4:06 a.m.
On Fri, Jan 2, 2009 at 5:40 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
On Jan 1, 2009, at 8:18 PM, Gavin King wrote:
> I certainly don't want to do anything that's incomplete. But I happen
> to believe that we can create something fairly complete here, since we
> are simply providing a facade over something that is *already* very
> complete (JMS).
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.
@Asynchronous methods in EJB do not support stuff like persistency,
logical channels, N-of-N vs 1-of-N semantics, etc. It's not
semantically sufficient for what we need here.
>> If we want to support distributed event processing, we have
two choices:
>
> (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 implementation detail.
It does not define routing but it does define the notion of logical
channels, which is what you need if you want to do routing. It
certainly does define certain QoS semantics (e.g. persistent messages
and transactional sessions), and 1-of-N vs N-of-N (queues vs. topics).
i.e. exactly the things we need :-)
> The reality is that we are *never* going to do (1). Web Beans is
never
> 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.
Yeah, more or less. It's a *much* simpler 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-dependent.
I don't understand what you are saying here. I don't agree that there
is no natural mapping from event type/bindings to JMS.
* Event type -> JMS channel (topic/queue), and
* event binding -> JMS message property
is very natural to me. Then the observed event bindings can be
expressed as a message selector :-)
Note that we don't have to define in detail exactly how event bindings
map to message properties, since from the point of view of the
application, this is an implementation detail.
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.
I just don't see the problem here. Why can the user not specify that
event type X is distributed on topic T declaratively?
From the user point of view, that is a hell of a lot easier than
having to write code in an observer method to wrap the event up in an
ObjectMessage and put it on the topic, and then a message driven bean
that unwraps the event and calls fireEvent().
All we are doing is providing a mechanism to do declaratively exactly
what the user would have to write code to do.
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.
It doesn't pull in MDB stuff at all. Exactly how the Web Beans
implementation implements this stuff is none of our business.
Serioulsy, dude, specifying this stuff is not difficult, because it
can all be expressed in terms of concepts that exist in JMS, without
needing to pull in anything about MDBs, etc.
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.
I believe it *is* that simple :-)
Perhaps nobody will believe me unless I actually start writing this
stuff up in more detail :)
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 architecture.
Hrm, I'm really not sure I agree with that. JMS defines things like
topics/queues, and a whole expression language (message selectors)
that is MUCH more powerful than web beans binding types.
>> Creating this kind of bridge would be fairly straightforward,
but really
>> 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.
So this is something that we seem to more or less have consensus on :-)
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.
In the current state, no. Certain semantics are totally wrong for
distributed events, namely:
* synchronicity
* context propagation
However, this semantic mismatch can be solved via introduction of the
@Asynchronous observer.
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.
It is and remains my very strong view that unless we provide a very
easy-to-use mechanism that allows state synchronization between
stateful components to occur as part of the transaction completion
lifecycle, then actual web beans applications are going to be riddled
with bugs. They are going to break the minute a transaction rollback
occurs. Many Java EE applications already have this kind of bug, since
it is difficult to code for, and even more difficult to test for.
Since Web Beans encourages stateful components, these bugs will become
even more common!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org