Java, XML, and Web services

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.