Java Web services high in potential

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 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 percent of respondents to the 2002 InfoWorld Application Integration Survey are evaluating Web services as a partial EAI solution, and another 14 percent 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 lackluster 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 .Net for EAI: 49 percent call J2EE important to their EAI strategy, whereas .Net is important to just 38 percent. 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 and BEA Systems 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

The success of J2EE technologies — and its strong enterprise following — has been thanks to the range of enterprise-ready integration components and solid infrastructure at its core. The cornerstone of the J2EE 1.3 architecture, the EJB (Enterprise JavaBeans) container, has proven its worth in server-side deployment by supporting crucial responsibilities such as security, persistence, and session management, and transactional integrity while simplifying application deployment and management. The new JCA (Java Connector Architecture) has proven a further boon to IT managers undertaking integration projects by offering an open standard for connecting enterprise information systems, such as PeopleSoft, SAP, and CICS (Customer Information Control System). JCA has reduced the complexity and hard-coding requirements necessary to integrate resource adaptors with the application server.

Add to this Java’s elements for multitier, distributed, scalable computing, messaging, and transaction services, and it’s little wonder that J2EE has curried favor 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’s CapeStudio, have given credibility to Java as a Web services platform.

Firming the firmament

Although XML processing is fundamental to Web services, it only begins to address the requirements of a comprehensive platform. Currently under development within the Java Community Process (JCP) is a specification request #209 JSR 109 #209 that will better define the programming model and run-time architecture for Java-based Web services. This formal road map to the future aims to provide a unified standard for Web services that will be essential for planning any long-term EAI projects on J2EE.

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 percent 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 percent of survey respondents expect Web services to make EAI less expensive, and 58 percent 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.

Additional Test Center Research Reports

Security solutions

Web services

Wireless

CRM

Enterprise storage

Return to our Test Center Research Report: Application Integration .

See our related infographic, .

Source: www.infoworld.com