看到 Shale 的 Spring Integration 文档的介绍原理，其中顺序如下：

When asked to resolve a variable name, the following algorithm is performed:

1.Does a bean with the specified name already exist in some scope (request, session, application)? If so, return it.

2.Is there a standard JavaServer Faces managed bean definition for this variable name? If so, invoke it in the usual way, and return the bean that was created.

3.Is there configuration information for this variable name in the Spring WebApplicationContext for this application? If so, use it to create and configure an instance, and return that instance to the caller.

4.If there is no managed bean or Spring definition for this variable name, return null instead.

这样的话，只要 Spring 可以控制 Bean 的 Scope 的话，就可以把 Managed-Bean 的配置放到 Spring Bean 里来配置，一方面，我们可以省去了 JSF 的 Managed Bean 的配置，另外的话，我们可以对 JSF 的 Backing Bean 使用 AOP 以及 Spring 提供的很多功能。过去在 JSF-Spring 中尝试着去控制 Spring Bean 的 Scope，但是做的并不好，现在 Spring 2.0 给我们提供了这样的能力，经过实验，证明了这样是可行的。

不过如果使用 Spring Bean 以后，会造成使用 Managed Bean 的 JSTL 无法使用，其实 JSTL 本身用起来就时好时坏的，所以影响并不太大了。

整合起来步骤非常的简单：

1. 把 Spring 2.0 的 jar 文件放到 lib 下面，当前使用的是 Spring 2.0 RC3

2. 因为使用的是 Servlet 2.4，所以要在 web.xml 中加入
    <listener>
        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
    </listener>

3. 修改 applicationContext.xml

注释或删掉以下内容：

  <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
  " http://www.springframework.org/dtd/spring-beans.dtd ">

修改 <beans> 为：

  <beans xmlns=" http://www.springframework.org/schema/beans "
       xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
       xmlns:aop=" http://www.springframework.org/schema/aop "
       xsi:schemaLocation="
  http://www.springframework.org/schema/beans   http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd ">

4. 然后就可以按照配置 Spring Bean 的方式来配置 Managed Bean:

    这个是 Request Scope 中的 Bean:
    <bean id="loginBean" class="org.agilejava.icustomer.backingbean.LoginBean"
          scope="request" autowire="byName">
        <aop:scoped-proxy/>
    </bean>

    这个是 Session Scope 中的 Bean:
    <bean id="menuBean" class="org.agilejava.framework.commons.menu.MenuBackingBean"
          scope="session" autowire="byName">
        <aop:scoped-proxy/>
    </bean>

虽然短期来看，配置上会少写了一些，因为 autowire="byName"，但是从长远来看，我们可以利用 Spring 的更多功能，比如 AOP 来增强 Backing Bean 的能力，我的第一个设想就是用 AOP 来处理 Backing Bean 中的异常.good

第 4 章：SOA 方法学

这是《SOA：原理方法实践》的第 4 章。在第 3 章我们已经详细阐述了作为一种新的方法，SOA使用哪些原理和方法去构建IT系统，并使得构建的IT系统更加灵活，更加和业务对齐。那么如何在实践的层面上，在IT的生命周期中贯彻SOA的原理和思想，一步步构建出符合SOA设计原则的IT系统呢？这个问题的答案属于SOA方法学的范畴。

广义上讲，SOA方法学贯穿于IT生命周期的各个阶段和各个方面：IT系统项目的规划，系统分析和设计，系统的实施，系统的部署和维护，以及整个过程中的监控和管理等。从实践的角度说，已经出现如下SOA方法学。

（1）面向服务的分析和设计（SOAD）。以服务为中心，根据业务需求发现服务、描述服务，并设计服务的实现。

（2）面向服务的开发过程。结合现有开发过程，规划以服务为中心的开发过程中的角色、职责、活动和工件。

（3）SOA的成熟度分析和迁移路线图。以服务为中心，分析现有或目标系统的成熟度，并设计从现有成熟度迁移到目标成熟度的路线图。

（4）SOA监管。设计组织和流程，确保SOA的设计原则在IT生命周期中得以贯彻，管理服务生命周期中的各种迁移的合理性等。

本章对SOA方法学的阐述主要集中在面向服务的分析和设计。首先介绍SOA方法学和主要的几种方法学的区别和联系，其次以IBM的SOMA（Service Oriented Modeling and Architecture，面向服务的建模与架构）为例，介绍SOA分析和设计中的主要内容和方法。

回页首

4.1 SOA方法学和其他方法学的比较

与SOA的设计原则类似，SOA方法学并不是全新的方法学，它是现有方法学的继承和发展。一方面，原有的方法学并不能解决由于服务概念的引入带来的问题，如怎样发现服务，怎样定义服务；另一方面，服务是一个水平的概念，而不是一个垂直的概念，在服务分析和设计的过程中，需要处理服务和现有方法学产物的关系，如业务流程和服务，企业架构和SOA，服务和对象等。因此服务的分析和设计最主要的职责在于发现服务、定义服务和实现服务，并指导如何和其他方法学结合完成这些职责。

如图4-1所示揭示了现有几种方法学的定位。图的横坐标将项目周期分为分析、设计和开发三个阶段，纵坐标将域分为应用、架构和业务。流程建模（BPM）用于业务领域的分析和设计，如业务流程的定义、业务数据的定义等；企业架构（EA）和方案架构（SA）侧重在架构领域的分析和设计，如根据业务需求确定目前目标业务系统和IT系统，根据目标系统需求设计主要架构元素和它们之间的关系；面向对象的分析和设计（OOAD）则贯穿分析、设计和开发三个阶段，它主要分析细粒度的业务需求，如用例，分析和设计实现这些需求的类和对象，以及它们之间的关系。

