运用J2EE创建灵活易扩展的企业应用程序探讨
alix_an@sohu.com
内容摘要
在J2EE技术飞速发展的今天，各种技术框架和设计模式层出不穷，每种技术都有各自的优势与劣势。目前，没有一种技术处于绝对的霸主地位，如何使我们的应用程序不过多地依赖某种实现技术，具有强的可扩展性，同时，能更好地集成各种技术框架，使他们发挥最大的优势，是我们创建企业应用时，应该考虑的问题。本文主要介绍了笔者基于SOA（Service Oriented Architecture）思想而设计的MiniSOA构架的设计原理，核心组件与使用示例，它能很好地帮您集成各种技术，使您轻松地选择自己的表现层、业务层和数据持久层，“无痛”切换各个层面的技术实现，降低各个层面的耦合性，同时满足多小组的团队开发，提高开发效率，最大限度地发挥开发人员的技术优势。
引言
随着J2EE的飞速发展，已经有越来越多的企业应用程序以J2EE技术为其构建的基石，J2EE本身并不是产品，它只是制定了一套创建企业应用程序的规范，不同厂商根据J2EE规范，创建了符合J2EE规范的产品，这给予了我们更多的选择创建企业应用的平台。
一个典型的J2EE的应用，至少应该包括以下三部分：表现层，业务逻辑层和数据持久层，为了更加容易地创建企业应用程序，许许多多的Framework涌现出来，表现层我们可以选择Struts, JSF, Tapestry, WebWork, Velocity等， 数据持久层我们可以选择原始的JDBC, ORMapping tools(Hibernate,toplink等),SQLMapper tools(Ibatis),JDO, EJB(Entity Bean)等，业务逻辑层我们可以用普通的JAVA Beans,也可以用EJB(Session Bean)。每种技术都有它的优点与缺点，各自有各自的适用范畴，例如EJB可以很好地进行分布式处理和Object Cache等，但EJB的运行需要EJB容器，开发调试起来很不方便，特别在需求不确定性很大、模型不稳定的情况下，实在是一种重量级别的开发；而JAVA BEAN则是一种很轻量级的方式，开发调试容易，但又很难实现分布式处理。在各种技术纷争的今天，暂时还没有一种技术处于绝对的霸主地位，在这种条件下，我们不能把“赌注“押在任何一种技术上，如何使我们的应用程序有很高的灵活性和易扩展性是我们要仔细研究的课题。
在实际的项目中，关于应用程序开发时所用技术的问题，大致存在两种情况，一种是构架师或技术经理没有严格限定用什么技术来实现具体的业务逻辑或者只有简单的开发规范，程序员在开发时，只是依据自己的技术背景，选择自己熟悉的实现方式，这种情况一般属于横向开发，在小的项目中，每个人只做自己负责的一个模块，从表现层，业务逻辑层，一直到数据层，都由同一个人来负责，这种方式给了技术人员更多的自我发挥能力的空间，但不便于后期维护，特别是人员流动频繁的情况下，问题更是严重。第二种情况是构架师或技术经理在项目初期从开发成本，项目需求等等各个方面做出评估，经过几番取舍，确定项目各个层面使用什么样的技术实现方式，按不同层面进行分工，不同的工作人员负责不同层面的技术实现，这种方式比第一种方式要好得多，适合校大项目的开发，但也存在很多问题。在目前各种实现技术纷争的情况下，没有一种技术是万能的，在做取舍时，难免和某一技术或实现方式依赖性过强，同时限定了技术人员个人技术特长的很好发挥，当由于某些原因要更改实现方式时，经常是牵一发而动全身，造成资源的极大浪费和开发成本的提高。
所以，在构建企业应用时，应该有个好的技术框架，这个框架应该考虑到各种主流的实现技术，我们既可以根据实际情况进行取舍，同时在从一种实现方式变更为另一种实现方式时，又可以进行平滑过度，让多种技术实现并存，发挥技术人员的最大优势，降低项目成本，提高开发效率。
基于SOA的构架
图一
SOA(Service Oriented Architecture),对这一术语我们并不陌生，因为Web service是基于SOA的一种技术，服务的提供者将提供的服务注册到UDDI，其使用者从UDDI上获得服务的描述（WSDL），然后根据服务接口使用服务。Web Service用XML进行消息的传递,通过SOAP绑定在现有的轻量级协议，如HTTP之上，可以透过防火墙，不依赖服务端和客户端具体地实现技术，进行分布式远程调用，它是现有的应用向Internet的延伸。Web service在EAI,B2B,应用到应用的集成等方面体现了巨大的优势，有很多文献介绍Web service，由于这不是本文重点，在此不再赘述。
SOA的优势在于降低了服务的提供者与使用者之间的耦合性，服务的提供者将自己提供的服务注册在中介那里，服务使用者先通过中介查找自己所需服务，使用者获得的是服务接口，但并不知道服务的具体实现，它根据调用接口调用服务，这样即使服务的实现方式发生了变化，只要供使用者调用接口没有改变，服务使用者就不会受到任何影响，这种思想正是我们应该学习和借鉴的地方。那么既然Web service是基于SOA的，我们的企业应用是不是就可以完全构架在Web service上呢？我们并不建议这么做，Web service对于企业内部的应用并不太适合，在一个应用内部使用Web service，系统大量的资源花费在进行XML消息的解析和进行远程调用上，造成系统运转缓慢。当然，从某种意义上讲，EJB也是SOA的一种实现，服务的提供者把服务注册在JNDI上，使用者通过JNDI找到自己想要的服务，通过远程接口使用服务，但EJB的运行需要EJB 容器，开发调试起来不方便，特别对于需求经常变化的系统，进行EJB调试的时间会更久。我们所需要的是一个轻量级的构架，能兼顾各种主流的技术，但又不依赖具体的某个实现方式，当实现方式从一种技术变更为另一种技术时，对于服务的使用者来说几乎没有影响，从而实现客户端和服务器端的松耦合，这样，我们的表现层，业务逻辑层和数据持久层都可以依据实际需求情况与偏好随意选择各种实现方式。
MiniSOA构架介绍
MiniSOA设计思想
MiniSOA是以SOA思想为指导的一个极其轻量级的构架，其主旨是降低服务使用者和提供者之间的耦合度，使现在流行的多种技术能够很好的并存，并充分发挥各自的优势，技术人员能够发挥自己的特长，用自己熟悉的技术来实现业务逻辑，同时应用程序某些层面能够方便的在不同的实现技术之间进行切换，而不会对其他层面造成影响。MiniSOA没有创建一个新的编程模式，没有Web service,EJB那么工业化的庞大，它只是通过XML配置把应用组件装配在一起，通过必要的缓存，提高组件的运行效率，自动管理组件运行时的事务、环境参数等信息，使其能更有效的运行，同时，提供多小组的团队开发的支持，并方便进行单元测试，使开发人员集中精力开发业务逻辑，提高劳动生产率。
图二
MiniSOA概述
为了降低表现层，业务层和数据持久层等各个层面之间的耦合性，各个层面使用其他层面提供的服务时，不是直接去使用服务对象，而是通过服务中介，查找定位服务接口，通过接口来访问服务，服务提供者可以通过各种方式来实现服务接口，然后把提供的服务注册到服务中介，服务中介是服务使用者和服务提供者之间进行通讯的桥梁，可以在服务中介上做一些其他方面的控制，如事务，安全等。
表现层作为业务层的使用者，在使用业务层提供的服务时，通过Business Service Manager这个中介来查找和使用服务接口；业务层是表现层的服务提供者，它把通过各种方式实现的服务对象注册到Business Service Manager,供表现层对象使用，同时业务层也是数据持久层服务的使用者，它通过Data Access Object Manager这个中介来使用数据持久层提供的服务；同样数据持久层把对数据库，文件等资源的存取进行封装，把以各种方式提供的服务对象以接口的形式注册到Data Access Object Manager,供业务层对象使用。
图三
MiniSOA包括业务层和数据持久层两部分组件，业务层的核心组件是ServiceManager, 它是表现层和业务层进行交互的桥梁；数据持久层的核心组件是DaoManager,它是业务层和数据持久层进行交互的桥梁。根据数据模型和业务需求，定义提供的服务接口后，开发人员用自己熟悉的技术开发接口的实现组件，经过单元测试后，把服务接口、实现组件和相应的事务，环境参数等信息配置到dao-conf.xml,service-conf.xml文件，服务使用者就可以通过ServiceManager,DaoManager来查找所需的服务接口，调用服务方法。
MiniSOA 业务层核心组件简介：
l ServiceFacotry：作为表现层调用业务层的Facade,它读取service-factory-conf.xml配置文件，创建用于各个模块的ServiceManager，便于多个开发小组的分工合作。
l Service-factory-conf.xml 实例：
<servie-factory>
<factory>
<service-id>module1</service-id>
<service-file>module1-service-conf.xml</service-file>
</factory>
<factory>
<service-id>module2</service-id>
<service-file>module2-service-conf.xml</service-file>
</factory>
</servie-factory>
通过service-factory-conf.xml配置文件，每个模块可以使用和本模块相关的service配置，适合多个开发小组共同开发，有效避免了资源冲突。
l ServiceManager, ServiceManagerBuilder：ServiceManagerBuilder用于读取serivice-conf.xml配置信息，创建每个service对象使用的环境对象ServiceContext，返回用于服务使用者查找具体服务的ServiceManager接口。
l Service-conf.xml实例：
<service-config>
<settings
cglib-enabled="true"
dao-config="dao-hibernate-conf.xml"
/>
<service singleton="true" runas="java-bean">
<interface>demo.Order</interface>
<java-bean>
<implementation>demo.OrderImpl</implementation>
</java-bean>
<environment>
<name>smtphost</name>
<value>mail.mycom.com</value>
</environment>
<environment>
<name>mailfrom</name>
<value>from@mycom.com</value>
</environment>
<transaction>
<method>sendMail</method>
<trans-automanagement>false</trans-automanagement>
</transaction>
<transaction>
<method>*</method>
<trans-automanagement>true</trans-automanagement>
</transaction>
</service>
<service singleton = "false" >
...
</service>
</service-config>
供使用者使用的每个service分别配置在<service>标签中，cglib-enable属性用于配置本模块的services是否要用cglib来增强Proxy功能，dao-config属性指定service使用的dao配置信息，runas属性设置service的实现方式：(java-bean,remote-ejb,corba,webservice),singleton属性用于配置service是否是单一实例的，如果singleton为true,则此service在第一次创建和使用后，被ServiceManager缓存起来,其他Client再请求此service时，则使用被缓存的对象，而不会再被创建，singleton为true的service是无状态的，不能保持每个Client的状态信息，相反，singleton为false的service是有状态的，每个Client都使用自己的service对象，它们之间互不影响。
l ServiceContext：是ServiceManager和service实现组件之间传递信息的桥梁，ServiceContext里保存了每个Service的环境变量的配置，每个方法的事务配置等信息。
l ServiceProxy：是ServiceManager创建service对象的代理对象，用于增强对service的控制。
关于数据持久层的各个组件的功能和业务层的各个组件功能类似，在此不再赘述。
使用MiniSOA进行应用程序开发示例
下面我们模拟银行转帐业务，来示例如何使用MiniSOA开发应用程序。
1. 定义用户接口组件Bank：
public interface Bank {
void transfer(String srcAccountNo,String destAccountNo, float amount );
}
2. 实现用户接口组件(用Java Bean + DAO)
public class BankImpl extends BaseService implements Bank { //BaseService是MiniSOA提供的服务接口实现组件的父类
public void transfer(String srcAccountNo,String destAccountNo, float amount ) {
try{
//通过ServiceContext得到DaoManager
DaoManager daoManager =
serviceContext.getServiceManager().getDaoManager();
//通过DaoManager得到数据访问层接口AccountDao
AccountDao accountDao =
(AccountDao) daoManager.getDao(AccountDao.class);
//通过AccountDao接口得到每个账号对应的Account信息
Account srcAccount = accountDao.findAccountByPK(srcAccountNo);
Account destAccount = accountDao.findAccountByPK(destAccountNo);
//对Account进行加、减帐户金额的操作
srcAccount.setAmount( srcAccount.getAccount() ? amount);
destAccount.setAmount( destAccount.getAccount() + amount);
//将更新的帐户信息写回到数据库
accountDao.updateAccount(srcAccount);
accountDao.updateAccount(destAccount);
}catch(Exception e) { … …}
}
}
注意对银行转帐业务逻辑的实现，必须在同一个事务中进行，否则，将导致数据的不一致，而上面对Bank的transfer方法并没有进行手工的Transaction的管理，下面在Service的配置中，可以让MiniSOA自动管理Transaction。
3. 配置service-factory-conf.xml,和本模块的service-config.xml文件，由MiniSOA自动管理Transaction
service-factory-conf.xml示例：
<servie-factory>
<factory>
<service-id> bankModule </service-id>
<service-file> bankModule-service-conf.xml</service-file>
</factory>
…
</service-factory>
bankModule-service-conf.xml示例：
<service-config>
<settings
cglib-enabled="true"
dao-config="dao-hibernate-conf.xml"
/>
<service singleton="true" runas=”java-bean”>
<interface>demo.Bank</interface>
<java-bean>
<implementation>demo.BankImpl</implementation>
</java-bean>
<transaction>
<method>transfer</method>
<trans-automanagement>true</trans-automanagement>
</transaction>
</service>
</service-config>
4. 写Client程序，调用Bank service
//先得到srcAccountNo, destAccountNo,amount
……
//得到ServiceFactory
ServiceFactory serviceFactory = ServiceFactory.getInstance();
//通过ServiceFactory得到本模块的ServiceManager
ServiceManager sm = serviceFactory.getServiceManager(“bankModule”);
//通过ServiceManager得到服务的操作接口Bank
Bank bank = (Bank)sm.getService(Bank.class);
//使用服务
if ( bank != null ) {
bank.transfer(srcAccountNo, destAccountNo, amount);
}
……
对于表现层，只要我们的Bank这个Interface不发生变化，我们可以选择任何框架技术，无论是基于MVC的Struts,JSF，还是Java Application, Java Applet对业务层都没有任何影响。
总结
以上初步介绍了我的MiniSOA构架的设计思想、核心组件以及使用MiniSOA开发的简单示例，使用MiniSOA我们可以很简单地创建灵活，具有易扩展性且不依赖于具体实现技术的应用程序，能够很好地集成各种流行的技术，在充分发挥各种技术优势的同时，最大限度地释放出开发人员的技术优势，同时有利于小组间的分工与合作，提高软件开发效率。
对MiniSOA有兴趣的读者可以向笔者索要免费的MiniSOA运行库、示例和技术支持，希望与您共同探讨可重用的软件构架技术， alix_an@sohu.com
|