.Net or J2EE?

In the face of rampant bias and exaggeration from both J2EE and .NET camps, how can you decide which of these great platforms will give you, your web services project and your company the best return on investment?

The more we at SpiritSoft thought about the question, the more this sounded like the kind of agony questions typically posed to a gossip columnist like "Should I date a Gemini?" or "Should I practice monogamy in my dating relationships?". As with most dilemmas, it's hard to make the right choice; it depends on understanding your particular problems, and matching them against the strengths and weaknesses of each of these platforms.

So we thought we would try and answer the .Net or J2EE debate with a slight Ann Landers or Dear Abby twist. Here's a multiple choice quiz that we hope will help you in your decision:

Are you building desktop or server side applications?

Your choice of platform will be strongly influenced by the kind of application you are building. An investment bank may need to use complex derivative pricing algorithms that are encapsulated in existing spreadsheets or DLLs; a manufacturer relies on its enterprise resource planning software:

1. We are building complex client side applications that have to interface with spreadsheets, email, or word processing as well as accessing web services-based components
2. We're building distributed web services that will expose our existing enterprise applications to our partners; we need to think about throughput, latency, reliability and recovery
3. We think web services are real neat, and we thought we could spend some time playing with them

Are you writing new code, or bundling existing code into web services?

Microsoft's development tools are legendary; they get you from nowhere to a functioning application in double-quick time. But they have not mastered round-trip and re-engineering, or the range of well thought out development patterns now being implemented in the Java community. It seems .NET is geared towards instant gratification - support for open asynchronous messaging standards (like JMS - the Java Message Service) is simply not in place.

1. We're going to put our best Visual programmers on the job - they'll soon have it licked
2. We rely on applications written over the last 10-25 years; we talk to these through asynchronous message queues, and JMS lets us integrate our legacy messaging systems into J2EE
3. We want to make the best of the infrastructure we've already got, but we're prepared to invest in rewrites where necessary

What platform and language skills do your developers have already?

It's tough to go against the grain. Re-training staff is time- consuming and expensive. If you're a Microsoft shop, or rely on multiple languages, then you probably have the right infrastructure to support .NET; even COBOL programmers can join in:

1. We already use Visual Studio for development
2. We program in Java of course - that's what we all learnt at school
3. We've outsourced or downsized our development group - we hire contractors whenever we need any work done

How many users will there be, who are they and where are they?

Distributing complex client applications to hundreds of users can be a major cost. Do you need to be thinking about standardized desktop configurations and software asset management? Will Java applets take too long to download? Do you need to think about page caching or a multi-tier caching framework?

1. We will have hundreds of users, mostly within the firewall, running on a managed desktop.
2. We expect to have thousands of users on the internet, and we can't be sure what technology they have - other than a browser
3. We are integrating intranet, internet and mobile users with our call center and we want to offer the same services through every channel

Are you an independent software vendor?

Both Microsoft and Java platforms support huge - and partially overlapping - economies of software vendors. Which would you like to play in?

1. We would like to compete with Microsoft - maybe they'll make us an offer!
2. We're looking forward to extensive "co-opetition" with IBM, Oracle, Sun, HP, BEA, …
3. We think our niche is too specialized for any of the big companies to take too close an interest - we'll just leverage their platform and tools

How did you do?

• Mostly (a): you're probably already looking at .NET, even if you haven't started using it in anger yet.
• Mostly (b): it sounds like you should be thinking about J2EE.
• Mostly (c): Congratulations! You're in the real, confusing world where there are no easy answers. Now, get down to the real evaluation!

The final choice

Really - religious differences aside - you can legitimately choose either or both platforms. "The question is not whether J2EE or .Net is the better architecture," says Yefim Natis, an analyst at Gartner Inc. in Stamford, Conn. "The question is, how to integrate them, how to make them work together, what are their strengths and weaknesses?".

With web services standards in place, architects can assemble complex applications where Microsoft "owns" only the fat client piece, and the Unix/Java world takes over - or at least gets a goodly share of - the server side (and some thin clients); a return to the typical "client/server" split of the early 1990s, but with internet and web services rather than the LAN as the common connection bus, and with a more complex network of loosely- coupled processes.

Software vendors - even those like SpiritSoft who are firmly in the Java camp - have to recognize that .NET has considerable merits - and even if we don't wholly approve, in the real world our customers are bound to adopt it to a greater or lesser extent anyhow. We can't simply ignore it and hope it goes away.

We can either whole-heartedly embrace it - or we can contain it, by offering Web services- based interoperability with J2EE. That way Java software vendors will ensure that we continue to have a major part to play in the heterogeneous environments that will inevitably be found in most real enterprises, and that our customers don't get trapped into a false choice by one side or other.