摘要:

在操作层协调java服务简介


摘要

迄今为止，web应用程序开发的焦点在于将业务逻辑封装成服务。在这篇文章中,Masayuki Otoshi建议将业务流程也剥离出来,就像那些业务过程管理/工作流产品一样，应用基于XML的文档来描述业务。但是这里他深入到了更低的粒度-操作。这篇文章同时展示了可继承的XML如何容许开发人员应用面向对象的概念去有效的表示流程。

在开发web应用程序的过程中，我们经常看到业务流程和逻辑在action中一起被实现，比如JSF中的后台bean和Struts中的action类。在现有框架的帮助下，比如EJB和Spring,我们能把业务逻辑剥离出来，但是业务流程始终还是嵌入在具体操作中。

BPM(业务流程管理)标准，比如BPMN(业务流程建模符号)和BPEL（业务流程执行语言），提供了一种分离业务流程的途径，那就是应用基于XML文档来描述这种分离。这种方法的另外一个好处可以在SOA(面向服务架构)基础上设计应用程序。但是，这种方法使得在web应用程序不能很好地应用action.actoin的粒度对于BPM/工作流产品来讲太低了。他们通常专注于更高的业务范围，如B2B应用程序和企业级的应用整合，而且他们假定业务分析人员会按照图1所示的方法来描述流程。但是在更低的粒度上，比如action，流程再用的可能性更大。


图1. 粒度比较

在这篇文章中，对于比较小的业务需求范畴，我建议java开发人员使用J-SOFA（Java Services Orchestration for Actions, Action级JAVA服务协调）。J-SOFA是一种协调服务的框架，这里的服务对应于类中的一个方法，无论是POJO(简单洁净Java对象)或者web服务。

由于粒度不同，J-SOFA并不支持消息，状态管理，监控等等的同步。但是不用担心，目前的BPM/工作流产品都支持这些功能，我们可以直接应用这些产品。这篇文章所讲到的服务协调框架主要关注于提供业务流程的可用性，就像服务那样。
图2说明了剥离的业务流程可以被其他应用程序重复利用。


图 2. 可重用的业务流程及服务

版权声明：任何获得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应用程序中的一些简单action的代码。我们的例子是一个简单的模型搜索程序：根据用户输入的模型ID返回模型具体信息。

你可以从这个资源下载这个示例的源代码。

在搜索jsp页面上，有一个文本框和一个submit按钮，用户可以输入model id然后提交。这个jsp页面通过一个叫ModelBean的后台bean调用showModel()方法。如列表1所示:

列表 1. search.jsp中的inputText及Submit按钮

<h:inputText id="modelId" value="#{ModelBean.modelId}" />
<h:commandButton type="submit" value="Submit" action="#{ModelBean.showModel}" />

为了产生模型具体信息页面(搜索结果页面)，showModel()方法创建Model对象和特征表，再赋值到属性当中

列表 2. 在backing bean中的showModel()方法

public String showModel() {
   if (modelId > 0) {
      ModelService modelService = new ModelService();
      BeanUtils.copyProperties(this, modelService.create(modelId));
      setFeatures(modelService.getFeatures(modelId));
   }
   ...
}

高级开发人员可以像上面展示的代码一样将业务逻辑从具体操作中分离出来，通过一个model的service实现创建model和features，再通过interface来调用它。不管怎样，如果其他人来维护后台bean，我们还能保持这个方法这样简单吗？这样做可能被证明非常困难，因为不是所有的开发人员都明白隔离展现层和业务层的好处。如果一个持有不同观点的开发人员开发维护后台bean,她/他可能会将业务逻辑加入到showModel()中去。在项目中，这种状况是很平常的，因为程序设计语言，比如这个例子中用到的java,容许我们用它强大的表现能力去实现任何业务逻辑。因此，我们应该用另外一种语言去实现业务流程，而不是java。

从一个框架的角度来看，预防开发人员沉溺于将流程和逻辑放在一起是非常重要的。描述业务流程的语言可能难于实现逻辑，但与此同时，却能像编程语言一样富有表现力。目前，需要应用BPM/工作流的概念去增加框架的解决方案。对于这个问题，我建议用XML-based文档（程序定义XML）去描述流程，它可以指定需要按照什么顺序调用哪些service。从而，应用了J-SOFA之后, showModel()方法中的流程可以像下面这样表示:

列表 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标签对应于service组件中所实现的方法。他们也可以被应用于条件或循环语句中，如if,choose,forEach等。然而，他们还是不如编程语言富于表现力。另外，J-SOFA并不能执行从service标签中获得的模型和特性对象的方法，除非是通过getter方法。这些限制条件要求开发人员用XML描述业务逻辑时具备更加复杂的知识才干，不管怎样，它们还是能帮助开发人员决定哪些业务逻辑应该用service类实现。有这些service方式实现的业务逻辑，我们可以开发基于SOA的应用程序，更能快速适应各种各样业务模型的变化。

典型的web应用程序框架不支持服务协调，如JSF和Struts。所以，我们必须在showModel()方法中编写下面的代码去执行处理：

列表 4. 调用流程的showModel()方法

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"));
   ...
}