图4-1 传统的方法学

如图4-2所示，面向服务的分析和设计贯穿项目周期的三个阶段和IT系统的三个域。这暗示着，在操作层面上，面向服务的分析和设计会和其他方法学紧密相联。

图4-2 SOA和传统的方法学

1．BPM和SOA

业务流程建模是一个相当零散的领域，存在各种各样的方法和技术，有效的方法可以帮助企业对业务进行合理的划分，从而求得业务层面的灵活性。有些方法则侧重于流程建模本身，例如如何确定和定义业务流程中的业务活动、业务数据、业务规则、业务指标和业务事件等，但是BPM并不会帮助我们去发现和定义服务。从SOA的方法学来看，各种BPM的结果是面向服务的分析和设计的重要输入，如业务组件、业务流程和业务目标是服务发现的重要依据，而业务指标、业务数据、业务规则等是服务暴露的分析的重要依据。

2．EA和SOA

尽管和BPM一样，EA是一个零散的领域，但是当前的EA主要侧重于定义跨越业务单元边界的系统框架，企业范围内系统的主要构成元素，这些元素间的关系，以及将这些元素有机组合在一起的参考架构。但是，各种EA技术都缺乏业务领域的蓝图指导企业架构的设计。从SOA方法学来看，一方面，面向服务的分析和设计通过和BPM结合将业务分解为各种类型的服务，可以作为企业业务的蓝图指导企业架构的设计；另一方面，企业架构设计的结果，如参考架构，又是服务实现的重要依据。

3．OOAD和SOA

面向对象的分析和设计告诉我们使用Use Case捕获需求，并设计类、对象及对象间交互来满足Use Case定义的需求。但是面向对象的分析和设计往往只是局限在单个应用内部，它不会缺乏业务蓝图和企业架构蓝图的指导。从SOA方法学看，在原理层面上，OOAD中的很多设计原则，如抽象、隔离关注等被SOA继承和发扬，并应用于服务的定义和实现中。而在操作层面上，服务模型为OOAD进行类和对象设计提供了业务蓝图和企业架构蓝图，与此同时，Use Case作为对业务流程的补充说明被用于服务的发现和定义中。

回页首

4.2 面向服务的分析和设计概述

本章以下小节将以IBM的SOMA为例，说明面向服务的分析和设计的主要任务和方法。 IBM的SOMA将面向服务的分析和设计分为服务发现、服务规约和服务实现。服务的实现包括服务、组件和服务组装的实现。

为了开始面向服务的分析和设计，如下的输入需要被用在分析和设计的过程中。

（1）业务领域（Business Domain）和业务功能域（Business Function Area）。业务领域和业务功能域的划分勾勒了目标企业的业务结构，它一方面帮助我们从全局的角度来理解目标企业的业务，另一方面也是我们进行组织服务层次结构的重要依据。

（2）业务流程（Business Process）。业务流程，尤其是第一级的业务流程，对企业经营全局至关重要。通常，通过第一级的业务流程可以追溯到企业中最为重要的业务活动，因此第一级业务流程是我们进行服务分析和设计的主要入口点。

（3）业务目标（Business Goal）。组织和业务流程都是为业务目标服务的，为了完成业务目标，组织和业务流程都有可能进行适当的调整。分析业务目标在有些时候可以帮助我们发现一些通过业务流程分析遗漏的服务；与此同时，业务目标也是服务描述中一部分重要的内容。

（4）现有系统（Existing System）。现有系统是目前业务活动和业务流程的写照，通过分析现有系统模块和功能，能够帮助发现服务。与此同时，对于现有系统的分析和理解是进行服务实现设计的重要前提。

在掌握了业务领域划分、业务流程、业务目标和现有系统后，SOMA按照三个阶段来进行服务分析和设计--发现服务、描述服务和服务实现，如图4-3所示。在SOMA三个阶段的分析和设计过程中，分析和设计人员还需要借助于传统方法中的一些素材，如业务环境和业务用例、IT环境、当前应用或组件的模型和设计等，从而完成与现有业务和IT紧密结合的服务规范和服务设计。在运用SOMA的过程中，这三个阶段并不是一次性完成的，一般需要一个迭代的过程。另外，从企业范围而言，分析和确定的服务模型也有一个演化的过程，并逐渐地精化，越来越贴近业务。

图4-3 面向服务的建模和架构（SOMA）概貌图

4.2.1 服务发现

服务发现是SOMA进行服务分析和设计的第一步。服务发现的主要任务，是确定在一定范围内（通常是企业范围，或若干关键业务流程范围内）可能成为服务的候选者列表。

目前有三种方式发现服务的候选者，它们分别是自上而下的领域分解、自下而上的现有系统分析和中间对齐的业务目标建模。

1．自上而下（领域分解）方式

自上而下的领域分解方式从业务着手进行分析，选择端到端的业务流程进行逐层分解至业务活动，并对其间涉及的业务活动和业务对象进行变化分析。

业务组件模型是业务领域分解的输入之一。业务组件模型是一种业务咨询和转型的工具，它根据业务职责、职责间的关系等因素，将业务细分为业务领域、业务执行层次和业务组件。由于企业内部和外部环境的不同，每个业务组件在成本、投资、竞争力等方面不尽相同，因此，每个业务组件在企业发展的过程中战略职责和演化的路径也是不同的，于是由于角度的不同，就形成了所谓的业务组件的"热点视图"。SOA是一种特别强调业务和IT互动的技术。对于面向服务的分析和设计，业务组件模型提供了进行服务划分的依据，而且这种划分的方法可以平滑地从业务视图细化到服务视图。

