[webbeans-dev] Re: Distributed event channels

OK, after thinking this through over the last couple of days I've come to the conclusion that we can live with something slightly less general. The usecase for this stuff is really state synchronization and therefore N-of-N semantics is the only thing that makes sense, and supporting guaranteed delivery sounds to me like total overkill.

Of course, if you guys think it's important, it's not hard add support for 1-of-N semantics and for persistent (guaranteed) events, but I really don't think it's something we need to do in 1.0. So the attached draft adds: * asynchronous event observers * topic mapped events * a definition of the tx, security and web beans contexts for all kinds of observers Take a look at 8.5.7-8.5.9 and 8.8, and let me know if you think something is missing or wrong. Thanks! On Sun, Dec 21, 2008 at 6:51 PM, Gavin King <gavin(a)hibernate.org&gt; 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(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org <Web Beans 20090116.pdf>