Download XML is the foundation of componentized and interoperable Web

1. Разработка клиент – серверных приложений для
мобильных устройств. XML-Web Services
XML is the foundation of componentized and interoperable Web Services. Java and XML are
perfectly suited for each other, since Java provides code mobility while XML provides data
mobility.
Markup data languages have been around since the 1970s. In fact, the HTML itself is a markup
language. What makes XML so special? Well, there are several reasons.



XML has rich expression power. Nested tag elements allow us to easily express hierarchical
data structures. More importantly, together with technologies such as XML Schema, XML
supports strong data typing. Strong typed data are fundamental to object-oriented systems
(i.e., Java applications). Please see Chapter 16 for more on XML Schema and XML data
types.
XML is both machine and human friendly. Unlike HTML, XML has strict syntax
requirements for easy and fast parsing. For example, every XML start tag must have a
matching end tag, and they must be properly nested. Since an XML document contains
descriptive tag information, it is easy for humans to read and understand.
XML promotes open standard. XML's extensibility and flexibility allows it to be adopted
across many industries. To become a ubiquitous data exchange format, XML must be
standardized. XML namespaces and schema are already standardized by W3C. Many
industry-specific and application-specific XML formats are also being standardized. Today,
XML is the most interoperable data format across many platforms.
XML and Java champion similar ideas such as open interface, platform independence, and objectoriented data. XML support on the Java platform is traditionally very strong. All popular XML
standards are supported on the J2SE and J2EE platforms. However, XML support on the J2ME
platform, especially CLDC/MIDP platform, is still in development. XML-compatible mobile clients
are slow to emerge because of the additional processing time and bandwidth required by XML tags.
For example, the sample applications often opted for tightly packed binary streams for data
exchange. But eventually, XML will become the ubiquitous data format for mobile applications.
Throughout this and the following several chapters, we will see several real-world examples that
showcase capabilities of mobile XML clients.
Note
J2ME Web Services Specification (JSR 172) will provide a standard set of XML parsing APIs on
the J2ME platform.
Since CDC and PersonalJava have full support of core Java libraries such as IO and String, we can
port J2SE and J2EE XML libraries to those platforms or even run compiled J2SE XML libraries
directly. Having said that, specially optimized, fast, and lightweight XML parsers are still preferred
on the mobile platform.
On the CLDC platform, we need specially written lightweight XML parsers. There are several
different CLDC-compatible XML parsers available from various commercial and open source
projects. In this chapter, we focus on the open source kXML package. For more parsers, please refer
to the "Resources" section. CLDC parsers provide only the most basic functionalities, and none of
them validates XML messages against document type definitions (DTDs) or schemas.
Alternative Lightweight XML Exchange Formats
XML is often considered bandwidth expensive in mobile applications because of the extra tags.
There are various ways to minimize the bandwidth impact. In the JXME project, an XML-like
binary format is used for compact data storage; In the WAP world, a standard XML compression
scheme called WBXML is widely used. However, neither technology is widely used by enterprise
backend applications
XML Parsing Models
The XML parser converts text-based XML documents to memory objects accessible to computer
programs. There are several ways to parse an XML document.
15.3.1 SAX
SAX (Simple API for XML) is an event-based parsing model. The parser goes through the entire
document in a linear pass. When the parser encounters an XML entity—such as a tag, a piece of
enclosed text, or an attribute—it emits an event. The events are captured and processed by an eventhandler method. The application developer implements the event handler to do application-specific
tasks with those events. The kXML v1.2 supports SAX. Figure 15.1 illustrates the SAX parsing
process.
SAX parsing process.
A simple SAX application looks like the following (Listing 15.2).
A simple SAX program
// Create a SAX parser.
// This is implementation specific.
Parser p = new SAXParser ();
// "handler" is the callback object that processes SAX events.
p.setDocumentHandler( handler );
p.parse();
Although SAX is simple to implement and very popular, it is outdated by the newer pull-based
parsing APIs. For more examples using SAX, please refer to Section 17.2.
15.3.2 XMLPull
One big problem the SAX model has is that it is push based: Once the parsing is started, parsing
events are pushed in continuously. The parser runs through the entire XML document in one pass.
Developers have no control over the flow of the parsing process. For example, let's suppose that you
are looking for a specific piece of information located in the middle of an XML document. Under
the SAX model, you cannot stop parsing after you retrieve the data. The parse keeps going until it
finishes the entire document. This is ineffective, especially for mobile clients.
XmlPull API gives developers more control over the parsing flow. Since the parser is pull based, the
application can pause the parsing to take care of other things and come back later, or it can even stop
the parsing before the end of the document is researched. The kXML v2.0 supports the XmlPull v1.0
API. Figure 15.2 illustrates the XMLPull parsing process.
Figure 15.2. XMLPull parsing process.
The heart of the XmlPull API is the XmlPullParser interface. XmlPull providers supply their own
XmlPullParser implementation through the XmlPullParserFactory factory class.
XmlPullParser defines a number of event types (e.g., the START_TAG event) and data access
methods (e.g., the getAttributeValue() method). Core methods to control the parsing flow are
next() and nextToken().


