[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] service composition scenarios
Duane, I agree with your analysis. If there is a reason to know details of what the service is doing, e.g. a language translation is needed as part of what the composite service will do and the user wants to make sure a certain class of translation engines is used, then this information should be part of the service description/metadata and there may be rules/policy to evaluate for the user to make sure the composite server is appropriate. Constructing an orchestrated composite service may be done through another service, but such a service will be like any other to the RM. However, the example does indicate there may be a need for specific metadata and rules/policy capability and this may or may not go beyond the idea of a generic service. (Or, we may say that an SOA requires certain instances of a generic service be present.) Ken At 03:54 PM 4/20/2005, 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 >*********** > > -- --------------------------------------------------------------------------------- / 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 ***
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]