RE: proposal for restricting a service to a single interface

Amy,

I'd model the service as an aggregation using the R085 endpoint reference 
proposal. I'd have the main interface handle admin, and I'd delegate the 
notification to another interface so I can use different protocols for 
them.

In your example suppose we have the following interfaces:

customerNotificationInterface - contains customerChange
customerAdminInterface - contains addCustomer, removeCustomer, 
updateCustomer, AND getNotificationService

Here's how getNotificationService is defined. Note that the interface has 
an operation that returns the endpoint reference for the notification 
interface.

<message name="getNotificationServiceInput"/>

<message name="getNotificationServiceOutput">
        <part name="return" type=xsd:anyURI"/>
</message>

<interface name="customerAdminInterface">

        <documentation>The notification service shares the state of the 
admin service.</service>
        <operation name="getNotificationService">
                <input message="getNotificationServiceInput"/>
                <output message="getNotificationServiceOutput">
                        <endpoint name="notificationServiceUri" 
part="return" interface="tns:customerNotificationInterface"/>
                </output>
        </operation>

        ... other operations
</interface>

Suppose you have the bindings:

customerNotificationMulticastBinding
customerAdminHttpBinding

Here's how customerAdminHttpBinding is defined. Note that the notification 
binding uses multicast.

<binding name="customerAdminHttpBinding" 
interface="tns:customerAdminInterface">

        <operation name="getNotificationService">
                <input>....</input>
                <output>
                        <endpoint name="notificationServiceUri" 
binding="tns:customerNotificationMulticastbinding"/>
                </output>
        </operation>

        ... other operations

</binding>

The service is defined as:

<service name="customerAdminService" 
interface="tns:customerAdminInterface">
        <port name="customerAdminHttpPort" 
binding="tns:customerAdminHttpBinding>
                <http:address 
location="http://www.tibco.com/customer/admin"/>
        </port>
</service>

I think this is clearer than WSDL 1.1 since there is no implication that 
the ports that appear within a <service> element share any state. In this 
solution, the notification service is directly related to the admin 
service via the getNotificationService operation.  In fact, you don't 
really even need a <service> element for the notification service since 
you can get its location dynamically.


Arthur Ryman,
WebSphere Studio Development Lead,
Web Services, XML and Data Tools

phone: 905-413-3077, TL 969-3077
assistant: 905-413-2323, TL 969-2323
fax: 905-413-4920, TL 969-4920
intranet: http://w3.torolab.ibm.com/~ryman/




"Amelia A. Lewis" <alewis@tibco.com>
Sent by: www-ws-desc-request@w3.org
04/23/2003 04:40 PM

 
        To:     WS-Desc ((Public)) <www-ws-desc@w3.org>
        cc: 
        Subject:        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