9:15 p.m.
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(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org