代码改变世界

关于企业应用快速开发平台的思考

2011-10-21 17:29  elivsit  阅读(520)  评论(0编辑  收藏  举报

    企业构建自己的信息系统,有两种途径,一是购买现有产品,而是自主开发。即使购买现有产品的企业,因为所购买产品不是针对自身需求进行开发的,往往也需要进行二次开发。而企业应用系统的开发总是一个非常复杂的过程。因为企业应用需求的不确定性、开发工具和支撑平台的多样性、可用技术资源的匮乏性,导致企业应用开发常常投入大量资金确收效甚微。利用现有的开发平台,不管是微软的Visual StudioIBMWSADSunSun One,还是第三方独立软件供应商如borlandjBuilderDephi,进行一个典型的企业应用开发,都是非常困难的事情,因为这些开发工具的出发点都是面向技术层面的(更确切地说是面向软件工程师的),而不是面向企业需求的,因此,即使高级软件工程师和经验丰富的系统架构师也不能在短时间内快速构建出一个能满足通常应用的系统。

       是否能有一种面向企业需求的快速开发平台,可以满足各种规模企业应用的快速构建呢?

       总结一个典型的企业应用,不管它是企业资源计划(ERP)、客户关系管理(CRM)、电子政务(E-Government)、电子商务(E-Business)、工作流(WorkFlow)或是内容管理系统(CMS),都可能会具有如下特征:

Ø         安全:限制使用该系统的角色(Role)及相应权限(Permission),保护受限的资源(Resource),可能还需要对同类角色分组(Group)进行管理。

Ø         事务:对典型的电子交易或审批流程来说,事务是至关重要的一环,可保证一系统活动的全部完成或全部回滚。

Ø         对象关系映射:现有的主要编程模式多是OOP,而主要的数据存储方式都是RDBMS,因此几乎每种应用都涉及到对象关系映射O/R Mapping

Ø         消息服务:每个活动、每个子系统之间如何传递消息。消息的传递方式应该是一种统一的模型,与所选用的平台和所构建的系统无关。

Ø         缓存和及时更新:对高并发、大访问量的系统,需要增加缓存策略,缓存最常访问的信息,同时要保证这些信息及时更新。

Ø         日志:对操作流程进行记录,保证操作的不可抵赖性;对错误信息进行记录,便于对系统进行调试和监控。

对于各种企业应用来说,这些特征不是必须的,而是可选配置。我们需要的是一种设计良好可插入式企业功能组件,每个组件满足一个特定的企业需求,然后可使用这些组件来快速构建企业应用。

2目标

       构建一个企业应用快速开发平台,需要这么几个部分:

Ø         企业功能组件组件:包括安全、事务、对象关系映射、消息服务、缓存机制、日志管理等。每种组件使用AOP技术实现,对外提供统一接口,可横向插入系统,不具侵入性,不会影响其它子系统的设计实现。

Ø         抽象容器层:企业应用遵循标准的J2EE标准,但是运行在一个抽象容器层之上,以便于将系统与底层的中间件服务器分离,这样可使企业应用独立于J2EE应用服务器。

Ø         模板和向导:为每种组件提供一个模板,以描述该组件的功能和提供的接口。向导则使用模板定义的规则将该组件构建为子系统。

Ø         构建系统:构建系统应该独立于各种集成开发环境IDE,自动地将各种组件、各个子系统构建为完整的企业应用。

 

企业应用快速开发平台应该使用开放的标准如javaXML和得到广泛使用的开源工具如antxdoclet等进行构建,尽量不依赖于操作系统和应用服务器。

3技术方案

企业应用快速开发平台的整体结构如下:

        首先是企业功能组件。所有的企业功能组件,不管是既有的还是重新设计的,都必须遵循IOCInversion of control)和AOPAspects-Oriented Programming)设计范式,可以动态地插入到IOC/AOP Container中运行。组件与组件之间应该是链状的关系,彼此不相互依赖,如下图:

