看到 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，但是做的并不好，現(xiàn)在 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系統(tǒng)，并使得構建的IT系統(tǒng)更加靈活，更加和業(yè)務對齊。那么如何在實踐的層面上，在IT的生命周期中貫徹SOA的原理和思想，一步步構建出符合SOA設計原則的IT系統(tǒng)呢？這個問題的答案屬于SOA方法學的范疇。

廣義上講，SOA方法學貫穿于IT生命周期的各個階段和各個方面：IT系統(tǒng)項目的規(guī)劃，系統(tǒng)分析和設計，系統(tǒng)的實施，系統(tǒng)的部署和維護，以及整個過程中的監(jiān)控和管理等。從實踐的角度說，已經出現(xiàn)如下SOA方法學。

（1）面向服務的分析和設計（SOAD）。以服務為中心，根據(jù)業(yè)務需求發(fā)現(xiàn)服務、描述服務，并設計服務的實現(xiàn)。

（2）面向服務的開發(fā)過程。結合現(xiàn)有開發(fā)過程，規(guī)劃以服務為中心的開發(fā)過程中的角色、職責、活動和工件。

（3）SOA的成熟度分析和遷移路線圖。以服務為中心，分析現(xiàn)有或目標系統(tǒng)的成熟度，并設計從現(xiàn)有成熟度遷移到目標成熟度的路線圖。

（4）SOA監(jiān)管。設計組織和流程，確保SOA的設計原則在IT生命周期中得以貫徹，管理服務生命周期中的各種遷移的合理性等。

本章對SOA方法學的闡述主要集中在面向服務的分析和設計。首先介紹SOA方法學和主要的幾種方法學的區(qū)別和聯(lián)系，其次以IBM的SOMA（Service Oriented Modeling and Architecture，面向服務的建模與架構）為例，介紹SOA分析和設計中的主要內容和方法。

回頁首

4.1 SOA方法學和其他方法學的比較

與SOA的設計原則類似，SOA方法學并不是全新的方法學，它是現(xiàn)有方法學的繼承和發(fā)展。一方面，原有的方法學并不能解決由于服務概念的引入帶來的問題，如怎樣發(fā)現(xiàn)服務，怎樣定義服務；另一方面，服務是一個水平的概念，而不是一個垂直的概念，在服務分析和設計的過程中，需要處理服務和現(xiàn)有方法學產物的關系，如業(yè)務流程和服務，企業(yè)架構和SOA，服務和對象等。因此服務的分析和設計最主要的職責在于發(fā)現(xiàn)服務、定義服務和實現(xiàn)服務，并指導如何和其他方法學結合完成這些職責。

如圖4-1所示揭示了現(xiàn)有幾種方法學的定位。圖的橫坐標將項目周期分為分析、設計和開發(fā)三個階段，縱坐標將域分為應用、架構和業(yè)務。流程建模（BPM）用于業(yè)務領域的分析和設計，如業(yè)務流程的定義、業(yè)務數(shù)據(jù)的定義等；企業(yè)架構（EA）和方案架構（SA）側重在架構領域的分析和設計，如根據(jù)業(yè)務需求確定目前目標業(yè)務系統(tǒng)和IT系統(tǒng)，根據(jù)目標系統(tǒng)需求設計主要架構元素和它們之間的關系；面向對象的分析和設計（OOAD）則貫穿分析、設計和開發(fā)三個階段，它主要分析細粒度的業(yè)務需求，如用例，分析和設計實現(xiàn)這些需求的類和對象，以及它們之間的關系。

圖4-1 傳統(tǒng)的方法學

如圖4-2所示，面向服務的分析和設計貫穿項目周期的三個階段和IT系統(tǒng)的三個域。這暗示著，在操作層面上，面向服務的分析和設計會和其他方法學緊密相聯(lián)。

圖4-2 SOA和傳統(tǒng)的方法學

1．BPM和SOA

業(yè)務流程建模是一個相當零散的領域，存在各種各樣的方法和技術，有效的方法可以幫助企業(yè)對業(yè)務進行合理的劃分，從而求得業(yè)務層面的靈活性。有些方法則側重于流程建模本身，例如如何確定和定義業(yè)務流程中的業(yè)務活動、業(yè)務數(shù)據(jù)、業(yè)務規(guī)則、業(yè)務指標和業(yè)務事件等，但是BPM并不會幫助我們去發(fā)現(xiàn)和定義服務。從SOA的方法學來看，各種BPM的結果是面向服務的分析和設計的重要輸入，如業(yè)務組件、業(yè)務流程和業(yè)務目標是服務發(fā)現(xiàn)的重要依據(jù)，而業(yè)務指標、業(yè)務數(shù)據(jù)、業(yè)務規(guī)則等是服務暴露的分析的重要依據(jù)。

2．EA和SOA

盡管和BPM一樣，EA是一個零散的領域，但是當前的EA主要側重于定義跨越業(yè)務單元邊界的系統(tǒng)框架，企業(yè)范圍內系統(tǒng)的主要構成元素，這些元素間的關系，以及將這些元素有機組合在一起的參考架構。但是，各種EA技術都缺乏業(yè)務領域的藍圖指導企業(yè)架構的設計。從SOA方法學來看，一方面，面向服務的分析和設計通過和BPM結合將業(yè)務分解為各種類型的服務，可以作為企業(yè)業(yè)務的藍圖指導企業(yè)架構的設計；另一方面，企業(yè)架構設計的結果，如參考架構，又是服務實現(xiàn)的重要依據(jù)。

3．OOAD和SOA

面向對象的分析和設計告訴我們使用Use Case捕獲需求，并設計類、對象及對象間交互來滿足Use Case定義的需求。但是面向對象的分析和設計往往只是局限在單個應用內部，它不會缺乏業(yè)務藍圖和企業(yè)架構藍圖的指導。從SOA方法學看，在原理層面上，OOAD中的很多設計原則，如抽象、隔離關注等被SOA繼承和發(fā)揚，并應用于服務的定義和實現(xiàn)中。而在操作層面上，服務模型為OOAD進行類和對象設計提供了業(yè)務藍圖和企業(yè)架構藍圖，與此同時，Use Case作為對業(yè)務流程的補充說明被用于服務的發(fā)現(xiàn)和定義中。

回頁首

4.2 面向服務的分析和設計概述

本章以下小節(jié)將以IBM的SOMA為例，說明面向服務的分析和設計的主要任務和方法。 IBM的SOMA將面向服務的分析和設計分為服務發(fā)現(xiàn)、服務規(guī)約和服務實現(xiàn)。服務的實現(xiàn)包括服務、組件和服務組裝的實現(xiàn)。

為了開始面向服務的分析和設計，如下的輸入需要被用在分析和設計的過程中。

（1）業(yè)務領域（Business Domain）和業(yè)務功能域（Business Function Area）。業(yè)務領域和業(yè)務功能域的劃分勾勒了目標企業(yè)的業(yè)務結構，它一方面幫助我們從全局的角度來理解目標企業(yè)的業(yè)務，另一方面也是我們進行組織服務層次結構的重要依據(jù)。

（2）業(yè)務流程（Business Process）。業(yè)務流程，尤其是第一級的業(yè)務流程，對企業(yè)經營全局至關重要。通常，通過第一級的業(yè)務流程可以追溯到企業(yè)中最為重要的業(yè)務活動，因此第一級業(yè)務流程是我們進行服務分析和設計的主要入口點。

