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 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]