Re: proposal for restricting a service to a single interface

Hello,

When saying that the output of getNotificationService message is an endpoint
:
> <output message="getNotificationServiceOutput">
>                        <endpoint name="notificationServiceUri"
part="return" >interface="tns:customerNotificationInterface"/>
>                </output>
>        </operation>

it might be necessary to use an XPath selector in case the referenced
message part is a complex type. If the part is a simple type, as in your
example,  a selector is indeed can be omitted, while the endpoint's part
attribute can itself also be optional when there's only one part  in a
message.
Also, may be it's not necessary/can be optional to specify the binding ? :

> <output>
>                        <endpoint name="notificationServiceUri"
>binding="tns:customerNotificationMulticastbinding"/>
>                </output>

The client runtime can probably select itself an appropriate binding which
is bound to a given interface/portType, and even select between several ones
(with the help of some configuration info). While it may be more difficult
to implement, at the same time it may bring some extra flexibility.

Thanks
Sergey Beryozkin
Zandar Technologies, Dublin, Ireland

----- Original Message -----
From: Arthur Ryman
To: Amelia A. Lewis
Cc: WS-Desc ((Public)) ; www-ws-desc-request@w3.org
Sent: Friday, April 25, 2003 11:04 PM
Subject: 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

Received on Monday, 28 April 2003 04:52:15 UTC