企业应用中.Net和J2EE的对比分析

转载 2004年10月16日 19:27:00

.NET and J2EE Battle for the Enterprise

Peter O'Kelly (来自中国系统分析员)   2003年03月01日

Keeping track of the ongoing rivalry between Microsoft and Sun Microsystems as they seek to control the enterprise application development market can puzzle even the most dedicated developer. For the software architect, the competing "standards" can be bewildering. Yet would you believe that today's choices actually make it a relatively easier time for enterprise developers, compared to the previous generations of tools?

Microsoft and Sun share compelling visions for a new enterprise architecture, and each vision features strong interoperability through Web services and various standards.

It's certainly easier to deal with the .NET Framework and the Java 2 Platform Enterprise Edition (J2EE) now rather than handle five or ten largely incompatible visions, which is where the middleware industry was headed previously.

One of the most widely debated questions in the industry today is whether to choose Microsoft .NET or J2EE. From an enterprise architectural planning perspective, .NET and J2EE have a great deal in common and developer skills transfer nicely between them. J2EE products from vendors such as BEA, IBM, Macromedia, Oracle, and Sun have matured to the point where it's necessary for enterprise architects to place bets on either .NET or J2EE or both; the vast majority will place bets on both. For these reasons, think of .NET and J2EE as complementary, not competitive.

It's not surprising that the J2EE/.NET domain has been controversial and confusing. To begin with, both represent the culmination of decades of software evolution. For instance, Sun's J2EE 1.3 tutorial weighs in at more than 700 pages, and there are many books on J2EE and .NET that tip the scale at more than 1,300 pages. Such heft is not surprising, given that these documents attempt to address almost the entire computing spectrum, from enterprise middleware to handheld devices.

J2EE and .NET are also dynamic and fast-moving projects, each building on a large number of standards initiatives, especially for XML and Web services. As these standards are thrown together with the usual software industry marketing and propaganda, J2EE/.NET competition is so intense that it's often difficult to remember what the software market was like before they arrived. (Anyone embarking on a career in IBM's CICS or BEA's Tuxedo these days?)

Clear Up the Terminology

The inconsistent use of terminology has complicated the understanding of similarities and differences between the two models. Terms such as objects, components, and services are used in both models, for example, but often with subtly different meanings. It doesn't help that the press and industry analysts often compare specifications with product releases, and are imprecise about what's included in current releases versus what's planned for the future.

Even the scope of the competitive offerings is confusing. For example, J2EE products often include integration and portal services, while .NET is generally used as a blanket term to describe all future Microsoft software and services. Standing back from the hype and dynamic definitions, however, it's possible to discern many ways in which J2EE and .NET are converging toward a common enterprise architecture model.

At the core of an enterprise application, there's almost always a database management system (DBMS), transaction processing (TP) monitor, and message-oriented middleware (MOM) service included, such as IBM WebSphere MQ, Microsoft Message Queuing (MSMQ), or TIBCO. Indeed, in most enterprise contexts there are usually multiple instances of each, although they're increasingly morphing into platform services instead of distinct server product categories—a trend accelerated by the advent of Web application servers.

In the J2EE/.NET model, both the underlying DBMS/TP/MOM services and the business application contexts are managed at an object-oriented (OO) level of abstraction. The J2EE/.NET model brings the OO approach to mainstream enterprise computing, with powerful OO frameworks (class libraries) for services such as object persistence, transactions, Web services, and more. This model greatly extends the scope of work that can be done declaratively (with little or no procedural coding), and often includes a page/form/layout-driven drag-and-drop approach for application development.

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]).

netj2ee.gif

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).

netj2ee1.gif

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.

Finally, see for yourself. Sun, Microsoft, and other vendors have conveniently provided a set of resources that simplify the processes of exploring and comparing .NET and J2EE, and highlight both the common elements and the ways in which the approaches diverge.

Sun created a Java Pet Store reference application as part of its Java blueprint. This sample application is representative of common enterprise applications. For example, it includes components for customer, order, product, and shopping cart implementations. It's a nontrivial reference, with more than 700 individual files in the 1.3 version. Not surprisingly, Microsoft and other vendors have seized upon the Pet Store application to showcase their products. Microsoft's version provides a useful means of comparing the .NET and J2EE approaches, especially in terms of understanding the different component middleware approaches embodied in EJB and .NET components.

Don't Worry, Make Users Happy

If you're like most enterprises, you'll migrate gradually to J2EE and .NET. Especially during tight economic times, nobody is eager to "rip and replace" working applications, and most enterprises will wait for more case studies before placing strategic bets on either technology.

Enterprises that focus on common areas between J2EE and .NET will benefit most because they'll leverage the transferability of skills and produce more reusable application components by using analysis and design techniques that apply to both, such as OO analysis and design using UML. Clearly, enterprises should work with their application and service suppliers to ensure that the suppliers' J2EE/.NET priorities align with their own. It would be unfortunate, for example, if a .NET-committed shop learned that its leading application vendor was leaning toward J2 EE instead of .NET—although it wouldn't exactly be the end of the world, thanks to XML Web services interoperability.

