| QUESTION & ANSWER |
The case for document-centric Web services development |
 |
By Colleen Frye, News Writer
15 Jun 2005 | SearchWebServices.com |
|
|
Edmund Smith, a software engineer at EMB, in Cambridge, England, recently co-authored a white paper, "Rethinking the Java SOAP Stack," with Steve Loughran, a scientist from HP Labs in Bristol, England. In the white paper, the authors make the argument that the Java application programming interface (API) for XML-based Remote Procedure Call (RPC), formerly known as JAX-RPC (now JAX-WS), is fundamentally flawed. Moreover, they claim that any SOAP API that relies on a perfect two-way mapping between XML data and native language objects is flawed.
The authors have proposed an alternative SOAP stack for Java, dubbed Alpine, which takes a more document-centric approach to Web services development. Rather than mapping between XML and custom Java classes, Alpine will provide access to SOAP messages using modern XML support libraries. Alpine will require an understanding of XML, which the authors claim is needed to develop robust Web services, and they advocate that Web services developers should acquire that skill. What are the key advantages and drawbacks to a document-centric vs. an RPC-centric approach to Web services development?
Edmund Smith: Document-centric development focuses upon on the exchange of messages, with significant emphasis on understanding and managing the messages themselves. When an RPC-centric viewpoint is applied to Web services, control of the messages is delegated to third-party components, and developers are encouraged to think only of the method invocations involved, and perhaps to think of service instances as remote objects.
In encouraging developers to think of Web service development as no more than development of a Java class with annotations, an RPC-centric approach does not encourage good service architecture, nor is interface stability likely to be maintained. The lure of a familiar paradigm attracts developers down this route, but ultimately that familiarity is an illusion: A Web service is fundamentally not like an object instance that might throw RemoteExceptions every now and then.
Is a document-centric approach inherently less complex?
Smith: The upfront complexity of a message-centric approach is higher, but any developer working on services in production environments will end up facing that same complexity. In the case of an initially RPC-centric design, it will be compounded with the additional complexity of all the code that initially hid it from them. They're then faced with the task of trying to control the messages at a further degree of separation; in JAX-RPC 1.x it can feel like sewing with boxing gloves on after a while -- sure you don't get hurt at first, but trying to match someone else's pattern is pretty difficult.
What prompted the white paper?
Smith: Steve [Loughran] has been a contributor to the Apache Axis project [for] some time, and I spent some time developing a testing framework for grid services built on Axis. The idea for the paper came from the work Steve and I did on the Web service API for the CDDLM [Configuration Description, Deployment, and Lifecycle Management], a working group of the GGF [Global Grid Forum]. Our frustration with the standard approach to service development in JAX-RPC ultimately lead to the paper being written.
What do you think of the reaction so far?
Smith: I think the reaction so far has been largely positive. Regardless of whether I agree or disagree with some of the online commentary, I think that the discussion we've provoked in terms of the direction Java Web service development should be taking is valuable to the community. There is an obvious tension between those people who feel that Web services should be as accessible as possible, and those that worry we risk losing the virtues of interoperability and flexibility that made Web services compelling in the first place.
Will the Alpine initiative change the way we think about Web services communications and standards such as SOAP? Why or why not?
Smith: It's clear that there isn't one single way of thinking about Web services at present, and that seems unlikely to change in the near future. Alpine represents the logical conclusion of one of those ways of thinking, focusing on the messages involved in the communications themselves. If Alpine is successful, it's possible that more people will be won over to the advantages of this document- and message-centric mode of development.
JAX-WS 2.0 (Java API for XML Web Services), formerly JAX-RPC 2.0, is said to be more document-centric. How do you respond?
Smith: The current draft of the JAX-WS specification seems to create the potential for more document-centric usage; indeed the proposed functionality for Alpine may well form a proper subset of the JAX-WS standard. It doesn't seem that the emphasis has shifted toward a document-centric viewpoint, more that document-centric development is no longer so undermined.
Ultimately, JAX-WS retains the paradigm of service calls as method invocations, and of automatically generated service interfaces, that made JAX-RPC so flawed. While it's no longer obligatory to use this functionality, that's not the same thing as making it any safer to do so.
What happens after you present the paper to the IEEE in July?
Smith: We're already working on the design of Alpine, and we expect the effort to continue for the foreseeable future. Presenting to ICWS [International Conference on Web Services] will afford an opportunity to discuss further the direction in which Web service stacks should be heading. We don't have any timetable for the development of Alpine at present.
|
