Integrating enterprise applications has been a thorn in the side of enterprise planners since companies started using more than one piece of software to run the business. An end-to-end solution, Java has helped join the disparate worlds of enterprise information systems, linking legacy, ERP, and relational databases with Web-based business applications. Sun Microsystems Inc. has shaped J2EE (Java 2 Enterprise Edition) into a formidable platform for enterprise integration. But the strengths of Java don’t necessarily make a clear-cut case for standardizing EAI efforts on J2EE Web services.
The J2EE platform has matured into an enterprise powerhouse, but Sun has hindered J2EE Web services by poorly developing a decisive track for services-oriented computing.
Although Web services are garnering attention for improving end-user access to data and applications, the technology is also shaping up as an alternative to traditional methods for EAI; 53 per cent of respondents to the 2002 InfoWorld Application Integration Survey are evaluating Web services as a partial EAI solution, and another 14 per cent are considering it as a complete solution. But the path for Java as a comprehensive platform for Web services remains riddled with outstanding issues, such as the lack of a definitive model for class extensions and adopted security mechanisms.
Sun announced Sun ONE (Open Net Environment) as a vision for both platform and architecture, rolling together the Solaris OS, iPlanet application server, Forte development tools, and J2EE. But the vendor has done little to address the requisite specifications and standards necessary for a comprehensive Java Web services stack.
No small surprise, then, that J2EE received relatively lacklustre reviews from our survey respondents. Participants ranked J2EE with roughly a 50-50 split in importance to EAI considerations, and another survey question proffered similar results in its popularity as a standards-based integration broker. In spite of Java’s shortcomings, it has become the platform of choice for developing and deploying Web services by many early adopters in situations, such as in-house application integration, where lack of inherent security, for example, may not present an overriding concern.
A majority of survey respondents ranked J2EE higher in importance than Microsoft Corp.’s .Net for EAI: 49 per cent call J2EE important to their EAI strategy, whereas .Net is important to just 38 per cent. But some of Java’s popularity can be attributed to Microsoft’s unhurried advance into the Web services space. Also, industry heavyweights such as IBM Corp. and BEA Systems Inc. have pushed Java by building solutions on top of the technology; for example, BEA recently included support for the new J2EE 1.3 specification in its WebLogic product line.
But how long can strong momentum and good intentions sustain Java? Specification add-ons from the past year have helped draft an interim solution. But for Java to remain competitive and for CTOs to develop long-term technical strategies, the standards committee must soon release an authoritative framework for the future of Java Web services.
Drafting an Architecture
Add to this Java’s elements for multitier, distributed, scalable computing, messaging, and transaction services, and it’s little wonder that J2EE has curried favour with such a large audience. Despite all of Java’s attributes as an integration tool, advances toward improving J2EE as a development platform for Web services enterprise integration have been slow.
Because the primary underpinnings of Web services are based on XML, the success of any Web services-based EAI implementation will turn on its capability of processing and transforming XML efficiently. One advance in the support of XML for Web services has already been defined: Sun’s JAX (Java Architecture for XML) is a collection of APIs that allows J2EE to uniformly process XML. Sun also added XML support to JSPs (Java Server Pages) and servlets. JAXP (JAX processing) adds mechanisms to J2EE that handle the basic processing and transforming of XML documents, supporting both the SAX (simple API to XML) and DOM (document object model) models. SOAP (Simple Object Access Protocol) messaging constructs are available through either JAXM (JAX messaging) or JAX-RPC (Remote Procedure Call), and they support additional profiles, including the ebXML (e-business XML) messaging service. And JAXR (JAX registries) facilitates publishing and locating requirements of Web services directories.
One of the latest advances in APIs is JAXB (JAX binding). Currently available as a public preview, the final release of JAXB will facilitate mapping XML documents to Java objects; ultimately, this enables normal Java objects to directly represent XML documents. Using JAXB not only speeds document processing but also simplifies the complexities of writing XML parsing and code validation, enabling faster deployment.
Providing development support for Java-based Web services is the array of tools that enable J2EE components as Web services and manipulate XML. While Microsoft has been polishing Visual Studio .Net, mature development tools, such as Borland’s Enterprise Studio platforms and Cape Clear Software Inc.’s CapeStudio, have given credibility to Java as a Web services platform.
Firming the Firmament
By building on existing specifications and fortifying server and client-side frameworks, JSR 109 will improve transport binding options, add XML encryption, and provide for implementing end-to-end security. Better integration with existing Internet security models, such as digital signatures, will help to bolster efforts for authentication and non-repudiation in Web services transactions.
The final draft of JSR 109 was originally slated for completion in February 2002, but the JCP would not speculate on its ability to deliver within that time frame. Furthermore, it’s still a long walk from proposing the specification to actually seeing it included in J2EE, along with useable development tools and compliancy tests for vendors. But, if the JCP applies a little steam, its specification could find its way into J2EE 1.4, due out by the end of this year. And that type of guidance is exactly what CTOs need to feel confident basing EAI on J2EE Web services.
For IT leaders looking to bridge the EAI gap with Web services – and 56 per cent of survey participants have already identified EAI as readily addressable by Web services – J2EE will offer a solid choice as soon as a platform guideline assures uniformity among developers. What will make J2EE such a good fit for Web services is its capability of exposing interfaces in existing Java components without requiring your IT staff to rearchitect your systems or spend huge sums on code modifications.
Furthermore, Web services inherit the benefits of J2EE’s flexibility and wide assortment of vendor choices. Because availability and scalability is crucial to Web services’ success, maintaining costs by taking advantage of competitive pricing will be important; after all, 51 per cent of survey respondents expect Web services to make EAI less expensive, and 58 per cent think it will make EAI easier.
J2EE may have the early advantage over .Net in Web services, but this ship has barely left the port. Before the J2EE platform will be able to successfully prove its EAI value in Web services, a cohesive architectural framework must be put in place. If one fails to come to market by year’s end, customers sitting on the fence over platform choices will probably be swayed to non-J2EE solutions or rely on third-party vendors for more comprehensive and costly platform support. The challenge is under way.
J2EE vs. .Net: Dilemma or Non-debate?
Choosing a platform on which to standardize your Web services-based architecture may appear fraught with uncertainty. When comparing Sun J2EE (Java 2 Enterprise Edition) with Microsoft .Net, making a clear-cut distinction through the whirl of marketing spin is a challenge. Despite general similarities between the two platforms, when evaluating the pros and cons that could give one the edge over the other, it’s clear that neither – in the grand scheme of Web services – has proven its worth.
Microsoft has had the distinct advantage of architecting .Net from the ground up, weaving Web services natively into all aspects of the architecture. Sun, by comparison, has had to retrofit APIs onto J2EE in order to facilitate capabilities for XML-based processing and communications. The open standards, committee-based process for developing these add-ons has imposed considerable delay, as well as given Microsoft a jump-start in developing XML processing and a formidable IDE (integrated development environment) coming to bear in Visual Studio. Microsoft’s solutions are on par with those from Java proponents such as BEA Systems or IBM, whose WebSphere is demonstrating its own strengths in XML.
J2EE brings to Sun’s solutions important platform strengths, such as portability, strong enterprise connectors, and inherent transactional state management. Also, J2EE isn’t encumbered by the training requirements imposed by the .Net redesign; because .Net introduces new concepts to the Microsoft platform, developers must build their skills with new tools and concepts, including Common Language Runtime and the C# language.
Ultimately, the primary differentiators between the two – Java’s platform independence and vendor flexibility vs. Microsoft’s performance benefits and ease of use – will likely persist. And take with a grain of salt the debates currently waging between both camps, extolling the virtues of code size and throughput metrics won by each solution.
The final choice for deployment in any enterprise scenario will rest on issues such as existing architectures and in-house skill sets. But with Web services, CTOs won’t have to deliberate so meticulously over the synergy between new technology deployments and partners and vendors in any long-term technical strategy; the new technology will offer enough flexibility to mitigate many concerns.
The requirements for Web services, however, will remain much the same as with any traditional enterprise platform – reliability, scalability, and availability – but with the bonus of being easier to implement than traditional integration, regardless of the platform on which you standardize.
THE BOTTOM LINE
J2EE for Web Services and EAI
Executive Summary: The J2EE platform for EAI and Web services offers flexibility and savings potential over licensing proprietary solutions. Web services for EAI bring long-term value to the equation.
Test Center Perspective: The direction of Web services remains cloudy for Java, and specifications are not likely to firm up by year’s end. Third-party J2EE-based EAI solutions that help shore up shortcomings will best serve immediate enterprise needs.
