.NET and J2EE Battle for the Enterprise

　　Components are a key part of the J2EE/.NET model; think of them as collections of objects packaged and deployed together for simplicity, reusability, and flexibility. On the Java side, think "component" whenever you see "bean." .NET Enterprise Services and J2EE's Enterprise JavaBean (EJB) features are especially powerful for enterprise components, offering object and connection pooling and robust load balancing services.

　　UML-based tools are often used for J2EE/.NET application analysis and design, both because UML's object orientation is ideal for the J2EE/.NET implementation model and because of the expanding scope and complexity of today's enterprise endeavors. Although the approaches diverge at the coding/implementation phase, a common set of analysis and design techniques applies to both J2EE and .NET.

　　The use of a virtual machine (VM) architecture is also common to J2EE and .NET. Application development tools—such as Borland JBuilder, Sun Forte for Java, and Microsoft Visual Studio .NET—produce intermediate-level code instead of platform-specific binary code, which means the VM interprets that code in real time or performs Just-In-Time (JIT) compilation; the Microsoft VM always runs JIT-compiled code. This VM-based model results in platform-independent applications and is conducive to the late-binding technique that's critical to the OO approach.

　　J2EE and .NET share an asynchronous, loosely coupled, service-centric communication model, with application flow of control determined by messages among objects instead of sequential flow within monolithic programs. The newer model is more appropriate for the inherently object-oriented natures of J2EE and .NET, but it leads to a potentially steep learning curve for developers who are accustomed to the more traditional program-flow approach.

　　Finally, J2EE and .NET share a broad common foundation of standards, especially around XML and Web services. Web services are rapidly becoming the neutral zone between J2EE and .NET because they offer a self-describing, vendor- and technology-independent means of inter-application communication over the Internet. If it weren't for Web services, J2EE/.NET interoperability would be much more problematic and Internet-based communication among applications based entirely on either .NET or J2EE would be much more complex.

　　The multi-tiered approach typically followed for J2EE and .NET applications helps separate presentation from structure (for example, HTML at the presentation layer and XML at the business logic layer, and transaction from user interaction [see Table 1]).

　　Given the scope of the new enterprise model, it's important to follow an approach that supports role specialization so that all developers shouldn't feel it's necessary to understand the entire big picture (see Table 2 for J2EE/.NET perspectives by enterprise application development role types).

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

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