无论如何，如果框架拥有支持调用处理的功能，我们不需要创建action。相反，我们需要：
--创建流程定义XML
--创建用于在处理中被调用的service组件
--在JSP页面编写显示处理返回值的代码

在这部分，我解释了流程定义XML如何为action定义流程；无论如何，其中的有些定义可以在真实世界中被重用。在下一节中，我将用另外一个例子去说明如何再利用流程。

可继承的XML

创建流程的时候，我们发现有些流可以被其他的流程共享。举个例子，我创建了4个页面，如下图3所示：模型总览，模型特性，和其他两种分类索引页面。所有的页面包含相同的标题和页脚。前两个模型页面用同一个Model对象来显示模型信息，如模型名称。后两个分类页面同样那个也是用一个Category对象。最后，每个页面有自己单独的页面处理进程。


图3. 流程中的共享流

在这个案例中，每个流，如模型特性，能用subProcess标签标识，它能执行另外一个叫做“sub-process”的流程。

列表 5. modelFeatures.xml调用sub-processes
(注意：在这个和后面的清单中，为了简化代码，service标签中的子标签将被省略)

<process>
   <subProcess path="page.xml" />  ---------- (1)
   <subProcess path="model.xml" /> ---------- (2)
   <service name="modelService" operation="getFeatures" /> ----- (3)
</process>

页面和模型流程隐藏在每个sub-process中，但是我们仍然能找到从(1) 到 (3)的连续流。所以，如果我们要修改流，比如改变流的顺序为(2), (3), (1),那么在另外的流程中，也不得不做这种改变。

为了解决这个问题，J-SOFA支持一种基于继承的解决方法。基本的思路是提供这样一种机制：容许导出一个基础过程中的标签，然后再重写它。

我们可以在process标签中用extends属性创建一个导出过程。在这个例子中，过程的层次结构能用如图4表示：


图 4. 流程等级图

Header和footer在基础过程中定义，model和Category在导出过程中定义，导出过程从基础过程中继承了header和footer标签。每一个代表一个特定的页面的过程，可以看成是model或category过程的扩展。
在page.xml中，我们产生一个header和footer,可是，我们并不知道到底在这个页面中会显示什么内容(模型或者分类？)在此刻，abstract标签会被导出流程中的其他标签重写，可以按如下方式应用:

列表 6. page.xml (基础流程)

<process>
   <service id="header" name="commonService" operation="getHeader" />
   <service id="footer" name="commonService" operation="getFooter" />
   <abstract id="contents" />
</process>

在列表7中，model.xml可以看成是从page.xml得到的，所以，page.xml被列入process标签的extends属性中。在这个XML块中，我们只需要描述需要重写的标签。在这个案例中，model.xml中的group标签重写了abstract标签，它在page.xml中有着相同的id ”contents”.

在这个时候，我们知道必须创建Model对象，可是我们不知道究竟哪个页面会调用这个过程。因此，我们不创建一个具体的过程，而是用abstract标签表示特定页面的内容：

列表 7. model.xml (继承流程)

<process extends="page.xml">
   <group id="contents">
      <service name="modelService" operation="create" />
      <abstract id="pageContents" />
   </group>
</process>

如列表8所示,具体页面内容在从model.xml继承的modelFeatures.xml中描述。除了特性表之外所有我们需要创建的服务，都已经在基础过程中定义，所以我们只需要重写abstract标签，用service标签调用getFeature()操作。这样，开发人员可以将焦点放在跟特定页面相关的处理上。

列表 8. modelFeatures.xml (具体流程)

<process extends="model.xml">
   <service id="pageContents" name="modelService" operation="getFeatures" />
</process>

当过程实例被实例化时，page.xml,model.xml和modelFeatures.xml这三个XML文档在执行之前被创建,如下面列表9所标示的那样:

列表 9. Model Features的复合流程

<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>

应用XML继承方法,开发人员能够重用在基础过程中表述的工作流。开发人员同样可以提供定义通用流的抽象过程,给其他开发人员描述特定页面的过程。

结论
用XML-based文档描述工作流这个概念已经在BPM和工作流产品中实施。不管怎样,到目前为止,它主要用于高层次业务描述中。在本文中,我们看到,这个概念同样适用于web应用程序中的action。
服务协调框架将直接帮助开发人员决定哪些流应该用过程XML描述,哪些逻辑应用用service实现。结果是,应用程序会基于SOA设计和开发,重用性会变得越来越好。

关于作者
Masayuki Otoshi 是一个家公司的开发Web应用的高级程序员。他还负责这家公司的应用框架的设计与开发。

资源
---下载本文源码：
http://www5f.biglobe.ne.jp/~webtest/jsofa/misc/jw-0417-sofa.zip
---J-SOFA主页：
http://www5f.biglobe.ne.jp/~webtest/jsofa/
---Matrix:Java,开源和中间件社区
---Javaworld:http://www.Javaworld.com

      JBoss 宣布发布JBoss Transactions 4.2 和JBoss Rules 3.0 新版本。

      JBoss Transactions 是一款开源的分布式事务管理平台，原来是属于Arjuna 的产品。Arjuna Technologies 公司的事务引擎已有20年的历史，并且已经被升级到可以使用Web服务事务。2005，JBoss 年通过收购Arjuna 而获得此项技术。

      JBoss Rules 是JBoss的企业规则引擎产品，前身是大家都熟悉的Drools。2005年12月，JBoss的创始人兼总裁Marc Fleury在巴塞罗纳举行的“JBoss 世界”的会议上发表的主题演讲中宣布收购Drools。 从此，Drools 项目以及该项目的主要负责人Mark Proctor 都加入了JBOSS。

