原文：http://www.tibco.com/resources/solutions/soa/uddi_wp.pdf
概述 随着業務發展步伐的加快，要求企業對客戶需求要達到實時的反應。為了達到這個目标，很多企業的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系統中沒有資訊總線的時候，服務消費者通常将他們的服務終點進行寫死——這種方式就無法得到使用動态服務選擇的好處。這種方式在某種些時候可能會提高性能，但是它缺乏靈活性，不能允許在服務更改位置時不用停止流程。比如，當服務被移植到一台新的伺服器，應編碼的流程就會因為找不到服務而運作失敗。 一些企業試圖采用動态服務查找來解決這個問題——這種方式可以減少代碼的維護量，但會使性能和擴充性下降。大多數企業都因為各種原因而沒有去實作動态服務查找。安全方面的問題也顯現出來——企業通常不希望在沒有檢視代碼的情況下就很容易的相信一個服務。性能和擴充性也是個問題，如果服務代理選擇了一個很忙的服務，可能會造成重複調用并且降低整個網絡的性能。