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: M reads: rm-ra] Re: service interaction [was: [soa-rm-ra] Follow-up to 7-5-08 Telecom]


Sorry I let this drop but couldn't push it while on travel.  I've reread the RM and sections 3.5 and 4.3 of the RA, and I'm still not satisfied we are clear on what needs to be said about Action.

Section 4.3 reads: An interaction can be characterized by a sequence of actions.

The RM reads:  interaction proceeds through a series of information exchanges and involved actions.

First, would it be appropriate to harmonize the two by having section 4.3 read: An interaction proceeds through a sequence of actions?

Next, I have been picking at our definition of Action as the application of intent.  (Note, Intent is defined differently on line 784 and line 844.)

If sending the message is the Action, then the action model of a service consists of the messages that can be received.

Line 759 states: An action may have preconditions.  If the action is the sending of the message, then the preconditions are those of the sender and not the receiver (likely the service).  I don't send messages before breakfast can be my precondition.  The receiver may not know or care about my preconditions.

Now, it is reasonable that the message sender's preconditions should include:
- knowing the message being sent to a given endpoint is part of the receiver's action model related to that endpoint
- knowing preconditions of the message endpoint, especially the related process model.

<digression>
Before I go on, let me respond to Rex's comment.  My distinction between action level and service level is meant to be real and not just for that discussion.  In theory, there can be one Ken Laskey Web Service (I'm being specific here on purpose) that does everything Ken Laskey needs through dozens of WSDL operations: one operation for sports scores, another for stock quotes, another to tell my wife when I've left work.  Each operation can have its peculiar RWE and, per WS-Policy, can have its separate policies.  From the perspective of service description and discovery, this is a disaster.  How can I describe a service if I have to describe each operation in separate detail?  Why aren't these just separate services?

The examples we give in the RM talk to multiple process steps -- described in the process model -- that must be followed in sequence to realize a RWE.  There is then some describable connection that can be captured at the service level.
</digression>

Back to Frank's context for action, an agent sends a message because it knows the RWE will be the message recipient, e.g. a service, taking certain "action".  Let's assume the action is the application of intent by the service.  Is making this indirection explicit really necessary?  Action against the service makes no sense if the service doesn't follow with an action.  Do we lose anything by saying the message sender invokes the service's action.  Interaction will still be the sequence of actions -- each a joint action between sender and receiver -- leading to the RWE.

One final thing: there appears there should be a strong, explicit connection between Operation defined in section 4.3.2 and the Process Model.  Note that Operation is only used in two places: the paragraph beginning on line 1955 and on line 2007.  So I ask whether defining Operation is necessary, especially because it is likely to cause confusion with the WSDL operation.  Can we not talk about this in terms of private actions or steps in the process model?

And one more thing: line 1965 states: the request/response MEP represents action.  What does this mean if both the request and the response is a joint action?

Enough for now.

Ken

On May 13, 2008, at 12:15 PM, Jeffrey A. Estefan wrote:

Folks,
 
Remember, there are only two types of action:
 
1. [Separate] "Action," which is the application of intent by [A] participant (or agent) in order to achieve a RWE.
2. "Joint Action," which is an action involving the efforts of [TWO OR MORE] participants to achieve a RWE.
 
Note:  The emphasis in brackets is mine.
 
In the context of interaction, we emphasize "joint action" because you have to have a speaker AND a listener in order to interact.  Further, recall that we define the means by which joint actions [and event notifications] are coordinated by service participants (or agents) to be "message exchange," and we define "operations" as the sequence of actions a service must perform in order to validly participate in a joint action.  Consequently, there are indeed separate actions that service performs (i.e., perform operations) and there are joint actions [and event notifications] used for message exchange.  This is why we make the point that messages denote either action (more accurately, joint action) that causes a RWE and events that report a RWE.
 
What we should probably do is make the emphasis on joint action relative to Fig. 40 (based on PRD 1 of the RA) so as to not cause this kind of confusion.  The emphasis on joint action isn't really addressed in until later in Section 4.3.2 when we talk about message exchange.  In addition, it is not just the joint action realized through messages that causes a RWE to occur but also the separate actions (i.e., operations) that the service performs that contribute to the RWE, i.e., it is both types of action performed in concert that leads to a RWE.  This point is not clearly articulated in the RA and needs to be.
 
If yawl agree, I'll make the necessary minor updates to the Interacting with Services model to help resolve this ambiguity before the next PRD.
 
Cheers...
 
 - Jeff
 
 
 
 
 
 
 
 
 
 

-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7515 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508





smime.p7s



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