Telstra’s decision to standardise on Sun Microsystems-backed J2EE (Java 2 Enterprise Edition) technology for its future application development surprised Australia’s IT community.

For Telstra, Microsoft’s largest private-sector Australian customer, to pick J2EE over Microsoft’s own .NET architecture sent shock waves all the way to Redmond. Microsoft president Steve Ballmer wasted no time coming to Melbourne, and his smiling embrace upon emerging from discussions with Telstra suggested that the relationship was back on track.

That such a seemingly small announcement could cause such a large stink reveals just how serious the stakes have become in the brewing battle for control of the enterprise.

In one corner is Microsoft, which has made it clear that its .NET strategy—announced nearly two years ago in a fanfare of enthusiasm that’s set to explode with the frequently-delayed launch of Windows Server 2003 (previously named Windows .NET Server) now due in April—is the company’s latest bet-the-farm attempt to build an extensible, distributed and standards-compliant framework for Web applications.

In the other corner is Sun Microsystems, perennial Microsoft critic and developer of the Java family of technologies—including nearly two-year-old Java 2 Enterprise Edition (J2EE)—which has years of experience in providing tools to the world’s developer community.

Both are promoting their own visions of the future of enterprise computing. But as the dust settles and product begins shipping, it’s becoming clear that maybe they’re not so different after all.

War of words
It’s one of those rare situations where Microsoft is David, not Goliath; .NET is a displacement ploy targeted squarely against Java and J2EE, which has gained significant momentum amongst customers since its debut. As in J2EE, .NET applications go through a number of stages between source code and application. These stages are designed to liberate the source code from dependencies on the underlying software platform, although in .NET’s case there are many operating system hooks available when necessary.

In time-honoured tradition, the pitting of Microsoft against Sun has led to a war of words between executives, who trade barbs over keynotes waxing lyrical about the future of enterprise computing. “J2EE . . . is more feature-complete, more mature, and what .NET has going for it is a marketing budget only God can dream of,” Sun vice president and Java creator James Gosling told the crowd at a November developers’ conference in the US.

Gosling also took the opportunity to attack the technical design of Microsoft’s Common Language Runtime (CLR) compiler, an analogue to the Java Virtual Machine, that runs applications written in any .NET-compatible language and compiled into MSIL (Microsoft Intermediate Language)—the conceptual analogue of Java bytecode. Yet in the same speech, Gosling acknowledged the appeal of Microsoft’s Visual Studio.NET development environment—implicit recognition that, in technology terms, the race is well and truly on.

With Microsoft and Sun platforms already moving, however, it’s unlikely to become anything more than a two-horse race any time soon. And in the long term, it could be a competition with no clear winner: Gartner, for one, has projected that .NET and Java will each settle at around 40 percent of the market, with other development platforms making up the remaining 20 percent. Given the J2EE leanings of application server giants IBM, BEA, and Sun, the game has become a familiar one: Microsoft against the rest of the world.

Faced with this challenge in the past, Microsoft has often sought to differentiate its products with proprietary extensions that led the market in new directions but broke established standards. This time, however, Microsoft may find itself constrained by its need to keep .NET interoperable with common Web services-related standards—XML (eXtensible Markup Language) for data representation, SOAP (Simple Object Access Protocol) for interoperability between services, and UDDI (Universal Description, Discovery, and Integration) for cataloguing Web services.

Standards compliance will be crucial to avoid chaos, points out Peter Pritchard, regional director with software giant Compuware, who believes customers will try both environments and “drift towards one or the other. But the one thing everybody needs to keep an eye on is if we see anyone truly trying to break the standard,” he warns. “If someone succeeds, Web services goes out the window and the only thing we’ll be able to use is EDI. And nobody wants that. There’s a lesson there for all of us: you’ve got to try to win this on fairly even turf rather than trying to [jockey for advantage].”

J2EE vs .NET: Developers, Microsoft and platform choices

Developers take up the reins
And jockey they have. Yet while Sun and Microsoft have been fiercely contrasting their two offerings, they have yet to offer compelling evidence that will, on its own, push executives to support one model over the other.

After all, both .NET and J2EE ultimately provide a standards-based architecture for deploying distributed, online, enterprise applications to any device, anywhere. And both Microsoft and Sun recognise that this time, it will be the developers who will be making technology recommendations to their business associates.

Just what they’re going to like depends on personal taste. Owing to its roots in the well established Java development language, J2EE is perceived by many to be more mature—and, therefore, a safer bet—than its rival. Java, after all, has become ubiquitous within university programming courses, something that should guarantee a large and available pool of Java-skilled developers for the long term.