端到端的业务流程是业务领域分解的另一个输入。将业务流程分解成子流程或者业务活动，逐级进行，直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点，都是服务的候选者，构成了服务候选者组合。业务领域分解可以帮助发现主要的服务候选者，加上自下而上和中间对齐方式发现的新服务候选者，最终会构成一个服务候选者列表。在SOA的方法中，服务是业务组件间的契约，因此将服务候选者划分到业务组件，是服务分析中不可或缺的一步。服务候选者列表经过业务组件的划分，会最终形成层次化的服务目录。

变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来，通过将易变的业务逻辑及相关的业务规则剥离出来，来保证未来的变化不会破坏现有设计，从而提升架构应对变化的能力。变化分析可能会从在未来需求的分析中发现一些新的服务候选者，这些服务候选者需要加入到服务候选者目录中。

2．自下而上（已有资产分析）方式

自下而上的已有资产分析方式的目的是利用已有资产来实现服务，已有资产包括：已有系统、套装或定制应用、行业规范或业务模型等。

通过对已有资产的业务功能、技术平台、架构及实现方式的分析，除了能够验证服务候选者或者发现新的服务候选者，还能够通过分析已有系统、套装或定制应用的技术局限性，尽早验证服务实现决策的可行性，为服务实现决策提供重要的依据。

3．中间对齐（业务目标建模）方式

中间对齐的业务目标建模方式的目的是帮助发现与业务对齐的服务，并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。

业务目标建模将业务目标分解成子目标，然后分析哪些服务是用来实现这些子目标的。在这个过程中，为了可以度量这些服务的执行情况并进而评估业务目标，我们会发现关键业务指标、度量值和相关的业务事件。

结合这三种方式的分析，我们发现服务候选者组合，并按照业务范围划分为服务目录。同时为服务规约做好其他准备，如通过对已有资产分析进行的技术可行性评估，通过业务目标建模发现的业务事件等。

关于服务发现示例，请参见本书第13章"SOA体系结构的实例讲解"。

4.2.2 服务规约

经过服务发现阶段，服务目录基本形成，但是对于每个服务本身的属性信息依然零散。为了能够将服务作为业务和IT层面互动的契约，服务规约阶段是必不可少的。服务规约阶段的主要任务是规范性地描述服务各个方面的属性，其中既包括输入/输出消息等功能性属性，服务安全约束和响应时间等服务质量约束，以及服务在业务层面的诸多属性，如涉及的业务规则、业务事件、时间/人员消耗等。与此同时，规范描述服务相关方面的关系也很重要，如服务间依赖关系，服务和业务组件间关系，服务和IT组件间关系和服务消息间关系等。

进行服务暴露决策是服务规约的第一步。理论上所有的服务候选者都可以暴露为服务，但是一旦暴露为服务，该服务候选者就必须满足附加的安全性、性能等方面的要求。企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支，因此，我们会根据一定的规则来决定将哪些服务候选者暴露为服务。

这些规则包含以下几个方面：

• 业务对齐。该服务候选者可以支持相关的业务流程和业务目标。
• 可组装。该服务候选者满足技术中立、自包含及无状态等特点，同时还满足复合应用的相关非功能性需求。
• 可重用。该服务候选者可以在不同的应用、流程中重用，从而减少重复的功能实现，降低开发和维护的成本。

基于企业应用开发的经验，我们还可以有其他一些方面的考虑。

经过服务暴露决策后，层次化的服务目录基本形成。下一步是结合传统的方法学对服务各方面属性进行描述。这里说的传统的方法学是指企业架构，面向对象的分析和设计等。在企业架构方法学的产物中，企业数据模型有助于服务消息的定义，IT组件模型有助于服务和IT组件间关系的描述，企业安全架构有助于服务安全约束规约，企业基础设施架构有助于服务质量的描述。在面向对象分析和设计的产物中，业务用例和系统用例有助于服务消息、服务相关业务规则和业务事件等描述，组件静态模型和动态模型有助于描述服务间关系。

经过服务规约，服务组件（企业组件）和服务的各个方面的属性被规范下来，它会成为业务和IT层面互动的基础。以后，业务对IT的新需求会体现为服务层面的变更，IT层面的变化会尽量遵循服务规约。在SOA监管的配合下，任何对服务规约的变更都是可管理和可控制的。

关于服务规约示例，请参见本书第13章"SOA体系结构的实例讲解"。

4.2.3 服务实现

经过服务规约阶段，作为业务和IT互动的服务契约已经形成。但是服务契约和IT的现状还是有很大差距的，如和某个服务对应的业务逻辑分散于不同的应用中，分散在不同的地域，某些服务目前主要依靠人工完成，还没有IT层面的实现。

为了将服务契约落在实地，服务实现阶段通过差距分析，并结合传统方法学完成每个服务实现决策。这其中包括的内容甚多，其主要内容如下。

（1）现有系统分析：调研现有系统架构，了解架构风格、主要架构元素和能力和架构元素的基本特征；调研现有应用，了解应用主要功能和对外接口，技术实现特征等；如果应用构建已经遵循基于组件开发规范，编制应用已有组件目录；如果应用并没有组件化，将应用覆盖的业务功能和服务规约确定的企业组件进行映射，确定应用现有"组件"目录。

（2）确定服务分配：通过服务组件和现有系统分析确定的IT组件间差距分析，确定服务组件和IT组件间映射关系。例如，一个服务组件对应一个或多个IT组件，没有IT组件和服务组件对应，没有服务组件和IT组件对应，服务组件和IT组件对应时有能力缺失或不匹配等。经过差距分析，一些服务中介被确定下来去实现服务路由，或消息格式等不匹配现象，一些新的IT组件被确定下来，如实现某业务流程的组件或实现人工服务的组件等。最终，服务组件都被映射到IT组件上，从而完成服务分配。

