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 1 - mapping between wsdl:service a nduddi:businessService


Please find <CvR>my comments</CvR> below.


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

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>

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>

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>

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>

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.


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