Kendall Clark's most recent XML-Deviant column highlights the debate of subsetting XML, JAXP and SAX in the J2ME Web Services Specification (JSR 172). At issue is the specification allowance of
parsers to throw a SAXParseException when encountering a document type declaration, and to not support non-predefined entity references and interoperability with the full XML specification.
This is an excellent point. While I believe not all Web services should useful to a mobile device the current handling of such an occurrence is unacceptable.
In the article Michael Champion is quoted asking
what's a cellphone supposed to do with an external entity reference, or a notation declaration? The answer is simply — nothing. In the tradition of the Web, I would suggest unknown data types be quietly ignored unless explicitly declared programmatically by the developer.
This recent debate has returned my attention to some comments I submitted to the JSR 172 group in December and another major failing of this specification that I have not seen discussed.
I've yet to completely review this draft, but I have scanned the change log and checked for what I thought was the one of the most crucial omissions
the word asynchronous.
There are zero occurrences of the word in this draft. As I wrote in my comments to the JSR 172 group,
if there is one place where asynchronous messaging is most needed its with the unreliable low-bandwidth mobile networks that mobile phone and PDAs operate.
One of WAP's leading failings (and there where so many) was that applications were useless if a connection was not available or lost. In the US we know how common this occurrence is. Sun lists J2ME's local execution of applications (MIDlets) as a key advantage over WAP applications on mobile devices. However without there will not be a standardize way in this specification for a developer to cope with a loss of connectivity. Without the ability to deal with the loss of connectivity Web service-enabled MIDlets will be useless as a WAP application. That's why I find it remarkable that this specification does not support this vision.
I'm sometimes taken aback as to how little we the developer community seem to understand the realities for developing for the mobile medium
particularly resource constrained devices like mobile phones or common PDAs. It is not realistic to believe the solution is mobile phones become as powerful as laptops and bandwidth to become as plentiful as air. Social, economic and environmental factors make this difficult to address and unlikely to succeed in practice.
Sadly, it seems this has been lost on the JSR 172 group and we'll have a mobile Web services specification, and eventually implementations, that really aren't very useful or reliable in reality.
I am cautiously optimistic that some form of
Web services will be achievable though its likely to be outside of this specification and subject to a different set of issues.
Consider this: J2ME supports HTTP communications down through MIDP and the recently released MIDP 2.0 specification supports a push communications facilities. (See my article on MIDP 2.0 for more.) RESTful J2ME Web services anyone?
The following is my email to the JSR 172 in its entirety including grammatical mistakes. ;)
Subject: JSR-172 v.03 Draft Comments. Date: Sun, 15 Dec 2002 20:50:47 –0800 (PST) From: Timothy Appnel To: email@example.com
I've read the v0.3 draft of the J2ME Web services specification and have these comments to submit for consideration by the JSR 172 expert group.
First, I'd like to acknowledge and commend the group on taking what is truly a difficult assignment. XML and Web services specifications where not designed with such resource constrained environments in mind, however the loss of flexibility and openness to a proprietary or binary would be unfortunate.
I think the JAXP subset, including restrictions of DTD support, is reasonable though I feel 25KB is not acceptable size in comparison to other J2ME XML parsing packages such as kXML. I realize that this packages are not JAXP compliant, however in my experience in MIDP development, it is my belief that file size and speed is more important then compatibility with JAXP. Existing J2SE and J2EE code is likely to be inappropriate for J2ME applications and will require some refactoring regardless. Given these circumstances I would choose to use kXML that only has a file size of 9KB in its minimum package form.
Likewise I think the JAX-RPC functionality is reasonable however it is my opinion that RPC support is not nearly as useful or relevant to providing Web services through some simple form of asynchronous messaging. The continued emphasis on RPC style Web services remains my biggest criticism and disappointment of the group's work so far. If there is one place where asynchronous messaging is most needed its with the unreliable low-bandwidth mobile networks that mobile phone and PDAs operate. While the specification does not preclude the implementation of service QoS mechanisms that would provide the infrastructure for dealing with unreliable connections, a generic baseline should absolutely be required. I strongly suggest the expert group reconsider this decision.
A 50K file size is a bit larger then I would hope. I had 35K-40K in mind. Related to file size, I understand that the J2ME JAX-RPC package must be independent of the JAXP package. The specification does not clear state what (if any) ROM savings there are if the two coexisted. If there were not any savings to mention, I would question why this is since clearly the JAX-RPC package must parse XML to function.
The data types support in the JAX-RPC subset is acceptable. In the tradition of the Web, I would suggest unknown data types be quietly ignored unless explicitly declared programmatically by the developer.
I think defining a recommended protocol would be warrant if its allows the specification to assure a standard and demonstrative means of reducing bandwidth consumption. Given the verbosity of XML and Web services protocols some form of compression is needed in this specification.
Given the SOAP 1.2 protocol's release is likely to occur before this specification's release, I would suggest that more consideration and emphasis be placed on SOAP 1.2 then what currently exists in this draft.
I hope that my comments have been helpful and constructive. Please feel free to contact me if any further questions exist or further discussion is warranted.
What do you think of the JSR 172 specification and Web services place in mobile?