[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opaqueness and Transactions
The grammar for a notification operation is:
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:portType > </wsdl:definitions>
The output element specifies the abstract message format for the notification operation.
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
<Quote>I don't know how it determines what local means to everyone on the list.</Quote>It would probably begin by referencing the OASIS membership information which may eventually get it to your organization's listed city and state - which may or may not be the place at which you actually work (so it would not be foolproof). Security and privacy considerations, of course, come into play.
<Quote>Other than invoking this service, I give it no input (its description tells me it will send to the soa-rm list andI believe it)<Quote>Ah - would the action that invoked (triggered) the service be considered an input?
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.comFrom: Ken Laskey [mailto:klaskey@mitre.org]Sent: Wed 5/4/2005 9:53 AMTo: Chiusano JosephCc: McGregor.Wesley@tbs-sct.gc.ca; Duane Nickull; soa-rm@lists.oasis-open.orgSubject: Re: [soa-rm] Opaqueness and Transactions
I could have a service that sends the local weather to anyone on thesoa-rm mailing list. I don't know how it determines what local meansto everyone on the list. Other than invoking this service, I give itno input (its description tells me it will send to the soa-rm list andI believe it) and it sends nothing back to me as the requester.However, magically everyone gets their local weather. Is this a gooddesign? That question is out of scope as long as this can been aservice 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 LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347515 Colshire Drive fax: 703-983-1379McLean 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]