Having said that, .NET’s intrinsic support for most major programming languages means that developers may find that environment more accommodating than J2EE, which only supports Java. Support for multiple languages is particularly important in companies with a significant code base that needs to be moved online: instead of having to rewrite aging COBOL, C++, and Visual Basic applications in Java, those applications can be ported to .NET with minimal effort.

Developers are also coming to appreciate the Microsoft-authored C# language that debuted with Visual Studio.NET last year. “Java programmers like C# in ways they don’t like C++,” says Eyal Aronoff, chief technology officer with Quest Software. “It’s a modern development language with all the key concepts of Java, whereas C++ is trying to take an ancient language and make it modern. People that never went for Java get very excited about [.NET].”

Anecdotal evidence supports Aronoff’s observations. Visual Studio.NET encapsulates many complex Web application components into easy-to-manage function calls, maintaining detailed lists of interdependencies between applications. These lists ensure that modules communicate properly no matter how they’re moved. The end result is that developers often get up and running with .NET in virtually no time. Software vendor MXL, for one, saw productivity increase four-fold when it jumped from C++ to C# and .NET (see case study on page 36).

Charles Sterling, .NET developer evangelist with Microsoft Australia, has a simple explanation for the improvements: “I don’t think we’ve had anything that’s truly fun to develop in since Visual Basic 3,” he says. “The developer community has embraced and loves .NET. It’s not painful; you can just go out and develop. We’ll have to [win developers by] focusing on productivity: you can get apps done faster because you’ll have to write fewer lines of code.”

Smarter J2EE tools are delivering efficiency improvements on the other side of the scale, too. One business analyst, working with US consulting firm E-SoftSys, recently tried out Compuware’s OptimalJ development system to rewrite a J2EE-based workflow application. He was able to complete the work in 248 hours, compared with the 400 hours it had taken a two-person team the first time around. That’s a significant improvement, given the inherent complexity of J2EE and its component Enterprise Java Beans (EJB) architecture.

Whether those improvements came from the development tools or were the result of the specific developer’s technique is not clear. The point to take from their experiences is that with the right approach to development, both J2EE and .NET can help developers produce fully Web-enabled applications far faster than they could in the past. As they come to favour the nuances of one environment over the other, they’ll be able to formulate concrete arguments as to which direction their company should go.

In the long term, however, those preferences may well change as J2EE development tools follow the lead of Visual Studio.NET, and other .NET development environments.

“It’s currently easier in Visual Studio.NET to build a Web service than it is under Java,” says Andy Cooper, brand manager for information management solutions with Computer Associates Australia. “But that’s now as opposed to three months down the track. By the time Web services become really used, a year from now, both will probably have similar ease of use.”

Microsoft: learning to be open?
While it’s easy to reduce the J2EE versus .NET question to one of platform—choose Windows and you’re tied to .NET, pick J2EE if you’re using Unix—recent changes in the industry mean that’s no longer a guarantee.

For example, a US judge’s recent decision to force Microsoft to incorporate Java into Windows could revitalise Java’s role in that environment, paving the way for a better J2EE platform running under Windows. If customers took that approach, they would tap into the innovation around the Windows environment without being locked into .NET and Microsoft’s other applications.

At the same time, the obvious need for Microsoft to avoid seeming heavy-handed has seen its representatives surprisingly open about the possibility of moving .NET off the Windows platform. It was quick to submit its Common Language Interface (CLI), a key component of the CLR, to the European Computer Manufacturers Association (ECMA). ECMA standardised the CLI, along with the C# language, in 2001, paving the way for third parties to build other versions of the applications on other platforms.

As if to prove the point, Microsoft partnered with one-time Linux advocate Corel—which owes its very existence to Microsoft’s US$135 million stake in the company—to build shared-source versions of C# and the Common Language Interface (CLI) for Windows and the FreeBSD operating system. Linux was intentionally left off the agenda, a move that suggested Microsoft was testing the waters of Unix but wasn’t yet ready to give in to longtime nemesis Linux.

Recognising that playing in the world of standards removes the strength of leverage, Sterling concedes that Microsoft’s desire to promote .NET has forced a different mindset. He’s even accepting of the possibility that Linux and Solaris will play a role in .NET’s success, thanks to the efforts of the Ximian-headed Mono project (www.go-mono.com). The developers working on Mono have already ported the CLI to Linux on Intel and PowerPC processors as well as S390-based mainframes; versions for StrongARM (used in handheld computers) and Sun’s SPARC computers are also underway.