下载地址：http://jboss.org/jbossBlog/blog/mlittle/?permalink=JBoss_Transactions_4_2_Released.txt

注意这一节标以“面向服务与面向对象”，有别于“比较面向服务与面向对象”。 区别在于所强调的事实：在这两个思想派别之间不必是竞争关系。

事实上，面向对象编程被普遍用于有 Web 服务内构建封装应用逻辑。然而，面向对象编程方法论在基本上与面向服务有何，这值得探究。对它们差异的理解会有助于你的工作。

下面列出这些设计方法方面的比较。（然而面向服务是基于服务的设计，面向对象是围绕对象的创建为核心。为了避免服务和对象间的比较混乱，使用了“处理逻辑单元”这一术语。）

l 面向服务强调处理逻辑（服务）单元间的松散耦合。尽管面向对象支持创建复用性、松耦合的编程例程，它们多数是以预先定义的类依赖为基础，结果导致了更多处理逻辑（对象）的紧密绑定。

l 面向服务鼓励不优雅的接口（服务描述）以便于每个通信（消息）包含尽可能多的信息以便于工作完成指定任务。面向对象编程充分支持精确的接口（ API ）以便通信（ RPC 或本地 API 调用）单元能够执行不同规模的任务。

l 面向服务期待显著改变处理逻辑单元（服务）的作用域。面向对象处理逻辑（ objects ）趋于使其作用域更小且更有针对性。

l 面向服务促进活动未知的处理逻辑单元（服务）的创建，从而驱动通信单元（消息）的智能化。面向对象鼓励处理逻辑数据的绑定，产生了高度智能化的单元（对象）。

l 面向服务偏爱处理逻辑单元 （服务）被设计成尽可能无状态。面向对象促进数据与逻辑的绑定，导致更具状态的单元（对象）。（然而，最近基于构件的设计方法偏离了这一趋势。）

l 面向服务支持组合松散耦合的处理逻辑单元（服务）。面向对象支持组合但也鼓励处理逻辑单元（ objects ）间的继承，这会导致紧耦合。

你或许已经注意到我们避免提及特定的面向对象原则，比如封装、继承及聚合。因为我们还不会充分描述面向服务的原则，我们在这一层次上给出个别的比较范例。以后将 详细解释个别的面向服务原则，然后 再继续这一讨论。

要点总结

• SOA 从根本上源自客户 - 服务器架构。当前 SOA 使用了一些用于构建客户 - 服务器应用的技术。尽管更加完善， SOA 引进的复杂性也与单纯的两层客户 - 服务器架构形成了尖锐对比。
• 分布式互联网架构已与 SOA 一样普遍，包括大量的技术。然而，不论是技术还是其基本设计原则， SOA 都具有明显特征。例如， SOA 引进了不同于分布式互联网架构的处理与安全需求，而且管理也典型地更加复杂，归咎于它对基于消息的通信的依赖。
• 传统架构已经且可继续在其自身的设计范式中使用 Web 服务。重要的是不要将这些架构与 SOA 相混淆。在分布式互联网架构中，发现了典型的对 Web 服务的非 SOA 方式的使用，此处 Web 服务被用于反映 RPC 风格的通信。

在前一节中，我们提到最近的分布式互联网架构变化已如何成为混合 Web 服务。这一主题值得详细说明，因为它已经是（并预期继续是） SOA 周围的混乱之源。

首先，传统架构内使用 Web 服务是完全合理的。由于许多编程语言都支持对 Web 服务的开发，他们可轻易地将其嵌入老的应用设计。并且，对于那些不支持 Web 服务定制开发的遗留环境，通常也可用适配器的方法来解决。

注意

尽管我们集中于分布式互联网架构，但并没有限制两层客户 - 服务器的应用使用 Web 服务。

Web 服务作为构件包装器

Web 服务在这个语境中的主要角色已引进了一个包含包装器服务的整合层，促成经由 SOA P 兼容的集成通道的同步通信（ 图 4.7 ）。实际上， SOA P 规范初始发布和第一代 SOA P 服务器都被特别设计用来复制使用消息的 RPC 风格的通信。

这些集成通道主要在集成结构中，被用以促进与其他应用或外部合作伙伴的通信。也被用于促成与其他（更多的面向服务）解决方案通信，还可利用第三方工具提供的 Web 服务。不管他们在传统架构中的使用或目的，关键是要澄清靠这种方式在分布式互联网架构中纳入 Web 服务不具备真正的 SOA 资格。这只是使用 Web 服务的分布式互联网架构。

