[webbeans-dev] Re: Distributed event channels

[Gavin King]

Blogged here:

http://in.relation.to/Bloggers/DistributedEventsForWebBeans

On Sun, Dec 21, 2008 at 6:51 PM, Gavin King <gavin at hibernate.org> wrote:
> IBM has raised the issue of event processing in a distributed
> environment, and we (Red Hat) have promised to address this issue in
> the revised public draft.
>
> The Web Beans event bus provides a very nice way for stateful
> components to synchronize their state (transactionally) with changes
> that take place in the application. Event processing is *much* more
> important in an environment with stateful object such as SFSBs than it
> is in an environment with only stateless objects such as SLSBs or
> Spring beans. Furthermore, event processing must be aware of the
> transaction completion lifecycle (many applications today have bugs
> when transaction rollbacks occur). Therefore, I believe that event
> processing is an essential feature of Web Beans.
>
> However, the event bus we have today is a purely local construct and
> does not help when the application is distributed across multiple
> cluster nodes or multiple physical tiers.
>
> Designing a distributed event bus would potentially be a very
> difficult undertaking, with so many issues to think about: QoS,
> asynchronicity, transactionality, routing, etc. Fortunately, JMS
> already has the features we need, and is what is sometimes used today
> to solve the problems we're talking about:
>
> * asynchronous, distributed semantics
> * a notion of both 1-of-N and N-of-N semantics (queues and topics)
> * a notion of logical channels (to allow routing of events between
> tiers and applications)
> * support for a range of QoS semantics
> * transactionality
>
> Furthermore, JMS is well-understood and well-supported.
>
> If the spec simply defines that events were distributed via JMS,
> absolutely nothing would stop vendors from also supporting alternative
> distribution mechanisms as proprietary extensions (for example, in
> JBoss we could provide support for JGroups).
>
> And when EE finally gets a WorkManager API, a future version of Web
> Beans could also define that distribution of local asynchronous events
> is via the WorkManager.
>
> The application developer would not be exposed to the JMS APIs. The
> actual interaction with JMS would be handled by the container. All the
> developer would need to do is specify that events with a specific type
> and binding types would be distributed by a certain queue or topic.
> (web-beans.xml would be the right place to specify this mapping.)
>
> What I'm thinking is the following:
>
> (1) Event observers may specify that they receive events asynchronously:
>
>       void invalidateCache(@Observes @Asynchronously @Created Product
> product) { ... }
>
>   or even:
>
>       void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
> product) { ... }
>
> By default, an asynchronous observer is a purely local construct.
> However, unlike synchronous observers, an asynchronous observer is
> called in a different set of web beans contexts to the contexts in
> which the event was fired.
>
> (2) A topic or queue declaration may specify a set of events which are
> distributed via that queue/topic:
>
>       <Topic>
>           <destination>java:comp/env/jms/CacheInvalidationEvents</destination>
>           <connectionFactory>java:comp/env/jms/TopicConnectionFactory</connectionFactory>
>           <events>
>               <myapp:Product>
>                   <myapp:Created/>
>               </myapp:Product>
>           </events>
>       </Topic>
>
> This declaration means that any event that is "assignable" to the
> specified type and binding types is a distributed event, distributed
> by the named JMS topic.
>
> (3) The Web Bean manager would validate that all observers for any
> event distributed via JMS are declared to be asynchronous observers,
> and throw an exception if there are any synchronous observers for the
> event.
>
> (4) We need to think carefully about the concept of an asynchronous
> transaction completion event observer. The following combinations are
> semantically correct, and need to be supported, even for the distributed
> case:
>
>       @Observes @Asynchronously @AfterTransactionCompletion
>       @Observes @Asynchronously @AfterTransactionSuccess
>       @Observes @Asynchronously @AfterTransactionFailue
>
>  However, this combination is not meaningful:
>
>        @Observes @Asynchronously @BeforeTransactionCompletion
>
> (5) Finally, since JMS is a transactional medium, we could support a
> further setting which writes the event transactionally to the queue/topic.
> However, this setting needs to be a global setting for the event type.
> Perhaps an @Transactional annotation for the event type?
>
> WDYT?
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org