Simple text messages, readable and writable by people and computers, live at the core of every successful Internet application. XML seeks to grow the expressive power of these texts while preserving their accessibility. Java, although born to the Internet, has been oddly slow to embrace these paradigms.
For example, regular expressions are the most basic tool for working with patterned text. Yet only now, in the JDK (Java Development Kit) 1.4 release, do regular expressions become a standard feature of the Java platform. Likewise, basic XML facilities such as parsing with SAX (Simple API for XML) and DOM (Document Object Model) interfaces, and transformation with XSLT (Extensible Stylesheet Transformation) -- although long available from other sources -- make their first official debut in J2SE (Java 2 Standard Edition) 1.4.
Although Sun's Java/XML engine may have started slowly, it's really cranking now. A set of unbundled XML and Web-services APIs, in various stages of development, seeks to complement the XML core that's built into the platform. These "JAX Pack" APIs define a Java framework within which developers can perform several tasks, including the following.
- Translate between XML documents and native Java objects
- Use tightly-coupled RPC-style (Remote Procedure Call) Web services
- Use document-style Web services that communicate in more loosely coupled ways
- Locate Web services using UDDI (Universal Description, Discovery, and Integration) or ebXML (e-business XML)
All this lingo, admittedly, gets pretty thick. To cut through the fog of acronyms, Sun offers the mantra: "Portable code, portable data." That's helpful, but there's no avoiding the fact that the simplicity of the early Internet is just a memory. We now expect the Internet to do everything that proprietary enterprise systems once did and more. The result is a welter of initiatives that no single platform can hope to nail down in a single iteration. Sun's strategy, as the next-generation Web bootstraps itself into existence, is to adapt Java as flexibly as it can to an ecosystem in rapid evolution.
The whys of the APIs
So what exactly are the features of Sun's emerging Web services model? For Hal Stern, CTO of iPlanet's software division, there are three core activities: creating service endpoints, assembling services into business processes, and deploying these in ways that administrators can control and users can comprehend. "We tend to lump all these things together," Stern says, "without realizing that requirements in one domain may affect another." For example, SOAP (Simple Object Access Protocol) messages can easily be encrypted using SSL (Secure Sockets Layer), but what's the security context in which such messages are exchanged? Tacitly or explicitly, it is defined by existing networks, applications, and business processes. These are diverse within companies, and even more so across them.
Creating context for Web services is the charter of ebXML, one of the messaging profiles supported by JAXM (Java API for XML Messaging). (Another JAXM profile is WS-Routing, formerly SOAP-RP.) But business-collaboration protocols such as ebXML will not soon, and may never, solve the kinds of semantic problems that plague systems integrators who regularly struggle with the need to match one company's definition of supplier, customer, or purchase order to another's.
"You're not going to change SAP's or Siebel's notion of a user," Stern says. What you can and must do is map between these representations. No matter what style of XML messaging is used to connect them, the fact that it is XML guarantees that you can create that mapping.
Note that although Sun's "portable data" slogan implies Java-to-non-Java interoperability, that isn't the only reason to use XML with Java. Application semantics ride on top of platforms and languages. Even in an all-Java environment, XML creates common ground on which to wrestle with those semantics. Were this not so, JAXB (Java Architecture for XML Binding), which translates between Java classes and XML documents, might seem useful only for communicating with the non-Java world. After all, Java has always natively supported the serialization of objects to and from a binary format. But Java doesn't natively support the transformation of objects, and it is nicely complemented by XML in this regard.
Styles of Web services
First-generation Web services recapitulate a theme we've all seen before: Issue a remote function call, receive a package of data in response. As industry veterans like to say, "just insert your favorite RPC protocol." Whether you use Java's RMI (Remote Method Invocation) or XML-RPC or SOAP, it's all the same kind of thing. When the calls and responses are written in XML, however, they're open to easy inspection and manipulation. Of course, XML also underpins the language and platform neutrality that is the hallmark of Web services. The Web services "stack" -- SOAP, WSDL (Web Services Description Language), and UDDI -- aims to make the dream of cross-language and cross-platform interoperability come true.
That dream hasn't quite come true yet, despite much encouraging progress. One reason is XML's transition from the DTD (Document Type Definition) as a way of defining data types, to the much richer XML Schema. WSDL uses XML Schema to articulate the types of objects exchanged among Web services. Since January, Version 1.2 of Sun's JAXP (Java API for XML Processing) has included the Apache XML Project's Xerces 2 parser, which supports XML Schema. Confusingly, J2SE 1.4 includes the older Crimson parser, which doesn't support XML Schema. (Likewise JAXB currently supports DTD only, not Schema.) A further wrinkle is that the Java API for WSDL remains in the request phase of the Java Community Process, and isn't yet included in the JAX Pack. On the bright side, it's encouraging to see Sun working more closely with the open-source community, which has delivered so much Java/XML innovation.
Even as RPC-style Web services settle on a Schema-based type definition, a new document-oriented style is emerging. In the latter case, the body of the SOAP message does not model the call/response semantics of conventional programming languages. Rather, it carries arbitrary XML documents, which can also be described in WSDL and validated using XML Schema. The champion of this approach has been Microsoft, whose .Net toolkit prefers the document-oriented flavor of SOAP. Sun's JAX Pack includes APIs geared for both approaches: JAX-RPC (Java API for XML-based RPC) for RPC-style Web services, and JAXM for document-style services.
Developers facing these choices find themselves anxiously scanning "use case" matrices that describe when and why to favor one approach or the other. The long-term trend is clear. RPC technology may or may not prove sufficiently robust at Internet scale, but the Web is proof that pure document exchange will. In a world of rapidly changing business alliances and technical infrastructures, large-scale distributed applications cannot depend on brittle RPC-style APIs that require all endpoints to evolve in lockstep. The more XML messages say about themselves, the less their senders and receivers need to know about one another's infrastructures.
This loosely coupled approach can even make it possible to develop new application behavior in a declarative rather than procedural way. "Configure, don't code," says MetraTech, a company whose Web services-based billing engine supports telecommunications service providers. With MetraTech's solution, a service aggregator who defines a new offering in conjunction with a partner doesn't code another interface, but accepts a stream of XML that defines how the new service works. "By describing more of the system in a way the computer can understand," says MetraTech's CEO Jim Culbert, "we can make the tools do a lot of what used to be rocket-science coding."
Bootstrapping the next-generation Web
Clearly there will be lots of ways to produce and consume SOAP services in Java. Too many, perhaps, but when you're bootstrapping it's wise to accommodate a broad range of legacy systems and attitudes. The real question for Java developers, and indeed for all developers, is how to contextualize the use of those services. To that end, iPlanet's Stern argues for "a thin waistline of core standards" -- just SOAP and WSDL and UDDI. "Then let's innovate on top of these to solve the assembly problem," he says.
At this level, conventional programming languages fade into the woodwork. The focus shifts to languages that are today spoken, and protocols that are today enacted, by people. When a company signs a new supplier, Stern points out, lawyers gather in a room to negotiate terms and conditions, and all documents subsequently exchanged fall within the scope of that agreement. ebXML addresses this realm. So does IBM's WSFL (Web Services Flow Language), and Microsoft's XLANG, the orchestration dialect of BizTalk Server. Until basic Web services find their way into routine use, we won't be able to fully evaluate these approaches to composing systems based on them.
Java may have arrived late to the Web services party, but the music hasn't really started yet. When it does, nobody will remember who shipped what kind of XML parser for which programming language on what date. We'll all be too busy figuring out how to piece together a much larger puzzle.