RE: proposal for restricting a service to a single interface

On Wed, 23 Apr 2003, Amelia A. Lewis wrote:
> After discussion with colleagues at TIBCO, I have to question whether
> this proposal is a good idea.
>
> The following use case is illustrative of the problem:
>
> Imagine an interface that defines three request/response operations (for
> example, addCustomer, removeCustomer, updateCustomer).  A parallel
> interface defines a single notification operation (for example,
> customerChanged).
>
> It is logical to:
>
>      1) use different underlying protocols (perhaps HTTP for the customer
>         administration interface, perhaps IP multicast for the
> notifications)
>
>      2) still wish to have both interfaces be a part of the same service,
>         each with different endpoints.
>
> Quoting a collegue: "The critical issue is that the data (the state) is
> the same ... it is undeniably one black box."
>
> This proposal makes it impossible to use different transports to access
> the state of this single service.  In the current state of WSDL, it is
> still easy to do so: create each interface, create a binding for each,
> and create a port for each -- these ports would be inside one service.
>
> It would be possible to aggregate the two interfaces, but only if the
> bindings for the different transports can then *not implement* one of
> the subinterfaces.  Which is really horrid; it's aggregation for the
> sake of legalism, violating the spirit of interface
> inheritance/aggregation.
>
> Another possibility would be to create bindings for just the
> subinterfaces, and to set the superinterface on the service.  Each port
> then implements a "part" of the service.  Again, this seems to reject
> the spirit of the proposal, and possibly may violate its letter as well
> (depending upon the wording that ended up in the specification).

Yet another possibility is to modify your binding
specification to allow different protocols to be used for
different interfaces.  It would probably be most clean to
also push the location attribute into the binding element,
but one could in theory increase the abstraction of the
address element so that it somehow represented both the HTTP
address and the IP multicast address.

> The ability to aggregate ports representing different interfaces into a
> single service is mostly likely needed when the transports have
> significantly different characteristics (client/server versus pub/sub,
> for instance), so that each interface is logically implemented through a
> binding to a protocol that cleanly supports the requirements of the
> interface.
>
> It does not seem sensible to require that a logically-unified service be
> artificially divided into two (or more) services in order to fulfill the
> requirement that only a single interface per service be supported.  It
> is also artificial to "unify" interfaces that are logically distinct,
> even though they are part of the same *service*.  The interfaces stand
> alone, even if they access the *same* information.

I think I would agree with this, but I wonder if, with the
current spec, the same thing occurs but just at the
interface level rather than the service level.  That is,
perhaps there are times when a logically-unified interface
must be artificially divided into two or more interfaces to
fulfill the requirement that only a single protocol/address
per interface be supported.

Received on Thursday, 24 April 2003 12:32:08 UTC