RE: Definition for a Web Service

Thank you for your very clear and useful exposition.  I believe that I
am not the only person confused about this stuff, and I think it would
be nice if the WSD document output included an explanation along these
lines and perhaps even a comment about what an audit log might want to
include.  It seems to me that's a very important business requirement.

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
Sent: Tuesday, August 12, 2003 11:45 AM
To: Cutler, Roger (RogerCutler); Anne Thomas Manes
Cc: Www-Ws-Arch@W3. Org
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:36:25 UTC