Re: proposal for restricting a service to a single interface

Dear Arthur,

Thanks for responding directly.

On Fri, 25 Apr 2003 18:04:31 -0400
"Arthur Ryman" <ryman@ca.ibm.com> wrote:
> 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. 

*shrug*  Okay.  But that doesn't reflect the reality that I see there,
which is that this is a single service, with two forms of access.  In
one form, it's stodgily traditional client-server: ask a question (or
give a command), get an answer (change the server's state).  In another
form, the server notifies anyone who cares when its internal state
changes.  Is the fact that all the information is about a single service
important enough to drive a requirement that it be possible to model it
as such?

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

Represented as xsd:anyURI, rather than a possibly more complex type?

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

[snip]

> 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

*sigh*  But the point *is* that they *do* share state.  It is possible
to state unequivaocally that every time addCustomer, removeCustomer, and
updateCustomer are completed successfully, a customerChange is delivered
on the notification interface.  It's the *same* *state*.  So ... why
does it have to be modelled as a separate service?  It seems to me that
this is intruding binding information into the 

> this solution, the notification service is directly related to the
> admin service via the getNotificationService operation.  In fact, you
> don't

Yes, but it isn't a notification service, it's just the notification
interface to the customer maintenance service.

> really even need a <service> element for the notification service
> since you can get its location dynamically. 

Say what?

Isn't there a service description somewhere that defines this endpoint
explicitly?  I hope so; moving too far in the direction of the problems
of CORBA/DCOM strikes me as a "solution" already known to have
corresponding drawbacks.

It's certainly possible to model a single service that happens to be
exposed through multiple endpoints implementing multiple interfaces as
multiple services instead.  I won't deny that it's possible.  I merely
suggest that it isn't desirable.  This is easier:

<service name="OneBigService">
    <port binding="httpAdminBinding" />
    <port binding="mcastNotificationBinding" />
</service>

I'm leaving stuff out.  But this does, I think, show that it is simpler
to model a single service as a single service.

Question: suppose we have multiple interfaces (requiring multiple
bindings to different protocols in necessarily different endpoints) but
none of them provide request/response semantics?  I can't go from a
service that doesn't have r/r to some other service ('cause I can't ask
it where to get that other interface), using the above model.  Is this
case too marginal to care about?

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 28 April 2003 10:27:20 UTC