Re: [uddi-spec] WSDL TN: Issue 1 - mapping between wsdl:service anduddi:businessService

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

Claus,

Comments below in the usual style.

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 2:29 PM
Subject: RE: [uddi-spec] WSDL TN: Issue 1 - mapping between wsdl:service and
uddi:businessService


> John,
>
> Please find <CvR>my comments</CvR> below.
>
> Claus
>
> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> Sent: Mittwoch, 20. November 2002 11:54
> To: uddi-spec
> Subject: [uddi-spec] WSDL TN: Issue 1 - mapping between wsdl:service and
> uddi:businessService
>
>
> I do not agree there is a fundamental difference between the grouping
> offered by a uddi:businessService and a wsdl:service.  The UDDI
> specification describes a businessService as describing "a collection of
> related Web services offered by an organization described by a
> businessEntity." and section 1.6.2 describes a fairly loose logical
grouping
> of Web services.  I think it is perfectly valid to have bindingTemplates
> within a single businessService that correspond to ports that in turn
> correspond to different portTypes, with the assumption that there is some
> relationship among them.
>
> <CvR>Right you are! There are cases where the proposed mapping approach is
perfectly valid. But it is at least questionable to mandate the approach for
ALL wsdl:services in order to conform to the WSDL TN when they are
registered with UDDI.</CvR>

<JC>
I think we can consider it questioned. :-)

I think that people will "do the right thing" as far as defining services is
concerned because of the programming language issues etc. so I don't see the
need for a more complicated scheme allowing people to assign individual
ports to different businessServices.
</JC>

> Given that WS-I says very little regarding wsdl:services I am not inclined
> to attempt to invent any UDDI-specific Best Practice in this area.  I
quite
> agree that a WSDL Best Practice independent of UDDI would be a good thing.
>
> The other dimension to consider is the programming language/tool one.
This
> is a case where it is particularly relevant.  I can only speak with any
> confidence about Java and in Java there is a specification, JAX-RPC, that
> includes a mapping from WSDL to Java.  The mapping of a WSDL service is to
a
> service class which acts as a factory for the things corresponding to the
> ports etc. so the collection of the ports is exposed to the Java
programming
> model.  You cannot arbitrarily rearrange the aggregation of ports without
> changing the programming model for that service.
>
> <CvR>I am not a Java expert at all, but why should Web service consumers
rely on the Web service provider's Java programming model?</CvR>

<JC>
They wouldn't but the Java programming model can apply to the client side as
well as the server side.  If I have some deployment WSDL then this factory
class that is used to acquire a port etc. is used on the client side not the
service side.
</JC>

> Two final factors are that not keeping the 1-1 correspondence will make it
> harder to discover related (in the WSDL sense!) ports
>
> <CvR>If related ports (in terms of the containing service) are to be
discoverable in UDDI, the corresponding UDDI registrations should be tagged
with appropriate metadata, for example, by using the proposed approach. But
if related ports are to registered in different businessServices,
businessEntities or different UDDI registries, the approach can't be
used.</CvR>

<JC>
Yes, but that is a circular argument.  I do not see the need to allow ports
from the same wsdl:service to be mapped to bindingTemplates in different
uddi:businessServices.
</JC>

> and to generate deployment WSDL.
>
> <CvR>I can still generate a deployment WSDL by using the bindingTemplate's
accessPoint and the referenced binding tModel.</CvR>

<JC>
The deployment WSDL is for the wsdl:service as a whole, not an individual
port.
</JC>

> Given all of this, I propose leaving the mapping largely the way it is
now,
> mapping a wsdl:service to exactly one businessService.  I am in favour of
> adding the extra restriction that only a single wsdl:service can be mapped
> to a uddi:businessService.
>
> John
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>