Web Services成熟之日，平價解決方案來臨之時
SOA的趨勢已確立
從1998年到現在，Web Services雖然只是發展才5年的技術，但已成為廣受各界矚目的明日之星。微軟於W3C（World Wide Web Consortium）提出Web Services的概念之初，並沒有受到廣大的回響，直到2001年由於IBM及其他業者陸續加入W3C共同制定標準，才逐漸受到重視。
為解決應用程式整合的問題，而興起的SOA（Service-Oriented Architecture；以服務為導向的架構）概念，是將龐大的應用系統轉化成各種服務，以提供應變的彈性，配合使用單位迅速調整商業模組。早在十幾年前已有CORBA、DCOM及J2EE等技術，實踐SOA的概念。
Web Services更是實現SOA的一項重要科技，BEA技術經理蕭百齡說：「資訊產業走向以SOA為主流的趨勢已經確立。」微軟、IBM、BEA、HP、Oracle及昇陽等大廠，無不致力於Web Services的開發。相較於過去的SOA技術，Web Services可降低串連異質系統的成本，以更平價的方式增加系統之間互動的解決方案。
初期許多不甚了解Web Services的資訊廠商，誤以為網站所提供的服務即為Web Services，便大張旗鼓地宣告有提供Web Services。微軟為釐清觀念，便在Web Services前面加註XML，而Java Web Services則是以Java實作Web Services，所以Web Services、XML Web Services及Java Web Services三者意義相同。Web Services的基本成員
Web Services主要由W3C制定的XML、SOAP、WSDL及OASIS制定的UDDI組成。
XML
過去異質系統傳輸資料多使用匯出匯入的方式，存在的隱憂是資料並不是以容易解讀的格式呈現，以致人員異動時後續的人員難以接手。XML（Extensible Markup Language）文件則藉由標籤（Tag）讓使用者及電腦均可輕易了解資料的意義，大幅簡化異質平臺資料交換的複雜性。標籤導向的XML類似HTML，但兩者目的不同。HTML是用以描述資料在瀏覽器中呈現的方式；XML則描述資料本身代表的意義。
XML 1.0版於1998定案，編碼格式分為RPC Style及Document Style兩種，RPC Style會清楚定義資料型態，可透過任何程式語言解讀WSDL，了解Web Services中傳遞的參數、資料型態及排列順序。而Document Style則是以純XML文件交換訊息，由於每個產業或企業本身均可能自行定義訊息交換的規格，因此開發工具不容易拆解格式自由的樹狀結構XML文件。許多人存疑.NET的Web Services與Java無法互通，事實上是因為微軟預設Web Services以Document Style編碼，所以其他工具解讀不易，若變更設定以RPC Style格式編碼即可互通。
過去XML以DTD（Document Type Description）驗證，不過DTD為標準SGML所使用的結構定義方式，由於源自於文件管理而非資料庫，所以對資料類型的支援較為不足，因此W3C便制定XML Schema，以彈性、可延伸的資料類型語法補DTD之不足。
DOM（Document Object Model）與SAX（Simple API for XML）則是兩種不同的解析XML的規格，DOM由W3C制定，將檔案載入記憶體，並分析XML的樹狀結構，所以可異動資料內容；SAX最初由David Meginson所發展，後來成為W3C的標準，以SAX解析XML文件，不需在記憶體中建立和維護XML的樹狀節點，因此可節省記憶體空間達到較好的效率。DOM與SAX的應用各有不同，DOM為雙向的機制，適合影音及資料庫的應用；SAX則屬於單向的機制，例如傳送電子郵件。目前瀏覽器及XML編輯工具都包含XML解析及驗證的工具，所以幾乎每臺電腦均可解讀XML文件。
SOAP
SOAP（Simple Object Access Protocol）是以XML為基礎的RPC（Remote Procedure Call）與訊息交換機制，雖然支援多種通訊協定，不過一般仍以HTTP為主。1998年SOAP制定初期，微軟扮演主要的推手，並在1999年底推出SOAP 1.0版。2000年5月IBM與其他業者加入W3C，參與制定SOAP 1.1的規格，這對Web Services而言是意義相當重大的里程碑。由於IBM也是Java及J2EE規格制定的重要成員，它的參與代表Web Services規格不再由微軟單一廠商主導。
WSDL
WSDL（Web Services Description Language）是描述Web Services的規格，Web Services潛在的使用者必須先取得WSDL檔，以獲得存取Web Services必要的資訊，包括Web Services內含的方法、接收的參數、資料格式、回傳的訊息、通訊協定及Web Services的位址等。WSDL是一份冗長的XML文件，其平臺與程式語言的中立性，讓開發工具及資訊人員可輕易拆解內容，取得呼叫Web Services時必要的項目，以撰寫程式碼。
UDDI
UDDI（Universal Description Discovery and Integration）可說是Web Services的黃皮書，提供Web Services服務的企業，可至UDDI伺服器註冊，提供Web Services相關的資訊，讓潛在的Web Services使用者可搜尋提供需要的服務的企業、了解服務的內容並取得進一步的資訊。
UDDI註冊包含公眾的、企業內部使用及具身分限制等類型，目前IBM及微軟等均提供開放的UDDI查詢服務，所有在開放性UDDI伺服器註冊的資料均會相互複製，因此Web Services只要在單一UDDI伺服器註冊，即可被所有公眾的UDDI伺服器查詢出來。企業內部使用的UDDI可能包含尚未轉換成Web Services的元件，作為內部可重複使用的元件的目錄。查詢具有身分限制的UDDI伺服器必須通過身分認證許可，才能查詢Web Services資訊，適合具合作關係的上下游廠商，以此方案取得透過Web Services互動的方法。標準化才能真正解決企業所面臨的困境
WS-I的出現解決了各說各話的亂象
整合異質系統以支援商業流程，長久以來一直是相當複雜、高成本且曠日費時的任務。根據ZapThink的調查，企業約有70%的資訊預算是用於解決整合的問題。為因應瞬息萬變的大環境，僵化的應用系統已無法提供即時地應變，因此企業面臨重大的挑戰，希望以經濟、有效率、易於管理且安全的方式，串連各種專屬系統。
Web Services即是新興的跨平臺技術，微軟開發工具暨平臺推廣處產品行銷經理許建志表示：「Web Services使網路應用不再受到瀏覽器的限制。」傳統網路的應用，使用者必須透過瀏覽器與電腦互動，Web Services則使各種異質平臺可自動化的溝通。
不過，Web Services普及的前提是必須標準化，才能真正的解決長久以來企業所面臨的整合問題。雖然W3C制定了SOAP、XML及WSDL等標準，但是文字描述存在模稜兩可的盲點，以致資訊廠商實作出來的產品不見得可以互通，使得以Web Services跨平臺互通的理想大打折扣。
由微軟、IBM、HP、BEA、Borland及昇陽等多家廠商組成的WS-I（Web Services Interoperability Organization），是Web Services相容性測試組織，目前最新推出的Web-I Basic Profile 1.0，明確規範XML Schema 1.0、SOAP 1.1、WSDL 1.1及UDDI 2.0等Web Services的基本規格。Porfile是實作Web Services的指導原則，釐清了Web Services規格中模稜兩可的部分，未來WS-I更將推出相容性測試的套件，檢驗資訊廠商實作的Web Services產品，是否確實遵循Profile的建議準則，以確保互通的承諾。
WS-I對於Web Services整合與推廣有絕對的貢獻，對企業而言，WS-I的Profile實現了降低整合成本及增加彈性的承諾，並減少導入Web Services失敗的風險。對提供Web Service解決方案的資訊廠商而言，Profile制定了遊戲規則可增加市場接受度，並簡化Web Services產品的複雜程度。Java與.NET各家廠商的努力
微軟是W3C及WS-I主要的成員，理所當然全力推廣Web Services，從伺服器端Windows Server 2003、SQL Server、Exchange Server及BizTalk等，到用戶端的Office、Visual Studio .NET甚至SmartPhone均全面支援Web Services。未來微軟並不考慮開發CORBA相關技術，將以Web Services為主軸，整合Windows平臺的產品，並以此作為與異質平臺溝通的橋樑。
BEA在WebLogic 8.1已將XML視為一等公民，並在WorkShop中提供相當簡單的Web Services開發工具。在Web Services規格的貢獻方面，BEA除了在JCP（Java Community Process）協助制定Web Services規格，更在WS-I中實際參與多項標準的制定。
在J2EE 1.4推出之前，昇陽提供Java Web Services Developer Pack，包括JAXP、JAXM、SAAJ、JAX-RPC、JAXR及JAXB等6項開發介面，供資訊廠商及使用者下載，並納入即將在年底推出的J2EE 1.4規格中。
Borland則在.NET及Java領域均有對等的產品，算是中立的角色。在2001年Borland全系列開發工具，無論Windows或Linux平臺的產品，已全數支援Web Services。Delphi 6是市場上第一個內建支援Web Services的產品，隨後推出的C++ Builder 6及Kylix 2.0也均內建Web Services規格的實作。而.NET方面，由於是微軟單一廠商主導，Borland就沒有貢獻心力的機會了。
在Java方面，Borland不但參與Apache AXIS Toolkit的實作，更實際參與JCP制定JSR 109 Implementing Enterprise Web Services、JSR 153 Enterprise JavaBeans 2.1、JSR 175 A Metadata Facility for Java Programming Language及JSR 181 Web Services Metadata for Java Platform等J2EE相關的Web Services規格。.NET與Java之間，仍存有良性的競爭
走過陣痛期，Web Services將蓬勃發展
微軟表示，從伺服器端到用戶端全系列產品均「內建」支援Web Services，所以執行效率較佳。Java陣營對於微軟支援Web Services的作法予以肯定，不過針對「內建」支援Web Services的說法，抱持不同的看法。
微軟憑藉自家作業系統的優勢，許多產品在開機時即順便啟動，並暫存於記憶體中，因此雖然開機時間較久但執行時效能較佳。其他必須「多掛」的非微軟產品，雖然首次執行的效能較吃虧，但暫存於記憶體之後，與微軟產品的效能相差無幾。
與作業系統緊密綑綁也有其致命的缺點，應用程式內建於系統的核心固然效能佳，但是只要程式設計有所疏失，一隻小臭蟲即可能導致電腦死當，出現微軟用戶難忘的「藍色死亡畫面」。針對關鍵性的應用系統，企業對安全性及穩定性的要求，往往遠勝於最新版本的追求與效能的期待，所以效能應不是吸引企業青睞的致勝關鍵。
不過Java陣營仍坦承.NET開發工具設計的相當方便，開發人員只要在程式中標註〔WebMethod〕即成為Web Services，而Java目前仍需藉由較複雜的操作流程才能完成。不過Java陣營也會見賢思齊，在JSR 181中已提出類似.NET簡單的規格，BEA WebLogic 8.1更預先實作了這個部分，只要在註解中加註「Operation」，元件即轉換為Web Services。
雖然.NET製作Web Services相當容易，不過BEA認為Visual Studio .NET雖可依據WSDL產生XML文件，卻不具調整的彈性。根據業界實際的案例，文件格式並非由單方面決定，多遵循業界標準或客戶的要求，所以應配合符合期待標準格式。WebLogic 8.1的Workshop己提供格式對應的工具，可依據標準調整欄位對應格式。工具是否具有彈性，提供鬆散的結合而非緊密的綑綁，將是SOA成敗的關鍵，可想見Visual Studio .NET的下一個版本，將可能推出類似的機制。由此看來，.NET與Java之間除了嚴苛的批判，仍有良性的競爭。
目前加入WS-I的廠商已超過170家，雖然Web Services仍是尚未成熟的技術，蕭百齡透露：「Web Services的發展會有陣痛期，但終將成為主流。」就像HTML剛興起之初，在安全性、效能各方面仍有許多不完備的地方，但絕對是一股銳不可當的勢力。
昇陽教育訓練中心技術顧問王森認為：「與以往在網路上傳輸，短小精幹的訊息相較，XML龐大的檔案內容，將成為妨礙Web Services發展的絆腳石。」不過，這些缺陷將隨著寬頻的興盛及電腦等級的不斷提升，而逐漸消弭於無形。Web Services簡單及方便的特性，將使這門技術推向應用的高峰。
Borland資深產品經理李匡正表示：「Web Services的出現，意味著平價時代的來臨。」過去雖然企業普遍都有EDI（Electronic Data Interchange；電子資料交換）的需求，但由於建置成本昂貴，只有大型企業可以負擔。隨著Web Services的興起，將使EDI普及到中小企業。
Web Services的出現將使B2B的應用有依循的標準，對於網際網路的內容提供者而言，過去僅能透過瀏覽器提供網頁內容，讓使用者以肉眼讀取；現在透過Web Services也有機會與應用程式結合，提供有用即時的資訊，更象徵新的商機。所以雖然Web Services仍處於技術成長期，但多數企業及廠商仍看好未來的市場。文⊙李延華
