[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Opaqueness and Transactions
Very strange; it works for me. Anyway, I've attached the document in case this is a wider problem. Mark. Duane Nickull wrote: > 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 *** >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > -- Mark Little Chief Architect Arjuna Technologies Ltd (www.arjuna.com)
The-Session-Concept-in-Web-Services.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]