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: Re: [soa-rm-ra] Fwd: [guinea pig] July 24 notes on Interaction,Action Model, and (Service) Action


I find it pretty comprehensible, with one minor exception: we need to 
prevent 'public service action' from being confused with politics. 
Perhaps 'public (transparent-visible) service action' or 
'publicly-visible service action' or 'public, service action.'

My opinion on "Can we keep things to the Participant level and the 
Service level?" NO. This is the real meat of the RA. I would say its 
a MUST. (Of course I won't drag us all down over it, but I did want 
to emphasize that I think its very important.)

I don't want to leave the door wide open for 'fifty ways to leave 
your lover..." Analogously, this is the process point where 
contractors can substitute substandard materials to build bridges 
which fail under stress if there isn't a policy enforcement point 
built into the process.

Suggestion (This is purely arbitrary and is not based on any internal 
logic related to 'kinds' of messages): Two basic kinds of messages:
Communicative Action Messages (e.g. Messages that Invoke or Trigger 
Service: Book Flight, Check Credit Card, etc);
Service Action Messages (e.g. Messages that Denote Completion/Result 
of Service: Flight Booked, Credit Card Declined, etc).

This corresponds to Request-Response, but could handle all MEPs. We 
need both kinds of messages (lack of completing message can be 
written into policy for: ignore or abort) to complete Joint Actions 
and/or Interactions. Whether Joint Action is superclass or subclass 
of Interaction is open to debate. They seem more like sibling 
subclasses of Action to me.

Note: Yes, we're all frustrated by this sticking point, but... If we 
don't tackle this now, it'll bite us later.

Painful experience tells me that if we don't specify restrictions, 
Real World Situations will demand that loosely-specified components 
will be used to shoe-horn usages that don't clearly fit elsewhere. 
Sometimes this is of negligible impact, but in emergency response, 
its critical.

When someone uses a headline text field from an alert/warning 
standard for instructions and you see it in an amber alert sign on a 
highway being used for evacuation information, it gets very sticky.

Cheers,
Rex



At 10:30 PM -0400 7/24/08, Ken Laskey wrote:
>I asked Danny to be a guinea pig before I sent this to the list 
>because I wasn't sure it would be understandable.  Danny is either 
>exceptionally perceptive, the notes make sense, or both.  Thus, I 
>have a 2 out of 3 chance this will be informative to the whole list.
>
>If there are major problems, Jeff will be happy to answer all questions ;-)
>
>Ken
>
>Begin forwarded message:
>
>>From: "Danny Thornton" <danny.thornton@scalablearchitectures.com>
>>Date: July 24, 2008 6:17:55 PM EDT
>>To: "Ken Laskey" <klaskey@mitre.org>
>>Cc: "Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
>>Subject: RE: [guinea pig] July 24 notes on Interaction, Action 
>>Model, and (Service) Action
>>
>>What you've described makes sense to me.  In the realization view 
>>we can discuss interaction via messages, but we should not limit 
>>the discussion to just messages in the ecosystem view.   My 
>>understanding of your summary below supports the ecosystem layer of 
>>participant/communicative exchange(action) down to the realization 
>>layer of service/message exchange.
>>
>>While the layered approach eliminates the confusion of an agent 
>>versus a participant, I think it will be confusing to start adding 
>>agent to the realization/owning section diagrams.   I still agree 
>>with Ken that we should have a section that comments on the 
>>assumption of the use of agents in the diagrams.  Unless someone 
>>can demonstrate how that can be done succesfully without causing 
>>confusion.
>>
>>Danny Thornton
>>
>>
>>-------- Original Message --------
>>Subject: [guinea pig] July 24 notes on Interaction, Action Model, and
>>(Service) Action
>>From: Ken Laskey <klaskey@mitre.org>
>>Date: Thu, July 24, 2008 2:59 pm
>>To: Danny Thornton <danny.thornton@scalablearchitectures.com>
>>Cc: "Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
>>
>>Danny,
>>
>>You may be wondering about the subject line.  The following are 
>>notes I made during a discussion Jeff and I had today.  Jeff 
>>suggested I distribute to the group but before I do that I wanted 
>>to check if it at all comprehensible by someone who was not part of 
>>the discussion.  So before I raise a firestorm of misunderstanding, 
>>I'd like you to see if it makes some sense to you.
>>
>>Thanks,
>>
>>Ken
>>
>><notes>
>>At Frank level (Service Ecosystem View), Joint Action between Participants.
>>
>>Realizing SOA View is more mechanical --> interacting with 
>>services, not between Participants
>>
>>Need relationship between Joint Action and Interaction at 
>>Participant level and then at the Service level
>>
>>Services are Agents, not Participants
>>
>>Both Agents and Participants capable of Actions, whether or not we 
>>define these as subtypes of Actor
>>
>>Can we keep things to the Participant level and the Service level?
>>
>>Jeff: Interaction is realized by message exchange
>>
>>From RM: Interaction as one or more message exchanges, each 
>>conforming to MEPs as described in service description
>>
>>From RM: Interacting with a service involves performing actions 
>>against the service.
>>
>>Ignoring Joint Action for the moment. For RA, at service level, 
>>interaction is set of message exchanges.
>>
>>Agreed: Interaction realized by (process of) message exchange AND 
>>composed of individual message exchanges (that may conform to 
>>different MEPs).
>>
>>Still question of unnamed bucket that contains more than one 
>>interaction and some private actions towards realizing RWE.
>>
>>RM: The action model of a service is the characterization of the 
>>actions that may be invoked against the service.
>>
>>Action in Action Model aligns with WSDL operation.  Action is what 
>>we want service to do and message is the means by which I tell 
>>service to do it.  The act of sending a message is part of 
>>interaction.  Frank: sending message is Action.
>>Jeff: qualify as Service Action? as all the actions (both public 
>>and private) that a service performs to achieve a RWE.  The public 
>>service actions correspond to the permissible actions a service can 
>>perform, i.e., service action exposed by the service and that 
>>comprise the Action Model.
>>Ken: not sure but not drop dead.
>>
>>Still open is Joint Action.  Jeff: that at Participant level. 
>>Also, Joint Action vs. separate action but this not action in terms 
>>of Action Model at service level.
>></notes>
>>
>>-----------------------------------------------------------------------------
>>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
>
>
>
>
>
>
>I asked Danny to be a guinea pig before I sent this to the list 
>because I wasn't sure it would be understandable.  Danny is either 
>exceptionally perceptive, the notes make sense, or both.  Thus, I 
>have a 2 out of 3 chance this will be informative to the whole list.
>
>If there are major problems, Jeff will be happy to answer all questions ;-)
>
>Ken
>
>
>Begin forwarded message:
>
>>From: "Danny Thornton" 
>><<mailto:danny.thornton@scalablearchitectures.com>danny.thornton@scalablearchitectures.com>
>>Date: July 24, 2008 6:17:55 PM EDT
>>To: "Ken Laskey" <<mailto:klaskey@mitre.org>klaskey@mitre.org>
>>Cc: "Jeffrey A. Estefan" 
>><<mailto:jeffrey.a.estefan@jpl.nasa.gov>jeffrey.a.estefan@jpl.nasa.gov>
>>Subject: RE: [guinea pig] July 24 notes on Interaction, Action 
>>Model, and (Service) Action
>>
>>What you've described makes sense to me.  In the realization view 
>>we can discuss interaction via messages, but we should not limit 
>>the discussion to just messages in the ecosystem view.   My 
>>understanding of your summary below supports the ecosystem layer of 
>>participant/communicative exchange(action) down to the realization 
>>layer of service/message exchange.
>>
>>While the layered approach eliminates the confusion of an agent 
>>versus a participant, I think it will be confusing to start adding 
>>agent to the realization/owning section diagrams.   I still agree 
>>with Ken that we should have a section that comments on the 
>>assumption of the use of agents in the diagrams.  Unless someone 
>>can demonstrate how that can be done succesfully without causing 
>>confusion.
>>
>>Danny Thornton
>>
>>
>>
>>-------- Original Message --------
>>Subject: [guinea pig] July 24 notes on Interaction, Action Model, and
>>(Service) Action
>>From: Ken Laskey <<mailto:klaskey@mitre.org>klaskey@mitre.org>
>>Date: Thu, July 24, 2008 2:59 pm
>>To: Danny Thornton 
>><<mailto:danny.thornton@scalablearchitectures.com>danny.thornton@scalablearchitectures.com>
>>Cc: "Jeffrey A. Estefan" 
>><<mailto:jeffrey.a.estefan@jpl.nasa>jeffrey.a.estefan@jpl.nasa.gov>
>>
>>Danny,
>>
>>You may be wondering about the subject line.  The following are 
>>notes I made during a discussion Jeff and I had today.  Jeff 
>>suggested I distribute to the group but before I do that I wanted 
>>to check if it at all comprehensible by someone who was not part of 
>>the discussion.  So before I raise a firestorm of misunderstanding, 
>>I'd like you to see if it makes some sense to you.
>>
>>Thanks,
>>
>>Ken
>>
>><notes>
>>At Frank level (Service Ecosystem View), Joint Action between Participants.
>>
>>Realizing SOA View is more mechanical --> interacting with 
>>services, not between Participants
>>
>>Need relationship between Joint Action and Interaction at 
>>Participant level and then at the Service level
>>
>>Services are Agents, not Participants
>>
>>Both Agents and Participants capable of Actions, whether or not we 
>>define these as subtypes of Actor
>>
>>Can we keep things to the Participant level and the Service level?
>>
>>Jeff: Interaction is realized by message exchange
>>
>>From RM: Interaction as one or more message exchanges, each 
>>conforming to MEPs as described in service description
>>
>>From RM: Interacting with a service involves performing actions 
>>against the service.
>>
>>Ignoring Joint Action for the moment. For RA, at service level, 
>>interaction is set of message exchanges.
>>
>>Agreed: Interaction realized by (process of) message exchange AND 
>>composed of individual message exchanges (that may conform to 
>>different MEPs).
>>
>>Still question of unnamed bucket that contains more than one 
>>interaction and some private actions towards realizing RWE.
>>
>>RM: The action model of a service is the characterization of the 
>>actions that may be invoked against the service.
>>
>>Action in Action Model aligns with WSDL operation.  Action is what 
>>we want service to do and message is the means by which I tell 
>>service to do it.  The act of sending a message is part of 
>>interaction.  Frank: sending message is Action.
>>Jeff: qualify as Service Action? as all the actions (both public 
>>and private) that a service performs to achieve a RWE.  The public 
>>service actions correspond to the permissible actions a service can 
>>perform, i.e., service action exposed by the service and that 
>>comprise the Action Model.
>>Ken: not sure but not drop dead.
>>
>>Still open is Joint Action.  Jeff: that at Participant level. 
>> Also, Joint Action vs. separate action but this not action in 
>>terms of Action Model at service level.
>></notes>
>>
>>-----------------------------------------------------------------------------
>>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
>
>
>
>
>
>
>Attachment converted: Macintosh HD:smime 859.p7s (    /    ) (00A049C8)


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


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