n Part I of this article, you saw how to read and write the WBXML format. To use WBXML in any EDI scenario (such as database synchronization) you must be able to convert the WBXML to XML (human readable format) or parse the WBXML directly into SAX/DOM.

Therefore, it’s useful to have a generic mechanism for performing both tasks so you can use the appropriate version to build applications. Imagine a distributed application that runs on two web servers. The data flow within the sample application is:

1. A simple HTML page (see Listing 1) sends a data request to a JSP page (see Listing 2) running on Web Server 1 (an imaginary retailing company’s web site). In the sample application, the JSP page in Listing 2listens at http://localhost:8080/examples/jsp/wbxmlTest_2ndVersion/Retailer/Retailer.jsp.
2. Web Server 1 does not have the data required to fulfill this request, therefore Listing 2 calls its server side JavaBean Converter (see Listing 3) which generates a WBXML stream equivalent to the XML request. The JSP page then calls another bean Server2ServerCommunicator (see Listing 4) that also resides on Web Server 1.
3. The Server2ServerCommunicator sends an HTTP request to a remote server (Web Server 2, a manufacturer’s web site), using an HTTP PUT request. The request requires the PUT method because you need to send a non-textual binary data in an HTTP request—and there’s no content-type setting field in an HTTP request (the content-type field is available only in an HTTP response). If you use a GET request an HTTP client will treat your data as text and will convert all bytes above 0x7f to a question mark (meaning it doesn’t understand those bytes in textual format). The HTTP PUTmethod was designed for HTTP file upload sequences, and therefore the server doesn’t care about content types for this method—it just reads the binary data without converting it.
4. The JSP page in Listing 5 on Web Server 2 listens at the URL http://localhost:6080/examples/jsp/wbxmlTest_2ndVersion/Manufacture/Manufacture.jsp. It receives the request as a WBXML stream. The JSP page calls the Converter bean (see Listing 3 needs to be present on both servers), which transforms the WBXML back into XML. It then adds the required data to the resulting XML document. The code creates the XML document using Java’s String class without using the DOM. By focusing as much as possible only on WBXML related issues, the XML operations are very simple. In real world applications, XML is rarely this simple, so the preferred way to create an XML stream is by using the DOM. Finally, the JSP page in Listing 5 calls the Converter bean again (see Listing 3) that creates the WBXML version of the updated XML stream.
5. The last step in this sequence is to send the WBXML back to Web Server 1, which converts the response WBXML file back into XML before sending it to the requesting client.

Here’s a more detailed analysis of the Converter bean in Listing 3. The converter class has two methods: getWBXMLStream, which converts XML to WBXML, and getXMLStream, which converts WBXML to XML. Both methods accept and return a byte array. The example uses kXML to perform all low-level XML to WBXML (or back) conversions. kXML is part of the EnhydraME Open Source Project. KXML offers various parsers and writers. The converter class uses the kXML:

• XML Parser
• WBXML Parser
• XML Writer
• WBXML Writer

The parser classes read and parse input documents in XML or WBXML format, and load the parsed tree in memory. Writer classes write output to an output stream object. You can use any Parser/Writer combination to convert one format to another. Therefore, here’s the sequence to perform XML to WBXML or WBXML to XML conversions:

1. Create a parser object and pass the input stream (XML or WBXML) to it.
2. Create a DOM document object.
3. Call the document object’s Parsemethod , passing the parser object from step 1 to it as a parameter. At this point, the input stream exists in memory as a DOM object.
4. Create a writer object that matches the desired output format. For example, use an XmlWriter object if you want to produce an output XML stream.

1. Call the document object’s Write method to write required format to the output stream.

WBXML with J2ME
You’ve seen how to convert XML to WBXML and back, but you can also parse a WBXML stream directly—without first converting it to XML using the Java 2 Micro Edition (J2ME). Although the example is client-side code, the concepts discussed in this section are equally applicable to server side application development scenarios.

The J2ME application sends a WML file from a JSP web server to a J2ME client using an Open Source WAP gateway (JWAP, see the References column). The WAP gateway translates the WML file to WBXML before sending it over the air to the wireless J2ME client. The sample client-side application receives the WBXML data, parses it and displays useful information on the J2ME screen.

Look at the getConnect method in Listing 7. The method makes a Datagram request to the port for the JWAP server (the example uses datagram://127.0.0.1:9200) and sends it a hard coded Wireless Session Protocol (WSP) request. (Wireless Session Protocol is the wireless version of HTTP).

The JWAP gateway forwards the request to the destination Web server http://localhost:8080/examples/jsp/finalfiles/Dat.jsp in the example). When the JSP page in Listing 6 receives the request, it responds with a hard coded WML file containing the WML content-type encoding.

The JWAP gateway receives the WML file, converts it to WBXML on the fly and changes its content-type encoding to WBXML. It then forwards the WBXML stream to the J2ME client’s getConnect method. The getConnect method forwards the data to another method, called getIncomingTextOfWmlc, which extracts information from the data. JWAP communicates using a WAP protocol stack, so it wraps the WBXML data with a WSP header that the getIncomingTextOfWmlc method discards (the WSP header content is not important for the purposes of this article).

After discarding the WSP header, the getIncomingTextOfWmlc method follows a four-step, event-based parsing mechanism using kXML:

1. Create a WmlParser object, passing in the input stream holding the WBXML byte array to its constructor.
2. Call the WmlParser’s Read method The Readmethod throws the first event that it finds in the XML file.
3. Read the event and check it if it’s the one that you’re looking for (in this example, you’re looking for a start tag event containing a specific attribute).
4. Repeat steps 2 and 3 in a loop.

The example in Listing 7 shows the process in its most basic form, but you can build comprehensive parsing mechanisms based on this very simple logic.

Using this method, you can use WBXML directly without first converting it to XML. You might be wondering whether kXML internally converts WBXML to XML before parsing. It doesn’t. It parses WBXML directly without creating any XML stream. You can obtain the kXML source code, and I encourage you to do so and study it.

The WBXML file format significantly reduces the size of XML files, making it possible to use XML not only in WAP devices, but also in other Web-based programs that must send significant volumes of XML-formatted information over the wire.