并非是反映构件接口和用 Web 服务建立点对点连接， SOA 提供了对于不同通讯模型的强健支持（基于同步和异步的交换）。另外，在 SOA 内的 Web 服务受制于特定的设计需求，象由面向服务原则提供的那些。这些和其他的特征都支持对和谐的松散耦合的追求。一旦实现，单个服务不再限于点对点通信；它能够适应任何的现在和未来的请求者。

SOA 内部的 Web 服务

然而 SOA 在大小和品质方面会有所不同， SOA 与其他架构在 Web 服务的使用方面有切实不同的特征。本书主要专注于探索这些特征。目前已经充分阐明：基本上， SOA 构建于一组 Web 服务，它们被设计用于一个或多个电子商务流程的集体自动化（或者参与自动化的）， SOA 促进将这些服务组织成抽象企业自动化逻辑特定部分的特定层。

同样通过跨企业的标准 SOA ，出现了天然的协同性，超越了专有的应用平台。这考虑到先前不同的环境组成，以支持新的和进化的业务自动化过程。

这似乎有点自相矛盾，如果 SOA 可被视作分布式互联网架构的一种形式，同时我们初期建立早先类型的分布式架构也可被设计为 SOA 。尽管如此，且尽管现在的分布式环境可能已经深深地受到了面向服务原则的影响， SOA 这样的变化仍旧是罕见的。故而在此所提供的比较是将传统的分布式互联网架构作为其最常被设计的风格出现。

分布式互联网架构简史

为了对付两层客户服务器架构相关的成本与限制问题，构建基于构件应用的概念成为主流。多层客户 - 服务器架构浮出水面，将单独的客户程序分解成构件设计，成为符合面向对象的不同扩展。

在构件中不同的分布式应用逻辑（一些仍驻留在客户端，其他在服务器上），减少了大量逻辑都集中部署在服务器端的令人头痛的问题。服务器端构件，现在集中于应用服务器，从而可共享数据库连接管理池，减轻数据库并发访问的负担（ 图 4 ）。一个单连接就可轻易满足多用户要求。

图 4. 典型的多层客户 - 服务器架构。

获取这些效益的代价是复杂性的增加，并且最终转换为从部署问题到开发和管理过程的费用和努力。构建多样化处理能力的构件，并发请求比直接为单个用户开发一个可执行程序更困难，而且问题多多。

另外，替代客户 - 服务器数据库连接的是客户 - 服务器远程程序调用（ RPC ）连接。象 CORBA 与 DCOM 这样的 RPC 技术，准许客户工作站与服务器构件间进行远程通信。出现了类似客户 - 服务器架构的问题，包括资源及永久连接。增加这个新的维护是由于引入了中间件层。比如，在大型环境中对于应用服务器及事务监控需要特别关注。

随着万维网在 90 年代中后期成为一个计算技术的可用媒介，多层客户 - 服务器环境开始组成互联网技术。最重要的成就是软件构件被浏览器所替代。这个变化不仅从根本上改变（且限制）了用户界面设计，实际上还把 100% 的应用逻辑移到了服务器端 （ 图 5 ）。

图 5. 典型的分布式互联网架构

分布式互联网架构也引入了一个新的物理层， Web 服务器。这导致 HTTP 替代了专有的 RPC 协议而用于工作站与服务器间的通信。 RPC 的角色被限制到促成远程 Web 与应用服务器间的通信。

从 90 年代后期 2000 年中期，分布式互联网架构对于定制开发的企业解决方案而言，代表了事实上的计算平台。基于构件的日常编程技术及日益复杂的中间件，最终减少了一些整体复杂性。

那么，这个熟悉而又相似的架构该如何与 SOA 相比较呢？且看分布式互联网架构与 SOA 特征部分。

注意

尽管多层客户 - 服务器在其所有权内是一个独特的架构，我们不提供它与 SOA 之间的比较。大多数在客户 - 服务器及分布式互联网架构的比较中升级的问题，掩盖了将在多层客户 - 服务器与 SOA 的比较中讨论的问题。

应用逻辑

除了一些罕见的应用以专有扩展的方式嵌入到浏览器中以外，分布式互联网应用将其所有应用逻辑放在了服务器端。甚至客户端脚本想要执行在网页上的一个事件响应，都要从 Web 服务器基于初始的 HTTP 请求来下载。没有客户工作站上保存的逻辑，整个解决方案都是集中式的。

从而强调了：

• 应用逻辑应当如何被分割
• 被分割的处理逻辑应当驻留在何处
• 处理逻辑应当如何交互

从一个物理的角度来看，面向服务架构与分布式互联网架构非常相似。提供者逻辑驻留于服务器端而被分割成单独的单元。其中差异由刚刚所列三个主要设计原则所决定。

传统的分布式应用包含了驻留于一个或多个应用服务器上的一系列的构件。构件设计为不同粒度的功能，依赖于所执行的任务，以及它们被其他任务或应用的复用范围。驻留于相同服务器的构件通过专有 API 通信，按照它们暴露的公共接口来调用。 RPC 协议被用于实现跨越服务器边界的通信。这有可能通过使用代表远程构件的本地代理存根来实现（ 图 6 ）。

图 6 构件通信依赖于代理存根

