所以，盡管分布式組件技術為構建SOA提供了明確支持，并且基于行業認可的標準，但上述兩個因素在企業層面上妨礙了重用的實現。注意，實際的情況還要更糟，因為要使用這些基于標準的技術，企業需要讓系統基于專用的中間件技術，比如MQ和TIBCO。所有這些系統，無論是基于標準的還是基于專用技術的，都應該被認為是企業的IT資產，因為在構建這些系統的過程中企業進行了大量的投資。這些現有系統中已經存在的功能必須被公開為可重用的服務，從而使用它們輕松構建新的系統。使用CORBA和J2EE的經驗告訴我們，引入另一組API或另一種傳輸協議無法解決這個問題。我們需要做的是對消息格式進行標準化，并使用已經在企業中普遍應用的傳輸協議，比如MQ和IIOP。在下一節中，您將會看到Web services是如何滿足這種需求的。
Web Services是救星？
Web services基于很多與Internet和Web相同的技術，它解決了分布式組件模型所具有的很多問題。我假定您已經對Web services有了一些基本的了解。對于想要快速入門的人，可以參考本文結尾處的參考資料部分。在這一節中，我將說明Web services是如何解決CROBA和J2EE之類的分布式組件模型的局限性的。
Web services使用HTTP作為其傳輸協議。HTTP已經被廣泛采用和認可，這不僅有助于增強互操作性，而且使用現有的基礎架構還可以提高操作效率。注意，Web services實際上是獨立于傳輸協議的，HTTP只是可以使用的傳輸協議中的一種而已�？梢詫eb services使用已經在企業中普遍應用的傳輸協議，比如MQ和IIOP。 XML的使用。Web services使用XML來描述接口和需要在服務及其消費者之間交換的消息�？梢允褂肳eb services描述語言（Web services Description Language，WSDL）來描述通向某個Web服務的接口。盡管從表面看來，WSDL類似于IDL或Java接口，但是WSDL的功能更為強大，并擁有支持服務松散耦合的構件。例如，WSDL支持多個類型系統，所以可以使用它來描述使用大型主機類型系統的服務。它還支持多種協議和傳輸方式，例如，可以指定某個特定的服務基于JMS而不是HTTP可用。最后，借助于WSDL，可以以一種抽象方式定義Web服務的操作性行為，然后在不同的網絡端點將其綁定到訪問它的特定方式。 承諾降低復雜性。分布式組件技術之所以復雜，原因之一就是它們規定了自己的編程模型，因此需要學習一組新的API。相比之下，Web services就沒有指定任何新的編程模型，您可以繼續使用您所熟悉的環境，包括J2EE或CORBA。這還意味著，可以選擇使用任何編程語言——C++、Java、Perl。Web services其實是一種接合和消息傳遞技術。從上面的討論中可以看出，Web services實際上解決了與分布式組件模型相關的許多問題。Web services最適用于部署SOA。
然而，我們尚未完全實現這一目標。前面我曾提到過，當討論與分布式組件模型相關的復雜性時，造成復雜性的主要原因是難于支持服務的整個生命周期，這不僅涉及到服務的構建，而且還涉及到對服務的部署、版本控制、保護和管理。我們還需要對服務的定義進行擴展，以便包容企業現有的資產，即使企業不是基于SOAP和WSDL之類的Web services技術。這包括在消息解決方案之外構建的集成，比如.NET、MQ Series、TIBCO和遺留及打包應用程序。為了支持真正的重用，我們需要打破企業中存在的屏障。我們還需要使這些服務的發現和使用更為輕松——這不僅涉及到程序員，而且還涉及到操作人員甚至是業務分析師。
服務基礎架構：新興解決方案
我們看到，行業基于共同的經驗教訓在繼續發展。上述討論不應該被理解為傳統技術在企業中沒有存在的位置或價值。我們仍然需要面向對象的編程語言，比如Java、分布式組件技術和消息傳遞系統，來構建新的系統。正如前面提到的那樣，問題在于通過把這些系統中的功能看作服務并支持利用這些服務創建新的復合應用程序，從而跨現有的技術筒倉來支持重用。盡管使用現有技術進行手動構建是可行的，但是這樣做既不輕松，也不經濟有效。就像我們使用J2EE作為構建應用程序的基礎架構一樣，我們也需要一個類似的基礎架構來組成、消費和管理企業中服務的生命周期。簡而言之，我們需要服務基礎架構（參見圖1）。這類服務基礎架構的本質特征應該包括：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
