看到 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 給我們提供了這樣的能力，經(jīng)過實驗，證明了這樣是可行的。

不過如果使用 Spring Bean 以后，會造成使用 Managed Bean 的 JSTL 無法使用，其實 JSTL 本身用起來就時好時壞的，所以影響并不太大了。

整合起來步驟非常的簡單：

1. 把 Spring 2.0 的 jar 文件放到 lib 下面，當(dāng)前使用的是 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

注釋或刪掉以下內(nèi)容：

  <!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"，但是從長遠(yuǎn)來看，我們可以利用 Spring 的更多功能，比如 AOP 來增強 Backing Bean 的能力，我的第一個設(shè)想就是用 AOP 來處理 Backing Bean 中的異常.good

第 4 章：SOA 方法學(xué)

這是《SOA：原理方法實踐》的第 4 章。在第 3 章我們已經(jīng)詳細(xì)闡述了作為一種新的方法，SOA使用哪些原理和方法去構(gòu)建IT系統(tǒng)，并使得構(gòu)建的IT系統(tǒng)更加靈活，更加和業(yè)務(wù)對齊。那么如何在實踐的層面上，在IT的生命周期中貫徹SOA的原理和思想，一步步構(gòu)建出符合SOA設(shè)計原則的IT系統(tǒng)呢？這個問題的答案屬于SOA方法學(xué)的范疇。

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

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

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

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

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

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

回頁首

4.1 SOA方法學(xué)和其他方法學(xué)的比較

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

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

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

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

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

1．BPM和SOA

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

2．EA和SOA

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

3．OOAD和SOA

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

回頁首

4.2 面向服務(wù)的分析和設(shè)計概述

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

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

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

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

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

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

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

圖4-3 面向服務(wù)的建模和架構(gòu)（SOMA）概貌圖

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

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

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

1．自上而下（領(lǐng)域分解）方式

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

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

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

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

2．自下而上（已有資產(chǎn)分析）方式

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

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

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

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

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

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

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

4.2.2 服務(wù)規(guī)約

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

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

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

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

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

經(jīng)過服務(wù)暴露決策后，層次化的服務(wù)目錄基本形成。下一步是結(jié)合傳統(tǒng)的方法學(xué)對服務(wù)各方面屬性進行描述。這里說的傳統(tǒng)的方法學(xué)是指企業(yè)架構(gòu)，面向?qū)ο蟮姆治龊驮O(shè)計等。在企業(yè)架構(gòu)方法學(xué)的產(chǎn)物中，企業(yè)數(shù)據(jù)模型有助于服務(wù)消息的定義，IT組件模型有助于服務(wù)和IT組件間關(guān)系的描述，企業(yè)安全架構(gòu)有助于服務(wù)安全約束規(guī)約，企業(yè)基礎(chǔ)設(shè)施架構(gòu)有助于服務(wù)質(zhì)量的描述。在面向?qū)ο蠓治龊驮O(shè)計的產(chǎn)物中，業(yè)務(wù)用例和系統(tǒng)用例有助于服務(wù)消息、服務(wù)相關(guān)業(yè)務(wù)規(guī)則和業(yè)務(wù)事件等描述，組件靜態(tài)模型和動態(tài)模型有助于描述服務(wù)間關(guān)系。

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

關(guān)于服務(wù)規(guī)約示例，請參見本書第13章"SOA體系結(jié)構(gòu)的實例講解"。

4.2.3 服務(wù)實現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二，SOA的首要目標(biāo)是IT與業(yè)務(wù)對齊，支持業(yè)務(wù)的快速變化；其次是IT架構(gòu)的靈活性和IT資產(chǎn)的重用。

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

第三，在工程上，SOA的重點是服務(wù)建模和基于SOA的設(shè)計原則進行架構(gòu)決策和設(shè)計。

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

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

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

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

回頁首

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

1.2.1 計算環(huán)境

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，ESB采用總線結(jié)構(gòu)模式簡化了應(yīng)用之間的集成拓?fù)洌ㄟ^源自實踐的模式，提供了基于標(biāo)準(zhǔn)的通用連接服務(wù)，使得服務(wù)請求者和服務(wù)提供者之間可以以松散耦合、動態(tài)的方式交互，從而在不同層次上使得SOA解決方案是一個松散耦合、靈活的架構(gòu)。

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

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

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

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

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

回頁首

1.3 軟件體系結(jié)構(gòu)的演變和面向服務(wù)的設(shè)計原則

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

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

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

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

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

結(jié)構(gòu)上，服務(wù)總線是SOA的架構(gòu)模式之一。

關(guān)于服務(wù)，一些常見和討論的設(shè)計原則如下：

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

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

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


圖1-6 SOA的概念架構(gòu)模式

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

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

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

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

（7）重用能力。服務(wù)應(yīng)該是可以重用的。

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

1.4 軟件工程的演變和面向服務(wù)體系結(jié)構(gòu)

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

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

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

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

回頁首

1.5 SOA技術(shù)概覽

本節(jié)將討論目前SOA體系架構(gòu)中用到的主要技術(shù)和標(biāo)準(zhǔn)。

1.5.1 SOA的主要組件

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

1.5.2 SOA主要技術(shù)和標(biāo)準(zhǔn)

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

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

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


表1-1 當(dāng)前Web服務(wù)協(xié)議棧

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

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

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

　　SOA有以下特性

　　SOA服務(wù)具有平臺獨立的自我描述XML文檔。Web服務(wù)描述語言（WSDL， Web Services Description Language）是用于描述服務(wù)的標(biāo)準(zhǔn)語言。

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

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

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

　　為什么選擇SOA？

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

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

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

　　服務(wù)架構(gòu)

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

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

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

　　SOA基礎(chǔ)結(jié)構(gòu)

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

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

　　SOAP， WSDL， UDDI

　　WSDL，UDDI和SOAP是SOA基礎(chǔ)的基礎(chǔ)部件。WSDL用來描述服務(wù)；UDDI用來注冊和查找服務(wù)；而SOAP，作為傳輸層，用來在消費者和服務(wù)提供者之間傳送消息。SOAP是Web服務(wù)的默認(rèn)機制，其他的技術(shù)為可以服務(wù)實現(xiàn)其他類型的綁定。一個消費者可以在UDDI注冊表（registry）查找服務(wù)，取得服務(wù)的WSDL描述，然后通過SOAP來調(diào)用服務(wù)。

　　WS-I Basic Profile

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

　　J2EE 和 .Net

　　盡管J2EE和。NET平臺是開發(fā)SOA應(yīng)用程序常用的平臺，但SOA不僅限于此。像J2EE這類平臺，不僅為開發(fā)者自然而然地參與到SOA中來提供了一個平臺，還通過他們內(nèi)在的特性，將可擴展性，可靠性，可用性以及性能引入了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中用來調(diào)用遠(yuǎn)程服務(wù)，這使得開發(fā)和部署可移植于標(biāo)準(zhǔn)J2EE容器的Web服務(wù)變得容易，與此同時，實現(xiàn)了跨平臺（如。NET）的服務(wù)互用。

　　服務(wù)品質(zhì)

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

　　安全

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

　　可靠

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

　　策略

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

　　控制

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

　　管理

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

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

　　SOA 不是Web服務(wù)

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

　　SOA的優(yōu)勢

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