（3）服务实现决策：服务分配仅仅确定了需要哪些组件来实现服务，但是并没有实现的策略和技术层面的决策。服务实现决策首先帮助确定服务实现策略，是在现有基础上进行服务包装，还是重新构建，如果重新构建，是采用已经包装好的应用，还是外包，或者自己构建；如果是服务包装的话，有哪些候选方案等。通常服务实现决策和传统的架构决策是关联在一起的。

（4）服务基础设施设计：服务的功能实现，非功能需求的满足都需要服务基础设施的支持。在进行服务实现决策后，需要根据具体的需求确定服务基础设施的能力，如用于支撑人工服务的人工服务容器，用于支撑服务编排的流程引擎等。

将服务实现阶段的各种产物和传统设计方法结合起来，就可以开始指导实际服务实现的实施。

转发
1.1 SOA 的基本概念

SOA是英文词语"Service Oriented Architecture"的缩写，中文有多种翻译，如"面向服务的体系结构"、"以服务为中心的体系结构"和"面向服务的架构"，其中"面向服务的架构"比较常见。SOA有很多定义，但基本上可以分为两类：一类认为SOA主要是一种架构风格；另一类认为SOA是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期：建模-开发-整合-部署-运行-管理。后者概括的范围更大，着眼于未来的发展，我们更倾向于后者，认为SOA是分布式软件系统构造方法和环境的新发展阶段。

在SOA架构风格中，服务是最核心的抽象手段，业务被划分（组件化）为一系列粗粒度的业务服务和业务流程。业务服务相对独立、自包含、可重用，由一个或者多个分布的系统所实现，而业务流程由服务组装而来。一个"服务"定义了一个与业务功能或业务数据相关的接口，以及约束这个接口的契约，如服务质量要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标（Key Performance Indicator，KPI）等。接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解。除了这种不依赖于特定技术的中立特性，通过服务注册库（Service Registry）加上企业服务总线（Enterprise Service Bus）来支持动态查询、定位、路由和中介（Mediation）的能力，使得服务之间的交互是动态的，位置是透明的。技术和位置的透明性，使得服务的请求者和提供者之间高度解耦。这种松耦合系统的好处有两点：一点是它适应变化的灵活性；另一点是当某个服务的内部结构和实现逐渐发生改变时，不影响其他服务。而紧耦合则是指应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当发生变化时，某一部分的调整会随着各种紧耦合的关系引起其他部分甚至整个应用程序的更改，这样的系统架构就很脆弱了。

SOA架构带来的另一个重要观点是业务驱动IT，即IT和业务更加紧密地对齐。以粗粒度的业务服务为基础来对业务建模，会产生更加简洁的业务和系统视图；以服务为基础来实现的IT系统更灵活、更易于重用、更好（也更快）地应对变化；以服务为基础，通过显式地定义、描述、实现和管理业务层次的粗粒度服务（包括业务流程），提供了业务模型和相关IT实现之间更好的"可追溯性"，减小了它们之间的差距，使得业务的变化更容易传递到IT。

因此，可以将SOA的主要优点概括为：IT能够更好更快地提供业务价值（Business Centric）、快速应变能力（Flexibility）、重用（Reusability）。

从演变的历程来看，SOA在很多年前就被提出来了，现在SOA的再现和流行是若干因素的结合。一方面是多年的软件工程发展和实践所积累的经验、方法和各种设计/架构模式，包括OO/CBD/MDD/MDA、EAI和中间件；另一方面是互联网的多年发展带来前所未有的分布式系统的交互能力和标准化基础。与此同时，企业越来越重视业务模型本身的组件化，以支持高度灵活的业务战略。但是现有的企业软件架构不够灵活，难以适应日益复杂的企业整合，难以满足随需应变商务的需要，因此与业务对齐、以业务的敏捷应变能力为首要目标、松散耦合、支持重用的SOA架构方法得到青睐。更多的细节请参见"以服务为中心的企业整合"。

基于我们同客户打交道的经验，有必要在这里澄清大家经常混淆的几个基本问题。

第一，SOA是架构风格，是方法；而不是具体架构具体实现技术（如Web Service）、具体架构元素（如企业服务总线，Enterprise Service Bus，ESB）。

经常有人认为只要用了Web Service，就是SOA了。这是不对的，Web Service只是实现服务的一种具体技术表现形式。同样，认为搞SOA，就是买点软件，建个ESB，这也是不对的，ESB只是SOA架构风格中的一部分。首先，ESB是一种从实践中总结出来的架构风格元素，即BUS（总线模式）；其次，ESB的主要功能是负责连通性和服务中介（Service Mediation），解耦服务的请求者和服务的提供者。

第二，SOA的首要目标是IT与业务对齐，支持业务的快速变化；其次是IT架构的灵活性和IT资产的重用。