Not encouraging .NET on Windows’ arch rivals, but not discouraging it either—it’s a strategy that will ultimately allow Microsoft to extend .NET’s reach without having to overtly support its philosophical arch rival Linux. And with low-cost or free alternatives to .NET out there, Sterling says Microsoft is committed to playing the game right this time around.

“Operating systems now have to compete on their own merits,” he says. “They don’t get to compete on history, momentum, or existing investments. If we’re going to compete with OSes that cost 20 times as much as us, and compete with OSes that are free, we have to show we’re much more cost-effective and provide more value than either. This is what’s going to cause us to become a much better company. I like to think of it not so much as competing, but as playing well with others.”

A kinder, gentler Microsoft? Maybe. But James Eagleton, enterprise architect with Sun, believes Java’s openness and support across multiple platforms—the standard is progressed by a 400-strong worldwide community of software vendors building all kinds of applications—will make it the emotional favourite for developers long sceptical of Microsoft’s way of doing things.

“.NET is relatively untested, but it’s a recognition from Microsoft that object-oriented based languages are a step forward in better componentisation of code, and that a runtime environment is a good step,” Eagleton says.

“It will make development much easier in terms of interoperability between business logic and internal operations. But there are other reasons that big enterprises want to run their systems. A lot of it comes down to the maturity of the language and framework. Compatibility between all three application tiers is a compelling factor for Java.”

There is one area where many fear Microsoft hasn’t learned new tricks, however. Its disastrous Licensing 6.0 pricing program, launched to widespread criticism last August, raised the cost of Microsoft products so much that it’s been credited with convincing many companies to evaluate non-Microsoft products for the first time. With Windows Server 2003 poised to become the linchpin of Microsoft’s future application strategy (soon to include enterprise applications like its Great Plains ERP and a forthcoming Microsoft-built CRM package) many fear the company will impose an equally onerous pricing model this time around.

Among the changes is a new per-processor External Connector license, says Microsoft Australia Windows server product manager Michael Leworthy, that will cover access to .NET Server “for business partners, customers, alumni—anyone who’s a non-employee of the company”. In other words, anyone who’s not an internal, salaried employee needs to pay for even occasional use of Windows Server 2003-driven resources (see www.microsoft.com/licensing/resources/server_overview.asp for more details of the licensing scheme).

That approach may prove unpalatable for companies seeking to build large .NET applications extending to a large number of business partners. Implications for individual companies will obviously vary, but it’s worth your time to carefully weigh up current and future licensing obligations when considering long-term application costs.

Making the platform choice
In the early days of .NET, its close ties with Windows meant the choice of platform was a simple one: .NET for Windows environments, J2EE for everything else.

With cross-breeding between Sun, Microsoft, Linux and other platforms now well underway, the decision is very much about personal taste—that of your developers—rather than being an exercise in technical isolation. Also important in the decision is your existing allegiance to IT suppliers: strong involvement with IBM, for example, may push you in the direction of J2EE simply because that’s where the company’s skills are.

Since both frameworks are built to interface with industry-standard Web services, integration between the two should (theoretically) be a relatively simple matter. This will make it entirely feasible for companies to apply a horses-for-courses approach and teach J2EE and .NET to live together in something resembling bliss.

That’s one theory, at least. In practicality, the expense of sourcing and keeping dual-skilled developers may drive many companies towards the platform that’s best supported by strategic application partners. If more Microsoft-loving software companies build their applications more for .NET than J2EE environments, natural selection will start to play a role. But if application developers can maintain parity in their support for the two, tomorrow’s enterprise applications market should support both for the long term.

“I think a lot of organisations who are currently saying they’re going to choose one or the other, will probably end up using both,” says CA’s Cooper, who says the company wants to be “the Swiss of the platform battle. You tend to find hard and fast rules only tend to appear when the business gets involved.”

Companies with relatively few legacy environments and a strong investment in Windows may gravitate towards .NET for its ease of use and ability to consolidate their applications around Windows servers. Certainly, companies wanting to roll out rich applications integrated with client desktops may find .NET’s tight Windows integration to be a real benefit.

But that doesn’t mean it’s the only choice. J2EE is universally recognised (even by Gosling) to be harder to work with and more complex to get up and running, but once it’s up it is highly secure, tremendously scalable, and extremely robust. That was one of the key factors behind Telstra’s decision to use J2EE as the basis of its future development, although .NET will still play a role in scattered parts of the organisation.

