.NET 对 J2EE[2](二)

2014-11-23 21:39:35 · 作者: · 浏览: 20
s 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 interface 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 interfaces 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 da