[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: service interaction [was: [soa-rm-ra] Follow-up to 7-5-08 Telecom]
Comments inline: On May 12, 2008, at 2:11 PM, Ken Laskey wrote: > So let me push this a little further now. > > When I was working service description, I emphasized that > description needed to be at the service level rather than the action > level because otherwise it was difficult if not impossible to > describe the policies, functions, and effects of a service. Let me > follow this logic and say the service interaction is that set of > message exchanges under prescribed conditions that result in certain > real world effects. The conditions and effects are captured in the > execution context. The service interaction is then also defined at > the service level and tightly bound to the execution context. As > such, I think the scope Michael required (i.e. beyond just the > message channel) is covered. > > Now to also respond to Frank's later response. I don't think saying > > both actions and events are *initiated* through messages > > really causes any problems and is probably more accurate per Frank's > observation that the message to initiate the action will not result > in the effect if the message doesn't get to the point of action. > Yes, sending the message that tries to initiate an action or > indicate an event is the critical piece for nonrepudiation, but it > does not touch the conditions of action unless that corresponds to > an execution context. I am sorry, but I cannot fully agree with this. I mentioned non- repudiation because that was a consequence of the 'attempting to act' way of thinking. If you postpone the 'real' action until it gets into the service then two things follow: it becomes impossible to pinpoint the actual performance of an action -- especially from the client's perspective -- and it ignores the client's logical view of the world. Consider the situation where an agent signs an agreement: i.e., the fact that an agent agrees to a deal is fully captured by the appropriate interpretation of the message exchanged and has nothing to do with any back-end processing a service performs as a result. Frank > > Ken > > +++ previous email +++ > > I think we handled the execution context okay. The question now is > whether (or when) a separate interaction occurs with each action or > one interaction covers all actions within a process. > > I'm currently wrestling with my wife's medical insurance and related > open enrollment (non-US citizens living in countries with civilized > medical systems, please stop laughing) and don't currently have the > patience to offer an opinion. > > Ken > > On May 10, 2008, at 9:38 PM, Francis McCabe wrote: > >> Michael has a point about 'security in depth'. It is arguably >> better to encrypt the message than the channel. >> >> This is completely independent, however, from the discussion on >> Execution Context. >> >> Frank >> >> On May 10, 2008, at 5:16 PM, Ken Laskey wrote: >> >>> Michael, >>> >>> If I had the chance to modify line 552, I would change SERVICE to >>> SERVICE INTERACTION. My interpretation is that the service being >>> used is an element of the interaction, but the execution context >>> in your example specifies not only the service but also critical >>> elements of what it means to interact with the service when that >>> interaction falls under UK jurisdiction. So I acknowledge what >>> you want to cover but think the service interaction accomplishes >>> that. >>> >>> Before I end, let me push on this from a different angle. If a >>> process model makes use of several actions, I can look at separate >>> service interactions as being what is necessary to accomplish each >>> action or as a single multi-step interaction needed to accomplish >>> the process. I don't believe we've ever clarified that, but I >>> think my explanations lean toward the process interpretation. We >>> made need to pursue that to answer your question. >>> >>> Ken >>> >>> On May 10, 2008, at 7:05 PM, michael.poulin@uk.fid-intl.com wrote: >>> >>>> Ken and Danny, >>>> >>>> while actions better be not assigned to execution context, it is >>>> NOT my point. >>>> >>>> Ken used only one reference in RM to the executions context where >>>> the latter is applied to "a service interaction". Here is >>>> another reference, where EC is applied to the service itself: >>>> >>>> <RM> >>>> 551 In support of the dynamics of interacting with services >>>> are a set of concepts that are about >>>> 552 services themselves. These are the service description, >>>> the EXECUTION CONTEXT OF THE SERVICE and >>>> 553 the contracts and policies that relate to services and >>>> service participants. >>>> <RM> >>>> >>>> In my original message I am saying that for the SOA service all >>>> security measures applied to the service interaction MUST apply >>>> to the service ITSELF also, to this or that degree; the SOA RA >>>> HAS to point to this, otherwise we are sending a wrong message to >>>> the community. >>>> >>>> To achieve this consistent security view, I propose to replace >>>> words SOA-based message exchange by the words SOA-based systems >>>> in the section 5.2.7. That is, I propose to extend security >>>> requirements onto the SOA eco-system; service interaction is an >>>> important but only a part of the SOA eco-system. >>>> >>>> If you disagree with me, please, say this directly. Below, I am >>>> giving you a real-life example: >>>> a fund management company accepts debit card payments via its Web >>>> portal; the portal is supported by SOA services (inside >>>> enterprise firewall), which process payments validation and store >>>> payment attributes (including debit card number, etc.) in its >>>> local databases for later settlement procedure. Currently, at >>>> least, in the UK, it is required that all payment attributes >>>> related to the card to be encrypted in certain way (in all data >>>> stores through the processing) defined by the PCI DSS standard (https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm >>>> ). This protects sensitive card information from the tempering >>>> even inside the enterprise. >>>> >>>> Thus, security of the service body/implementation is equally >>>> important as the security of the service interaction (via its >>>> interface). I hope, you get me right this time. >>>> >>>> - Michael >>>> >>> >>> ----------------------------------------------------------------------------- >>> Ken Laskey >>> MITRE Corporation, M/S H305 phone: 703-983-7934 >>> 7151 Colshire Drive fax: 703-983-1379 >>> McLean VA 22102-7508 >>> >>> >>> >>> >> > > ----------------------------------------------------------------------------- > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-983-7934 > 7151 Colshire Drive fax: 703-983-1379 > McLean VA 22102-7508 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]