Oracle's Thoughts on Removing Message

Oracle's Thoughts on Removing the Message Construct

We considered the proposal to get rid of the Message construct in WSDL. This note summarizes our perceptions and concerns.

In general, simplification is always a desirable outcome. We should strive for a reconciled representation using the available XML constructs. Given this intent, it appears at first that the constructs, Message and Part, repeat some of the functionality that are already provided by XML Schema on the surface. For example, a complexType may express the same conceps as a "sequence" of fixed number of elements which may be considered to map to message parts. The message/partrelationship can be expressed by using XML schema in a certain restricted way, i.e. sequences, no multiplicity, etc. Roberto's proposal provides examples to this effect.

We observe that using XML Schema is presented as a "solution" to some of the shortcomings of Parts:

multiplicity (and hence optionality) of each part
references and content sharing
arbitrary order of parts
extensible number of parts

However, it is not clear what the problem that we are trying to solve is. The listed shortcomings are the essence of easily describing RPC style interaction expressed by a WSDL document. In such interactions, it is essential to have the restrictions for which the proposal is intending to solve, i.e. arbitrary ordering of parts does not make any sense for mapping to RPC calls. Except the intent of expressing referencibility between multiple parts, the relaxation of these constraints, even without moving to XML schema but by extending Part definition, would be very problematic for RPC.

PortType is an abstract construct and the binding describes the actual message sent. By removing the message construct and by having one element/Type to describe the message, we will lose the ability/flexibility of distributing the abstract parts of a message among various sections of an actual message. This means ultimately a mechanism is needed in the binding to be able to dictate where pieces of the data should go, i.e. header/body/attachments etc. Given the current proposal and RPC style encoding, we made the observation that a meta-data mapping between arbitrary XML schema constructs and RPC style interactions would have to be defined in the binding.

We believe that there are several issues for the meta-data to represent arbitrary mappings and using XML schema alone. Some of them have already been addressed in the emailing list:

representing attachments within XML Schema components and their mapping.
representing attachments which are not XML documents, i.e. jpeg documents with XML schema. This requires some wrappering specification for attachments in general.
the complexity of representing a generalized mapping between XML Schema constructs and the binding.

This mapping would have to work both ways, for extracting actual parts from the documents as well as constructing documents from results. Whatever scheme is used, it must be fully reversible in order to reconstruct the data on the receiving side. We cannot think of an obvious solution to this reversibility - XPath is only good for the extraction and not the reconstruction. Further, this approach would make binding information completely unreadable from a human pespective and would require complex tools.

On a philosophical level, it appears that this would further fundementally challenge the RPC style usage of Web Services in favor of Document style. It appears this way because

The role of Operation would become unclear as "parts" would not be easily identified. If we were to go down this route, operation would not be very meaningful as RPC style method binding would not be easily expressed if the mapping problem is not addressed adequately. Today, we don't have this problem.
It is essential to have a canonical wire representation so that RPC message exchange can be utilized. Without operations and parts mapping, this does appear to be problematic.

Today, the Message/Part structures serve a very useful purpose. They provide a very natural way of describing RPC style exchange pattern and allow vendors to provide tools for writing and generating web service implementations. Further, utilizing the full power of XML schema is not disabled with the current WSDL design. It is subsumed by using only one Part and using a complex XML Schema type to represent the content. Namely, a schema type can be used today to represent elements with multiplicity, extensibility, etc. This means we have the functionality we need without making RPC unnecessarily complex and without needing redesign.

We therefore believe that it is essential to look at the architectural implications of "fixing" the problems of Message/Part constructs. WSDL is essentially a representation of a service and describes how a service should be used to those parties which will make use of the service. We are concerned that making this change will introduce fundamental problems the way web services are going to be implemented & used by making RPC style interactions extremely difficult to express.