企业应用下的业务组件开发实践

什么是企业应用下的业务组件

首先，这是一个组件，这意味着它需要在容器里运行，因此不包括任何中间件服务，同时以一定结构（文件结构或者压缩格式）组成，被容器识别；其次，这是一个业务组件，即提供的是应用服务，而非技术服务；第三，这是企业应用，在业务上包括功能和服务（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却面临着多个企业用户的需求，面临定制化带来的维护问题，特别是业务和技术的隔离问题（即如何保持构建业务组件的所使用技术的平稳升级）。

 

组件的容器

既然要企业应用下的业务组件，而现有的组件技术又无法支撑，那么就需要一个新的组件容器了（当然，作为一个普通开发人员，我们无法新建一个公开标准的组件体系，也独立维护一个私有的）。新的组件容器完全使用现有的中间件技术，并加上一些新的内容，包括如下：

组件框架，识别组件，以及组件（文件）结构和各个技术工件。
技术框架，提供业务无关的技术支持，以便于技术的平稳升级切换。
运行容器，采用现有中间件技术，包括Tomcat、应用服务器和数据库服务等；
工具，包括打包以及部署工具等。
关于数据隔离问题，在EIP中提到了各种解决方案，这里采用的共享数据库方式，即各个组件都共用一个数据库，各个组件只提供数据库定义和初时数据（如同EJB/OSGi一样，运行时环境由容器提供）。

 

组件的关系

组件的关系分为两种：依赖和联动。依赖关系在已有的组件技术上已经广为认知，而联动则是新创造的（肯定不是第一个创建的，只不过不同人有不同的叫法）。

联动和依赖的区别是：如果有组件B和组件A联动，则组件B可以在没有组件A的情况下运行，并提供相应功能。

针对三种不同技术工件（即三个隔离问题）呈现不同特点，如下：

1. UI资源（交互隔离问题），依赖是指UI资源的嵌入、引用和替换，联动是指UI资源的新增。

2. 应用程序（程序访问隔离），依赖是指API/模型依赖，联动是指消息（传统消息和JMS消息）以及SPI实现。其中，无论是依赖或者联动都涉及到相应的非功能性需求，包括：异步、事务控制和服务时限等。

3. 数据库资源（数据隔离），依赖是指外键关联和级联操作，无明显的联动关系。

这里，需要关注应用程序的依赖和联动

1. SPI和API存在业务不匹配问题。

虽然组件A依赖组件B，但是不代表组件B提供的服务完全匹配组件A的要求。有时组件A所需要的数据需要组件B的多个API组成，为了开发方便或者组件A所需要的性能问题，可能会在组件B新写一个接口给组件A使用，注意该接口不是组件B的API，该接口仅适用于组件A。

2. 尽可能的使用SPI集成方式

SPI集成方式是相对于API集成方式，API集成方式就是，组件B直接调用其它组件的API及其模型。SPI集成方式（类似于依赖倒置），组件B定义其所需要的接口及其模型，由组件A或者胶水层代码来实现。

这个点对于行业ISV尤为明显。对于企业用户来说，依赖是明确的，组件A依赖/联动于组件B，但对于行业ISV，则面临着定制化问题，虽然组件A依赖/联动于组件B，但是在某个定制化项目中，由于客户已有系统C，而需要组件A依赖/联动于客户已有系统C。此时采用SPI方式。

在开源世界里采用SPI方式更是广泛。很多框架为了兼容（同一功能）不同实现的类库，都是先定义框架所需接口，并同时提供不同类库的胶水代码。

不论是EJB/OSGi/SCA都没有对SPI集成方式的支持。

3. 依赖和联动的非功能性需求。

事实上，非功能性需求都是在集成时才存在的。以事务管理为例，除了及其少数的例子外，大部分事务只能在处理流程才被决定（注意，EJB在这方面着是定义在API上的，这样的设计是不适应需求的），而组件A的API在用例1中需要被异步调用，而在用例2中需要被同步调用是常见的。即便是OSGi规范，也在这方面没有任何处理。

 

组件的定制化

定制化问题只针对于行业ISV有效，对于企业用户来说，除非是那种跨国企业在面临不同国度的业务模式、法律监管和会计制度等差异，存在定制化需要，即使如此，ISV和企业用户对于同一问题的解决方式也是不同的。

既然我们已经将原有的应用采用组件化方式开发，那么应用的定制化问题就转化为组件的定制化问题。同样，应用的定制化手段也就转化为组件的定制化手段。

 

组件框架

       罗罗嗦嗦的说了半天，有人就说了：这不就是把UI、Java和数据库三个东东一打包，然后说这就是一个企业应用下的业务组件，有啥新意呢，不就是模块化开发嘛，一直一来大家都是就是这么搞的嘛，何必搞个怪名词来忽悠。

       是的，就是把UI、Java和数据库三个东东整合在一起，组件容器说提到的技术框架很多的开发队伍都有一套，运行容器更是有无数开源商业的，打包部署工具更是写了无数。

这确确实实就是我们常说的模块化开发。但是模块化开发不同于组件开发，模块化开发只是在逻辑上做了切分，物理上（开发出的系统代码）通常并没有真正意义上的隔离，一切都只是在文档中。

我们需要一点干货，只有实实在在的组件框架才能组件化开发真正落地的（如同OSGi框架那样）：我们需要一个类似于Equinox的界面扩展框架来支持UI资源的依赖和联动；我们需要一个集成框架来支持应用程序的依赖和联动，解决所面临的种种问题（业务不匹配、SPI集成以及各种非功能性需求）；我们需要一个打包部署工具（类似Spring DM）提供部署UI资源、应用程序和数据库定义资源（Spring DM提供了基于Web资源的部署能力）。

 

其它问题

对于采用J2EE下B/S环境的组件应用还面临一个问题，即现有Servlet规范只允许一个web.xml，不支持组件各自定义私有的Filter和Servlet，不过这个问题不是很严重，在现有技术框架已经支持一份简单的web.xml，而新的Servlet规范已经允许多个web.xml。

分布式部署以及集群部署问题，这其实不是个问题。基于应用的我们有很多手段和技术，那么基于组件的也一样有办法。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/lins/archive/2010/02/21/5314529.aspx