RE: [sca-assembly] Pointer to SCA event processing presentation

["Tim Gleason" <tim.gleason@oracle.com>]

> 
> So far it seems to me that this can be handled by services,
> references, and bindings. I may be wrong in the end, but it seems
> worthwhile to start from that premise given the additional complexity
> the eventing proposal introduces.
> 
> Jim
> 

[[TMG]] 
Eventing and invocation differ in a couple of important aspects:

1) For the publisher, events are "fire and forget".  Once the event is
fired, the publisher is not affected in any way by downstream processing.
For example, if a subscriber throws an exception, the publisher never knows.
The two are isolated from a runtime level and a transaction level.

2) Events are one-to-many.  A single event can have from zero to infinite
subscribers.  

3) Events have different QOS guarantees.  Since events are "stored and
forwarded", they have different levels of QOS -- those that are typical for
eventing: at-least-once, at-most-once, exactly-once.  The implementation of
this style of messaging is significantly different than invocations.

4) Philosophically, events should promote "loose coupling" of applications.
To me, events are to scripting as invocations are to strongly typed
languages.  

On a very "surface" level, events look similar to invocations.  But
philosophically and semantically, they are quite different.  Once could
argue that if two things "look" similar that they should share an
implementation.  In my opinion, when you try to share the implementation of
two things that "look" the same, you end up boxing yourself into a corner.
As the two things evolve, they may naturally move in different directions.
By keeping the implementations separate, they are allowed to naturally grow
in their own direction.

Thanks,
tim