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]