RE: proposal for restricting a service to a single interface

Hi Amy!

> > And I'd like to add that I'm yet to find any deployed 
> services which 
> > actually use multiple portTypes. If anyone knows of any 
> please do send 
> > a pointer. If there aren't any, then this is a simplification which 
> > many will appreciate and none will miss.
> 
> Red Herring.
> 
> There can't be, because at the moment there aren't useful 
> bindings to things like asynchronous protocols that would 
> make it useful.  When everything looks like HTTP, then 
> everything looks like HTTP, and it makes perfect sense to 
> impose silly restrictions.

No value judgment there, of course... :)

> For what it's worth, I *agree* that we should keep it simple. 
>  I reject the argument that this proposal does so.  The 
> proposal only requires that all ports have the same 
> interface, not that they be the same service instance.  If 
> they require that they be the same instance, *and* the same 
> interface, they complicate things for people exposing 
> multiple forms of access, without simplifying *anything* for 
> the people who use a single protocol.

OK, so here's my take.

- We should restrict <service>s to a single interface.

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

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

I think this has a lot of value - it makes crystal clear (and easy to implement) what it means to have multiple endpoints in a <service>.  It separates the various concerns into individual issues, and it frames the discussion of what our next steps need to be in order to a) decide how far up the complexity stack we want to go, and b) decide how to deal with each level.

My $0.02,

--Glen

Received on Wednesday, 30 April 2003 14:35:04 UTC