RE: proposal for restricting a service to a single interface

I'm having a bit of a tough time following this discussion.  I get the
feeling that there are two competing requirements and pros/cons.  Let me
know if this roughly the state of the discussion.

1. Amy: A web service has multiple ports for different semantic tasks (such
as notification and administration).  These can be in the same service.
Pros: Software dealing with a somewhat complex MEP deals with only one
service.
Cons: Software can't determine what are the semantically equivalent ports.

2. Arthur: A Web service has multiple ports only for semantically equivalent
tasks.  These are in the same service.  Semantically separate tasks must be
in a different service.  The pros/cons are the inverse of #1.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Amelia A. Lewis
> Sent: Wednesday, April 30, 2003 11:24 AM
> To: Glen Daniels
> Cc: ryman@ca.ibm.com; www-ws-desc@w3.org
> Subject: Re: proposal for restricting a service to a single interface
>
>
>
> On Wed, 30 Apr 2003 13:51:49 -0400
> Glen Daniels <gdaniels@macromedia.com> wrote:
> > +1 and +1.
> >
> > I was writing up a longer response to Amy's earlier post, but then I
> > got really confused because she seemed to be arguing first for
> > multiple ports in a service, and then for a service to represent a
> > single "state machine" (instance)... after a few minutes I may have
> > figured it out. :)
>
> Multiple ports referencing bindings to multiple portTypes,
> representing
> a single state machine/instance.
>
> > So I think (please correct me if I'm wrong here) that Amy
> does want a
> > single "instance" behind a <service>, but she wants the ability to
>
> Yes.
>
> > specify different portTypes in order to support things like
> an "extra"
> > registerForCallback() API which is needed on an asynchronous
> > binding/endpoint and not required for a synchronous HTTP endpoint to
> > the
>
> No.  I don't know what this is, but it sounds ugly and
> complex.  I just
> want to be able to put my notification service in the same
> place as the
> administration service and have clients understand that the two are
> different accesses to the same service.  Why I would want to have a
> registration for this isn't at all clear to me.
>
> > same service.  In other words, the API differences which
> the multiple
> > ports in the <service> might evince are more about the
> > binding-specific semantics (QoS, asynchrony) than they are about
> > actual application semantics.  Is that at all accurate, Amy?
>
> I would argue that it's *useful* to require that a service be a single
> application (or instance, or state machine, choose your term).  It is
> *not* useful to force the different means of accessing that state
> machine to be somehow unified into one Great Big Ugly Bogus
> Superinterface complete with
> getThisSubInterfaceThatImActuallyInterestedInFromARequestRespo
> nseServic
> ePlease() method.  All superinterfaces are, by requirement,
> request/response enabled.  Why, why, *what value* does imposing this
> restriction provide to *anybody*?  The information about the portTypes
> is *already* there.  Forcing everything to be a single interface adds
> needless complexity for the folks whose use case is only
> *slightly* more
> complex than XML-enabled HTTP servers.
>
> > I'd strongly prefer to keep things simple, only allow one interface
> > per<service>, but then let the binding specifications (or
> SOAP Module
>
> It doesn't make things simple.  It makes things very complex for
> slightly more complex cases, without adding any information whatsoever
> in the simple case.
>
> On the other hand, requiring that a service be a single
> *instance* adds
> information not otherwise available, without requiring complex
> getThisInterfaceFromThatOneOverThere method calls.  Simple,
> declarative,
> a service is one thing, thank you, so make two if you need
> to, and keep
> one together if you've only got one.  The current proposal makes some
> single services into two or more (because the interfaces can't be
> unified nicely), without prohibiting the unification of multiple
> instances in a single service element.
>
> > Bottom line - don't force developers who want to do the simple stuff
> > to handle the potentially complex stuff.  Keep the simple
> stuff simple
> > and add complexity as needed in a modular fashion.
>
> Agreed.  So stop making silly complexity.  The current
> proposal doesn't
> simplify anything, doesn't add any information.  If it
> *specified* that
> all the ports in a single service element belong to the same instance,
> it would add *some* information, even while it makes life painful for
> those of us who see value in multiple forms of access for a single
> instance (that is, different portTypes because they are
> better suited to
> different bindings in potentia).
>
> Amy!
> --
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
>
>

Received on Wednesday, 30 April 2003 14:45:22 UTC