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

[Jim Marino <jim.marino@gmail.com>]

Hi Tim,

Comments inline.

Thanks,
Jim

On Sep 1, 2009, at 2:24 PM, Tim Gleason wrote:

>>
>> 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.

My strawman proposal meets this requirement. As an aside, I don't  
think "fire and forget" is an attribute which distinguishes  
"invocations" from "events." Specifically, non-blocking invocations  
have this same behavior.

> 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.
>

This is also true of the JMS binding as well as references in general.

> 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.
>
That is also the case with the JMS binding as well as WS-RM and just  
about any other reliable message-oriented protocol.

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

Invocations should promote loose coupling as well when they are inter- 
process.

> 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.
>

Eventing and invocations may be different but I'm not sure the  
attributes you outlined above are what distinguishes them. I agree it  
is important not to conflate concepts. However, there is the opposite  
danger of over-specialization. That is, missing out on an opportunity  
to use a general concept by substituting a number of special cases.  
This leads to unwarranted complexity. For example, SCA came about as a  
way to generalize and simplify distributed systems, something existing  
technologies such as Java EE made overly complex for most use-cases  
through specialization of APIs (e.g. EJB, JMS, JAX-WS, RMI, etc.).

Jim

> Thanks,
> tim
>
>
>
>