Almost all organizations will use a mix of J2EE and .NET, in part because the underlying platform choices are often dictated by existing application decisions. If your accounting department is already running Microsoft Great Plains, a J2EE version isn't likely to appear soon. Also, most organizations already use a mix of legacy Microsoft and Java-based tools and services, with the possible exceptions of Microsoft itself and some of the J2EE vendors, such as Sun.

Overall, you should anticipate that the coming enterprise architecture model will result in a raised least common denominator for enterprise applications and middleware, which will simplify and extend what was previously possible. Perhaps most significantly, as back-end development tasks are simplified, you'll actually be able to devote more attention to areas that directly impact the user experience and productivity. Imagine the benefits that directly impact user experience and productivity, such as a richer user experience and support for multiple device types. PDAs, smart phones, set-top boxes, and game consoles could be your next calling.

J2EE与.NET技术架构的比较

一、J2EE简介 J2EE体系结构图:                          1.组件-容器模型 J2EE是一个基于组件-容器模型的系统平台,其核心概念是容器。容器是指为特定组件提供服务...
  • kanglix1an
  • kanglix1an
  • 2014年06月04日 19:36
  • 8283

.net 和 j2ee的区别

.net 和 j2ee的区别关于.NET技术与Sun公司的Java2企业版(J2EETM)相比较,许多客户都想了解Microsoft公司的观点。由于以下的几个原因,.NET和JEE的比较有点棘手:1)...
  • tyouvivi
  • tyouvivi
  • 2007年04月24日 09:27
  • 1281

J2EE 企业级应用架构简述

企业应用的特点 多环境多系统的交互海量数据、高并发、高TPS安全等级高自动化集群管理 架构的原则 CAP原则(一致性、可用性、分区容错性)复杂的事情简单化 ...
  • zwx19921215
  • zwx19921215
  • 2017年03月12日 20:12
  • 784

.Net与J2EE的快餐型比较,纯属个人之见

经常有客户问我,到底用微软平台还是Java平台的问题。其实这是一个永远没有结果的悖论,只能陷入空对空的空谈。不过如果抛弃个人喜好与特定客户的历史原因来客观地考虑,二者之间的确是微软平台的优势更加明显一...
  • gongfs
  • gongfs
  • 2009年08月26日 16:56
  • 44150

【杂谈】PHP和J2EE比较(转)

我们该如何选择?java还是php?《Java和PHP的web开发技术比较》 比较PHP和JSP这两个web开发技术,在目前的情况是其实是比较PHP和Java的Web开发。以下是我就几个主...
  • u013517797
  • u013517797
  • 2015年02月02日 15:59
  • 2389

LAMP与J2EE与 .NET三者的比较

为了开发一个动态网站出来,有3中选择,三种选择是一种三足鼎立的一种状态:LAMP   J2EE  .NET,各有各的好,下面自己总结一下 1、ASP.NET ASP.NET 的开发框架是 ...
  • lonsegdi
  • lonsegdi
  • 2015年08月02日 08:54
  • 2568

深度解析:J2EE vs .NET开发平台

看到这个标题,也许会有人表示疑惑,J2EE和.NET并不在一个层次上,怎么能将它们放在一起呢?需要指出的是,通常所说的.NET包含了一个相当广泛的产品家族,包括开发平台、操作系统、服务器、终端设备等,...
  • java060515
  • java060515
  • 2007年07月27日 09:02
  • 14923

选择加j2ee还是.net,比较

 毫无疑问,程序员,软件开发商,企业IT经理一直都在密切的关注着J2EE和.NET的发展,但是选择一个在性能,价格,时间上满足他们需求的平台却并不是一件简单的事情。本文试图在技术上做一个简单的比较,希...
  • hy1234
  • hy1234
  • 2007年04月11日 16:06
  • 445

asp、php、asp.net、jsp介绍及优缺点比较

asp、php、asp.net、jsp介绍及优缺点比较 现在主流的网站开发语言无外乎asp、php、asp.net、jsp等。 北京网站制作从开始简单的hmtl到复杂的服务语言,走过了10多个年头...
  • qq_21439971
  • qq_21439971
  • 2015年10月17日 13:06
  • 4235

轻量级JavaEE企业应用实战(五)

虽然常把基于WEB应用称为B/S架构的应用,但其实WEB应用一样是C/S结构的应用。只是这种应用的服务器是WEB服务器,而客户端是浏览器 application对象对于大部分浏览器而言,通常负责三种...
  • qq503318485
  • qq503318485
  • 2015年12月16日 18:08
  • 517
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:企业应用中.Net和J2EE的对比分析
举报原因:
原因补充:

(最多只允许输入30个字)