A key ingredient for any web services application is SOAP. The problem with developing a wireless SOAP/XML application — and the reason for the above-mentioned JSR172 — revolves around the following issues. First, the common XML and SOAP packages currently available are quite large and contain hundreds of classes. Second, these packages depend on features of the Java runtime that simply don’t exist on a microdevice. I’m thinking specifically about the Connected Limited Device Configuration (CLDC) specification which did away with nearly the entire core set of Java classes normally present in the J2EE and J2SE distributions: AWT, Swing, Beans, Reflection, and most java.util and java.io classes have simply disappeared. The purpose of this “bare bones” Java runtime is to accommodate the limited footprint of the KVM — a low-memory virtual machine running on a microdevice.
This is where Enhydra.org comes to the rescue. KSOAP and KXML are two packages available from the web site designed to enable SOAP and XML applications to run within a KVM. They are thin, easy to use, and well documented. Combined into a single jar file, they take up less than 42K.
KSOAP begins with a class called SoapObject. This is a highly generic class which allows a wireless application to build SOAP calls. A quick look at the documentation reveals that the methods getProperty() and setProperty() are used to accomplish this functionality.
You might immediately notice the conflict with traditional Java programming inherent in this design model; it detracts from the use of static typing. Ideally, application development goes more smoothly if the data structures are defined statically and are able to be marshaled/unmarshaled across the network, just as if they were running within the same runtime environment. In other words, imagine having to rely solely on the Hashtable for all your data structures, assigning each property a key for access and retrieval and then having to remember each property’s unique key and given type.
By having your data model defined statically, a developer can forget all that and rely on the compiler, not the runtime, to catch the type-mismatch errors. Further, casting is kept to a minimum, and it is easier to take advantage of tool support that depends on static typing to help the programmer.