[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opaqueness and Transactions
> -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Tuesday, May 03, 2005 11:41 PM > To: Duane Nickull > Cc: McGregor.Wesley@tbs-sct.gc.ca; soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Opaqueness and Transactions > > I am trying to deal with this in the service section write-up > but unfortunately I haven't gotten back to it since New > Orleans. However, here are some thoughts. > > A service "does something" and that's why you invoke it. To > a certain extent you can say it is opaque if it requires no > inputs and gives no outputs Then is it truly a service? (you do somewhat express that point below, however) Without inputs, how would it know what to process? It is possible to have no outputs, however (although it is not a good design technique IMO). Consider a service that changes the state of something - for example, decrements an inventory by one - based on input from a user. When completed, the service may not provide an output to the user (an example of an output it could provide, of course, would be a message such as "Thank you - the inventory has now been decremented by 1 for this item"), yet the processing was still done. Again, not a good design technique IMO. Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com other than to say it did what it > "advertised" but then one can still draw conclusions on its > internal processing based on that. One can probably draw > better conclusions based on information exchanges through the > published service interfaces. In any case, the only thing > that is completely opaque is something that sits in a closed > box and appears to do absolutely nothing. :-) > > OTOH, a service may publish metadata that reduces its opacity > but does so to support a consumer's need to make sure it is > invoking the appropriate service. So some level of > transparency may be required and that may be in response to > external needs rather than requirements of the service > processing. There are also other possibilities but let's not > get into intentional obfuscation. > > I will try to do justice to this in the write-up but I expect > there to be many, many comments. > > Ken > > On Apr 29, 2005, at 5:52 PM, 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 > > *********** > > > > > -------------------------------------------------------------- > ---------- > ------------------ > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-983-7934 > 7515 Colshire Drive fax: 703-983-1379 > McLean VA 22102-7508 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]