每个组件还必须提供自描述的基于XML的模板文件(templates),该模板文件定义了这个组件实现的功能,所提供的接口,所需的资源。在构建系统时,将根据这个模板文件来组装(或插入)这个组件。

       第二是IOC/AOP Container容器。该容器将提供各个组件运行所需的最小运行时环境(Runtime Context),一经实现,它将是稳定的内核,对每一个新的企业应用开发来说,它是内部底层的东西,不需要开发人员去注意和了解。

       第三是向导Wizards。使用Wizards来定义一些典型应用的封装过程(即如何将既有组件组合为一个特定的企业应用),在更高一级抽象层次上描述企业应用的快速开发过程。开发人员可以使用向导逐步构建一个系统,并且在每一步向导中所做的设置在向导完成后都可以再更改。向导的实现可以有两种方式,一是基于XML的模板使用命令行完成,类似于unixmake工具。第二是开发eclipse插件,使用图形界面的形式完成。

       最后是构建系统Build System。这一步将完成整个企业应用的构建,前提是存在可用企业功能组件,每个功能组件都有完善的自我描述模板,并使用向导对这些组件的封装进行了设置。在此基础上,使用ANTXDOCLET技术或其扩展形式完成系统的构建。构建系统应该完成编译、部署、运行和测试的工作。

 

 Aop技术

    面向 Aspect 的编程(AOPAspect-Ooriented Programming)是一种新型编程技术。UML的创始人Grandy Booch认为AOP会是下十年最重要的编程技术。传统的程序经常表现出一些不能自然地适合单个程序模块或者几个紧密相关的程序模块的行为,因此面向 Aspect 的编程(AOP)应运而生。Aspect 的先驱将这种行为称为横切(Crosscuts),因为它跨越了给定编程模型中的典型职责界限。例如,在面向对象的编程中,模块性的天然单位是类,横切关系是一种跨越多个类的关系。典型横切关系包括日志记录、对上下文敏感的错误处理、性能优化以及设计模式。

       面向方面编程AOP是一个令人兴奋的新模式。面向对象编程(OOPObject-Oriented Programming)是过去十年最重要的编程技术,主要用于为同一对象层次的公用行为建模。它的主要弱点是对象之间的关系必须是静态的,一个公用的功能模块也不得不由多个对象模型来实现,因此,任一需求的变化、任一对象模型的变化都可能导致软件工程的延期。而这恰恰是AOP适合的地方。AOP技术允许我们动态地设计新的模型来满足变更的需求,而不必修改原有的静态模型。另外,我们可以将这些模型的代码统一放置在一个地方,仅提供一个接口为外界服务,而不是将代码分散在很多包和类中。AOPOOP式互为补充的开发技术。AOP可以从原来分散在包、类、方法里面的功能模块抽象出来,封装为更易于维护和为外界提供调用接口的拦截器Interceptor,每个Interceptor专注于完成自己的功能而不与无关的模块交互,每个Interceptor都是可插拔的。AOP技术可以将完成特定功能的相关对象组合在一起,使得代码有更好的可读性并便于维护。

    目前AOP具体实现有以下几个项目:

AspectJ (TM):创建于Xerox PARC. 有近十年历史,技术成熟,目前和eclipse结合了。缺点是过于复杂;破坏封装;需要专门的Java编译器。

动态AOP:使用JDK的动态代理API或字节码Bytecode处理技术。

基于动态代理API的具体项目有:JBoss4nanning

基于字节码的项目有:aspectwerkzspring

    后三种AOP技术均可直接运行于java平台。目前国内还没有可用的AOP产品。

IOC技术

       IOCInversion of Control的简称。它的原理是基于OO设计原则的好莱坞原则(The Hollywood Principle):不要访问我,我们将访问你。也就是说,所有的组件都是被动的(Passive),所有的组件初始化和调用都由容器负责。IOC有几种实现的类型,包括基于方法参数调用的Method-based (M) IoC,它把组件传递给每个方法调用;基于接口的Interface-based (I) IoC(通常称为类型1),它使用接口来声明组件之间的依赖性,例如,Serviceable, Configurable;基于Setter方法的Setter-based (S) IoC(通常称为类型2),它使用setter方法来设置组件之间的依赖性;基于构造函数的Constructor-based (C) IoC(通常称为类型3)。IOC是框架开发的一个基本原理。在开源软件中,不少的容器类框架都采用了IOC的思路。例如PicoContainer采用了类型3IOC技术,Spring主要采用了类型2IOC技术,而apacheAvalon则主要采用了类型1IOC技术。国内目前还没有基于IOC技术的产品。

 

企业功能组件

       基于AOP技术和IOC技术的企业功能组件,主要是按企业应用需求进行划分的。许多企业应用所需的功能如安全和用户验证模块,几乎在所有的系统里都需要重新开发一遍,这是对软件资源的极大浪费。而采用AOPIOC技术来设计这个功能模块,就完全可以在不同的系统里复用这个功能组件,极大地提高软件的复用率和生产效率。目前国内外都还没有对该课题进行专门的研究,没有现成的产品可用。