在设计时，预期的交互构件将与其他一起考虑 --- 如此强烈以致实际对其他物理构件的引用可嵌入到程序代码内。这个设计时水平的依赖是紧耦合的形式。这样的稍许处理相对于试图在运行时定位所需构件的浪费而言是有效的。然而，嵌入式耦合导致绑定构件网络，一旦实现，不易更改。

当代 SOA 依然使用并依赖于构件。然而，整个建模方法现在会考虑创建封装一些或所有构件的服务。这些服务根据面向服务原则而设计，并且策略性地定位及暴露特定的功能集。同时这个功能可由构件提供，也可源自遗留系统及其他资源，象来自其它套装软件产品的适配器接口，或者甚至是数据库。

在服务内包装功能的目标是经由一个开放的、标准化的接口暴露功能 --- 而不用关心用于实现底层逻辑的技术。标准化的接口支持置于 SOA 核心的开放通信框架。而且，使用 Web 服务建立了松散耦合的环境，其中也运行着相对设计的分布式应用。如果设计得当，松散耦合的服务支持组合模型，允许单个的服务参与集合的设计。这引入了持续的复用与扩展机会。

有关分布式应用逻辑的设计与行为的另一个重要转变在于服务如何交换信息。当传统构件提供方法时，一旦被激活，就发送与接受参数数据，而 Web 服务通过 SOA P 消息通信。即使 SOA P 支持 RPC 风格的消息结构，大多数面向服务的 Web 服务设计却依赖于文档风格的消息。（这一重要差别在后面探究。）

消息也是结构化的并尽可能是自足的。通过使用 SOA P 报头，消息内容可以伴随阒宽泛的元信息、处理指导以及策略规则。与纯粹构件世界内的数据交换相比较， SOA 所用的通讯框架更加复杂、更加庞大，并且更易导致少数的个别传输。

最后，尽管也普遍强调复用传统的分布式设计方法， SOA 可通过促进解决方案未知服务的创建鼓励复用以及深层次的跨应用协同。

应用处理

不管什么平台、构件都代表了最大部分的应用逻辑并因此负责大多数的处理。然而，因为用于构件间通信的技术不同于完成服务间通信的技术，处理需求也是如此。

分布式互联网架构促进专有通信协议的使用，象用于远程数据交换的 DCOM 和厂商实现的 CORBA 。当这些技术遭遇历史性挑战时，它们相对是有效可靠的，特别是一旦有主动连接时。它们能够支持有状态和无状态构件的创建，主要影响同步数据交换（一些平台支持异步通信，但并未普遍使用）。

另一方面， SOA 依赖基于消息的通信。包括负载有 XML 文档的 SOA P 消息序列化、传输及去序列化。处理步骤会包括将关系数据转换成 XML 兼容结构、 XML 文档预校验以及随后的传输、以及对所接收文档进行解析和抽取。尽管已有所进步，譬如企业解析器及硬件的持续加速，大部分还是抱怨 SOA P 比 RPC 通信明显要慢一些。

在面向服务应用环境中，因为 SOA P 服务器的网络能够有效代替 RPC 风格的通信通道，导致系统开销成为一个重要的设计问题。文档与消息建模规约及校验逻辑的布置策略是重要因素，形成了面向服务架构的传输层。

这个通讯框架促进了自治服务的创建，支持宽泛的消息交换模式。尽管完全支持同步通信，但还是鼓励异步模式，因为它们提供了由通信最小化而带来的进一步优化的机会。深入支持无状态服务是不同语境的管理可采取的措施，包括使用 WS-* 规范，如 WS- 协调与 WS-BPEL ，还有定制解决方案。

技术

分布式互联网架构背后的技术在过去几年内经历了几个阶段。初始架构包含有构件、服务器端脚本以及原生的 Web 技术，比如 HTML 与 HTTP 。中间件方面的进步，允许增加处理能力及事务控制。 XML 的出现引入了复杂的数据表达，实际上提供了经由互联网协议传输的东西。后来 Web 服务的可用性允许分布式互联网应用跨越专有平台的边界。

因为许多当前的分布式应用使用了 XML 与 Web 服务，有可能这些解决方案背后的技术与那些基于 SOA 的没有太大不同。虽然一个明显的区别在于当代 SOA 将有可能构建在 XML 数据表达与 Web 服务技术平台技术之上。除了互联网核心技术集和构件的使用，没有被传统的互联网应用所统治的技术。因此， XML 与 Web 服务对于分布式互联网架构而言是可选的，但对于当代 SOA 不是。

安全

当应用逻辑散布于多个物理边界时，实现象鉴权与授权这样的基本安全措施变得更加困难。

在两层客户 - 服务器环境中，一个独有的服务器端连接可轻易实现用户论证及企业数据的传输安全。然而，当独立的连接被移除时，而且要跨越不同的物理层传播时，就需要新的安全方法。要确保信息的安全运输及用户凭证的识别、同时保留原始的安全语境，可用象委托和假冒这样传统的安全架构合成方法。加密也被加到其他广泛而开放的 HTTP 协议方面，可在 Web 服务器之外传送时受到保护。

