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?
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 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?
<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.
[<wsdl11:service> | <wsdl20:service> ] <extensibility>* </wsa:metadata>
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.
posted by Chris at
Sunday, February 06, 2005
|
0 comments
0 Comments:
Post a Comment
<< Home