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

The discussion as I recall it was that
we have a parsable indication of version in the various WSDL names. The
downside of this requiring special parsing was considered not a significant
problem for v1.0 (there is only 1 version). By comparison, we didn't think
we had the time to debate the tradeoffs of the various possibilities for
indicating version in the v1 timeframe. With a use case before us, perhaps
a good way to proceed would be to collect input on ways (with pros and
cons) to indicate version and then have a value to the use case vs complexity
and cons type of discussion.

Rich 

Andre Kramer <>

01/16/2004 11:12 AM

To



cc

Subject

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

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