Re: [soa-rm] service composition scenarios

[Duane Nickull <dnickull@adobe.com>]

Frank:

I think I understand your point of view now.  The scenario you describe 
above sounds similar to how I interpret Martin's process management 
concept.  We wrote an architectural pattern for process as a layer over 
top of SOA to illustrate that service consumers may consume more than 
one services as a functional work unit.  There were two basic patterns 
for consumption of multiple services - serial and parallel. (see attached).

The basic premise is that each service is an autonomous, oblivious 
atom.  The layer of logic that maps out the 
orchestration/choreography/rules of consuming more than one service is 
the "POA" concept.  This equates to the process management concept 
Martin referred to.  From a services perspective, I submit that a 
service should not care whether it is being consumed as a single service 
or as part of some process.  There is no distinction that the service 
itself has to be aware of.  Note: If a service is to be used as part of 
a process involving serial or parallel consumption of multiple services, 
AND there is some sort of ACID policy, the service probably needs to 
have functions for both "put()" and "commit()".

This would be in alignment with the W3C WSA and WS* architecture.

I can see that there is an open question regarding the scope of SOA.  
Does it include the service consumer (either normative or in a non 
normative manner).  If it does, should the concept be discussed since 
process management is part of the service consumers functionality, not 
the service itself.  My taking is that for the SOA Reference model, this 
is probably out of bounds, but still open to discussion on this matter.  
I think that this is probably the basis for a second reference model 
called Process Oriented Architecture (which suffers from the same 
ambiguity as SOA due to the multiple perceptions of what it really is.

Nevertheless, it may be good to make note of this to help facilitate 
understanding of how POA relates and dovetails into SOA.  I have some 
axioms in mind:

1. Architecture may be both SOA and POA concurrently. (based on our 
limited assumptions and understanding of what each of those are)
2. A service does not need to distinguish from services requests that 
are part of a process involving more than one service vs. a single 
call.  Any logic, choreography and/or orchestration for "transparent 
service consumption's" MUST be kept away from the service itself. 
3. (however) Services MAY logically be in alignment with the types of 
services required for a Service Consumer to execute a process involving 
multiple services, either in parallel or serial invocation.

We may need to consider how we can explain this is a section.  For now, 
perhaps it can be added as place holder.

My $0.02 CAD worth.

Duane


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

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