业务对敏捷性的需要，是SOA最大的驱动力。一方面是业务在这方面的要求越来越高；另一方面是今天的IT很不灵活，很难适应业务快速变化的需求，不仅仅是因为IT架构不灵活，更重要的是业务模型中的元素和IT系统的元素之间存在很大的差距。这种不对齐，导致业务人员和IT人员之间的沟通不够有效，业务的变化需要花费很大的代价传递到IT系统。很难想像，业务人员对一个Java对象，一个EJB或者一个JSP页面感兴趣，这离业务世界太远了。这种业务和IT的对齐，需要在IT系统中实现更高阶的抽象元素，就是业务模型中的元素（服务、流程、业绩管理），并且满足业务需要的水平整合（将人、信息、应用和流程端到端地动态整合起来）。这样一个以服务为中心的、端到端整合的环境，首先使得业务变化可以在业务元素这个层面上沟通，更容易、更准确地从业务传递到IT。其次，这种变化被隔离在需要变化的局部，而不扩散到系统的其他部分。这就需要整个IT架构本身是松散耦合的，一个服务的变化（功能、数据、过程、技术环境等）不影响其他服务。最后，我们希望这些反映业务元素的服务，是相对稳定、可以重用的，这对快速适应变化、减少成本是非常重要的。

第三，在工程上，SOA的重点是服务建模和基于SOA的设计原则进行架构决策和设计。

经常碰到客户提出这样的问题：SOA挺好，为什么好？怎么做才是SOA的方法？跟过去的方法，比如OO/CBD有什么不同？有时候一个J2EE服务器就好了，为什么那么复杂？

从建模和设计的角度来说，SOA更多地侧重在业务层次上，也就是通过服务建模将业务组件化为服务模型，它是业务架构的底层，是技术架构的顶层，承上启下，是灵活的业务模型和IT之间的桥梁，保证二者之间的"可追溯性"。从这里往下，是基于已有的方法，比如OO/CBD来进行的。从架构的层次上，SOA更多地侧重于如何将企业范围内多个分布的系统（包括已有系统/遗留系统）连接起来（ESB，Adapter/Connector），如何将它们的功能、数据转化为服务，如何通过服务中介机制（ESB，Service Registry）保证服务之间以松散耦合的方式交互，如何组装（集成）服务为流程，如何管理服务和流程等。从这往下，对于实现服务的一个具体应用，它的架构、设计和实现是可以基于已有的实践和方法的，比如J2EE或.NET。

有些时候，由于业务需求比较简单，所有这些东西都在一个J2EE的应用服务器上，有些要素不是那么突出，不过随着系统规模的扩大，要解决的业务问题更复杂、范围更大的时候，SOA的各种架构要素就会变得越来越重要。

在下面的小节里就概括地讨论一下SOA的若干个重要方面，包括：面向服务的计算环境，编程模型，架构风格，工程方法，以及相关的技术。

回页首

1.2 计算环境的演变和面向服务的计算环境

1.2.1 计算环境

计算环境由一组计算机、软件平台和相互联通的网络组成，这个环境能够处理和交换数字信息，允许外界访问其内信息资源（1） 。不同的计算环境有不同的计算风格和编程模型，由一些特定于该计算环境的技术来支撑。如何在一个计算环境中分割和部署计算能力、数据资源，如何让各个部分相互通信和协作，如何在概念上对问题域进行建模，然后映射到该计算环境，都会受到计算环境的影响和制约。因此，了解一下计算环境的历史，会帮助我们理解面向服务的计算环境是如何演变而来的。

1.2.2 计算环境的演变历程

计算环境的演变经历了若干个阶段，在早期的主机时代，绝大多数的计算功能和系统的组成部分，都包括在一台机器里。在20世纪80年代，随着PC的繁荣，计算环境发生很大的变化。通过局域网相互连接的计算设备构成客户/服务器计算环境，计算资源和数据资源被适当地分割，客户和服务器通过网络协议、远程调用或消息等方式来相互协作，完成计算。

为了满足更高的可伸缩性需求，多层架构出现，计算资源和数据资源的分布多样化，与企业中原来已经存在的计算环境，尤其是主机及其遗留系统之间的集成也变得越来越重要。中间件迅速发展，开始出现分布式对象、组件和接口等概念，用于在计算环境中更好地分割运算逻辑和数据资源。计算环境中不同部分之间的交互，也从原有相对低层的网络协议、远程调用和消息机制的基础上，发展到支持分布式对象、组件和接口之间的交互，这种交互在名字服务（Naming Service）等的支持下，通常是位置透明的。但由于缺乏普遍的标准化支持，很难做到技术透明，系统是紧耦合的。

随着互联网（Internet）的发展，开放和标准的网络协议被普遍支持，所有底层计算平台都开始支持这些标准和协议，这导致一个计算环境内部和各个计算环境之间交互的藩篱被打破。数据和功能的表示与交互在XML、WEB服务（Web Service）技术与标准的基础上，保证了通用性和最大的交互能力，这使得计算环境发展到一个全新的阶段--基于标准、开放的互联网技术的计算环境。在这样的计算环境中，各个部分可以采用异构的底层技术，它们使用XML来描述和表示自己的数据和功能，采用开放的网络协议（如HTTP）来握手，在此之上，基于Web服务来互操作和交换数据。在这里，一个很重要的新概念是"服务"（2），它是一个自包含的功能，使用者通过明确定义的接口（契约）来与一个服务交互，这个接口的描述基于WSDL（Web Service Description Language）这样的开放标准。对象和组件重在表示一个事物本身的组成部分和相互关联（也就是WHAT"THINGS"ARE的问题），而服务则表示一个事物做什么（也就是WHAT"THINGS"DO的问题）。Web服务是实现服务的技术手段，就如同各种编程语言中的对象是实现对象的技术手段，J2EE中的EJB是实现组件的技术手段一样。这种基于标准、开放的互联网技术，以服务为中心的计算环境，我们称之为"面向服务的计算环境"。

1.2.3 面向服务的计算环境

在面向服务的计算环境中，系统可以是高度分布、异构的。它一般包括服务运行时环境（Service Runtime）、服务总线（Service Integration Infrastructure）、服务网关（Service Gateway）、服务注册库（Service Registry）和服务组装引擎（Service Choreography Engine）等，如图1-1所示。

