[aru-ufmg] J2EE vs .NET

  • From: "rubralinux" <rubralinux@xxxxxxxxxx>
  • To: "Felipe Naves" <fnaves@xxxxxxxx>
  • To: "Lista UFMG II" <aru-ufmg@xxxxxxxxxxxxx>
  • Date: Fri, 21 Feb 2003 09:46:35 -0300

Web Services Face-Off: J2EE vs. Microsoft's .NET*

The headline begs the question: Are Sun and Microsoft at 
it again? No, at least not in the traditional sense. 
With the proliferation of Web services on the horizon, 
businesses need to make intelligent decisions about 
their Web services initiatives. The two contenders for 
building XML-based Web services are the Java? 2 
Platform, Enterprise Edition (J2EE?), built by Sun and 
other industry leaders; and .NET, Microsoft's own 
development framework for Web services. Don't worry, no 
one is going to throw any punches?other than a blow-by-
blow comparison of the rival architectures, that is.

Let's start with some similarities between J2EE 
and .NET. Both frameworks evolved out of application 
server technology used for building business 
applications. Each camp agrees that SOAP, WSDL, and UDDI 
are good things and will be linchpins for the success of 
Web services. They also agree there is a great deal 
of "plumbing" that goes into building Web services, like 
interoperability, load-balancing, and transactions.

Now, onto the good part?the areas where J2EE and .NET 
diverge. Sun collaborated with other industry leaders 
like BEA, Oracle, and IBM to define J2EE. The primary 
goal of J2EE enthusiasts is to give customers a choice 
of vendors and encourage quality products through 
increased competition. To this end, they created an 
industry standard with J2EE. Microsoft's .NET framework, 
on the other hand, is a rewrite of Windows DNA that 
includes a Web services layer.

Here's an important distinction if there ever was one: 
J2EE is a standard embraced by more than 50 
vendors; .NET is a product developed by a single vendor. 
Another example of the industry momentum behind J2EE can 
be seen with the Java Community Process (JCP), a 
community of 500 individuals and companies working to 
enhance the J2EE specification and create new 
interfaces. The specifications are created by subject 
matter experts within the international Java developer 
community. With such a diverse group of developers, it's 
not a stretch to say that there is likely a far greater 
brain trust behind J2EE than .NET, which is a closed 

Given J2EE's wide adoption throughout the industry, 
numerous tools, products, and applications have been 
developed to support J2EE?more than any one vendor could 
provide. Yet, for an organization that desires the 
simplicity of a single-vendor approach, J2EE provides 
this option as well. Many of the larger players, like 
Sun, offer a complete Web services solution. Taking that 
a step further, the J2EE platform also offers single-
vendor solutions for legacy applications in any 
environment. Quite the opposite, .NET only supports 
legacy Microsoft customers.

Since we're on the topic of legacy systems, let's talk 
integration. Legacy integration is one of the most 
difficult hurdles to cross when building a Web service. 
It's also the most necessary of evils. J2EE offers a 
cost-effective way to remedy integration headaches 
without rewriting legacy applications and rewriting 

The crown jewel of legacy integration is the J2EE 
Connector Architecture (JCA). The JCA is a specification 
for plugging in "resource adaptors" that can talk to 
existing enterprise information systems. And if an 
adaptor isn't available, it can be created. In fact, 
there is tremendous buy-in for the JCA, and many vendors 
are designing adaptors to streamline enterprise 
application integration. While .NET does provide some 
legacy integration via its Host Integration Server 2000, 
it doesn't currently offer anything of the caliber of 
the JCA.

Another key consideration when investigating a Web 
services architecture is platform maturity. Web services 
must be reliable, scalable, and high-performance. The 
quality of deployed Web services will depend on all 
layers of the platform, from the hardware, to the 
operating system, to the Web services components and 
management tools. Sun has always viewed the world from a 
services model perspective and has built a mature, 
proven, and stable platform in J2EE. When it comes to 
service-oriented platforms, Microsoft is the new kid on 
the block. So, Microsoft may have a solution for Web 
services but its long-term tenure in this space is 

No one captures the next point of difference better than 
Java creator James Gosling: ".NET is a product from a 
company. J2EE is a market." J2EE is really about working 
in an economy of partners, developers, and vendors, as 
opposed to .NET's single-vendor solution. For example, 
many consulting firms and ISVs are backing J2EE so 
customers not only get a robust Web services 
infrastructure, but a broad range of consulting support 
and ISV applications, as well. Think too about the 
momentum behind open process communities. When numerous 
programmers can easily build and customize a piece of 
software, innovation and improvement happens at 
astonishing rates. The same holds true for the J2EE 
because future requirements of the platform aren't 
dictated by a single company, as in the case of .NET, 
but by an entire market through the JCP.

The corner of the ring that you stand behind depends on 
many factors?your existing systems, your relationships 
with customers and partners, and the skill set of your 
developers, to name a few. Both J2EE and .NET are 
formidable contenders. Still, the Web services framework 
that is supported by industry heavyweights, is mature 
and stable, eases integration woes, is open, works well 
with other platforms, and packs a pretty big punch.

*On Thursday January 9, 2003, Microsoft dropped ".NET" 
from the name of their flagship Windows server OS, 
changing it to simply "Windows Server 2003". 

E-mail Premium BOL
Antivírus, anti-spam e até 100 MB de espaço. Assine já!

Subscribe List:
Unsubscribe List:

Other related posts:

  • » [aru-ufmg] J2EE vs .NET