On Jan 1, 2009, at 8:18 PM, Gavin King wrote:
I certainly don't want to do anything that's incomplete. But
to believe that we can create something fairly complete here, since we
are simply providing a facade over something that is *already* very
See below for some more details about JMS. I like @Asynchronous in
the EJB spec, and if you reread it, it's completely defined without
any JMS reference. That kind of definition is complete and well
defined. Copying @Asynchronous it for WebBeans would be fine. JMS
under WebBeans is not fine.
> If we want to support distributed event processing, we have two
(1) define, from scratch, all the various event-processing semantics
like QoS, 1ofN/NofN, routing, transactionality, routing, etc.
(2) simply leverage JMS, which already defines all those things.
No, JMS does not define those things. Most importantly in this
context, JMS does not define routing at all. That's left as an
Since the WebBeans event bus is all about routing (i.e. finding an
observer for an event), there's a mismatch between the abstraction of
the two specs. JMS doesn't address that problem at all. (I'm not
criticizing JMS for this. It's not what JMS is designed for.)
The reality is that we are *never* going to do (1). Web Beans is
going to grow into a spec that defines an async messaging system.
I assume you mean async distributed messaging system. I'd certainly
agree with that.
As you pointed out, an async local messaging system is essentially the
EJB @Asynchronous, which would be fine.
Forget it. For one thing, it would wind up competing with JMS, or
would at least be perceived to compete with JMS by other people. Not
So, if we are going to have support for distributed event processing,
we are going to have to utilize a technology that pre-exists. The only
available candidate is JMS, and I think the mapping is really quite
I would *much* rather see the spec define a standard mapping from
Beans events to JMS, leaving open the possibility of other,
proprietary mappings to proprietary messaging technologies than have
the whole event bus removed from the spec due to the objection that
I think this will explain the problem.
A WebBeans event is a <object,binding> pair. The object maps
trivially to the JMS ObjectMessage, but the binding maps to nothing
natural in JMS. Remember, destinations (topics/queues) in JMS are
opaque from the spec's point of view. Any structure is implementation-
From WebBeans to JMS, someone can easily write an @Observer bridge to
route the object to the proper queue or topic (based on @BindingType
of the @Observer), but there's no way WebBeans can possibly define
that mapping itself because JMS doesn't provide enough detail to map
bindings to queues/topics, and it would be inappropriate for WebBeans
to impose extra detail on top of JMS.
From JMS to WebBeans, someone could write a message-driven bean (or
equivalent), to forward JMS objects to WebBeans events, and they could
add appropriate @BindingType to the fireEvent. WebBeans could define
a specialized message-driven bean for this purpose, but that would
effectively pull in MDB logic into the WebBeans spec. And given XA
(and pooling, etc), that logic is not trivial.
WebBeans defines a nice local event bus, and someone can write a
bridges nicely with JMS, but extending WebBeans to a distributed bus
is not at all as simple as bolting on JMS.
> Besides, JMS is designed as a facade around a real messaging
> system. It's
> not really suitable for low-level messaging.
I don't understand the difference between "real" messaging and
"low-level" messaging. There are plenty of lightweight, pure-Java
implementations of JMS.
"real" meaning concrete, as opposed to abstract (not "real" vs
"low-level" meaning basic queuing of objects/requests (like EJB
@Asynchronous), not high-level facades like the Message API.
For example, any messaging implementation needs to have a routing
architecture. A low-level specification messaging (like Jabber/XMPP
or SMTP) defines things like addressing/routing. WebBeans defines
routing. JMS does not, i.e. JMS is a facade around a concrete
Actually, what I was thinking is something *exactly* like the
semantics of @Asynchronous, @Timeout or of message-driven beans. The
EJB spec already gives us a good definition of what an "asynchronous"
listener is, which we can simply copy/paste :-)
Sure. Of course, I'd like all aspects defined in either spec to apply
to any components in any spec.
> 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.
I mean the Web Beans contexts like the request context, etc.
> Creating this kind of bridge would be fairly straightforward, but
> doesn't belong in the spec. (At least this version.)
OK, but what I'm hearing from other people is that if Web Beans
*doesn't* have this functionality in this version, then it should not
have *any* event functionality in this version.
It's a decent argument. There's certainly a strong need for
distributed events. I think the local events are a much more
specialized application, and I'm not sure how valuable they are.
While I don't completely agree with this, I do think they have a
very strong point
in that the event functionality is fundamentally incomplete if the
event processing doesn't work in a clustered or tiered deployment.
The WebBeans events are not suitable for a distributed event system in
the current state, and adding JMS does not solve the underlying
problem. So, if the event system isn't useful for local-only
applications, I'd have to say it should be put off.
Now, a spec that used the WebBeans ideas to solve the distributed
event problem would be a very interesting spec, but way out of scope
for this group.
So at this point we are effectively left with a choice between:
(1) Do distributed events
(2) Drop events entirely from the spec.
Given only those two choices, I'd have to recommend #2.
And then start a new JSR to solve #1, possibly using many of the
concepts already developed in the draft.
> If an application wanted to handle its own queuing rather than
> container-managed queuing, it would want a "synchronous" observer.
> 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
It's not difficult for guys like you and me, but it *is* the kind of
thing that is difficult for many developers.
Certainly. I was thinking in terms of a specification/implementation
layered on top of WebBeans.
> (5) Finally, since JMS is a transactional medium, we could support a
> further setting which writes the event transactionally to the queue/
> However, this setting needs to be a global setting for the event
> Perhaps an @Transactional annotation for the event type?
> If fireEvent() becomes transactional, wouldn't that logically imply
> that it
> could rollback?
Um, no, that's not what I meant at all. What I'm referring to is the
notion of persistent messages (DeliveryMode.PERSISTENT).
See the "transacted send" concept in the EJB 3.1 draft (4.4.2).
Logically, the concept would apply to the fireEvent() call.
Persistent messages is really a QoS thing, not really transactional
(although of course the implementation details are intertwined.)
(For topics, durable subscribers may also come into this.)
> 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.
No, I definitely don't want to define anything new here, since it is
already defined by JMS. All I'm trying to do is map notions that
already exist in JMS back up into the Web Beans APIs.