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