作者:  Anders小明


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

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

 

为什么要企业应用下的业务组件

组件技术从提出到现在已经有20多年了,为什么要提企业应用业务组件?因为现有的组件技术不支持企业应用环境下的组件要求,J2EEEJB不支持,.NETDLL也不支持。

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

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

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

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

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

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

 

组件的容器

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

  1. 组件框架,识别组件,以及组件(文件)结构和各个技术工件。
  2. 技术框架,提供业务无关的技术支持,以便于技术的平稳升级切换。
  3. 运行容器,采用现有中间件技术,包括Tomcat、应用服务器和数据库服务等;
  4. 工具,包括打包以及部署工具等。

关于数据隔离问题,在EIP中提到了各种解决方案,这里采用的共享数据库方式,即各个组件都共用一个数据库,各个组件只提供数据库定义和初时数据(如同EJB/OSGi一样,运行时环境由容器提供)。

 

组件的关系

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

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

针对三种不同技术工件(即三个隔离问题)呈现不同特点,如下:

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

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

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

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

1. SPIAPI存在业务不匹配问题。

虽然组件A依赖组件B,但是不代表组件B提供的服务完全匹配组件A的要求。有时组件A所需要的数据需要组件B的多个API组成,为了开发方便或者组件A所需要的性能问题,可能会在组件B新写一个接口给组件A使用,注意该接口不是组件BAPI,该接口仅适用于组件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上的,这样的设计是不适应需求的),而组件AAPI在用例1中需要被异步调用,而在用例2中需要被同步调用是常见的。即便是OSGi规范,也在这方面没有任何处理。

 

组件的定制化

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

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

 

组件框架

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

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

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

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

 

其它问题

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

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

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