RE: [uddi-spec] Issue with the WSDL TN

["John Colgrave" <colgrave@hursley.ibm.com>]

Daniel,

I think you have come to the right conclusion so I won't belabour the point
too much, but I will just point out a couple of issues.

What if one tool decided that wsdl:port should be at the beginning of the
string and another decided it should be at the end?

Assuming the strings in Claus's example are typical, there would be space
for three extra name-value pairs to be added to the instanceParms in V2.
However, if only one of the strings was one character longer then there
would only be space for two.  What is the third application that wants to
extend instanceParms to do in this case?

John Colgrave
IBM


-----Original Message-----
From: Daniel Feygin [mailto:feygin@unitspace.com] 
Sent: 29 May 2003 08:33
To: 'Von Riegen, Claus'; 'John Colgrave'; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Issue with the WSDL TN

I fail to see John's point that adding arbitrary name-value pairs to WSDL
tModelInstanceInfo instanceParms would hamper portability/interoperability.
If tools vendors know to expect such extra parameters, they will know to
ignore them and only look for the ones that matter to their tool.

However I don't see why these extra parameters couldn't go into a separate
tModelInstanceInfo corresponding to a different tModel.  This other
tModelInstanceInfo would be a part of the same bindingTemplate and therefore
would constitute a part of its technical fingerprint.  I don't perceive
Claus's direction as digressive, but I don't see a compelling reason to
adopt this proposal.

If no such compelling reason exists (I'm not aware of any at this time), I
would object having arbitrary parameters in WSDL tModelInstanceInfo
instanceParms on the grounds that this supports, and thereby fosters, poor
registration modeling decisions on the part of developers publishing to
UDDI.  Because these decisions would affect individuals other than the
publishers, we should strive to improve the affected users' experience with
UDDI by making publishers conform to 'good' practices.  Requiring separate
tModels to represent different concepts would enable better communication
between service provider and service consumer by imposing one such good
practice on the publisher.

Daniel


> -----Original Message-----
> From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com] 
> Sent: Wednesday, May 28, 2003 7:41 PM
> To: 'John Colgrave'; uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] Issue with the WSDL TN
> 
> 
> What I actually suggested was the ability to add additional 
> data in the form of name-value pairs, separated by 
> semicolons. For example, if one wants to express an 
> implementation detail about a (propietary) procedure that is 
> necessary to get a user account in the system that implements 
> the Web service, the instanceParms within a bindingTemplate 
> (that represents a wsdl:port) could look as follows:
> 
> <instanceParms>wsdl:port="the-port-name";example.com:user-acco
unt="http://www.example.com/webservices/useracco> unt"</instanceParms>
>  
> Tools then would look for the "wsdl:port" name within the 
> instanceParms and could still automatically retrieve the 
> corresponding name value.
> 
> Note that this approach would be necessary (at least in V2) 
> if one wants to avoid the publication of such (propietary) 
> tModels since bindingTemplates don't carry a categoryBag (in 
> V3 a keyedReference using the general_keywords category 
> system would work, although it would then not be part of the 
> "technical fingerprint", i.e. the set of tModelInstanceInfos).
> 
> I know that there is a trade-off between this flexible, but 
> more complex approach and the limited, but simpler approach 
> that is currently specified in the TN. I'd be happy to drop 
> the proposal if the TC tells me that my proposed direction is 
> too digressive.
> 
> Claus
> 
> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com] 
> Sent: Mittwoch, 28. Mai 2003 15:59
> To: uddi-spec@lists.oasis-open.org
> Subject: [uddi-spec] Issue with the WSDL TN
> 
> 
> Following yesterday's call, there is one technical issue, 
> apart from the one that led to CR-032, that Claus raised on 
> the WSDL TN that has not, in my opinion, been closed.
> 
> If anybody thinks that they have raised technical issues that 
> have not been addressed then speak now.
> 
> This issue is to do with the use of instanceParms in the 
> instanceDetails element of the tModelInstanceInfo that 
> relates to the binding tModel.
> 
> Claus has suggested that we allow arbitrary content in this 
> instanceParms element in addition to the content required by 
> the WSDL TN so that other specifications etc. that want to 
> build on the WSDL TN can add their own content.
> 
> My view is that this whole tModelInstanceInfo is specific to 
> the WSDL TN and if other information needs to be supplied for 
> a particular use of the WSDL TN then that can be achieved by 
> having another tModelInstanceInfo element for some other 
> tModel relevant to the application domain, or putting the 
> information in the WSDL itself using WSDL extensibility 
> elements and using the "WSDL Implementation Document" 
> approach in the WSDL TN to allow the WSDL to be retrieved and 
> the information read from there.
> 
> If we allow particular uses of the WSDL TN to alter the 
> content of the UDDI artifacts required by the WSDL TN then we 
> lose portability/interoperability.
> 
> It is also far from clear that overloading the single 
> instanceParms element will be sufficient given the limits on 
> the length of it of 255 in UDDI V2 and even 8192 in UDDI V3.
> 
> John Colgrave
> IBM
> 
> 
> 
> 
> You may leave a Technical Committee at any time by visiting 
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php

You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php