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

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

Claus,

See below.

John
----- Original Message -----
From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
To: "'John Colgrave'" <colgrave@hursley.ibm.com>; "uddi-spec"
<uddi-spec@lists.oasis-open.org>
Sent: Wednesday, November 20, 2002 4:11 PM
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>

<JC>
It depends on how flexible you are willing to be about the meaning of
"obtained".  I think the proposal is somewhere between having the value
directly in the accessPoint and the notion of a hostingRedirector Service,
and much closer to the direct end of the spectrum.

The description of the URLType value "other" includes "When this value is
used, one or more of the tModel signatures found in the tModelInstanceInfo
collection must imply that a particular format or transport type is
required." so another way to look at it is that the WSDL URL is a particular
format that is uniquely identified by the presence of the new tModel.

Given that this will not collide with any other use of "other" I can't see a
problem with this in practice.
</JC>

> 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>

<JC>
I would think that a tool that looked at the value before the URLType was
poorly written.  I agree that there is a lot of overlap between URLType and
the URL scheme in a lot of cases, but there is no difference in the content
between the fax and the phone cases so you have to look at URLType, which is
mandatory.

However, I can easily come up with a different address format that is not a
URL but that contains the URL, for example
WSDL(http://example.com/service.wsdl).
</JC>

> 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>