Re: proposal for restricting a service to a single interface

Hey, Glen,

On Wed, 30 Apr 2003 14:34:14 -0400
Glen Daniels <gdaniels@macromedia.com> wrote:
> OK, so here's my take.
> 
> - We should restrict <service>s to a single interface.

No.  It adds no value, and makes things complex that need not be.

> - We should make clear that a <service> represents a single
>   entity (i.e. ultimate destination node in SOAP parlance).

Yes.

>   Therefore if you happen to be talking to a stateful entity,
>   and use some non-binding-specific way of maintaining state
>   (either the state is shared for all users or you use something
>   like SOAP headers to maintain sessions), you will get the
>   exact same state no matter which endpoint/binding you use.
>   (Blah blah blah, translate to spec-ese)
> 
> - We should give some guidance as to how to deal with
>   extension-specific (i.e. bindings or modules) ways of
>   achieving patterns like asynchrony, pub/sub.  I think this
>   should be a separate conversation.  As you say, it isn't
>   solved now, so we need to solve it.  I'd prefer to do so
>   as a modular entity instead of mixed up with <service>
>   definitions.

What?  I don't understand at all, I'm afraid.

Is this going back to the whole application-level subscription stuff? 
Most pub/sub protocols don't expose subscription at the application
level.  It is enough to describe the publication destination; the client
already knows how to handle subscription, and subscription doesn't use
XML messages (as a rule).

It looks like someone *really* wants to make this stuff hard.  Why?

> - We should give some guidance as to how to represent the
>   "connectedness" between multiple <services>, either via
>   something we might ourselves provide, like <serviceGroup>
>   or somesuch, or by using extensions.

Or declaratively, by placing ports that are part of a single service
inside a single service.

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

Received on Wednesday, 30 April 2003 14:51:17 UTC