By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Under the rather sinister rubric 'One Pack to Build Them All,' Sun has announced the availability of its Java Web Services Pack, Early Access Release 1. Like Tolkien's One Ring, only time will tell whether this technology bundle is a tool of great power or a dangerous weapon that should be flung into the fires that forged it.
Context You can view the pack in one of two ways. On the one hand, it's simply an add-on to Java 2 Enterprise Edition (J2EE) 1.3 that paves the way for the inclusion of Web services capabilities in J2EE 1.4. On the other hand, by defining Java APIs for XML messaging, processing, registries and remote procedure calls, the Web Services Developer Pack takes its place as a key component in the Sun Open Network Environment (ONE), now battling it out for world domination with Microsoft's .NET framework and IBM's WebSphere product line.
Technology The four Java APIs included in the pack are designed to confer the benefits of XML to developers who want portable data but don't want to get their hands dirty with that messy markup language. Sun believes the hardest part of developing Web services is programming the infrastructure - tedious plumbing chores like security, messaging and distributed transaction or connection pool management. Add to that the huge numbers of simultaneous users Web services are expected to support, and developers face a series of major and interconnected challenges. The four APIs are designed to address these challenges.
The Java API for XML Processing (JAXP) leverages the parser standards SAX (simple API for XML parsing) and DOM (document object model). This gives developers a choice between parsing data as streams of events, with SAX, or collections of objects, with DOM. You might use SAX to perform an efficient search for one piece of data in a few documents, but if you needed to make changes to the document, it would be quicker and easier to load the whole document object model into memory and use DOM.
This trade-off illustrates the rationale behind Sun's reluctance to tie the Web Services Developer Pack to any single standard. In a similar way, the Java API for XML Messaging (JAXM) is based on SOAP 1.1 and SOAP With Attachments, and can be extended to work with higher-level messaging protocols like ebXML. The Java API for XML Registries (JAXR) also supports multiple standards, in this case ebXML (again) and UDDI. In fact, Sun's white paper on the Java APIs takes pains to point out that where ebXML is considered an open standard, UDDI is, at present, no more than an industry consortium-led specification. The implication is that UDDI should be handled with care.
The final API, Java API for XML-based Remote Procedure Calls (JAX-RPC), leads Sun still further into the standards quagmire. Java already has two other APIs for making remote procedure calls. The first, based on the common object request broker architecture (CORBA) and the Object Management Group's interface definition language (OMG-IDL), is called Java IDL. The second, Remote Method Invocation (RMI), is a Java implementation of RPC - except when it's used over IIOP, when the methods invoked may be in another language. Sun intends to keep supporting both, on the grounds that both they and JAX-RPC serve different users with distinct needs.
JAX-RPC is a specialized form of SOAP messaging, designed to shield the user from much of SOAP's complexity. By contrast, JAXM handles asynchronous messaging, routing of messages to more than one party and guaranteed delivery. You'd use JAXM for industrial-strength messaging apps, and JAX-RPC for simpler apps that don't need SOAP's powerful messaging features.
The pack also includes a JSP tag library, a registry server and the Apache Ant Build Tool and Tomcat servlet container. It's available for free download from Sun's website.
Conclusion The Web Services Developer Pack is most interesting for the way it illustrates Sun's ambivalence toward -- and frustration over -- the recent Web services standards push. Although Sun executives would be the very last to admit it, the company was caught off guard by the IBM-Microsoft alliance that generated both SOAP and WSDL, the core Web services specifications. Now Sun must implement those standards to avoid seeming out-of-date.
The trouble is that in doing so, the company plays directly into IBM's hands. IBM has played an ingenious double-sided game over Web services. By collaborating with Microsoft, it ensured that the emerging Web services standards from both companies would be at least approximately interoperable. By embracing Java, it ensured that WebSphere would continue to be a viable replacement for Sun software. Now all IBM has to do is keep selling Linux machines into companies replacing their Sun server farms. The irony is that the more resources Sun pours into Java, the stronger IBM becomes. The true 'One Ring,' it turns out, is Java itself.
For More Information
- What do you think about this article? If you'd like to send feedback, you can E-mail the Editor.
- Visit our Best Web Links for Web Services for the best editor-selected resources on the Web.
- Post your questions or opinions, or help out your peers by answering questions, in our Discussion Forums.
- Ask the Experts! Our Web Services, SOAP, WSDL, XML, .NET, Java and EAI gurus answer your toughest questions.