在Eclipse->Help->Install new software
http://dist.springsource.com/release/TOOLS/update/3.9.4.RELEASE/e4.7/
SOA設計與應用
包包（人名）所在的Group從事的是為歐美航空公司量身打造客機管控平台的項目， 基於多方面考慮，整個Group采用了SOA的架構。他們沒有像IBM那樣設計一整套企業級服務總線，而是針對具體業務具體實現，來一個需求就暴露一個接口方法。其實，說白了，就是用JavaBean封裝企業邏輯，然后通過WebSevice的方式來暴露，只是.NET沒有JavaBean，而是用WF工作流來代替。
作為開發者，在拿到UseCase后，只要定制一下Request和Response消息中的實體，然后在類圖設計器中把契約、方法以及參數（Request）、返回值（Response）擺放並連接正確，右鍵點擊“生成代碼”菜單，就會基於SOA架構自動生成6個project。
SOA主要技術和標准，根據技術標准在SOA中的角色功能，將其分為三大類：服務層次上的信息交互規范、基礎通信標准規范、元數據標准規范。根據各種標准規范在SOA 體系中的角色功能，可以將 SOA 協議棧分為 7 層，如圖1所示。從底向上，包括傳輸層、消息層、描述層、管理層、服務組合層、表示層及服務發現注冊層，其中除了ebXML和電子商務相關的技術標准（如資源注冊的ebRS、消息表示ebMS、外部服務資源編排的WS-CDL等）外，大多數在國內已經得到了相當的應用，如東方通科技的應用集成產品TongIntegrator和應用服務器TongWeb，都支持部分Web服務的相關技術標准，如傳輸層的SOAP、RMI、SMTP，消息層的SOAP、JMS以及描述層的WSDL協議等。
1）W3C 組織提出的標准的Web服務描述語言WSDL，它從句法層面對Web服務的功能進行描述，包括4個不同的粒度：數據類型（Data type）、消息（Message）、方法（Operation）和訪問端口（PortType）。這只是提供了Web服務的接口描述，對服務的行為約束和屬性描述缺乏進一步的支持。
2）OWL-S是語義Web服務標記語言的標准，它比WSDL更能向用戶提供可理解的服務資源的描述形式，提高服務選取與推薦的准確性。語義Web服務的主要方法是利用Ontology來描述Web服務，然后通過這些帶有語義信息的描述實現Web服務來實現服務的自動發現，調用和組合。語義Web和Web 服務是語義Web服務的兩大支撐技術。OWL-S是連接兩大技術的橋梁，目前對語義Web服務標記語言研究最重要的組織就是DARPA組織，其研究組 OWL Services Coalition提出了語義Web服務標記語言OWL-S（原DAML-S）。
3）XML Web服務和ebXML都使用SOAP 作為消息傳輸技術，但是XML Web服務服務定義了松散耦合的協議堆棧，該堆棧由可靠傳輸 (WS-Reliability) 和 安全 (WS-Security) 的各個規范組成，而ebXML將所有這些功能都融入到自己的消息傳遞標准和ebMS中，從而使用混合技術。
XML Web服務分別使用WSDL和UDDI標准，UDDI注冊機制是基於目錄的體系結構，其注冊內容包括技術模型和業務模型，本身可擴展但目前其注冊的內容和描述還不夠豐富和完整。
而 ebXML將服務描述和發現機制對應兩個標准，一是注冊信息模型ebRIM，二是注冊服務規范ebRS。ebXML注冊機制要比UDDI豐富和完善的多，它的注冊機制用途廣泛，可以表示范圍廣泛的數據對象，包括 xml 模式、業務流程描述、ebXML Core Component、UML模型、一般貿易合作伙伴信息及軟件組件。
4）SCA（Service Component Architecture），即服務組件架構，提供了一種編程模型，可以支持基於SOA的應用程序實現。SCA是一種模型，可以支持實現服務組件的各種技術，連接服務組件的各種存取方法。對於組件，不僅包括不同的編程語言，也包括這些語言使用的框架和環境。對於存取方法SCA合成操作支持各種通訊、服務存取技術，如：WS、MQ、RPC。SCA規范包括了Assemble Model和Client Model兩部分。前者約定了如何將異種組件（Java類，BPEL，Web Service）組裝並發布成SOA服務，是SCA最大的特點和最核心的概念；后者則約定了如何在異種語言環境中調用SOA服務。通過這兩部分的規范，就可以完全解決了服務從服務端到客戶端的跨語言、跨環境的問題。
5）JBI 是Java商業集成（Java Business Integration）的簡稱。這個標准定義了一個標准的體系結構允許第三方的組件插入到標准的基礎設施上，並且即使這些組件是有不同提供商提供的，它們也可以以一種可預見的和可靠的方式互操作。從高層次上看，JBI 定義了可以從可插入組件構建集成系統的體系結構，這一結構中組件的交互使用一種經過中介的消息交換機制，而這一消息交換模式是基於WSDL 2.0或WSDL 1.1的。
6）WS4BPEL，即Web服務業務流程執行語言，它是一種可執行語言，能夠與各種促使業務流程自動化的軟件系統相兼容。
7）WS-CDL，即Web Services Choreography Definition Language，Web服務編排定義語言，它定義為在多個交易伙伴之間建立形式化關系，它不要求所有被集成的端點（endpoints）都有Web服務基礎設施。
8）JSR168 是java 規范要求，它為創建portlet建立標准的api，它是為實現porltet、基於java的門戶服務器和其他web應用程序之間的互操作性而設計的。 JSR168的主要價值在於它被獨立軟件開發商（isv）所廣泛采用。在采用JSR168之前，企業應用程序開發商不得不支持所有開發商門戶的不同 portlet集，支持多個門戶開發商不同的portlet集在類似業務信息、內容管理、檢索和分析這樣的領域中非常令人頭疼。使用JST168規范，現在開發商只需要支持一種portlet集。
9）WSRP，即Web Services for Remote Portlets的縮寫，它定義了如何利用基於 SOAP 的 Web 服務在門戶應用程序中生成標記片斷的規范。通過定義一組公共接口，WSRP 允許門戶在它們的頁面中顯示遠程運行的 portlet，而不需要門戶開發人員進行任何編程。對於最終用戶，這些 porlet 就和運行在他們本地的門戶上一樣，但是實際上這些 portlet 來自於遠程運行的 portlet 容器，並且交互是通過SOAP 消息的交換來實現的。
包包對比SOA中技術和標准，發現應用於其項目中的一些問題。
1）雖然大多數SOA系統要求平台兼容，但實際應用中卻發現做來做去竟然全都是.NET平台，而極少甚至是沒有Java平台。這時候發現數組和集合的轉來轉去是白做了，性能受到很大影響。這種情況其實也是有解決方案的，就是先全都做成.NET平台的集合，然后哪些方法需要暴露給J2EE使用，再包一層面向數組的WebService。
2）寫WebService的人可能和你不是一個Team的，他不可能修改他的project來滿足你的額外要求，或者，這個WebService是用Java寫的……沒轍了么？還有最后一招，就是自己再寫一層WebService，並添加這個異步文件，並在其中調用原有的WebService，然后Silverlight再調用自己寫的這個WebService。
3）2中的例子，原先要部署一個Service，變成了要部署兩個Service。就是說，要在ReleaseNotes里面添加這一筆配置信息。如果這個Service被部署在其他Server上，那么就要准備好幾份ReleaseNotes。要知道，部屬的事情不一定是開發這套code的人去做的，所以WebService的多少和出錯的幾率是成正比的。
4）SOA中部署的復雜，導致了一旦其中有一個環節出錯，就摸不着頭腦找不到是那一層的問題。於是要添加異常處理機制，把異常從底層到高層逐層往上冒。所以，對於一個Service方法，返回的不是成功執行后得到的string或int，而是一個object數組。第一個參數表示成功與否，如果是否，那么第二個參數就要傳遞捕獲到的異常信息。