服务运行时环境提供服务（和服务组件）的部署、运行和管理能力，支持服务编程模型，保证系统的安全和性能等质量要素；服务总线提供服务中介的能力，使得服务使用者能够以技术透明和位置透明的方式来访问服务；服务注册库支持存储和访问服务的描述信息，是实现服务中介、管理服务的重要基础；而服务组装引擎，则将服务组装为服务流程，完成一个业务过程；服务网关用于在不同服务计算环境的边界进行服务翻译，比如安全。

面向服务的计算环境是开放的、标准的，由如图1-2所示的技术标准协议栈所定义和支持。例如，Transport层的HTTP协议，Service Description层的WSDL，Business Process层的WS-CDL等，与Policy相关的WS-Policy。本书后面的章节将讨论所有统称为WS-*的标准和协议。

图1-1 SOA计算环境的组成要素


图1-2 SOA计算环境的标准协议栈

面向服务的计算环境，为IBM所定义的随需应变计算环境奠定了现实基础。随需应变计算环境应具备以下特点，如图1-3所示。

图1-3 随需应变的计算环境应该具备的特点

（1）整合：将人、过程、应用和数据全面整合起来。

（2）虚拟化：将分布、异构的物理资源（服务器、存储设备等）整合起来，呈现为统一的逻辑对象，以安全和可管理的方式供使用。

（3）自主计算：如同生物体一样，系统具备一些高级生物系统的能力，包括自我诊断和修复问题，自动配置和调整以适应环境的变化，自动优化资源的使用效率、增强工作负荷的处理的能力，自我保护数据和信息的安全。

（4）开放标准：整个环境建立在开放的标准之上，保证系统的交互性。

1.2.4 面向服务计算环境的现状

不同的服务计算环境，采用不同的技术和产品，这里主要结合IBM的产品和技术来介绍在J2EE平台上实现的服务计算环境。

主机通过增加对互联网技术和标准的支持，来创建主机上的面向服务计算环境。比如IBM的CICS 3.1，提供了SOAP和Web服务的支持，可以将主机上的应用以Web服务的方式提供出来，供消费者使用。

多年来，IT界的主要技术提供者，一直携手努力定义和推动Web服务的相关标准，并且在主要的几个计算平台上实现了高度兼容，包括.NET，J2EE和开源平台（如LAMPLinux，Apache，mySQL，PHP/Perl/Python）。

IBM以J2EE为基础，提供了全面的、强大的服务计算环境，如图1-4所示。

图1-4 IBM提供的服务计算环境

在这个计算环境中，它是服务的世界。其中，Access Services提供访问已有应用或遗留系统的能力，将已有系统中的功能和信息转化为服务，IBM提供了访问不同系统的适配器和相应的框架来帮助转化。Business App Services指那些通过新的计算平台J2EE（如IBM的WebSphere Application Server）来实现的新应用，它们所实现的功能和信息也都转化为服务提供出来。Partner Service指那些来自合作伙伴的服务，WebSphere Partner Gateway提供企业边界处不同安全等差异的转换。Information Service是那些跟信息（而不是活动）有关系的服务，比如将多个系统中异构的数据，聚合、转换为业务需要的统一整齐的业务数据对象来访问。Process Service是指把多个服务聚合成为一个服务流程对应业务过程的服务，这种复合服务通常是长时间运行的过程。Interaction Service是把人的活动，通过人机交互以服务的方式出现在整个业务过程中，作为Process Service中的一部分。

在面向服务计算环境中，企业服务总线处于非常重要的位置，它提供服务的中介，解耦服务请求者和服务提供者，是服务计算环境中的核心。 ESB是过去消息中间件的发展，采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上的动态互联互通。

ESB的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

ESB所提供的基于标准的连接服务，将应用中实现的功能或者数据资源，转化为服务请求者能以标准的方式来访问的服务；当请求者来请求一个服务时，ESB中这种中介转化过程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、选择一个服务，消息的传递、路由和转换、协议的转换。这种中介过程，是ESB借助于服务注册管理及问题域相关的知识（如业务方面的一些规则等）自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础。这使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。

所以，ESB采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOA解决方案是一个松散耦合、灵活的架构。

需要注意的是，ESB是一种架构模式，不能简单地等同于特定的技术或产品，但实现ESB确实需要各种产品在运行时和工具方面的支持。IBM有很好的产品支持，运行时支持包括WebSphere ESB和WebSphere Message Broker；工具支持有WebSphere Integration Developer，支持用户以图形界面的方式来完成相关的开发任务，如发布服务、使用各种模式、转换消息和定义路由等。

1.2.5 面向服务的编程模型：服务组件架构（SCA）和服务数据对象（SDO）

为了促进面向服务应用的开发，IT公司联合起来，在2005年11月发布了服务组件架构（Service Component Architecture）和服务数据对象（Service Data Object）规范，这些公司包括IBM，BEA，Oracle，SAP等。

SCA的目标是大大地简化服务开发，直接采用Web服务和XML开发服务，使得程序员工作在底层技术上，需要应付各种异构环境下的具体实现细节。其中，SCA定义和规范了技术中立和实现透明的服务组件、服务及服务调用和组装；而SDO定义和规范了服务世界里的数据，这些数据对象拥有清晰定义的信息模型，独立于数据源和具体数据访问技术，使得服务访问数据和在服务之间交换数据更方便、有效。

很多公司已经在J2EE平台上支持了SCA/SDO，还提供了C++的版本。IBM WebSphere Process Server 6实现了SCA/SDO规范，提供了最新的SOA编程模型的支持，已经在很多实践中被广泛使用。

