Re: [soa-rm] service composition scenarios

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

It seems that you see this as an atoms and molecules distinction. I can 
see that that would make sense.

On the POA front, that is a new distinction to me. I always assumed 
that SOA was equivalent to POA; but I am willing to be educated!

I agree completely that

"a service should not care whether it is being consumed as a single 
service or as part of some process. "

Why I think we might need to embrace POA is to be able to account for 
service intermediaries.

On reflection, I would agree that the WSA is much more a POA than a SOA

Frank

On Apr 20, 2005, at 2:43 PM, Duane Nickull wrote:

> 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
> ***********
>
> <parallelServicePattern.png><serialServicePattern.png>