RE: proposal for restricting a service to a single interface

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

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.

The addition of the interface attribute on the service element does not
add much to WSDL (since the interface controlling a given port may be
established by following the pointer to binding and then to
interface(s)).

Amy!
--
Amelia A Lewis
Architect
TIBCO/Extensibility

Received on Wednesday, 23 April 2003 16:40:39 UTC