[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 ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]