Both
possibilities certainly, but the problem, as I understood it was more at the
transport/SOAP call level than a WSDL issue (we already have
structured portType names) and I would not wish to re-invent a general
service/version discovery mechanism (WS-Inspection proposal). But doing
something simple just raises the question of why 1.0 (or 1.1???) did
not feature a simple version stamp.
regards,
Andre
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: 16 January 2004 15:55
To:
Subject: Re: [wsrp-interfaces]
Add RegistrationData.version field for 2.0
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