（3）業(yè)務目標（Business Goal）。組織和業(yè)務流程都是為業(yè)務目標服務的，為了完成業(yè)務目標，組織和業(yè)務流程都有可能進行適當?shù)恼{整。分析業(yè)務目標在有些時候可以幫助我們發(fā)現(xiàn)一些通過業(yè)務流程分析遺漏的服務；與此同時，業(yè)務目標也是服務描述中一部分重要的內容。

（4）現(xiàn)有系統(tǒng)（Existing System）。現(xiàn)有系統(tǒng)是目前業(yè)務活動和業(yè)務流程的寫照，通過分析現(xiàn)有系統(tǒng)模塊和功能，能夠幫助發(fā)現(xiàn)服務。與此同時，對于現(xiàn)有系統(tǒng)的分析和理解是進行服務實現(xiàn)設計的重要前提。

在掌握了業(yè)務領域劃分、業(yè)務流程、業(yè)務目標和現(xiàn)有系統(tǒng)后，SOMA按照三個階段來進行服務分析和設計--發(fā)現(xiàn)服務、描述服務和服務實現(xiàn)，如圖4-3所示。在SOMA三個階段的分析和設計過程中，分析和設計人員還需要借助于傳統(tǒng)方法中的一些素材，如業(yè)務環(huán)境和業(yè)務用例、IT環(huán)境、當前應用或組件的模型和設計等，從而完成與現(xiàn)有業(yè)務和IT緊密結合的服務規(guī)范和服務設計。在運用SOMA的過程中，這三個階段并不是一次性完成的，一般需要一個迭代的過程。另外，從企業(yè)范圍而言，分析和確定的服務模型也有一個演化的過程，并逐漸地精化，越來越貼近業(yè)務。

圖4-3 面向服務的建模和架構（SOMA）概貌圖

4.2.1 服務發(fā)現(xiàn)

服務發(fā)現(xiàn)是SOMA進行服務分析和設計的第一步。服務發(fā)現(xiàn)的主要任務，是確定在一定范圍內（通常是企業(yè)范圍，或若干關鍵業(yè)務流程范圍內）可能成為服務的候選者列表。

目前有三種方式發(fā)現(xiàn)服務的候選者，它們分別是自上而下的領域分解、自下而上的現(xiàn)有系統(tǒng)分析和中間對齊的業(yè)務目標建模。

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

自上而下的領域分解方式從業(yè)務著手進行分析，選擇端到端的業(yè)務流程進行逐層分解至業(yè)務活動，并對其間涉及的業(yè)務活動和業(yè)務對象進行變化分析。

業(yè)務組件模型是業(yè)務領域分解的輸入之一。業(yè)務組件模型是一種業(yè)務咨詢和轉型的工具，它根據(jù)業(yè)務職責、職責間的關系等因素，將業(yè)務細分為業(yè)務領域、業(yè)務執(zhí)行層次和業(yè)務組件。由于企業(yè)內部和外部環(huán)境的不同，每個業(yè)務組件在成本、投資、競爭力等方面不盡相同，因此，每個業(yè)務組件在企業(yè)發(fā)展的過程中戰(zhàn)略職責和演化的路徑也是不同的，于是由于角度的不同，就形成了所謂的業(yè)務組件的"熱點視圖"。SOA是一種特別強調業(yè)務和IT互動的技術。對于面向服務的分析和設計，業(yè)務組件模型提供了進行服務劃分的依據(jù)，而且這種劃分的方法可以平滑地從業(yè)務視圖細化到服務視圖。

端到端的業(yè)務流程是業(yè)務領域分解的另一個輸入。將業(yè)務流程分解成子流程或者業(yè)務活動，逐級進行，直到每個業(yè)務活動都是具備業(yè)務含義的最小單元。流程分解得到的業(yè)務活動樹上的每一個節(jié)點，都是服務的候選者，構成了服務候選者組合。業(yè)務領域分解可以幫助發(fā)現(xiàn)主要的服務候選者，加上自下而上和中間對齊方式發(fā)現(xiàn)的新服務候選者，最終會構成一個服務候選者列表。在SOA的方法中，服務是業(yè)務組件間的契約，因此將服務候選者劃分到業(yè)務組件，是服務分析中不可或缺的一步。服務候選者列表經過業(yè)務組件的劃分，會最終形成層次化的服務目錄。

變化分析的目的是將業(yè)務領域中易變的部分和穩(wěn)定的部分區(qū)分開來，通過將易變的業(yè)務邏輯及相關的業(yè)務規(guī)則剝離出來，來保證未來的變化不會破壞現(xiàn)有設計，從而提升架構應對變化的能力。變化分析可能會從在未來需求的分析中發(fā)現(xiàn)一些新的服務候選者，這些服務候選者需要加入到服務候選者目錄中。

2．自下而上（已有資產分析）方式

自下而上的已有資產分析方式的目的是利用已有資產來實現(xiàn)服務，已有資產包括：已有系統(tǒng)、套裝或定制應用、行業(yè)規(guī)范或業(yè)務模型等。

通過對已有資產的業(yè)務功能、技術平臺、架構及實現(xiàn)方式的分析，除了能夠驗證服務候選者或者發(fā)現(xiàn)新的服務候選者，還能夠通過分析已有系統(tǒng)、套裝或定制應用的技術局限性，盡早驗證服務實現(xiàn)決策的可行性，為服務實現(xiàn)決策提供重要的依據(jù)。

3．中間對齊（業(yè)務目標建模）方式

中間對齊的業(yè)務目標建模方式的目的是幫助發(fā)現(xiàn)與業(yè)務對齊的服務，并確保關鍵的服務在流程分解和已有資產分析的過程中沒有被遺漏。

業(yè)務目標建模將業(yè)務目標分解成子目標，然后分析哪些服務是用來實現(xiàn)這些子目標的。在這個過程中，為了可以度量這些服務的執(zhí)行情況并進而評估業(yè)務目標，我們會發(fā)現(xiàn)關鍵業(yè)務指標、度量值和相關的業(yè)務事件。

結合這三種方式的分析，我們發(fā)現(xiàn)服務候選者組合，并按照業(yè)務范圍劃分為服務目錄。同時為服務規(guī)約做好其他準備，如通過對已有資產分析進行的技術可行性評估，通過業(yè)務目標建模發(fā)現(xiàn)的業(yè)務事件等。

關于服務發(fā)現(xiàn)示例，請參見本書第13章"SOA體系結構的實例講解"。

4.2.2 服務規(guī)約

經過服務發(fā)現(xiàn)階段，服務目錄基本形成，但是對于每個服務本身的屬性信息依然零散。為了能夠將服務作為業(yè)務和IT層面互動的契約，服務規(guī)約階段是必不可少的。服務規(guī)約階段的主要任務是規(guī)范性地描述服務各個方面的屬性，其中既包括輸入/輸出消息等功能性屬性，服務安全約束和響應時間等服務質量約束，以及服務在業(yè)務層面的諸多屬性，如涉及的業(yè)務規(guī)則、業(yè)務事件、時間/人員消耗等。與此同時，規(guī)范描述服務相關方面的關系也很重要，如服務間依賴關系，服務和業(yè)務組件間關系，服務和IT組件間關系和服務消息間關系等。

進行服務暴露決策是服務規(guī)約的第一步。理論上所有的服務候選者都可以暴露為服務，但是一旦暴露為服務，該服務候選者就必須滿足附加的安全性、性能等方面的要求。企業(yè)還必須為服務的規(guī)劃、設計、開發(fā)、維護、監(jiān)管支付額外的開支，因此，我們會根據(jù)一定的規(guī)則來決定將哪些服務候選者暴露為服務。

這些規(guī)則包含以下幾個方面：

• 業(yè)務對齊。該服務候選者可以支持相關的業(yè)務流程和業(yè)務目標。
• 可組裝。該服務候選者滿足技術中立、自包含及無狀態(tài)等特點，同時還滿足復合應用的相關非功能性需求。
• 可重用。該服務候選者可以在不同的應用、流程中重用，從而減少重復的功能實現(xiàn)，降低開發(fā)和維護的成本。

基于企業(yè)應用開發(fā)的經驗，我們還可以有其他一些方面的考慮。

經過服務暴露決策后，層次化的服務目錄基本形成。下一步是結合傳統(tǒng)的方法學對服務各方面屬性進行描述。這里說的傳統(tǒng)的方法學是指企業(yè)架構，面向對象的分析和設計等。在企業(yè)架構方法學的產物中，企業(yè)數(shù)據(jù)模型有助于服務消息的定義，IT組件模型有助于服務和IT組件間關系的描述，企業(yè)安全架構有助于服務安全約束規(guī)約，企業(yè)基礎設施架構有助于服務質量的描述。在面向對象分析和設計的產物中，業(yè)務用例和系統(tǒng)用例有助于服務消息、服務相關業(yè)務規(guī)則和業(yè)務事件等描述，組件靜態(tài)模型和動態(tài)模型有助于描述服務間關系。

經過服務規(guī)約，服務組件（企業(yè)組件）和服務的各個方面的屬性被規(guī)范下來，它會成為業(yè)務和IT層面互動的基礎。以后，業(yè)務對IT的新需求會體現(xiàn)為服務層面的變更，IT層面的變化會盡量遵循服務規(guī)約。在SOA監(jiān)管的配合下，任何對服務規(guī)約的變更都是可管理和可控制的。

關于服務規(guī)約示例，請參見本書第13章"SOA體系結構的實例講解"。

4.2.3 服務實現(xiàn)

經過服務規(guī)約階段，作為業(yè)務和IT互動的服務契約已經形成。但是服務契約和IT的現(xiàn)狀還是有很大差距的，如和某個服務對應的業(yè)務邏輯分散于不同的應用中，分散在不同的地域，某些服務目前主要依靠人工完成，還沒有IT層面的實現(xiàn)。

為了將服務契約落在實地，服務實現(xiàn)階段通過差距分析，并結合傳統(tǒng)方法學完成每個服務實現(xiàn)決策。這其中包括的內容甚多，其主要內容如下。

（1）現(xiàn)有系統(tǒng)分析：調研現(xiàn)有系統(tǒng)架構，了解架構風格、主要架構元素和能力和架構元素的基本特征；調研現(xiàn)有應用，了解應用主要功能和對外接口，技術實現(xiàn)特征等；如果應用構建已經遵循基于組件開發(fā)規(guī)范，編制應用已有組件目錄；如果應用并沒有組件化，將應用覆蓋的業(yè)務功能和服務規(guī)約確定的企業(yè)組件進行映射，確定應用現(xiàn)有"組件"目錄。

（2）確定服務分配：通過服務組件和現(xiàn)有系統(tǒng)分析確定的IT組件間差距分析，確定服務組件和IT組件間映射關系。例如，一個服務組件對應一個或多個IT組件，沒有IT組件和服務組件對應，沒有服務組件和IT組件對應，服務組件和IT組件對應時有能力缺失或不匹配等。經過差距分析，一些服務中介被確定下來去實現(xiàn)服務路由，或消息格式等不匹配現(xiàn)象，一些新的IT組件被確定下來，如實現(xiàn)某業(yè)務流程的組件或實現(xiàn)人工服務的組件等。最終，服務組件都被映射到IT組件上，從而完成服務分配。

（3）服務實現(xiàn)決策：服務分配僅僅確定了需要哪些組件來實現(xiàn)服務，但是并沒有實現(xiàn)的策略和技術層面的決策。服務實現(xiàn)決策首先幫助確定服務實現(xiàn)策略，是在現(xiàn)有基礎上進行服務包裝，還是重新構建，如果重新構建，是采用已經包裝好的應用，還是外包，或者自己構建；如果是服務包裝的話，有哪些候選方案等。通常服務實現(xiàn)決策和傳統(tǒng)的架構決策是關聯(lián)在一起的。

（4）服務基礎設施設計：服務的功能實現(xiàn)，非功能需求的滿足都需要服務基礎設施的支持。在進行服務實現(xiàn)決策后，需要根據(jù)具體的需求確定服務基礎設施的能力，如用于支撐人工服務的人工服務容器，用于支撐服務編排的流程引擎等。

將服務實現(xiàn)階段的各種產物和傳統(tǒng)設計方法結合起來，就可以開始指導實際服務實現(xiàn)的實施。

轉發(fā)
1.1 SOA 的基本概念

SOA是英文詞語"Service Oriented Architecture"的縮寫，中文有多種翻譯，如"面向服務的體系結構"、"以服務為中心的體系結構"和"面向服務的架構"，其中"面向服務的架構"比較常見。SOA有很多定義，但基本上可以分為兩類：一類認為SOA主要是一種架構風格；另一類認為SOA是包含運行環(huán)境、編程模型、架構風格和相關方法論等在內的一整套新的分布式軟件系統(tǒng)構造方法和環(huán)境，涵蓋服務的整個生命周期：建模-開發(fā)-整合-部署-運行-管理。后者概括的范圍更大，著眼于未來的發(fā)展，我們更傾向于后者，認為SOA是分布式軟件系統(tǒng)構造方法和環(huán)境的新發(fā)展階段。

在SOA架構風格中，服務是最核心的抽象手段，業(yè)務被劃分（組件化）為一系列粗粒度的業(yè)務服務和業(yè)務流程。業(yè)務服務相對獨立、自包含、可重用，由一個或者多個分布的系統(tǒng)所實現(xiàn)，而業(yè)務流程由服務組裝而來。一個"服務"定義了一個與業(yè)務功能或業(yè)務數(shù)據(jù)相關的接口，以及約束這個接口的契約，如服務質量要求、業(yè)務規(guī)則、安全性要求、法律法規(guī)的遵循、關鍵業(yè)績指標（Key Performance Indicator，KPI）等。接口和契約采用中立、基于標準的方式進行定義，它獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。這使得構建在不同系統(tǒng)中的服務可以以一種統(tǒng)一的和通用的方式進行交互、相互理解。除了這種不依賴于特定技術的中立特性，通過服務注冊庫（Service Registry）加上企業(yè)服務總線（Enterprise Service Bus）來支持動態(tài)查詢、定位、路由和中介（Mediation）的能力，使得服務之間的交互是動態(tài)的，位置是透明的。技術和位置的透明性，使得服務的請求者和提供者之間高度解耦。這種松耦合系統(tǒng)的好處有兩點：一點是它適應變化的靈活性；另一點是當某個服務的內部結構和實現(xiàn)逐漸發(fā)生改變時，不影響其他服務。而緊耦合則是指應用程序的不同組件之間的接口與其功能和結構是緊密相連的，因而當發(fā)生變化時，某一部分的調整會隨著各種緊耦合的關系引起其他部分甚至整個應用程序的更改，這樣的系統(tǒng)架構就很脆弱了。

SOA架構帶來的另一個重要觀點是業(yè)務驅動IT，即IT和業(yè)務更加緊密地對齊。以粗粒度的業(yè)務服務為基礎來對業(yè)務建模，會產生更加簡潔的業(yè)務和系統(tǒng)視圖；以服務為基礎來實現(xiàn)的IT系統(tǒng)更靈活、更易于重用、更好（也更快）地應對變化；以服務為基礎，通過顯式地定義、描述、實現(xiàn)和管理業(yè)務層次的粗粒度服務（包括業(yè)務流程），提供了業(yè)務模型和相關IT實現(xiàn)之間更好的"可追溯性"，減小了它們之間的差距，使得業(yè)務的變化更容易傳遞到IT。

因此，可以將SOA的主要優(yōu)點概括為：IT能夠更好更快地提供業(yè)務價值（Business Centric）、快速應變能力（Flexibility）、重用（Reusability）。

從演變的歷程來看，SOA在很多年前就被提出來了，現(xiàn)在SOA的再現(xiàn)和流行是若干因素的結合。一方面是多年的軟件工程發(fā)展和實踐所積累的經驗、方法和各種設計/架構模式，包括OO/CBD/MDD/MDA、EAI和中間件；另一方面是互聯(lián)網(wǎng)的多年發(fā)展帶來前所未有的分布式系統(tǒng)的交互能力和標準化基礎。與此同時，企業(yè)越來越重視業(yè)務模型本身的組件化，以支持高度靈活的業(yè)務戰(zhàn)略。但是現(xiàn)有的企業(yè)軟件架構不夠靈活，難以適應日益復雜的企業(yè)整合，難以滿足隨需應變商務的需要，因此與業(yè)務對齊、以業(yè)務的敏捷應變能力為首要目標、松散耦合、支持重用的SOA架構方法得到青睞。更多的細節(jié)請參見"

基于我們同客戶打交道的經驗，有必要在這里澄清大家經常混淆的幾個基本問題。

第一，SOA是架構風格，是方法；而不是具體架構具體實現(xiàn)技術（如Web Service）、具體架構元素（如企業(yè)服務總線，Enterprise Service Bus，ESB）。

經常有人認為只要用了Web Service，就是SOA了。這是不對的，Web Service只是實現(xiàn)服務的一種具體技術表現(xiàn)形式。同樣，認為搞SOA，就是買點軟件，建個ESB，這也是不對的，ESB只是SOA架構風格中的一部分。首先，ESB是一種從實踐中總結出來的架構風格元素，即BUS（總線模式）；其次，ESB的主要功能是負責連通性和服務中介（Service Mediation），解耦服務的請求者和服務的提供者。

第二，SOA的首要目標是IT與業(yè)務對齊，支持業(yè)務的快速變化；其次是IT架構的靈活性和IT資產的重用。

業(yè)務對敏捷性的需要，是SOA最大的驅動力。一方面是業(yè)務在這方面的要求越來越高；另一方面是今天的IT很不靈活，很難適應業(yè)務快速變化的需求，不僅僅是因為IT架構不靈活，更重要的是業(yè)務模型中的元素和IT系統(tǒng)的元素之間存在很大的差距。這種不對齊，導致業(yè)務人員和IT人員之間的溝通不夠有效，業(yè)務的變化需要花費很大的代價傳遞到IT系統(tǒng)。很難想像，業(yè)務人員對一個Java對象，一個EJB或者一個JSP頁面感興趣，這離業(yè)務世界太遠了。這種業(yè)務和IT的對齊，需要在IT系統(tǒng)中實現(xiàn)更高階的抽象元素，就是業(yè)務模型中的元素（服務、流程、業(yè)績管理），并且滿足業(yè)務需要的水平整合（將人、信息、應用和流程端到端地動態(tài)整合起來）。這樣一個以服務為中心的、端到端整合的環(huán)境，首先使得業(yè)務變化可以在業(yè)務元素這個層面上溝通，更容易、更準確地從業(yè)務傳遞到IT。其次，這種變化被隔離在需要變化的局部，而不擴散到系統(tǒng)的其他部分。這就需要整個IT架構本身是松散耦合的，一個服務的變化（功能、數(shù)據(jù)、過程、技術環(huán)境等）不影響其他服務。最后，我們希望這些反映業(yè)務元素的服務，是相對穩(wěn)定、可以重用的，這對快速適應變化、減少成本是非常重要的。

第三，在工程上，SOA的重點是服務建模和基于SOA的設計原則進行架構決策和設計。

經常碰到客戶提出這樣的問題：SOA挺好，為什么好？怎么做才是SOA的方法？跟過去的方法，比如OO/CBD有什么不同？有時候一個J2EE服務器就好了，為什么那么復雜？

從建模和設計的角度來說，SOA更多地側重在業(yè)務層次上，也就是通過服務建模將業(yè)務組件化為服務模型，它是業(yè)務架構的底層，是技術架構的頂層，承上啟下，是靈活的業(yè)務模型和IT之間的橋梁，保證二者之間的"可追溯性"。從這里往下，是基于已有的方法，比如OO/CBD來進行的。從架構的層次上，SOA更多地側重于如何將企業(yè)范圍內多個分布的系統(tǒng)（包括已有系統(tǒng)/遺留系統(tǒng)）連接起來（ESB，Adapter/Connector），如何將它們的功能、數(shù)據(jù)轉化為服務，如何通過服務中介機制（ESB，Service Registry）保證服務之間以松散耦合的方式交互，如何組裝（集成）服務為流程，如何管理服務和流程等。從這往下，對于實現(xiàn)服務的一個具體應用，它的架構、設計和實現(xiàn)是可以基于已有的實踐和方法的，比如J2EE或.NET。

有些時候，由于業(yè)務需求比較簡單，所有這些東西都在一個J2EE的應用服務器上，有些要素不是那么突出，不過隨著系統(tǒng)規(guī)模的擴大，要解決的業(yè)務問題更復雜、范圍更大的時候，SOA的各種架構要素就會變得越來越重要。

在下面的小節(jié)里就概括地討論一下SOA的若干個重要方面，包括：面向服務的計算環(huán)境，編程模型，架構風格，工程方法，以及相關的技術。

回頁首

1.2 計算環(huán)境的演變和面向服務的計算環(huán)境

1.2.1 計算環(huán)境

計算環(huán)境由一組計算機、軟件平臺和相互聯(lián)通的網(wǎng)絡組成，這個環(huán)境能夠處理和交換數(shù)字信息，允許外界訪問其內信息資源（1） 。不同的計算環(huán)境有不同的計算風格和編程模型，由一些特定于該計算環(huán)境的技術來支撐。如何在一個計算環(huán)境中分割和部署計算能力、數(shù)據(jù)資源，如何讓各個部分相互通信和協(xié)作，如何在概念上對問題域進行建模，然后映射到該計算環(huán)境，都會受到計算環(huán)境的影響和制約。因此，了解一下計算環(huán)境的歷史，會幫助我們理解面向服務的計算環(huán)境是如何演變而來的。

1.2.2 計算環(huán)境的演變歷程

計算環(huán)境的演變經歷了若干個階段，在早期的主機時代，絕大多數(shù)的計算功能和系統(tǒng)的組成部分，都包括在一臺機器里。在20世紀80年代，隨著PC的繁榮，計算環(huán)境發(fā)生很大的變化。通過局域網(wǎng)相互連接的計算設備構成客戶/服務器計算環(huán)境，計算資源和數(shù)據(jù)資源被適當?shù)胤指睿蛻艉头掌魍ㄟ^網(wǎng)絡協(xié)議、遠程調用或消息等方式來相互協(xié)作，完成計算。

為了滿足更高的可伸縮性需求，多層架構出現(xiàn)，計算資源和數(shù)據(jù)資源的分布多樣化，與企業(yè)中原來已經存在的計算環(huán)境，尤其是主機及其遺留系統(tǒng)之間的集成也變得越來越重要。中間件迅速發(fā)展，開始出現(xiàn)分布式對象、組件和接口等概念，用于在計算環(huán)境中更好地分割運算邏輯和數(shù)據(jù)資源。計算環(huán)境中不同部分之間的交互，也從原有相對低層的網(wǎng)絡協(xié)議、遠程調用和消息機制的基礎上，發(fā)展到支持分布式對象、組件和接口之間的交互，這種交互在名字服務（Naming Service）等的支持下，通常是位置透明的。但由于缺乏普遍的標準化支持，很難做到技術透明，系統(tǒng)是緊耦合的。

隨著互聯(lián)網(wǎng)（Internet）的發(fā)展，開放和標準的網(wǎng)絡協(xié)議被普遍支持，所有底層計算平臺都開始支持這些標準和協(xié)議，這導致一個計算環(huán)境內部和各個計算環(huán)境之間交互的藩籬被打破。數(shù)據(jù)和功能的表示與交互在XML、WEB服務（Web Service）技術與標準的基礎上，保證了通用性和最大的交互能力，這使得計算環(huán)境發(fā)展到一個全新的階段--基于標準、開放的互聯(lián)網(wǎng)技術的計算環(huán)境。在這樣的計算環(huán)境中，各個部分可以采用異構的底層技術，它們使用XML來描述和表示自己的數(shù)據(jù)和功能，采用開放的網(wǎng)絡協(xié)議（如HTTP）來握手，在此之上，基于Web服務來互操作和交換數(shù)據(jù)。在這里，一個很重要的新概念是"服務"（2），它是一個自包含的功能，使用者通過明確定義的接口（契約）來與一個服務交互，這個接口的描述基于WSDL（Web Service Description Language）這樣的開放標準。對象和組件重在表示一個事物本身的組成部分和相互關聯(lián)（也就是WHAT"THINGS"ARE的問題），而服務則表示一個事物做什么（也就是WHAT"THINGS"DO的問題）。Web服務是實現(xiàn)服務的技術手段，就如同各種編程語言中的對象是實現(xiàn)對象的技術手段，J2EE中的EJB是實現(xiàn)組件的技術手段一樣。這種基于標準、開放的互聯(lián)網(wǎng)技術，以服務為中心的計算環(huán)境，我們稱之為"面向服務的計算環(huán)境"。

