[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Re: service interaction [was: [soa-rm-ra] Follow-up to7-5-08 Telecom]
Yes. Because I think that the sending of the message *is* the action. The back-end processing is the response to the action. Frank On May 12, 2008, at 7:14 PM, Ken Laskey wrote: > Frank, > > I don't think anybody is saying that action is strictly the back end > processing. I send a message to an endpoint. On receipt, an action > is initiated. It may just be the receiver agent wakes up. The > processing that follows SHOULD (not positive whether there are cases > that preclude MUST) be in line with the execution context. Some of > that may be taken care of by the choice of endpoint receiving the > message. The continuing interaction may require passing additional > messages and initiating additional actions in order to realize the > RWE. > > Do you still have problems with that? > > Ken > > On May 12, 2008, at 6:22 PM, Francis McCabe wrote: > >> 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 >>> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs >> in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/ >> my_workgroups.php > > ----------------------------------------------------------------------------- > 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]