Chris's Rants

Sunday, February 06, 2005

Detailed EPR metadata proposal

Steve blogs about his Detailed EPR metadata proposal from IBM, IONA, Oracle, SAP, and Sun.

I believe in general, the proposal is a good one. However, I do have one serious reservation.

Why does the proposal permit the content of the wsa:Metadata element to be a choice of WSDL1.1 or WSDL2.0 service element?
[<wsdl11:service> | <wsdl20:service> ] <extensibility>* </wsa:metadata>
The use of choice here will (IMO) only serve to present the Web services community with unnecessary versioning and interoperability headaches down the road. At the very least, it will foster islands of interoperability where some subset of software is capable of consuming one flavor of EPR, another subset the other flavor and yet another subset capable of consuming either flavor.

Keep in mind the tenet that any optionality in a specification is the breeding ground of interoperability issues.

As I see it, the motivation for permitting a choice of either a WSDL1.1 or a WSDL2.0 service element is to allow Web services tooling and runtime software that has been implemented to a specific version of WSDL to easily produce and/or consume the metadata straight from the WSDL description itself. IMO, this motivation is both misguided and unnecessary.

Consider that software that consumes WS-Addressing endpoints carrying this proposed wsa:Metadata element has yet to be implemented (beyond any prototyping associated with this proposal). Thus, it will, of necessity, require a bit of engineering on the part of Web services runtime and tooling providers to incorporate support for EPRs that carry the proposed wsa:Metadata element.

Consider also that the essential information carried in both the WSDL1.1 and WSDL2.0 service elements is roughly equivalent. It is certainly the case that a WSDL2.0 service element is a superset of the information carried in a WSDL1.1 service element, although the WSDL1.1 service element's child port elements are not constrained to a single interface/portType as is the case with a WSDL2.0 service element's child endpoint elements. It is also the case that a WSDL1.1 description contains all the essential ingredients to populate a WSDL2.0 service element.

IMHO, it would be trivial, therefore, to transform, by whatever means, a WSDL2.0 service element to a WSDL1.1 service element and vice-versa. Thus, were the proposal to provide exclusively for a WSDL2.0 service element child of the wsa:Metadata element, we would improve the potential for interoperability between the componentry that issues the EPR and that which consumes it (regardless of which version of WSDL that software was designed to use) and eliminate a built-in versioning headache, at a cost of a trivial amount of code to transform the WSDL2.0 service element to a WSDL1.1 service element for software that is not based on support for WSDL2.0 descriptions.


  • I think any spec being developed today has to take into account the existing infrastructure of which SOAP 1.1 and WSDL 1.1 are foremost. It would be nice to target just SOAP 1.2 or WSDL 2.0 but who has that luxury? Does this make interop harder? Well yes. Can anyone get traction around a spec that does not target those versions? Not yet. I think those writing to both today are the ones who are helping to pave that path to the future beyond the current SOAP/WSDL stacks.

    Ultimately the real issue here is that we just don't have a critical mass of SOAP 1.2 implementations and WSDL 2.0 isn't done yet. Until WSDL is done and we get wide support for both of the updated SOAP/WSDL versions this is the world we have to live in.

    Sucks, but not as bad as the first story here. It's very fitting that he thinks its funny.

    By Blogger Marc g, at February 09, 2005 10:24 PM  

Post a Comment

<< Home