.NET 对 J2EE[2]
Picking a Winner: .NET vs. J2EE
Although both frameworks stand on a foundation of programming languages, object models and virtual machines, they are strikingly different when you consider the design goals of their runtime environment.
The Java 2 Enterprise Edition (J2EE) framework has captured significant mindshare among online application developers and their organizations, as a powerful, portable and widely-supported application development environment. Microsofts announcement of .NET (dot-NET) has captured the attention of just as many, since it represents the future direction of all things Microsoft, from desktop applications like Microsoft Office to development tools like Visual Studio to back-end servers like SQL Server, and everything in between.
Opinions on the ultimate outcome of this framework competition range far and wide—zealots on either side of the "demilitarized zone" claim emphatically that either Sun and J2EE or Microsoft are doomed to fail. Some of the more balanced 易做图ysts predict a near-term stalemate, with J2EE and dot-NET eventually claiming a roughly equal share of the application development market. This prediction seems the most sensible, given the two forces facing off—J2EE with a significant amount of development inertia and a broad array of tool and application vendors behind it, and dot-NET with the marketing influence of Microsoft fueling its spread.
Regardless of the long-term result, it seems unavoidable that technology managers, strategists and software developers will have to contend with both of these frameworks for some time to come, and Ive tried to provide some guidance to the development community around this "framework divide." Whether youre part of an organization committed to either J2EE or Microsoft platforms, trying to assess the costs and benefits of sticking with your current framework, jumping to the other or attempting to support both; or if youre an organization about to venture into a development effort and attempting to pick the most suitable path, Ive attempted to lay out the two frameworks as clearly and unambiguously as possible.
(Half-)Sisters Under the Skin
Its important to acknowledge that despite what the best marketing minds at Sun and Microsoft might lead you to believe, dot-Net and J2EE are surprisingly similar from a pragmatic standpoint. Both offer a server- and client-side component model for assembling enterprise applications, APIs that allow you to create both fat and thin user inte易做图ces for these applications, and specifications and corresponding APIs that allow you to access critical services such as transactional data sources, directory services and remote objects.
At a lower level, the two frameworks are both based on a virtual machine architecture aimed at portability (though the type of portability each strives for is a critical difference between the two). Also, J2EE and dot-NET are comparable in some areas in terms of feature support and architecture.
Dont Know Beans?
When J2EE was introduced by Sun, it subsumed, to a large degree, the JavaBean and Enterprise JavaBean component models. JavaBeans are the meat-and-potatoes Java components, with well-defined properties, event-handling provisions, persistence through Java serialization and introspection, in addition to all of the basic services provided by the Java runtime environment, like memory management, "sandbox" security and the core Java APIs. Enterprise JavaBeans are the distributed equivalent: remotely-accessible components that operate within an environment that provides application security, distributed transaction support, richer persistence management facilities, life cycle management and resource pooling.
The dot-NET framework, meanwhile, subsumes Microsofts workhorse COM and COM+ component models. These component models are replaced, in a sense, by the new component architecture of the dot-NET framework. The Common Language Runtime (CLR) now provides "sandbox" security and basic services like garbage collection, similar to the Java Virtual Machine, which were not available previously in the COM and COM+ environments. It also extends the component model itself with features such as multiple inte易做图ce inheritance, extensible meta-data and a new delegate model. So the CLR defines a new, richer component model, which COM and COM+ components can be mapped into, and which is accessible by COM and COM+ components, but it is separate and distinct from COM. This has fueled doubts as to whether COM and COM+ will continue as "first-class" supported programming models in Microsofts product line (See Don Boxs article, "House of COM," in the December 2000 issue of MSDN magazine on how the new CLR environment differs from the COM environment).
Microsofts support for components has a long history, driven in part by the fact that it provides the principal visual IDE for Microsoft developers (Visual Studio and its predecessors). Microsoft has had the luxury of taking its component model through several iterations of improvements, despite the subsequent churn inflicted on its developers. Javas component model inherited the institutional learning that came before it, but improvements to the Java component model are handicapped to some degree by its dependence on the Java language and the open nature of Javas evolution.
The Skinny on Fat Clients
For "fat" GUI clients, J2EE offers the Java Swing API, with a palette of standard GUI JavaBean components that can be assembled programmatically, or pulled into visual GUI design tools like WebGain (formerly Symantec) Visual Cafe, Borland JBuilder, IBM VisualAge for Java and so on. For thin-client development, the servlet and JavaServer Pages (JSP) standards provide ways to build HMTL, WML, XML and other thin inte易做图ces on top of a Java middle tier. Java servlets and JSPs are supported by a number of application server vendors, both commercial (such as BEA WebLogic, iPlanet, IBM WebSphere and SilverStream), and open source (for instance, Apaches Jakarta project, Enhydra and Resin).
In the past, Microsoft has offered "fat" client support through its Microsoft Foundation Classes (MFC) API, but dot-NET offers a new set of components: Windows Forms. Windows Forms fill the same functional role as MFC, but they are plugged into the new dot-NET runtime framework and component model. Similarly, on the thin-client front, ASP.NET is the dot-NET successor to Active Server Pages (ASP): Functionally, it fills the same role as a thin-client (HMTL, WML or XML) paradigm for applications, but ASP.NET pages participate in the new CLR. In this case, that means that code snippets and component references can be added to pages using any CLR-compliant language, and ASP.NET pages are compiled into the IL-based CLR runtime, rather than interpreted, as ASP pages are.
Data Sources and Directory Services
J2EE and dot-Net both support, in different ways, a few strategic APIs and services such as access to data sources and directory services, and general-purpose XML support for applications. Access to data sources within the Java environment is handled through JDBC, an RDBMS-independent Java specification for inte易做图cing with relational databases. Specific vendor RDBMSs are supported through JDBC drivers, which are available for all of the popular commercial and open-source database options.
JDBC is a fairly low-level API, in that it models database access in terms of Connections, Statements and ResultSets. JDBC 2.0 and its standard extensions add useful services suc
补充：软件开发 , Java ,
