【文章內(nèi)容簡(jiǎn)介】 分類法（例如 North American Industry Classification System 和 Standard Industrial Classification）的行業(yè)類別； “ 綠頁(yè) ” 詳細(xì)介紹了訪問(wèn)服務(wù)的接口，以便用戶能夠編寫(xiě)應(yīng)用程序以使用 Web 服務(wù)。服務(wù)的定義是通過(guò)一個(gè)稱為類型模型（或 tModel）的 UDDI 文檔來(lái)完成的。多數(shù)情況下， tModel 包含一個(gè) WSDL 文件，用于說(shuō)明訪問(wèn) XML Web Service 的 SOAP 接口，但是 tModel 非常靈活，可以說(shuō)明幾乎所有類型的服務(wù)。 UDDI 目錄還包含若干種方法，可用于搜索構(gòu)建您的應(yīng)用程序所需的服務(wù)。例如，您可以搜索特定地理位置的服務(wù)提供商或者搜索特定的業(yè)務(wù)類型。之后， UDDI 目錄將提供信息、聯(lián)系方式、鏈接和技術(shù)數(shù)據(jù)，以便您確定能滿足需要的服務(wù)。 Web Service 技術(shù)背景 研究一下當(dāng)前的應(yīng)用程序開(kāi)發(fā)， 我們 發(fā)現(xiàn)一個(gè)絕對(duì)的傾向：人們開(kāi)始偏愛(ài)基于瀏覽器的瘦客戶應(yīng)用程序。這當(dāng)然不是因?yàn)槭菘蛻裟軌蛱峁└玫挠脩艚缑?，而是因?yàn)樗軌虮苊饣ㄔ谧烂鎽?yīng)用程序發(fā)布上 的高成本。發(fā)布桌面應(yīng)用程序成本很高，一半是因?yàn)閼?yīng)用程序安裝和配置的問(wèn)題，另一半是因?yàn)榭蛻艉头?wù)器之間通信的問(wèn)題。 關(guān)于客戶端與服務(wù)器的通信問(wèn)題，一個(gè)完美的解決方法是使用 HTTP 協(xié)議來(lái)通信。這是因?yàn)槿魏芜\(yùn)行 Web瀏覽器的機(jī)器都在使用 HTTP 協(xié)議。同時(shí)，當(dāng)前許多防火墻也配置為只允許 HTTP 連接。 許多商用程序還面臨另一個(gè)問(wèn)題，那就是與其他程序的互操作性。如果所有的應(yīng)用程序都是使用 COM或 .NET 語(yǔ)言寫(xiě)的，并且都運(yùn)行在 Windows 平臺(tái)上，那就天下太平了。然而，事實(shí)上大多數(shù)商業(yè)數(shù)據(jù)仍然在大型主機(jī)上以非關(guān)系文 件 (VSAM)的形式存放，并由 COBOL 語(yǔ)言編寫(xiě)的大型機(jī)程序訪問(wèn)。而且，目前還有很多商用程序繼續(xù)在使用 C++、 Java、 Visual Basic 和其他各種各樣的語(yǔ)言編寫(xiě)?，F(xiàn)在，除了最簡(jiǎn)單的程序之外，所有的應(yīng)用程序都需要與運(yùn)行在其他異構(gòu)平臺(tái)上的應(yīng)用程序集成并進(jìn)行數(shù)據(jù)交換。這樣的任務(wù)通常都是由特殊的方法，如文件傳輸和分析，消息隊(duì)列，還有僅適用于某些情況的的 API，如 IBM 的 高級(jí)程序到程序交流 (APPC)等來(lái)完成的。在以前，沒(méi)有一個(gè)應(yīng)用程序通信標(biāo)準(zhǔn)，是獨(dú)立于平臺(tái)、組建模型和編程語(yǔ)言的。因此只有通過(guò) Web Service，客戶端和服務(wù)器才能夠自由的用 HTTP 進(jìn)行通信，不論兩個(gè)程序的平臺(tái)和編程語(yǔ)言是什么。 Web Service 領(lǐng)域中另一件大事是 的成立， 是致力于為保證 Web Service 所承諾的互振作性而成立的一個(gè)組織，其主要的工作就是開(kāi)發(fā)保障 Web Service互操作性的相關(guān)規(guī)范，并進(jìn)行規(guī)范實(shí)施的測(cè)試。 ： Accenture、Bea、 HP、 Intel、 Microsoft、 Oracle、 SAP等， SUN 不在其中。 WebService 的現(xiàn)狀 目前，人們對(duì) Web 服務(wù)只有很少的直觀認(rèn)識(shí)和了解。 Web 服務(wù)領(lǐng)域還有待通過(guò)標(biāo)準(zhǔn)、應(yīng)用和準(zhǔn)確的定義進(jìn)行補(bǔ)充和完善，并且需要對(duì)部署 Web 服務(wù)所必需的組成部份的性能和成本進(jìn)行概述。 SUN J2EE 與 Microsoft .Net 是目前企業(yè) Web Service 平臺(tái)市場(chǎng)的兩個(gè)最重要的應(yīng)用框架（ Application Framework）。它們都為針對(duì)分布式 NTier 應(yīng)用的設(shè)計(jì)、集成、性能、 6 安全性和可靠性等諸多方面為用戶提供了總體的指南和規(guī)范，基于這些指南和規(guī)范，技術(shù)提供商提供了相應(yīng)的平臺(tái)、工具和編程環(huán)境。 盡管如 此， Web 服務(wù)作為一個(gè)重要的新市場(chǎng)，將不可避免地改變我們的商業(yè)交易方式。我們僅僅能對(duì)將來(lái)進(jìn)行估計(jì)，而無(wú)法給出確切的令人滿意的答案?；诠?yīng)商和最終用戶的一些跡象， Yankee Group 分析公司作出了以下幾個(gè)方面的評(píng)估 : Web 服務(wù)行業(yè)的現(xiàn)狀 普遍采用 Web 服務(wù)還需要至少 2年時(shí)間 與 Web 服務(wù)的產(chǎn)品相比較，有更多言過(guò)其實(shí)的廣告宣傳 大多數(shù)行動(dòng)都集中于對(duì)工具包和應(yīng)用程序進(jìn)行開(kāi)發(fā) IBM 和微軟的合作促進(jìn)了 Web 服務(wù)安全標(biāo)準(zhǔn)的發(fā)展 。由此可見(jiàn)，兩家公司都在市場(chǎng)開(kāi)發(fā)過(guò) 程中邁出了重要而積極的一步。 用戶要求 Web 服務(wù)中商業(yè)交易是正當(dāng)?shù)臓顟B(tài)或事實(shí)，有明確的 Web 服務(wù)使用說(shuō)明，并且能夠了解 Web 服務(wù)的成本架構(gòu)和配置指南。 設(shè)計(jì)需要解決的問(wèn)題 在設(shè)計(jì) Webservice 應(yīng)用時(shí)，以下幾點(diǎn)務(wù)必要考慮到： 管理好與外系統(tǒng)的協(xié)同關(guān)系 掌握底層的傳輸模型 提供與應(yīng)用相適應(yīng)的安全策略 計(jì)劃好部署的相關(guān)事項(xiàng) 以下，將就這幾條相關(guān)的設(shè)計(jì)需求和一些常用模式是如何應(yīng)用于 Webservice 模型展開(kāi)詳細(xì)討論。在討論中，你會(huì)發(fā)現(xiàn) Webservice 這項(xiàng)新的技術(shù)是如何與我們?cè)谝酝能浖_(kāi)發(fā)相結(jié)合的。 標(biāo)準(zhǔn)提供了協(xié)同的能力 Webservice 的一個(gè)最基本的目的就是提供在各個(gè)不同平臺(tái)的不同應(yīng)用系統(tǒng)的協(xié)同工作能力。 為了使得一個(gè)公司的網(wǎng)絡(luò)應(yīng)用達(dá)到最高的效率，存在它自己和它的合作伙伴，供應(yīng)商以及客戶之間的 Webservice，應(yīng)該能夠?qū)崿F(xiàn)無(wú)縫的交互。 如果在眾多的 Webservice 之間不能輕松的實(shí)現(xiàn)交互，那么該應(yīng)用的效率將大打折扣。但是，在現(xiàn)實(shí)中這種情況是極有可能出現(xiàn)的。由于各個(gè)公司對(duì)業(yè)務(wù)的 理 解各不相同，就是理解相同的情況下，對(duì)于相同的概念也可能用不同的形式加以表現(xiàn)，具體而言就是對(duì)于同一數(shù)據(jù)可能采取不同的 xml 表示。由于以上的原因， 對(duì)于協(xié)同性的問(wèn)題應(yīng)該在設(shè)計(jì)應(yīng)用架構(gòu)時(shí)就加以考慮，而不是留待以后去改變。 Webservice 主要由以下幾塊技術(shù)所構(gòu)成， SOAP (Simple Object Access Protocol), WSDL (Web service Description Language), 以及 UDDI (Universal Description, Discovery and Integration)。 WSDL 是實(shí)現(xiàn)協(xié)同能力的關(guān)鍵，它提供了一份契約用于與新老的應(yīng)用之間交互。這項(xiàng)技術(shù)使得各個(gè)組織可以將標(biāo)準(zhǔn)的制定集中在 Service 的外部 接口，而不用考慮各組織的具體實(shí)現(xiàn)。簡(jiǎn)而言之，它實(shí)現(xiàn)了 Webservice 的接口與實(shí)現(xiàn)的分離。從而使得標(biāo)準(zhǔn)的制定， 7 更加容易。并且，基于這份接口描 述，很多工具可以從中自動(dòng)生成客戶端代碼，減少了開(kāi)發(fā)者的工作量，并使得大部分開(kāi)發(fā)者擺脫了編寫(xiě) SOAP 消息傳遞代碼過(guò)程。 SOAP 是實(shí)現(xiàn)在各個(gè) Webservice 組件之間傳遞消息的傳輸層。因此， SOAP 應(yīng)該是 一項(xiàng)透明的協(xié)同技術(shù)。但是，由于很多的 SOAP 實(shí)現(xiàn) 方法卻與標(biāo)準(zhǔn)背道而馳，要么添加了新的擴(kuò)展功能要么刪減了一些標(biāo)準(zhǔn)功能。由于對(duì) SOAP 標(biāo)準(zhǔn)的支持程度不同，使得 Webservice的協(xié)同能力大打折 扣，實(shí)現(xiàn)協(xié)同的困難加大了?；谶@種情況，當(dāng)開(kāi)發(fā)者需要 Webservice運(yùn)行在不同平臺(tái)上時(shí)，就要對(duì)具體情況加以了解并相應(yīng)的編碼以解決這種不一致 性。如果所有的 SOAP 實(shí)現(xiàn)組織都能夠遵循標(biāo)準(zhǔn)的話，那么 Webservice 的開(kāi)發(fā)者就不需要考慮使用該 Webservice 的底層平臺(tái)了。 盡管如此，不同 SOAP 實(shí)現(xiàn)的協(xié)同還是相 當(dāng)困難，因?yàn)閰f(xié)同標(biāo)準(zhǔn)的制定存在大量的分歧，目前一些組織正致力于標(biāo)準(zhǔn)的制定，比如 SOAP Builders 和 WSI。然而，現(xiàn)在Webservice 開(kāi)發(fā)者只有針對(duì)不同平臺(tái)，給予不同的實(shí)現(xiàn)，使得開(kāi)發(fā)的成本和負(fù)擔(dān)加大了。 理解傳輸模型 SOAP 并不是完全透明的解決方案，它把一些復(fù)雜的實(shí)現(xiàn)細(xì)節(jié)隱藏起來(lái)。 Webservice的開(kāi)發(fā)者必須深入的了解 SOAP，了解底層的傳輸機(jī) 制以及模型 ,從而知道 SOAP 是如何實(shí)現(xiàn)的。在一些簡(jiǎn)單的應(yīng)用中，某些工具可以幫助 Webservice 的開(kāi)發(fā)者生成 SOAP 消息傳遞的代碼， 但是這只在 最簡(jiǎn)單的應(yīng)用中有效。真正的情況不可能那么簡(jiǎn)單，可能在某些方面你需要有特殊的處理（這種情況在實(shí)際開(kāi)發(fā)中是很常見(jiàn)的），這個(gè)時(shí)候，你就需要直接操縱 SOAP 的消息傳遞代碼，以及一些底層的 XML 內(nèi)容。因此， Webservice 的開(kāi)發(fā)者需要深入了解 SOAP 和 XML 層的內(nèi)容。 在開(kāi)發(fā) Webservice 的接口的時(shí)候，不要以為使用 XML 技術(shù)，協(xié)作性的問(wèn)題就迎刃而解了， XML 并不是解決集成問(wèn)題的靈丹妙藥。這里同樣 需要標(biāo)準(zhǔn)的制定，需要一個(gè)在業(yè)界公認(rèn)的詞匯表。僅僅在你的設(shè)計(jì)框架中引入 XML 技術(shù)并不能保證系統(tǒng)具有協(xié) 同性， XML 僅僅是用來(lái)描述數(shù)據(jù)的語(yǔ)言， XML 自 己并不提供語(yǔ)義去理解數(shù)據(jù)。就如同英語(yǔ)和德語(yǔ)都使用拉丁字母，但是他們的語(yǔ)義卻并不相同。 即使 使用相同的語(yǔ)言，也不能保證具有良好的協(xié)作性。比如你的公司可能使用 Order描述一個(gè)訂單，但你的合作伙伴可能使用 Purchase_Order，而另一個(gè)伙伴可能又不相同。你不可能強(qiáng)迫你所有的合作伙伴都采用和你相同的詞匯。因此需要有一項(xiàng)技術(shù)可以在眾多的描述之間 充當(dāng)翻譯的角色。 XSLT 就是這么一種技術(shù)，它用于不同語(yǔ)言的轉(zhuǎn)換。和 XSLT的配合使用 XML才能解決協(xié)同性的問(wèn)題。 DOM vs. SAX 許多的 Webservice 開(kāi)發(fā)環(huán)境，將開(kāi)發(fā)者從底層的 XML 文檔的解析和處理中解放出來(lái)，他們提供了自動(dòng)化或者很方便的工具，使得這一過(guò)程變 得很簡(jiǎn)單。但是對(duì)于一些有特殊要求的 Webservice 應(yīng)用，比如需要更好的柔性或者對(duì)速度要求特別高的應(yīng)用，就需要手工處理 XML文檔。這時(shí)候兩種 XML解析的模型－ DOM 和 SAX 的選擇，將成為重要的問(wèn)題。 DOM 使用樹(shù)狀圖的方式解析 XML 文檔，而 SAX 則更多的采用事件驅(qū)動(dòng)的模型。 DOM 先將 XML文檔映射成一顆樹(shù)，然后通過(guò)采用一系列與樹(shù)相關(guān)的操作 去處理這份文檔。這種方法有很多的好處，首先開(kāi)發(fā)者很容易理解，使用一顆 樹(shù)這對(duì)于開(kāi)發(fā)者來(lái)說(shuō)是最常見(jiàn)不過(guò)的了。 DOM 最常用于 XML 在 Service 中需要頻繁修改的場(chǎng)合。當(dāng)然 DOM 也有它的缺點(diǎn)，在處理 XML 文檔的時(shí)候，它 需要載入整個(gè)文檔，而不管你需要修改的是否只是其中的一小 8 部分。因此它的運(yùn)行效率以及對(duì)內(nèi)存的使用顯然是不能接受的，尤其是面對(duì)很大的 XML 文檔。 SAX 使用事件驅(qū)動(dòng)的模型來(lái)處理 XML 文檔。通過(guò)一系列事件的觸發(fā)，來(lái)完成對(duì) XML 的解析，你可以只關(guān)心你所要處理的事件，當(dāng)這些事件發(fā)生時(shí)， 會(huì)調(diào)用到相應(yīng)的回調(diào)函 數(shù)來(lái)通知到你。采用這種方式就可以在很大程度上提高 XML 文檔解析的效率。但是它的缺點(diǎn)在于難于使用，以及對(duì)同一文檔的多次處理會(huì)存 在一些問(wèn)題。 總而言之， DOM 更適合處理那種文檔型的 XML 文件，而 SAX 則適于那種想直接將 XML結(jié)構(gòu)映射成在你系統(tǒng)中的一個(gè)對(duì)象的操作。（比如將一個(gè) XML 結(jié)構(gòu)直接映射成 JAVA 中的一個(gè) Class）或者那種針對(duì) XML 文件中特殊 Tag 的操作。 文檔交換 vs. RPC 模型 這兩種交互方式應(yīng)該在應(yīng)用架構(gòu)的設(shè)計(jì)初始就應(yīng)該詳加考慮，因?yàn)樗鼘⒃诤艽蟪潭壬蠜Q定系統(tǒng)的耦合程度。 RPC（ Remote Procedure Call）本質(zhì)上就是遠(yuǎn)程方法的調(diào)用。盡管 Webservice 是基于 XML的但是你仍然可以使用遠(yuǎn)程方法調(diào)用這種模式來(lái)進(jìn)行 Webservice 的實(shí) 現(xiàn)，尤其是在那種簡(jiǎn)單的請(qǐng)求相應(yīng)的模型中。在這個(gè)過(guò)程中，傳輸中的 XML 文件所描述的更多是有關(guān)遠(yuǎn)程方法的信息，比如方法名，方法參數(shù)等等。 而文檔交換方式，與 RPC相比較在 XML 文件中不是做遠(yuǎn)程方法的映射，而是一份完整的自包含的業(yè)務(wù)文檔，當(dāng) Service 端收到這份文檔后，先 進(jìn)行預(yù)處理（比如詞匯的翻譯和映射），然后再構(gòu)造出返回消息。這個(gè)構(gòu)造返回消息 的過(guò)程中，往往不再是簡(jiǎn)簡(jiǎn)單單的一個(gè)方法調(diào)用，而是多個(gè)對(duì)象協(xié)同完成一個(gè)事 務(wù)的處理，再將結(jié)果返回。 這兩種方式的區(qū)別，類似與打電話和發(fā)郵件的不同處理方法。在目前，對(duì)于第一種方法提供了很多自動(dòng)化的工具使得遠(yuǎn)程方法的調(diào)用能夠很容易的完成，而后一種方法缺少一系列工具的支持，需要開(kāi)發(fā)者手工完成。 盡管如此，在此還是推薦使用文檔交換的方式。由于它在以下方面具有 RPC 所不具備的優(yōu)點(diǎn)。 使用文檔方式，你可以充分利用 XML 文件的功能去描述和驗(yàn)證一份業(yè)務(wù)文檔，而在 RPC模型中 XML僅僅被用于描述方法的信息。 使用文檔方式，在客 戶的 Service 的提供者之間不再需要緊密的約定，而 RPC 模型需要客戶和 Service 的提供者緊密相連，一旦方法發(fā)生變化，客戶端就需要做相應(yīng)的改動(dòng)。這不符合低耦合系統(tǒng)的要求，而在文檔交換方式中則靈活的多。 由于業(yè)務(wù)數(shù)據(jù)是自包含的，顯然文檔模型更利于采用異步處理。 利用設(shè)計(jì)模式 設(shè)計(jì)模式在設(shè)計(jì) Webservice 的時(shí)候顯然可以起到相當(dāng)大的作用。設(shè)計(jì)模式的主要目的就是為解決某些在類似環(huán)境下的相像問(wèn)題提供已有的較為成熟的設(shè)計(jì)方案。在這里，只簡(jiǎn)單的提及一些很常用的模式，讓我們了解到模式在 Webservice 中 可以起到的作用。 Adapter ：為內(nèi)部系統(tǒng)提