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] Opaqueness and Transactions

I hope this 
is a constructive addition to the discussion.


Duane Nickull wrote:

> Wes:
> I have re-thought this a lot too. I now think that a better axiom 
> would be to state that a service controls its' level of opacity. This 
> is also an aspect of the concept of the autonomous nature of services.
> Services are expected to be implemented across a wide variety of 
> boundaries and environments. Assuming vastly different implementation 
> models, a service must remain somewhat autonomous in nature and 
> assumptions of consistent behavior due to central authorities or 
> consistent implementation environments cannot be made carte blanche.
> Some of the logic behind the autonomous nature of services is that 
> they must be able to reclaim resources needed to perform their duties. 
> A service may have several levels of contracts with multiple service 
> consumers. If a quality of service guarantee is offered to one group 
> of service consumers, while a second group is offered services on a 
> “best efforts” basis, the service may decide to end leases on it by 
> the group with the best efforts group in order to reclaim resources 
> need to fulfill its contractual obligations with the guaranteed 
> service group.
> Does any of this make sense or am I in need of a weekend?
> Duane
> McGregor.Wesley@tbs-sct.gc.ca wrote:
>> Hi All,
>> I would like clarification on the following items if possible:
>> Opaqueness
>> I believe there are degrees of opaqueness. If a service interface 
>> allows JAVA classes as a parameter to the actual call, one definitely 
>> knows that the service supports JAVA at some level, implying the 
>> consumer has some knowledge about the internals of the service (not 
>> much but some). The service is not completely opaque.
>> If the service only allowed XML as incoming data and object 
>> constructs, then the parser of choice could be in any language or any 
>> other combination of service calls.  I would then say the service is 
>> more opaque.
>> Proposal: There are degrees of opaqueness within the SOA RM and we 
>> need to define them.
>> Transactions
>> If a service is a combination service, example, service A is composed 
>> of service B and C, are we going to describe the method by which B 
>> and C asynchronous responses are delivered to the appropriate 
>> reception point within service A?
>> Proposal: We need to describe by what method or model we support 
>> service composition at run-time.
>> All comments welcome especially by those who have not said much so far!
>> Enjoy your face to face,
>> Wes
>> -----Original Message-----
>> From:     Ken Laskey [mailto:klaskey@mitre.org] Sent:    April 20, 
>> 2005 4:16 PM
>> To:    Duane Nickull; SOA-RM
>> 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 ***

Mark Little
Chief Architect
Arjuna Technologies Ltd

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