1.2.3 面向服務的計算環(huán)境

在面向服務的計算環(huán)境中，系統(tǒng)可以是高度分布、異構的。它一般包括服務運行時環(huán)境（Service Runtime）、服務總線（Service Integration Infrastructure）、服務網(wǎng)關（Service Gateway）、服務注冊庫（Service Registry）和服務組裝引擎（Service Choreography Engine）等，如圖1-1所示。

服務運行時環(huán)境提供服務（和服務組件）的部署、運行和管理能力，支持服務編程模型，保證系統(tǒng)的安全和性能等質量要素；服務總線提供服務中介的能力，使得服務使用者能夠以技術透明和位置透明的方式來訪問服務；服務注冊庫支持存儲和訪問服務的描述信息，是實現(xiàn)服務中介、管理服務的重要基礎；而服務組裝引擎，則將服務組裝為服務流程，完成一個業(yè)務過程；服務網(wǎng)關用于在不同服務計算環(huán)境的邊界進行服務翻譯，比如安全。

面向服務的計算環(huán)境是開放的、標準的，由如圖1-2所示的技術標準協(xié)議棧所定義和支持。例如，Transport層的HTTP協(xié)議，Service Description層的WSDL，Business Process層的WS-CDL等，與Policy相關的WS-Policy。本書后面的章節(jié)將討論所有統(tǒng)稱為WS-*的標準和協(xié)議。

