The question is not whether you should develop web services in .NET or J2EE. The question is, how do you get them to interoperate?

	express delivery
	• print  • comment
	Connecting .NET and Java web services isn't as hard as people expect, but embracing both platforms has its pitfalls: Developer productivity is higher with .NET J2EE is preferred for larger systems Standards don't necessarily mean the two will work together, but problems are minor Connecting the messaging and management infrastructures requires specialist skills Few developers understand both environments
	Glossary terms: J2EE, .NET, Java, web services, interoperability, lookup tool Sponsored links: your text link here

As an integration technology, it's inevitable that, sooner or later, web services running in one environment are going to have to interact with services running in the other — if not internally, then on venturing beyond the firewall.

Point-to-point integration doesn't cause many problems, say companies who've already brought the two together. But more complex interactions expose the current immaturity of higher-level standards, and may require additional specialist software to bridge gaps between the two.

So although the integration capabilities of web services in principle give companies the freedom to select whichever environment works best for individual projects, in practice there are other considerations to take into account.

The divide between Microsoft's .NET Framework and Java 2 Enterprise Edition (J2EE) usually boils down to a matter of productivity versus scalability. Java is traditionally seen as more scalable, robust and reliable, while .NET is more productive and easier to use. Developer prejudice comes into it as well — .NET is tied to Microsoft's Windows platform, while J2EE is an industry standard jointly developed by everybody else, and founded on Sun's Java language. Adoption in web services projects is evenly split, with analyst groups such as Gartner and Meta variously scoring the two platforms either in a 50-50 dead heat, or leaning 60-40 towards one or the other.

"My sense is there is a schism between the two environments," says Dwight Davis, vice president of Boston-based Summit Strategies and the head of its web services practice. "The main issue is the ease of development and productivity of the tools. Microsoft with .NET has a bit of an edge here."

Productivity gap

The ease of use of Visual Studio.NET, Microsoft's tools platform for .NET, is the winning factor, along with close ties into Windows that make it easy to squeeze every last drop of functionality out of the environment. A senior executive at one of the big SIs, nervous to go on the record for fear of upsetting either camp, estimates a 30 percent productivity advantage with .NET.

By contrast, until recently J2EE has been far too complicated for Java developers to keep up to speed with. One developer told Loosely Coupled: "Java is getting very large. There are too many standards. It includes so many different things that for a developer to call themselves an expert in J2EE they need to understand many different technologies and many different APIs and sub-APIs."

Java tools vendors have recently been making efforts to close that gap. BEA's WebLogic Workshop, for example, which is available as a free download for the WebLogic application server platform, is described by the vendor as "Visual Studio for the Java platform".

Like Visual Studio, but unlike earlier generations of J2EE tools, WebLogic Workshop allows developers to design and develop applications on the same platform they'll be deployed on. Developers quickly get over the novelty of this integrated approach, says Neil Sholay, industry marketing manager at BEA. "For the first day or two it's a bit of a culture shock, but all development is integration. I've never seen a project that doesn't involve some integration."

J2EE's biggest trump card over .NET is its ability to deploy to a heterogeneous server environment, whereas .NET is limited to just Windows servers. "In a big company, you are not deploying on Windows, you are deploying on Windows, HP-UX, Sun Solaris and a variety of platforms," says one Java developer. This means, says Sholay, that BEA rarely competes with .NET products because the two operate at different levels of the enterprise, J2EE being at the mission-critical end.

Interoperability problems

"The battle for the middle ground has not yet begun," says Sholay. "But that will come at some point and we're keen to head off the schisms and get standards in place before we lock horns. If not, we will only create confusion for end-users."

On this score, Davis believes web services may have provided Microsoft with a 'get-out-of-jail-free' card. "Web services is at least making some progress toward bridging the two worlds," he asserts.

However, it's a mistake to believe that just because the two adhere to the basic web services standards they will automatically work together. Massimo Pezzini, vice president of Enterprise Architecture and Infrastructure at Gartner, explains: "Standards are frequently not completely defined or are ambiguous. So two implementations of the same standard are not necessarily equivalent. In the case of SOAP there are issues regarding the mapping between SOAP data types and Java and .NET data-types which may lead to interoperability problems. But they are usually minor and can be fixed with a little bit of work."

Jon Calladine, legacy access and major systems integration manager at UK-based telecoms company BT — which has a healthy pedigree in internal web services projects — agrees that it is still incumbent on developers to prove rather than assume interoperability. Perversely, though, he often sees .NET coming out on top in this respect: "Interoperability is a key issue and in our experience .NET-based web services tend to be more vanilla and work better with other technologies, probably because most vendors go out of their way to provide .NET interoperability because of the market position Microsoft enjoys."

London-based multinational British American Tobacco linked the two environments in its first production pilot, which it recently completed. It has taken SAP and two i2 modules, exposed them using web services, and created a supply chain dashboard, using software from CXO Systems. CXO runs on .NET, whereas the source web services are running on J2EE. Of course, this is how web services is supposed to work, but it's still seen as an achievement.

"It was probably less of a surprise to us than to some other people outside of the organization we've mentioned it to," says Kevin Poulter, application technology manager. "We knew what we wanted to use to web-service-enable the SAP and i2 systems. One of the premises behind our work here is we're going to have to work with both, so we're going to have to get them to work together — and it didn't give us too many problems."

Specialist infrastructure

Other challenges arise when you move into more sophisticated layers of infrastructure such as messaging, choreography and management. Guaranteed messaging, for instance, is one of the many "boring bits" of operational management in the Java world that WebLogic Workshop takes care of, says Sholay. But it does so using the JMS standard, while .NET uses Microsoft's messaging architecture, which throws up issues when the two meet.

Despite the work being done by the Web Services Interoperability organization (WS-I) and various standards bodies, the easiest way to deal with such issues today is by turning to specialist tools and platforms, such as The Mind Electric's Gaia. Currently in beta, Gaia is a web service fabric that treats services either from Java or .NET or elsewhere as part of the fabric and handles all the infrastructure issues between them, explains Graham Glass, founder and chief architect of the company, based in Addison, Texas.

Web services management vendor AmberPoint rises above any interoperability issues by offering native versions of its software for both environments. "This has turned out to be a pretty powerful competitive advantage," says Ed Horst, VP of marketing at the California-based company. For reasons to do with both performance and skills, customers insist on web services management tools running native in the same environment as the web services themselves, he explains.

For many organizations, the skills base they can call on may prove to be the biggest single barrier to interoperability. While the advances in usability of both J2EE and .NET tools has alleviated companies' reliance on so-called 'gurus' with knowledge of both environments — who charge themselves out at thousands of dollars a day — there is still a shortage of developers conversant with both environments. And, as Simon Guest, author of Microsoft .NET and J2EE Interoperability Toolkit, writes in a recent article on MSDN: "A basic working knowledge of both [.NET and J2EE] is required."

Companies must carefully consider the impact of web services projects on skills strategies. How many developers do they have who understand both the major web services environments intimately and, if they have those skills, how long are they likely to stay with the company? BT's Calladine recommends a cautious approach: "Don't change platforms just to accommodate web services development," he advises. "Both platforms can do a good job for web services."

More on this topic