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] another issue with WSDLDeployment in current TN


My interpretation of the requirement is to provide a mechanism to represent
a WSDL document that "represents both the technical fingerprint and the
access point" without 1) making a user physically break up the document into
multiple pieces, and 2) registering non-reusable resources.

This requirement doesn't indicate to me a determination that if you use
wsdlDeployment, then you don't use any tModels. And more to the point, the
spec doesn't indicate this determination, either. The spec simply refers to
wsdlDeployment as a method of indirection. If wsdlDeployment were intended
to be used as a replacement for registering specs as tModels, then the spec
should have said so.

Personally, I don't think that the wsdlDeployment feature addresses this
requirement very well. The basic UDDI model assumes that you will describe
your technical specifications using a tModel. If the assumption is that if
you use wsdlDeployment, then you don't use any tModels, then you break a
very common practice used to search for services (search for service types
that match your requirements, then search for implementations of those
service types). I would view this model as contradictory to the basic UDDI
model.

I would say that the WSDL TN does a much better job at addressing this
requirement.

The WSDL TN defines a mapping for a single WSDL document that represents
both the technical fingerprint and the access point into a business service
and multiple reusable UDDI entities. And just because the original author
never intended to make his portType reusable, I don't see a reason why it
can never be reusable.

Bottom line: although this requirement drove the creation of the
wsdlDeployment feature, I don't think it comes into play in this
conversation. We now have this feature in V3 called wsdlDeployment. Per the
spec, it provides a method of indirection. Period. Users read the spec and
interpret the language to mean that rather than specifying the endpoint in
UDDI, they have the option of pointing to a WSDL file instead. Based on that
interpretation, certain folks have said "Hey that's useful. I want it in V2,
too." And now we have a requirement to support this indirection in V2.

Anne



> -----Original Message-----
> From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> Sent: Friday, November 22, 2002 10:56 AM
> To: 'John Colgrave'; uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] another issue with WSDLDeployment in current TN
>
>
> Hi John,
>
> Here is the "Problem Outline" from the requirement document,
> authored by Karsten, that finally was solved by the
> "wsdlDeployment" useType in UDDI V3's accessPoint:
>
> "UDDI's modeling today is quite stringent in terms of delineating
> between modeling implementations (accessPoints of bindings) and
> modeling technical interfaces (overviewUrls of tModels).  While
> this strict bifurcation is logical from a conceptual point of
> view, it does not accommodate a common
> scenario presented in the Web Services landscape: a single
> document that performs both of these goals.  As such, modeling a
> "deployment document" which represents both the technical
> fingerprint and the access point is rather cumbersome in UDDI v1/v2.
> A concrete example of such a "deployment document" is a WSDL
> document which represents both the interface for a given service
> as well as the service endpoint.  Modeling such a coupled WSDL
> file is awkward in UDDI: it requires either (1) an unnatural
> decoupling of the WSDL file into separate parts or
> (2) registering the coupled WSDL file as a tModel that has no
> intention of being reused.  Both of these options are unnatural.
> Option #1 forces developers to modify existing WSDL files in an
> unintuitive way.  Option #2 ends up polluting UDDI with  tModels
> that are not compliant with UDDI's vision
> of the way tModels represent abstract interface information that
> is meant to be reused.
> This particular use case is but one example of how the rigidity
> of the UDDI data model prevents the kinds of real world use cases
> that UDDI needs to support.  Without providing the means to model
> such use cases, UDDI runs the risk of ostracizing a large set of
> its intended community - namely
> developers of Web Services."
>
> While it is not explicitely stated in the specification, it is
> still represents a valid requirement.
>
> Claus
>
> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> Sent: Freitag, 22. November 2002 16:19
> To: uddi-spec@lists.oasis-open.org
> Subject: Re: [uddi-spec] another issue with WSDLDeployment in current TN
>
>
> another issue with WSDLDeployment in current TNClaus,
>
> You will have to show me where in the published V3 specification there is
> any text that supports your view of what wsdlDeployment should be (have
> been) as I just can't see it.
>
> John
> ----- Original Message -----
> From: Von Riegen, Claus
> To: 'John Colgrave' ; uddi-spec@lists.oasis-open.org
> Sent: Friday, November 22, 2002 12:04 PM
> Subject: RE: [uddi-spec] another issue with WSDLDeployment in current TN
>
>
> John,
>
> At least the initial design goal Karsten describes in his earlier mail is
> correct. The wsdlDeployment stuff was invented in order to a) let service
> providers simply put the URL to the WSDL file in the bindingTemplate's
> accessPoint without any additional tModel modeling and b) let service
> consumers get all the Web service's metadata by retrieving the remote WSDL
> file.
> The question we now have on the table is: are providers of "ad hoc" Web
> services required to register their Web services conformant to the current
> version of the WSDL TN or will the WSDL TN also allow the alternative to
> model the bindingTemplate with nothing but the deployment WSDL's
> URL in the
> accessPoint?
>
> Claus
>
> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> Sent: Freitag, 22. November 2002 10:19
> To: uddi-spec@lists.oasis-open.org
> Subject: Re: [uddi-spec] another issue with WSDLDeployment in current TN
>
>
> Karsten,
>
> Are you talking about wsdlDeployment as a categorization value from the
> uddi.org:categorization:types scheme, or wsdlDeployment as a useType value
> on accessPoint?
>
> I can imagine that wsdlDeployment as a categorization might have been
> intended for the use you describe, but that is not at all clear from the
> published V3 spec.
>
> I think it is quite clear that wsdlDeployment as a useType value on
> accessPoint is meant only as a level of indirection for the endpoint, and
> that is the use of wsdlDeployment that we need to focus on.  Section B.1.2
> says
>
> 'Instead of directly providing the network address in the
> accessPoint, it is
> occasionally useful or
> necessary to provide this information through indirect means. One common
> scenario for such
> a behavior is when the accessPoint is embedded within a WSDL
> file. In such a
> scenario, the
> UDDI accessPoint contains the address of the WSDL file, and the
> client then
> must retrieve the
> WSDL file and extract the end point address from the WSDL file itself.
>
> In this case, decorating the UDDI accessPoint with a
> useType="wsdlDeployment" is
> appropriate.'
>
> I think this is quite clear that the only thing of relevance in the WSDL
> file is the end point address and it does not imply anything about whether
> there are any tModels for the reusable parts of the WSDL etc.
>
> I must admit that I sneaked in the categorization as well in the
> last update
> I sent but that was because the example in the spec. added it when the
> accessPoint was used.  If it is the categorization that is causing the
> confusion then we can remove that, but I think the V3 spec. needs to be
> clarified as they currently use it in the way that I did.
> ----- Original Message -----
> From: Karsten Januszewski
> To: uddi-spec@lists.oasis-open.org
> Sent: Wednesday, November 20, 2002 7:15 PM
> Subject: [uddi-spec] another issue with WSDLDeployment in current TN
>
>
> Another issue with the wsdlDeployment in the current TN is that it was
> introduced in v3 to address the case when the WSDL information was decided
> not meant for reuse, a one-off, service.  As such, the thinking was that
> there would be no tModel modeled and it would be a simple way to
> publish web
> services.  However, the tn for both v2 and v3 assume that all the tModel
> modeling occurs along with the wsdlDeployment decoration.  I fear that we
> are moving away from the initial design goal.
> Regards,
> Karsten
>
>
> Karsten Januszewski
> Program Manager, UDDI and Web Services
> Microsoft Corporation
> Phone: 425.707.5818
>
>
> ----------------------------------------------------------------
> 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