SOA 通过引入对安全如何组合以及对应用的大规模改变，从而远离了这个模型。由于严重依赖 WS- 安全框架所建立的扩展和概念，在 SOA 中所用的安全模型在通讯层面上强调安全逻辑的安置。 SOA P 消息提供的报送区块中可存入安全逻辑。那样，无论消息在何方，安全也就随之而至。这个方法需要个体自治和服务间的松散耦合，同时一个服务可完全维持在无状态的范围。

管理

维护基于构件的应用包括跟踪单个构件实例、本地及远程通信问题，监控服务器资源需求，当然，还有标准化的数据库管理任务。分布式互联网架构进一步引入了 Web 服务器，同时解决方案执行时还需要关注额外的物理环境。因为客户 --- 不管本地的还是外部的组织 --- 使用 HTTP 连接到这些解决方案， Web 服务器就成为正式的第一接触点。因此它必须设计成可扩展的 --- 这一需求已导致 Web 服务器机器资源池的创建。

企业级 SOA 典型地需要一个额外的运行时管理。通讯框架带来的问题（特别是工作在异步交换模式时）会比基于 RPC 的数据交换的问题更不易发现。这是因为关于消息如何交换，存在太多的变化。 RPC 通信一般需要一个来自初始构件的响应，表明成功还是失败。遇到一个失败条件，就会抛出一个异常。通讯框架的异常处理可能更复杂而更不健壮。尽管 WS-* 扩展被定位于更好地处理这些情形，仍需努力保持高度管理。

其他维护任务，象资源管理（类似于构件管理），同样需要。然而，为了更好地促进复用性及可组合性，对于企业构建大量的 Web 服务而言，管理基础设施的一个很有用部分是私有注册。 UDDI 是一个标准化的技术，用于标准化地注册接口，能够手工或程序化地访问发现服务描述。

我们现在实际地跳回时间轴看一看过去架构与 SOA 的差别。这是一项有趣的研究， 我们能够看出 SOA 许多当代特征的起源。

3.1. 什么是架构？

自打有计算机处理的自动化解决方案方案起，技术架构就已存在。然而，在较老的环境中，解决方案直接建构于抽象的任务上，并规定其架构很少被执行。

随着多层应用的崛起，应用交付的变异开始剧增。 IT 部门开始认识到需要定义标准化的基线应用，作为其他应用的模板。这个定义自然是抽象的，但明确地解释了所有解决方案以这个模板为基础，包括其技术、边界、规则、限制及设计特征。这就产生了应用架构。

应用架构

应用架构对于应用开发团队的意义，相当于蓝图对于建筑工团队的意义。不同的组织印证不同水平的应用架构。一些保持了高水平，提供技术蓝图的抽象的物理及逻辑表达。另一些则包括更多的细节，类似通用数据模型，通信流程图，应用范围的安全需求，以及基础设施方面。

对于一个组织而言有几个不同的应用架构的情况是不希奇的。一个架构文档典型地代表了不同的解决方案环境。例如，一个同时拥有 .NET 与 J2EE 解决方案的组织很有可能针对每一种有分别的应用架构规范。

任何应用级架构的关键部分在于它既要直接反映解决方案的需求，同样又要考虑长期的、策略性的 IT 目标。正由于这个缘故，组织内的应用架构会伴以企业架构，并与其中居统治地位的一个保持一致。

企业架构

在较大的 IT 环境，关键在于需要控制并指导 IT 基础设施。当有很多不同的应用架构共同存在的时候，且有时甚至要整合，底层的主机平台变会复杂而繁重。因此，通常会创建一个控制规范，为企业内存在的所有异质形态的提供高层概述，同时给出支持基础设施的定义。

继续我们前一个类推，对于组织而言，企业架构规范相当于一个城市的城市规划。因此，城市规划与建筑蓝图间的关系，可与企业与应用架构规范间的关系相类比。

典型地，企业架构的变化直接影响应用架构，这是为什么架构规范通常由同一组人来维护。而且，企业架构经常包含组织长期技术和环境发展规划。例如，阶段性的目标有可能是要立足于这个规范来逐步淘汰过时的技术平台。

最后，也可能会定义技术与策略背后的企业级安全度量。然而，这经常会被作为单独的安全架构规范。

面向服务架构

简单而言，面向服务架构跨越了企业与应用架构两个领域。当被用于跨多解决方案的环境时， SOA 所提供的潜在效益才能真正释放。这个是对可复用和可协同服务的投资，并且充分利用基于厂商中立的通信平台。这并不意味着企业必须变成面向服务。 SOA 所引入的特性及特征大部分都属于这一范畴。

注意术语“ SOA ”并不意味着一个特殊的架构范围。 SOA 可以是指一个应用架构，或是用于跨企业的技术架构的标准化方法。因为 SOA 天生的可组合性（意味着单个的应用层架构可由不同的扩展及技术组成），完全适用于超越 SOA 的组织。

请注意，如同前一章所解释的， Web 服务平台提供了众多实现 SOA 形式中的一个。它是本书专门研究的一种方法，但是还存在其他方法，比如由传统的分布式平台所提供的这些。术语方面有一点很重要，就是在后面章节中及整本书中所用的术语“ SOA ”是指在第 3章 所建立的当代 SOA 模型（基于 Web 服务与面向服务原则）。

