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 <>
01/16/2004 06:14 AM
To
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
