轉載自 http://dev.yesky.com/216/7701216.shtml
隨着業務發展步伐的加快，要求企業對客戶需求要達到實時的反應。爲了達到這個目標，很多企業的IT部門已經採用了面向服務架構(SOA)。SOA可以幫助企業降低開發成本，降低項目失敗的風險，增加IT資產的重用，並且提高業務的敏捷性。
SOA是一種利用可重用的業務邏輯構建企業系統平臺的方式。這些業務邏輯是一些離散的功能，可以爲了實現不同的功能進行重用，開發人員可以通過調用和編排多個服務、事件和模型來創建複雜的應用程序，所以將這些業務邏輯組合起來可以成爲更高級的業務流程。
在SOA中使用服務註冊和倉庫有明顯的益處：
提高資產重用：資產重用可以增加企業IT基礎架構的靈活性，降低對整體化應用的依賴，這些應用是很難進行配置和重用的。
提高兼容性：目前很多企業對外部規則與內部業務指導方針的兼容級別缺乏有效的監控。然而，爲了實現SOA，把資產都進行註冊，SOA很容易的就可以讓管理員對現有資產的目錄進行準確的維護，收集度量和加強操作規範。
提高效率：Web Service可以增強編碼的標準，更容易的實現通訊並且在大型的、地理位置分散的企業中最大程度的減少重複的工作。
然而，很多SOA潛在的優點取決於實施方法。因爲SOA平臺由衆多的“服務”組成，這些服務可以配置成多種方式的交互，這個對IT機構選擇組件和機制來使服務的性能、效率和擴展性達到最優水平非常重要。
本文將講述服務註冊與發現的不同方法，服務管理的生命週期。這裏還要介紹兩種可能用到的配置SOA平臺的方法。在SOA中，服務註冊提高資產重用程度
因爲SOA是基於離散的可重用服務，比如WSDL服務描述、BEPL流程描述或者XSLT映射和遠遠超越整體化應用集成的擴展和分佈的組合。如果不能正確地管理和組織，情況會變得混亂。
通過創建集中的元數據註冊，企業可以使開發人員更容易的查找和重用已有的資產。服務註冊是服務接口在SOA中的索引。它實現一個對服務定義具體實現的鏈接的功能，但是並不必需包括定義本身。這個功能就像一個目錄，服務註冊必須提供向這個目錄中發佈新的服務的方法，並且要在目錄中瀏覽和搜索可重用的服務，還要作爲一種服務分類的機制使他們能與應用關聯。這些註冊可以防止重複的工作並且提高效率。UDDI是SOA註冊的Web Service標準。
服務倉庫，保存服務定義實現的的內容，比如Java代碼，BPEL流程，WSDL描述或者XSLT轉換。除了服務定義的內容之外，服務倉庫通常還保存元數據，比如服務(比如，XSLT映射調用BEPL業務流程)和版本管理機制之間的依賴關係。UDDI提供基於標準的Web Service索引
被用來定位、調用和管理服務的元數據，UDDI大概是三個Web Service核心標準中最不被瞭解的。同更爲人所知的WSDL和SOAP一起，UDDI使鬆耦合架構成爲可能，這也是SOA的主要特點(見圖1)。UDDI標準也描述了一套Web Service編程接口(API)用來在服務註冊中發佈、搜索、變更調用和複製。
圖1 UDDI作爲SOA實現的一部分
UDDI提供兩個主要功能：
位置獨立：與在應用程序中通過硬編碼調用它們的目標服務不同，UDDI提供了一種在運行時動態的查找和定位服務接口的機制。
分類法：UDDI支持基於服務類別和Web Service搜索引擎功能的分類。有着良好定義的服務分類可以幫助發佈比僅根據名稱查詢更好的結果。
基本的UDDI信息模型由一個包括四個數據類型的層組成：
1. businessEntity. UDDI信息模型的最高一級是businessEntity——比如，一家自行車修理店。
2. businessService.businessEntity可以包含很多businessService分類——比如，自行車商店可以提供很多維修服務，新自行車和齒輪。
3. bindingTemplate.bindingTemplate被businessService包含，bindingTemplate包括服務運作的技術信息。
4. tModels.這些技術模型是用來展現查找和鑑別服務的命名空間的UDDI結構，並且作爲一種描述服務調用信息的技術指紋。tModel是被bindTemplate引用的，而不是被包含的。一個tModel的例子是習慣分類中的叫做“repair chain”的服務。作爲一個技術指紋，tModel可能是一個WSDL規則用來描述服務和他的調用機制之間的接口。SOA的好處對系統配置的依賴
對SOA環境的配置有兩種可選的方式。第一種方式，服務的消費者和提供者以點到點(或者端到端)的方式直接通訊。在第二種方式中，在服務的消費者和提供者之間有一個服務中介人，比如企業服務總線(ESB)。TIBCO強烈建議中介方式，在這種方式中所有的服務請求和處理都通過ESB，這種方式比點到點的配置方式具有更好的靈活性，可擴展性和可靠性。
爲了理解直接通訊和中介通訊的區別，我們考慮一個現實中的例子。假設你自行車上的鏈條壞了，需要安裝一個新的。在這個例子中，服務就是“維修鏈條”——要訪問這個服務，需要打電話給自行車店。在直接查找的場景中，你可能需要查找電話黃頁，找到“自行車維修”目錄下的修理店，然後直接給修理店打電話要求服務。這個方法就是前面提到的點到點方式。你是服務消費者，自行車修理店是服務提供者，電話黃頁是告訴你如何請求服務的註冊庫。
然而，如果這個自行車修理店搬到了另一個地方並且更換了新的電話號碼，那電話黃頁上的信息就不在有用了。在SOA環境中也會有相同的問題，當一個服務提供者更改了服務的位置而沒有更新註冊庫，服務消費者就無法再訪問這個服務，直到註冊庫中的記錄被更新。即使這樣，也只有在消費者每次檢查電話黃頁並進行服務請求的時候纔會發現記錄被更新了。
在中介方式中，自行車修理店會有個800電話號碼，它可以轉到本地電話(即使電話號碼變更了)。在這個例子中，800電話就作爲ESB來保證服務消費者可以找到合適的服務，而不管他們的本地電話有沒有變化。因爲800電話變更的可能性很小，而且更容易記住這個虛擬號碼，就不用去頻繁的檢查電話黃頁了。
中間件提供最大限度的靈活性和優越性
爲了理解爲什麼服務總線對良好設計的SOA環境非常重要，必須首先理解這個環境的基本元素，如圖2。
圖2 SOA環境中的基本元素
1. 服務倉庫：元數據倉庫可以存儲、查詢和獲取任何類型的數據元素和對象，包括服務定義、策略、Schema、樣式表、命名空間、例子代碼和Billing信息。他們可以爲SOA環境中的其他組件提供安全參數、消息格式信息、授權技術、轉換信息、消息處理的規則和邏輯、設計和架構的信息、對象(比如，屬性、方法或者繼承數據)信息等等。
服務倉庫可以用來存儲各種角色，比如註冊權、提交機構和負責機構。通過支持模式分類，倉庫可以管理對象並且提供外部訂閱，同時，靈活多變的結合可以有利於加快影響分析。
由於服務倉庫做爲一個連接所有流程和數據庫的通用引用點，集成數據和方法就簡單得成爲找到他們的等價物並將他們結合在一起。因爲服務倉庫知道源系統和目的系統的數據模式，它也包括了從源系統到目的系統消息流的轉換信息。有時候這種信息轉換可以自動的通過語義映射進行生成，而不需要人工的干預。服務倉庫也可以通過跟蹤所有的資產和依賴來使IT管理變得更簡單。
2. 服務生產者.服務生產者創建服務——通過編碼或者配置來執行某種業務流程，比如信用鑑定——並且對服務註冊發佈這些服務的目錄信息。在SOA中進行重用意味着很多服務消費者共享同樣的服務實例。因爲當共享的服務停止或者移植到其他的地方，使用它的應用系統就會終止，這樣在服務提供者的實現和位置修改時，確保服務消費者不會終止就非常重要。
3. WSDL.服務提供者使用WSDL對服務註冊發佈服務接口描述。儘管WSDL文件包含服務對外開放的接口信息，但是它沒有包含開發人員可能會用到的所有的附加信息，尤其是在他們決定是否要使用這個服務的時候。比如，WSDL文檔沒有包含服務的定價數據或者服務什麼時候是可用的。新的標準，比如WS-Policy正在形成，可以用來描述比簡單的WSDL接口更豐富的服務信息，但是即使使用WS-Policy，每個服務的實現者還是有可能使用不同的方式進行服務屬性的描述。
4. 服務註冊.元數據註冊庫被設計用來管理公共元數據，這些元數據是存儲在不同類型的企業服務倉庫中的數據元素的子集。大多數的服務註冊庫是開發人員在開發時使用，在運行時並不進行查詢。服務註冊被設計用來與SOAP消息，對WSDL文檔的進行訪問授權，和定義的，與在目錄中列出的Web Service交互的其他的原數據共同工作。
在SOA環境中，服務註冊是基於UDDI標準的。UDDI服務註冊是開放的，基於XML的，平臺無關的，允許將業務展示在Internet上，並且爲與其它業務交互定義參數;或者企業內部的一個團體對其他的團體開發它的服務。
5. 服務消費者.一旦一個服被髮布到服務註冊庫中，服務消費者就可以通過瀏覽或者訂閱發現這個服務。在點對點的方式中，服務消費者需要通過SOAP向服務提供者發送一個運行時請求。然而，在ESB中，服務消費者調用ESB，ESB將請求路由給最合適的服務提供者。
6. SOAP請求. 在執行了一個服務查找之後，不論通過UDDI服務註冊的動態查找，還是通過中間件的代理，服務消費者都使用SOAP進行服務調用。這些請求通常都使用HTTP協議，也可能使用其他的消息協議。
ESB對於SOA環境的保持高性能，高擴展性和高可用性非常重要。作爲服務消費者和服務生產者之間的緩和劑，中間件作爲連接基礎架構和傳輸請求之間的每一個元素的信息總線。這種方式保證了在遺留系統上創建服務接口的可靠性，是他們能夠加入服務註冊庫而不需要硬編碼，使應用程序在調用一個服務時不需要再每次都進行服務查找，從而提高了性能。因爲在服務消費者和服務生產者之間不再使用直接連接，中間件也提高了平臺的安全性。
點對點方式降低性能、擴展性和可靠性
企業應用系統經常在非常複雜和不靈活的IT環境中運作，包括獨立的整體化的應用程序，點對點連接和硬編碼的接口。這種環境在業務需求變更的時候很難被修改。因爲這種原因，當SOA系統中沒有信息總線的時候，服務消費者通常將他們的服務終點進行硬編碼——這種方式就無法得到使用動態服務選擇的好處。這種方式在某種些時候可能會提高性能，但是它缺乏靈活性，不能允許在服務更改位置時不用停止流程。比如，當服務被移植到一臺新的服務器，應編碼的流程就會因爲找不到服務而運行失敗。
一些企業試圖採用動態服務查找來解決這個問題——這種方式可以減少代碼的維護量，但會使性能和擴展性下降。大多數企業都因爲各種原因而沒有去實現動態服務查找。安全方面的問題也顯現出來——企業通常不希望在沒有檢視代碼的情況下就很容易的相信一個服務。性能和擴展性也是個問題，如果服務代理選擇了一個很忙的服務，可能會造成重複調用並且降低整個網絡的性能。