3.2. 比较 SOA 与客户 - 服务器架构

几乎在任何环境中，只要有一段软件从另一个请求或接收信息，都能够被称为“客户 - 服务器。”几乎每一个不同的应用架构都曾存在（包括 SOA ）一种客户 - 服务器的交互元素。然而，行业术语“客户 - 服务器架构”通常是指特殊的前一代环境，期间客户端与服务器扮演了特定的角色，并有清晰的实现特征。

客户 - 服务器架构简史

初期庞大的主机授予组织严格的计算方式，通常被视作是客户 - 服务器架构稚形。这些环境，其中庞大的主机后端伺服瘦客户端，被看作单层客户 - 服务器架构（ 图 2 ）。

图 2. 一 个典型的单层客户端服务器架构

主机系统天然支持同步及异步通信。后一种方法主要用于让服务器连续不断地接收来自终端的字符，以响应个别的击键事件。只在某种条件下服务器才会响应。

虽然它仍有残留痕迹，但是当两层客户 - 服务器的变化设计在 80 年代后期出现时，主机作为最初的统治计算平台开始衰退。

这个新方法引入了委派逻辑、以及处理职责下发到单个工作站的概念，导致了胖客户的诞生。受图形用户界面（ GUI ）创新的进一步支持，两层客户 - 服务器被认为是前进了一大步，并在 90 年早期持续统治了 IT 界数年之久。

这个架构的通常配置包含多个胖客户端，每一个都有自己到中心数据库服务器连接。客户端软件执行大量处理，包括所有的展现相关及多数的数据访问逻辑（ 图 3 ）。一个或多个服务器通过累积可扩展的关系型数据库管理系统，促进了这些客户端。

图 3. 典型的两层客户 - 服务器架构

让我们通过单独地和将它们与 SOA 的相应部分作比较两种方式，来看一看两层客户 - 服务器架构的主要特征。

应用逻辑

客户 - 服务器环境将大多数应用逻辑放到客户端软件中。这导致庞大的程序连同后端资源来一起来控制用户体验。分布式业务规则是一个例外。一个流行趋势是将嵌入的和维护的业务规则与数据关联，放入数据库的存储过程与触发器之内。这略微抽象了一组来自客户端的业务逻辑，并简化了数据访问编程。尽管如此，客户端还是承担着所有的展示任务。

当代面向服务解决方案中的展现层会有所不同。任何软件片段若有能力依照所需的服务契约进行 SOA P 消息交换，都可归为服务请求者。同时通常也期望请求者能提供服务，展现层的设计完全开放并对应特定的解决方案需求。

在服务器环境内，存在关于应用逻辑如何驻留与分布的选择权。这些选择权不排除数据库触发器和存储过程。同时，面向服务设计的原则开始起作用，通常指导划分自治处理逻辑的单元。这促进了特定设计品质，比如服务无状态化及协同性，还有可组合性及复用性。

另外，常有这些处理逻辑单元在 SOA 内不属于任何解决方案的情形。这也支持了促进复用以及跨越应用边界的松散耦合这一终极目标。

应用处理

因为大部分客户 - 服务器应用逻辑驻留于客户端，客户端工作站负责了大量的处理。 80/20 比率常被作为一个经验法则，按此法则数据库服务器承担了 20% 的工作量。尽管如此，数据还是常常成为这些环境中的性能瓶颈。

有大用户量的两层客户 - 服务器解决方案，通常需要每一客户建立其自身的数据库连接。通信可预期是异步的，而且这些连接是永久的（意味着它们需要通过用户登录并保持活动直至其退出应用）。专有数据库连接是昂贵的，并且资源需求经常压垮数据库服务器，给所有用户以可观的反应时间。

另外，假定客户被分配以主要的处理职责，他们常要求重要的资源。客户端执行完全是有状态的，并要消耗大量的固定 PC 内存。用户工作站因此经常需要专门运行客户端程序，以便所有可用资源能够提供给应用。

SOA 中的处理是高度分布式的，每一服务都有一个清晰的功能边界和相关的资源需求。在面向服务架构建模技术中，对于如何能够定位及部署服务你有很多的选择。

企业解决方案包含多个服务器时，每一个都装有 Web 服务并支持中间件。因此，对于 SOA 而言没有固定的比率。服务可根据需要分布，而且在决定物理部署配置时，性能需求是要考虑的因素之一。

服务与请求者间的通信可以是同步的或是异步的。这一灵活性允许进一步改进处理，特别是使用异步的消息模式时。另外，通过在消息中放入更多的智能，可获得消息层面的语境管理选择。这促进了无状态的及自治的服务本性，并进一步经历减少对状态信息缓存的需要。

技术

客户 - 服务器应用的出现促进了第四代 4GL 编程语言的使用，比如 Visual Basic 与 PowerBuilder 。这些开发环境充分利用了 Windows 操作系统所提供的能力，来创建更美观丰富、更具交互性的用户界面。尽管如此，传统的第三代语言，比如 C++ ，仍在使用，特别是对于有更严格的性能需求的解决方案。在后端，主流的数据库厂商，象 Oracle 、 Informix 、 IBM 、 Sybase 与微软，提供了强健的关系型数据库管理系统，能够管理多连接，同时提供了灵活的数据存储及数据管理特性。

