In-Depth

Catch of the Day: JAVA and XML in J2EE

The platform-neutral J2EE is becoming the middle tier of choice.

The eXtensible Markup Language (XML) and Java have always been a perfect fit. XML contains data, Java does something to it, and both can run on nearly any application platform.

The next few releases of Sun Microsystems' Java 2 Enterprise Edition platform (J2EE) will closely integrate XML and Java with the addition of three significant XML APIs.

Of these APIs, only one will be available when J2EE 1.3 ships; the other two will arrive later this year. Sun also plans to offer XML support in its Java servlet technology, which serves up data from a database to a Web page.

Incompatible No More
Although application server vendors already offer some of the functionality in these APIs, the functionality varies from server to server. Because most organizations tend to hedge their bets by buying servers from several vendors, they'll face incompatibility problems.

This is one reason why the platform-neutral J2EE is becoming the middle tier of choice. It runs on nearly every application platform, making hardware, platform, operating system and data source(s) immaterial.

A Java-Centric Approach
"The ultimate goal is to deliver some APIs with open, vendor-neutral standards and provide better interoperability between application servers," explains Karen Shipe, product line manager for Java XML technology at Sun. "The APIs all address some sort of problem people have encountered in the industry, like parsing, delivering e-commerce messaging and conversion from XML data to Java objects and back."

While Sun's Java-centric approach to XML should come as no surprise, it has some people worried. Giga Information Group Director Randy Heffner says, "If [the APIs] weren't in there, then I'd be saying they're really missing the boat." He cautions, "There are broader ways to look at applying XML, rather than being Java-centric. Sun should expand their view more to see things with different-colored glasses like XML and Web services."

JAXP: The Bait and Switch
The first and only API to ship with J2EE 1.3 is the Java API for XML Processing (JAXP). This provides an XML parsing interface.

This interface is comparable to the swivel on a fishing line. The swivel lets you quickly switch from one lure to another. Without a swivel, the lure would be tied directly to the string, forcing you to cut the line and make a new tie every time you wanted to change lures.

In the pre-JAXP world, developers had to hard-code calls to an XML parser, such as the Simple API for XML (SAX), a standard interface for event-based XML parsing; and Document Object Model (DOM), an XML document processing API. This was tantamount to tying the lure directly to the line. If you wanted to change parsers, you had to change all of the code that called the parser.

With JAXP, Java programmers code to the JAXP interface, which uses the parser of choice. Because the application speaks to the API, not the parser, programmers can easily switch parsers without having to rewrite their parsing code.

Getting Feedback
Sun hasn't tested JAXP against every parser on the market, but it has tested it against the most common parsers, including SAX, DOM and Xerces, the open-source parser developer from The Apache Group.

"This API frees up so much time for me," says Michael Riecken, senior consultant with The Stonebridge Group, an IT development and consulting firm in Minneapolis, Minn. "I don't have to write stuff from scratch, because it's independent of the input stream. All we have to do is handle network communication."

For performance and speed, the Stonebridge Group frequently develops applications using one parser and deploys on another. In the past, this meant having to rewrite all of the parse code. JAXP lets the developers switch APIs between development and deployment with minimal effort.

JAXB: Tying the Fly
JAXB is the Java API for XML Binding, a schema compiler and marshalling framework for mapping data to Java objects and back. Using JAXB, the XML data is handled as a Java object. This means Java programmers can handle the data rather than having to hand it off to XML programmers.

Data binding automatically maps the components of an XML document to in-memory Java objects that represent the document's intended meaning, according to its schema. This process is called "serializing data." All the bits and bytes of data are stored to a file on disk or network stream.

Data is unserialized by recreating the same data state in memory. It's a quicker and more secure method of storing both the data and the object that uses the data, in this case a bean. Java programs that manipulate XML content can be written at the same conceptual level as the content itself, rather than at the line-by-line level of a parser.

Serialized data is also ideal for passing objects from system to system. This allows complex data, such as graphics or rich text, to be passed among machines without losing its original state.

Otherwise, the data would be transformed through an XML parser and re-created on the recipient machine. This poses risks because, like it or not, XML still isn't an entirely precise language. There's a chance you could lose a complex chunk of data in the parsing translation.

JAXM: Reeling 'Em In
When it comes right down to it, XML data transfers are completed with faith and crossed fingers. They lack the security, reliability and data integrity that message queuing has had for years.

JAXM 1.0 is the Java API for XML Messaging. This API is for building reliable XML messaging into applications. JAXM will add some of those XML message exchange features and make XML data transfers more asynchronous, just like message queuing is today.

JAXM will provide a standard message envelope and headers for routing of message content and reliable delivery of messages. It will also add template support for a variety of data types in message payloads, privacy and integrity of communications between parties, authentication of senders of messages and secure audit trails.

Hook, Line and Sinker
Java Server Pages (JSPs) are Sun's answer to Microsoft's Active Server Pages (ASPs). In J2EE 1.3, they'll get a slight upgrade with the addition of hooks to run JSP data through an eXtensible Style Sheet Transformation (XSLT).

This process allows data to be transformed for easier viewing on a variety of target clients. For example, HTML looks terrible when viewed on wireless devices, such as Palm Pilots or wireless phones. An XSLT filter can reformat the data to make it more presentable to different clients.

XSLT will be particularly useful for companies, such as Encore Development (Jacksonville, Fla.), a custom application development firm. Orlando Caro, senior engineer at Encore, explains, "We can write code and not have to worry about the client. Otherwise, we have to sit down and create our own deployment descriptors for the app server all over again."

Making a Splash
J2EE 1.3—with the XSLT support in JSPs and the JAXP API—will ship in the third quarter of this year. The JAXM and JAXB APIs will ship by the end of the year and operate seamlessly with J2EE 1.3. Sun plans to make these APIs all standard features in J2EE 1.4.

Although it will be several months before you'll see these APIs in one bundle, the wait will be worth it. We'll see a simplified XML deployment and greater code reuse than is possible today. Rather than constantly working to stay current in every application server technology, programmers will be able to focus on one technology and apply it across multiple platforms.

Must Read Articles