Sorry to send you a duplicate, Ken,
However, I neglected to hit the "reply to all" option. I'll respond
to Jeff separately.
Cheers,
Rex
>Date: Wed, 4 Jun 2008 17:58:27 -0700
>To: Ken Laskey <>
>From: Rex Brooks <>
>Subject: Re: [soa-rm-ra] The many faces of Action
>Cc:
>Bcc:
>X-Attachments:
>
>Thanks Ken,
>
>My response is inline.
>
>>I think it's agreed that we need to have a consistent story for
>>
>>- Action as part of the Action and Process Models
>>
>>- Action as related to Messages and Interaction.
>>
>>As promised near the end of today's call, I'm trying to capture
>>what we have so far and look for the common thread. The following
>>is my attempt at that. Personally, I think the thread gets a
>>little frayed by the end but that's why we work as a team to bind
>>those threads together.
>>
>>So here goes. We start with the definition of Action from line 755:
>>
>>Action is the application of intent by a participant (or agent) to
>>achieve a real world effect.
>>
>>So any time "action" is used in the following, I should be able
>>(and intend) to identify
>>
>>- what is the intent
>>
>>- whose intent is it
>>
>>- how is it applied
>>
>>- what RWE does the who expect
>>
>>To summarize where we were at the end of the call, to first order
>>
>>- Action as used in the Action Model is singular, i.e. there
>>is only one Participant
>>
>>- Action in Interaction is Joint Action, i.e. there must be
>>two or more Participants
>>
>>- Types of Joint Action are:
>>
>> -- serial: one Participant does something [is this an Action in
>>any sense?] and then another Participant does something in turn,
>>possibly in response. A Speaker speaking followed by a Listener
>>receiving the speech is an example.
>>
>> -- parallel: some subset of the Participants must do separate
>>things at the same time for the desired RWE to occur. One
>>Participant signing a contract and another Participant witnessing
>>the signing is an example we used during the call.
>>
>> -- cooperative: two or more Participants have to do separate
>>(possibly very similar) things in a coordinated manner for the
>>desired RWE to occur. Two Participants lifting a heavy object is
>>an example; again, an example from the call.
>>
>>- A Communicative Action is a parallel Joint Action in which
>>one Participant takes on the role of Speaker and the other
>>Participants take on the role of Listener. Who is the Speaker and
>>who are the Listeners typically changes over the course of an
>>Interaction.
>>
>>We have committed for this RA that Interaction will be done through
>>message exchange.
>>
>>Checkpoint 1: do we have agreement to here?
>
>This works for me.
>
>>
>>
>>Frank has advocated that the message is the Action. Thus, how
>>intent is applied is always by using a message create and send
>>client. This doesn't pass my feel-right test, but we'll let it go
>>for now.
>
>Doesn't feel right to me either. I think the use of a message
>denotes a communicative action.
>
>>If the Action Model (as defined in the RM) is the characterization
>>of the actions that may be invoked against the service, then the
>>Action Model comprises those messages that the service is prepared
>>to receive. This begs the question of what needs to be done in
>>response to receiving a message, and for lack of a better term I'm
>>going to refer to the effect (RWE?) of receiving the message as the
>>Initiated Activity. Thus, there is an Initiated Activity for every
>>received message, where the details of the activity are private to
>>the service.
>
>hmmmn. Have to give this some thought. This is where I prefer for
>the result of a message to be a bit more like an additive process,
>e.g. each stage of the process adds its allotment of "something" to
>the process up until a threshold of some kind is reached where a
>pre-defined "event" or "trigger" occurs which achieves some part of
>the RWE (perhaps all, perhaps only some of a RWE).
>
>>According to the RM, the Process Model characterizes the temporal
>>relationships and temporal properties of actions and events
>>associated with interacting with the service. Let's stick with
>>Actions and not look at Events right now. So the Process Model is
>>saying the service has to receive a first message before it is
>>prepared to receive the second message and move on to completing
>>its described business function, leading to its described business
>>function RWE. This can be seen as a Precondition for the Action.
>>
>>Checkpoint 2: I think things are still holding together. Are
>>others still on board?
>
>Slightly different words but the gist seems the same with the
>exception that I brought up the "event' already.
>
>>
>>
>>Now we've said the Actions for the Action (and Process) Model are
>>singular, i.e. there is only one Participant. So who is the
>>Participant?
>
>Disagree. See below.
>
>>It has to be the service because that is the only constant. Where
>>in our models do we show a single Participant "invoking" Action?
>>What are the conditions and relationships? I would have to say the
>>Action is the "act" of the service receiving (being prepared to
>>receive?) the message and proceeding (being prepared to proceed?)
>>with the Initiating Activity in response. The Action is more of a
>>potential because it has to exist even when there isn't a message.
>>Note, if there is a real message, then we have Interaction and
>>therefore Joint Action.
>
>For me, the consumer requesting the service is an Action. It becomes
>an Interaction only if it triggers a response, e.g. a Joint Action.
>That's why receiving a message is so often the "Event" which
>initiates a Business Process. However, it is the reception of the
>message which serves as the Event, not the sending of the message.
>Sending the message is prototypical Action. It is purely singular
>even if the parties have exchanged WSDLs and practiced the
>interchange in simulations to work out the kinks.
>
>The Service can only hold itself in readiness until it is requested.
>There are potentially different intents at work, some that coincide,
>some that don't. The Consumer intends to request and use the
>Service. The Provider intends to offer the Service under some set of
>conditions. The Consumer and Provider both intend to bring about
>some part or all of the RWE, which can have many parts, some of
>which require Joint Actions, Communicative Actions and Singular
>Action.
>
>>So under these conditions, for singular Action:
>>
>>- intent: proceed to Initiating Activity
>>
>>- who: the service
>>
>>- how: private
>>
>>- RWE: whatever portion of the RWE associated with the business
>>function that is achieved from this Action
>>
>>This isn't very satisfying, so I look forward to variations.
>>
>>How does things change is there is a message and we proceed with
>>Interaction? The Speaker (who) uses a client to create and send a
>>message (how) so the service will proceed with the Initiating
>>Activity (intent) leading to a successfully completed business
>>function (RWE). The "jointness" (i.e. completing the Communicative
>>Action) is the Listener is there to receive the message, and then
>>we're on to the Activity.
>>
>>Checkpoint 3: Are things starting to get flaky?
>>
>>
>>
>>This seems to create schizophrenia with the concept of Action. I
>>still think this goes away if the message is what initiates the
>>service Action rather than having to be an Action itself.
>
>Agree. See above.
>
>>But let's see where else this may go. Per Jeff's model that just
>>came in, Communicative Action conveys (initiates?)
>
>Disagree. I take convey to mean "transports or transmits a message
>or notification."
>
>>Action. I can interpret this to mean the communicative Action
>>leads to the singular Action of the Action and Process Models to
>>proceed with the corresponding Initiating Activity. The component
>>Message provides (conveys) the Message payload (per indicated
>>Structure and Semantics) to that same Action so it has what it
>>needs to proceed.
>
>I think the "Initiating Activity" should be spelled out as the
>"Event" agreed upon beforehand where some threshold is reached which
>starts a process according to a "Business Rule." For me this is
>where business logic takes over, however it gets initiated, and is
>more precisely "Management."
>
>>Checkpoint 4: is this a reasonable interpretation of what is
>>intended by the model?
>
>For me, yes, with the caveats mentioned.
>
>>
>>
>>Questions related to models:
>>
>>1. Do we need a common parent class for Action and Joint Action?
>>Having the two independent as classes but so tightly entwined will
>>undoubtedly lead to more confusion.
>
>I think the distinction between one participant and two or more is
>pretty clear cut.
>
>>
>>2. In an attempt to simplify, can we say that
>>
>> a. we are only modeling SOA so we do not have to show subclasses
>>that are not relevant to SOA, and
>
>I think Action > Joint Action/Interaction (or Transaction) are
>acutely relevant to SOA and especially the RA, and we should just
>keep hammerin' on it till we get consensus.
>
>> b. if we only have one subclass of a class, then we should
>>collapse those into the subclass and, if helpful for clarity, only
>>mention the parent class in the accompanying text.
>
>Don't like this a hard and fast rule, but as a rule of thumb (not
>applied to Action > JointAction>CommunicativeAction) 'sokay.
>
>
>Cheers,
>Rex
>
>>
>>
>>
>>Other important things I'm missing?
>>
>>
>>
>>Ken
>>
>>
>>------------------------------------------------------------------------------------------
>>
>>Ken Laskey
>>
>>MITRE Corporation, M/S H305 phone: 703-983-7934
>>
>>7515 Colshire Drive fax: 703-983-1379
>>
>>McLean VA 22102-7508
>
>
>--
>
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-898-0670
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