SOA 所用的技术集实际上并不象它所延展的那么多。旧版本的程序语言的更新版本，象 Visual Basic ，依旧能够用于创建 Web 服务，且依旧可以使用传统数据库。尽管如此， SOA 的技术版图已经变得日渐不同。除了 Web 技术的标准集（ HTML 、 CSS 、 HTTP 等等），当代 SOA 一并带来了建立 XML 数据表达架构的绝对需求，还有 SOA P 通讯框架，以及服务架构所包含的永远扩展的 Web 服务平台。

安全

除了数据的存储与管理以及嵌入存储过程和触发器中的业务规则，安全是经常在客户 - 服务器架构的服务器层面集中处理的另一个部分。数据库十分复杂，足以管理用户帐户及用户组长，并将其分配到物理数据模型的个别部分。

安全也能够客户程序中控制，特别是当它与特定应用逻辑执行的业务规则相关联时（譬如挑选用户对部分用户界面进行限制访问）。另外，与操作系统级的安全协作可实现单点登录，此时应用直接继承操作系统的登录账户信息。

尽管有人夸耀 SOA 的优势，许多架构师却羡慕客户 - 服务器的安全性。企业数据经由单点鉴权而受到保护，建立了客户端与服务器间的单一连接。在 SOA 的分布世界中，这是不可能的。安全变成一个重要而复杂的问题，与必需的安全措施程度直接相关。牵扯到许多典型技术，大多数包含在 WS- 安全框架中 。

管理

客户 - 服务器时代终结的一个重要原因在于相关分发的大量维护成本的增加，以及跨工作站应用逻辑的维护。因为每一个客户装载有应用代码，每一次应用更新都要对所有的工作站重新分发软件。在较大型的环境中，这造成了高度繁重的管理流程。

维护问题跨越了用户端和服务器端。客户工作站受特定环境问题的支配，因为不同的工作站会安装不同的软件程序，或者可能购买不同的硬件厂商。更有甚者，还增加了对服务器端数据库的要求，特别是当客户 - 服务器应用拓展到更大的用户基础时。

因为面向服务的解决方案会有不同的请求者，它们还要受到来自客户端维护的挑战。同时其分布式后端要适应应用及数据库服务器的扩展性，会引入新的管理需求。例如，一旦 SOA 发展为服务复用并成为多服务组合的一部分，服务器资源与服务接口的管理会需要强大的管理工具，包括私用注册的使用。

8.3. 面向服务的一般原则

在第 3章 中我们建立了不止一个 SOA 定义。也有不止一个掌控定义面向服务背后原则的标准体。同样，对于面向服务的组成，也有许多源自公开的 IT 组织、厂商及咨询机构观点。

据称面向服务的根源在于软件工程理论所谓的“关注点分离”。这一理论基于这样的观念：将一个大的问题分解为一系列单个关注点是有益的。这使得逻辑将需要解决的问题分解成更小的、相关片段的集合。每一段逻辑处理一个特定的关注点。

这个理论已经被不同的开发平台以不同的方式实现。例如，面向对象的编程与基于组件的编程方法，通过使用对象、类和组件而实现了关注点分离。

面向服务能够被视作以截然不同的方式来实现关注点分离。面向服务原则提供了一个支持此理论的方法，同时实现了一种基本范式，在此基础上可构建诸多当代 SOA 特征。实际上，如果你再次研究这些特征，将会注意到数个（直接或间接）与关注点分离理论有联系。

如前所述，没有官方的面向服务原则。然而，却有一些最常与面向服务关联的原则。现将这些原则罗列如下，本节将做进一步描述。

l 服务可复用 不管是否存在即时复用的机会，服务被设计为支持潜在可复用。

l 服务共享一个正式契约 为了与服务交互，只需要共享描述每个服务信息交换术语定义的正式契约。

l 服务是松散耦合的 服务被设计为无需紧密的、跨服务的依赖而交互。

l 服务是底层逻辑的抽象 只有经由服务契约所暴露的部分服务对于外部世界是可见的。契约之外所表达的底层逻辑是不可见的，且与服务请求者无关。

l 服务是可组合的 服务可能组合其他服务。这允许表示不同粒度的逻辑，并促进复用及抽象层的创建。

l 服务是自治的 逻辑由服务所控制，并位于一个清晰的边界内。服务已经在这个边界内被控制，并且不依赖于执行其控制的其他服务。

l 服务是无状态的 服务应当不需要管理状态信息，因此能够其维持松耦合性。服务应当尽可能设计成无状态的，即便这意味着要将状态管理移至别处。

l 服务是可发现的 服务应当允许其描述被发现，并被人工和可能会利用其逻辑的服务请求者所理解。

在这八条原则中，自治性、松散耦合、抽象、以及需要正式契约被视为形成 SOA 根本基础的核心原则。如同在本章后面面向服务原则内部如何关联一节所解释，这四个原则直接支持其他原则（及其相互之间）的实现。