回页首

1.3 软件体系结构的演变和面向服务的设计原则

软件开发一直是一件很难的事情，因为我们要处理的问题越来越复杂，人们处理这种复杂性最主要的手段就是抽象。回顾历史，我们的抽象层次越来越高，反映在各个方面，从编程语言、平台、开发过程、工具到模式。尤其是模式，大量出现在那些结构上设计得很好的软件系统中，无论是微观层次上（对象、组件）稳定出现的结构范式，还是在宏观层面上出现的架构模式。使用哪些抽象手段来为问题域建模？如何定义组成部分之间的协作和结构关系？如何定义从外界所看到的系统结构和行为？是什么设计原则在指导我们的架构决策？有什么最佳实践和模式可供借鉴？所有这些，形成了不同设计风格和体系结构范式（Architecture Paradigm）。

通常，一种体系结构范式，包括设计原则，来自实践的结构式样、组成要素和关系，以及在整个开发生命周期中它们是如何被识别、描述和控制的。体系结构从过去单个应用包罗一切的客户/服务器的模式，逐渐演变到三层和多层结构的各种分布式计算模式。今天，人们开始谈论和实践面向服务、更加分布化的架构范式。

从抽象手段而言，SOA在原有方法的基础上，增加了服务、流程等元素。这些抽象手段之间的关系如图1-5所示。

如何利用这些抽象手段，将一个业务需求转化为流程、服务，进一步建模为服务组件，然后结合具体实现环境，在重用已有系统的功能和数据资源的基础上来实现？如图1-6所示是IBM总结的SOA架构概念模式。

SOA架构中，继承了来自对象和组件设计的各种原则，如封装、自我包含等。那些保证服务的灵活性、松散耦合和重用能力的设计原则，对SOA架构来说同样是非常重要的。

结构上，服务总线是SOA的架构模式之一。

关于服务，一些常见和讨论的设计原则如下：

（1）无状态。以避免服务请求者依赖于服务提供者的状态。

（2）单一实例。避免功能冗余。

图1-5 SOA中的重要抽象手段


图1-6 SOA的概念架构模式

（3）明确定义的接口。服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式（Schema）用于定义所交换的消息格式（即服务的公共数据）。使用者依赖服务规约来调用服务，所以服务定义必须长时间稳定，一旦公布，不随意更改；服务的定义应尽可能明确，减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。

（4）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

（5）粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用（RPC），通常消息量比较大，但是服务之间的交互频度较低。

（6）服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术、当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。

（7）重用能力。服务应该是可以重用的。

（8）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，比如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，比如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS- Policy用于定义可配置的互操作语义，来描述特定服务的期望、控制其行为。在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。

1.4 软件工程的演变和面向服务体系结构

软件工程方法和过程伴随着软件实践不断发展。软件危机发生之后，从瀑布模型、原型方法等讲究过程、文档密集、控制较多的方法，逐渐发展到轻量级、敏捷和迭代的方法。这些方法更加人性化，避免因为过重的过程而扼杀人的主动性和创造性。这些方法更强调快速地交付对客户有价值的软件、直接的沟通、持续集成和持续质量保证。

SOA和当前软件工程过程的一个共同交叉点就是业务价值驱动（Business Centric），强调速度。SOA从软件的灵活性和重用能力入手，而敏捷过程则从软件交付效率出发。

SOA的架构特性，使得敏捷过程非常适合SOA项目的实施。在SOA架构中，服务的独立性，使得每个服务可以被单独地开发、测试和集成。一个企业中的IT系统，如果是基于SOA的计算环境，那么这个环境就是一个服务的生态系统，每开发一个服务，马上就可以独立部署，成为这个生态系统中的一部分。这样既很好地支持了持续集成、持续质量保证，又很好地使得这个服务马上产生业务价值，而不是苦等其他服务的到位。服务的特性，使得敏捷过程和SOA架构可以有一个很好的结合，让二者相得益彰。以我们与不同客户合作的实践，我们已经充分体会到这二者在实现过程中的风险控制、业务需求改变的适应能力方面相互配合的好处。比如我们在中远集运，从瀑布过程转向了迭代的开发过程，采用了敏捷方法的原则。

在韩国的项目里，我们的团队来自IBM中国，IBM韩国及韩国客户自己的工程师，分处汉城和北京两个地方，这些工程师怎样协作才能很快地交付高质量的系统而不相互牵扯？对于北京的工程师，北京的团队无法复制客户在汉城的已有系统，如何测试自己开发的服务？通过服务建模，系统被分解为若干相互独立的服务，我们将那些要重用已有系统来实现的服务交给汉城的队员，其他的交给北京的队员，并且要求每个服务开发人员提供一个简单的"伪"实现（Mock Service）。一开始，这些简单实现被部署在北京和汉城的测试环境中，然后各个服务开发小组开始各自独立地开发自己所负责的服务，而流程开发人员也在同一时间开始开发他的流程，不过所基于的服务是在那些简单实现之上，但是这些简单实现足以支持有意义的单元和集成测试。随后，一旦某个服务被实现，它就被部署到实际的环境中，通过调整ESB的服务中介配置，对此服务的请求被路由到真实实现。一旦真实实现有问题，还可以换回简单实现，以避免影响其他服务、流程的单元和集成测试。这种灵活性带来的随时开发、随时部署、随时集成和测试对于采用敏捷过程是非常有利的。

回页首

1.5 SOA技术概览

本节将讨论目前SOA体系架构中用到的主要技术和标准。

1.5.1 SOA的主要组件