圖1-1 SOA計算環(huán)境的組成要素


圖1-2 SOA計算環(huán)境的標準協(xié)議棧

面向服務的計算環(huán)境，為IBM所定義的隨需應變計算環(huán)境奠定了現(xiàn)實基礎。隨需應變計算環(huán)境應具備以下特點，如圖1-3所示。

圖1-3 隨需應變的計算環(huán)境應該具備的特點

（1）整合：將人、過程、應用和數(shù)據(jù)全面整合起來。

（2）虛擬化：將分布、異構的物理資源（服務器、存儲設備等）整合起來，呈現(xiàn)為統(tǒng)一的邏輯對象，以安全和可管理的方式供使用。

（3）自主計算：如同生物體一樣，系統(tǒng)具備一些高級生物系統(tǒng)的能力，包括自我診斷和修復問題，自動配置和調整以適應環(huán)境的變化，自動優(yōu)化資源的使用效率、增強工作負荷的處理的能力，自我保護數(shù)據(jù)和信息的安全。

（4）開放標準：整個環(huán)境建立在開放的標準之上，保證系統(tǒng)的交互性。

1.2.4 面向服務計算環(huán)境的現(xiàn)狀

不同的服務計算環(huán)境，采用不同的技術和產品，這里主要結合IBM的產品和技術來介紹在J2EE平臺上實現(xiàn)的服務計算環(huán)境。

主機通過增加對互聯(lián)網(wǎng)技術和標準的支持，來創(chuàng)建主機上的面向服務計算環(huán)境。比如IBM的CICS 3.1，提供了SOAP和Web服務的支持，可以將主機上的應用以Web服務的方式提供出來，供消費者使用。

多年來，IT界的主要技術提供者，一直攜手努力定義和推動Web服務的相關標準，并且在主要的幾個計算平臺上實現(xiàn)了高度兼容，包括.NET，J2EE和開源平臺（如LAMPLinux，Apache，mySQL，PHP/Perl/Python）。

IBM以J2EE為基礎，提供了全面的、強大的服務計算環(huán)境，如圖1-4所示。

圖1-4 IBM提供的服務計算環(huán)境

在這個計算環(huán)境中，它是服務的世界。其中，Access Services提供訪問已有應用或遺留系統(tǒng)的能力，將已有系統(tǒng)中的功能和信息轉化為服務，IBM提供了訪問不同系統(tǒng)的適配器和相應的框架來幫助轉化。Business App Services指那些通過新的計算平臺J2EE（如IBM的WebSphere Application Server）來實現(xiàn)的新應用，它們所實現(xiàn)的功能和信息也都轉化為服務提供出來。Partner Service指那些來自合作伙伴的服務，WebSphere Partner Gateway提供企業(yè)邊界處不同安全等差異的轉換。Information Service是那些跟信息（而不是活動）有關系的服務，比如將多個系統(tǒng)中異構的數(shù)據(jù)，聚合、轉換為業(yè)務需要的統(tǒng)一整齊的業(yè)務數(shù)據(jù)對象來訪問。Process Service是指把多個服務聚合成為一個服務流程對應業(yè)務過程的服務，這種復合服務通常是長時間運行的過程。Interaction Service是把人的活動，通過人機交互以服務的方式出現(xiàn)在整個業(yè)務過程中，作為Process Service中的一部分。

在面向服務計算環(huán)境中，企業(yè)服務總線處于非常重要的位置，它提供服務的中介，解耦服務請求者和服務提供者，是服務計算環(huán)境中的核心。 ESB是過去消息中間件的發(fā)展，采用了"總線"這樣一種模式來管理和簡化應用之間的集成拓撲結構，以廣為接受的開放標準為基礎來支持應用之間在消息、事件和服務級別上的動態(tài)互聯(lián)互通。

ESB的基本特征和能力包括：描述服務的元數(shù)據(jù)和服務注冊管理；在服務請求者和提供者之間傳遞數(shù)據(jù)及對這些數(shù)據(jù)進行轉換的能力，并支持由實踐中總結出來的一些模式如同步模式，異步模式等；發(fā)現(xiàn)、路由、匹配和選擇的能力，以支持服務之間的動態(tài)交互，解耦服務請求者和服務提供者。高級一些的能力，包括對安全的支持、服務質量保證、可管理性和負載平衡等。

ESB所提供的基于標準的連接服務，將應用中實現(xiàn)的功能或者數(shù)據(jù)資源，轉化為服務請求者能以標準的方式來訪問的服務；當請求者來請求一個服務時，ESB中這種中介轉化過程可能簡單到什么也沒有，也可能要很復雜的中介服務支持，包括動態(tài)地查找、選擇一個服務，消息的傳遞、路由和轉換、協(xié)議的轉換。這種中介過程，是ESB借助于服務注冊管理及問題域相關的知識（如業(yè)務方面的一些規(guī)則等）自動進行的，不需要服務請求者和提供者介入，從而實現(xiàn)了解耦服務請求者和提供者的技術基礎。這使得服務請求者不需要關心服務提供者的位置和具體實現(xiàn)技術，雙方在保持接口不變的情況下，各自可以獨立地演變。

