[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Opaqueness and Transactions
I could have a service that sends the local weather to anyone on the soa-rm mailing list. I don't know how it determines what local means to everyone on the list. Other than invoking this service, I give it no input (its description tells me it will send to the soa-rm list and I believe it) and it sends nothing back to me as the requester. However, magically everyone gets their local weather. Is this a good design? That question is out of scope as long as this can been a service in an SOA. Ken On May 4, 2005, at 7:52 AM, Chiusano Joseph wrote: >> -----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 >> >> >> >> ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 *** note change of phone extension from 883 to 983 effective 4/15/2005 ***
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]