.NET and J2EE Battle for the Enterprise

　　Here's Where They Differ

　　Although there's much common ground between J2EE and .NET, significant differences remain. Before moving forward, you'll need to make some choices. First, decide whether you want to program in a language other than Java. J2EE naturally focuses on the Java programming language, while .NET supports multiple programming languages—primarily C# and Visual Basic .NET, but also many others, ranging from Cobol to Eiffel. Language developers must comply with the .NET common language interface to take full advantage of the .NET common language runtime (CLR) and Framework. (It's definitely not your father's Fortran or Cobol.) There's nothing inherent to the JVM that precludes your using it with other programming languages, but at this point Sun is singularly focused on the Java programming language for its Java platform.

　　Another question for you to answer is how many platforms your shop supports. Beyond run-almost-anywhere HTML/JavaScript client support, Microsoft addresses only Microsoft server platforms with .NET, while J2EE products are available on a wide variety of platforms (including Windows). At least one vendor, Ximian, is focused on porting more of .NET to non-Microsoft platforms, but it's by no means clear whether they will be successful (or if Microsoft will allow them to ship anything broader than the parts of .NET standardized by the European Computer Manufacturers Association [ECMA]). Interoperability is strong, thanks to Web services, and both .NET and J2EE support client platforms using HTML, JavaScript, and Macromedia Flash, but the server- and middle-ware-centric parts of .NET currently run only on Windows servers.

　　Is multi-vendor support an important consideration for you? Only one vendor supports .NET, while multiple vendors support J2EE. However, cross-vendor portability for J2EE is definitely not the fabled "write once, run anywhere" scenario. This is due in part to its organic growth model, where vendors add their own Web service features and other ex-tensions ahead of the J2EE specification process. J2EE vendor portability can be achieved by focusing on the parts of J2EE that are fully covered in the J2EE specification—such as servlets—but doing so is currently very constraining and even impossible. For example, EJB deployment dimensions aren't completely addressed in the J2EE specification.

　　Decide how important an in-market track record is to your organization. J2EE products have been available for years, while the first products incorporating the .NET CLR and Framework were released only at the beginning of 2002. Even though some key elements of .NET are based on Microsoft products and services that have been available for years (.NET Enterprise Services, built on the COM+ architecture, first appeared in 1996 as part of Microsoft Transaction Server), the J2EE product market is more mature.

　　Whichever way you go, be assured that both .NET and J2EE are rapidly evolving, as are the standards upon which they're based. Currently .NET leads in Web services, while J2EE has a broader overall scope. In general, you can expect both to evolve and expand very rapidly.

　　So far, the J2EE EJB model is more elaborate than its .NET counterpart. EJB flavors include (stateless and stateful) session beans and entity beans (component- and bean-managed), while .NET currently only includes support for components similar to stateless session beans. This represents a difference in architectural vision between Microsoft and the Java Community Process (JCP). Debates will continue until more real-world experience is available to help determine which approach is most effective for enterprises.

　　Determine whether ECMA standardization is important to your team. Sun controls the JCP and owns the Java specification. Although Microsoft maintains similar control over .NET, it has submitted key parts of it to ECMA for standardization. Despite its reputation as a predatory competitor, Microsoft could well out-maneuver the Java camp in terms of creating and building on industry standards.

　　Third-party support issues may have already made the decision for you. Component marketplaces are very practical for both J2EE and .NET. While such marketplaces have historically been limited primarily to Visual Basic add-ins, the rich component and Web service models supported in both J2EE and .NET are conducive to much broader component marketplaces. Support from application software vendors such as PeopleSoft, Siebel, and SAP will also contribute to the relative J2EE/.NET momentum. If SAP, for example, were to introduce a new version of its application suite that can be used as components in J2EE but not .NET, such a move would influence the strategies and priorities of enterprise application architects worldwide.

更多軟考資料請(qǐng)?jiān)L問：考試吧軟件水平考試欄目

希望與更多網(wǎng)友交流，請(qǐng)進(jìn)入考試吧軟件水平考試論壇