[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Opaqueness and Transactions
Mark: The link kept stopping me from accessing it. Can anyone else see it? Duane Mark Little wrote: > I hope this > http://www.orablogs.com/pavlik/archives/The-Session-Concept-in-Web-Services.pdf > is a constructive addition to the discussion. > > Mark. > > > 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 *** >>> >>> >>> >>> >>> >>> >>> >>> >> > -- *********** 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]