作者:未知 時間:2005-09-13 23:35 出處:Blog.ChinaUnix.NET 責編:chinaitpower
摘要：J2EE與.NET比較分析白皮書
I. 序言
在這個白皮書里，我們會在為商業(yè)公司建立基于XML的Web services的兩種產(chǎn)品中做一個強有力的比較:由太陽微系統(tǒng)公司設(shè)計的Java 2 平臺, Enterprise Edition (J2EE)1,，另一個是微軟公司的Microsoft.NET2。
在這篇文章中，一些觀點可能會冒犯你，但我們希望其中大部分觀點能和你相通！所以當你閱讀這篇文章時，請記住我們的三個承諾 ：
1，我們承諾：在做比較時是在一個合理的，中立的和毫無偏見的基礎(chǔ)上！
2，我們承諾：告訴您我們關(guān)于這兩個技術(shù)比較的真實感受！
3，我們承諾：消除您關(guān)于市場中這兩個技術(shù)的不安定因素！
盡管J2EE 和 .NET覆蓋了大量的技術(shù)和標準，但我們會把焦點明確的集中在為web services建立服務(wù)器端這一點上。在讀完這篇白皮書后，你會發(fā)現(xiàn)我們對這兩個技術(shù)的比較，能夠使你在設(shè)計web services時，做出選擇！
首先，這個白皮書的前一半是基于web services,J2EE和.NET部分信息的。如果你已經(jīng)掌握了這些技術(shù)，可以跳過這一部分，進入第二部分，那里有您感興趣的關(guān)于兩者比較的內(nèi)容！
II. 介紹
通過已被廣范接泛的技術(shù)來創(chuàng)建web services
在web services的身后是完整的理論體系，現(xiàn)在讓我們來看看如何去創(chuàng)建和使用一個web service。
Web services現(xiàn)在只是舊技術(shù)戴著頂新帽子，它現(xiàn)在只是簡單的基于XML的界面。下面的一些技術(shù)已經(jīng)為大多數(shù)工業(yè)所接受，將是建立Web services的方法：
· 供應商選擇自己的編程語言，中間件和開發(fā)平臺開發(fā)，裝配Web services。
· 各供應商定義一個Web services描述語言（the Web Services Description Language4 ），通過統(tǒng)一語言和標準來建立Web services。
· 供應商在UDDI注冊，UDDI能讓供應商發(fā)布Web services，并能為他們的軟件找到由其它供應商提供的服務(wù),也就是大家資源共享！
· 用戶通過UDDI搜索他想要的服務(wù)。
· 用戶通過SOAP（簡單對象ACCESS協(xié)議）來調(diào)用service的操作。SOAP提供一個類似XML的能通過HTTP描繪參數(shù)和返回數(shù)值的方法。這是一個所有Web services都遵守的協(xié)議。
注意，以上的這些技術(shù)僅僅是對簡單的Web services的。對于商業(yè)事務(wù)，多請求事務(wù)，計劃，文件流，擴展的商業(yè)交易，就需要一個已經(jīng)完全協(xié)議上的結(jié)構(gòu),這些應用程序的要求條件經(jīng)常超出純粹地基于SOAP的執(zhí)行。這就是ebXML產(chǎn)生的動機，一套XML規(guī)范＋相互聯(lián)系的程序＋為提供一個B2B協(xié)作綜合基礎(chǔ)的方法。
注意上面的方法只是建立Web services的一種，你還可以有更多的選擇，但是我們覺得上面的這些方法是極其重要的將會為廣泛的工業(yè)所采用！事實上，我們還未能取得關(guān)于建立Web services完全一致的意見，現(xiàn)在還是有很多的其它解決方案，例如，關(guān)于SOAP的擴展，ebXML和服務(wù)流程描述，但它們都還未達成一致。但我們也有好的消息：
· 絕大多數(shù)的開發(fā)商，包括SUN和Microsoft都在SOAP，WSDL，UDDI上達成一致,這些技術(shù)都會為未來提供一個良好的基礎(chǔ)。
· 所有的開發(fā)商都在共同建立Web services的標準。
The J2EE and Microsoft.NET
如果你想建一個便于使用的web services，你就得使你的web services比須是可靠的，高度可利用的，能容錯的，可升級的并且能在可接受的條件下完成任務(wù)。這些需要和任何其他的企業(yè)應用程序沒什么區(qū)別。
J2EE和.NET正是從現(xiàn)有的應用程序服務(wù)器演變而來，用于建立這些企業(yè)應用程序的。在它們的早期版本中，這些技術(shù)從歷史的觀點上看并不是用于web services的?，F(xiàn)在web services時代已經(jīng)到來，這兩個陣營都正在各自的平臺上重新設(shè)計他們的解決方案，任何一個平臺都能滿足您關(guān)于建立web services的需求。
像XML協(xié)同工作，平衡載入，事務(wù)處理，在J2EE與.NET之間，兩者有著太多的相似。你可以通過它們提供的服務(wù)輕松的寫出你的程序，而不是像以前一樣你獨自的寫出每一句程序。
這樣就可以讓你專注于編寫你想加強功能的那一模塊。假如，你從事一家財務(wù)服務(wù)公司，你非常熟悉財務(wù)服務(wù)，但是比起像SUN，IBM，BEA，Oracle和Microsoft等這樣的技術(shù)公司，你對web services的編程就理解甚少。你只需購買他們的相關(guān)程序包，你不必成為一個樣樣精通的編程專家也能建立一個基于財務(wù)服務(wù)的web services。你只要找到你商業(yè)事務(wù)中的隨時可能遇到的問題就可以了，因為這部分可以由你自己來編程處理，而其它瑣碎的程序編寫就留給你購買的程序包去解決！
現(xiàn)在，我們就開始看看J2EE與.NET的細節(jié)部分。
III. J2EE
JAVA2平臺，企業(yè)版（J2EE）是為單一的復雜問題，如有關(guān)部門發(fā)展，人員配置，項目管理等多級企業(yè)解決方案而設(shè)計的。J2EE是一個由SUN微系統(tǒng)公司提出的工業(yè)標準。
你應該意識到J2EE是一個標準，而不是一個產(chǎn)品，這一點是很重要的。所以你沒有辦法去“下載”J2EE。你更適合去下載一套Adobe Acrobat PDF格式的有關(guān)描述應用程序與程序包之間的協(xié)議文檔。只要雙方都服從J2EE的約定，其應用程序就能在各種各樣的程序包環(huán)境下運行。
J2EE陣營的目的是使所有用戶有權(quán)自己去選擇他們要的產(chǎn)品和工具，這樣也鼓勵了產(chǎn)品間的競爭。這一目的的實現(xiàn)比須是J2EE已成為工業(yè)標準。為了使用戶放心的買入，SUN公司同其他的EBusiness平臺開發(fā)商（像BEA，IBM和Oracle）合作定義J2EE。SUN還發(fā)起了JAVA民間組織以汲取新的方案來不斷完善J2EE。SUN公司做這些的原因是：他們不得不這樣做以爭取成功，他們想成為業(yè)界標準。
Java: J2EE的基礎(chǔ)語言
J2EE體系構(gòu)造的基礎(chǔ)是JAVA語言。JAVA最激動人心的地方是他只用編程者寫一次代碼，就能運行在其它的平臺上，具體如下：
1，開發(fā)者用JAVA編寫源代碼。
2，JAVA代碼被編譯成字節(jié)碼，這是一個跨平臺的中間代碼，居于源代碼和機器代碼之間。
3，當這些代碼運行時，JAVA運行環(huán)境（JRE）解釋這種字節(jié)碼并且同時執(zhí)行。
J2EE是JAVA語言的應用。你的J2EE組件被轉(zhuǎn)化成字節(jié)碼在JRE下執(zhí)行。
J2EE和web Services
J2EE從歷史觀點上看是一個用JAVA語言建筑服務(wù)器端應用的體系結(jié)構(gòu)。它能創(chuàng)建傳統(tǒng)的網(wǎng)站，軟件組件或者是應用程序包。J2EE最近已被擴展成包括支持建立基于XML的web services。這些web services能同其它web services交互操作。
J2EE web services發(fā)展模型如圖1所示：
圖1簡要的解釋如下：
J2EE應用程序是一組企業(yè)應用程序，其由許多必要的服務(wù)程序集成，如事務(wù)處理服務(wù)程序，安全服務(wù)程序等。
在商業(yè)層上執(zhí)行商業(yè)處理和數(shù)據(jù)資料處理，在J2EE應用程序中，這些大多數(shù)是用Enterprise JavaBeans (EJB) components來建立的。這一層完成商業(yè)處理和數(shù)據(jù)處理，通過Java Database Connectivity (JDBC) 或SQL/J或使用Java Connector Architecture (JCA)的現(xiàn)有系統(tǒng)來實現(xiàn)數(shù)據(jù)庫的連接。當然也能使用web services技術(shù)（SOAP，UDDI，WSKL，EBXML），這些是通過JAVA的API函數(shù)來實現(xiàn)的。
商業(yè)伙伴能經(jīng)web services技術(shù)（SOAP，UDDI，WSKL，EBXML）分享J2EE應用程序。一個小servlet，能接受來自商業(yè)伙伴的web service的請求。servlet使用JAVA的API來執(zhí)行web services操作。
傳統(tǒng)的“胖”客戶，像applets和應用程序直接通過EJB層來連接，因此這里沒有必要與基于XML的web services協(xié)作。
WEB瀏覽器和無線設(shè)備與JSP連接，使用戶不必在乎它們與HTML，XHTML或WML之間的接口。
參考工具
為了提供詳細的說明，SUN公司也提供了J2EE的參考工具。程序員編寫工具以保證其組件的可移植性。這些工具不應該是產(chǎn)品，它們僅僅是用來起測試的作用。
額外的服務(wù)
所有支持J2EE平臺的廠家都能提供額外的服務(wù)，當然這些是在業(yè)界標準里找不到的，所以其中可能會影響移植能力，如擴展的EAI功能性，電子商業(yè)組件，高級的B2B集成。還有其它的一些特色，如平衡載入，是不影響程序代碼移植性的，因為它們的服務(wù)是由底層的程序包提供的。
IV. Microsoft's .NET 平臺
Microsoft .NET是一組能使你建立良好的，企業(yè)級的web services的產(chǎn)品。注意，它們有一個重要的不同：.NET是一個產(chǎn)品策略，然而J2EE是一個任何產(chǎn)品都要用到的標準。
.NET大量的改寫了Microsoft早期開發(fā)平臺的底層代碼和組件，其中包括了許多現(xiàn)在正廣范用到的技術(shù)，也包括MTS和COM＋，消息隊列（MSMQ），和Microsoft SQL server數(shù)據(jù)庫。新的.NET結(jié)構(gòu)取代了這些技術(shù)，并且包括了一個web services層來提高語言的支持能力。
用Microsoft的.NET建筑web services的開發(fā)模型如下圖：
關(guān)于上圖的簡要解釋：
.NET應用程序是運行在一個大型的程序包上，由其提供大量的服務(wù)，例如事務(wù)處理，安全保護和消息傳輸服務(wù)。
在商業(yè)層上用.NET的管理組件來建立.NET應用程序。在這一層上，完成的是商業(yè)處理和數(shù)據(jù)整理。它通過ADO.NET來連接數(shù)據(jù)，也可通過SOAP，UDDI，WSDL來連接你的商業(yè)伙伴。
商業(yè)合作者們能由.NET應用程序通過web services技術(shù)（SOAP，UDDI，WSDL，BizTalk)來相互聯(lián)接。
傳統(tǒng)的胖客戶機，網(wǎng)頁瀏覽，無線設(shè)備通過HTML，XHTML或WML與ASP.NET實現(xiàn)聯(lián)接，高級用戶界面則是由windows的窗體建立。
· .NET 框架
Microsoft的.NET實現(xiàn)了語言獨立性和語言的互用性，這正是.NET框架中一個迷人的地方。一個單獨的.NET組件能由VB.NET編寫，也能由C＃(一個新的面向?qū)ο缶幊陶Z言）編寫。
它是如何工作的呢？首先，源程序被翻譯成Microsoft Intermediate Language（中間代碼），我們稱其為MSIL，或IL。這種IL代碼是一種與JAVA字節(jié)碼類似的中性語言。
IL代碼接著被解釋翻譯成本地可執(zhí)行的代碼。.NET框架包含了一個通用語言運行庫（CLR），與JAVA的實時運行環(huán)境（JRE）是類似的。CLR是.NET開發(fā)者的源代碼與下層硬件的一個中間接口，所有的.NET代碼最終都是在CLR上運行的！
CLR提供了一些動人的特性，像自動垃圾收集，異常操作，跨語言繼承，調(diào)試，還有各個不同版本組件“side-by-side”的執(zhí)行機制。
.NET 服務(wù)程序
.NET平臺由以下.NET企業(yè)服務(wù)程序構(gòu)成：
SQL Server 2000 微軟的關(guān)系數(shù)據(jù)庫系統(tǒng)。
Exchange 2000 Server 一個消息傳輸，協(xié)作平臺，用于開發(fā)，運行核心的商業(yè)服務(wù)，現(xiàn)在已集成在Windows 2000中。
Commerce Server 2000 提供簡單的電子商務(wù)解決方案。
Application Center Server 2000用于管理眾多的服務(wù)程序。
Host Integration Server 2000 輕松的與其它平臺相聯(lián)。
Internet Security and Acceleration (ISA) Server 2000 提供防火墻和網(wǎng)頁緩存功能。
BizTalk Server 2000 微軟的基于XML的協(xié)作的電子商務(wù)解決方案。
其他.NET產(chǎn)品和服務(wù)程序
微軟的旗艦產(chǎn)品：新版本的Visual studio.NET，已經(jīng)發(fā)行。這是一個綜合的.NET開發(fā)環(huán)境。除了JAVA，它幾乎支持所有的語言。
Visual Studio.NET也提供了新的所謂C＃語言，與JAVA類似，你會發(fā)現(xiàn)它們只有一點點的不同。
另外還有Hailstorm9 。 是微軟的portfolio of building block web services. Microsoft and possibly Microsoft partners will host the Hailstorm web services. Some Hailstorm web services will be available on a subscription basis, and others will be free. For example, Microsoft's Passport service is now freely available as a web service-oriented universal identification mechanism.
Web services such as Microsoft's Passport offer a shared context in that many other web services can depend upon Passport for identity and security credentials. User's need not have their contextual information spread across and possibly duplicated across multiple web sites. "Islands" of information can now be located in a single repository and then shared by user-centric web services regardless of the invoking client device. Privacy of information is focal point in Hailstorm web servicing. In fact, users of Hailstorm web services are empowered to manage the availability of their personal information through "affirmative consent".
Understanding J2EE and .NET by analogy
To help you understand both models, we offer analogies between J2EE and .NET technologies in Table 1. This table only showcases the similarities--we will get to the differences in a few moments.
特性
J2EE
.NET
技術(shù)類型
標準
產(chǎn)品
中間供應商
30+
Microsoft
翻譯器
JRE
CLR
動態(tài)web網(wǎng)頁
JSP
ASP.NET
中間層組件
EJB
.NET 管理組件
數(shù)據(jù)庫存取
JDBC SQL/J
ADO.NET
SOAP, WSDL,
UDDI
Yes
Yes
Implicit middleware
(load-balancing, etc)
Yes
Yes
Table 1 Analogies between J2EE and .NET
V. Comparative Analysis
Time-to-Market Features
When developing a commerce solution in today's marketplace, a few months of time is an eternity. Missing a small window of opportunity is the difference between a corporation that is first to market, and a corporation that must play catch-up for years.
One way to speed time to market is to choose a Web services platform that allows rapid application development. This enables developers to write and maintain code quickly, lowering development time.
Both Sun J2EE and Microsoft .NET provide runtime mechanisms that insulate software developers from particular dependencies. In addition to a web service-oriented XML layer of indirection between platforms, languages, and enterprise architectures, Sun J2EE and .NET offer language-level intermediation via the Java Runtime Environment (JRE) and the Common Language Runtime (CLR) respectively.
J2EE offers several features that accelerate time-to-market which are not found in .NET. For example, state management services enable developers to write less code and not worry about managing state, resulting in a higher degree of rapid application development. State management services enable you to build components that hold state. Persistence services (entity beans) enable developers to write applications without coding data access logic, resulting in leaner, database-independent applications that are easier to build and maintain. Programmatic transactions allow you to have greater transactional control. And custom tags are extremely powerful, and empower developers and web designers to easily collaborate.
In addition to these features that enable rapid application development, there are several features that specific vendors offer which aid time-to-market, such as business process management, E-Commerce components, XML-based legacy integration, and enhanced B2B collaboration. A warning: Customers who elect to leverage these features will sacrifice portability. This is a consequence of J2EE architecture not being all things to all people. However, it should be noted that even after taking advantage of such proprietary features, there would still be a great deal more portability in the end solution than the .NET alternative.
Microsoft.NET offers a variety of time-to-market features not found in J2EE as well. Most notably, ASP.NET is independent of client device, and allows for user interfaces to be rendered to alternative user interfaces without rewriting code. Microsoft also offers Queued Components which are superior to MessageDriven Beans. It should be noted here that Microsoft has tried to simplify server-side programming greatly by removing support for features found in traditional enterprise applications, such as stateful servers and simple transactions. If developers need to go outside this box, their code must be made to be non-managed and reside outside the .NET Framework rather than take advantage of it. Microsoft also provides business process management and E-Commerce capabilities, which are available in some J2EE implementations but not all.
In conclusion, we feel the ability to achieve rapid application development offered by both J2EE and .NET is definitely not equal. It is, however, comparable. The feature differences are minor and it is very difficult to make a compelling argument either way. We do not recommend organizations make their platform decision based upon them. There are larger business issues at hand that dictate the platform choice.
Single-Vendor Solution
When building web services, in general you should always prefer to have a single-vendor solution. A single vendor solution is usually more reliable, interoperable, and less error-prone than a two-vendor bridged solution.
One of J2EE's strengths is that it has spawned a wide variety of tools, products, and applications in the marketplace, which provide more functionality in total than any one vendor could ever provide. However, this strength is also a weakness. J2EE tools are often-times not interoperable, due to imperfections in portability. This limits your ability to mix and match tools without substantial low-level hacking. With lower-end J2EE implementations, you need to mix and match to get a complete solution, and this is the tradeoff when choosing a less complete package. Larger vendors, such as IBM, Oracle, BEA, and iPlanet, each offer a complete web services solution.
.NET provides a fairly complete solution from a single vendor--Microsoft. This solution may lack some of the higher end features that J2EE solutions offer, but in general, the complete web services vision that Microsoft will be providing is equal in scope to that of a larger J2EE vendor.
Another way to look at a single-vendor solution is from a legacy perspective. Many legacy systems are written by J2EE vendors, such as IBM or BEA. J2EE offers a single-vendor solution from the legacy integration perspective, since you can re-use existing relationships with those vendors. A J2EE solution would therefore be a single-vendor solution, since you can stay with that legacy system vendor rather than inject a new vendor such as Microsoft. For users with existing Microsoft-based systems, the reverse argument applies.
Support for Existing Systems
Most large corporations have existing code written in a variety of languages, and have a number of legacy systems, such as CICS/COBOL, C++, SAP R/3, and Siebel. It is vital that corporations be given an efficient, rapid path to preserve and reuse these investments. After all, it is likely that businesses will have neither the funds nor the time to reinvent all existing systems. This legacy integration often is one of the most challenging (if not the most challenging) tasks to overcome when building a web service.
There are several ways to achieve legacy integration using J2EE, including
o The Java Message Service (JMS) to integrate with existing messaging systems
o Web services to integrate with any system
o CORBA for interfacing with code written in other languages that may exist on remote machines.
o JNI for loading native libraries and calling them locally.
But by far, the most important part of the J2EE vision for integration is the J2EE Connector Architecture (JCA). The JCA is a specification for plugging in resource adapters that understand how to communicate with existing systems, such as SAP R/3, CICS/COBOL, Siebel, and so-on. If such adapters are not available, you can write your own adapter. These adapters are reusable in any container that supports the JCA. The major vendors of existing systems are bought into the JCA.
.NET also offers legacy integration through the Host Integration Server 2000. COM Transaction Integrator (COM TI) can be used for collaborating transactions across mainframe systems. Microsoft Message Queue (MSMQ) can integrate with legacy systems built using IBM MQSeries. Finally, BizTalk Server 2000 can be used to integrate with systems based on B2B protocols, such as Electronic Data Interchange (EDI) (the reader should note, however, that BizTalk does not serve as an access point to a proprietary network on which EDI takes place).
In conclusion, we believe that the legacy integration features offered by J2EE are superior to those offered by .NET. The JCA market is producing a marketplace of adapters that will greatly ease enterprise application integration. Integration with packaged applications and legacy systems will become much easier--imagine integrating with a system such as Siebel, Oracle, or SAP without ever leaving the Java programming environment. There is no analog to this in the Microsoft domain; rather, there is limited connectivity to select systems provided off-the-shelf through the Host Integration Server.
Market Perception
When comparing two platforms, your first instinct is probably to compare the technologies. The unfortunate reality is that good technology rarely succeeds in the marketplace because it's good technology. Usually it's the technology with the best marketing that wins.
J2EE is an extremely well-marketed platform because it is being marketed by an entire industry of 50+ assorted vendors. This network of interdependent businesses form a virtual marketing machine, and the result is a fantastic market perception for J2EE.
.NET's marketing strength stems from the fact that Microsoft knows how to market a platform. They have put their "A" team on marketing .NET, as is apparent in the industry hype surrounding the platform. This is a powerful force not to be reckoned with. Microsoft's advantage is also that it announced it's web services strategy before the J2EE players, which gave it market perception. So in the marketing front, we give the nod to Microsoft for doing the best job in hyping their platform--so far.
Maturity of Platform
Organizations that adopt a web services platform must consider the maturity of the underlying platform. A less mature, earlier-generation platform is more prone to errors and problems.
J2EE is a veneer atop existing J2EE solutions. J2EE deployments are alive and healthy, running a variety of mission-critical business problems today. However, when looking past the surface, it should be noted that there are some identifiable areas of risk where J2EE lacks maturity:
o The automatic persistence provided EJB is still immature
o The Java Connector Architecture (JCA) is new.
o All web service support is new.
For Microsoft.NET, the story is a bit different. Some of .NET is based on Windows DNA, which also runs a variety of mission-critical web sites today and enjoys success. However:
o With the new CLR, a good portion of the underlying .NET platform has been substantially rewritten. Indeed, the platform itself is currently only available in a beta version.
o C# is new.
o All web service support is new.
In conclusion, we must find that J2EE is the more mature platform. It is true that certain new features in J2EE are new and risky. However, the very underlying fabric of .NET, is an overhauled rewrite, and the entire C# language is brand new. This represents enormous risk compared to the new J2EE features. This best thing about .NET is that it removes the dependency on the COM Registry -- .NET will do away with DLL Hell. But the worst thing about .NET is that it tosses out the existing infrastructure. We recommend that the risk averse take a 'wait and see' approach with first-generation software such as this.
Language Support
J2EE promotes Java-centric computing, and as such all components deployed into a J2EE deployment (such as EJB components and servlets) must be written in the Java language. To use J2EE, you must commit to coding at least some of your eBusiness systems using the Java programming language. Other languages can be bridged into a J2EE solution through web services, CORBA, JNI, or the JCA, as previously mentioned. However, these languages cannot be intermixed with Java code. In theory, JVM bytecode is language-neutral, however in practice, this bytecode is only used with Java.
By way of comparison, .NET supports development in any language that Microsoft's tools support due to the new CLR. With the exception of Java, all major languages will be supported. Microsoft has also recently introduced its new C# language which is equivalent (with the exception of portability) to Java and is also available as a programming language within the Visual Studio.NET environment. All languages supported by the CLR are interoperable in that all such languages, once translated to IL, are now effectively a “common” language. A single .NET component can therefore be written in several languages.
The multiple language support that Microsoft has introduced with the CLR is an exciting innovation for businesses. It is clearly a feature advantage that .NET has over J2EE. But is the CLR a business advantage for you? This is a more interesting discussion. We are a bit concerned that the CLR may represent a poor design choice for you if more than one language is used. This is for the following reasons:
Risk.Many existing systems are internally convoluted. Disrupting such existing systems is a risky proposition, since knowledgeable engineers, original source code, and a general understanding of the existing system are often-times unavailable. The old adage, "if it ain't broke, don't fix it" applies here.
Maintainability.We speculate that a combination of languages running in the CLR may lead to a mess of combination spaghetti code that is very difficult to maintain. If you have an application written in multiple languages, then to fully develop, debug, maintain, and understand that application, you will need experts in different languages. The need to maintain code written in several languages equates to an increase in developer training expenditures which contributes further to an increased total cost of ownership.
Knowledge building.With combination language code, your developers are unable to share best practices. While individual productivity may increase, communication breaks down, and team productivity decreases.
Skills transfer.While developers using different languages may have very quickly coded a .NET system using VB.NET and C#, what happens if the new C# developers leave your organization? You have two choices. Train your VB.NET developers to understand and write code with C#, or hire other C# developers who know nothing about your code base. The resulting lack in productivity equates to a reduced time to market and a higher total cost of ownership.
In most cases, we feel that it's much better design to standardize on a single language, and to treat legacy systems as legacy systems and integrate with them by calling them through legacy APIs, which can be achieved using either J2EE or .NET.
We do feel the CLR still adds significant value. The value is that a new eBusiness application can be written in a single language of choice other than Java. This is useful for organizations that are not ready to embrace Java. However, again we must provide words of caution.
o It will not be seamless to transition existing developers from their familiar language into productive .NET developers. Procedural languages such as COBOL and VB are being rewritten for .NET to be object-oriented. Teaching developers object-oriented programming is much more of a stepping stone than understanding syntactical rules.
o Languages such as COBOL or VB were never intended to be object-oriented. Legacy code will not seamlessly transition into .NET. The resulting code is forever bound to .NET and can never be taken from its .NET home.
o We question the general wisdom in reinvesting in outdated technologies, such as COBOL, with new eBusiness or web services initiatives.
In summary, there are pros and cons to both approaches to language support. Use the approach that best suits your business needs, but at least be aware of the consequences of your decision.
Migration from Previous Platform
For organizations who have an existing deployment using either J2EE-based technologies or Windows DNA-based technologies, an interesting discussion is the ease of migration from the previous platform to the new platform.
J2EE does not impose many migration problems. As previously mentioned, the Java Connector Architecture (JCA) as well as the web services support in J2EE is brand new and will require new code, but those are minor overall.
Although Microsoft.NET is based on MTS and COM+, we are concerned that the migration to .NET will be taxing compared to J2EE. First off, .NET is based on the “managed code” framework, which steals a lot of ideas from COM+ and MTS, but it’s still an entirely new infrastructure based on an entirely new code base - CLR. Taking advantage of the most valuable aspects of the CLR impose one-time frictions.
For example to accommodate a Common Type System (CTS) which standardizes on data types used between languages, the original Visual Basic data types have been dismissed. Consequently, code dependent upon those original Visual Basic data types will break, and there is currently no migration tool.
Another example is the COM+ migration path. In .NET terminology, code that runs within the CLR is referred to as managed code, while code running outside the CLR is called unmanaged code. If you're a COM+ developer and want to take advantage of the new CLR, then you have two options for migration:
Rewrite existing code as CLR code.. COM+ code needs to be rewritten to accommodate the CLR’s automatic garbage collection mechanism and its deprecation of pointers. Dependencies also need to be removed to the COM registry.
Keep your existing code as unmanaged.To collaborate between managed and unmanaged code, special measures must be taken.
So as you can see, migration is not free. But to Microsoft's credit, we do understand that with the innovation of the CLR, that this is a necessary step for their customers to evolve into their new platform, and with such a radical change nothing less could be expected. However, we feel obligated to warn users that the migration path will not be easy compared to J2EE migration path, as some might have you believe. Consider these statements from a recent Gartner report:
“‘This is fundamentally a brand new platform,’ said Gartner Analyst Mark Driver, comparing the migration to .NET as more drastic than the switch from MS-DOS to Windows. ‘This is the tiger changing its stripes...the migration to .NET will be a difficult one for IT departments because it represents such a major shift from the current Microsoft platforms. For instance, developers will have to rewrite as much as 60 percent of the code for some existing Windows applications if they want them to take advantage of Microsoft's .NET platform, Gartner analysts predicted. That's a frightening prospect for companies who are currently switching to Windows 2000, or for those who still run Windows 98 and NT.”
Portability
A key difference between J2EE and .NET is that J2EE is platform-agnostic, running on a variety of hardware and operating systems, such as Win32, UNIX, and Mainframe systems. This portability is an absolute reality today because the Java Runtime Environment (JRE), on which J2EE is based, is available on any platform.
There is a second, more debatable aspect of portability as well. J2EE is a standard, and so it supports a variety of implementations, such as BEA, IBM, and Sun. The danger in an open standard such as J2EE is that if vendors are not held strictly to the standard, application portability is sacrificed. CORBA, for example, did not have any way to enforce that CORBA middleware did indeed comply with the standard, and thus there were numerous problems with portability. In the early days of J2EE there were the same problems.
To help with the situation, Sun has built a J2EE compatibility test suite, which ensures that J2EE platforms comply with the standards. This test suite is critical because it ensures portability of applications. At the time of this writing, there were 18 application server vendors certified as J2EE-compatible. There are a myriad of other vendors as well that are not certified10.
Our opinion is that in reality, J2EE portability will never be completely free. It is ridiculous to think that complex enterprise applications can be deployed from one environment to the next without any effort, because in practice, organizations must occasionally take advantage of vendor-specific features to achieve real-world systems. However--and this is important--portability is exponentially cheaper and easier with J2EE and the compatibility test suite than with proprietary solutions, and that is a fact we stand behind through years of consulting with customers using a variety of J2EE solutions. Over time, as the J2EE compatibility test suite becomes more and more robust, portability will become even easier.
By way of comparison, .NET only runs on Windows, its supported hardware, and the .NET environment. There is no portability at all. It should be noted that there have been hints that additional implementations of .NET will be available for other platforms. However, a question remains - how much of the complete .NET framework will be (or even can be) supplied on other platforms? History has taught us to be skeptical of Microsoft's claims of multiple platform support. Microsoft ported COM to other platforms, but never ported the additional services associated with COM that were necessary to make COM useful. We find it hard to believe that .NET portability will ever become a reality given Microsoft's historically monopolistic stance.
So how important is portability to you? This is the key question businesses must ask themselves. When evaluating the importance of portability, there are three scenarios worth considering.
o If your firm is selling software to other businesses, or if you are a consulting company, and your customers are on a variety of platforms, we recommend specializing in J2EE architecture. Unless you can guarantee that every one of your customers will accept a Windows/.NET solution, you are restricting your salespeople from major accounts that may have solutions deployed on UNIX or mainframes. This is rarely acceptable at most ISVs or consulting firms.
o If, on the other hand, your customers are on the Windows platform, then either J2EE or .NET will suffice, since they both run on Windows. You should then ask your sales force and consultants what middleware your customers are using on that platform, and make your architecture decision from there. It's important to really be proactive and get this information--the more data you have, the better.
o If you host your own solutions, then you control the deployment environment. That enables you to pick J2EE as well as .NET. If you are willing to standardize on the Win32 platform, and live with the advantages and disadvantages of that platform exclusively, then platform neutrality is irrelevant, and you should consider other factors when deciding on J2EE or .NET. But we offer a word of caution: you can never predict the future. Business goals might change, new vendors might be introduced into the picture, and mergers and acquisitions might happen. All of these may result in a heterogeneous deployment environment. Your applications will not be portable to those platforms in this scenario.
We offer a final opinion to end the debate about just how important is portability. Although both J2EE and .NET will each have their audiences, think about what platform you would choose if you were an ISVs or a consulting company. Most likely you'd have customers on a variety of platforms, and therefore, you'd probably adopt the architecture behind J2EE because you don't want to lock yourself out of deals.
Indeed, we are noticing today that an incredible number of consulting firms and ISVs are standing behind J2EE, such as Vignette, Broadvision, Chordiant, Kana, NaviSys, and Versata.
What does this mean? It's not about the platform, it's about the applications. As time goes on, customers will likely choose the solution that not only provides the web services infrastructure, but the most consulting support and ISV applications as well.
This makes the future of J2EE very bright in our minds, and is one of the critical differentiators between J2EE and .NET.
Web Services Support
The future of eBusiness collaboration is undoubtedly web services. For organizations that are pursuing a web services strategy, or are preparing for the future of web services, their underlying eBusiness architecture must have strong web services support.
Today, J2EE supports web services through the Java API for XML Parsing (JAXP). This API allows developers to perform any web service operation today through manually parsing XML documents. For example, you can use JAXP to perform operations with SOAP, UDDI, WSDL, and ebXML.
Additional APIs are also under development. These are convenience APIs to help developers perform web services operations more rapidly, such as connecting to business registries, transforming XML-to-Java and Java-to-XML, parsing WSDL documents, and performing messaging such as with ebXML.
A variety of J2EE-compatible 3rd party tools are available today that enable rapid development of web services. There are at least sixteen SOAP implementations that support Java. Almost all of these implementations are built on J2EE (servlets or JSP). There are only five UDDI API implementations available, and four of them support Java (IBM UDDI4J, Bowstreet jUDDI, The Mind Electric GLUE, and Idoox WASP). Third-party software vendors such as Tradia (www.tradia.com ), CapeClear (www.capeclear.com ) and The Mind Electric (www.themindelectric.com ) also offer tools for creating web services.
The preview release of Microsoft.NET also enables organizations to build web services. The tools that ship with Microsoft.NET also offer rapid application development of web services, with automatic generation of web service wrappers to existing systems. You can perform operations using SOAP, UDDI, and SDL (the precursor to WSDL). Visual Studio.NET provides wizards that generate web services.
Our conclusions from our web services comparison are as follows.
With J2EE, you can develop and deploy web services today using JAXP. However, this is not the ideal way to build web services, since it requires much manual intervention. An alternative is for organizations to leverage 3rd party libraries to accelerate their development. In the future these libraries will be standardized through the JAX APIs. For now, if you develop web services rapidly, you'll need to bundle these libraries with your application.
With .NET, you can develop web services today using the partial release of .NET. However, since this is only a beta implementation, it does not represent a realistic deployment platform. Another issue with .NET is that it does not support true web services because of a lack of support for ebXML. ebXML is a very important standard for eBusiness collaboration, and is experiencing broad adoption from around the world. Thousands of vendor and non-vendor companies, government institutions, academic and research institutions, trade groups, standards bodies, and other organizations have joined the ebXML community. This includes HL7 (Health Care), OTA (Open Travel Alliance), RosettaNet, OAG (Open Applications Group), GCI (Global Commerce Initiative), and DISA (Data Interchange Standards Association). Undoubtedly, ebXML is going to be an important force in web services, and we hope that Microsoft chooses to embrace it. Microsoft is still clinging to their BizTalk proprietary framework which has proprietary SOAP extensions. This evidence makes us question Microsoft's true commitment to open and interoperable web services.
Tools
The Sun J2EE Product Portfolio includes Forte, a modular and extensible Java-based IDE that pre-dates both Sun J2EE and .NET. Developers who prefer other IDEs for Java development are free to use WebGain’s Visual Caf? IBM’s VisualAge for Java, Borland’s JBuilder, and more. Numerous 3rd party tools and open source-code products are available.
Microsoft has always been a strong tools vendor, and that has not changed. As part of its launch of .NET, Microsoft released a beta version of the Visual Studio.NET integrated development environment. Visual Studio.NET supports all languages supported by earlier releases of Visual Studio - with the notable exception of Java. In its place, the IDE supports C#, Microsoft’s new object-oriented programming language, which bears a remarkable resemblance to Java. Visual Studio.NET has some interesting productivity features including Web Forms, a web-based version of Win Forms, .NET’s GUI component set. Visual Studio.NET enables developers to take advantage of .NET’s support for cross-language inheritance.
Our conclusion is that Microsoft has the clear win when it comes to tools. While the functionality of the toolset provided by J2EE community as a whole supercedes the functionality of the tools provided by Microsoft, these tools are not 100% interoperable, because they do not originate from a single vendor. Much more low-level hacking is required to achieve business goals when working with a mixed toolkit, and no single tool is the clear choice, nor does any single tool compare with what Microsoft offers in Visual Studio.NET. Microsoft's single-vendor integration, the ease-of-use, and the super-cool wizards are awesome to have when building web services.
Shared Context
A key element of smart web services is shared context. To understand shared context, think about how many usernames, passwords, credit card information, and so-on that you need to remember and re-type in every time you visit a web site. The vision for shared context is that you type this information in once, and that information is then accessible to all web services that you choose to give access to that information. The information is under your control, rather than the control of the web services, and is protected using security rules that you define.
The Sun J2EE vision for shared context is a decentralized, distributed suite of shared context services that live on the Internet. Each user might have a list of one or more of their preferred shared context services, with each repository storing select information about that user. You would point the web service to your preferred shared context service when you connect.
Today, developers are empowered to create shared context services by writing a servlet that exposes itself as a web service using JAXP, and by using JDBC to access a relational storage.
In the future, Sun J2EE will include standards to access shared context services. This will enable the context repositories to act as web services using a standard interface, empowering other web services to connect with and tap into the shared context service in standard ways.
By way of comparison, Microsoft.NET achieves shared context via the Passport.NET service. Passport.NET is a repository hosted by Microsoft that contains user identity information. It is the cornerstone to Microsoft's Hailstorm services, which is their vision for creating user-centric web services experiences.
In conclusion, we have found that both Sun J2EE and Microsoft.NET support shared context, and each have their own advantages and drawbacks. The noticeable difference is that the Sun J2EE approach of a shared context standard will spawn a marketplace of shared context repositories on the Internet, whereas the Microsoft.NET solution is a single shared context repository approach.
The advantages of the Sun J2EE approach are:
o Each shared context repository can be specialized for different needs. For example, there could be medical repositories that store medical history information, or financial repositories that store credit card and banking information. It is unlikely that a single repository approach such as Passport.NET would be specialized enough to cover all the bases of shared context information that the industry demands when smart web services become widely used.
o There is no 'big brother' effect. Businesses and individuals do not need to trust their data to any individual firm. Local shared context repositories can be created within a trusted few partners in a business web, which means data can be contained.
o We believe the J2EE solution will will scale to handle the needs of the masses. The needs of the many better then Passport.NET. Shared context is a more important phenomenon than any one organization.
o There is no single point of failure.
o There is no control being enforced by a single organization. Can you envision a time when AOL agrees to use Passport? Or when VISA, MasterCard, or American Express agree to let Microsoft control their customers’ information? It is difficult to imagine just one vendor-controlled identity service succeeding for all.
The advantages of the Microsoft.NET approach are:
o There is no question of what is the 'official' shared context repository. There is one place to find identity information. This is a very important point. J2EE runs the risk of a fragmented shared context repositories, eliminating the usefulness of such systems, unless care is used.
o Passport is an established and active system.
o Until Sun J2EE standardizes on a schema and API for accessing web services that are shared context services, we do not predict any real usage of J2EE-based shared context services.
Given that almost no web services use shared context yet, it is too early to tell which approach is the best. Fortunately most organizations are barely getting up to speed with the basics of web services, and shared context is in the distance. For most organizations, this debate is likely to be important when choosing J2EE or .NET.
System Cost
A wide variety of implementations based on J2EE architecture are available for purchase, with price points varying dramatically, enabling a corporation to choose the platform that meets its budget and desired service level. Costs are typically in the single-digit thousands of dollars per processor, although there are higher-end implementations and lower-end ones. At the time of this writing, Microsoft had not released pricing information for the .NET platform.
As far as hardware, J2EE supports UNIX and Mainframe systems, while both J2EE and .NET support the Win32 platform, which is generally the less expensive alternative. There is a level playing field for hardware costs, and the hardware cost debate becomes a moot point.
The takeaway point is that you can get low-cost solutions with both Microsoft and J2EE architecture. Microsoft's solution has an aggressive price, whereas J2EE architecture allows you choose your service level. For example, with J2EE you can have a high-end, expensive solution (iPlanet running on Sun Solaris in an E-10000 server), or a low-end, inexpensive solution (jBoss running on Linux on a Cobalt RAQ server). There's also an assortment of free and/or open source tools and services that support Java and XML. It should be noted that you pay for what you get, and most organizations will not go for this low-end solution, but rather will embrace a midrange solution as a happy medium.
If you are trying to make heads or tails out of the price wars, we recommend that you consider this: the price of the platform is always a drop in the bucket compared to the total cost of the project. This is defined as the price of the server platform, the cost to train developers, the cost to build and evolve a solution on that platform, the cost to maintain the solution, and any business opportunity costs from picking the 'wrong' platform.
We hope that firms realize that the total cost of ownership of a project dwarfs any short-term cost differences between underlying platforms. We recommend you do not consider the price of the platform when selecting between J2EE, .NET, or any other platform, but rather consider the more important other factors.
Performance
A platform performs if it yields an acceptable response time under a specified user load. The definition of what is 'acceptable' changes for each business problem. To achieve acceptable performance, it is important that the underlying web services infrastructure empowers you to build high-performing systems.
The primary bottleneck when building web services is usually integration with back-end database systems. The reason for this is that most enterprise applications are data-driven systems with much more data logic than business logic. Given that the database is usually the bottleneck, any possible tactics for reducing database load will result in a significant wins.
J2EE reduces database traffic through two tactics:
Stateful business processes allow you to maintain business process state in memory, rather than writing that state out to the database on each request.
Long-term caching(provided by some implementations) allow for database data to be cached for long periods of time, rather than re-reading database data upon each request.
It should be noted that both maintaining business state in-memory and caching must be used with caution, and may result in problems if developers are not properly trained on when to (and when not to) use these features. This is a fundamental difference between the J2EE and .NET approaches to building web services: J2EE's advantage is that it gives programmers more control over lower-level services such as state management and caching. Well-educated developers can tap into these features to improve the quality of their deployment. But it is of vital importance that developers are properly educated on when to make these tradeoff decisions, or error may be introduced into systems.
By way of comparison, Microsoft.NET does not offer these tactics for improving performance. There are no opportunities for performance wins, but at the same time, there are no opportunities for developers to introduce errors into systems.
When trying to choose between whether these features are important for your organization, consider the quality of your developers. If they are well-educated and do not require much hand-holding, then they will likely find the flexibility and performance gains from a J2EE system as valuable. If your developers require more hand-holding, then the Microsoft approach is clearly superior.
Scalability
Scalability is essential when growing a web services deployment over time, because one can never predict how new business goals might impact user traffic.
A platform is scalable if an increase in hardware resources results in a corresponding linear increase in supported user load while maintaining the same response time. By this definition, the underlying hardware (Win32, UNIX, or Mainframe) is irrelevant when it comes to scalability, because both J2EE and .NET allow one to add additional machines to increase user load while maintaining the same response time. The major implementations based on J2EE architecture, as well as .NET, provide load-balancing technology that enable a cluster of machines to collaborate and service user load that scales over time.
The significant difference between J2EE and .NET scalability is that since .NET supports Win32 only, a greater number of machines are needed than a comparable J2EE deployment due to processor limitations. This multitude of machines may be difficult for organizations to maintain.
VI. Conclusions
The J2EE verses .NET battle will be the soap opera of the decade for geeks to watch. But there are promises and realities about both platforms. For example, J2EE is a rather brilliant move on the vendors' part, but should not be seen as an altruistic initiative. All vendors that participate in J2EE are after financial gains, as well as an effective weapon against Microsoft. J2EE enables these vendors to collaborate together and stand ground. Many of these vendors have undergone recent mergers and acquisitions themselves, and so organizations must exercise good judgment when choosing such a platform.
As far as Microsoft.NET, that is far from an altruistic initiative. It is a monopolistic initiative dressed in altruism. Microsoft has been claiming that .NET is about open and interoperable web services, when in reality Microsoft is already making their web services closed and proprietary. Microsoft will likely increase the costs of their solutions if a monopoly can be achieved, and innovation will be slowed down significantly.
So what's a company like yours to do? Both platforms are useful, and both can lead you to the same destination. Which platform is right for you? When deciding, we recommend you concentrate on the larger business issues. Think about your existing developer skillsets, your existing systems, your existing vendor relationships, and your customers. Those almost always drive the decision, not the minor features.
Arguments supporting both platforms
o Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE, OO training for .NET)
o You can build web services today using both platforms
o Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or Windows/Win32 hardware for .NET.
o Both platforms offer a single-vendor solu
