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