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: 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.


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