所以，ESB采用總線結構模式簡化了應用之間的集成拓撲，通過源自實踐的模式，提供了基于標準的通用連接服務，使得服務請求者和服務提供者之間可以以松散耦合、動態(tài)的方式交互，從而在不同層次上使得SOA解決方案是一個松散耦合、靈活的架構。

需要注意的是，ESB是一種架構模式，不能簡單地等同于特定的技術或產品，但實現(xiàn)ESB確實需要各種產品在運行時和工具方面的支持。IBM有很好的產品支持，運行時支持包括WebSphere ESB和WebSphere Message Broker；工具支持有WebSphere Integration Developer，支持用戶以圖形界面的方式來完成相關的開發(fā)任務，如發(fā)布服務、使用各種模式、轉換消息和定義路由等。

1.2.5 面向服務的編程模型：服務組件架構（SCA）和服務數(shù)據(jù)對象（SDO）

為了促進面向服務應用的開發(fā)，IT公司聯(lián)合起來，在2005年11月發(fā)布了服務組件架構（Service Component Architecture）和服務數(shù)據(jù)對象（Service Data Object）規(guī)范，這些公司包括IBM，BEA，Oracle，SAP等。

SCA的目標是大大地簡化服務開發(fā)，直接采用Web服務和XML開發(fā)服務，使得程序員工作在底層技術上，需要應付各種異構環(huán)境下的具體實現(xiàn)細節(jié)。其中，SCA定義和規(guī)范了技術中立和實現(xiàn)透明的服務組件、服務及服務調用和組裝；而SDO定義和規(guī)范了服務世界里的數(shù)據(jù)，這些數(shù)據(jù)對象擁有清晰定義的信息模型，獨立于數(shù)據(jù)源和具體數(shù)據(jù)訪問技術，使得服務訪問數(shù)據(jù)和在服務之間交換數(shù)據(jù)更方便、有效。

很多公司已經在J2EE平臺上支持了SCA/SDO，還提供了C++的版本。IBM WebSphere Process Server 6實現(xiàn)了SCA/SDO規(guī)范，提供了最新的SOA編程模型的支持，已經在很多實踐中被廣泛使用。

回頁首

1.3 軟件體系結構的演變和面向服務的設計原則

軟件開發(fā)一直是一件很難的事情，因為我們要處理的問題越來越復雜，人們處理這種復雜性最主要的手段就是抽象。回顧歷史，我們的抽象層次越來越高，反映在各個方面，從編程語言、平臺、開發(fā)過程、工具到模式。尤其是模式，大量出現(xiàn)在那些結構上設計得很好的軟件系統(tǒng)中，無論是微觀層次上（對象、組件）穩(wěn)定出現(xiàn)的結構范式，還是在宏觀層面上出現(xiàn)的架構模式。使用哪些抽象手段來為問題域建模？如何定義組成部分之間的協(xié)作和結構關系？如何定義從外界所看到的系統(tǒng)結構和行為？是什么設計原則在指導我們的架構決策？有什么最佳實踐和模式可供借鑒？所有這些，形成了不同設計風格和體系結構范式（Architecture Paradigm）。

通常，一種體系結構范式，包括設計原則，來自實踐的結構式樣、組成要素和關系，以及在整個開發(fā)生命周期中它們是如何被識別、描述和控制的。體系結構從過去單個應用包羅一切的客戶/服務器的模式，逐漸演變到三層和多層結構的各種分布式計算模式。今天，人們開始談論和實踐面向服務、更加分布化的架構范式。

從抽象手段而言，SOA在原有方法的基礎上，增加了服務、流程等元素。這些抽象手段之間的關系如圖1-5所示。

如何利用這些抽象手段，將一個業(yè)務需求轉化為流程、服務，進一步建模為服務組件，然后結合具體實現(xiàn)環(huán)境，在重用已有系統(tǒng)的功能和數(shù)據(jù)資源的基礎上來實現(xiàn)？如圖1-6所示是IBM總結的SOA架構概念模式。

SOA架構中，繼承了來自對象和組件設計的各種原則，如封裝、自我包含等。那些保證服務的靈活性、松散耦合和重用能力的設計原則，對SOA架構來說同樣是非常重要的。

結構上，服務總線是SOA的架構模式之一。

關于服務，一些常見和討論的設計原則如下：

（1）無狀態(tài)。以避免服務請求者依賴于服務提供者的狀態(tài)。

（2）單一實例。避免功能冗余。

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


圖1-6 SOA的概念架構模式

（3）明確定義的接口。服務的接口由WSDL定義，用于指明服務的公共接口與其內部專用實現(xiàn)之間的界線。WS-Policy用于描述服務規(guī)約，XML模式（Schema）用于定義所交換的消息格式（即服務的公共數(shù)據(jù)）。使用者依賴服務規(guī)約來調用服務，所以服務定義必須長時間穩(wěn)定，一旦公布，不隨意更改；服務的定義應盡可能明確，減少使用者的不適當使用；不要讓使用者看到服務內部的私有數(shù)據(jù)。

（4）自包含和模塊化。服務封裝了那些在業(yè)務上穩(wěn)定、重復出現(xiàn)的活動和組件，實現(xiàn)服務的功能實體是完全獨立自主的，獨立進行部署、版本控制、自我管理和恢復。

（5）粗粒度。服務數(shù)量不應該太大，依靠消息交互而不是遠程過程調用（RPC），通常消息量比較大，但是服務之間的交互頻度較低。

（6）服務之間的松耦合性。服務使用者看到的是服務的接口，其位置、實現(xiàn)技術、當前狀態(tài)等對使用者是不可見的，服務私有數(shù)據(jù)對服務使用者是不可見的。

（7）重用能力。服務應該是可以重用的。

（8）互操作性、兼容和策略聲明。為了確保服務規(guī)約的全面和明確，策略成為一個越來越重要的方面。這可以是技術相關的內容，比如一個服務對安全性方面的要求；也可以是跟業(yè)務有關的語義方面的內容，比如需要滿足的費用或者服務級別方面的要求，這些策略對于服務在交互時是非常重要的。WS- Policy用于定義可配置的互操作語義，來描述特定服務的期望、控制其行為。在設計時，應該利用策略聲明確保服務期望和語義兼容性方面的完整和明確。

1.4 軟件工程的演變和面向服務體系結構

軟件工程方法和過程伴隨著軟件實踐不斷發(fā)展。軟件危機發(fā)生之后，從瀑布模型、原型方法等講究過程、文檔密集、控制較多的方法，逐漸發(fā)展到輕量級、敏捷和迭代的方法。這些方法更加人性化，避免因為過重的過程而扼殺人的主動性和創(chuàng)造性。這些方法更強調快速地交付對客戶有價值的軟件、直接的溝通、持續(xù)集成和持續(xù)質量保證。

SOA和當前軟件工程過程的一個共同交叉點就是業(yè)務價值驅動（Business Centric），強調速度。SOA從軟件的靈活性和重用能力入手，而敏捷過程則從軟件交付效率出發(fā)。

