????? 這個標準看來很早就有了，以前不知道怎么沒有注意到，現在補充學習一下。這東西跟前兩天見到的那個WSMX差不多?，SOA和Web Service目前看來，基本上是可以畫等號的。
??????? 一篇是BEA的開發者社區上的Bill寫的，一篇是IBM開發者社區上的方國偉寫的。
?????? SCA及未來的開發
?????? 2005年11月30日，BEA宣布，將與IBM、Oracle、SAP、Iona、Siebel和Sybase一起，支持一種構建和包裝應用程序的新規范，即Service Component Architecture(服務組件架構，SCA)。
什么是SCA?
SCA是一種規范，它使開發人員可以將注意力集中在業務邏輯的編寫上。更直接地說，它是一種大大改進了的部署描述符，它可以使用任何語言而不限于Java。此外，您還可以使用編程式語言和聲明式語言，比如BPEL和XSLT。SCA的特別之處在于，它對安全性、事務和可靠消息傳遞之類的特性使用了聲明式策略的理念。
使SCA脫穎而出的是，它是專門針對SOA設計的，而不像J2EE只是面向SOA做了修改。SCA關注的是如何描述按照各種編程模型和協議編寫的組件所組成的程序集。
SCA的目標與BEA的目標是一致的:使事情(這次是應用程序的構建)更容易。SCA允許開發應用程序集而不考慮特定的中間件API或具體語言。
SCA的核心概念是服務及其相關實現。服務由接口定義，而接口包含一組操作。服務實現可以引用其他服務，稱為引用。服務可以有一個或多個屬性，這些屬性是可以在外部配置的數據值。
SCA中的一個關鍵推動因素是Service Data Object(服務數據對象，SDO)。AquaLogic Data Services Platform一直在使用它。SDO用于表示業務數據、參數以及服務調用的返回值，當它遍歷服務網絡時，它還是一種表示數據的方式。注意，也可以使用XMLBeans及其它技術。
SCA組件被組成為程序集。程序集是服務級的應用程序，它是服務的集合，這些服務被連接在一起，并進行了正確的配置。SCA程序集運行在兩個級別:第一種情況，程序集是系統內的一組松散連接的組件;另一種情況，程序集是模塊內的一組松散連接的組件。二者的區別在于，一般來說，模塊是組件的集合，而系統是模塊的集合。此外，系統對應于“大規模編程”(programming in the large或megaprogramming)，而模塊對應于“小規模編程”(programming in the small)，比如構建當今的典型應用程序。相關例子以及更詳細的說明請參見Dev2Dev站點上的SCA白皮書。
將組件連接到它所依賴的服務的方式就是服務網絡“裝配”的方式。程序集已經在許多技術和框架中廣為應用，比如CORBA、J2EE、ATG Dynamo和Spring，也就是說，它并不是新出現的。從這些技術中我們可以知道，程序集提供了許多重要的優點，比如更輕松的迭代開發，以及避免使業務邏輯依賴于中間件容器。SCA使用程序集解決了許多SOA開發中的重要問題，包括:
-
業務邏輯與底層基礎架構、服務質量和傳輸的分離。
-
“小規模編程”與“大規模編程”的聯系。
-
為架構的設計、編碼和操作性部署在自底向上(bottom-up)和自頂向下(top-down)兩種方法中來回切換提供了一種統一的方式。
對BEA來說，它意味著什么?
SDO 2.0規范是整個SCA技術平臺的一個組成部分，它將在AquaLogic Data Services Platform (ALDSP)產品家族(已經支持SDO 1.0)的下一個主版本中實現。BEA AquaLogic Data Services Platform完全是針對SOA構建的，它自3.0版本開始就采用SCA技術。它提供企業數據服務的自動創建和維護，這可以幫助客戶獲得更高的生產力，進行業務優化，并更快地創造價值。BEA AquaLogic Data Services Platform提供了一個捕獲與數據訪問和數據更新有關的邏輯的單一位置。數據服務層提供了對相關的不同實時數據的可重用的、簡化了的訪問。注意，BEA Workshop中即將包含SCA支持。還有，BEA Workshop可免費下載。
為什么SCA如此重要?
SCA具有重大意義，因為它是第一項承諾提供一個組合模型以啟用服務網絡并支持構建下一代面向服務應用程序的技術。這一領域的每一次革新，都會導致出現一個新的抽象層，從而產生一批新的應用程序。C允許我們構建不能在匯編程序中構建的應用程序，而C++允許我們構建不能使用C構建的應用程序，Java又允許我們構建不能使用C++構建的應用程序。所有這些都是SCA的先例，簡單地說，SCA就是未來用于構建大規模企業組合應用程序的技術。
===============================================================================
SCA 編程模型入門
目前業界主要的軟件廠商都在大力推廣面向服務的架構(Service Oritented Architecture，SOA)的概念，但是對于很多客戶來說，SOA的概念還是顯得相對抽象的。為了使客戶能夠更加簡單的實現向這種面向服務架構的轉變，IBM在推出一系列WebSphere新產品的同時，提出了一種新的服務組件模型。這是一種全新的、跟語言無關的編程模型，它提供了一種統一的調用方式，從而使得客戶可以把不同的組件類型，比如POJO, EJB, 流程組件，人工交互組件等都可以通過一種標準的接口來封裝和調用。結合SDO的數據模型，這種服務組件的編程模型可以大大的簡化客戶的編程，提高應用的靈活性，這就是面向服務組件的架構(Service Component Architecture，SCA)。目前IBM 對SCA的支持是在最近推出的WebSphere Process Server(WPS)中，但是以后該服務組件模型將作為一個IBM軟件重要的編程模型被應用到底層平臺當中。本文將介紹SCA編程模型中的基本概念，并以一個簡單的例子來說明它的一些基本用法，期待能夠拋磚引玉，并為讀者以后深入了解SCA打下基礎。
1.1 SCA的起源
基于組件的編程一直是軟件業簡化編程和提高效率和質量的一個重要方法，但是往往對于不同語言我們有不同的組件模型，從而需要不同的調用方式。比如在J2EE技術領域，我們就有EJB，POJO，JDBC，JMS等，這對于開發人員來說是一個極大的挑戰。為了給這些不同的接口提供一個統一的調用方式，IBM提出了WSIF (Web Service Invocation Framework，具體請參考http://ws.apache.org/wsif/ )，并將它貢獻給Apache組織。WSIF作為Web Service領域的一個規范，提供了一種基于
Java
API統一調用各種服務的能力。但是WSIF沒有形成一個基于組件的架構模型，因此IBM在此基礎上推出了一個面向服務的組件模型(Service Oritented Architecture, SCA)。這個模型不但解決了統一調用的問題，還提出了一個基于組件的構建模型，并提供了許多面向企業計算的QoS能力。因此，從技術的角度來說，SCA是WSIF的延續和擴展。SCA的目的是使用戶在構建企業應用時有一個不再直接面對具體的技術細節的層次，而是通過服務組件的方式來構建應用。這種方式也使得客戶的企業應用具有良好的分層架構，能夠很好的分離應用的業務邏輯和IT邏輯，不但易于應用的構建，也易于應用的更改和部署。
1.2 SCA中的基本概念
服務組件模型(SCA)中提出了一些新的概念，比如服務組件，模塊，共享庫，導入和導出等。下面將分別解釋這些服務組件中的基本概念。
1.2.1 服務組件
服務組件是SCA中的基本組成元素和基本構建單位，也是我們具體實現業務邏輯的地方。我們可以把它看成是構建我們應用的積木。我們可以非常容易地把傳統的POJO，無狀態會話BEAN等包裝成SCA中的服務組件。 SCA服務組件的主要接口規范是基于WSDL(Web Service Description Language)的，另外為了給Java編程人員提供一個比較直接的接口，SCA的部分服務組件也提供了Java接口。因此，使用服務組件的客戶端可以選擇使用WSDL接口或Java接口。
服務組件提供給別的服務調用的入口叫Interface(接口)。而服務組件本身可能也需要調用別的服務，這個調用出口叫Reference(引用)。無論是接口還是引用，其調用規范都是WSDL或Java接口。SCA服務組件的接口模型請參考圖 1:
圖 1: SCA 服務組件接口模型
WebSphere Process Server 充分利用了SCA的這種組件架構，并在產品中提供了一些與業務聯系比較緊密的組件，比如業務流程，人工任務，業務狀態機，業務規則等。這樣用戶就可以直接利用這些服務組件，構建自己的業務流程或其它業務集成的應用。在WebSphere Process Server V6.0.1中，服務組件及SCA在架構中的作用如圖 2所示:
圖 2: WebSphere Process Server V6.0.1的架構環境
我們可以從圖 2 中看到服務組件架構在WebSphere Process Server中的基礎地位，也可以看到各種與業務相關的服務組件或技術相關的輔助服務組件的關系。關于WebSphere Process Server的體系架構這里不展開論述，具體請參考developerWorks專刊，2005年第三期的文章――WebSphere Process Srever V6體系結構概述。
SCA服務組件與傳統組件的主要區別在于:
1. 服務組件往往是粗粒度的，而傳統組件以細粒度居多。
2. 服務組件的接口是標準的，主要是WSDL接口，而傳統組件常以具體API形式出現。
3. 服務組件的實現與語言是無關的，而傳統組件常綁定某種特定的語言。
4. 服務組件可以通過組件容器提供QoS的服務，而傳統組件完全由程序代碼直接控制。
1.2.2 服務模塊(Module)
服務模塊(簡稱模塊)由一個或多個具有內在業務聯系的服務組件構成。把多少服務組件放在一個模塊中，或者把哪些服務組件放在一起主要取決于業務需求和部署上靈活性的要求。模塊是SCA中的運行單位，因為一個SCA模塊背后對應的是一個J2EE的企業應用項目。這里之所以說是"背后"，原因是我們在開發工具WID(WebSphere Integration Developer V6.0)中，通過業務集成透視圖看到都是SCA級別的元素。但是當你切換到J2EE透視圖你就會發現這些SCA元素與實際J2EE元素之間的對應關系。因此，在WID中構建一個模塊就相當于構建一個項目。另外，由于模塊是一個獨立部署的單元，這給應用的部署帶來很大的靈活性。比如，只要保持模塊接口不變，我們很容易通過重新部署新的模塊而替換原有的業務邏輯，而不影響應用的其它部分。
由于一個模塊中往往會包含多個服務組件，那我們如何來構建這些服務組件之間的相互調用關系呢?在WID工具中，我們只要簡單地通過接口與引用之間的連線，就可以指定它們之間的調用關系而不需要寫一行代碼。另外，我們可以在這些連線上面設定需要的QoS要求，比如事務，安全等。
1.2.3 導入(Import)和導出(Export)
用戶實際的應用經常是比較復雜的，因此實際的應用通常需要多個模塊才能滿足要求，而且這些模塊之間又往往存在相互調用的關系。
另外模塊中服務組件除了調用別的服務組件之外，也需要調用已有的一些應用，或者是讓一些已有的應用來調用模塊的服務，而這些應用可能不是基于SCA架構的。為了解決上述問題，在模塊中我們引入了兩個特殊的"端點"，一個是導入(Import)，它的作用是使得模塊中的服務組件可以調用模塊外部的服務。另一個是導出(Export)，它的作用是使得模塊外部的應用可以調用模塊中的服務組件。
由于涉及到模塊內外的調用，因此需要指定專門的綁定信息。這些綁定信息包括了目標服務或源服務的調用方式，位置信息，調用的方法等。目前，在WebSphere Process Server V6.0中，導入端點提供了四種綁定方式，包括:JMS綁定，Web Service綁定，SCA綁定和無狀態會話BEAN的綁定。導出端點提供了三種綁定方式，包括:JMS綁定，Web Service綁定和SCA綁定。對于SCA模塊之間的調用，我們可以非常方便的把綁定方式設置為SCA綁定，但是對于非SCA模塊與SCA模塊之間的調用我們只能選擇其它綁定方式。
1.2.4 共享庫(Library)
當我們在構建了多個模塊的時候，如果有一些資源可以在不同模塊之間共享，那么我們可以選擇創建一份可以在不同模塊之間進行共享的資源，而不是在不同模塊中重復創建。共享庫就是存放這些共享資源的地方。共享庫可以通過與模塊類似的方式在WID中創建，但是共享庫包含的內容只有:數據定義，接口定義，數據映射和關系。與模塊最大的區別使共享庫不包含服務組件，因此也就不包含業務邏輯。從包含的功能來看，我們可以把共享庫看作是模塊的一個子集。當一個模塊需要用到共享庫中的資源的時候，我們只需要使模塊依賴于共享庫即可。從部署的角度，一個共享庫會對應一個JAR包。在部署的時候，模塊所對應的J2EE企業應用會會自動包含所依賴的共享庫JAR包。這里特別要注意的是，這里的共享庫概念與WebSphere應用服務器中的共享庫不是一個概念，它們之間沒有任何聯系，因此不要混淆。
1.2.5 Standalone Reference
模塊中的服務組件是不能直接被外部Java代碼使用的，為了外部的Java代碼，比如JSP/Servlet使用模塊中的服務組件，WID工具在模塊中提供了一個特殊的端點，叫做Standalone Reference。這個端點只有引用(Reference)，而沒有接口(Interface)。只要把這個端點的引用連接到需要調用的服務組件的接口，外部的Java代碼通過這個引用的名稱來調用相應的服務組件了。具體如何調用請參考后面例子的實際代碼。
至此，與服務模塊相關的主要概念已大概介紹完了，它們之間的關系如圖 3 所示:
圖 3:服務模塊總覽圖
1.3 同步調用和異步調用
我們知道，常見的方法調用都是同步調用，這種調用方式是一種阻塞式的調用方式，即客戶端(主調用方)代碼一直阻塞等待直到被服務端(被調用方)返回為止。這種調用方式相對比較直觀，也是大部分編程語言直接支持的一種調用方式。但是，如果我們面對是基于粗粒度的服務組件，面對的是一些需要比較長時間才能有響應的應用場景，那么我們就需要一種非阻塞式調用方式，即異步調用方式。
SCA編程模式提供了三種方式的異步調用，它們分別是:
1. 單向調用方式。
2. 延遲響應方式。
3. 請求回調方式。
單向調用
單向調用方式是最為簡單的異步調用方式，在這種調用方式中，客戶端發出請求之后就不再關心服務端的情況，包括是否執行成功，返回值是什么等等。我們可以用下面的圖 4示來描述這種單向調用方式:
圖 4: 單向調用
單向調用方式是一種不管調用結果的方式，但是在很多情況下我們是需要知道調用結果的。我們需要知道調用是否成功，需要知道調用的結果，就算調用失敗我們也希望知道錯誤代碼等信息。在這種情況下，延遲響應和請求回調就是兩種能夠讓我們知道調用結果的方式。
延遲響應方式
延遲響應方式是指客戶端在發出調用請求之后繼續執行，但是經過一段時間之后，客戶端再調用相應的方法去檢索返回結果，并通過參數指定如何根據調用的結果而執行進一步動作。由于是異步調用方式，因此，在第一次發出調用請求的時候，服務端需要返回一個稱為票據(Ticket)的對象。這個對象會作為第二次發出檢索結果請求時的一個參數。顯然，這個Ticket對象的作用與WEB編程的SessionID非常類似。我們可以用圖 5 來表示延遲相應調用方式:
圖 5:延遲響應調用方式
請求回調
與延遲響應方式類似，請求回調方式也能得到服務端的響應，但是不同的是這個響應是由服務端通過回調方式來觸發的，而不像延遲響應方式由客戶端來主動檢索的。請求回調方式的原理與許多編程語言中的回調機制類似，不同的是這里實現的層次比較高一點。我們可以用圖6來表示請求調用方式:
圖 6:請求回調方式
1.4 SCA客戶端的兩種調用方式
從接口的角度，SCA的客戶端編程模型有兩種方式:
1. 靜態調用方式
2. 動態調用方式
靜態調用方式
靜態調用方式是一種類型安全的方式，也是在一般Java編程中最為常見的方式。所謂類型安全指的就是在編譯的時候就做類型的檢查，而不是等到運行的時候發現類型錯誤問題。說明示例如下:
在SCA客戶端編程中，靜態方式就是直接拿到實際實現的接口類型，也即直接拿到Java接口。
動態調用方式
與靜態調用方式相對，動態調用方式是一種非安全的方式。它的優點是調用非常靈活，但同時帶來的不利之處是部分問題在編譯的時候是發現不了的，只有等到運行的時候才能發現。說明示例如下:
像上面例子所示，在動態調用方式中，客戶端通過invoke方法的字符串參數的方式來指定具體要調用的方法名稱。很顯然，在這種方式下，如果方法名有誤是不能在編譯時發現的。
關于動態調用方式另外要注意的一點是，在這種調用方式下，所有參數傳遞都是通過DataObject的方式，即SDO的方式。哪怕實際參數只是一個字符串，也需要包裝成一個DataObject的方式。
接口類型與調用方式
實際上客戶端采用哪種調用方式是與接口類型有密切的關系。當提供的接口類型是WSDL類型的，那么客戶端的調用方式只能是動態調用方式。由于WSDL是SCA模型中主要的接口方式，這樣就導致動態調用方式在SCA編程模型中非常普遍。但是如果提供的接口類型時Java類型的，那么客戶端的調用方式可以是動態調用方式，也可以是靜態調用方式。
1.5 SCA的第一個例子――HelloWorld
與學習一種語言一樣，在初步了解一些基本概念之后，您是不是迫不及待的想自己動手寫點東西了?讓我們一起來寫一個"SCA版"的HelloWorld。我們需要的開發環境就是一個WebSphere Integration Developer V6.0(WID)，與IBM的許多其它的開發工具類似，這也是一個基于Eclipse 3.0的開發工具。下面簡單描述一下WID與IBM其它開發工具如Rational Application Developer(RAD)，Rational Software Architecture(RSA)，WebSphere Business Modeler等工具的區別。如果采用基于角色的開發方式，我們一般可以把集成項目的主要開發人員分為下面四大類:業務分析人員，集成開發人員，軟件架構師，J2EE/JAVA應用開發人員。他們的主要職責、技術要求和推薦使用的工具可以參見下表:
由上表可知，WID是一個主要針對集成開發人員的工具。除了專門的集成功能之外，WID工具也包含了RAD中的大部分功能。為了便于集成應用的測試，這個開發工具集成了一個測試環境，即WebSphere Process Server V6.0的運行環境。
這個例子的主要目的是幫助大家進一步理解前面描述的那些SCA基本概念。在HelloWorld應用模塊中，我們會構建一個用Java實現的SCA組件，其接口為HelloWorldInterface.wsdl，其實現代碼為HelloWorldImpl.java。為了使SCA模塊外部的JSP文件可以調用這個SCA組件，需要一個Standalone Reference。在模塊外部，我們構建一個index.jsp文件通過Standalone Reference來調用HelloWorld服務組件，并在頁面上把調用結果顯式出來。整個HelloWorld應用的基本圖示如下:
圖 7: HelloWorld 應用
1.5.1 構建的基本步驟
下面給出創建HelloWorld例子的基本步驟:
1. 創建模塊。打開WID，切換到Business Integration透視圖，新建一個模塊，名稱為HelloWorld。
2. 創建接口。通過點擊HelloWorld模塊左邊的"+"號展開，選擇"Interface"，然后通過右鍵創建一個接口，名稱為HelloWorldInterface。圖示如下:
HelloWorld接口包含一個sengMessage操作，輸入為一個名為message的字符串，輸出一個名為status的字符串。可以通過點擊接口編輯器上方的 按鈕來添加一個操作。通過 和 分別來添加輸入和輸出參數。圖示如下:
3. 創建服務組件。雙擊打開HelloWorld模塊的圖形化編輯器，然后在控制面板上把Java組件圖標 拖拉到編輯器中即生成一個Java服務組件，并把名稱改為HelloWorld。如下圖所示:
通過點擊 按鈕為HelloWorld組件選擇一個接口，即我們前面定義的HelloWorldInterface。
通過雙擊上圖中的HelloWorld組件，WID會自動生成HelloWorld組件實現類的基本框架HelloWorldImpl.java。如下圖所示:
上圖中高亮處顯示的代碼行就是我們可以給sendMessage方法添加業務代碼的地方。比如，我們可以輸入:return message + ". It's our first SCA example!";
4. 創建standalone reference。在工具欄中把 圖標拖拉到編輯器中即生成一個standalone reference。如下圖所示:
然后把Standalone Reference端點與HelloWorld組件連接起來。工具自動會為Standalone Reference創建一個匹配HelloWorld組件接口的引用。這里要注意的是，向導在自動創建Standalone Reference的引用時會彈出一個窗口詢問需要創建一個Java接口類型的引用還是WSDL接口類型的引用。不同類型的接口會使得我們的客戶端代碼(在本例中是一個名為index.jsp的JSP文件)需要采用不同的調用方式。下面會分析兩種不同類型的實現。
5. 生成JSP代碼。如果我們在前面的引用接口類型中選擇的是WSDL接口。那么Standalone Reference的屬性如下圖所示:
我們可以看到，引用的名稱為HelloWorldInterfacePartner，接口為名稱為HelloWorldInterface這個WSDL類型的接口。
如果我們在前面的引用接口類型中選擇的是Java接口。那么Standalone Reference的屬性如下圖所示:
我們可以看到，引用的名稱為HelloWorldInterfacePartner，接口為名稱為world.hello.hello.world.interface_.HelloWorldInterface這個Java類型的接口。具體JSP代碼參考下面的客戶端代碼分析部分。
6. 檢查生成的項目。如果把WID切換到J2EE透視圖的導航視圖中，我們可以看到與HelloWorld模塊對應的J2EE項目。J2EE企業項目為HelloWorldApp，其包含EJB項目HelloWorldEJB，Web項目HelloWorldWeb，J2EE客戶端項目HelloWorldEJBClient。另外一個是名為HelloWorld的Java項目，這個項目的內容最終會以一個JAR文件的形式被HelloWorldApp應用使用。上一步中所提到的JSP文件需要在HelloWorldWeb項目中生成。具體如下圖所示:
1.5.2 JSP客戶端代碼片斷分析
那么如何在JSP頁面中來調用我們的HelloWorld服務組件呢?按照前面的介紹，我們需要通過Standalone Reference來調用。那么我們如何才能得到這個Standalone Reference的引用呢?這里涉及到SCA編程模式中很重要的一個概念，那就是ServiceManager。ServiceManager是一個SCA環境的核心類，全名為com.ibm.websphere.sca.ServiceManager。這個類的作用主要就是能夠讓客戶端去定位一個服務提供方。一般調用的方式是通過ServiceManager的locateService(String serviceRefName)方法。拿到服務之后，客戶端就可以調用服務中所提供的方法了。(熟悉J2EE編程的人員可以聯系對比JNDI的Lookup方法。)下面分別根據Standalone Reference引用的接口類型來分析主要JSP代碼片斷。
當接口類型是WSDL接口的情況
1.首先需要在JSP中導入相關的類，主要如下:
<%@ page import="com.ibm.websphere.sca.ServiceManager" %>
<%@ page import="com.ibm.websphere.sca.Service" %>
<%@ page import="commonj.sdo.DataObject" %>]]>
2.生成ServiceManager對象，并拿到相應的服務。
ServiceManager serviceManager = new ServiceManager();
Service service = (Service) serviceManager.locateService("HelloWorldInterfacePartner");
這里locateService()方法中的參數是standalone reference的實際名稱。從某種程度上我們可以把外部的JSP/Servlet的Java代碼看成是Standalone reference的實現，這樣來理解服務組件之間的相互調用。
3.調用服務的方法。
String msg = request.getParameter("message");
DataObject resp = (DataObject) service.invoke("sendMessage",msg);
由于我們這里使用的是WSDL接口類型，因此返回結果是以DataObject的形式存在。
4. 顯式得到的結果。
<%=resp.getString("status")%>]]>
通過調用DataObject的getString方法，我們拿到實際的返回結果，名為status的字符串。
當接口類型是Java接口的情況
1.首先需要在JSP中導入相關的類，主要如下:
<%@ page import="com.ibm.websphere.sca.ServiceManager" %>
<%@ page import="com.ibm.websphere.sca.Service" %>
<%@ page import="world.hello.hello.world.interface_.HelloWorldInterface" %>]]>
2.生成ServiceManager對象，并拿到相應的服務。
ServiceManager serviceManager = new ServiceManager();
HelloWorldInterface service =
(HelloWorldInterface) serviceManager.locateService("HelloWorldInterfacePartner");
由于Standalone Reference的接口變成了Java接口，因此這里返回的服務可以直接造型成HelloWorldInterface類型。
3.調用服務的方法。
String msg = request.getParameter("message");
String resp = service.sendMessage(msg);
由于我們這里使用的是Java接口類型，因此調用的方式就是正常的Java接口調用。
4. 顯式得到的結果。
<%=resp%>]]>
由于靜態調用方式得到的就是實際定義的類型，因此這里字符串的顯式比較簡單。
具體實際項目的代碼請參考本文附的項目交換文件包。
1.6 結束語
本文介紹了SCA的主要目的和一些基本的概念，并展示了一個最為簡單的服務組件例子。從上面的討論我們可以看到，SCA不但解決了統一調用的問題，而且提供了一個服務組件架構。這個服務組件架構將在構建面向服務的架構中起到舉足輕重的作用，并在IBM的許多產品中會有所體現。
后記，在這篇文章完成之后，傳來了一個關于SCA的好消息。SCA得到了業界幾個主要軟件廠商的支持。IBM、Oracle、BEA、SAP、Siebel、Sybase、IONA等廠商聯合發布了SCA規范的0.9版本。具體規范可參見IBM DW的網址:http://www.ibm.com/developerworks/library/specification/ws-sca/