The next() method advances the parser to the next event. Event types seen by the next()
method are START_TAG, TEXT, END_TAG, and END_DOCUMENT.
The nextToken() method gives developers a finer control. It sees all the events the next()
method sees. In addition, it sees and reports the following events: COMMENT, CDSECT,
DOCDECL, ENTITY_REF, PROCESSING_INSTRUCTION, and IGNORABLE_WHITESPACE.
The use of an XmlPull parser is illustrated in Section 15.5.
15.3.3 Document Model
Both SAX and XmlPull treats the hierarchical XML data structure as a linear flow. To reconstruct
data into a logical tree structure requires the developer to control the event handler carefully with
flags and case statements. This kind of code is hard to write and hard to debug. Also, SAX and
XmlPull support only serial access. We do not have random access to any node in the document.
The document model parsers come to the rescue.
A document model parser is essentially a SAX or XmlPull parser with a predefined event handler
that stores XML information into an in-memory tree. The application can then access and
manipulate any data in the tree model using a set of API methods. Figure 15.3 illustrates the DOM
(Document Object Model) parsing process.
Figure 15.3. DOM parsing.
The building block of any document model is the Node object. The Node class defines methods that
allows multiple Node objects to be linked into a tree structure. The XML document is represented by
such a tree. Objects representing other XML entities, such as elements, attributes, and text, inherit
from Node.
A standard XML document model API is DOM, which is defined by the W3C. However, the
standard DOM is quite complex. There are several easy-to-use DOM-like APIs, such as the JDOM
API, in the Java world. For mobile devices, full support for DOM has proven too expensive. A
particularly interesting lightweight XML object model is kDOM, supported by both kXML v1.2 and
v2.0. Code examples for kDOM are given in Section 15.6.
RSS
The last example of XML parser use in this chapter is a mobile Really Simple Syndication (RSS)
client. RSS is a widely used XML format for news and blog sites to feed their headline contents to
aggregators. For news sites, RSS makes it possible to advertise their headlines and provides links
back to their sites; for aggregators, the use of RSS avoids HTML screen scraping and makes it
possible to automatically aggregate a large number of sites.
Web Services
It seems that distributed computing technologies keep reinventing themselves every couple of years.
From COBRA to COM to RMI, now XML Web Services is all the rage. Web Services is touted as a
platform-independent integration technology that supports loose coupling. It promises universal
interoperability and supports advanced messaging protocols. The Simple Object Access Protocol
(SOAP) is the foundation for XML Web Services. Smart mobile clients that fit into the corporate
Web Services infrastructure could prove crucial for any mobile enterprise solution.
What Is SOAP Web Services?
Standardization is key to the success of XML. Raw XML by itself is just a bunch of tags, attributes,
and text that can be used to express almost anything in any format. The flexibility gives XML the
power of a universal data language. But in any specific application field, the meaning of XML
syntax elements must be standardized to ensure interoperability. In order for XML to carry generic
data between object-oriented programming systems, we need a syntax system that expresses
complex object and type information in serialized XML format.
The SOAP Advantage
SOAP is the most widely used protocol for XML-based object serialization. It is the technology of
choice for future ubiquitous Web Services. Compared with competing technologies, SOAP has the
following advantages:



Note
Strong type support: SOAP defines more than 40 standard data types through XML Schema
and allows users to custom-define complex data types. Such sophisticated data-type support
makes SOAP a powerful and rich language for exchanging information among today's
widely deployed object-oriented systems.
Flexible and ubiquitous messaging: In addition to strong data-type support, SOAP also
supports various messaging schemes. Those schemes include synchronous RPC,
asynchronous messaging, multicast messaging (subscription), and complex message routes
with multiple intermediaries.
Standardization: Since SOAP has gained mainstream support as a Web Services messaging
standard, most other Web Services protocols must interoperate or bind with SOAP. For
example, WSDL (Web Services Description Language), UDDI (Universal Description,
Discovery, and Integration), and most XML registries support SOAP; XML Digital
Signature, XML Encryption, SAML (Security Assertion Markup Language), and other
secure XML protocols all provide standard binding with SOAP. Each binding protocol
provides syntax of its own special element inside SOAP messages. SOAP's full support for
XML namespaces has made it easy to bind with other protocols.
The use of SOAP does present bandwidth and CPU/memory overheads for mobile devices. We have
to design our systems carefully to make judicial use of SOAP Web Services. We should use it only
to interface with external modules or when universal interoperability is a primary concern.
Serialize Arbitrary Java Objects
Arbitrary Java Serializable objects can be serialized to byte arrays and then transported by SOAP
as a Base64 element. However, this not a recommended practice, since it requires the receiving ends
to be Java aware too. If we already know that both communication parties use Java, Java-only
technologies like RMI and JMS work better than SOAP. SOAP is designed for serialization (and
deserialization) based on semantics rather than a simple object wrapper.
Architecture of SOAP Web Services
As an infrastructure solution, Web Services is touted as self-contained, automatically discovered,
and automatically configured reusable software components. Web Services is much more than
SOAP—which only serves to provide a platform-independent transport layer. Figure 16.1 illustrates
the overall architecture of Web Services.
Figure 16.1. Web Services architecture.


