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