Re: [uddi-spec] WSDL TN: Claus's Issues

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

Hi Karsten,

Glad you could finally join us. :-)

As you may have seen, I also agree with Sam, but I disagree with you as I am
not in favour of a V2 mapping that does not support the "wsdlDeployment"
scenario.

If we are going to do migration then we can obviously migrate a V2-style
wsdlDeployment accessPoint to a V3-style.

If you are thinking of concurrent access by both V2 clients and V3 clients,
then you have to consider the opposite case too.  The sentence immediately
prior to the one you quote says

If an entity is saved with the v3 namespace and a v2 inquiry is made, the
URLType will be returned as "other".

So an instance of the v3 wsdlDeployment accessPoint will look to a v2 client
very much like my proposal for a v2 version of wsdlDeployment in that it
will have a URLType of "other" and the value will be the URL of the WSDL
file.  I would say that my proposal is required to prevent the TN
contradicting the v3 spec.

We could keep the extra tModel in the v3 case, as mentioned in the TN, for
compatibility and so that a v2 client looking at a v3 wsdlDeployment
accessPoint can still disambiguate between this use of "other" and any other
(no pun intended).

We would also have to document that a user of the v3 mapping will have to
look for this tModel even in the case where the useType is "endPoint" but
that is definitely preferable, as far as I am concerned, to not supporting
the v2 view of the v3 wsdlDeployment case.

John
----- Original Message -----
From: "Karsten Januszewski" <karstenj@windows.microsoft.com>
To: "Wai-Kwong Sam LEE" <Sam.Lee@oracle.com>; "uddi-spec"
<uddi-spec@lists.oasis-open.org>
Sent: Wednesday, November 20, 2002 5:59 PM
Subject: RE: [uddi-spec] WSDL TN: Claus's Issues


> Sorry for my absence in this discussion...been having problems with the
> uddi-spec list.  But now I'm back.
>
> I completely agree with Sam below for both his reasons.  I am not in
> favor of making the wsdlDeployment scenario available in v2.  It is
> problematic on a number of levels.  I would add to Sam's point on
> migration that we assumed that any accessPoint in v2 would actually
> represent an endPoint, not an indirection.  I quote:
>
> 10.2.10       ...
>
> In the case when a v3 inquiry is made on an entity published with the v2
> namespace, the v3 useType attribute will be returned as "endPoint".
>
> Thus, the technical note is in contradiction with the established
> semantic meaning of accessPoint in v2.  A TN can't override the meaning
> of the spec itself.
>
> Regards,
> Karsten
>
>
> -----Original Message-----
> From: Wai-Kwong Sam LEE [mailto:Sam.Lee@oracle.com]
> Sent: Wednesday, November 20, 2002 8:04 AM
> To: uddi-spec
> Subject: Re: [uddi-spec] WSDL TN: Claus's Issues
>
> Sorry that I am a bit late. I'd like to re-iterate my concern:
> 7) Reduce the complexity in UDDIv2-UDDIv3 migration (that is created by
> the differences in WSDL-UDDIv2 mapping and  WSDL-UDDIv3 mapping).
>
> It'd be great if the WSDL-UDDIv2 mapping is strict subset of the
> WSDL-UDDIv3 mapping, in other words, the WSDL-UDDIv3 mapping is backward
>
> compatible with WSDL-UDDIv2 mapping.
>
> Details:
> The WSDL artifacts that have different mappings for UDDIv2 case and
> UDDIv3 cases are:
> *    The URL of the WSDL doc that contains the wsdl:port
>       (instanceParms for v2 vs accessPoint with useType="wsdlDeployemnt"
>
> for v3)
> *    The wsdl:port local name
>       (instanceParms for v2 vs bindingTemplate/categoryBag for v3)
>
> The concerns are:
> 1. primarily on the migration from UDDIv2 to UDDIv3, from both the
> perspective of tooling and the perspective of registry data migration;
> 2. to a lesser extent, ease of understanding / avoiding confusion for
> the community (so that to encourage the adoption).
>
> This issue is orthogonal to the rest of the issues, but it can provide a
>
> guidance/consideration in decididing the solution for the other issues.
>
>
> - sam
>
> Anne Thomas Manes wrote:
> > Let me add one more issue to the list:
> >
> > 6) The requirement to capture the WSDL Entity Type for service and
> port.
> >
> > I'm with John on this. From my perspective, the critical goal of this
> TN is
> > to support the needs of WSDL tools:
> > - to automatically register service types and implementations based on
> WSDL
> > - to obtain WSDL for a particular service type or implementation
> >
> > Anne
> >
> >
> >>-----Original Message-----
> >>From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> >>Sent: Tuesday, November 19, 2002 8:46 AM
> >>To: 'John Colgrave'; uddi-spec
> >>Subject: RE: [uddi-spec] WSDL TN: Claus's Issues
> >>
> >>
> >>John,
> >>
> >>Excellent idea.
> >>I agree to the lists, except that I'm missing an issue in the
> >>list of issues that are still open:
> >>5) The requirement to identify the wsdl:port from a given
> >>uddi:bindingTemplate (i.e. why to register the port's target
> >>namespace and local name in UDDI).
> >>
> >>Thanks,
> >> Claus
> >>
> >>-----Original Message-----
> >>From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> >>Sent: Dienstag, 19. November 2002 14:24
> >>To: uddi-spec
> >>Subject: [uddi-spec] WSDL TN: Claus's Issues
> >>
> >>
> >>Claus,
> >>
> >>I would like to reset this discussion as the chain of notes is
> becoming
> >>unwieldy.  I would like to spell out the issues that I think are
> >>closed and
> >>then list the issues that are still open.  I will then start a
> separate
> >>discussion of each of the open items.
> >>
> >>The issues that I think are closed are:
> >>1) The use of wsdlDeployment in the V3 mapping/model.
> >>
> >>That list is shorter than I was expecting! :-)
> >>
> >>The issues that I think are still open are:
> >>1) The cardinality of the mapping between wsdl:service and
> >>uddi:businessService.
> >>2) The requirement to generate the wsdl:service.
> >>3) The use of something like wsdlDeployment in the V2 mapping/model.
> >>4) The tagging of the bindingTemplate rather than the binding tModel
> with
> >>details of the protocol and/or transport.
> >>
> >>Do you agree with these lists?
> >>
> >>Before going on to respond to each of these open issues
> >>separately, I would
> >>like to give a little more of my general perspective.  A lot of the
> >>discussion has been around the requirements for web service
> >>interoperability, no doubt influenced by WS-I.  While I think
> >>that WS-I is a
> >>very valid and valuable perspective, it is by no means the only one.
> I
> >>would go further and say that, for WSDL, it is probably not the most
> >>important one at the moment.  A different perspective that is at least
> as
> >>important is that of programming languages and application development
> >>tools.  Most of the implementations of the current BP are in that
> context
> >>and I would say most of the usage of WSDL in general.
> >>
> >>John Colgrave
> >>
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>