SOA的架構特性，使得敏捷過程非常適合SOA項目的實施。在SOA架構中，服務的獨立性，使得每個服務可以被單獨地開發(fā)、測試和集成。一個企業(yè)中的IT系統(tǒng)，如果是基于SOA的計算環(huán)境，那么這個環(huán)境就是一個服務的生態(tài)系統(tǒng)，每開發(fā)一個服務，馬上就可以獨立部署，成為這個生態(tài)系統(tǒng)中的一部分。這樣既很好地支持了持續(xù)集成、持續(xù)質量保證，又很好地使得這個服務馬上產生業(yè)務價值，而不是苦等其他服務的到位。服務的特性，使得敏捷過程和SOA架構可以有一個很好的結合，讓二者相得益彰。以我們與不同客戶合作的實踐，我們已經充分體會到這二者在實現(xiàn)過程中的風險控制、業(yè)務需求改變的適應能力方面相互配合的好處。比如我們在中遠集運，從瀑布過程轉向了迭代的開發(fā)過程，采用了敏捷方法的原則。

在韓國的項目里，我們的團隊來自IBM中國，IBM韓國及韓國客戶自己的工程師，分處漢城和北京兩個地方，這些工程師怎樣協(xié)作才能很快地交付高質量的系統(tǒng)而不相互牽扯？對于北京的工程師，北京的團隊無法復制客戶在漢城的已有系統(tǒng)，如何測試自己開發(fā)的服務？通過服務建模，系統(tǒng)被分解為若干相互獨立的服務，我們將那些要重用已有系統(tǒng)來實現(xiàn)的服務交給漢城的隊員，其他的交給北京的隊員，并且要求每個服務開發(fā)人員提供一個簡單的"偽"實現(xiàn)（Mock Service）。一開始，這些簡單實現(xiàn)被部署在北京和漢城的測試環(huán)境中，然后各個服務開發(fā)小組開始各自獨立地開發(fā)自己所負責的服務，而流程開發(fā)人員也在同一時間開始開發(fā)他的流程，不過所基于的服務是在那些簡單實現(xiàn)之上，但是這些簡單實現(xiàn)足以支持有意義的單元和集成測試。隨后，一旦某個服務被實現(xiàn)，它就被部署到實際的環(huán)境中，通過調整ESB的服務中介配置，對此服務的請求被路由到真實實現(xiàn)。一旦真實實現(xiàn)有問題，還可以換回簡單實現(xiàn)，以避免影響其他服務、流程的單元和集成測試。這種靈活性帶來的隨時開發(fā)、隨時部署、隨時集成和測試對于采用敏捷過程是非常有利的。

回頁首

1.5 SOA技術概覽

本節(jié)將討論目前SOA體系架構中用到的主要技術和標準。

1.5.1 SOA的主要組件

在前面關于計算環(huán)境的討論里，我們已經提到SOA計算環(huán)境的主要組件包括：服務運行時環(huán)境、服務總線、服務注冊庫、服務網(wǎng)關和流程引擎。通常，還會包括服務管理、業(yè)務活動監(jiān)控（Business Activity Monitoring）和業(yè)務績效管理（Business Performance Management，BPM）。另外，在服務建模、開發(fā)和編排服務等方面，我們需要相應的工具來支持。在分析、設計方面，我們需要基于服務的分析、設計方法，就是我們通常說的服務建模，包括服務的識別、定義和實現(xiàn)策略，其輸出是一個服務模型（Service Model）。

1.5.2 SOA主要技術和標準

Web服務作為實現(xiàn)SOA中服務的最主要手段。我們首先來了解跟Web Service相關的標準，它們大多以"WS-"作為名字的前綴，所以統(tǒng)稱WS-*。 Web服務最基本的協(xié)議包括UDDI，WSDL和SOAP，通過它們，我們可以提供直接而又簡單的Web Service支持，如圖1-7所示。

但是基本協(xié)議無法保證企業(yè)計算需要的安全性和可靠性，所以我們需要增加這方面的協(xié)議，比如WS-Security，WS-Reliability和WS-ReliableMessaging；對于復雜的業(yè)務場景，我們需要WS-BPEL和WS-CDL這樣的語言來將多個服務編排成為業(yè)務流程；管理服務的協(xié)議如WS-Manageability，WSDM等。跟Web服務相關的標準，還在快速發(fā)展當中。目前在SOA產品和實踐中，除了基本協(xié)議外，比較重要的還包括BPEL，WS-Security，WS-Policy和SCA/SDO。如表1-1所示給出了一個基本的總結，后面的章節(jié)會介紹重要的技術和標準。

圖1-7 基本W(wǎng)eb服務協(xié)議


表1-1 當前Web服務協(xié)議棧

1.5.3 SOA技術在工業(yè)界的支持現(xiàn)狀

目前，Web的標準和技術在演變當中，不同的技術環(huán)境的支持力度也不同，但是前面提到的基本核心協(xié)議，都有很好的支持。關于Web服務協(xié)議的接受和支持程度，如圖1-8所示。

圖1-8 當前Web服務的接受情況
  對于面向同步和異步應用的，基于請求/響應模式的分布式計算來說，SOA是一場革命。一個應用程序的業(yè)務邏輯（business logic）或某些單獨的功能被模塊化并作為服務呈現(xiàn)給消費者或客戶端。這些服務的關鍵是他們的松耦合特性。例如，服務的接口和實現(xiàn)相獨立。應用開發(fā)人員或者系統(tǒng)集成者可以通過組合一個或多個服務來構建應用，而無須理解服務的底層實現(xiàn)。舉例來說，一個服務可以用。NET或J2EE來實現(xiàn)，而使用該服務的應用程序可以在不同的平臺之上，使用的語言也可以不同。

　　SOA有以下特性

　　SOA服務具有平臺獨立的自我描述XML文檔。Web服務描述語言（WSDL， Web Services Description Language）是用于描述服務的標準語言。

　　SOA 服務用消息進行通信，該消息通常使用XML Schema來定義（也叫做XSD， XML Schema Definition）。消費者和提供者或消費者和服務之間的通信多見于不知道提供者的環(huán)境中。服務間的通訊也可以看作企業(yè)內部處理的關鍵商業(yè)文檔。

　　在一個企業(yè)內部，SOA服務通過一個扮演目錄列表（directory listing）角色的登記處（Registry）來進行維護。應用程序在登記處（Registry）尋找并調用某項服務。統(tǒng)一描述，定義和集成（UDDI， Universal Description， Definition， and Integration）是服務登記的標準。

　　每項SOA服務都有一個與之相關的服務品質（QoS， quality of service）。QoS的一些關鍵元素有安全需求（例如認證和授權），可靠通信（譯注：可靠消息是指，確保消息“僅且僅僅”發(fā)送一次，從而過濾重復信息。），以及誰能調用服務的策略。

　　為什么選擇SOA？

　　不同種類的操作系統(tǒng)，應用軟件，系統(tǒng)軟件和應用基礎結構（application infrastructure）相互交織，這便是IT企業(yè)的現(xiàn)狀。一些現(xiàn)存的應用程序被用來處理當前的業(yè)務流程（business processes），因此從頭建立一個新的基礎環(huán)境是不可能的。企業(yè)應該能對業(yè)務的變化做出快速的反應，利用對現(xiàn)有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業(yè)務需求，為客戶，商業(yè)伙伴以及供應商提供新的互動渠道，并呈現(xiàn)一個可以支持有機業(yè)務（organic business）的構架。SOA憑借其松耦合的特性，使得企業(yè)可以按照模塊化的方式來添加新服務或更新現(xiàn)有服務，以解決新的業(yè)務需要，提供選擇從而可以通過不同的渠道提供服務，并可以把企業(yè)現(xiàn)有的或已有的應用作為服務， 從而保護了現(xiàn)有的IT基礎建設投資。

　　如圖1的例子所示，一個使用SOA的企業(yè)，可以使用一組現(xiàn)有的應用來創(chuàng)建一個供應鏈復合應用（supply chain composite application），這些現(xiàn)有的應用通過標準接口來提供功能。

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

　　服務架構