The use of Java also allows encapsulation of business logic into highly portable application modules that mirror individual business functions. Those modules can then be assembled in different ways to follow the company’s change over time. This, says Compuware’s Pritchard, could tilt the scales in J2EE’s direction.

“The whole J2EE model architecture is a nice thing for large applications where you can have business analysts write the program,” he explains. “That’s been one of the big problems of IT projects from back in the dinosaur ages: business analysts would design something but couldn’t code it, and it was done by technical people who did not know what the code means. They would code something wonderful that didn’t do the job.”

Ultimately, doing the job is exactly what these platforms are all about. Thanks to Sun’s years of experience with Java and the ongoing pressure on Microsoft to conform to standards, corporate customers now have two extremely robust, well-received application platforms on which to base their future Web-based businesses. That’s not a clear answer to the question “which platform is better”—but it may help many managers sleep well knowing they no longer have to sell their souls when making the choice.

Getting a handle on Web services

So with procedural programming, complex programs can become increasingly difficult to maintain and support.

Then, there’s object-oriented programming (OOP), which offers a greater level of sophistication to developers. With OOP, objects contain both state and behaviour, allowing a single entity to describe what it is and what it can do. And the objects have relationships to each other. Also, OOP introduced such concepts as encapsulation and polymorphism. OOP made complex programs easier to write, maintain, and support.

Now service-oriented programming (SOP) has entered the fray with even more sophistication. Developing applications using SOP encourages a powerfully clean separation of developer concerns, increased reuse, fewer defects, and increased ability to meet future needs. In the same manner that OOP builds on procedural programming, SOP builds on object-oriented programming.

A service is a core piece of business logic that is protocol independent, location agnostic, and contains no user state. Services don’t contain presentation logic, nor do they contain logic to integrate with data-tier resources, such as a database. Services focus exclusively on solving business domain problems.

Services are very loosely coupled with other components of an application. They’re protocol independent, allowing for the same service to be accessed in multiple ways, and coarse-grained. This allows the service to perform its business logic and return the result in a single call. A good example of this would be a service named getAccounts, which returns the information for all specified bank accounts for a given user.

Services typically rely on configuration data to determine things, such as which data-tier integration module to call. But configuration data for individual users is typically never stored. For example, services shouldn’t store user state beyond a single request. This enables services to be multi-user-safe (ie, a single instance of a service can be called simultaneously for many users).

Applications are typically described by what they do, not necessarily by what they are or what they contain. For this reason, it’s much more straightforward to describe an application using verbs as opposed to nouns. In contrast, OOP establishes itself on the basis of describing objects, and the state and behaviour they contain.

In most distributed component frameworks, such as J2EE’s Enterprise JavaBeans, the primary entities that are intended for business logic are based on an OOP component. Since objects define a thing and not an action, an impedance mismatch can occur when attempting to encapsulate what a component does as opposed to what a component is.

In SOP, an application is described much more naturally. Each function of the application that can be verbalised will likely be a candidate for a service.

Typically there are five tiers in an enterprise application:

• Client tier renders the user interface (UI) of an application. The client could be an application running on a PC, a browser connected to the Internet, a cell phone, or a PDA.
• Presentation tier is responsible for receiving requests from a client, interpreting them, and then forwarding them to the business tier for processing. The presentation tier then packages the response and sends it to the client.
• Business tier should be the focus of any enterprise system and is the domain that should contain all business logic for an enterprise. Business logic should be exposed as loosely coupled services that can be reused as parts of multiple diverse applications.
• Integration tier contains software modules that connect to external resources to get and output data. External resources can be databases, directory services, Web service providers, file systems, etc.
• Resource tier contains repositories of data such as a database or another enterprise system such as an ERP, CRM, or a Web service provider.

These five tiers are logical constructs in nature. Where they reside physically is typically a deployment issue. For example, in a small application, the presentation, business, and integration tiers might all reside on a single machine. In more complex applications they will be deployed across multiple machines. Similarly, when an application’s popularity increases to the point that it needs additional resources, these logical tiers can be separated physically to provide additional computing power.

A service-oriented approach to enterprise application development encourages increased reuse of major business components. With a service-oriented development model, application development consists of combining one or more business services together to form a cohesive unit. This approach has the potential to bring about a faster time-to-market, fewer bugs, and lower maintenance costs.

—Jeff Hanson

.NET switch proves academic for MXL

