W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2003

Re: Comments on the pretty pictures

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Sat, 14 Jun 2003 07:38:01 +0600
Message-ID: <067901c33215$9988fea0$72545ecb@lankabook2>
To: "WS Description List" <www-ws-desc@w3.org>

"Amelia A. Lewis" <alewis@tibco.com> writes:
> In brief,
> The nice pretty pictures in part 1, section 1.1 (figure 1-1 and 1-2) are

I'm glad that we're now talking about the real question- whether
we all like the pretty pictures.

Let's not start with a picture that has a circle saying "service."
The model that Arthur proposed is the following:
    - Consider a resource identified by some URI. The resource could 
      be a concrete thing (e.g., entity bean) or a virtual concept
      used to group together sets of interactions. 
    - -A set of interactions with this resource may be grouped
      together to form an interface. 
    - -There may be more than one such interface for interacting
      with that resource. Each interface could provide one related
      set of business/management/whatever functionality.
    - -Each interface may be accessed (used) over one or more bindings,
      where a binding is roughly an implementation of the interface
      or more precisely a way to use or get to an implementation. 
    - -Each binding may be published at one or more URLs. 
Look at the service resource picture and imagine it without the 
"service" circle and that's a picture for this model.

The thing I like about this model is that it builds on fairly well-
known concepts: resource, interface, operation, etc.. I am not
sure you will agree, but I believe that the term "resource" does 
have a well-defined role in Web architecture. 

Once we agree on the model (and I hope you do agree with the above),
the question becomes what XML syntax should be used to represent
it in WSDL. As a WSDL 1.1 author, I claim that the intent of 
WSDL 1.1 was to allow <service> to represent the entire thing 
because it allowed any set of ports to be within a <service>. 
However, it certainly did not have a nice clean model that gave
proper semantics to what <service> meant. 

A disadvantage of using a static XML syntax to represent the whole
thing is that (IMHO) often it will be the case that additional 
interfaces to manipulate a resource will be available without the 
knowledge of all the interface providers. That is, I may be providing
interface foo to work with a resource and you may be providing
interface bar to work with the same resource and I may not know 
about you. For example, a service could be able to manage a set
of other services without the services themselves knowing 
statically who their management service is. 

We considered three different syntaxes at the meeting:
    - <serviceGroup> wrapper to hold everything and <service>
      to represent everything from a single interface (this is
      DavidO's proposal)
    - let <service> describe everything from a single interface
      and have it explicitly point to other services that work
      on the same resource (my <association> proposal)
    - have <service> point to a resource URI and thus two 
      <service>s which point to the same resource have that 
      commonality (I believe Jonathan came up with this)

Both the first two options suffer from the static nature I described
earlier: at the time of describing a service one has to know all 
the other services that work with the same resource. 

We discussed and agreed (I think) that in the 80-20 case there will
likely be only one interface present. The latter two approaches support
that better as it doesn't require any out wrapper to contain all the
stuff for all interfaces. Given that the middle option has the staticness
issue, we settled on the last option. 

That's how we ended up with saying everything related to a single 
interface is  <service> and that other stuff is found by having two
<service>s that point to the same resource URI.

In the process of doing this we agreed to add @interface to <service>
to indicate the interface it implements. Yes, that is redundant with
@interface from binding. If you look at the minutes from Rennes you
will also see that we discussed a set of binding simplifications that
eliminate this redundancy and makes WSDL more flexibile. We haven't
done that yet (Kevin Liu and I are spsed to be making a proposal that
combines his ideas and mine soon), but that's clearly the intent. 

Some specific comments below.

> The nice pretty pictures in part 1, section 1.1 (figure 1-1 and 1-2) are
> certainly *pretty*.  The definitions embedded in them are completely
> innovative, however, and innovative in a way I would argue encourages
> maximum incomprehension.

So you accuse me of asserting that the single-interface-per-service
this is simpler, but you appear to have the right to make arbitrary
assertions like "encourages maximum incomprehension." Please give 

> The use of "resource" as a larger thing than "service" is a reversal of
> common use.  Commonest-of-all use of "resource" is in the terms "uniform

I don't believe there is common use with "resource" and "service"
today. Can you point me to it please? WSDL 1.1 certainly doesn't do

> resource locator" or "uniform resource identifier"; these terms
> implicitly define a resource as being an endpoint and an interface; the

Um, no. URIs and URLs don't talk about an endpoint or an interface. 

> fact that multiple resources may point at the same abstract [something],
> or share its state, indicates that the general use of the term
> "resource" is to indicate a subset of an interface on a service.

I disagree.

> Possibly something could be recovered by using a different term. 
> Redefining "resource" to be big-big-big in direct contradiction to its
> common usage is likely to produce massive email and teleconference
> discussions, due to confusion over the actual meaning of the term. 
> Among other things.

We're not defining it to be anything more than what it is. In fact,
we're not defining it at all - we're simply using it in the same 
warm, fuzzy, not-precisely-defined way that WebArch uses it IMO.

> The definition of "service" in these graphics is that a service is a
> subset of a (web) service.  Again, innovative language.  Possibly,
> though, it is not best to define a service (element) to be a subset of a
> (web) service.  Service is a subset of a service is less than ... ideal.
>  At best.
> These linguistic issues show up a fundamental conceptual problem.  If we
> have an element called "service", then it is sensible, reasonable, and
> intuitive that the element represent a web service; this interpretation
> is commonly applied to WSDL 1.1 documents, even though the service
> element is underspecified in that specification.
> Use of the term "service" to mean something other-than, smaller-than,
> a-subset-of, related-to a web service is necessarily unreasonable,
> non-intuitive, and ... nonsense, in a word.  Making life harder for
> folks who have to train the folks who will be using WSDL ("Well, a
> service *element* isn't an actual *web* service.  It's ... umm, well, it
> may be a *part* of a web service, and we'll call that web service a
> "resource", so now we can find all the parts of a web service by
> relating them with a "target resource" attribute, but now we're not
> using the term "resource" in the same way that it's used in a URI or
> URL, so please ... make your mind a _tabula rasa_, if you would, and we
> will redefine all the words that we plan on using.") is probably not the
> ideal means of encouraging early adoption of the specification.

One can certainly define a "Web service" to be the same thing that
<wsdl:service> represents. At least for WSDL that would be true. I
certainly hope that WS-Arch adopts that too and the fact that they are
engaging in discussions here shows that they we have some chance of
using a common model.

> Now, in WSDL 1.1, portType <- binding <- service/port
> In WSDL 1.2:
>   interface <- binding <- service/endpoint
>   interface <- service

As I said earlier, this redundancy is simply a point-in-time 
issue. We already have a draft proposal on how we can eliminate
this redundancy and at the same time simplify WSDL significantly.
See the Rennes minutes for the presentation I made.

> No gain, just the introduction of redundancy, with no possibility of
> removing it (are we going to suggest that the relationship between
> interface and binding can be broken?  between binding and endpoint?).

Lots of gain: better support for the 80-20 case, better overall
model, and full support for additional services that work with the
same resource to come along independently. 

Quite to the contrary, I see *no* loss as I can describe everything
that was possible with WSDL 1.1 and do it in a much more well-defined

> Tfu.

Sorry, don't know that one?

Received on Friday, 13 June 2003 21:37:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:30 UTC