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 12:45:01 UTC