M
mis_hid
Unregistered / Unconfirmed
GUEST, unregistred user!
[轉自 www.javatwo.net ] [ QQ:52128393]
J2EE vs. Microsoft.NET
I. 序
在本文中，我們將深入的比較兩種可用來建置商業XML Web Services的平台，分別是Sun Microsystems 所提供的Java 2 Enterprise Edition (J2EE)以及Microsoft所提供的 Microsoft.NET平台。雖然J2EE代表的是一個公開的標準，而 .NET是單獨一家廠商的標準(雖然.NET試圖取得ECMA的標準，但是卻只有在最基礎的部分被ECMA採納變成標準，請參考http://msdn.microsoft.com/net/ecma/ ，在企業的應用上確卻沒有標準化)，反觀Java平台，確是所有除了Microsoft以外的各大廠商都遵循著JCP的標準制定所有規格(請參考http://www.jcp.org ，您會發現所有的Java技術都是協調各大公司而來)。儘管在標準化上Java遙遙領先，但我們仍然將只針對伺服器端的Web Services架構做探討。例如：我們的討論將不涉及 JINI 或是Office XP，我們也不會討論Java跨足Solaris、Linux、Mac OS X、以及Windows平台，而.NET只跨Windows 98/ME/2000/XP等Windows平台的事實。我們更不會討論 ”跨語言” 這個Java早已試圖達成，Microsoft又拿來當成.NET的重大特點，卻根本不是這回事的功能。
(請參閱http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html，大家可以發現Java早就達到所謂跨語言的功能，Smalltalk、Eiffel、Lisp、Prolog、BASIC等語言都可以順利轉換成Java bytecode，不像.NET號稱跨語言，卻出現COBOL.NET這種怪物，原本的語言要削足適履來配合.NET，所以才產生VB.NET、COBOL.NET這一大串東西)。在讀完本文之後，您將會更加了解這兩種架構的彼此優缺點，而且在制定貴公司下一代Web Services決策時將有更明確的考量。
 
II. 前言
下一代的分散式運算時代已經來臨了。在過去幾年中，XML 被廣泛的運用於電腦運算環境中，以達到在全球資訊網上共享資訊的遠大目標。如今，它可以更進一步地提供運算能力上的分享。從技術的觀點來看，Web Services的出現並不能算是分散式電腦運算的新革命。它可以結構化的呈現資訊，甚至是程式內部的訊息，因而很自然地比XML應用程式更加引人注目。
 
III. 工業標準與企業標準
透過Web Services，任何應用程式可以在網路上順利地整合在一起。Web Services的基本原理是利用標準的網路協定(例如：HTTP)來傳送XML訊息。這是一種非常輕便的溝通機制，因此可以讓任何程式語言、中間層元件或平台很輕易地整合進來。一般工業上或企業內部會接受成熟且廣為廠商採用的業界標準，更尤其是已經受過市場考驗行之有年的標準。有了Web Services，您就可以快速且低成本的整合兩個企業、部門或甚至是兩個程式。
 
要建置Web Services必須得採用業界通用的Web Services技術。現在讓我們來看看Web Services究竟是什麼。首先您必須先知道如何建置以及使用Web Services。其實Web Services是種很簡單的XML界面，適用於商業、應用程式以及系統服務。說穿了也就是將既有的技術舊衣新穿而已。Web Services其實是一種新一代的分散式服務，在這之前，有CORBA、DCOM、COM+、RMI，都是用來實作分散式架構的技術，而且也被證明運作的非常順利；而新一代的分散式服務，採用的是XML技術，如XML-RPC和SOAP就是最佳的例子，新一代的分散式技術可以用寄有的通訊協定做基礎(如SMTP、FTP等)，但是目前最後最受歡迎的方式仍然是將XML基植於HTTP這個廣受歡迎，但是效能並非最佳的通訊協定上。即使如此，這些新一代的技術尚未通過時間的考驗，或許他們有可能運作的得很成功，也可能有些許的風險存在。
 
面對這麼多的分散式技術，J2EE平台與.NET平台的支援程度如下表:
 
對就有分散式技術的支援:
 
J2EE
.NET
CORBA
支援
不支援
RMI/IIOP
支援
不支援
COM+
不支援
支援
 
對新一代Web Services的支援:
 
J2EE
.NET
XML-RPC
支援
不支援
SOAP
支援
支援
 
從上述兩個圖表之中我們可以得知，對於姿態保守的公司而言，J2EE支援了較為廣泛應用於現有企業系統的分散式運算服務，而.NET平台仍然只支援延伸自COM與DCOM的COM+，其技術前身MTS COM+比Enterprise Java BeanJavaBeans技術早了三年，不消說，我們可以推斷J2EE提供的分散式服務比.NET的技術領先三年。此外，目前企業內部使用之大型主機所使用的皆為CORBA技術，J2EE對舊有技術的支援能當然是最佳的，因為COM+只能在Windows平台上運行。
 
如果是態度前衛的公司，使用J2EE者可以選用XML-RPC(http://java.sun.com/xml/jaxrpc/index.html)或是SOAP(http://java.sun.com/xml/jaxm/index.html)技術，Sun Microsystems更提供了Java Web Service Developer Pack(http://java.sun.com/webservices/webservicespack.html)供開發者開發Web Services。反觀.NET技術，只提供對於SOAP的支援。在對於既有分散式技術支援不足的情況下，對新一代分散式技術的支援又無法提供彈性的選擇，風險之大，是可以預估的。
 
  
就算新一代的Web Services非常穩定好了，他的穩定度常常會被底層作業系統的穩定度所影響，如果你選用.NET，就會被綁死在公認最不穩定的Windows平台上，更糟糕的是，.NET還只能在Microsoft官方的網頁伺服器上運作，相信之前使用IIS的朋友，在遭受過Nimda等不斷出現的病毒的惡夢之後，會不會對其安全性與穩定性產生質疑? 但是，如果您選用的是J2EE技術，那麼在諸多遵循標準的廠商所提供的應用程式伺服器中，您可以選擇最符合您需要，成本最低，而且又認為最佳的平台。
 
您可以到http://www.soapware.org/directory/4/implementations查詢既有的SOAP實作品，看看有多少是針對Java所設計的實作品，如下圖所示:
 
 
總而言之，我們就平台的穩定性，伺服器的穩定性，以及產品的多樣性這三方面來考量，J2EE徹底擊敗.NET技術。
 
下列的技術都是已為業界所採用，而且也是通往Web Services的最佳途徑：
‧
提供Web Services的人員使用自己的程式語言、元件與平台來開發、連接與佈署Web Services。
‧
提供Web Services的人員以WSDL (Web Services Description Language)定義Web Services。WSDL文件可以讓其他人知道Web Services的功用。
‧
提供Web Services的人員以UDDI (Universal Description, Discovery, and
  
Integration6)將Web Services註冊。 UDDI讓程式開發人員可以佈署Web Services，同時也可以搜尋他人所提供的服務。
‧
使用者透過UDDI登錄來找尋Web Services。
‧
使用者的程式會結合Web Services，並透過SOAP (Simple Object Access Protoco)或XML-RPC來呼叫Web Services。XML-RPC或SOAP 在HTTP協定上提供一份XML格式的訊息傳遞。這是所有Web Services共同的溝通協定。
 
請注意，上述的機制是建置Web Services並讓它運作的一種途徑。雖然有其他方法可以做到，但我們認為這些技術是最重要且將廣為業界採用的一種。
由此可知，實際上我們尚未有一致的方式來建置Web Services，建構上仍然有許多的困難需要克服。以SOAP、ebXML以及服務串流的規格來說，眾家廠商意見各異了。而且SOAP最常被宣傳的: 與程式語言無關，與特定平台無關這兩項特點，會在您嚐試著使用Apache SOAP與Microsoft SOAP Toolkit產生的Web Services進行溝通時，徹底地粉碎(譯注:這是因為xsi:type屬性在實作上有分歧的關係)。除了是對於實作上細節的理解有差異之外，更重要的原因是因為有人刻意地破壞標準。
 
即使如此，對於Web Services來說，仍然有不少好消息：
‧
很難得的，所有的廠商，包括Sun Microsystems與Microsoft等大廠，均同意SOAP、 WSDL以及UDDI 是有潛力的好產品，因此他們將在未來的產品中進一步提供這些技術的支援。
‧
所有意見不一的廠商都團結在一起，共同為建立Web Services的標準並廣植Web Services的應用而努力。
 
IV. 使用J2EE 以及Microsoft.NET來開發Web Services
 
如果您想開發一個有用的網路服系統。所面臨的挑戰並非表面上所看如此簡單。您的Web Services必須可靠、普及、不容易出錯、有彈性而且必須讓大家願意接受。這些嚴格的要求並不亞於任何企業等級的商業應用程式。
J2EE 以及 .NET 是現有用來開發伺服器端企業級應用程式的技術延伸。這些技術的早期版本並非專門用來開發Web Services用。如今Web Services已經成為趨勢，於是兩大陣營也隨之調整各自平台的解決方案，因此您現在已經可以使用這些技術來開發Web Services了。J2EE 以及 .NET的共通願景就是希望能達成開發Web Services的基礎工程，例如：跨平台的XML溝通、負載平衡以及交易。與其自己重新撰寫這些基礎工程，倒不如在可提供這些服務的平台上撰寫應用程式。
但是，當開發到一定規模的應用程式時，會產生一定的複雜度，這個時候就必須有開發工具的輔助，如果您選用了其中一種平台，那麼您可以選用的工具如下表所示:
開發新一代Web Services的開發工具:
平台
工具
J2EE
JBuilder (Borland)
Forte for Java (Sun)
WebLogic Workshop (BEA)
JDeveloper (Oracle)
Visual Age for Java (IBM)
Visual Café (WebGain)
.NET
只有Visual Stdio.NET
 
從這裡可以看出，您可以在您既有的企業解決方案提供廠商那邊，取得最佳的工具和解決方案，而且從免費的基本版本到付費的專業版本都有，各人可以根據不同的需求來做最佳的選擇，而不是只能尋求單一廠商所提供的工具和解決方案。
 
V.  J2EE
Java 2 Platform, Enterprise Edition (J2EE) 被設計成專門用來解決多層式企業解決方案的開發、佈署以及管理上的問題。在Sun Microsystems 所帶領的諸多廠商的努力之下，J2EE 已經成為一種業界標準。對您而言，最重要的一點就是，您必須先了解J2EE是一種標準，而非一種產品。您不能說”下載”J2EE，而是下載一系列的Adobe Acrobat PDF 檔案，這些檔案會仔細說明應用程式與所在容器(Container)之間的運作規定。透過遵守J2EE的規定，應用程式可以被部署在各種平台上的容器中。J2EE陣營的目標是提供客戶有多重選擇產品與工具的機會，並以此帶動良幣驅逐劣幣的效應，讓最好的產品成為市場上的贏家。要達成此理想的唯一的方法就是所有的廠商都要符合J2EE標準。
 
在交易安全方面，Sun Microsystems更與許多提供電子商務平台的廠商合作，例如：BEA、IBM以及Oracle等，共同制定J2EE。Sun Microsystems更發起一個Java標準制定組織Java Community Process (JCP)，專門隨時構思新決策來改善J2EE。 Sun Microsystems之所以這樣作的理由是因為，要達到電子交易安全最好的方法，就是要請所有的專家共同來制定嚴格的規範--唯有這樣的作法才能成功地達成他們整合市場的目標。J2EE 是一種Java的應用。您的J2EE 元件必須被轉譯成bytecode並在Java的執行引擎下執行JRE。值得一提的是，即使是相容於J2EE平台的容器，大多數都是以Java技術實作而成的。相較於Microsoft.NET在正式發行沒多久時間就因為安全上的錯誤而發表Service Pack1來說 (詳見http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q317396&sd=msdn&，使用.NET卻還沒有去下載的朋友請趕緊連上去看看，以免惡夢重現) ，
我們應該更了解一件事，就是:安全性是大家的事，決不是單一廠商就能決定的。
 
VI. J2EE 以及Web Services。
J2EE 在以往的Java程式語言中被定位成開發伺服端應用程式的架構。它可以被用來建置傳統的網站，軟體元件或是Web應用程式(Web Application)。到了最近，J2EE更被擴充成可支援XML Web Services的標準。這些Web Services可以和其他用J2EE或非J2EE標準所開發的Web Services溝通。J2EE Web Services的開發模型如圖表1所顯示
 
 
圖表1的內容概述如下：
J2EE應用程式存在於一個容器之中，這個容器提供企業級應用程式所需的服務，當然也具有企業所需要的品質，例如：交易、安全以及Persistence services。商業層級負責商業程式與資料邏輯。在大型規模的J2EE應用程式中，商業邏輯是利用Enterprise JavaBeans (EJB) 元件技術所建置。由此可知，這個層級專門用來負責商業程式以及資料邏輯的處理。它可以透過Java Database Connectivity (JDBC)、SQL/J來連接資料庫，或是透過Java Connector Architecture (JCA)技術來連結既有系統。它更可以利用Java用來處理XML的API (JAXP， Java API for XML Processing)，並透過Web Services技術(包括：SOAP、UDDI、 WSDL以及ebXML)來連接其他協力廠商所提供的商業應用程式。因此協力廠商們可以透過Web Services技術(包括：SOAP、UDDI、 WSDL以及ebXML)讓J2EE程式彼此連接起來。所以只要利用Java Servlets (這是一種支援HTTP請求/回應的Java技術)就可以從協力廠商的Web Services中接受請求了，並予以回應。Java Servlets使用JAXP/JAXR/JAXM/JAX-RPC等技術來提供Web Services運作時的所有功能。Web Services目前是擴充程式庫的型態存在，目前已經著手將Web Services併入J2EE下一版的規格之中，並成為業界共通的標準。傳統的客戶端程式，例如Java Applet或桌面應用程式，將直接以Internet Inter-ORB Protocol (IIOP)來連接EJB元件而非透露Web Services，如果要使用Web Services也可，但是因為通常客戶端的應用程式都會和J2EE應用程式出自同一家廠商，因此根本不需要XML Web Services來扮演溝通的角色，就算真的有需要，也是沒有問題的。瀏覽器以及無線裝置則可以連接到Java Server Pages (JSP)，這些JSP則有著各企業自行使用HTML、XHTML或WML所設計的使用者界面。
 
VII. 微軟的 .NET 平台
 
Microsoft .NET 是一項可以讓企業開發智慧型與企業級Web Services的產品。在此要特別注意的是，.NET與J2EE最大的差異：.NET是一項產品策略，而J2EE則是一項標準。Microsoft.NET可說是Windows DNA的大翻修，這是微軟先前提供開發企業級應用程式的平台。Windows DNA 包含許多現有產品的技術，包括Microsoft Transaction Server (MTS)與COM+、Microsoft Message Queue
(MSMQ)以及Microsoft SQL Server 資料庫。而新的 .NET Framework 則是設計來取代這些技術的，並加入Web Services層級以及程式語言的改進。微軟.NET的Web Services開發模型如圖表2所示：
 
 
圖表2的概述如下：
.NET應用程式存在於一個容器中，這個容器提供企業級應用程式所需的服務，例如：交易、安全以及訊息服務。.NET應用程式的商業層級是透過.NET managed 元件所開發的。這個層級負責商業程式與資料邏輯。它可以透過Active Data Objects(ADO.NET)來連接資料庫，或是在現有的系統中使用Microsoft Host Integration Server 2000所提供的服務，例如：COM Transaction Integrator (COM TI)。當然它也可以透過Web Services技術(包括：SOAP、UDDI、 WSDL以及BizTalk)來連接協力廠商的商業應用程式。因此協力廠商們可以透過Web Services技術(包括：SOAP、UDDI、 WSDL以及BizTalk)讓.NET程式彼此連接起來。傳統的客戶端程式、瀏覽器以及無線裝置則可以連接到Active Server Pages(ASP.NET)，這些ASP.NET則有著各企業自行使用HTML、XHTML或WML所設計的使用者界面。
 
VIII. 了解J2EE 與 .NET的相同點
為了幫助您了解這兩個平台所提供的架構模型，我們提供一個關於J2EE與 .NET技術相同點的列表，整理如表1。這張表僅列出兩個模型的相似點，至於相異的地方則稍後就會討論到。
 
 
IX. 比較分析
 
就產品上市時間而言:
在今日的市場上若要開發一個商業上的解決方案，時間就是金錢。錯失一個小小的機會，影響所及，將導致一個公司成為市場先驅或成為落後的追趕者。要加快產品上市時間的方法之一就是選擇可以快速開發程式的Web Services平台。這將讓開發人員可以快速地開發與維護程式碼，降低開發時程。Sun J2EE 與Microsoft .NET 兩者都提供一些執行機制，讓軟體開發人員可以避免觸碰到一些底層複雜的部分。除了在平台、程式語言以及企業架構上支援XML Web Services的中間層外，Sun J2EE 以及 .NET還分別透過Java Runtime Environment (JRE)與Common Language Runtime (CLR)提供基礎層面的服務。 J2EE還提供許有多.NET沒有的功能，這些功能可以加速產品上市時間，例如： 狀態管理服務，這讓開發人員可以撰寫較少的程式碼而且不用管理狀態，因此可以說是高階且快速的軟體開發環境。狀態管理服務可以讓您開發元件保持狀態。Persistence services (entity beans)讓程式開發人員在開發應用程式時，不需額外撰寫連接資料庫的程式碼，因此讓資料庫程式將變得易於開發與維護。Programmatic transactions讓您可以擁有更多的交易控制項。而custom tags 讓程式開發人員與網路設計人員可以更緊密地合作。
 
最後，我們覺得J2EE與.NET所提供的這兩種程式的開發環境是完全不同的。.NET號稱有強大的程式開發工具 Visual Studio.NET，Java也有各家廠商 (Borland、Sun、BEA、IBM等) 的整合式開發工具可供選擇使用;
在學習難度和系統設計及開發過程上面，.NET也是完全採用Java自始就採行的物件導向分析設計技術，學VB.NET或是C#要花的的工夫和學Java沒有兩樣，而且到系統架構設計上，OOAD、UML、Design Patterns等方法也是雙方都採行的標準步驟。所以在就平台的穩定性，伺服器的穩定性，以及產品的多樣性等方面來考量，J2EE徹底擊敗 .NET技術，兩者在程式開發上的方法也歸於一統，J2EE又已經經過這幾年市場上眾多企業用戶的實際檢驗，所以我們相信比較起前科累累而且還在嬰兒期的 Microsoft .NET系列技術來說，J2EE 是一個成熟穩定、高效能、而且自由開放的選擇。
 
 
J2EE vs. Microsoft.NET
I. 序
在本文中，我們將深入的比較兩種可用來建置商業XML Web Services的平台，分別是Sun Microsystems 所提供的Java 2 Enterprise Edition (J2EE)以及Microsoft所提供的 Microsoft.NET平台。雖然J2EE代表的是一個公開的標準，而 .NET是單獨一家廠商的標準(雖然.NET試圖取得ECMA的標準，但是卻只有在最基礎的部分被ECMA採納變成標準，請參考http://msdn.microsoft.com/net/ecma/ ，在企業的應用上確卻沒有標準化)，反觀Java平台，確是所有除了Microsoft以外的各大廠商都遵循著JCP的標準制定所有規格(請參考http://www.jcp.org ，您會發現所有的Java技術都是協調各大公司而來)。儘管在標準化上Java遙遙領先，但我們仍然將只針對伺服器端的Web Services架構做探討。例如：我們的討論將不涉及 JINI 或是Office XP，我們也不會討論Java跨足Solaris、Linux、Mac OS X、以及Windows平台，而.NET只跨Windows 98/ME/2000/XP等Windows平台的事實。我們更不會討論 ”跨語言” 這個Java早已試圖達成，Microsoft又拿來當成.NET的重大特點，卻根本不是這回事的功能。
(請參閱http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html，大家可以發現Java早就達到所謂跨語言的功能，Smalltalk、Eiffel、Lisp、Prolog、BASIC等語言都可以順利轉換成Java bytecode，不像.NET號稱跨語言，卻出現COBOL.NET這種怪物，原本的語言要削足適履來配合.NET，所以才產生VB.NET、COBOL.NET這一大串東西)。在讀完本文之後，您將會更加了解這兩種架構的彼此優缺點，而且在制定貴公司下一代Web Services決策時將有更明確的考量。
 
II. 前言
下一代的分散式運算時代已經來臨了。在過去幾年中，XML 被廣泛的運用於電腦運算環境中，以達到在全球資訊網上共享資訊的遠大目標。如今，它可以更進一步地提供運算能力上的分享。從技術的觀點來看，Web Services的出現並不能算是分散式電腦運算的新革命。它可以結構化的呈現資訊，甚至是程式內部的訊息，因而很自然地比XML應用程式更加引人注目。
 
III. 工業標準與企業標準
透過Web Services，任何應用程式可以在網路上順利地整合在一起。Web Services的基本原理是利用標準的網路協定(例如：HTTP)來傳送XML訊息。這是一種非常輕便的溝通機制，因此可以讓任何程式語言、中間層元件或平台很輕易地整合進來。一般工業上或企業內部會接受成熟且廣為廠商採用的業界標準，更尤其是已經受過市場考驗行之有年的標準。有了Web Services，您就可以快速且低成本的整合兩個企業、部門或甚至是兩個程式。
 
要建置Web Services必須得採用業界通用的Web Services技術。現在讓我們來看看Web Services究竟是什麼。首先您必須先知道如何建置以及使用Web Services。其實Web Services是種很簡單的XML界面，適用於商業、應用程式以及系統服務。說穿了也就是將既有的技術舊衣新穿而已。Web Services其實是一種新一代的分散式服務，在這之前，有CORBA、DCOM、COM+、RMI，都是用來實作分散式架構的技術，而且也被證明運作的非常順利；而新一代的分散式服務，採用的是XML技術，如XML-RPC和SOAP就是最佳的例子，新一代的分散式技術可以用寄有的通訊協定做基礎(如SMTP、FTP等)，但是目前最後最受歡迎的方式仍然是將XML基植於HTTP這個廣受歡迎，但是效能並非最佳的通訊協定上。即使如此，這些新一代的技術尚未通過時間的考驗，或許他們有可能運作的得很成功，也可能有些許的風險存在。
 
面對這麼多的分散式技術，J2EE平台與.NET平台的支援程度如下表:
 
對就有分散式技術的支援:
 
J2EE
.NET
CORBA
支援
不支援
RMI/IIOP
支援
不支援
COM+
不支援
支援
 
對新一代Web Services的支援:
 
J2EE
.NET
XML-RPC
支援
不支援
SOAP
支援
支援
 
從上述兩個圖表之中我們可以得知，對於姿態保守的公司而言，J2EE支援了較為廣泛應用於現有企業系統的分散式運算服務，而.NET平台仍然只支援延伸自COM與DCOM的COM+，其技術前身MTS COM+比Enterprise Java BeanJavaBeans技術早了三年，不消說，我們可以推斷J2EE提供的分散式服務比.NET的技術領先三年。此外，目前企業內部使用之大型主機所使用的皆為CORBA技術，J2EE對舊有技術的支援能當然是最佳的，因為COM+只能在Windows平台上運行。
 
如果是態度前衛的公司，使用J2EE者可以選用XML-RPC(http://java.sun.com/xml/jaxrpc/index.html)或是SOAP(http://java.sun.com/xml/jaxm/index.html)技術，Sun Microsystems更提供了Java Web Service Developer Pack(http://java.sun.com/webservices/webservicespack.html)供開發者開發Web Services。反觀.NET技術，只提供對於SOAP的支援。在對於既有分散式技術支援不足的情況下，對新一代分散式技術的支援又無法提供彈性的選擇，風險之大，是可以預估的。
 
  
就算新一代的Web Services非常穩定好了，他的穩定度常常會被底層作業系統的穩定度所影響，如果你選用.NET，就會被綁死在公認最不穩定的Windows平台上，更糟糕的是，.NET還只能在Microsoft官方的網頁伺服器上運作，相信之前使用IIS的朋友，在遭受過Nimda等不斷出現的病毒的惡夢之後，會不會對其安全性與穩定性產生質疑? 但是，如果您選用的是J2EE技術，那麼在諸多遵循標準的廠商所提供的應用程式伺服器中，您可以選擇最符合您需要，成本最低，而且又認為最佳的平台。
 
您可以到http://www.soapware.org/directory/4/implementations查詢既有的SOAP實作品，看看有多少是針對Java所設計的實作品，如下圖所示:
 
 
總而言之，我們就平台的穩定性，伺服器的穩定性，以及產品的多樣性這三方面來考量，J2EE徹底擊敗.NET技術。
 
下列的技術都是已為業界所採用，而且也是通往Web Services的最佳途徑：
‧
提供Web Services的人員使用自己的程式語言、元件與平台來開發、連接與佈署Web Services。
‧
提供Web Services的人員以WSDL (Web Services Description Language)定義Web Services。WSDL文件可以讓其他人知道Web Services的功用。
‧
提供Web Services的人員以UDDI (Universal Description, Discovery, and
  
Integration6)將Web Services註冊。 UDDI讓程式開發人員可以佈署Web Services，同時也可以搜尋他人所提供的服務。
‧
使用者透過UDDI登錄來找尋Web Services。
‧
使用者的程式會結合Web Services，並透過SOAP (Simple Object Access Protoco)或XML-RPC來呼叫Web Services。XML-RPC或SOAP 在HTTP協定上提供一份XML格式的訊息傳遞。這是所有Web Services共同的溝通協定。
 
請注意，上述的機制是建置Web Services並讓它運作的一種途徑。雖然有其他方法可以做到，但我們認為這些技術是最重要且將廣為業界採用的一種。
由此可知，實際上我們尚未有一致的方式來建置Web Services，建構上仍然有許多的困難需要克服。以SOAP、ebXML以及服務串流的規格來說，眾家廠商意見各異了。而且SOAP最常被宣傳的: 與程式語言無關，與特定平台無關這兩項特點，會在您嚐試著使用Apache SOAP與Microsoft SOAP Toolkit產生的Web Services進行溝通時，徹底地粉碎(譯注:這是因為xsi:type屬性在實作上有分歧的關係)。除了是對於實作上細節的理解有差異之外，更重要的原因是因為有人刻意地破壞標準。
 
即使如此，對於Web Services來說，仍然有不少好消息：
‧
很難得的，所有的廠商，包括Sun Microsystems與Microsoft等大廠，均同意SOAP、 WSDL以及UDDI 是有潛力的好產品，因此他們將在未來的產品中進一步提供這些技術的支援。
‧
所有意見不一的廠商都團結在一起，共同為建立Web Services的標準並廣植Web Services的應用而努力。
 
IV. 使用J2EE 以及Microsoft.NET來開發Web Services
 
如果您想開發一個有用的網路服系統。所面臨的挑戰並非表面上所看如此簡單。您的Web Services必須可靠、普及、不容易出錯、有彈性而且必須讓大家願意接受。這些嚴格的要求並不亞於任何企業等級的商業應用程式。
J2EE 以及 .NET 是現有用來開發伺服器端企業級應用程式的技術延伸。這些技術的早期版本並非專門用來開發Web Services用。如今Web Services已經成為趨勢，於是兩大陣營也隨之調整各自平台的解決方案，因此您現在已經可以使用這些技術來開發Web Services了。J2EE 以及 .NET的共通願景就是希望能達成開發Web Services的基礎工程，例如：跨平台的XML溝通、負載平衡以及交易。與其自己重新撰寫這些基礎工程，倒不如在可提供這些服務的平台上撰寫應用程式。
但是，當開發到一定規模的應用程式時，會產生一定的複雜度，這個時候就必須有開發工具的輔助，如果您選用了其中一種平台，那麼您可以選用的工具如下表所示:
開發新一代Web Services的開發工具:
平台
工具
J2EE
JBuilder (Borland)
Forte for Java (Sun)
WebLogic Workshop (BEA)
JDeveloper (Oracle)
Visual Age for Java (IBM)
Visual Café (WebGain)
.NET
只有Visual Stdio.NET
 
從這裡可以看出，您可以在您既有的企業解決方案提供廠商那邊，取得最佳的工具和解決方案，而且從免費的基本版本到付費的專業版本都有，各人可以根據不同的需求來做最佳的選擇，而不是只能尋求單一廠商所提供的工具和解決方案。
 
V.  J2EE
Java 2 Platform, Enterprise Edition (J2EE) 被設計成專門用來解決多層式企業解決方案的開發、佈署以及管理上的問題。在Sun Microsystems 所帶領的諸多廠商的努力之下，J2EE 已經成為一種業界標準。對您而言，最重要的一點就是，您必須先了解J2EE是一種標準，而非一種產品。您不能說”下載”J2EE，而是下載一系列的Adobe Acrobat PDF 檔案，這些檔案會仔細說明應用程式與所在容器(Container)之間的運作規定。透過遵守J2EE的規定，應用程式可以被部署在各種平台上的容器中。J2EE陣營的目標是提供客戶有多重選擇產品與工具的機會，並以此帶動良幣驅逐劣幣的效應，讓最好的產品成為市場上的贏家。要達成此理想的唯一的方法就是所有的廠商都要符合J2EE標準。
 
在交易安全方面，Sun Microsystems更與許多提供電子商務平台的廠商合作，例如：BEA、IBM以及Oracle等，共同制定J2EE。Sun Microsystems更發起一個Java標準制定組織Java Community Process (JCP)，專門隨時構思新決策來改善J2EE。 Sun Microsystems之所以這樣作的理由是因為，要達到電子交易安全最好的方法，就是要請所有的專家共同來制定嚴格的規範--唯有這樣的作法才能成功地達成他們整合市場的目標。J2EE 是一種Java的應用。您的J2EE 元件必須被轉譯成bytecode並在Java的執行引擎下執行JRE。值得一提的是，即使是相容於J2EE平台的容器，大多數都是以Java技術實作而成的。相較於Microsoft.NET在正式發行沒多久時間就因為安全上的錯誤而發表Service Pack1來說 (詳見http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q317396&sd=msdn&，使用.NET卻還沒有去下載的朋友請趕緊連上去看看，以免惡夢重現) ，
我們應該更了解一件事，就是:安全性是大家的事，決不是單一廠商就能決定的。
 
VI. J2EE 以及Web Services。
J2EE 在以往的Java程式語言中被定位成開發伺服端應用程式的架構。它可以被用來建置傳統的網站，軟體元件或是Web應用程式(Web Application)。到了最近，J2EE更被擴充成可支援XML Web Services的標準。這些Web Services可以和其他用J2EE或非J2EE標準所開發的Web Services溝通。J2EE Web Services的開發模型如圖表1所顯示
 
 
圖表1的內容概述如下：
J2EE應用程式存在於一個容器之中，這個容器提供企業級應用程式所需的服務，當然也具有企業所需要的品質，例如：交易、安全以及Persistence services。商業層級負責商業程式與資料邏輯。在大型規模的J2EE應用程式中，商業邏輯是利用Enterprise JavaBeans (EJB) 元件技術所建置。由此可知，這個層級專門用來負責商業程式以及資料邏輯的處理。它可以透過Java Database Connectivity (JDBC)、SQL/J來連接資料庫，或是透過Java Connector Architecture (JCA)技術來連結既有系統。它更可以利用Java用來處理XML的API (JAXP， Java API for XML Processing)，並透過Web Services技術(包括：SOAP、UDDI、 WSDL以及ebXML)來連接其他協力廠商所提供的商業應用程式。因此協力廠商們可以透過Web Services技術(包括：SOAP、UDDI、 WSDL以及ebXML)讓J2EE程式彼此連接起來。所以只要利用Java Servlets (這是一種支援HTTP請求/回應的Java技術)就可以從協力廠商的Web Services中接受請求了，並予以回應。Java Servlets使用JAXP/JAXR/JAXM/JAX-RPC等技術來提供Web Services運作時的所有功能。Web Services目前是擴充程式庫的型態存在，目前已經著手將Web Services併入J2EE下一版的規格之中，並成為業界共通的標準。傳統的客戶端程式，例如Java Applet或桌面應用程式，將直接以Internet Inter-ORB Protocol (IIOP)來連接EJB元件而非透露Web Services，如果要使用Web Services也可，但是因為通常客戶端的應用程式都會和J2EE應用程式出自同一家廠商，因此根本不需要XML Web Services來扮演溝通的角色，就算真的有需要，也是沒有問題的。瀏覽器以及無線裝置則可以連接到Java Server Pages (JSP)，這些JSP則有著各企業自行使用HTML、XHTML或WML所設計的使用者界面。
 
VII. 微軟的 .NET 平台
 
Microsoft .NET 是一項可以讓企業開發智慧型與企業級Web Services的產品。在此要特別注意的是，.NET與J2EE最大的差異：.NET是一項產品策略，而J2EE則是一項標準。Microsoft.NET可說是Windows DNA的大翻修，這是微軟先前提供開發企業級應用程式的平台。Windows DNA 包含許多現有產品的技術，包括Microsoft Transaction Server (MTS)與COM+、Microsoft Message Queue
(MSMQ)以及Microsoft SQL Server 資料庫。而新的 .NET Framework 則是設計來取代這些技術的，並加入Web Services層級以及程式語言的改進。微軟.NET的Web Services開發模型如圖表2所示：
 
 
圖表2的概述如下：
.NET應用程式存在於一個容器中，這個容器提供企業級應用程式所需的服務，例如：交易、安全以及訊息服務。.NET應用程式的商業層級是透過.NET managed 元件所開發的。這個層級負責商業程式與資料邏輯。它可以透過Active Data Objects(ADO.NET)來連接資料庫，或是在現有的系統中使用Microsoft Host Integration Server 2000所提供的服務，例如：COM Transaction Integrator (COM TI)。當然它也可以透過Web Services技術(包括：SOAP、UDDI、 WSDL以及BizTalk)來連接協力廠商的商業應用程式。因此協力廠商們可以透過Web Services技術(包括：SOAP、UDDI、 WSDL以及BizTalk)讓.NET程式彼此連接起來。傳統的客戶端程式、瀏覽器以及無線裝置則可以連接到Active Server Pages(ASP.NET)，這些ASP.NET則有著各企業自行使用HTML、XHTML或WML所設計的使用者界面。
 
VIII. 了解J2EE 與 .NET的相同點
為了幫助您了解這兩個平台所提供的架構模型，我們提供一個關於J2EE與 .NET技術相同點的列表，整理如表1。這張表僅列出兩個模型的相似點，至於相異的地方則稍後就會討論到。
 
 
IX. 比較分析
 
就產品上市時間而言:
在今日的市場上若要開發一個商業上的解決方案，時間就是金錢。錯失一個小小的機會，影響所及，將導致一個公司成為市場先驅或成為落後的追趕者。要加快產品上市時間的方法之一就是選擇可以快速開發程式的Web Services平台。這將讓開發人員可以快速地開發與維護程式碼，降低開發時程。Sun J2EE 與Microsoft .NET 兩者都提供一些執行機制，讓軟體開發人員可以避免觸碰到一些底層複雜的部分。除了在平台、程式語言以及企業架構上支援XML Web Services的中間層外，Sun J2EE 以及 .NET還分別透過Java Runtime Environment (JRE)與Common Language Runtime (CLR)提供基礎層面的服務。 J2EE還提供許有多.NET沒有的功能，這些功能可以加速產品上市時間，例如： 狀態管理服務，這讓開發人員可以撰寫較少的程式碼而且不用管理狀態，因此可以說是高階且快速的軟體開發環境。狀態管理服務可以讓您開發元件保持狀態。Persistence services (entity beans)讓程式開發人員在開發應用程式時，不需額外撰寫連接資料庫的程式碼，因此讓資料庫程式將變得易於開發與維護。Programmatic transactions讓您可以擁有更多的交易控制項。而custom tags 讓程式開發人員與網路設計人員可以更緊密地合作。
 
最後，我們覺得J2EE與.NET所提供的這兩種程式的開發環境是完全不同的。.NET號稱有強大的程式開發工具 Visual Studio.NET，Java也有各家廠商 (Borland、Sun、BEA、IBM等) 的整合式開發工具可供選擇使用;
在學習難度和系統設計及開發過程上面，.NET也是完全採用Java自始就採行的物件導向分析設計技術，學VB.NET或是C#要花的的工夫和學Java沒有兩樣，而且到系統架構設計上，OOAD、UML、Design Patterns等方法也是雙方都採行的標準步驟。所以在就平台的穩定性，伺服器的穩定性，以及產品的多樣性等方面來考量，J2EE徹底擊敗 .NET技術，兩者在程式開發上的方法也歸於一統，J2EE又已經經過這幾年市場上眾多企業用戶的實際檢驗，所以我們相信比較起前科累累而且還在嬰兒期的 Microsoft .NET系列技術來說，J2EE 是一個成熟穩定、高效能、而且自由開放的選擇。