　　為了實現(xiàn)SOA，企業(yè)需要一個服務架構，圖2顯示了一個例子：

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

　　在圖2中， 服務消費者（service consumer）可以通過發(fā)送消息來調用服務。這些消息由一個服務總線（service bus）轉換后發(fā)送給適當?shù)姆諏崿F(xiàn)。這種服務架構可以提供一個業(yè)務規(guī)則引擎（business rules engine），該引擎容許業(yè)務規(guī)則被合并在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似審核，列表（billing），日志等功能。此外，該架構給企業(yè)提供了靈活的業(yè)務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影響其他服務的情況下更改某項服務。

　　SOA基礎結構

　　要運行，管理SOA應用程序，企業(yè)需要SOA基礎，這是SOA平臺的一個部分。SOA基礎必須支持所有的相關標準，和需要的運行時容器。圖3所示的是一個典型的SOA基礎結構。接下來的章節(jié)將逐一討論該結構的每個部分。

　　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服務的默認機制，其他的技術為可以服務實現(xiàn)其他類型的綁定。一個消費者可以在UDDI注冊表（registry）查找服務，取得服務的WSDL描述，然后通過SOAP來調用服務。

　　WS-I Basic Profile

　　WS-I Basic Profile，由Web服務互用性組織（Web Services Interoperability Organization）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用Basic Profile測試程序來測試服務在不同平臺和技術上的互用性。

　　J2EE 和 .Net

　　盡管J2EE和。NET平臺是開發(fā)SOA應用程序常用的平臺，但SOA不僅限于此。像J2EE這類平臺，不僅為開發(fā)者自然而然地參與到SOA中來提供了一個平臺，還通過他們內在的特性，將可擴展性，可靠性，可用性以及性能引入了SOA世界。新的規(guī)范，例如 JAXB（Java API for XML Binding），用于將XML文檔定位到Java類；JAXR（Java API for XML Registry）用來規(guī)范對UDDI注冊表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用來調用遠程服務，這使得開發(fā)和部署可移植于標準J2EE容器的Web服務變得容易，與此同時，實現(xiàn)了跨平臺（如。NET）的服務互用。

　　服務品質

　　在企業(yè)中，關鍵任務系統(tǒng)（mission-critical system，譯注：關鍵任務系統(tǒng)是指如果一個系統(tǒng)的可靠性對于一個組織是至關重要的，那么該系統(tǒng)就是該企業(yè)的關鍵任務系統(tǒng)。比如，電話系統(tǒng)對于一個電話促銷企業(yè)來說就是關鍵任務系統(tǒng)，而文字處理系統(tǒng)就不那么關鍵了。）用來解決高級需求，例如安全性，可靠性，事物。當一個企業(yè)開始采用服務架構作為工具來進行開發(fā)和部署應用的時候，基本的Web服務規(guī)范，像WSDL，SOAP，以及UDDI就不能滿足這些高級需求。正如前面所提到的，這些需求也稱作服務品質（QoS，quality of services）。與QoS相關的眾多規(guī)范已經由一些標準化組織（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分將會討論一些QoS服務和相關標準。

　　安全

　　Web服務安全規(guī)范用來保證消息的安全性。該規(guī)范主要包括認證交換， 消息完整性和消息保密。該規(guī)范吸引人的地方在于它借助現(xiàn)有的安全標準，例如，SAML（as Security Assertion Markup Language）來實現(xiàn)web服務消息的安全。OASIS正致力于Web服務安全規(guī)范的制定。

　　可靠

　　在典型的SOA 環(huán)境中，服務消費者和服務提供者之間會有幾種不同的文檔在進行交換。具有諸如“僅且僅僅傳送一次”（ once-and-only-once delivery），“最多傳送一次”（ at-most-once delivery），“重復消息過濾”（duplicate message elimination），“保證消息傳送”（guaranteed message delivery）等特性消息的發(fā)送和確認，在關鍵任務系統(tǒng)（mission-critical systems）中變得十分重要。WS-Reliability 和 WS-ReliableMessaging是兩個用來解決此類問題的標準。這些標準現(xiàn)在都由OASIS負責。

　　策略

　　服務提供者有時候會要求服務消費者與某種策略通信。比如，服務提供商可能會要求消費者提供Kerberos安全標示，才能取得某項服務。這些要求被定義為策略斷言（policy assertions）。一項策略可能會包含多個斷言。WS-Policy用來標準化服務消費者和服務提供者之間的策略通信。

　　控制

　　當企業(yè)著手于服務架構時，服務可以用來整合數(shù)據(jù)倉庫（silos of data），應用程序，以及組件。整合應用意味著例如異步通信，并行處理，數(shù)據(jù)轉換，以及校正等進程請求必須被標準化。在SOA中，進程是使用一組離散的服務創(chuàng)建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。

　　管理

　　隨著企業(yè)服務的增長，所使用的服務和業(yè)務進程的數(shù)量也隨之增加，一個用來讓系統(tǒng)管理員管理所有運行在多相環(huán)境下的服務的管理系統(tǒng)就顯得尤為重要。WSDM（Web Services for Distributed Management）規(guī)定了任何根據(jù)WSDM實現(xiàn)的服務都可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。

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

　　SOA 不是Web服務

　　在理解SOA和Web服務的關系上，經常發(fā)生混淆。根據(jù)2003年4月的Gartner報道，Yefim V. Natis就這個問題是這樣解釋的：“Web服務是技術規(guī)范，而SOA是設計原則。特別是Web服務中的WSDL，是一個SOA配套的接口定義標準：這是Web服務和SOA的根本聯(lián)系。”從本質上來說，SOA是一種架構模式，而Web服務是利用一組標準實現(xiàn)的服務。Web服務是實現(xiàn)SOA的方式之一。用Web服務來實現(xiàn)SOA的好處是你可以實現(xiàn)一個中立平臺，來獲得服務，而且隨著越來越多的軟件商支持越來越多的Web服務規(guī)范，你會取得更好的通用性。

　　SOA的優(yōu)勢

　　SOA的概念并非什么新東西，SOA不同于現(xiàn)有的分布式技術之處在于大多數(shù)軟件商接受它并有可以實現(xiàn)SOA的平臺或應用程序。SOA伴隨著無處不在的標準，為企業(yè)的現(xiàn)有資產或投資帶來了更好的重用性。SOA能夠在最新的和現(xiàn)有的應用之上創(chuàng)建應用；SOA能夠使客戶或服務消費者免予服務實現(xiàn)的改變所帶來的影響；SOA能夠升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再適用于新需求的現(xiàn)有系統(tǒng)。總而言之，SOA以借助現(xiàn)有的應用來組合產生新服務的敏捷方式，提供給企業(yè)更好的靈活性來構建應用程序和業(yè)務流程

JBoss Seam是一個Java EE 5框架。它通過把JSF與EJB3.0組件合并在一起，從而為開發(fā)基于Web的企業(yè)應用程序提供一個最新的模式。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開發(fā)的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 的強大的應用程序框架。本文將發(fā)現(xiàn)這兩種框架之間的互補性。
2、借助 Seam 進行對話
借助 Seam 開發(fā)有狀態(tài)的 CRUD 應用程序是件輕而易舉的事情。本文向您展示如何使用 Java™Server Faces (JSF) 和 Seam 為基于 Web 的高爾夫課程目錄開發(fā)創(chuàng)建、讀取、更新和刪除用例。
3、用于 JSF 的 Ajax
JSF 基于組件的方法論促進了抽象，但大多數(shù) Ajax 實現(xiàn)由于公開了底層的 HTTP 交換而使之大受干擾。本文展示了如何使用 Seam Remoting API 和 Ajax4jsf 組件與服務器上的受管 bean 通信，就好像這些 bean 與瀏覽器同在本地一樣。