欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

企业应用下的业务组件开发实践 博客分类: 架构乱弹 企业应用应用服务器OSGI框架EJB 

程序员文章站 2024-03-19 17:13:04
...

作者:  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

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