Re: proposal for restricting a service to a single interface

I agree that it's useful to be able to talk about services that have 
multiple, different interfaces.

At the same time, there is a simple concept, that of a "service with one 
interface", or rather of "multiple endpoints which are equivalent but 
use different bindings", that begs to be expressed. It's important for a 
client to know when it runs into one of these things, because it can 
then freely select the most appropriate endpoint based on binding 
considerations and know that it'll work just as well as the others.

I'm not sure which of the two constructs, services as they exist now and 
services as Sanjiva defines them, is more worthy of carrying the name 
"service", but I think that both should be definable in WSDL. Sanjiva's 
construct seems more basic though and it should be possible to define 
the other one as an aggregation of these simpler "services" (even 
representing aggregation via a relationship much like Sanjiva's 
<association/>).

Roberto


Sedukhin, Igor S wrote:
> Let me put my voice into this dicussion. We're -1 on single interface per service. 
> 
> The reason is techically quite simple -- for aggregation purposes it is very covenient. Aggregation may be one of the important aspects of defining a possible usage/implementation pattern for manageable services. Association is NOT always sufficient, so your example, Sanjiva, is not the the only solution necessary for defining manageability, for example.
> 
> The inheritance solution, proposed by Arthur earlier, I believe, does not work well for agregation because of the binding limitation. In case of aggregation, I may want to bind two interfaces designed for two separate purposes with two completely separate bindings, and still call it one service. If I try to mimic this with inheritance, bindings would have to be able to "partially concretize" an interface or dig through the inheritance and pick the one to concretize. That is too much of a change to binding spec and too much of complication for WSDL processors.
> 
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> 
> 
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
> Sent: Friday, May 02, 2003 9:12 PM
> To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1); www-ws-desc@w3.org
> Cc: 'Amelia A. Lewis'; Glen Daniels
> Subject: Re: proposal for restricting a service to a single interface
> 
> 
> 
> "VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com> writes:
> 
>>+1 to Amy. In the management space it is convenient to break down
> 
> management
> 
>>capabilities into different interfaces so that managed object can 
>>choose what sets of capabilities they want to expose for a resource 
>>that they represent. They do this by choosing a set of interfaces they 
>>implement. Those interfaces when grouped in one service are related in 
>>the sense that they provide management capabilities for the same 
>>resource.
> 
> 
> In the management space, how often is it the case that an object manages itself vs. an object has an associate management object? That is, can an object really manage itself (like start/suspend/resume .. if its suspended how do u resume it???)? It seems to me that more often there will be a closely related service that does the management of a given object.
> 
> When we did WSFL, we had a lifecycle interface built into each flow. That worked ok, but in reality the implementation of that interface was not done by the flow itself - it was implemented by a related service and some notifications would be issued to the flow. In BPEL, we changed that and the lifecycle stuff is really outside now in some other service.
> 
> I think what's really needed is a way to say something like this:
> 
>     <service name="s1" interface="x:i1">
>         <port name="p1" .../>
>         <association type="my-management-service">service info</association>
>     </service>
> 
> Then your service's business functionality would be what's in interface i1 and its management interface would be what the associated service does. Similarly there could be lots of other associated services, one that provide reputation information via a BBB like rating system or whatever.
> 
> Sanjiva.
>

Received on Thursday, 8 May 2003 19:03:16 UTC