[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Opaqueness and Transactions
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 *** >> >> >> >> >> >> >> >> > -- Mark Little Chief Architect Arjuna Technologies Ltd (www.arjuna.com)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]