Each Web Service makes a description of its service available as a WSDL document. The
WSDL describes technical details on how to access the service. Authorized remote clients
can download the WSDL file and generate a stub that matches the SOAP service interface.
Any RPC method in a Java stub can be called from clientside Java applications as if it were a
local method. All leading Web Services toolkits provide WSDL-to-stub code generators.
Web Services register themselves with central registry databases such as the UDDI registry.
The client searches the UDDI, finds out the service it needs, fetches the WSDL file,
generates the stub, and starts calling remote methods.
Introducing kSOAP
To build Web Services clients on J2ME devices, we first need a J2ME-compatible SOAP parser.
Most standard Java SOAP libraries (such as the Apache Axis and Java Web SDK) are too heavy for
small devices. The open source kSOAP project runs on all J2SE and J2ME platforms, including the
MIDP. Built on top of the kXML parser, the entire kSOAP library is only 42 KB. However, as a
trade-off for the lightness, kSOAP does not support the entire SOAP specification. It supports the
most commonly used SOAP features and is sufficient for most Web Services that are currently
available. Currently, almost all major kSOAP applications and tools are based on kSOAP release
v1.2, which supports a core subset of SOAP 1.2 features. Although kSOAP v2.0 was released in
November 2002, new features are still being developed and debugged. I recommend you use
kSOAP v1.2 for important real-world applications but keep an eye on kSOAP v2.0. For developers,
kSOAP v2.0 is easy once you understand the key concepts and programming models in v1.2. For the
above reasons, we focus on kSOAP v1.2 in this chapter and give a programming tutorial for kSOAP
v2.0 in
What Is SOAP Parsing?
Every generic XML parser with namespace support understands SOAP messages and can extract
information from them. In theory, we can always extract text information from a SOAP document
using a generic XML parser and then convert those text strings to Java data objects when we need to
use them. For example, the statement
int i = Integer.parseInt("123");
converts a text string "123" to an integer value 123. But such manual conversion burdens application
programmers. Extracting Java data objects directly from a SOAP document provides a better
approach. Enter the SOAP parser.
A SOAP parser is built on a generic XML parser with special type-mapping and text datamarshaling mechanisms. A SOAP parser understands the data-type information in SOAP messages
and automatically converts the SOAP elements to Java data objects. The parser's real value is that it
makes SOAP serialization and deserialization—and the entire wire protocol-transparent to objectoriented developers. The programmer just feeds Java objects into a SOAP writer, sends the message,
waits for the server response, and then reads Java objects directly from the SOAP parser.
kSOAP Explained
The Default Mapping
By default, kSOAP understands the mappings described in Table 16.1. Notice that xsd:float is not
supported due to the lack of Float support in CLDC v1.0.
Table 16.1. Default Type Mapping in kSOAP
SOAP type
Java type
xsd:int
java.lang.Integer
xsd:long
java.lang.Long
xsd:string
java.lang.String
xsd:Boolean
java.lang.Boolean
When a simple kSOAP parser encounters a SOAP element, the parser reads the XML element into a
Java object according to the following rules:




If the SOAP element is one of the default primitive types in the table above, it converts to a
Java object of a matching type.
If the SOAP element has no children (a primitive element) but is not a default type, it
converts to a SoapPrimitive object. We can retrieve the element's original SOAP type
information from the SoapPrimitive.getNamespace() and SoapPrimitive.getName()
methods. We can access the element's string value from the SoapPrimitive.toString()
method.
If the SOAP element has children (a complex element), it converts to a KvmSerializable
object. KvmSerializable is an interface; the kSOAP package provides the interface's
convenience implementation: SoapObject. Similar to SoapPrimitive objects, you can
retrieve the element's original SOAP type information from the
SoapObject.getNamespace() and SoapObject.getName() methods.
A complex element's children convert to properties inside the parent SoapObject according
to the above three rules in this list. Each property also has an associated PropertyInfo
object containing information such as the SOAP element name and the property's Java object
type. The PropertyInfo class supports element namespace in kSOAP v2.0 beta.
16.3.2 Object Structure
Since a SoapObject can take other SoapObjects as properties, we can use SoapObject to express
complex hierarchical structures. An analogy to the XML DOM can be drawn here: The SoapObject
resembles the parent node, and the property and PropertyInfo pairs resemble child nodes.
In simple cases, like the Google spell check example where the document contains only one
primitive SOAP element, we can directly retrieve the mapped Java object or SoapPrimitive object
through the SoapEnvelope.getBody() or SoapEnvelope.getResult() methods. If the SOAP
message contains more information, the above two get methods return a root SoapObject, which
contains the entire hierarchy of Java objects mapped from the SOAP elements according to the
above rules.
getBody()
versus getResult()
The getBody() method gets the first child element of the SOAP-ENV:Body element. The
getResult() method gets the first grandchild of the body element. Method getResult()
is used in HttpTransport class to parse the RPC response message because the return
value is always embedded in a result element under the SOAP body element.