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] Interacting w/Services Model Updated (a start on EDA & event-driven SOA)


Michael
  You have misunderstood the connection that we looked at before here.

  An event cannot cause anything. Least of all an action.

  By definition, an event is a report f something that has happened  
that is of interest to someone.

  An action is the application of intent (I personally prefer the  
term force over intent, but that riases more potential for  
misunderstanding) on a target to achieve an effect.

  Actions may (but then again may not if the action was unsuccessful)  
give rise to events. An event may be interpreted by an agent as a  
reason for initiating actions.

  Messages may be used to denote events and actions. More accurately:

We use message exchange as the realization of communication of  
actions and events.

  More accurately still, following from Herbert Clark's notion of  
joint action:

Participants send and receive messages (which are inherently  
individual actions) in order to participate in joint actions (the  
exchange of a message, the performance of an action, the reporting of  
an event).

In our architecture, actions and events are both realized via message  
exchange. A message may be used to denote an action and/or an event.

Frank

On Mar 18, 2007, at 3:13 PM, michael.poulin@uk.fid-intl.com wrote:

> Replying to the Jeff's question about relationship between Event  
> and Action, let me suggest that an Event can cause an Action  
> directly or indirectly; plus, in some cases, one Action might be  
> not enough to cause particular Action. All this looks complex.
>
> Would it be easier to define that an Event can relate to the Action  
> via a Message? On the UML diagram, the 'denote' relationships might  
> be bi-directional... In other words, I propose using following UML  
> construct here:
>
>       :EVENT  ------x-------->  :ACTION
>                     !
>                     !
>                     !
>                     !
>                  :MESSAGE
> - Michael
>
>



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