OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [uddi-spec] WSDL TN: Issue 3 - UDDI V2 equivalent of wsdlDeployment


John,

Please find <CvR>my comments</CvR> below.

Claus

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Mittwoch, 20. November 2002 15:00
To: uddi-spec
Subject: [uddi-spec] WSDL TN: Issue 3 - UDDI V2 equivalent of
wsdlDeployment


I think it is reasonable to support an approach for UDDI V2 equivalent to
the UDDI V3 wsdlDeployment support.  I think it is a valid requirement to
defer to the WSDL file for the address/endpoint information and I do not
want to force people to have to wait for a UDDI V3 implementation before
being able to do so.

I am not sure it warrants changing the V2 specification however, but I do
not think that is necessary with the modified proposal below.

<CvR>V2 is done and your proposal doesn't seem to fix something that is currently broken. Thus, I agree to not change V2.</CvR>

It has been pointed out that an empty accessPoint value is not valid, and
Karsten has suggested using the URL as the value, which I think is a very
good idea, not least because it is very close to the V3 wsdlDeployment
approach.  So, the remaining issues are how to model this correctly without
changing the V2 specification.

<CvR>Well, an empty accessPoint ("") is theoretically valid since the UDDI V2 schema allows it, but since the specification states that the "service entry point" has to be obtained from the accessPoint element, there is practically no way to a) leave it empty or b) to let it point to something else
than the Web service endpoint.</CvR>

In V2, the accessPoint has a URLType attribute and one of the values of that
is "other" and when "other" is used, one of the tModelInstanceInfos must
imply the meaning of the accessPoint value.  My proposal is that we say that
in the V2 equivalent of wsdlDeployment, we use a URLType of "other" and we
put the URL of the deployment WSDL file in the value of the accessPoint.  To
disambiguate this case from any other use of "other", we have the
tModelInstanceInfo for the WSDL URL Reference tModel that is currently used.
The instanceParms can now be removed as the URL is the accessPoint value.

<CvR>While this proposal is consistent by itself, it does not fit to the general idea of the accessPoint and the URLType's value "other". Even if this value is used, the accessPoint must still be the service entry point, but its format (that can not be specified by any other URLType value) is
described in one of the tModelInstanceInfo elements. Also, in V3 we decided to remove the URLType attribute since it can be derived from the accessPoint's value already. I could think of tools that already do so in V2 - if the accessPoint's value starts with "http", then the service entry point is a
URL. This would not work for your proposal since the WSDL document is also referenced by a URL.</CvR>

This tModel also neatly provides an equivalent of the wsdlDeployment
categorisation of a bindingTemplate that V3 suggests also.

John


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC