Again interspersed.On May 21, 2008, at 12:38 AM, Francis McCabe wrote: Hi Ken Comments and thoughts in-line: On May 20, 2008, at 8:49 PM, Ken Laskey wrote:
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.
This may be true; but I know that for myself, I have had a consistent understanding action. If we do not communicate a consistent understanding then that needs fixing.
I don't think we have sufficiently captured your understanding. As I said, I see where you're going but I'm not sure I'm comfortable with all the implications. Hopefully this discussion will tease out some important details. I don't think we have
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.
This is one area where we made a genuine advance in the RA work. At the time of the RM we did not have the same clear distinction of action and event that we have now. The clause 'information exchanges' was there to cover the REST-style web access where the only thing returned by a service was information. I would now re-characterize that within the RM to actions and events if I could.
I still see an information return in response to a request, e.g. a GET, as RWE and not an event. An event would be someone being notified that a service has sent a response somewhere. This may be analogous to a bank sending me a credit card (a RWE) and a letter telling me a credit card had been sent (the event).
First, would it be appropriate to harmonize the two by having section 4.3 read: An interaction proceeds through a sequence of actions?
This seems right.
sold!
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.)
Oops. This needs to be fixed. We should have just one definition. The one on line 784 is too short, I think. And it focuses too much on goals. However, I know where it came from :)
The defn on line 844 is a bit windy; but is better suited to our purposes.
I think 844 is dialog that follows a definition like 784. Also, I think Figure 10 needs a connection between Intent and Action rather than Intent and RWE, and should probably also include Goal.
If sending the message is the Action, then the action model of a service consists of the messages that can be received.
Yes.
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.
In fact, the preconditions of an action may 'reside' anywhere. They may be associated with the sender or the receiver (e.g., sending an open account to a bottle bank does not have quite the same meaning as to a local bank). In general, I think that it is good practice to require that preconditions be public and conversation oriented -- a transfer balance action/message has no meaning if there was no previous open account action/message.
Certainly the sender may (should) have preconditions -- the most important being that the action furthers one of his/her goals.
To this point, there is too little of a connection between the sender's preconditions and that of the recipient/service. The next couple lines is trying to elaborate a tightening.
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>
There is a whole section that we might want to write on the methodology of services -- how to identify services, how to design services that work well with each other etc. Would this be part of owning/using or ecosystem views?
This is broached in section 4.1.2.2. It may need to reside there or elsewhere.
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.
I really really need that indirection. I want to be able to describe the public semantics of an action -- that may have nothing to do with anything that a software system does in response to the action.
This has nothing to do with the private actions of the recipient/service. Of course there are public semantics (or a public means of semantic negotiation) because the sender should only send a message the recipient understands. I see making the obvious clear but in most cases I don't need to pick that apart, and I think it will lead to confusion on the part of the reader. This is analogous to the question of when we need to be explicit about there being an Agent.
Something like lines 328-333 of the RM -- especially the last line -- may be useful:
The service concept above emphasizes a distinction between a capability that represents some functionality created to address a need and the point of access where that capability is brought to bear in the context of SOA. It is assumed that capabilities exist outside of SOA. In actual use, maintaining this distinction may not be critical (i.e. the service may be talked about in terms of being the capability) but the separation is pertinent in terms of a clear expression of the nature of SOA and the value it provides.
We can discuss Agent, we can discuss the indirection, but we can do without the details where convenient. There are a lot of examples of action where the message *is* the action and any internal actions that a system performs are reactions to the action rather than completions or implementations of the action. Two examples: "I pronounce that you shall be hanged at the yardarm" and "I hereby sign the contract".
Two problems: 1. I interpret the examples differently. Pronouncing the sentence or making it clear you have signed a contract is the RWE. The message is merely the means of conveying that, and is more akin to an event. 2. Following the RM, we only need to be complete for examples having to do with software architecture. Do we have such examples that illustrate your point?
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?
Hmm. The way I think of operations is that they form the halves (if you will) of the joint action.
Don't think that works because Operation is a sequence of actions, where I interpret sequence to be any number of steps and not just two halves. They are not private, because the joint action itself is not private. I am certainly willing to come up with a different name if that helps avoid confusion.
Still think we need a strong, explicit connection with 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?
So, in defense of Jeff, I would say that the language is a little informal. But, it is easy to think of a single instance of a MEP as constituting a joint action -- joint actions do not need to be in parallel to be joint. It is like the difference between a solid diamond and a hollow diamond in UML (if that does not confuse the matter further of course :)
I think you are confusing the two parts of a joint action with the separate messages (both joint actions) of request/response.
I thought Jeff's statement was clear but now we need to get back to the job of clarity and consistency.
Enough for now.
As usual, Ken, some thought provoking questions. Much appreciated.
Does this capture the uneasiness that Dave Ellis was talking about wrt action?
I'm sure Dave has other comments :-)
Frank
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
----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
|