看到 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 與瀏覽器同在本地一樣。

     摘要: 當您自以為已經了解了所有開發工具時，肯定又會冒出一個新的工具。在本文中，developerWorks 的固定撰稿人 Rick Hightower 用一個真實世界的例子向您介紹兩個最激動人心的企業新技術。Hibernate是一個對象關系映射工具，而 Spring是一個 AOP 框架和 IOC 容器。Rick 介紹了如何結合這兩者，為企業應用程序構建一個事務持久層。 　　如果...  閱讀全文      java 的打印真是有點麻煩，本人最近在做一個銀行的項目，已經測試上線了! 銀行用的打印機一般用報表打印機針式打印機和套表打印機PS機。行里的老掉牙的打印機一大堆。結果，在一些機子上打印得好好的，在一些機子上打印卻問題不少。要么無法定義邊界或超出邊界。
    經過這次，總結點心得出來，本人采用兩種java打印API。

   1、