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: Claus's Issues


Sam,

I quite agree with you.  We have already added migration as a goal in the
document (but you have not seen that) but I think we need to go further and
decide what to do about supporting concurrent access via both UDDI V2 and V3
APIs.  There is an obvious tension between using the new facilities in V3
and supporting backward compatibility with V2.  Some things we don't have
any choice about, but where we do have a choice we need to think carefully
about whether we describe an approach that is compatible with V2 or we
optimise the use of V3.  If there is significant value in using a V3 feature
that is not compatible with V2 then I think we should describe how to
migrate a V2/common entity to the V3-only form, and also how to create a
V3-only mapping.  I think there is only one possible candidate for that,
described below.

My new proposal has already addressed the wsdlDeployment issue (but I am
going to say more in response to Karsten's note) so that leaves two other
issues to resolve:
1) The categoryBag on a bindingTemplate.
2) The use of "wsdlInterface" as a useType attribute on a tModel
overviewURL.

Issue 1 is by far the most significant and is the only possible candidate
for special treatment I mentioned above.  The V3 spec. does not describe
what a V2 client would see for a bindingTemplate with a categoryBag but the
only thing that would make sense would be for the V2 client to see the
bindingTemplate without the categoryBag.  We could therefore duplicate the
port local name in V3 so that it appeared as both a tModelInstanceInfo and a
category and the bindingTemplate could appear to a V2 client like a regular
bindingTemplate produced according to the V2 mapping in the TN, but it could
also appear as a V3 bindingTemplate with a categoryBag that can be used to
search on.

So, I think we can provide backward-compatibility at the cost of duplicating
the portName.  It is fairly easy to see how we can migrate the
bindingTemplate to the full-function V3 version with a categoryBag as we
have access to the necessary information.

The V3 spec. does not describe what a V2 client would see for an overviewURL
that used the new useType attribute on an overviewURL but I would assume
that the attribute was ignored so I think that would be OK.  Again, we can
easily migrate the V2 version to the V3 version in a way that will look the
same to a V2 client of a V2/V3 registry.

John
----- Original Message -----
From: "Wai-Kwong Sam LEE" <Sam.Lee@oracle.com>
To: "uddi-spec" <uddi-spec@lists.oasis-open.org>
Sent: Wednesday, November 20, 2002 4:03 PM
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>
>



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


Powered by eList eXpress LLC