OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[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 to 7-5-08 Telecom]


We have Action defined in 3.5.1: Action is the application of intent 
by a participant to achieve a real world effect.

The application of intent can and does exist in the messages, if any, 
and/or the automated process that constitutes the execution context. 
So I disagree with Michael that action should separated from 
execution context (which was not part of his original message).

I didn't catch this earlier because I'm dense and I've been busy, but 
it should have dawned on me that Ken was making a distinction between 
a service level, by which I think he meant the connection between the 
service description and the business viewpoint (not the the view), 
and an action level, by which I 'think' he meant the connection 
between the invocation (trigger) of the execution context (without a 
specific message, e.g. by rule which may include some security 
factors including signed encryption within the body of the message) 
or the invocation message itself (subject to security factors) that 
specifically initiates the execution context, (going back to 
Michael's original message). BTW I agree with Michael's suggestion 
that "SOA-based message exchanges should" be changed to "SOA-based 
systems should" because the latter subsumes the former.

However, in regard to Ken's thought: I don't think we have defined 
these 'levels' and he was using the idea of a 'level' as a handy 
fiction to illustrate his point.

I think we would be best served to keep 'action' to the definition 
and keep 'interaction' to its related definition in section 3.5.3 as 
a joint action: A joint action is an action involving the efforts of 
two or more participants to achieve a real world effect.

The difference is that 'action' is singular and 'interaction' or 
'joint action' is plural. Both aim to achieve an intended real world 
effect. I'm not sure how we got off into the distinctions between 
messages and back-end processing being part of 'Action.' In my 
opinion messages and processing are or can be part of an Action or 
Joint Action (interaction).

Cheers,
Rex

At 11:01 PM -0400 5/12/08, Ken Laskey wrote:
>My turn to disagree.  As noted previously, we have seriously 
>overloaded the term action.
>
>I don't think the RM is particularly clear on this and itself uses 
>the term action in different contexts.  The most relevant discussion 
>defines the action model:
>
>The characterization of the permissible actions that may be invoked 
>against a service.
>
>If sending the message is the action, why didn't we just say that? 
> If there is no message, i.e. the more general SOA, what is the 
>action?
>
>Ken
>
>On May 12, 2008, at 10:45 PM, Francis McCabe wrote:
>
>>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, 
>>>>>>><mailto:michael.poulin@uk.fid-intl.com>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>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>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
>>>
>>>
>>>
>>>
>>
>
>-----------------------------------------------------------------------------
>Ken Laskey
>MITRE Corporation, M/S H305      phone: 703-983-7934
>7151 Colshire Drive                         fax:       703-983-1379
>McLean VA 22102-7508
>
>
>
>
>
>Attachment converted: Macintosh HD:smime 775.p7s (    /    ) (0072C5B2)


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]