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: [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.

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.

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.

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


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

Powered by eList eXpress LLC