OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: service composition scenarios


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

PNG image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]