Re: proposal for restricting a service to a single interface

Dear Arthur,

Thanks for your response.  I'm sorry to continue debating this, but the
problem is that, from my perspective, the proposal to require all ports
within a service to be bindings of the same portType/interface has zero
value.  That is, it adds nothing, in a location where there is a
potential to provide useful information.

On Wed, 30 Apr 2003 11:09:32 -0400
"Arthur Ryman" <ryman@ca.ibm.com> wrote:
> 1. In WSDL 1.1, there is virtually no semantics associated with
> putting several <port>s in a <service>. See
> http://www.w3.org/TR/wsdl#_services

I agree with most of these points, except that you may overstate the
case slightly (rather than "do not communicate" I would say "are not
required to").

> 	The only claim is that IF two or more ports implement the same
> portType, then they are semantically equivalent and are alternate ways
> to access the service. 

An important point!  Can we make a distinction here?  Is a service

a) a collection of semantically-equivalent instances?
b) a single instance?

In the foregoing (mostly snipped) and the following, there is no
clarity, that I can see, in specifying how many instances may be
contained in a single service element.

It seems to me that this is a potentially very important piece of
information for choreography, for instance.

> 	2. In WSDL 1.2, I believe there is a desire to put more
> semantics into <service>. So we have two directions to go in. We can
> either strengthen the above statement so that ALL <port>s must
> implement the same portType and represent alternative ways to access
> the service, or we can add ways to state more semantics, e.g. that a
> set of the<port>s share state. IHMO either direction is preferrable to
> the status

My contention is that it the requirement that all ports must implement
the same portType/interface does *not* represent alternative ways to
access "the service".  That is, there is no requirement that this be a
single service, a single state machine.  There may be seventeen
different vendors represented in one service entry, none of them sharing
state.  Performing the "initialization" operation on one vendor's port,
followed by the "updateInformation" operation on another vendor's port,
does not have the same semantic as performing both operations in the
same sequence but using only one vendor.

In short, I think it far better to require that a service represent an
instance.  There is almost no way of verifying whether this is true, in
operation, but that in itself makes the requirement that the service
represent that bit of information all the more useful.

To return to a previous example, my previous illustration used a service
with an administration port and a notification port.  The requirement
that a service expose a single state machine would make the relationship
between these ports clear.  A requirement that all of a service's ports
be bindings of the same portType doesn't help here at all, and requires
resolution in a different fashion (such as the rather complex
interface-retrieval alternative that you had offered earlier).  In
contrast, I could create an aggregate WSDL that combined all seventeen
of my (identically-portTyped) vendors into a single service, which does
not tell me why I should choose one over another, or whether two or more
of these ports might or might not share state, or in fact anything that
I couldn't find out by following the path from port to portType.

> quo. The reason is that <service> is a modularization construct, and
> good modules should have cohesion, i.e. there should be a good reason
> for putting things in the same module. At present, the only reason is
> that somehow, the <port>s are "related". We should be able to be
> cleared than that. 

Agreed.  I just disagree that the approach of requiring a single
portType/interface adds any information.

> 	3. You raise the example of a service that has no
> request-response operations, which presents a problem for operations
> like getNotificationService. You probably will not like this
> suggestion, but why not define a parent request-response service that
> has getXXXService operations for all of its component services? You
> can have<service> elements for the parent service and each of the
> component services.

*shrug*  I can pull all sorts of ugly workarounds if a silly requirement
is set into place.  I'd just rather not have a silly requirement, when
it is possible to express something useful in the same place.  I think
it is deeply silly to require that sort of supermetaservice, and smacks
of the complexity that ended up killing CORBA.  I don't much like the
idea of passing "interfaces" around because it seems to me to lead
directly into the problem of passing alleged "pointers" over the
network, which I believe to have caused the failure of several
networking paradigms.

I agree that WSDL ought to say something *useful* about the service
element, defining it more stringently than WSDL 1.1.  I would prefer to
see it say that a service element *must* represent a single instance (a
single state machine).  I would infinitely prefer that to the proposal
that it represents a collection of semantically-equivalent instances,
because I don't believe that that statement adds any information that
cannot already be determined by following the port -> binding ->
portType resolution path.

A richer form of this would be to allow ports to specify their
relationship to other ports explicitly, but that may well be out of
scope

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

Received on Wednesday, 30 April 2003 12:08:39 UTC