Re: [wsrp-interfaces] Add RegistrationData.version field for 2.0

[Rich Thompson <richt2@us.ibm.com>]

You raise some interesting questions.
Would you be proposing an array for those versions the producer supports?

Another idea might be to define a constant
using the schema within each spec version that declares the version that
WSDL is for. One would then determine this by parsing the WSDL in a standard
manner rather than trusting some Producer metadata.

Rich

Andre Kramer <andre.kramer@eu.citrix.com>

01/16/2004 06:14 AM

To	wsrp-interfaces@lists.oasis-open.org
cc
Subject	[wsrp-interfaces] Add RegistrationData.version field for 2.0

Problem: deal with change in wsrp version.

We already define a standard naming scheme for our binding and portType wsdl. The UDDI technote we (the publish / find / bind SC) are working on documents this scheme and does not add any version information to binding information (proposed "tModels" are wsrp version independent).

It is therefore up to WSRP consumers to verify that they import the correct "version" when they retrieve a service wsdl. I believe we have adequate mechanisms to do this currently. However, we do not address the following 3 use cases:

An consumer, written in some dynamic, un-typed interpreted language, at runtime imports a service wsdl, generating un-typed stubs/proxies or uses dynamic invocation API to access a WSRP producer. The consumer may not be a full Portal but some kind of management utility. Such a consumer would have no other way to verify the wsrp service version but to parse our rather complex naming convention for wsrp version. Would it be simpler to provide the spec version number directly as metadata?

A producer service is accessed remotely via SOAP proxies / intermediaries. However, something has gone wrong with the service configuration and the wrong WSRP version is exposed to consumers. Since WSRP producers may be hosted in a complex application server environment, such deployment errors could easily happen. A simple version number check would catch such configuration errors.

Anything can "claim" to be a WSRP service. However, only producers passing a conformance suite are allowed to set the RegistrationData.version field in their meta-data [one can dream :-)]

There may be other good reasons to add such versioning meta-data. The above are just to kick off discussion and point out that versioning is already addressed at the WSDL (but not at the protocol) level. Such a field may be useful but should we add it in 2.0 if it did not make it into 1.0 (not compelling enough or for other reasons)?

regards,
Andre