??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>摘要:
q今为止Qweb应用E序开发的焦点在于业务逻辑装成服务。在q篇文章?Masayuki Otoshi业务流E也剥离出来,像那些业务q程理/工作品一P应用ZXML的文档来描述业务。但是这里他深入C(jin)更低的粒?操作。这文章同时展CZ(jin)可承的XML如何容许开发h员应用面向对象的概念L效的表示程
摘要
q今为止Qweb应用E序开发的焦点在于业务逻辑装成服务。在q篇文章?Masayuki Otoshi业务流E也剥离出来,像那些业务q程理/工作品一P应用ZXML的文档来描述业务。但是这里他深入C(jin)更低的粒?操作。这文章同时展CZ(jin)可承的XML如何容许开发h员应用面向对象的概念L效的表示程?br />
在开发web应用E序的过E中Q我们经常看C务流E和逻辑在action中一赯实现Q比如JSF中的后台bean和Struts中的actioncR在现有框架的帮助下Q比如EJB和Spring,我们能把业务逻辑剥离出来Q但是业务流E始l还是嵌入在具体操作中?br />
BPM(业务程理)标准Q比如BPMN(业务程建模W号)和BPELQ业务流E执行语aQ,提供?jin)一U分M务流E的途径Q那是应用ZXML文档来描q这U分R这U方法的另外一个好处可以在SOA(面向服务架构)基础上设计应用程序。但是,q种Ҏ(gu)使得在web应用E序不能很好地应用action.actoin的粒度对于BPM/工作品来讲太低了(jin)。他们通常专注于更高的业务范围Q如B2B应用E序和企业的应用整合,而且他们假定业务分析人员?x)按照?所C的Ҏ(gu)来描q流E。但是在更低的粒度上Q比如actionQ流E再用的可能性更大?br />
?. _度比较
在这文章中Q对于比较小的业务需求范_(d)我徏议java开发h员用J-SOFAQJava Services Orchestration for Actions, ActionUJAVA服务协调Q。J-SOFA是一U协调服务的框架Q这里的服务对应于类中的一个方法,无论是POJO(单洁净Java对象)或者web服务?br />
׃_度不同QJ-SOFAq不支持消息Q状态管理,监控{等的同步。但是不用担?j),目前的BPM/工作品都支持q些功能Q我们可以直接应用这些品。这文章所讲到的服务协调框架主要关注于提供业务程的可用性,像服务那样?br />?说明?jin)剥ȝ业务程可以被其他应用程序重复利用?br />
?2. 可重用的业务程?qing)服?br />
版权声明QQ何获得Matrix授权的网站,转蝲时请务必保留以下作者信息和链接
作?Masayuki Otoshi ;rainh95(作者的blog:http://blog.matrix.org.cn/page/rainh95)
原文:http://www.javaworld.com/javaworld/jw-04-2006/jw-0417-sofa.html?lsrc=jwrss
Matrix:http://www.matrix.org.cn/resource/article/44/44500_Business+Services.html
关键?Business;Services
JSF中的单action
让我们来看看用JSF开发的web应用E序中的一些简单action的代码。我们的例子是一个简单的模型搜烦(ch)E序Q根据用戯入的模型IDq回模型具体信息?br />
你可以从q个资源下蝲q个CZ的源代码?br />
在搜索jsp面上,有一个文本框和一个submit按钮Q用户可以输入model id然后提交。这个jsp面通过一个叫ModelBean的后台bean调用showModel()Ҏ(gu)。如列表1所C?
列表 1. search.jsp中的inputText?qing)Submit按钮<h:inputText id="modelId" value="#{ModelBean.modelId}" />
<h:commandButton type="submit" value="Submit" action="#{ModelBean.showModel}" />
Z(jin)产生模型具体信息面(搜烦(ch)l果面)QshowModel()Ҏ(gu)创徏Model对象和特征表Q再赋值到属性当?br />
列表 2. 在backing bean中的showModel()Ҏ(gu)public String showModel() {
if (modelId > 0) {
ModelService modelService = new ModelService();
BeanUtils.copyProperties(this, modelService.create(modelId));
setFeatures(modelService.getFeatures(modelId));
}
...
}
高开发h员可以像上面展示的代码一样将业务逻辑从具体操作中分离出来Q通过一个model的service实现创徏model和featuresQ再通过interface来调用它。不怎样Q如果其他h来维护后台beanQ我们还能保持这个方法这L(fng)单吗Q这样做可能被证明非常困难,因ؓ(f)不是所有的开发h员都明白隔离展现层和业务层的好处。如果一个持有不同观点的开发h员开发维护后台bean,?他可能会(x)业务逻辑加入到showModel()中去。在目中,q种状况是很q_的,因ؓ(f)E序设计语言Q比如这个例子中用到的java,容许我们用它强大的表现能力去实现M业务逻辑。因此,我们应该用另外一U语adC务流E,而不是java?br />
从一个框架的角度来看Q预防开发h员沉Z流E和逻辑攑֜一h非常重要的。描qC务流E的语言可能难于实现逻辑Q但与此同时Q却能像~程语言一样富有表现力。目前,需要应用BPM/工作的概念d加框架的解决Ҏ(gu)。对于这个问题,我徏议用XML-based文档Q程序定义XMLQ去描述程Q它可以指定需要按照什么顺序调用哪些service。从而,应用?jin)J-SOFA之后, showModel()Ҏ(gu)中的程可以像下面这栯C?
列表 3. process.xml <process>
<if test="${modelId > 0}">
<service name="modelService" operation="create">
<return name="model" />
</service>
<service name="modelService" operation="getFeatures">
<return name="features" />
</service>
</if>
</process>
在上面的XML?modelService的两个操作通过service标签被调用,service标签对应于servicelg中所实现的方法。他们也可以被应用于条g或@环语句中Q如if,choose,forEach{。然而,他们q是不如~程语言富于表现力。另外,J-SOFAq不能执行从service标签中获得的模型和特性对象的Ҏ(gu)Q除非是通过getterҎ(gu)。这些限制条件要求开发h员用XML描述业务逻辑时具备更加复杂的知识才干Q不怎样Q它们还是能帮助开发h员决定哪些业务逻辑应该用servicecd现。有q些service方式实现的业务逻辑Q我们可以开发基于SOA的应用程序,更能快速适应各种各样业务模型的变化?br />
典型的web应用E序框架不支持服务协调,如JSF和Struts。所以,我们必须在showModel()Ҏ(gu)中编写下面的代码L行处理:(x)
列表 4. 调用程的showModel()Ҏ(gu)public String showModel() {
ProcessInstance process = new ProcessInstance("process.xml");
ProcessContext context = new ProcessContext();
context.put("modelId", modelId);
process.execute(context);
BeanUtils.copyProperties(this, context.get("model"));
setFeatures((List) context.get("features"));
...
}
无论如何Q如果框架拥有支持调用处理的功能Q我们不需要创建action。相反,我们需要:(x)
--创徏程定义XML
--创徏用于在处理中被调用的servicelg
--在JSP面~写昄处理q回值的代码
在这部分Q我解释?jin)流E定义XML如何为action定义程Q无论如何,其中的有些定义可以在真实世界中被重用。在下一节中Q我用另外一个例子去说明如何再利用流E?br />
可承的XML
创徏程的时候,我们发现有些可以被其他的流E共享。D个例子,我创Z(jin)4个页面,如下?所C:(x)模型总览Q模型特性,和其他两U分cȝ(ch)引页面。所有的面包含相同的标题和脚。前两个模型面用同一个Model对象来显C模型信息,如模型名U。后两个分类面同样那个也是用一个Category对象。最后,每个面有自己单独的面处理q程?br />
?. 程中的׃n?br />
在这个案例中Q每个流Q如模型Ҏ(gu),能用subProcess标签标识Q它能执行另外一个叫做“sub-process”的程?br />
列表 5. modelFeatures.xml调用sub-processes
(注意Q在q个和后面的清单中,Z(jin)化代码,service标签中的子标{ְ被省?<process>
<subProcess path="page.xml" /> ---------- (1)
<subProcess path="model.xml" /> ---------- (2)
<service name="modelService" operation="getFeatures" /> ----- (3)
</process>
面和模型流E隐藏在每个sub-process中,但是我们仍然能找C(1) ?(3)的连l流。所以,如果我们要修Ҏ(gu)Q比如改变流的顺序ؓ(f)(2), (3), (1),那么在另外的程中,也不得不做这U改变?br />
Z(jin)解决q个问题QJ-SOFA支持一U基于承的解决Ҏ(gu)。基本的思\是提供这样一U机Ӟ(x)容许导出一个基q程中的标签Q然后再重写它?br />
我们可以在process标签中用extends属性创Z个导?gu)E。在q个例子中,q程的层ơ结构能用如?表示Q?br />
?4. 程{?br />
Header和footer在基q程中定义,model和Category在导?gu)E中定义Q导?gu)E从基础q程中承了(jin)header和footer标签。每一个代表一个特定的面的过E,可以看成是model或categoryq程的扩展?br />在page.xml中,我们产生一个header和footer,可是Q我们ƈ不知道到底在q个面中会(x)昄什么内?模型或者分c?)在此刻,abstract标签?x)被导出程中的其他标签重写Q可以按如下方式应用:
列表 6. page.xml (基础程) <process>
<service id="header" name="commonService" operation="getHeader" />
<service id="footer" name="commonService" operation="getFooter" />
<abstract id="contents" />
</process>
在列?中,model.xml可以看成是从page.xml得到的,所以,page.xml被列入process标签的extends属性中。在q个XML块中Q我们只需要描q需要重写的标签。在q个案例中,model.xml中的group标签重写?jin)abstract标签Q它在page.xml中有着相同的id ”contents?
在这个时候,我们知道必须创徏Model对象Q可是我们不知道I竟哪个面?x)调用这个过E。因此,我们不创Z个具体的q程Q而是用abstract标签表示特定面的内容:(x)
列表 7. model.xml (l承程) <process extends="page.xml">
<group id="contents">
<service name="modelService" operation="create" />
<abstract id="pageContents" />
</group>
</process>
如列?所C?具体面内容在从model.xmll承的modelFeatures.xml中描q。除?jin)特性表之外所有我们需要创建的服务Q都已经在基q程中定义,所以我们只需要重写abstract标签Q用service标签调用getFeature()操作。这P开发h员可以将焦点攑֜跟特定页面相关的处理上?br />
列表 8. modelFeatures.xml (具体程) <process extends="model.xml">
<service id="pageContents" name="modelService" operation="getFeatures" />
</process>
当过E实例被实例化时Qpage.xml,model.xml和modelFeatures.xmlq三个XML文档在执行之前被创徏,如下面列?所标示的那?
列表 9. Model Features的复合流E?<process>
<service id="header" name="commonService" operation="getHeader" />
<service id="footer" name="commonService" operation="getFooter" />
<group id="contents">
<service name="modelService" operation="create" />
<service id="pageContents" name="modelService" operation="getFeatures" />
</group>
</process>
应用XMLl承Ҏ(gu),开发h员能够重用在基础q程中表q的工作。开发h员同样可以提供定义通用的抽象q程,l其他开发h员描q特定页面的q程?br />
l论
用XML-based文档描述工作这个概念已l在BPM和工作流产品中实施。不怎样,到目前ؓ(f)?它主要用于高层次业务描述中。在本文?我们看到,q个概念同样适用于web应用E序中的action?br />服务协调框架直接帮助开发h员决定哪些流应该用过EXML描述,哪些逻辑应用用service实现。结果是,应用E序?x)基于SOA设计和开?重用性会(x)变得来好?br />
关于作?/b>
Masayuki Otoshi 是一个家公司的开发Web应用的高U程序员。他q负责这家公司的应用框架的设计与开发?
资源
---下蝲本文源码Q?br />http://www5f.biglobe.ne.jp/~webtest/jsofa/misc/jw-0417-sofa.zip
---J-SOFA主页Q?br />http://www5f.biglobe.ne.jp/~webtest/jsofa/
---Matrix:Java,开源和中间件社?/a>
---Javaworld:http://www.Javaworld.com
]]>
下面是它的首对它的介绍Q?br />J-SOFA是编排服务组件的一个轻量框架Q这些服务组件包括JSF中的Backing Bean 和Struts中的ActionQ等{。它使得我们可以把业务流E从动作中分d来ƈ且它q帮助我们将业务逻辑实现为服务。这让你的应用成为实C(jin)SOA的应用?
]]>
目录
1
l装模型
1.1
介绍
1.2
概述
1.3 模块
1.3.1 构g
1.3.2 构gcd
1.3.3 实现
1.3.4 接口
1.3.5 构g配置
1.3.6 覆盖属?/span>
1.3.7 外部服务
1.3.8 入口?/span>
1.3.9 q线
1.3.10 模块片段
1.4 子系l?/strong>
1.4.1 模块构g
1.4.2 覆盖
1.4.3 外部服务
1.4.4 入口?/span>
1.4.5 q线
1.5 l定
1.5.1 部vl定?/span>URI形式
1.5.2 SCAl定
1.5.3 Web服务l定
1.6 扩展模型
1.6.1 定义接口cd
1.6.2 定义实现cd
1.6.3 定义l定cd
2 附录1
2.1 打包与部|?/strong>
2.1.1 模块打包
2.1.2 子系l打?/span>
2.1.3 部v
2.2 XML Schemas
2.2.1 sca.xsd
2.2.2 sca-core.xsd
2.2.3 sca-interface-java.xsd
2.2.4 sca-interface-wsdl.xsd
2.2.5 sca-implementation-java.xsd
2.2.6 sca-binding-sca .xsd
2.2.7 ca-binding-web服务.xsd
2.3 UML模型
2.4 SCA概念
2.4.1 l定
2.4.2 构g
2.4.3 入口?/span>
2.4.4 外部服务
2.4.5 实现
2.4.6 接口
2.4.7 模块
2.4.8 模块构g
2.4.9 模块片段
2.4.10 属?/span>
2.4.11 服务
2.4.12 服务引用
2.4.13 子系l?/span>
2.4.14 pȝ
2.4.15 q线
2.5 提议的附加特?/strong>
2.5.1 扩展模型
2.5.2 外部服务的缺省引?/span>
3 附录2Q策略、安全、事务、可靠消?/span>
3.1 介绍
3.2 场景
3.3 交互{略
3.3.1 入口?/span>
3.3.2 外部服务
3.3.3 {略元模?/span>
3.4 实现{略
3.5 pȝ{略
3.6 {略
3.6.1 安全
3.6.2 事务
3.6.3 可靠消息
3.7 概要cd
3.7.1 WSI_BP_1.1
3.7.2 WSI_BSP_1.0
3.7.3 IBM_RAMP_1.0
3.7.4 implementationProfile.enterprise
4 参?/strong>
在中国的区中,宽带的连接成为基本配|,所以老的C曄也有同样的问题,而大量的新社个问题就不存在了(jin)。即便有无线局域网的技术,有线宽带的接口还是都提供的。新C的好处就是可以在一开始就部v新技术,而不需要走老\?span lang="EN-US">
如今Q全世界都在嚷嚷SOAQ那我们也需要考察国人怎么部vSOAQ中国h怎么部v。研I这个问题,Ҏ(gu)们Y件公司还是对我们的客户都是有极大帮助的,以免再一ơ被我们?span lang="EN-US">?/span>L?/span>厂商误导。因为,国人如何部|?span lang="EN-US">SOA军_国SOA产品的特征,中国人怎么部v军_中国SOA产品的特性?span lang="EN-US">
SOA 的核?j)是把业务流E功能模块构件化Qƈ对外提供标准的服务,Zq些服务Q企业内部的不同业务部门或是不同企业之间的业务整合就更加Ҏ(gu)一些?span lang="EN-US">SOA的出现是׃互联|技术的出现Q将原来各自为阵?span lang="EN-US">EAI?jng)场标准化?span lang="EN-US">
在美国由于多q的应用pȝQ企业的业务程大多C非标准的形式被掩藏在各种各样的应用系l之中,比如CRMpȝQ?span lang="EN-US">ERPpȝQ?span lang="EN-US">HRpȝQ信用评估系l等{。所以实?span lang="EN-US">SOA架构的第一步是那些掩藏在个应用系l之中的业务功能模块切割开来,加以包装之后成ؓ(f)标准的服务构Ӟ然后q要分散在不同pȝ中的数据整合包装成ؓ(f)数据服务Q最后根据业务的需要同q?span lang="EN-US">BPEL分散的服务q接成ؓ(f)新的服务。所以美国实?span lang="EN-US">SOA的方法ؓ(f)Q?span lang="EN-US">
1 。对原有业务程的提取和包装成ؓ(f)服务构gQ?span lang="EN-US">SCAQ;
2 。对原有数据的整合包装成为数据服务(SDOQ;
3 。用BPEL实现新的程?span lang="EN-US">
q个做法的可行性基于一个重要前提:(x)原有的业务流E可以被切割包装Q代价问题)(j)Q原有的数据可以在一定程度上被标准化包装成ؓ(f)服务Q如果所有的pȝ都需要通过人工切割和包装则代h(hun)太大Q必d在一ơ切割多ơ复用的情况Q否则切割的环节无法产品化。由于美国企业的应用pȝ大量采用?jin)有限厂商的产品比?span lang="EN-US">SAPQ?span lang="EN-US">ORACLEQ?span lang="EN-US">SIEBLE{,一定程度的标准切割是存在的Q尤其是多年?span lang="EN-US">EAI实践Qؓ(f)切割的标准化打下?jin)基。尽如此,大量的基于h工服务的切割q是必须的,所以,印度人有饭吃。而这些切割的工作与中国Y件外包企业多半无兟?span lang="EN-US">
因此Q我们可以预见美国制造的SOA产品把h标准切割?qing)打包功能作为重要的卖点Q也是品的价值所在。市(jng)场决定品的特征Q就q么单的逻辑?span lang="EN-US">
中国?/span> SOA 如何实现呢?我们的预见是多半是把pȝ按照SOA提供的标准来Q主是把系l徏设成?/span> SOA 标准的系l,而不是切割和包装Q那些需要切割和包装的系l绝大多C赖于服务而不是品。作?gu)个判断基两个前提Q?/span>
1Q??/span> 原有的系l很;
2Q??/span> 那些已经存在的系l很是能够被标准化切割的;
因此Q在中国开?/span> SOA 产品最重要的特征是如何在一个标准的q_上(框架内)(j)构造企业所需要的所有标准服务,q且Ҏ(gu)理和发展(变化Q。中国市(jng)?/span> ( 客户 ) 面(f)的主要问题有如下几条Q?/span>
考察中国的市(jng)场我们可以作出如下的预言Q?/span>
1Q??/span> SOA 被L?jng)场接受成?f)标准的体pȝ构;
2Q??/span> 国L?a target="_blank">SOA产品在中国会(x)水土不服Q?/span>
3Q??/span> 原有pȝ主要依靠服务来切割Q或者推倒重来;
4Q??/span> 大量的新建系l将采用标准的小颗粒构g构造流E别的标准服务构gQ?/span>
5?。普元面向构件的中间件将成ؓ(f) SOA L中的中国L?/span>