Re: Comments on the pretty pictures

Oh, *sigh*.  I really want out of this conversation.  There seems to be a determination to make WSDL 1.2 complex in places where WSDL 1.1 was nice and simple; I'm to the point of just waiting for the screams when it hits LC.

On Sat, 14 Jun 2003 07:38:01 +0600
"Sanjiva Weerawarana" <sanjiva@watson.ibm.com> wrote:
> "Amelia A. Lewis" <alewis@tibco.com> writes:
> > The nice pretty pictures in part 1, section 1.1 (figure 1-1 and 1-2) are
> [snip]
> 
> I'm glad that we're now talking about the real question- whether
> we all like the pretty pictures.

Did you forget your <sarcasm /> tags?

> Let's not start with a picture that has a circle saying "service."

Say what?  Resource Description Language, now?

> 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. 

Identified by a URI.  Okay.

>     - -A set of interactions with this resource may be grouped
>       together to form an interface. 

Identified how?

>     - -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.

Fine.

>     - -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. 

Righto.

>     - -Each binding may be published at one or more URLs. 

Good.

So, if they happen to be different interfaces, even if they belong to the same conceptual thing, we'll divide 'em into chunks, then create an attribute with fuzzy semantics to hook 'em all back together.

> Look at the service resource picture and imagine it without the 
> "service" circle and that's a picture for this model.

So the pictures don't actually define what was agreed upon?

> 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. 

Sure.  Well-known defintion of resource in the URI spec: "Anything identified by a uniform [anything identified by a uniform [anything identified by a uniform [anything identified by a uniform [anything idenitified by a uniform [anything identified by a uniform
STACK OVERFLOW: PROGRAM HALTED

> Once we agree on the model (and I hope you do agree with the above),

No.

Specifically, the artificial restriction of [whatever word someone cares to use to identify the thing that is in the wsdl:service element in WSDL 1.1] to a single interface remains, for me, inadequately motivated.  In particular, it is claimed to be "simpler" or to embody the best modeling of the power law, but no argument is supplied, and to date the complications resulting from the changes imply that "simplification" is *not* an appropriate description.

> 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>. 

Oh, good.  Something we can agree on.

> However, it certainly did not have a nice clean model that gave
> proper semantics to what <service> meant. 

Is this the problem being addressed, then?  "What should the semantics of the wsdl:service element be?"

> 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. 

Interesting.  I can't at all argue that this doesn't happen, of course.  Do you think that this, too, is likely to follow the power law?  That accounting for this circumstance is part of the 80/20 case?

> 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)

Better than the current nightmare.

>     - 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)

The accepted version.

>     - 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)

Same as yours without the requirement that a service implement a single interface?

> 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. 

How important is this case?

> We discussed and agreed (I think) that in the 80-20 case there will

So 80/20 gets applied to the two remaining contenders, with the first ruled out without applying that rule?  Or have I missed something?

> 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. 

Sorry.  I didn't see the single-interface requirement in #3.  It's supposed to be in there?

> 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.

Which is an innovative definition of service.  *shrug*

> 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

Which are the same sort of "simplifications" as the rest of this.  That is, not.

> 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. 

Looking through that presentation, I am left thinking that it intends to achieve this:

<service>
  <binding>
    <operation />+
    <port />+
  </binding>
</service>

In other words, it's a means of reducing reusability, insofar as I can tell (at least insofar as "inlining" and "defaulting" go).

I also completely fail to understand how the binding is going to drop the @interface (or @implements) attribute.  Or how the single-interface proposal retains any utility at all once it does.  At that point, I just stuff whatever I want into <binding> (part of this interface, part of that interface), create a single <interface> element to hold all the operations, and attach <service> to that.  No binding may actually implement all the operations, but that seems to be the point of the proposal.  It looks as though the next step is to discard <interface>, and let <operation> be a top-level element, with binding-specific information for each operation inside the <port> (or <endPoint>).

> 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 
> evidence.

Simple: I don't understand half of this.  As this has progressed, since I am partly responsible for tutoring, I've had to sit down and try to draw up lesson plans to describe the new nonsense.  The old nonsense may seem simpler merely because it is more familiar, but clearly the new nonsense doesn't simplify things.

Redefining terms is also a really grand way to encourage incomprehension.  That's what's been done with the service element.  It is no longer descriptive of a service; it is a concretization/binding of an interface.  Finding in the sketches for lesson plans something on the order of "a service may contain multiple services" and "a service represents one interface of a service" is ... very useful for encouraging maximum incomprehension.

> > 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
> it.

I can repeat myself: "Commonest-of-all use of "resource" is in the terms 'uniform resource locator' or 'uniform resource identifier'."  You seem to have problems with the clause following the semicolon, but I really do fail to see how a URL does not implicitly define an endpoint.  Note the type of the attribute soap:address/@locator.

> > 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. 

Ah.  We're probably using different world-wide webs, then.

Oops, forgot the <sarcasm /> tag my own self.  Oh, well.

> > 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.

<boggle />

> > 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.

Hard to do with the redefinition of wsdl:service to be a subset of the concept 'web service'.

> > 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.

I saw it.  Several times.  What it eliminates, in my opinion, is modularity and reuse of the binding element.

> > 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

What *is* this 80/20 case?  Could you describe it?

> model, and full support for additional services that work with the

The model really *bites*.  It requires redefinition of the terms "service" and of "resource" in order to work at all, and by requiring that redefinition, promotes lack of comprehension among those who are not aware of the redefinition.

> same resource to come along independently. 

*This* is more likely to occur than having different interfaces associated with a single service?

> 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
> manner.

I won't challenge that it's still possible to do everything that was possible in 1.1.  I would argue that the terms used in doing so are radically less intuitive than the terms used in 1.1, and I would argue that some of the useful things possible in 1.1 ("these endpoints belong to the same service", even though they bind different interfaces) is now more difficult.

> > Tfu.
> 
> Sorry, don't know that one?

Common expression of utter disgust in my second language.  Described in dictionaries as "a dry, spitting sound."

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 16 June 2003 10:43:49 UTC