Re: Definition for a Web Service

Thanks Sanjiva.

----- Original Message -----
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>; "Anne
Thomas Manes" <anne@manes.net>
Cc: "Www-Ws-Arch@W3. Org" <www-ws-arch@w3.org>
Sent: Tuesday, August 12, 2003 12:44 PM
Subject: Re: Definition for a Web Service


>
> "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com> writes:
> >
> > I'm not sure I understand what you say below -- the distinction between
> > ports and endpoints is a bit fuzzy to me -- but let me explain why I
>
> WSDL 1.2 has renamed WSDL 1.1's <port> construct to <endpoint>. So
> there aren't ports *and* endpoints.
>
> > think it is really important that a WS be identifiable by a URI and that
> > it be specified clearly how it should be identified.
>
> I don't disagree .. but see below :).
>
> > I'm going to be
> > detailed so that you can see if I'm confusing some concepts or
> > mislabelling anything.  I think I'm probably going to be agreeing with
> > Frank's earlier posting, but if so I'm going to say it differently.
> >
> > As I understand it, a Qname is a short string that identifies a Web
> > service uniquely within the context of a WSDL file, but which depends on
> > that context for the identification.  That is, a Qname taken outside the
> > context of a WSDL file may be ambiguous.  So far OK with me -- no reason
> > to carry around redundant baggage if it's not really needed.  So far no
> > driver to have a URI.
>
> No, a QName is not a short string. A QName is a tuple of two things:
>     {namespaceURI, localPart}
> where namespaceURI *is* a real, honest-to-goodness URI and localpart
> is a "name without a colon" .. a non-colonized name or an NCName.
>
> A QName is unique as far as the definition requires it to. In WSDL,
> a QName of a <service> element (formed by taking the value of the
> targetNamespace attribute from the containing <definitions> element
> and the name attribute from the <service> element) is required to
> be unique. That is, there must not be another <service> with the same
> QName. Same for the other "top-level" beasts of WSDL: interfaces and
> bindings. WSDL 1.2 operations also have this requirement, but let's
> focus on the current discussion without making it more confusing.
>
> > In order to invoke a WS you obviously need a URI, but that is specific
> > to the binding.  The HTTP and SMTP bindings of the X Web service may
> > have entirely different URI's.  Again, no driver as yet to have a URI
> > for the Web service itself.
>
> No, to invoke a Web service you need a *URL*, not a URI. That is,
> at the end of the day you need some darn place to POST a SOAP message
> to or email a SOAP message to (for SOAP/HTTP and SOAP/SMTP, respectively).
>
> In WSDL 1.2, that address is binding specific and identified within
> the <endpoint> construct within a <service>. The same was true for
> WSDL 1.1, except it was within the <port> construct within <service>.
>
> Those *addresses* have *nothing what so ever* to do with *identifying*
> the service.
>
> > But let's look at this in terms of audit trails.  Suppose a business
> > transaction has gotten totally screwed up and some poor schnook is
> > trying to untangle what happened in order to find out who didn't get
> > paid.  Agent A and Agent B both got price quotes, ostensibly for the
> > same thing.  Agent A got it from the HTTP binding of the X Web service,
> > Agent B got it from the SMTP binding of the X Web service.  The URI's in
> > the audit trail are completely different.  Did they get the same price
> > quote?  The answer should be "Yes", because the Web service is supposed
> > to give the same result, independent of binding.  So the audit trail
> > needs to come up with "X", not just the URI's that were invoked.
>
> Right- the audit trail needs to come up with the QName of the <service>
> element which contained the two endpoints:
>
>     <definitions targetNamespace="tns1">
>         ..
>         <service name="s1">
>             <endpoint name="http" ..>
>                 <soap:address>http://...</soap:address>
>             </endpoint>
>             <endpoint name="smtp" ..>
>                 <soap:address>mailto:...</soap:address>
>             </endpoint>
>         </service>
>     </definitions>
>
> So, the audit trail better deal with the QName {"tns1","s1"} in this case.
>
> > OK, now I see a real strong reason to have a URI for the Web service
> > itself -- and a SINGLE URI.  You don't want Agent A putting X into the
> > audit trail and Agent B putting X', a different name for the same
> > service.
>
> I agree, but that name doesn't have to be a URI .. a QName has the
> same capability :-).
>
> > So it doesn't bother me if the Web service is referred to inside the
> > WSDL document by a Qname, but I think somebody needs to be real clear
> > about how the single URI identifying the Web service is constructed.
>
> Again, the QName of the <service> element is precisely the identity
> you are looking for IMO.
>
> Now, for a variety of reasons (including the fact that QNames are a
> PITA to write down), it is indeed useful to have a URI instead of a
> QName to identify things. WSDL 1.0 and later followed the lead of
> XML Schema in using QNames to identify things and clearly its correct
> and it works. However, QNames don't give the same warm, fuzzy feeling
> to people that URIs appear to give.
>
> WS-Desc WG is considering a general proposal (I think as a solution to
> R120; I forget the #) to define a standard mechanism to map any of
> the WSDL QNames to URIs. While the proposal is sound (IMO), I'm not
> sure whether the WS-Desc group would end up putting it in .. but a
> another possibility is that WS-Desc special case <service> and define
> one way to map a <service> QName to a URI. The most simple would be
> to require the definitions/@targetNamespace attribute to not have a
> fragment ID and then say the URI is formed by concatenating NCName
> service/@name as the fragment ID:
>     URI of service = concat(definitions/@targetNamespace, '#',
>                             service/@name)
>
> This is just a possible approach .. and there are many thousand
> other ways possible.
>
> What I'm opposed to, however, is introducing yet another top level
> attribute for the user to dream up a URI to identify the service
> when they've already identified it by a QName.
>
> > Is that reasonable?
>
> I hope my explanation was helpful to better understand URIs and QNames.
>
> And, if you said yes to that, I recommend you grab a few beers and
> read the WSDL 1.2 drafts and try to understand why one needs two QNames
> to identify an operation from inside a binding ;-).
>
> Sanjiva.
>

Received on Tuesday, 12 August 2003 15:10:02 UTC