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
getThisSubInterfaceThatImActuallyInterestedInFromARequestResponseServic
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:23:40 UTC