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 5 - identification of port


Claus,

See below as usual.

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: Thursday, November 21, 2002 8:36 AM
Subject: RE: [uddi-spec] WSDL TN: Issue 5 - identification of port


> 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:42
> To: uddi-spec
> Subject: [uddi-spec] WSDL TN: Issue 5 - identification of port
>
>
>
> I think I have already covered at least part of this in one of the earlier
> notes.  One reason for requiring the namespace name and local name in the
> UDDI metadata is so that equivalent deployment WSDL can be generated by
two
> independent tools.
>
> <CvR>O.k. That means we should better agree on the meaning of
"equivalence" in this context. What I tried to say in my earlier response to
the "WSDL TN: Issue 2 - generation of wsdl:service" was that equivalence of
ports in two separate deployment WSDL documents is given when they are
generated from the same bindingTemplate - by using the referenced binding
tModel and the contained accessPoint. Naming of the port element and its
cointaining service element doesn't count for equivalence. If the port name
in the first generated deployment WSDL is built by using the
bindingTemplate's bindingKey and the port name in the second generated
deployment WSDL is built by concatenating the businessEntity:name, the
businessService:name and the name of the binding tModel, it is still the
same Web service if the port's network address is the same in the two
deployment WSDL documents.</CvR>
<JC>
I believe I have already pointed out that the proposal for equivalence in
the W3C WSDL group is simple name equivalence so two ports would be
equivalent if they had the same namespace name and the same local name.
</JC>
> The local name is also required in the wsdlDeployment case where a service
> has more than one port and only the base URL of the deployment WSDL file
is
> in UDDI, that is, we are not using XPointer.
>
> <CvR>We should either require referenced deployment WSDL documents to
contain only one port or use the XPointer mechanism as we used in the WSDL
BP V1 to distinguish between different bindings. Or we should revisit our
wsdlDeployment scenario and discuss what it means if the WSDL contains more
than one port.</CvR>
>

<JC>
I would not agree with placing any artificial limitations on the structure
of WSDL files that could be used with UDDI.

We could use XPointer but the local name would still have to be there.  The
advantage of XPointer would be that it could be used by a generic browsing
tool or something like that but for UDDI-specific tooling I think it would
be much easier to extract the information from the UDDI structures as
currently defined.

I don't understand your comment about the wsdlDeployment scenario.  Can you
elaborate?
</JC>

> I am not sure that you cannot define more than one targetNamespace in a
> single WSDL file so the namespace may also be required to uniquely
identify
> the correct service/port in the wsdlDeployment case also.
>
> We could choose not to categorise the bindingTemplate with the port
> namespace in the V3 model, but at the cost of requiring the containing
> service to be retrieved to find it.
>
> 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