|
'Note that I'm not against XML-consuming services: I just feel that the proper place for XML is as a representation for the data objects being manipulated and not as a marshalling format for parameters to a method call.'
this smells a little bit,
marshalling is the process of getting some possibly disparate bits of data--> put em in a buffer of some type--> organise/format as per the requirements of the reciever or programmatic interface. simple definition....
this is a well known pattern when working between language x and language y....in actual practice marshalling has proven to be inordinately difficult, as the implementation becomes rather specific to lang x and lang y, *because* there has been no agreed upon meta data format between the two; when there is an agreed upon meta data format this becomes easy; look at WDDX for example.
now that xml is and will be ubiqitous, internally and externally within lang x and lang y or remote procedure blah blah..... the idea of marshalling may change....( why fax when one can irc ? ).
the key issue, with most xml technologies;
a) does xml define a process with some sort of xml based language
or
b) is xml the substrate or format of this process
most efforts tend to mix the 2...
a few examples;
- in the EXSLT effort, we decided to generate standard *definitions* of functions, instead of binding the actual implementation with the definition. How many times has a simple function like string tokenize function been implemented in how many different languages ?
- in the XForms effort, there seems to be a lot of implementation specific details, along with generic form definition; mixing of the 2 strategies creates subtle situations, that are confusing for tool developers and authors, i would always like to see clear seperation between definition and implementation ( once again my mouth waters at the UML code generation aspects... )
- if one views SOAP as an IDL or definition format, then who cares what actually goes over the wire ? you are ( at its simplest ) one transformation away from whatever format that will become. ok, this is simplistic, but what to me is more important is to define a language which defines the process, instead of becoming both definition and implementation.
- WSDL is currently being adopted because it kind represents the URI in the REST equation for developers and web services users to *use* the service; this seems to be the useful cog in the whole system at present; especially with the auto code generation within the various languages; though i for one can foresee some issues down the line if we continue to use WSDL.
In almost every situation, i would opt for creating a *definition* in xml format, to give a coherant meta data skeleton which can then be fleshed out with any implementation ( using xml or not ).
- xml *is* the meta data format of choice
- having meta data everywhere is useful for assisting in deploying and defining web services
- the overall process should be defined by an xml language
The main problem i see is that in a world of SOAP, developers will defined complicated mesaging patterns using the SOAP headers.... which is an example of modeling with implementation, why not use XML pipeline ( on services steriods )to semantically model the marshalling requirements etc.... then have a transformation into DCOM (hehe ) implementation code ?
cheers, jim fuller
|
Previous Message
Up
