国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 編程 > .NET > 正文

J2EE vs. Microsoft.NET 之 Web Services

2024-07-10 13:05:00
字體:
來源:轉載
供稿:網友
j2ee vs. microsoft.net 之 web services
                   ——建置xml架構的web services之比較
作者:佚名    本文選自:cnjsp  2002年04月30日
i. 序

在本文中,我們將深入的比較兩種可用來建置商業xml web services的平臺,分別是sun microsystems 所提供的java 2 enterprise edition (j2ee)以及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這一大串產品)。號稱跨語言喊了半天,原來連自己的vb 6.0都跨不過去。在讀完本文之后,您將會更加了解這兩種架構的彼此優缺點,而且在制定貴公司下一代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.netcorba支持不支持rmi/iiop不支持com+不支持支持

對新一代web services的支持:

j2ee.netxml-rpc支持不支持soap支持支持

從上述兩個圖表之中我們可以得知,對于姿態保守的公司而言,j2ee支持了較為廣泛應用于現有企業系統的分布式運算服務,而.net平臺仍然只支持延伸自com與dcom的com+,其技術前身mts com+比enterprise javabeans技術早了三年,不消說,我們可以推斷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

- 使用者透過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)
  • visualage for java (ibm)
  • visual cafe (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應用程序存在于一個容器之中,這個容器提供企業級應用程序所需的服務,當然也具有企業所需要的品質,例如:交易、安全以及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應用程序存在于一個容器中,這個容器提供企業級應用程序所需的服務,

例如:交易、安全以及訊息服務。.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. 比較分析

就產品上市時間而言:

在今日的市場上若要開發一個商業上的解決方案,時間就是金錢。錯失一個小小的機會,影響所及,將導致一個公司成為市場先驅或成為落后的追趕者。要加快產品上市時間的方法之一就是選擇可以快速開發程序的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 是一個成熟穩定、高效能、而且自由開放的選擇。

<全文圖文并茂版請至 http://www.javatwo.net>

[/td]
發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 平凉市| 闽清县| 青龙| 木里| 简阳市| 仙桃市| 台北县| 宽城| 皋兰县| 屯留县| 绵阳市| 巴中市| 喜德县| 庄河市| 晋城| 治多县| 永靖县| 定西市| 宜君县| 睢宁县| 图木舒克市| 伊金霍洛旗| 沈丘县| 东乌珠穆沁旗| 长寿区| 大安市| 长阳| 祁门县| 项城市| 永平县| 神池县| 乐安县| 阜阳市| 上栗县| 全南县| 涞水县| 措美县| 巴彦淖尔市| 开阳县| 拉孜县| 防城港市|