[webbeans-dev] Re: Distributed event channels

[Scott Ferguson]

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

Some details on the points below:

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

Creating this kind of bridge would be fairly straightforward, but  
really doesn't belong in the spec.  (At least this version.)

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

For a future spec, these ideas are concepts that can be added, but  
creating a queuing/threading model that's also transactionally aware  
this late in the process is just not a good idea.

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.

-- Scott

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090101/bfcea2ca/attachment.html