Can't J2EE and .NET just be friends?
The two Web services standards are now settling into their respective roles and the reasons for choosing one over the other are becoming clearer. But can they play nicely together?
IT vendors love to talk about the interesting companies that have used their technologies, but few could top the claim of Sun Microsystems, whose J2EE (Java 2 Enterprise Edition) application environment was used to program NASA's twin Opportunity and Spirit Mars rovers.
In an environment where "mission-critical" takes on a whole new meaning, the choice of J2EE is a strong testament to the resilience of a platform that has enjoyed strong support from enterprise developers. It has also, through the support of non-Microsoft independent software vendors (ISVs) like IBM, BEA, and Sun, become a centre of gravity for advocates of Linux and open source development that many argue frees them from the shackles of a single-vendor computing environment.
But does philosophical superiority really translate into business benefits? After several years in a market where J2EE competes against Microsoft's .NET application environment, the answer is becoming less clear.
Through its bundling into Microsoft's latest operating systems, .NET is rapidly becoming ubiquitous in presence, if not in actual usage; this increased footprint has put significant momentum behind the Redmond creation. Given that Windows dominates the corporate desktop and is becoming increasingly common on the server side where .NET lives, many companies already have .NET installed when they decide to experiment with it.
J2EE, however, also has a strong following, particularly amongst large companies that years ago learned their lessons about the need for open software after forking over exorbitant maintenance fees and funding costly forklift upgrades to rebuild applications originally created in obsolete technologies. Because it is supported across a number of server platforms and lies at the centre of a maelstrom of productive competition, J2EE has rapidly evolved into the platform of choice for large companies needing to build applications that can easily extend across heterogeneous computing farms.
Convenience versus technical excellence; closed design versus open: from a purely philosophical perspective, it would seem J2EE would be set to win the battle hands down. However, there are other factors: cost, development complexity, deployment expenses, and skill sets all vary widely between the two platforms, each shaping the ultimate decision as to which technology is best.
In the long term, the choice of whether to pick J2EE or .NET remains highly subjective to the requirements of each individual environment. For most companies, it's not even an either-or choice: Gartner recently reported that "more than 90 percent of medium to large organisations that develop applications for their own projects will most likely use a mixture of both Microsoft and Java technologies through 2005."
Fence-sitters rejoice: judging from Gartner's feedback, you are not alone. For many companies the challenge, then, is not which platform to deploy--but which platform to deploy, where. The choice is no longer exclusive: a variety of methods allow interconnection of application components written in the two environments. Still, determining the right approach requires a clear understanding of the requirements of both short-term applications and long-term information strategies.
Step into the ring
One of the major arguments of J2EE proponents has been the fact that J2EE's openness, broad support and links with the open-source community--particularly with the inexpensive Linux server operating system--make it a less expensive and inherently more robust solution. This may sound good to budget-challenged managers, but those managers will do well to also consider a study by Forrester Research subsidiary Giga Research that last year concluded that .NET actually offered a significantly lower cost of application development and maintenance than J2EE.
| ||||||||||||||||||||||||||||||||||||||||||||||||
The findings refute the idea that J2EE might be cheaper to develop. For the large sample company, the cost of developing, deploying and supporting the application for three years was US$2,289,041 compared with US$1,643,112 for a .NET solution. The medium-sized company application weighed in at US$881,455 for J2EE and US$661,012.
Cynics will point out that the study, sponsored by Microsoft, would not have been released if it didn't find in the company's favour. Certainly, the higher number of .NET interviewees and the making of several assumptions means that the Forrester conclusions may not necessarily reflect real-world performance.
Nonetheless, Giga's analysis did raise several valid issues. One of the main problems with the J2EE approach is the fact that database, application server, development tools, and software maintenance typically needs to be purchased from different companies--preventing companies from achieving economies of scale by ordering many components from a single vendor. A license for four BEA WebLogic Enterprise Edition application server licenses, for example, cost US$68,000 compared with zero for the .NET solution.
Microsoft, on the other hand, bundles its .NET server components into every copy of Windows Server 2003, which has become the standard platform for new Windows server deployments. Microsoft also offers a full suite of software and support options making .NET software costs lower in the long term.
Another key issue highlighted by Giga is training. Assuming 9.25 full-time equivalent staff (FTEs) taking 10 days of J2EE and BEA WebLogic training for the J2EE solution and seven days of Microsoft training, Giga concluded that getting staff up to speed for the large company application would cost US$300,000 for J2EE/Linux and around US$210,000 for the .NET solution, while the medium-sized sample organisation would spend US$70,000 training staff for a J2EE/Linux solution and US$38,500 training them for .NET.
| ||||||||||||||||||||||||||||||||||||||||||||||||
Differences in staff training costs have been a very real part of the reason Melbourne-based development house WDG has focused its efforts on .NET rather than J2EE.
"Especially in the early days, .NET developers were significantly cheaper to find," says Karl Kopp, director of IT with WDG, which has 22 developers working on a range of .NET projects. "Java developers tend to be a lot more costly, and we're trying to run a business; it was a lot more cost-effective for us to follow the Microsoft path because developers are so much cheaper."
Playing the time to market gameSimple force of numbers may be part of the reason that Microsoft-skilled developers are easier to find, but this also reflects the significant effort that Microsoft has put into helping developers step into .NET's boots.
With a large and mature developer community already established, the software giant has put considerable effort into building technical resources to help developers from most backgrounds start building .NET applications as quickly as possible: the .NET Common Language Runtime (CLR) supports most development languages that people are likely to be using, with a highly modular design allowing even legacy applications to be wrapped into .NET components.
Could ease of development make .NET a favourite amongst developers? Kopp certainly thinks so: "there's enough information out there that anyone with a half-decent background in C can pick up and build an ASP service on .NET," he says. "With the effort that Microsoft has put into making .NET easy to learn and pick up: a lot of the syntax is really quite straightforward and similar to the languages that people are used to."
While Giga's research allowed twelve months for development and deployment of the application using J2EE/Linux, the firm allowed for the same process to take just nine months using .NET. That provides significant value for the company, both in terms of direct savings on developers and the indirect business benefits that flow from having the production application up three months earlier.
For Australian Swimming, rapid time to market was a real benefit of building its new membership management system within .NET. A four-person WDG development team was able to generate most of the application from the get-go--then build and test the whole system within just six weeks.
"We've developed a .NET framework that generates 80 percent of the code that any given project needs," says Kopp. "We've spent a lot of time and resources to build these tools and fast-track development. We build a database infrastructure and relationships, generate the classes, generate the business logic and we're done. They're exceptional, solid tools that help you create good code that's easily readable and runs very fast."
Much of the developer efficiency of the .NET space comes from the maturity and feature richness of Microsoft's integrated development environment (IDE) Visual Studio.NET, which has been widely praised for its ability to ease developers into .NET production within a relatively short timeframe. Overall, the long-time tools vendor has managed to produce an arsenal of development tools that, combined with the relative ease of use of the platform, have many .NET proponents pointing out that the system can deliver much faster time to market than J2EE.
| -Java developers tend to be a lot more costly, and we're trying to run a business; it was a lot more cost-effective for us to follow the Microsoft path." |
Using Visual Studio.NET as a model, Java Studio Creator is a drag-and-drop environment that's intended to bring J2EE development up to a similar level of ease of use that Laurie Wong, business manager for software with Sun Microsystems Australia, believes will encourage more casual developers to embrace J2EE.
"Whereas the Microsoft model is more tuned to quicker development--and therefore more desktop and departmental type applications--server-side applications are mainly in Java," Wong says. "If you are a complete visual developer, your programmers don't need to know much about the underlying technology. You can get speed out of your development, but you risk getting a system that is very difficult to maintain. If you have a very disciplined development environment, you end up with a very maintainable core--but you can't do it fast. With Java Studio Creator we are trying to provide a framework so you can have accuracy and speed as well."
Java Studio Creator will go head to head with Visual Studio but with what Wong calls "a more complete environment" including application servers, Web servers, the J2SE (Java 2 Standard Edition) software development kit, a Web services development pack, SQL database, and other applications. To complement its development tools push, Sun also plans to bolster its developer programs to foster closer involvement with that very critical community--and hopefully lower the bar for entry into the J2EE market.
Decision making by platform
If Sun and other companies can bring J2EE development tools on par with those of Microsoft--and the strongly competing Borland JBuilder--the playing field will be levelled far more than it was several years ago. As other aspects of the platforms come together, companies will be free to pick and choose elements of both environments for their work--without having to worry about the repercussions of committing to one vendor.
In such an environment, decisions can be based on each individual application and the platform supporting it. Microsoft's Windows-only focus, of course, means that .NET will remain centred around the company's various server operating system flavours; work to build an open-source version of .NET under the efforts of Mono continues, but that technology's suitability for large-scale enterprise applications is yet to be seen.
Conversations with developers reveal common themes when it comes to J2EE and .NET. For example, because it's running on standalone application servers dedicated to efficiency and designed from the ground up with expandability in mind, J2EE is seen by many as more readily scalable than .NET, where application services are one of many functions performed by the operating system.
Another determining factor is the complexity of the company's environment. Whereas many smaller companies can commit to a Microsoft-only solution, the sheer breadth and depth of applications in larger companies means such a commitment is not always wise or even possible. This is why cross-platform capabilities are critical for large companies like Telstra, who often end up focusing their development efforts around J2EE to ensure that their applications will be able to run--and be maintained in the long term--regardless of the platform decisions the company makes down the road.
| -If you have a very disciplined development environment, you end up with a very maintainable coreâ€"but you can't do it fast. With Java Studio Creator we are trying to provide a framework so you can have accuracy and speed as well." |
That's not to say that large companies running J2EE won't also investigate .NET; the rise and rise of Windows on the server side means that most organisations are likely to end up exploring and eventually deploying .NET in specific applications. Doing so, however, introduces one very important issue: how to get the two environments to talk to each other.
Integration: easier than you think
In the past, integration was a considerable bugbear for companies trying to link up different application environments. Yet both .NET and J2EE have one very nice thing going for them: both are being architected to conform to Web services standards like WSDL, SOAP, UDDI, and XML.
With those data interchange formats as common targets, integrating functions of both environments becomes far simpler. Web services will effectively become intermediaries in shuttling data between .NET applications and J2EE environments, allowing companies to build each individual infrastructure component according to their best design practices.
Recognising the inevitability of J2EE use in many of its customers, Microsoft has published an entire online book--Application Interoperability: Microsoft .NET and J2EE--that describes how to link the two environments, in both directions (see www.microsoft.com/indonesia/msdn/jdni.asp).
"We prefer organisations to use Web service as a way to integrate .NET and J2EE, and we haven't really seen massive issues with it," says Bill Karagounis, group manager for architecture with Microsoft Australia. "We really want to compete on implementation and the productivity of the platform and tool set, and the fact that you've got a well-known and well-understood platform running underneath you."
There are limitations to using Web services as a method for integration, however. Namely, SOAP--the preferred Web services way of allowing different Web services to communicate--is limited in the connectivity it can provide: all outgoing and incoming data must be converted to specific formats when it's sent or received. This may allow for exchange of data, but prevents applications from getting intimately acquainted with other services.
For those wanting a tighter and more functional connection, Borland offers Janeva, a dedicated piece of middleware that allows developers to wrap J2EE and CORBA in enough trimmings that .NET clients and servers can seamlessly link with J2EE/CORBA modules.
Janeva can do this because it is effectively an implementation of .NET that runs over IIOP (Internet Inter-ORB Protocol), an element of the J2EE 1.3 standard; .NET clients just use IIOP-compliant stubs to request servers from J2EE or CORBA servers. The latest version, Janeva 6, facilitates two-way communications between has been certified for use with all major J2EE applications servers for functions including transaction and security services.
Janeva's ability to bridge environments will make it, and its inevitable clones to come, critical tools for many companies that want to build up competencies in both .NET and J2EE but don't want to isolate the environments. This way, developers can build business and application logic in the form they're comfortable with, then deploy it on whatever infrastructure makes the most sense. They will also be able to reuse application modules in later developments, even if those modules were written in the other environment.
"We considered using various options to provide this interoperability but our needs required a tight, fine-grained integration, as well as high-performance, fault-tolerant and secure interoperability," says Choo Li Chin, director (Unix product management) with Singapore Telecommunications, one of Janeva's earliest customers and parent company of SingTel Optus. This "is the ideal way to connect applications built for the .NET Framework with J2EE and CORBA infrastructures."
With features nearly at parity and the performance of back-end servers allowing similar functionality in .NET and J2EE environments, companies deciding which approach to use must rely not on early prejudices about one technology or the other. Rather, they need to think long-term to decide which technology suits their business need and how their developers will deliver on that need. Once that decision is made, the technology platforms--and the benefits of Web services and distributed applications--will finally fall into place.
When you no longer have to choose
It used to be something of a religious war, but the choice between J2EE and .NET isn't so clearcut anymore. Here are a few things to consider when you're making the choice:
- Open source isn't everything
It may sound great, but don't let your philosophical pursuit of open standards keep you away from a solution that may provide strong business value - Single-vendor solutions can be cheaper
Like it or not, you can get better pricing out of a company when you buy more products from them. This means Microsoft on the .NET side; IBM can provide most of what you need when it comes to J2EE. Pick other vendors' products and you may pay more than you have to. - Plan for reusability
One of the big benefits of both environments is the fact that components can be readily reused, speeding development times. Get developers thinking this way and benefits may follow. - A good IDE can make all the difference...
One of J2EE's often-cited problems--and one of the reasons .NET is seen as being so easy to develop in--is complexity of developing within the environment. Sun's upcoming Java Studio Creator will be targeted directly at Microsoft's Visual Studio.NET, hopefully raising the bar for development tools. - ... but don't rely too much on it
Imagine: developers get so entranced with the drag-and-drop programming offered by modern integrated development environments that they lose track of what's going on in the back end. This is a big no-no when something goes wrong; make sure developers learn the ropes in both the front and back offices. - Training costs
Whichever platform you go to, you're going to have to plan for considerable training expense both upfront and on an ongoing basis. J2EE and .NET are evolving so rapidly that your staff will struggle to keep up without it. - Integration has become easy
With the launch of new products like Borland Janeva, integration between J2EE and .NET components has become something of a no-brainer. That means it doesn't really matter which platform you choose. - Hold onto your legacy
Just because you're modernising your applications doesn't mean you have to shut down your legacy mainframes and other systems. Both J2EE and .NET provide ways of interfacing with legacy systems, although .NET has done this by providing a way of writing a "wrapper" around legacy code. - If you choose J2EE, plan to write code
Lots of it. Whereas Microsoft has built .NET as a migration path that embraces the future, J2EE applications need to be written from the ground up. That's not necessarily bad, though: rewriting applications in J2EE usually means they'll run faster, work better and scale further than existing legacy systems.
case study Ford Financial, a subsidiary of Ford Motor Company, manages finance to purchasers of Ford, Jaguar, Volvo, Mazda, and Land Rover vehicles through a variety of brand names. A global entity with over 200 offices serving 12,500 dealers, Ford Financial has 20,000 employees and serves over 11 million customers in 36 countries. It is represented in Australia through Ford Credit Australia, where around 300 employees service 250 Ford dealers and 100,000 customers that collectively provide a receivables base of over $3 billion.
A long-time Sun Microsystems customer, Ford Financial began investigating ways to use Java to bring its legacy OS/2- and mainframe-based systems onto the Internet in order to improve customer and dealer communications, self-service capabilities, online loan applications, updating of remote software, and other aspects of the business. Through a dozen different projects, the two companies worked together to gradually shift key business functions onto an n-tier online architecture that would support all manner of new projects in the future.
The company's choice of J2EE was driven by several key factors. First was its desire for platform independence, something the company had come to value as IBM announced it would cease supporting the OS/2 on which Ford Financial relied so heavily. It was also looking for a way to extend its legacy mainframe applications online quickly and easily; automate many paper-driven processes; shorten development cycles that were as long as eight to 12 months under the previous environment; and provide a flexible framework to support wireless and other future technologies.
Ford Financial's new infrastructure is built around more than 30 Sun Enterprise 6500 and 4500 servers located in the Ford Financial data centre in Michigan, USA. The servers run Solaris 8, Sun's iPlanet Web Proxy Server, iPlanet Directory Service, and the Sun ONE framework, with Forte for Java used as the integrated development environment. Ford Financial also uses BEA WebLogic Application Server to provide its application processing tier, and an Oracle 8i database in the back end.
Among the key J2EE-based initiatives already delivered are a workflow system that distributes information to over 3000 customer service representatives in 8 North American customer service centres; the Used Vehicle Information System, for collecting vehicles in which the company has a financial interest; CreditWeb, to handle financial transactions between more than 6000 North American dealers and Ford Financial; and the global International Account Access program, which lets customers access account information online. This last application was pilot-tested at Ford Credit Australia before being rolled out globally.
The move to J2EE has paid off in many ways: development cycles have been cut to three to four months; customer service has been improved and dealers interact electronically where they used to communicate manually; Ford Financial has saved $15.5 million in annual development costs simply by being able to reuse large pieces of its coded architecture; the legacy systems' lifespans have been extended; and Ford Financial can now implement new e-business systems with far less effort than it would have required in the past.
J2EE has risen to the task of supporting Ford Financial's mission-critical applications handsomely, says Jeff Lemmer, e-commerce technology director with Ford Financial. "Total cost of ownership was a critical component in our decision to roll out our next-generation, enterprise-wide infrastructure," he explains. "The new [J2EE] platform infrastructure offers improved quality of service requirements, such as scalability, manageability, functionality, and serviceability demanded by our employees, dealers, and customers."
Australian Swimming dives into .NET
case study With more than 100,000 members spread across the country, Australian Swimming recognised that its existing collection of nine separate stakeholder databases was becoming an encumbrance.
The organisation manages swimming at every level from professional to rank amateur, but lacked nationwide perspective on its membership base because each office had its own relationship with nearby clubs, of which there are more than 1000 nationwide. This meant information didn't flow readily between states, making it hard to coordinate sanctioned swimming competitions and introducing the possibility of errors or lost data as information was often stored on index cards at individual clubs.
"For medico-legal reasons and to run the business of swimming, we need to know peoples' surnames, dates of birth, events they swim, and so on," says Sascha Saharov, IT project manager with ACT-based Australian Swimming Inc. "The challenge is in streamlining that process, and we're bringing everyone into the same database so that people can access the data they need. Just as some businesses are striving towards the paperless office, we're moving towards a paperless sport. We're devolving responsibility for data entry to the lowest possible level."
Working with application developer WDG, Australian Swimming mapped out its business processes and helped design a .NET based application that created a single centralised database accessible over the Web by the hundreds of individual club managers. Those managers can enter information about members, including the results of races as they're run, using a standard Web browser.
WDG's choice of .NET to build the system grew out of the company's past experience working with the technology, which had seen it build up a large library of prebuilt components. By connecting those components together and modelling them around Australian Swimming's optimised business processes, WDG delivered a working membership application within four weeks and had it in production two weeks later.
"The rules of swimming are quite strict and vary quite dramatically from state to state," says Saharov. "We've got very strict controls about who needs to see what, and we built those into the database. We're bolting on functionality all the time, and have developed functionality we haven't given to the users yet. Rather than flooding them with it, we're drip-feeding it so we have core elements out there and give them permission to use more and more of it. Ultimately, it's about providing better service to our members."