Re: [soa-rm] service composition scenarios

[Ken Laskey <klaskey@mitre.org>]

Frank,

Part of a service being opaque is we don't know if it is preconfigured or 
configured on the fly.  This, in part, is where the question of logging and 
requester access to the log comes in.

But your email brings up another point: where does fault reporting/recovery 
show up in the RM?

Ken

At 04:13 PM 4/20/2005, Francis McCabe wrote:
>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>
>

--
      ---------------------------------------------------------------------------------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------

*** note: phone number changed 4/15/2005 to 703-983-7934 ***