Previously, eMinerva had been designed to run inside a school over a conventional local area network. Several years ago, however, it became clear that many institutions would benefit from a Web-based version in which MXL hosted customer data and bore the burden of keeping the applications running. The company initially developed an ASP (Active Server Page) based version of eMinerva, which was hosted from the Macquarie Corporate Telecommunications data centre.

Acceptance of that version proved the viability of the Web-based model. However, MXL realised its growth plans—which include aggressive international expansion (UK and Singapore agreements have already been struck)—required a more flexible, redundant, distributed architecture that would allow seamless distribution of eMinerva across many data centres around the world. Early last year, the decision was made to use Microsoft’s .NET framework as the foundation for a complete rewrite of eMinerva.

After mapping business processes to determine customers’ core requirements, MXL programmers began redeveloping the system from the ground up using C# and the .NET framework. Almost instantly, says Paul McNamara, MXL’s director of IT, they were hooked.

“We found that we got about four times the productivity using C# and .NET,” he explains. “Because .NET comes with Web-based components, we were able to deploy a lot of Web functionality at a much more rapid rate than with the traditional C++ environment. The technology guys were telling me that Microsoft seemed to have taken the best of other languages and put it into one.”

“We did look at doing it in Java, but because C# was closer to C++ the jump to C# seemed a lot less than the jump to Java. The whole process didn’t present any problems; there were always workarounds, and there were no major showstoppers along the way.”

Over a dozen schools along Australia’s eastern seaboard are already up and running with the new system after just a few months of operation. Performance tests show a 20 to 30 percent speed improvement over the ASP version, and the new system’s scalable structure should ensure that eMinerva maintains its performance as MXL targets some 1300 additional high schools and other institutions it’s already identified as potential users.

Because the .NET development environment maintains inter­relationships between objects as they change, the new version of eMinerva will be easy to scale and adapt to customers’ changing needs. This includes, for example, a forthcoming move to increase redundancy by distributing the system across clusters of servers.

McNamara is anything but reserved in his praise for .NET. “It was a huge step forward into a very robust environment,” he says. “It’s very much easier to support, because the system can throw exceptions and report errors electronically. The turnaround on new releases and fixes is dramatically quicker, and we can bring on customers much faster. This is the first time in 25 years I’ve been in the industry that there has been some dramatic delivery from IT. There have been promises, but this technology actually delivers.”

What you need to know about J2EE and .NET

It's not just about Web services . . .
Many people assume J2EE and .NET have to involve Web services. But both platforms can be used to build applications that have nothing to do with Web services. Don't be intimidated assuming that you have to go from zero to Web giant overnight.

. . . but they can be a big help
That's not to say you should ignore Web services completely. Where appropriate, Web services are an invaluable way of integrating isolated business processes. Use them where you like, and your life may become easier.

J2EE and .NET are not mutually exclusive
The media loves to portray the choice between J2EE and .NET as some sort of massive battle, but the truth is that you can use both and move data between them with relative ease. Smaller companies may find it easier for practical reasons to standardise on one or the other, but if you've got enough developers feel free to choose the right platform for each application.

You can still choose your OS
It's easy to assume you .NET is only for Windows environments and J2EE only for Unix, but cross-pollination between the two means you may well be able to stick with the operating system you have while adopting either standard.

Think about the future
You may think your applications are fine as they are, but this stuff isn't going away. Even if you're not actively coding J2EE or .NET, plan for it: you'll need it down the road.

XML is the path to your legacy
J2EE and .NET are quite accepting of older platforms, since XML is providing an easy way to integrate them into your modern infrastructure. Here is yet another way to extend your past investment.

People are your destiny
None of this means anything without the right people to make it happen. Strong support for Java within academia has flooded the market with Java talent, and Microsoft is working hard to catch up with .NET skills. Make sure you're training your current developers, or watching the market to pick up people with the experience you're going to need.

Involve the business leaders
Each new generation of development moves businesses from one layer of abstraction to another. The modular design of J2EE and .NET means that it's relatively easy to model individual business processes in software, and let the frameworks take care of the nitty-gritty. Make sure your business line managers are working with developers so everything comes together properly.

Microsoft has changed
Yes, really. It has to. Since the world is clearly coalescing around some quite fundamental standards that have nothing to do with Microsoft, the company can no longer bend the market to its will. Microsoft may not readily admit it, but its desire to make .NET ubiquitous will force it to embrace the non-Windows world like never before. Live it up.

Subscribe now to Australian Technology & Business magazine.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.