Re: [soa-rm] service composition scenarios

[Francis McCabe <fgm@fla.fujitsu.com>]

Duane:
  All your comments are fine. However, there is still the case of what I 
have referred to as the "transparent service combination".
  In that case, the services are combined, perhaps without the knowledge 
of the owners of those services, in a transparent manner -- where it is 
obvious that there are component services.

  A transparent service would typically not have a *single* provider -- 
or owner. The scenario is something like this: provider A offers a full 
meta description of service A, B likewise. A third party offers a 
transparent service as a combination of A & B. This third party need 
not have any a priori connection to either A or B.

  This is like the difference between a playlist and the MP3 file 
itself. The playlist tells you which tracks to play without embodying 
the music itself. You can trade playlists, merge them, etc. 
independently of the underlying music files.

Finally, there is another situation. Even supposing the intervention of 
an offering agent for a combined service, there are likely to be cases 
where the abstraction breaks down -- in error cases for example. In 
that case you will get faults along the lines of "you did not get your 
book because the Fedex dog ate it"

Frank

On Apr 20, 2005, at 12:54 PM, Duane Nickull wrote:

> TC:
>
> Although this may not be part of the core RM, this is probably an 
> interesting discussion to have.  The concept of service composition 
> has been raised a few times on the list.  I wanted to state a few 
> observations about this concept.  Please see attached diagram for 
> details.
>
> 1. Services are opaque by nature.  That means that the service 
> consumer cannot see anything beyond the interface (service interface) 
> it uses.  If one service is actually aggregating two other services, 
> the service consumer cannot and should not know this.  From a service 
> consumers viewpoint, a service is merely an agent or interface that 
> offer some function(s).  Whether those functions are mapped to a set 
> of classes in some native language or another service is not important 
> or relevant (other than the service metadata stating what invoking the 
> service means or does)
>
> 2. The service function (for service A) is described in the service 
> description specific to that service.  If completing the function 
> depends on two or more serial or parallel paths of execution 
> successfully completing behind the service interface (like calling 
> services B and C) within a certain time frame, that is not relevant to 
> state in the service description for service A.  The service consumer 
> is only concerned with the service's ultimate success or failure.  
> Mapping the functionality to success and failure is the responsibility 
> of the service provider.
>
> Do you agree with this?  This supports the notion of opaqueness.
>
> 3. # 1 and # 2 above are mandatory to comply with a services 
> autonomous nature as described in the W3C WSA and subsequent services 
> architectures.  A service alone must determine whether the service 
> succeeds or fails.  If a service consumer can see any specifics behind 
> the service, this violates several of the core principles of SOA.  If 
> visibility beyond the offered service is required, then the service 
> does nor meet the demand of the service consumer.  Accordingly, the 
> service provider and consumer should discuss and re engineer.
>
> When implementing, more complex patterns of service invocation can be 
> facilitated while keeping these three axioms.  If a transaction 
> sequence is needed, a service interface can offer two services - a 
> put() and a commit().
>
> Duane
>
> -- 
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. - 
> http://www.adobe.com
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Adobe Enterprise Developer Resources  - 
> http://www.adobe.com/enterprise/developer/main.html
> ***********
>
> <compositeServiceA.png>