[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]
I see Frank's point, the action is initiated by a consumer sending a
message. So message based communications are really joint actions
between the consumer and provider.
This is reflected in Figure 13, Semantics of Communication Model, line
831, page 23.
Danny
-------- Original Message --------
Subject: Re: [soa-rm-ra] Re: service interaction [was: [soa-rm-ra]
Follow-up to 7-5-08 Telecom]
From: Ken Laskey <klaskey@mitre.org>
Date: Mon, May 12, 2008 8:01 pm
To: Francis McCabe <frankmccabe@mac.com>
Cc: michael.poulin@uk.fid-intl.com, soa-rm-ra@lists.oasis-open.org,
danny.thornton@scalablearchitectures.com
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, 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
-----------------------------------------------------------------------------
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]