<h:inputText id="modelId" value="#{ModelBean.modelId}" />
<h:commandButton type="submit" value="Submit" action="#{ModelBean.showModel}" />
public String showModel() {
if (modelId > 0) {
ModelService modelService = new ModelService();
BeanUtils.copyProperties(this, modelService.create(modelId));
setFeatures(modelService.getFeatures(modelId));
}
...
}
<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>
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"));
...
}
<process>
<subProcess path="page.xml" /> ---------- (1)
<subProcess path="model.xml" /> ---------- (2)
<service name="modelService" operation="getFeatures" /> ----- (3)
</process>
<process>
<service id="header" name="commonService" operation="getHeader" />
<service id="footer" name="commonService" operation="getFooter" />
<abstract id="contents" />
</process>
<process extends="page.xml">
<group id="contents">
<service name="modelService" operation="create" />
<abstract id="pageContents" />
</group>
</process>
<process extends="model.xml">
<service id="pageContents" name="modelService" operation="getFeatures" />
</process>
<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>
JBoss 宣布发布JBoss Transactions 4.2 和JBoss Rules 3.0 新版本?/p>
JBoss Transactions 是一Ƒּ源的分布式事务管理^収ͼ原来是属于Arjuna 的品。Arjuna Technologies 公司的事务引擎已?0q的历史Qƈ且已l被升到可以用Web服务事务?005QJBoss q通过收购Arjuna 而获得此Ҏ术?/p>
JBoss Rules 是JBoss的企业规则引擎品,前n是大安熟悉的Drools?005q?2月,JBoss的创始h兼总裁Marc Fleury在巴塞罗UD行的“JBoss 世界”的会议上发表的主题演讲中宣布收购Drools?从此QDrools 目以及该项目的主要负责人Mark Proctor 都加入了JBOSS?/p>
下蝲地址Q?a >http://jboss.org/jbossBlog/blog/mlittle/?permalink=JBoss_Transactions_4_2_Released.txt
JBoss周一Q?1/20Q于德国的一Z议中发表了新的企业服务ȝQenterprise service busQESBQ?.0版,补了该公司企业中介软gQJBoss Enterprise Middleware SuiteQJEMSQ范_q露其应用服务器更新版的核心技术?
JBoss母公司红帽(Red HatQ技术长Brian Stevens指出Q服务导向架构(services-oriented architectureQSOAQؓJBoss的主要框Ӟ其中Q隶属于JEMS一部䆾的ESB能够用来调解企业应用E序、商业服务、组件及中介软g?
所谓的企业服务ȝ是一新兴的整合技术,主要于企业应用Y仉扮演数据配送的角色Q整合商业应用YӞ目标为降低企业共享数据的成本?
JBoss产品理ȝPierre Fricke表示QESB是带来SOA架构的^台?
ESB所影响的JEMS技术诸如JBoss内容路径的业务规则引擎,以及用来传递讯息的JBossMQ QJBoss打算ESB延C务及工作程理JBoss jBPM产品Q合作伙伴可透过q结器、B2B|关器及SOA控制器扩充ESB?
ESB的功能涵盖一个可交换ESB子系l的q结架构Q对安全FTP及HTTP{讯息服务的支持Q以及连l数据格式的转换引擎Q亦支持扩展样式表{换语aQExtensible Stylesheet Language TransformationsQESLTQ及Smooks转换引擎?
JBoss表示Q目前ESB 4.0 RC版已可供下蝲Q最l版则预计在12月推出,技术支持版本计划在明年现n?
JBoss在该会议也透露C代应用服务器JBoss Application Server 5.0的核心技术,其组件包括符合JAX-RPC 1.1的JBoss Web Service、重新更Ҏ构以促进效能的JBoss Clustering、兼容于JMS 1.1的JBoss MessagingQ以及JBoss Seam 1.1、JBoss EJB3及Hibernate 3.2{?
JBoss Application Server 5.0试版将在今q?2月推出,最l版则计划在明年上半q出炉?/p>
C的业务应用程序很完全独立运行。它们需要彼此连接,以便创徏集成解决ҎQ从而ؓl织带来价倹{面向服务的体系l构(Service-Oriented ArchitectureQSOA)和事仉动的体系l构(Event-Driven ArchitectureQEDA)是处理复杂集成挑战的两个不同范例。组l如何选择更好的方法来满光求呢?实际上他们ƈ不必选择:企业服务ȝ(Enterprise Service BusQESB)允许同时实现 SOA ?EDA 概念?
引言
Z适应市场变化Q各个组l都們于将重点攑֜灉|性和响应能力上。IT 挑战实际上通常使用恰当的体pȝ构和技术来支持此业务远景。早期的zd是ؓ了将独立应用E序拆分为可调用的子例程Q但q程对象调用和消息传递处理的发展改变了这一炏V?/p>
而在最q,增加对组l中现有资的重?可反q来提高投资回报)和集成异cd用程序以形成一致业务解x案开始变得非常关键了。而这促进?SOA ?EDA 的广泛采用。这两个不同的设计范例均以最大化独立于应用程序的服务(可提?IT 适应能力和效?的重用ؓ目标。但构徏和部|大型集成解x案始l是一Ҏ较困隄d。而这正是 ESB 的用武之圎ͼ因ؓ它简化了d关键型应用程序的灉|而可靠的体系l构(SOA ?EDA)的实现?/p>
面向服务的体pȝ?/strong>
SOA 是一个体pȝ构概念,其中所有的功能或服务都使用描述语言加以定义Q且各自的接口均可通过|络q行发现。此cL口采用独立方式定义,不受服务实现所在的gq_、操作系l和采用的编E语a的媄响?/p>
SOA 的最重要优势之一是,它可以脱Y件开发中的孤立方?在此方式中,每个部门构徏自己的系l,而完全不考虑l织中的其他人已完成了哪些东?。这U“竖?(Silo)”方法将会导致低效且开销巨大的情况出玎ͼ可能会多ơ开发、部|和l护相同的功能。SOA Z在整个组l范围内׃n的服务组合,q提供了对现有资产的有效重用和集成,如图 1 中所C?
?1:“竖井”方法与 SOA Ҏ的对?/p>
SOA Z方便的请?应答机制Q如?2 中所C。服务用者将通过|络调用服务提供者,且必ȝ待,直到提供者一端的操作完成?/p>
?2:SOA 中的h/应答机制
?1 ?SOA 解决Ҏ的基本特征进行了ȝ:
功能 |
描述 |
松散耦合的交?/p> |
服务的调用独立于其技术和位置?/p> |
一对一通信 |
一个特定服务一ơ由一个用戯用。通信是双向的?/p> |
Z用户q行触发 |
控制由客户?服务使用?发v?/p> |
同步 |
应答以同步方式发回l用者?/p> |
?1:基本 SOA 特征
事g驱动的体pȝ?/strong>
?2003 q_Gartner引入了一个新术语Q用以描q基于事件的设计范例:事g驱动的体pȝ?(EDA)。EDA 定义了一U用于进行设计和实现应用E序和系l的ҎQ其中的事g在各个分解的软glg和服务间q行传递。EDA q不会替?SOAQ而只是对 SOA 形成补充。虽?SOA 通常更适合h/响应交换环境Q但 EDA 引入了一些长旉q行的异步进E功能。而且QEDA 节点可发布事Ӟ且ƈ不依赖于所发布的服务的可用性。它真正地实C同其他节点的分离。EDA 有时也称为“事仉动的 SOA”?/p>
EDA 使用消息传递来在两个或多个应用E序q程间进行通信。此c通信是由“事件”发L。触发器通常与某U业务情况对应。该事g的所有订阅者将随后得到通知Q从而激z,如图 3 中所C?
?3. 事g驱动的体pȝ构中的发?订阅机制
?2 ?EDA 的基本特征进行了ȝ:
功能 | 描述 |
分离的交?/td> | 事g发布者ƈ不会意识C件订阅者的存在?/td> |
多对多通信 | 采用发布/订阅消息传递,一个特定事件可以媄响多个订阅者?/td> |
Z事g的触发器 | 控制由接收者确?Z发布的事??/td> |
异步 | 通过事g消息传递支持异步操作?/td> |
?2:基本 EDA 特征
企业服务ȝ
定义
企业服务ȝ(Enterprise Service BusQESB)事仉动的Ҏ和面向服务的Ҏl合使用Q以化业务单元的集成Q从而在异类q_和环境间建立联系。ESB 充当允许不同应用E序q程之间q行通信的中间层。部|到企业服务ȝ的服务可以由使用者或事g触发。它同时支持同步方式和异步方式,可促q一个或多个参与者之间的交互(一对一和多对多通信)。因?ESB 可提?SOA ?EDA 范例的所有功能?/p>
企业服务ȝ是一U体pȝ构模式,可以采用许多不同的品在l织内实玎ͼq组装v来作合ȝ。现在有来多的供应商开始提供完整的产品来满企业集成需求。例?IBM WebSphere] Enterprise Service Bus提供了集成ȝ功能Q可以有效地q接应用E序(利用 Web 服务?J2EE {标??/p>
ESB 服务
目前q没有定?ESB 的正式标准,但通常都认?ESB 臛_必须提供传输、事?和中?服务Q以帮助集成大型异类应用E序?/p>
传输服务
必须保通过企业ȝ互连的业务流E间的消息正交付。传输还包括Z内容的\由功能。这意味着可以消息定向到不同的目的地。作ZQ务关键型环境的一部分Q这些服务采用事务处理方式,得到了相应的安全保证Qƈ会对其进行监视?/p>
事g服务
提供事g、触发和分发功能。这些功能与事g处理概念相关Q事件处理是一U用于分析和控制事g驱动的体pȝ?(EDA) 中相互关联事件组成的复杂pd。事仉动的范例q不是新概念。不q,它们促进了行业的发展Q代表着复杂事g处理 (Complex Event Processing) 的核心概c?/p>
中介服务
用于满两个目的。首先,中介可确保提供必要协议,以满集成异cȝl的需求。由于两个不同的服务q不一定用相同的传输协议Q而中介服务可负责从一个协议到另一个协议的转换Q因此可以进行此c通信。协议{换对于业务事务的所有参与服务是透明的?/p>
?4:协议中介——由 ESB q行协议转换
其次Q中介提供了转换M消息内容的可能性。这是业务集成的关键服务。它可确保Q何进E都能理解通过ȝ传输的数据。而且Q中介允许对内容q行扩展Q以使用附加信息丰富消息内容。内容{换由ȝ负责q行理:此过E对于Q何参与服务都是透明的?/p>
?5:内容中介——消息内容由 ESB q行转换和扩?/p>
让我们D个例子来说明内容中介的好处。假定有一个名?Yummy Inc. 的公司提供在U订服务。ؓ了对其向客户提供的菜单进行计划,他们需要验证其供应商提供的食品的可用性和h。ؓ了获得此信息而发送的消息的典型结构包?产品标识、数量和目标配送日期?/p>
?6:可用性消息的l构
当然QYummy Inc. 及其供应商ƈ未采用相同的方式来表C些信息。例如,两个pȝ上的日期格式׃相同。而且Q供应商需要用配送位|信息,因ؓ Yummy Inc. q不是其唯一的客戗ESB 中介服务可以所传输消息的信息进行{换和扩展Q以便目标服务接收到其所需的所有信息,如图 7 中所C?
?7:ESB 中介的内容{换和扩展
通过利用之前定义的关键技术服务,ESB 可提供灵zȝq接基础设施Q用于集成松散耦合的应用程序。它同时支持 SOA ?EDA 范例?/p>
?8:使用企业服务ȝq接各个服务
ESB 的好?/strong>
通过利用其内部服务,ESB 解决Ҏ可带来各U好处。就本质而言Q它化了q接各种相异应用E序的Q务,从而最l提高了业务的灵zL,q提供了以下功能:
Z标准的连?/strong>
作ؓ很多异类应用E序间的集成中枢QESB 必须提供很多不同的集成技术,q对大量供选择的标准技术加以利用?/p>
消息传递集成通常支持 Java?Message Service (JMS) APIQ而企业信息系l的q接则是?J2EE Connector Architecture (JCA) 提供的。ؓ了确?Web 服务互操作性,ESB 支持 JAX-RPC ~程模型。不同的 ESB lg间的集成可以通过 Java Business Integration (JBI) 规范q行标准化?/p>
渗透性集?/strong>
ESB h渗透性本质,因ؓ它可以跨不同的部门、业务单元甚至业务合作伙伴进行应用程序集成。而且Q它的核心体pȝ构原则还可以促进构徏于异cd发环境上的应用程序之间的通信。例如,ESB 解决Ҏ可以在不同的~程语言(J2EE、C++ ?.Net)之间起到桥梁作用?/p>
可靠集成
ESB 体系l构模式可提供系l安全性、可伸羃性或可用性。企业服务ȝ使用 SOA ?EDAQ可同时提供同步和异步功能。传输服务可保可靠交付和事务完整性。因此,ESB 的每个特征都对其E_性进行了增强Q可可能减集成或联合解决Ҏp|的风险?/p>
l束?/strong>
企业服务ȝ是一U体pȝ构模式,可通过传输、事件和中介服务促进和简化业务集成。它可连接各个异c节点ƈ作ؓ中介传递其间的所有通信和交互,q些节点可分散在面向服务的体pȝ?同步一对一Ҏ)和事仉动的体系l构(异步多对多方?中。ESB 是目前处理集成挑战的最有效ҎQ是可提供最大业务灵zL和不同应用E序间的高效q接技术解x案?/p>
注意q一节标以“面向服务与面向对象”,有别于?i>比较面向服务与面向对象”?/span> 区别在于所的事实:在这两个思想zֈ之间不必是竞争关pR?/span>
事实上,面向对象~程被普遍用于有
Web
服务内构建封装应用逻辑。然而,面向对象~程Ҏ论在基本上与面向服务有何Q这值得探究。对它们差异的理解会有助于你的工作?/span>
下面列出q些设计Ҏ斚w的比较。(然而面向服务是Z服务的设计,面向对象是围l对象的创徏为核心。ؓ了避免服务和对象间的比较混ؕQ用了“处理逻辑单元”这一术语。)
l
面向服务处理逻辑Q服务)单元间的松散耦合。尽面向对象支持创建复用性、松耦合的编E例E,它们多数是以预先定义的类依赖为基Q结果导致了更多处理逻辑Q对象)的紧密绑定?/span>
l
面向服务鼓励不优雅的接口Q服务描qͼ以便于每个通信Q消息)包含可能多的信息以便于工作完成指定d。面向对象编E充分支持精的接口Q?/span>
API
Q以侉K信Q?/span>
RPC
或本?/span>
API
调用Q单元能够执行不同规模的d?/span>
l
面向服务期待显著改变处理逻辑单元Q服务)的作用域。面向对象处理逻辑Q?/span>
objects
Q趋于其作用域更小且更有针Ҏ?/span>
l
面向服务促进zd未知的处理逻辑单元Q服务)的创建,从而驱动通信单元Q消息)的智能化。面向对象鼓励处理逻辑数据的绑定,产生了高度智能化的单元(对象Q?/span>
l
面向服务偏爱处理逻辑单元
Q服务)被设计成可能无状态。面向对象促q数据与逻辑的绑定,D更具状态的单元Q对象)。(然而,最q基于构件的设计Ҏ偏离了这一势。)
l
面向服务支持l合松散耦合的处理逻辑单元Q服务)。面向对象支持组合但也鼓励处理逻辑单元Q?/span>
objects
Q间的承,q会D紧耦合?/span>
你或许已l注意到我们避免提及特定的面向对象原则,比如装、承及聚合。因为我们还不会充分描述面向服务的原则,我们在这一层次上给Z别的比较范例。以后将
详细解释个别的面向服务原则,然后
再l这一讨论?/span>
要点ȝ
在前一节中Q我们提到最q的分布式互联网架构变化已如何成为?/span> Web 服务。这一主题值得详细说明Q因为它已经是(q期l是Q?/span> SOA 周围的׃源?/span>
首先Q传l架构内使用
Web
服务是完全合理的。由于许多编E语a都支持对
Web
服务的开发,他们可轻易地其嵌入老的应用设计。ƈ且,对于那些不支?/span>
Web
服务定制开发的遗留环境Q通常也可用适配器的Ҏ来解冟?/span>
注意
管我们集中于分布式互联|架构,但ƈ没有限制两层客户
-
服务器的应用使用
Web
服务?/span>
Web
服务作ؓ构g包装?/span>
Web
服务在这个语境中的主要角色已引进了一个包含包装器服务的整合层Q促成经?/span>
SOA
P
兼容的集成通道的同步通信Q?/span>
?/span>
4.7
Q。实际上Q?/span>
SOA
P
规范初始发布和第一?/span>
SOA
P
服务器都被特别设计用来复制用消息的
RPC
风格的通信?/span>
q些集成通道主要在集成结构中Q被用以促进与其他应用或外部合作伙伴的通信。也被用于促成与其他Q更多的面向服务Q解x案通信Q还可利用第三方工具提供?/span>
Web
服务。不他们在传统架构中的使用或目的,关键是要澄清靠这U方式在分布式互联网架构中纳?/span>
Web
服务不具备真正的
SOA
资格。这只是使用
Web
服务的分布式互联|架构?/span>
q是反映构件接口和?/span>
Web
服务建立点对点连接,
SOA
提供了对于不同通讯模型的强健支持(Z同步和异步的交换Q。另外,?/span>
SOA
内的
Web
服务受制于特定的设计需求,象由面向服务原则提供的那些。这些和其他的特征都支持对和谐的松散耦合的追求。一旦实玎ͼ单个服务不再限于点对炚w信Q它能够适应M的现在和未来的请求者?/span>
SOA
内部?/span>
Web
服务
然?/span>
SOA
在大和品质斚w会有所不同Q?/span>
SOA
与其他架构在
Web
服务的用方面有切实不同的特征。本书主要专注于探烦q些特征。目前已l充分阐明:基本上,
SOA
构徏于一l?/span>
Web
服务Q它们被设计用于一个或多个电子商务程的集体自动化Q或者参与自动化的)Q?/span>
SOA
促进这些服务组l成抽象企业自动化逻辑特定部分的特定层?/span>
同样通过跨企业的标准
SOA
Q出C天然的协同性,越了专有的应用q_。这考虑到先前不同的环境l成Q以支持新的和进化的业务自动化过E?/span>
q似乎有点自相矛盾,如果 SOA 可被视作分布式互联网架构的一UŞ式,同时我们初期建立早先cd的分布式架构也可被设计ؓ SOA 。尽如此,且尽现在的分布式环境可能已l深深地受到了面向服务原则的影响Q?/span> SOA q样的变化仍旧是|见的。故而在此所提供的比较是?i>传统?/i>分布式互联网架构作ؓ其最常被设计的风格出现?/span>
分布式互联网架构?/span>
Z对付两层客户服务器架构相关的成本与限刉题,构徏Z构g应用的概忉|Z。多层客?/span>
-
服务器架构Q出水面,单独的客户E序分解成构件设计,成ؓW合面向对象的不同扩展?/span>
在构件中不同的分布式应用逻辑Q一些仍ȝ在客LQ其他在服务器上Q,减少了大量逻辑都集中部|在服务器端的o人头痛的问题。服务器端构Ӟ现在集中于应用服务器Q从而可׃n数据库连接管理池Q减L据库q发讉K的负担(
?/span>
4
Q。一个单q接可L满多用戯求?/span>
?/span>
4.
典型的多层客?/span>
-
服务器架构?/span>
获取q些效益的代h复杂性的增加Qƈ且最l{换ؓ从部|问题到开发和理q程的费用和努力。构建多样化处理能力的构Ӟq发h比直接ؓ单个用户开发一个可执行E序更困难,而且问题多多?/span>
另外Q替代客?/span>
-
服务器数据库q接的是客户
-
服务器远E程序调用(
RPC
Q连接。象
CORBA
?/span>
DCOM
q样?/span>
RPC
技术,准许客户工作站与服务器构仉q行q程通信。出CcM客户
-
服务器架构的问题Q包括资源及怹q接。增加这个新的维护是׃引入了中间g层。比如,在大型环境中对于应用服务器及事务监控需要特别关注?/span>
随着万维|在
90
q代中后期成Z个计技术的可用媒介Q多层客?/span>
-
服务器环境开始组成互联网技术。最重要的成是软g构g被浏览器所替代。这个变化不仅从Ҏ上改变(且限Ӟ了用L面设计,实际上还?/span>
100%
的应用逻辑Ud了服务器?/span>
Q?/span>
?/span>
5
Q?/span>
?/span>
5.
典型的分布式互联|架?/span>
分布式互联网架构也引入了一个新的物理层Q?/span>
Web
服务器。这D
HTTP
替代了专有的
RPC
协议而用于工作站与服务器间的通信?/span>
RPC
的角色被限制C成远E?/span>
Web
与应用服务器间的通信?/span>
?/span>
90
q代后期
2000
q中期,分布式互联网架构对于定制开发的企业解决Ҏ而言Q代表了事实上的计算q_。基于构件的日常~程技术及日益复杂的中间gQ最l减了一些整体复杂性?/span>
那么Q这个熟悉而又怼的架构该如何?/span>
SOA
相比较呢Q且看分布式互联|架构与
SOA
特征部分?/span>
注意
管多层客户
-
服务器在其所有权内是一个独特的架构Q我们不提供它与
SOA
之间的比较。大多数在客?/span>
-
服务器及分布式互联网架构的比较中升的问题,掩盖了将在多层客?/span>
-
服务器与
SOA
的比较中讨论的问题?/span>
应用逻辑
除了一些罕见的应用以专有扩展的方式嵌入到浏览器中以外,分布式互联网应用其所有应用逻辑攑֜了服务器端。甚臛_L脚本惌执行在网上的一个事件响应,都要?/span>
Web
服务器基于初始的
HTTP
h来下载。没有客户工作站上保存的逻辑Q整个解x案都是集中式的?/span>
从而强调了Q?/span>
从一个物理的角度来看Q面向服务架构与分布式互联网架构非常怼。提供者逻辑ȝ于服务器端而被分割成单独的单元。其中差异由刚刚所列三个主要设计原则所军_?/span>
传统的分布式应用包含了驻留于一个或多个应用服务器上的一pd的构件。构件设计ؓ不同_度的功能,依赖于所执行的Q务,以及它们被其他Q务或应用的复用范围。驻留于相同服务器的构g通过专有
API
通信Q按照它们暴露的公共接口来调用?/span>
RPC
协议被用于实现跨服务器边界的通信。这有可能通过使用代表q程构g的本C理存Ҏ实现Q?/span>
?/span>
6
Q?/span>
?/span>
6
构g通信依赖于代理存?/span>
在设计时Q预期的交互构g与其他一赯虑
---
如此强烈以致实际对其他物理构件的引用可嵌入到E序代码内。这个设计时水^的依赖是紧耦合的Ş式。这LE许处理相对于试囑֜q行时定位所需构g的浪费而言是有效的。然而,嵌入式耦合Dl定构g|络Q一旦实玎ͼ不易更改?/span>
当代
SOA
依然使用q依赖于构g。然而,整个建模Ҏ现在会考虑创徏装一些或所有构件的服务。这些服务根据面向服务原则而设计,q且{略性地定位及暴露特定的功能集。同时这个功能可由构件提供,也可源自遗留pȝ及其他资源,象来自其它套装Y件品的适配器接口,或者甚x数据库?/span>
在服务内包装功能的目标是l由一个开攄、标准化的接口暴露功?/span>
---
而不用关心用于实现底层逻辑的技术。标准化的接口支持置?/span>
SOA
核心的开N信框架。而且Q?/span>
Web
服务建立了松散耦合的环境,其中也运行着相对设计的分布式应用。如果设计得当,松散耦合的服务支持组合模型,允许单个的服务参与集合的设计。这引入了持l的复用与扩展机会?/span>
有关分布式应用逻辑的设计与行ؓ的另一个重要{变在于服务如何交换信息。当传统构g提供ҎӞ一旦被Ȁz,发送与接受参数数据Q?/span>
Web
服务通过
SOA
P
消息通信。即?/span>
SOA
P
支持
RPC
风格的消息结构,大多?i>面向服务?/span>
Web
服务设计却依赖于文档风格的消息。(q一重要差别在后面探I。)
消息也是l构化的q尽可能是自的。通过使用
SOA
P
报头Q消息内容可以伴随阒宽泛的元信息、处理指g及策略规则。与Ua构g世界内的数据交换相比较,
SOA
所用的通讯框架更加复杂、更加庞大,q且更易D数的个别传输?/span>
最后,管也普遍强调复用传l的分布式设计方法,
SOA
可通过促进解决Ҏ未知服务的创建鼓励复用以及深层次的跨应用协同?/span>
应用处理
不管什么^台、构仉代表了最大部分的应用逻辑q因此负责大多数的处理。然而,因ؓ用于构g间通信的技术不同于完成服务间通信的技术,处理需求也是如此?/span>
分布式互联网架构促进专有通信协议的用,象用于远E数据交换的
DCOM
和厂商实现的
CORBA
。当q些技术遭遇历史性挑战时Q它们相Ҏ有效可靠的,特别是一旦有dq接时。它们能够支持有状态和无状态构件的创徏Q主要媄响同步数据交换(一些^台支持异步通信Q但q未普遍使用Q?/span>
另一斚wQ?/span>
SOA
依赖Z消息的通信。包括负载有
XML
文档?/span>
SOA
P
消息序列化、传输及d列化。处理步骤会包括关pL据{换成
XML
兼容l构?/span>
XML
文档预校验以及随后的传输、以及对所接收文档q行解析和抽取。尽已有所q步Q譬如企业解析器及硬件的持箋加速,大部分还是抱?/span>
SOA
P
?/span>
RPC
通信明显要慢一些?/span>
在面向服务应用环境中Q因?/span>
SOA
P
服务器的|络能够有效代替
RPC
风格的通信通道Q导致系l开销成ؓ一个重要的设计问题。文档与消息建模规约及校验逻辑的布|策略是重要因素QŞ成了面向服务架构的传输层?/span>
q个通讯框架促进了自L务的创徏Q支持宽泛的消息交换模式。尽完全支持同步通信Q但q是鼓励异步模式Q因为它们提供了由通信最化而带来的q一步优化的Z。深入支持无状态服务是不同语境的管理可采取的措施,包括使用
WS-*
规范Q如
WS-
协调?/span>
WS-BPEL
Q还有定制解x案?/span>
技?/span>
分布式互联网架构背后的技术在q去几年内经历了几个阶段。初始架构包含有构g、服务器端脚本以及原生的
Web
技术,比如
HTML
?/span>
HTTP
。中间g斚w的进步,允许增加处理能力及事务控制?/span>
XML
的出现引入了复杂的数据表达,实际上提供了l由互联|协议传输的东西。后?/span>
Web
服务的可用性允许分布式互联|应用跨专有^台的边界?/span>
因ؓ许多当前的分布式应用使用?/span>
XML
?/span>
Web
服务Q有可能q些解决Ҏ背后的技术与那些Z
SOA
的没有太大不同。虽然一个明昄区别在于当代
SOA
有可能构徏?/span>
XML
数据表达?/span>
Web
服务技术^台技术之上。除了互联网核心技术集和构件的使用Q没有被传统的互联网应用所l治的技术。因此,
XML
?/span>
Web
服务对于分布式互联网架构而言是可选的Q但对于当代
SOA
不是?/span>
安全
当应用逻辑散布于多个物理边界时Q实现象鉴权与授权这L基本安全措施变得更加困难?/span>
在两层客?/span>
-
服务器环境中Q一个独有的服务器端q接可轻易实现用戯证及企业数据的传输安全。然而,当独立的q接被移除时Q而且要跨不同的物理层传播时Q就需要新的安全方法。要保信息的安全运输及用户凭证的识别、同时保留原始的安全语境Q可用象委托和假冒这样传l的安全架构合成Ҏ。加密也被加到其他广泛而开攄
HTTP
协议斚wQ可?/span>
Web
服务器之外传送时受到保护?/span>
SOA
通过引入对安全如何组合以及对应用的大规模改变Q从而远Mq个模型。由于严重依?/span>
WS-
安全框架所建立的扩展和概念Q在
SOA
中所用的安全模型在通讯层面上强调安全逻辑的安|?/span>
SOA
P
消息提供的报送区块中可存入安全逻辑。那P无论消息在何方,安全也就随之而至。这个方法需要个体自d服务间的松散耦合Q同时一个服务可完全l持在无状态的范围?/span>
理
l护Z构g的应用包括跟t单个构件实例、本地及q程通信问题Q监控服务器资源需求,当然Q还有标准化的数据库理d。分布式互联|架构进一步引入了
Web
服务器,同时解决Ҏ执行时还需要关注额外的物理环境。因为客?/span>
---
不管本地的还是外部的l织
---
使用
HTTP
q接到这些解x案,
Web
服务器就成ؓ正式的第一接触炏V因此它必须设计成可扩展?/span>
---
q一需求已D
Web
服务器机器资源池的创建?/span>
企业U?/span>
SOA
典型地需要一个额外的q行时管理。通讯框架带来的问题(特别是工作在异步交换模式Ӟ会比Z
RPC
的数据交换的问题更不易发现。这是因为关于消息如何交换,存在太多的变化?/span>
RPC
通信一般需要一个来自初始构件的响应Q表明成功还是失败。遇C个失败条Ӟ׃抛出一个异常。通讯框架的异常处理可能更复杂而更不健壮。尽?/span>
WS-*
扩展被定位于更好地处理这些情形,仍需努力保持高度理?/span>
其他l护dQ象资源理Q类g构g理Q,同样需要。然而,Z更好Cq复用性及可组合性,对于企业构徏大量?/span>
Web
服务而言Q管理基设施的一个很有用部分是私有注册?/span>
UDDI
是一个标准化的技术,用于标准化地注册接口Q能够手工或E序化地讉K发现服务描述?/span>
我们现在实际地蟩回时间u看一看过L构与
SOA
的差别。这是一Ҏ的研究Q?/span>
我们能够看出
SOA
许多当代特征的v源?/span>
自打有计机处理的自动化解决ҎҎP技术架构就已存在。然而,在较老的环境中,解决Ҏ直接建构于抽象的d上,q规定其架构很少被执行?/span>
随着多层应用的崛P应用交付的变异开始剧增?/span>
IT
部门开始认识到需要定义标准化的基U应用,作ؓ其他应用的模ѝ这个定义自然是抽象的,但明地解释了所有解x案以q个模板为基Q包括其技术、边界、规则、限制及设计特征。这׃生了应用架构?/span>
应用架构
应用架构对于应用开发团队的意义Q相当于蓝图对于建筑工团队的意义。不同的l织印证不同水^的应用架构。一些保持了高水qI提供技术蓝囄抽象的物理及逻辑表达。另一些则包括更多的细节,cM通用数据模型Q通信程图,应用范围的安全需求,以及基础设施斚w?/span>
对于一个组l而言有几个不同的应用架构的情冉|不希奇的。一个架构文档典型地代表了不同的解决Ҏ环境。例如,一个同时拥?/span>
.NET
?/span>
J2EE
解决Ҏ的组l很有可能针Ҏ一U有分别的应用架构规范?/span>
M应用U架构的关键部分在于它既要直接反映解x案的需求,同样又要考虑长期的、策略性的
IT
目标。正׃q个~故Q组l内的应用架构会伴以企业架构Q?/span>q与其中居统d位的一个保持一致?/span>
企业架构
在较大的
IT
环境Q关键在于需要控制ƈ指导
IT
基础设施。当有很多不同的应用架构共同存在的时候,且有时甚臌整合Q底层的Lq_变会复杂而繁重。因此,通常会创Z个控制规范,Z业内存在的所有异质Ş态的提供高层概述Q同时给出支持基设施的定义?/span>
l箋我们前一个类推,对于l织而言Q企业架构规范相当于一个城市的城市规划。因此,城市规划与徏{蓝N的关p,可与企业与应用架构规范间的关pȝcL?/span>
典型圎ͼ企业架构的变化直接媄响应用架构,q是Z么架构规范通常由同一lh来维护。而且Q企业架构经常包含组l长期技术和环境发展规划。例如,阶段性的目标有可能是要立于q个规范来逐步淘汰q时的技术^台?/span>
最后,也可能会定义技术与{略背后的企业安全度量。然而,q经怼被作为单独的安全架构规范?/span>
面向服务架构
单而言Q面向服务架构跨了企业与应用架构两个领域。当被用于跨多解x案的环境Ӟ
SOA
所提供的潜在效益才能真正释放。这个是对可复用和可协同服务的投资,q且充分利用Z厂商中立的通信q_。这q不意味着企业必须变成面向服务?/span>
SOA
所引入的特性及特征大部分都属于q一范畴?/span>
注意术语?/span>
SOA
”ƈ不意味着一个特D的架构范围?/span>
SOA
可以是指一个应用架构,或是用于跨企业的技术架构的标准化方法。因?/span>
SOA
天生的可l合性(意味着单个的应用层架构可由不同的扩展及技术组成)Q完全适用于超?/span>
SOA
的组l?/span>
h意,如同前一章所解释的,
Web
服务q_提供了众多实?/span>
SOA
形式中的一个。它是本书专门研I的一U方法,但是q存在其他方法,比如׃l的分布式^台所提供的这些。术语方面有一点很重要Q就是在后面章节中及整本书中所用的术语?/span>
SOA
”是指在W?/span>
3?/span>
所建立的当?/span>
SOA
模型Q基?/span>
Web
服务与面向服务原则)?/span>
几乎在Q何环境中Q只要有一DY件从另一个请求或接收信息Q都能够被称为“客?/span>
-
服务器。”几乎每一个不同的应用架构都曾存在Q包?/span>
SOA
Q一U客?/span>
-
服务器的交互元素。然而,行业术语“客?/span>
-
服务器架构”通常是指Ҏ的前一代环境,期间客户端与服务器扮演了特定的角Ԍq有清晰的实现特征?/span>
客户
-
服务器架构简?/span>
初期庞大的主机授予组l严格的计算方式Q通常被视作是客户
-
服务器架构稚形。这些环境,其中庞大的主机后端伺服瘦客户端,被看作单层客?/span>
-
服务器架构(
?/span>
2
Q?/span>
?/span>
Lpȝ天然支持同步及异步通信。后一U方法主要用于让服务器连l不断地接收来自l端的字W,以响应个别的击键事g。只在某U条件下服务器才会响应?/span>
虽然它仍有残留痕q,但是当两层客?/span>
-
服务器的变化设计?/span>
80
q代后期出现ӞL作ؓ最初的l治计算q_开始衰退?/span>
q个新方法引入了委派逻辑、以及处理职责下发到单个工作站的概念Q导致了胖客L诞生。受囑Ş用户界面Q?/span>
GUI
Q创新的q一步支持,两层客户
-
服务器被认ؓ是前q了一大步Qƈ?/span>
90
q早期持l统M
IT
界数q之久?/span>
q个架构的通常配置包含多个胖客LQ每一个都有自己到中心数据库服务器q接。客L软g执行大量处理Q包括所有的展现相关及多数的数据讉K逻辑Q?/span>
?/span>
3
Q。一个或多个服务器通过累积可扩展的关系型数据库理pȝQ促q了q些客户端?/span>
?/span>
3.
典型的两层客?/span>
-
服务器架?/span>
让我们通过单独地和它们与
SOA
的相应部分作比较两种方式Q来看一看两层客?/span>
-
服务器架构的主要特征?/span>
应用逻辑
客户
-
服务器环境将大多数应用逻辑攑ֈ客户端Y件中。这D庞大的程序连同后端资源来一h控制用户体验。分布式业务规则是一个例外。一个流行趋势是嵌入的和维护的业务规则与数据关联,攑օ数据库的存储q程与触发器之内。这略微抽象了一l来自客L的业务逻辑Qƈ化了数据讉K~程。尽如此,客户端还是承担着所有的展示d?/span>
当代面向服务解决Ҏ中的展现层会有所不同。Q何Y件片D若有能力依照所需的服务契U进?/span>
SOA
P
消息交换Q都可归为服务请求者。同旉常也期望请求者能提供服务Q展现层的设计完全开攑ƈ对应特定的解x案需求?/span>
在服务器环境内,存在关于应用逻辑如何ȝ与分布的选择权。这些选择权不排除数据库触发器和存储过E。同Ӟ面向服务设计的原则开始v作用Q通常指导划分自治处理逻辑的单元。这促进了特定设计品质,比如服务无状态化及协同性,q有可组合性及复用性?/span>
另外Q常有这些处理逻辑单元?/span>
SOA
内不属于M解决Ҏ的情形。这也支持了促进复用以及跨越应用边界的松散耦合q一l极目标?/span>
应用处理
因ؓ大部分客?/span>
-
服务器应用逻辑ȝ于客LQ客L工作站负责了大量的处理?/span>
80/20
比率常被作ؓ一个经验法则,按此法则数据库服务器承担?/span>
20%
的工作量。尽如此,数据q是常常成ؓq些环境中的性能瓉?/span>
有大用户量的两层客户
-
服务器解x案,通常需要每一客户建立其自w的数据库连接。通信可预期是异步的,而且q些q接是永久的Q意味着它们需要通过用户dq保持活动直臛_退出应用)。专有数据库q接是昂늚Qƈ且资源需求经常压垮数据库服务器,l所有用户以可观的反应时间?/span>
另外Q假定客戯分配以主要的处理职责Q他们常要求重要的资源。客L执行完全是有状态的Qƈ要消耗大量的固定
PC
内存。用户工作站因此l常需要专门运行客LE序Q以便所有可用资源能够提供给应用?/span>
SOA
中的处理是高度分布式的,每一服务都有一个清晰的功能边界和相关的资源需求。在面向服务架构建模技术中Q对于如何能够定位及部v服务你有很多的选择?/span>
企业解决Ҏ包含多个服务器时Q每一个都装有
Web
服务q支持中间g。因此,对于
SOA
而言没有固定的比率。服务可Ҏ需要分布,而且在决定物理部|配|时Q性能需求是要考虑的因素之一?/span>
服务与请求者间的通信可以是同步的或是异步的。这一灉|性允许进一步改q处理,特别是用异步的消息模式时。另外,通过在消息中攑օ更多的智能,可获得消息层面的语境理选择。这促进了无状态的及自ȝ服务本性,q进一步经历减对状态信息缓存的需要?/span>
技?/span>
客户
-
服务器应用的出现促进了第四代
4GL
~程语言的用,比如
Visual Basic
?/span>
PowerBuilder
。这些开发环境充分利用了
Windows
操作pȝ所提供的能力,来创建更观丰富、更具交互性的用户界面。尽如此,传统的第三代语言Q比?/span>
C++
Q仍在用,特别是对于有更严格的性能需求的解决Ҏ。在后端Q主的数据库厂商,?/span>
Oracle
?/span>
Informix
?/span>
IBM
?/span>
Sybase
与微软,提供了强健的关系型数据库理pȝQ能够管理多q接Q同时提供了灉|的数据存储及数据理Ҏ?/span>
SOA
所用的技术集实际上ƈ不象它所延展的那么多。旧版本的程序语a的更新版本,?/span>
Visual Basic
Q依旧能够用于创?/span>
Web
服务Q且依旧可以使用传统数据库。尽如此,
SOA
的技术版囑ַl变得日渐不同。除?/span>
Web
技术的标准集(
HTML
?/span>
CSS
?/span>
HTTP
{等Q,当代
SOA
一q带来了建立
XML
数据表达架构的绝寚w求,q有
SOA
P
通讯框架Q以及服务架构所包含的永q扩展的
Web
服务q_?/span>
安全
除了数据的存储与理以及嵌入存储q程和触发器中的业务规则Q安全是l常在客?/span>
-
服务器架构的服务器层面集中处理的另一个部分。数据库十分复杂Q以管理用户帐户及用户l长Qƈ其分配到物理数据模型的个别部分?/span>
安全也能够客L序中控制Q特别是当它与特定应用逻辑执行的业务规则相兌Ӟ譬如挑选用户对部分用户界面q行限制讉KQ。另外,与操作系l的安全协作可实现单点dQ此时应用直接承操作系l的d账户信息?/span>
管有h夸耀
SOA
的优势,许多架构师却慕客户
-
服务器的安全性。企业数据经由单炚w权而受C护,建立了客L与服务器间的单一q接。在
SOA
的分布世界中Q这是不可能的。安全变成一个重要而复杂的问题Q与必需的安全措施程度直接相兟뀂牵扯到许多典型技术,大多数包含在
WS-
安全框架?/span>
?/span>
理
客户
-
服务器时代终l的一个重要原因在于相兛_发的大量l护成本的增加,以及跨工作站应用逻辑的维护。因为每一个客戯载有应用代码Q每一ơ应用更新都要对所有的工作站重新分发Y件。在较大型的环境中,q造成了高度繁重的理程?/span>
l护问题跨越了用L和服务器端。客户工作站受特定环境问题的支配Q因Z同的工作站会安装不同的Y件程序,或者可能购C同的g厂商。更有甚者,q增加了Ҏ务器端数据库的要求,特别是当客户
-
服务器应用拓展到更大的用户基时?/span>
因ؓ面向服务的解x案会有不同的h者,它们q要受到来自客户端维护的挑战。同时其分布式后端要适应应用及数据库服务器的扩展性,会引入新的管理需求。例如,一?/span> SOA 发展为服务复用ƈ成ؓ多服务组合的一部分Q服务器资源与服务接口的理会需要强大的理工具Q包括私用注册的使用?/span>
在第
3?/span>
中我们徏立了不止一?/span>
SOA
定义。也有不止一个掌控定义面向服务背后原则的标准体。同P对于面向服务的组成,也有许多源自公开?/span>
IT
l织、厂商及咨询机构观点?/span>
据称面向服务的根源在于Y件工E理论所谓的“关注点分离”。这一理论Zq样的观念:一个大的问题分解ؓ一pd单个xҎ有益的。这使得逻辑需要解决的问题分解成更的、相关片D늚集合。每一D逻辑处理一个特定的x炏V?/span>
q个理论已经被不同的开发^C不同的方式实现。例如,面向对象的编E与Zlg的编E方法,通过使用对象、类和组件而实Cx点分R?/span>
面向服务能够被视作以截然不同的方式来实现x点分R面向服务原则提供了一个支持此理论的方法,同时实现了一U基本范式,在此基础上可构徏诸多当代 SOA 特征。实际上Q如果你再次研究q些特征Q将会注意到CQ直接或间接Q与x点分ȝ论有联系?/span>
如前所qͼ没有官方的面向服务原则。然而,却有一些最怸面向服务兌的原则。现这些原则罗列如下,本节做q一步描q?/span>
l
服务可复?/span>
不管是否存在x复用的机会,服务被设计ؓ支持潜在可复用?/span>
l
服务׃n一个正式契U?/span>
Z与服务交互,只需要共享描q每个服务信息交换术语定义的正式契约?/span>
l
服务是松散耦合?/span>
服务被设计ؓ无需紧密的、跨服务的依赖而交互?/span>
l
服务是底层逻辑的抽?/span>
只有l由服务契约所暴露的部分服务对于外部世界是可见的。契U之外所表达的底层逻辑是不可见的,且与服务h者无兟?/span>
l
服务是可l合?/span>
服务可能l合其他服务。这允许表示不同_度的逻辑Qƈ促进复用及抽象层的创建?/span>
l
服务是自ȝ
逻辑由服务所控制Qƈ位于一个清晰的边界内。服务已l在q个边界内被控制Qƈ且不依赖于执行其控制的其他服务?/span>
l
服务是无状态的
服务应当不需要管理状态信息,因此能够其维持松耦合性。服务应当尽可能设计成无状态的Q即便这意味着要将状态管理移臛_处?/span>
l
服务是可发现?/span>
服务应当允许其描q被发现Qƈ被h工和可能会利用其逻辑的服务请求者所理解?/span>
在这八条原则中,自治性、松散耦合、抽象、以及需要正式契U被视ؓ形成
SOA
Ҏ基础的核心原则。如同在本章后面面向服务原则内部如何兌一节所解释Q这四个原则直接支持其他原则Q及其相互之_的实现?/span>