On Jan 1, 2009, at 6:30 PM, Gavin King wrote:

I have not yet heard *any* feedback from the group on this issue.

I'm not sure this is a wise extension to make in this version. It's fairly simple to create a bridge from WebBeans events to JMS, and to write an EJB message bean as a bridge from JMS to Web Beans. That's probably not the long term solution, but I'd think it would be better to put off a more complete proposal until after this version.

For one thing, I'm not convinced it's a good idea to tie the WebBeans spec directly with JMS at all. The two should be orthogonal, so they'll work together but not have any dependencies. (I've never liked the explicit tie with EJB either, and would prefer for that dependency to be hidden behind a EjbBean extends Bean implementation, not in this spec.)

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

Introducing that dependency on JMS is a terrible idea. There's no intrinsic reason for WebBeans to be dependent on JMS. It's like the EJB dependence on CORBA, or JAX-RPC (or JAX-WS). Unnecessary, complicating implementations, and freezing up the spec for all future revisions.

Besides, JMS is designed as a facade around a real messaging system. It's not really suitable for low-level messaging.

What I'm thinking is the following:

(1) Event observers may specify that they receive events asynchronously:

Do you mean introducing a queuing system and threading into the event system? Like the EJB @Asynchronous? That opens up a whole mess of issues, and just saying "JMS will solve it" is the wrong answer entirely.

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.

Do you mean classloader context? Or some other context? Presumably WebBeans could define that a fireEvent() call always dispatches events in the manager's classloader context. That would be the most logical. The same context rule could be applied to the getInstance() methods of Manager.

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

This is essentially implementing a message-driven bean as a bridge and defining a particular JMS message syntax, which goes well beyond what WebBeans really should be involved in.

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

If an application wanted to handle its own queuing rather than container-managed queuing, it would want a "synchronous" observer. (Which is kind of the point. It's already straightforward to design this kind of system on top of the web beans API, which would be a cleaner, more layered design.)

(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?

If fireEvent() becomes transactional, wouldn't that logically imply that it could rollback? It's an example of the kinds of issues that would need to be resolved if this idea goes forward. Logically, you'd be creating a transactional messaging/queueing model inside WebBeans, so would need to specify all the relevant behavior.

If the fireEvent is synchronous (in the sense of the same thread calling @Observes), then anyone can build a clean, transactional queuing model on top of it, without introducing a dependency on the Web Beans spec at all. Just write the appropriate bridges. For now, that would be the far preferable approach.