业务组件开发在企业中的应用

为什么80%的码农都做不了架构师？>>>   

首先，这是一个组件，这意味着它需要在容器里运行，因此不包括任何中间件服务，同时以一定结构（文件结构或者压缩格式）组成，被容器识别；其次，这是一个 业务组件，即提供的是应用服务，而非技术服务；第三，这是企业应用，在业务上包括功能和服务（Service，当前最时髦的说法，你可以理解为API），技术上（以J2EE来讲）包括：UI资源（JSF、JSP、JS和CSS等）、应用程序（Java）资源和配置文件、数据库表定义、初始化数据和存储过程。

组件技术从提出到现在已经有20多年了，为什么要提企业应用业务组件？因为现有的组件技术不支持企业应用环境下的组件要求，J2EE的EJB不支持，.NET的DLL也不支持。

如前所述，一个企业应用通常包括了交互界面、应用代码以及 数据库结构，而不论是EJB还是DLL只支持应用代码，都不包括交互界面和数据库结构。

如果说EJB不是，那么J2EE的EAR或者WAR是否算是一个组件？答案也不是，EAR或者WAR部署的是一个企业应用，请注意EJB规范中明确说：The Enterprise JavaBeans architecture is a architecture for the development and deployment of component-based (distributed) business applications(EJB 2.x和3.x唯一的区别是2.x有distributed），它们有自己的应用域，彼此相互隔离（简单的看，它们有各自独立的会话管理）。.NET也是有自己的应用域概念。

更进一步，基于应用的部署导致了三个隔离问题： 交互（界面）隔离、 程序访问隔离和 数据隔离（请注意这三个问题分别对应了企业应用业务组件的三个技术内容）。交互隔离导致了企业用户必须访问不同界面， 代码访问隔离导致了点对点的集成以及诸如性能、事务和异步处理等各种非功能性问题，而数据隔离导致了数据有效性、一致性等等问题。所有这些都进而导致了维护的问题。

为了解决这些问题，大厂商们都提出了各种解决方案：Portal来解决交互隔离问题，通过ESB来解决代码访问隔离问题，以及通过所谓的信息服务（Information Service）来解决数据隔离问题。

那么OSGi技术或者SCA技术能否满足要求？答案是目前不能，OSGi最初开发的目的就不是为了企业应用，只是这几年开始成熟，并向企业应用方向发展。09年推出的企业版（草案）刚刚提出针对程序访问问题的方案，如远程服务、事务管理等；交互隔离问题上规范并没有提出相应方案，只有Eclipse的Equinox提出了界面的扩展点机制，但这也不能解决B/S环境的问题；而数据隔离问题就没有任何方案。SCA从一开始就是面向企业应用，不过不解决交互隔离和数据隔离问题。

此外，对于行业ISV来说，除企业用户面临的这些种种问题，还面临着其它问题。企业用户毕竟只是面对自己的需求，行业ISV却面临着多个企业用户的需求，面临定制化带来的维护问题，特别是业务和技术的隔离问题（即如何保持构建 业务组件的所使用技术的平稳升级）。

 

本文转载自oecp社区 http://www.oecp.cn/hi/yongtree/blog/1408

转载于:https://my.oschina.net/oecp/blog/15041