在前面关于计算环境的讨论里，我们已经提到SOA计算环境的主要组件包括：服务运行时环境、服务总线、服务注册库、服务网关和流程引擎。通常，还会包括服务管理、业务活动监控（Business Activity Monitoring）和业务绩效管理（Business Performance Management，BPM）。另外，在服务建模、开发和编排服务等方面，我们需要相应的工具来支持。在分析、设计方面，我们需要基于服务的分析、设计方法，就是我们通常说的服务建模，包括服务的识别、定义和实现策略，其输出是一个服务模型（Service Model）。

1.5.2 SOA主要技术和标准

Web服务作为实现SOA中服务的最主要手段。我们首先来了解跟Web Service相关的标准，它们大多以"WS-"作为名字的前缀，所以统称WS-*。 Web服务最基本的协议包括UDDI，WSDL和SOAP，通过它们，我们可以提供直接而又简单的Web Service支持，如图1-7所示。

但是基本协议无法保证企业计算需要的安全性和可靠性，所以我们需要增加这方面的协议，比如WS-Security，WS-Reliability和WS-ReliableMessaging；对于复杂的业务场景，我们需要WS-BPEL和WS-CDL这样的语言来将多个服务编排成为业务流程；管理服务的协议如WS-Manageability，WSDM等。跟Web服务相关的标准，还在快速发展当中。目前在SOA产品和实践中，除了基本协议外，比较重要的还包括BPEL，WS-Security，WS-Policy和SCA/SDO。如表1-1所示给出了一个基本的总结，后面的章节会介绍重要的技术和标准。

图1-7 基本Web服务协议


表1-1 当前Web服务协议栈

1.5.3 SOA技术在工业界的支持现状

目前，Web的标准和技术在演变当中，不同的技术环境的支持力度也不同，但是前面提到的基本核心协议，都有很好的支持。关于Web服务协议的接受和支持程度，如图1-8所示。

图1-8 当前Web服务的接受情况
  对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

　　SOA有以下特性

　　SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web Services Description Language）是用于描述服务的标准语言。

　　SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。

　　在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。

　　每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。

　　为什么选择SOA？

　　不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

　　如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supply chain composite application），这些现有的应用通过标准接口来提供功能。

　　Figure 1. Supply chain application. Click on thumbnail to view full-sized image.

　　服务架构

　　为了实现SOA，企业需要一个服务架构，图2显示了一个例子：

　　Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.

　　在图2中， 服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。

　　SOA基础结构

　　要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。接下来的章节将逐一讨论该结构的每个部分。

　　Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.

　　SOAP， WSDL， UDDI

　　WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

　　WS-I Basic Profile

　　WS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。

　　J2EE 和 .Net

　　尽管J2EE和。NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规范，例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；JAXR（Java API for XML Registry）用来规范对UDDI注册表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如。NET）的服务互用。

　　服务品质

　　在企业中，关键任务系统（mission-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质（QoS，quality of services）。与QoS相关的众多规范已经由一些标准化组织（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分将会讨论一些QoS服务和相关标准。

　　安全

　　Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML（as Security Assertion Markup Language）来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。

　　可靠

　　在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery），“最多传送一次”（ at-most-once delivery），“重复消息过滤”（duplicate message elimination），“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。

　　策略

　　服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义为策略断言（policy assertions）。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。

　　控制

　　当企业着手于服务架构时，服务可以用来整合数据仓库（silos of data），应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。

　　管理

　　随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。

　　其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination 和 WS-Transaction 標準中描述， 這些都是OASIS 的工作。

　　SOA 不是Web服务

　　在理解SOA和Web服务的关系上，经常发生混淆。根据2003年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。

　　SOA的优势

　　SOA的概念并非什么新东西，SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用；SOA能够使客户或服务消费者免予服务实现的改变所带来的影响；SOA能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程

JBoss Seam是一个Java EE 5框架。它通过把JSF与EJB3.0组件合并在一起，从而为开发基于Web的企业应用程序提供一个最新的模式。Seam可以让你把EJB组件直接绑定到 JSF 页面。Seam还可帮助你把jBPM流程定义直接地集成到你的应用程序中。

相关的一些资源：
本土：JBoss Seam：http://www.jboss.com/products/seam
Docs：Seam Document：http://labs.jboss.com/portal/jbossseam/docs

入门：
一个使用JBoss Seam简化Web开发的Flash演示，可以当做JBoss Seam的入门教学
Example showing you how to generate a CRUD web application from a database using JBoss Eclipse IDE

进阶：
IBM developerWorks里的专题《Seam - 无缝集成 JSF》
这个系列讲述了 Seam 是真正适合 JSF 的第一个应用程序框架，能够修正其他扩展框架无法修正的主要弱点。阅读该系列的文章，您可以自己判断 Seam 是不是对 JSF 的适当补充。

目前有三篇文章在里面了
1、为 JSF 量身定做的应用程序框架
JSF 是用于 Java Web 应用程序的第一个标准化的用户界面框架，而 Seam 是一个扩展 JSF 的强大的应用程序框架。本文将发现这两种框架之间的互补性。
2、借助 Seam 进行对话
借助 Seam 开发有状态的 CRUD 应用程序是件轻而易举的事情。本文向您展示如何使用 Java™Server Faces (JSF) 和 Seam 为基于 Web 的高尔夫课程目录开发创建、读取、更新和删除用例。
3、用于 JSF 的 Ajax
JSF 基于组件的方法论促进了抽象，但大多数 Ajax 实现由于公开了底层的 HTTP 交换而使之大受干扰。本文展示了如何使用 Seam Remoting API 和 Ajax4jsf 组件与服务器上的受管 bean 通信，就好像这些 bean 与浏览器同在本地一样。