[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [uddi-spec] WSDL: Comments on WSDL Technical Note
Hi John,
More comments below ...
Claus
-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Freitag, 15. November 2002 17:01
To: 'UDDI Spec TC'
Subject: Re: [uddi-spec] WSDL: Comments on WSDL Technical Note
Claus,
Comments below, <JC>like this</JC>.
John Colgrave
----- Original Message -----
From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
To: "'Anne Thomas Manes'" <anne@manes.net>; "'UDDI Spec TC'"
<uddi-spec@lists.oasis-open.org>
Sent: Friday, November 15, 2002 2:33 PM
Subject: RE: [uddi-spec] WSDL: Comments on WSDL Technical Note
> Anne,
>
> Thanks for your feedback.
> Actually, most of my issues are related to the redundant nature of the
requirements to capture WSDL details in UDDI.
> I'd simply want to make registrations of Web service types and Web
services as easy as possible for their provider. If parts of the
registration information is redundant, it is more likely that changes to the
registrations make the data either inconsistent or prevent the required
queries we all want to see supported.
>
> See my response inline.
>
> Claus
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Donnerstag, 14. November 2002 22:12
> To: Von Riegen, Claus; 'UDDI Spec TC'
> Subject: RE: [uddi-spec] WSDL: Comments on WSDL Technical Note
>
>
> Claus,
>
> Thank you for your detailed comments. See responses/comments inline...
>
> Anne
>
> > -----Original Message-----
> > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > Sent: Thursday, November 14, 2002 10:28 AM
> > To: 'UDDI Spec TC'
> > Subject: [uddi-spec] WSDL: Comments on WSDL Technical Note
> >
> >
> > As requested, here are my outstanding comments/issues/questions
> > w.r.t. the "Using WSDL in a UDDI Registry" Technical Note.
> > Since I have not received an updated version so far, the comments
> > are based on the paper version that was distributed this Monday
> > at the FTF.
> >
> > 1. General
> > First of all, I'd like to thank John and Karsten for their
> > tremendous amount of work they have done in order to set this up.
> > Also, I'd like to see the TC's formal review period for this
> > Technical Note to be started as soon as possible so that it can
> > be publicly posted in order to get early feedback from the
> > general public. However, I still have several issues that I'd
> > like to be seen addressed or clarified.
> >
> > 2. Goals and Requirements
> > I support the goal to allow deployment WSDL to be generated from
> > UDDI (which is not new in general), but the document is missing
> > reasoning for several of the detailed requirements in the later
> > sections (see below).
>
> The latest draft provides much more specific requirements and rationale.
>
> > 3. Mapping wsdl:service to uddi:businessService
> > There is no real need to map wsdl:service elements to
> > uddi:businessService elements. A service in WSDL is a logical
> > grouping of ports and does not contain any information that is
> > relevant to Web service interoperability. The information that is
> > really required in order to invoke a Web service is
> > obtained from the port and the artifacts it references (binding,
> > portType, operation, message). Since the requirements for
> > grouping uddi:bindingTemplate elements in uddi:businessService
> > elements (for example, a purchase order service that can be
> > invoked by using different protocols) can differ from
> > the ones for grouping wsdl:port elements in wsdl:service elements
> > (for example, a purchase order Web service that is offered to
> > different public and private communities), I'd like to see the
> > requirement for the one-to-one mapping relaxed.
> > This would mean to remove the sections for mapping wsdl:service
> > to uddi:businessService (section 2.6.3 in V2 and section 2.7.3 in
> > V3) completely.
>
> One of the requirements is to enable automatic registration of services in
> UDDI from a WSDL file. If we do not provide mapping of wsdl:service to
> uddi:businessService, then I don't see how we can make this registration
> fully automatic. Ports belong to a service, and bindingTemplates must be
> grouped within a businessService. I think the issue is that a logical
> business service in UDDI doesn't always correspond to the physical
> collection of ports described in a WSDL service.
>
> <CvR>Exactly. That is why a one-to-one mapping of wsdl:service to
uddi:businessService doesn't help but rather eventually contradicts to the
UDDI architecture. If a Web service developer wants to publish a Web service
as a uddi:bindingTemplate within a new uddi:businessService, then the
wsdl:service name might help to name it, although the WSDL description
doesn't help to categorize the businessService in more business-related
terms. But to rely on the information that is registered with a
uddi:businessService in order to find a corresponding wsdl:service doesn't
work if wsdl:port elements from multiple wsdl:service elements are published
within one uddi:businessService.</CvR>
<JC>
I am not sure we are talking about the same thing here, or maybe there are
two issues. I thought your concern was that ports from a single
wsdl:service may be better modelled as bindingTemplates in multiple
businessServices, perhaps even in different UDDI registries.
<CvR>Correct. This is my original concern and requires the 1:M part of the N:M mapping.</CvR>
Is your
concern the case that multiple wsdl:services are mapped to a single
uddi:businessService?
<CvR>Unless we specify best practices for WSDL itself, we can not prevent that a SOAP port to a given portType and an ebXML Messaging port to the very same portType are described in different services or even in different WSDL documents, but registered in the same uddi:businessService - this
requires the N:1 part of the N:M mapping</CvR>
I had not intended the TN to support that scenario
but I must admit there is nothing obvious that prohibits it. I would be
happy to say that a uddi:businessService corresponds to zero or one
wsdl:services. I think it would be very confusing to try and map ports from
several different wsdl:services to bindingTemplates of a single
uddi:businessService.
<CvR>This depends on the WSDL modeling approach itself (see comment above).</CvR>
</JC>
> I recommend that we
> maintain the one-to-one mapping, specify a recommended practice for the
> collection of ports within a service (currently in a footnote), and
> recommend a practice of using projection to associate the WSDL-generated
> businessServices with a more logical UDDI businessService.
>
> <CvR>I support the idea to develop a recommendation how to model wsdl:port
elements in wsdl:service elements, but still don't see a need to map
wsdl:service to uddi:businessService. Even reconstructing wsdl:service FROM
uddi:businessService is not a goal for the technical note, IMO. It doesn't
help interoperability. How can a service projection help here? It does not
contain any information apart from the projected service.</CvR>
<JC>
Other people do have the requirement to generate the wsdl:service.
<CvR>Can you give more details about the reasoning for this requirement?</CvR>
Do you accept the need to produce a bindingTemplate for a port? If so, then
we have to have a uddi:businessService to contain the bindingTemplate. Are
you proposing that we choose an existing one or create one without any
reference to the wsdl:service that contains the wsdl:port?
<CvR>Yes, this is exactly what the Technical Note should allow. If one wants to register a wsdl:port as a uddi:bindingTemplate, they should either use an existing uddi:businessService (that logically fits to the wsdl:port's portType) or create a new uddi:businessService. I don't see a need to
reference the wsdl:service, yet.</CvR>
</JC>
> There are still some issues with the current mappings, though, as I've
> outlined in the comments in the latest draft.
>
> > 4. Identifying wsdl:portType and wsdl:binding elements in
> > uddi:tModel registrations
> > Rather than splitting the targetnamespace and the local name of
> > portType and binding elements when registering them as tModels,
> > the tModel name could also be built by concatenating them
> > (sections 2.6.1, 2.6.2, 2.7.1, 2.7.2). For example, the tModel
> > that represents the UDDI V3 Inquiry API portType
> > tModel would be named
> > "urn:uddi-org:api_v3_portType:UDDI_Inquiry_PortType". As a
> > consequence, the WSDL Namespace category system would be
> > dispensable. Also, by using the URN logic, one could easily
> > search (even in V2) for
> > * all tModels published by UDDI.org ("urn:uddi.org")
> > * all tModels that represent a known UDDI API portType or
> > binding (e.g. "urn:uddi.org:api_v3_portType" or
> > "urn:uddi.org:api_v3_binding")
> > Searching for tModels based on the portType and binding name,
> > independently of their namespace, seems to me to be of minor
> > importance. However, this would be available in V3 by using the
> > extended wildcard mechanisms (e.g. "%UDDI_Inquiry_PortType").
>
> Interesting proposal. It doesn't provide a way for us to capture the
> namespace and local name for a service or port, though.
>
> <CvR>IMO, we don't need the namespace and local name for wsdl:service and
wsdl:port elements when they are published as UDDI.artifacts.</CvR>
<JC>
They are needed to support the generation scenario and also the
"wsdlDeployment" scenario, with both UDDI V2 and V3.
<CvR>Given the bindingTemplate's accessPoint and the binding tModel it refers to, one could easily generate a deployment WSDL. The WSDL's port is at least logically equivalent to the one that was once registered as the bindingTemplate.</CvR>
.
</JC>
> Note: in the latest
> draft these tModels have been made more generic. They are general purpose
> XML namespace and XML local name tModels, rather than WSDL-specific
tModels.
>
> > 5. Registration of wsdl:port elements
> > Sections 2.6.4 and 2.7.4 are missing reasoning why
> > * to put the wsdl:port local name in the bindingTemplate's
> > instanceParms element (2.6.4) or in one of its keyedReference
> > elements (2.7.4)
>
> There is a requirement that a user should be able to find the WSDL
> definition of the port. There is no other way to capture the local name.
>
> <CvR>What do I need the wsdl:port for when the uddi:bindingTemplate
already contains the Web service's network address? Regardless of the
wsdl:port's binding extension mechanism, it MUST not specify more than one
address and MUST NOT contain any information other than the address (as
defined by WSDL 1.1, section 2.6).</CvR>
<JC>
The bindingTemplate may not contain the web service's network address if
that address is incompatible with the schema type and length restriction of
uddi:accessPoint.
</JC>
<CvR>If the uddi:accessPoint can not capture the Web service's network address, then UDDI is broken and we should consider to create an errata.</CvR>
> > * to reference the portType tModel while the binding tModel
> > is already referenced and thus allows the needed query - also, V3
> > (2.7.4) already allows a one-step query by using a find_service
> > with an embedded find_tModel
>
> There is a requirement that a user should be able to search for a service
> that implements a portType without specifying a specific binding. e.g., I
> want to find all services that implement the foo portType. Bindings are
> usually specific to particular implementations (e.g., soapAction, header
> messages, etc.), so users cannot search e.g., for all services that
support
> SOAP implementations of the foo portType by specifying a particular
binding.
> They must be able to search by portType.
>
> <CvR>I understand the requirement, but I do not understand the solution,
which is pretty redundant. The portType tModel is already captured in the
referenced binding tModel. V3 was explicitely enhanced in order to allow
more complex queries like these. Since the binding tModels reference the
portType tModels by using the WSDL portType Reference tModel, the V3 example
in section 3.5.3 (find implementations of portType)
>
> <find_binding xmlns="urn:uddi-org:api_v3">
> <tModelBag>
> <tModelKey>uddi:e8cf1163-8234-4b35-865f-94a7322e40c3</tModelKey>
> </tModelBag>
> </find_binding>
>
> can easily be changed to
>
> <find_binding xmlns="urn:uddi-org:api_v3">
> <find_tModel xmlns="urn:uddi-org:api_v3">
> <categoryBag>
> <keyedReference
> tModelKey="uddi:uddi.org:wsdl:portTypeReference"
> keyValue="uddi:e8cf1163-8234-4b35-865f-94a7322e40c3" />
> </categoryBag>
> </find_tModel>
> </find_binding>
>
> and makes the portType tModel reference in the bindingTemplate
dispensable.
> V2 does not allow this direct query but the requirement can still be met
by performing two subsequent queries - one for all binding tModels that
reference the portType tModel
>
> <find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
> <categoryBag>
> <keyedReference
> tModelKey="uuid:d3e8ef29-877e-3486-b9e2-46af338d6c85"
> keyName="portType reference"
> keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>
> </categoryBag>
> </find_tModel>
>
> and another to find all bindingTemplates that implement one of the found
bindings
>
> <find_binding generic="2.0" xmlns="urn:uddi-org:api_v2">
> <tModelBag>
> ... all tModelKeys that were found in the previous query ...
> </tModelBag>
> </find_binding>
>
> I'd rather see this as a missing feature in V2 and do not want to make Web
service registrations more and more complex and redundant.</CvR>
<JC>
This will not work for V2 as the V2 find_binding will only return
bindingTemplates that contain all of the tModelKeys. You would have to do a
separate find_binding for each tModelKey and then merge the results
yourself.
<CvR>I should have taken more care in developing the examples.
<find_binding generic="2.0" xmlns="urn:uddi-org:api_v2">
<findQualifiers>
<findQualifier>orAllKeys</findQualifier>
</findQualifiers>
<tModelBag>
... all tModelKeys that were found in the previous query ...
</tModelBag>
</find_binding>
works as desired by using the "orAllKeys" find qualifier and seems not to be too inefficient to me.</CvR>
These approaches will be very inefficient for a large number of bindings
that use the same protocol/transport. Even in V3 using the nested
find_tModel if there are a large number of binding tModels that are
categorised as, for example, SOAP/HTTP then this approach would produce very
complex queries.
Having a single tModel for SOAP etc. makes these queries very simple.
</JC>
> > * to reference the WSDL file that describes the wsdl:port
> > (2.6.4) since this is quite redundant to the mandatory
> > accessPoint (if the hostingRedirector is not used) - also, it
> > would not be compatible to Version 1 of the WSDL Best Practice
>
> There is a requirement that a user should be able to find the WSDL
> definition of the port -- perhaps to find other extensibility elements
that
> have not been captured in the bindingTemplate.
>
> <CvR>Can you give an example of a port extensibility element that has not
been captured in the bindingTemplate?</CvR>
>
> I don't see how this is incompatible with the V1 BP. The bindingTemplate
> still specifies the accessPoint and still provides a tModelInstanceInfo
for
> the binding tModel.
>
> <CvR>Appendix 5 WSDL URL Reference tModel states that "A service provider
may not want to specify the address of a service port in the
uddi:accessPoint element and instead require the user to retrieve a WSDL
file to obtain the service address." This is either inconsistent with the
UDDI specification (the accessPoint is required, unless the
hostingRedirector is used) or redundant (if the accessPoint is
specified).</CvR>
<JC>
UDDI V3 added specific support for this scenario with wsdlDeployment.
<CvR>To my best knowledge, this was introduced to register Web services without the need to register their abstract interface as tModels. The use of WSDL deployment documents seems to me to be quite unnecessary in this Technical Note, since their only usage (as far as Web serivce interoperability is
concerned) would be to retrieve the Web serivce's network address. But I can live with it as it may be a convenience for tool import and export.</CvR>
In
the mapping to V2, we say that an empty accessPoint indicates that the WSDL
file should be consulted.
<CvR>Again. An empty accessPoint, that is, accessPoint="", contradicts to the notion that the accessPoint must be provided and that it provides the service network address. At least, you would have to create a new URLType so that tools can distinguish between usual accessPoints and those that are
provided in a different manner. IMHO, this would be a new feature for V2.</CvR>
</JC>
> > * to categorize the bindingTemplate as being of type "port"
> > (no other UDDI artifacts can be of this type and the "WSDLness"
> > can be discovered by the referenced tModel
>
> I agree. I see no reason why the type information is required.
>
> > 6. Registration of WSDL binding information in
> > uddi:bindingTemplate elements
> > The registration of WSDL binding information, whether it is SOAP,
> > HTTP or another binding, in uddi:bindingTemplate elements
> > (sections 2.6.4.1 - 3 and 2.7.4.1 - 3) seems to be at too low a
> > level. The binding tModel should already by typed strongly enough
> > in order to provide all necessary binding
> > information that is used in ALL Web service implementations that
> > are represented by corresponding bindingTemplate elements. Why
> > should every implementation be mandated to provide this information?
>
> This is similar to your second point in question 5. There is a requirement
> that a user should be able to search for a service that implements a
> portType supporting a specific protocols without specifying a specific
> binding. e.g., I want to find all services that implement the foo portType
> using SOAP over HTTP. (Bindings are usually specific to particular
> implementations: e.g., soapAction, header messages, etc.)
>
> <CvR>If the binding tModels are categorized accordingly, which is the
"natural" UDDI philosophy, the very same query can be performed by
>
> <find_binding xmlns="urn:uddi-org:api_v3">
> <tModelBag>
> <tModelKey>uddi:uddi.org:protocol:soap</tModelKey>
> </tModelBag>
> <find_tModel xmlns="urn:uddi-org:api_v3">
> <categoryBag>
> <keyedReference
> tModelKey="uddi:uddi.org:wsdl:portTypeReference"
> keyValue="uddi:e8cf1163-8234-4b35-865f-94a7322e40c3" />
> </categoryBag>
> </find_tModel>
> </find_binding>
>
> and makes the "protocol" reference in ALL bindingTemplates dispensable.
However, the tModels that represent protocols would have to be categorized
as being category systems rather than protocols - we could also consider to
extend the UDDI Types category system or define a separate one that contains
all protocol types we need.</CvR>
<JC>
Your example assumes the bindingTemplate has the SOAP protocol tModel which
is what I thought you were arguing against.
<CvR>Oops. Here is the correct example, which
- queries for tModels that are bindings to the given portType tModel and are based on SOAP (by using the SOAP value within the UDDI Types category system)
- queries for bindingTemplates that implement at least one of the found bindings.
<find_binding xmlns="urn:uddi-org:api_v3">
<findQualifiers>
<findQualifier>orAllKeys</findQualifier>
</findQualifiers>
<find_tModel xmlns="urn:uddi-org:api_v3">
<categoryBag>
<keyedReference
tModelKey="uddi:uddi.org:wsdl:portTypeReference"
keyValue="uddi:e8cf1163-8234-4b35-865f-94a7322e40c3" />
<keyedReference
tModelKey="uddi:uddi.org:categorization:types"
keyValue="soapSpec" />
</categoryBag>
</find_tModel>
</find_binding>
</CvR>
See my comments above.
</JC>
> >
> > 7. Other addresses
> > How can an address be described in WSDL but not be mapped to the
> > uddi:accessPoint (sections 2.6.4.6 and 2.7.4.6)?
>
> The information might be in the WSDL, but the published may elect to have
> the consumer retrieve the address from the WSDL at runtime (i.e.,
> wsdlDeployment). Perhaps the wording should be clarified to indicate that
> it's the publisher's choice (rather than the information is unavailable).
>
> <CvR>Again, the uddi:accessPoint is required and the WSDL Best Practice V1
doesn't work if it is left blank (""). All in all, I would disallow the use
of URLs of type "wsdlDeployment" in the WSDL Technical Note since all
necessary information is given by the referenced binding tModel. Using
deployment WSDLs makes sense to me only if the service provider doesn't want
to provide reusable artifacts (tModels).</CvR>
<JC>
The address is not given by the binding tModel. Using wsdlDeployment is
entirely valid in the WSDL TN, and I think it would look very strange if we
did not use it!
</JC>
<CvR>I'm now o.k. when using the wsdlDeployment V3 feature in this Technical Note. But I'm not convinced to retrofit the feature to V2.</CvR>
> >
> > Best regards,
> > Claus
> >
> > ----------------------------------------------------------------
> > 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