5:18 a.m.
On Fri, Jan 2, 2009 at 2:15 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
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.
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).
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.)
Well, it's not a hard dependency. The event functionality works w/o
JMS, but if you
(a) happen to have a JMS provider, and
(b) *want* to map the events to distribution via JMS, you can.
I believe that the target environment (the EE Web Profile) requires
support for the JMS client libraries, so the APIs that the web beans
implementation would be interacting with are already there.
Nothing stops anyone from implementing alternative (non-JMS)
distribution technologies, and, indeed, I believe that the APIs we'll
define here (e.g. @Asynchronous) will be just as relevant for other
distribution technologies.
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.
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.
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.
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
gunna happen.
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
natural.
I would *much* rather see the spec define a standard mapping from Web
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
it's incomplete.
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.
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.
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 :-)
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.
I mean the Web Beans contexts like the request context, etc.
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.
Yes, correct, it's basically a simple facade over JMS, making JMS
*much* easier to use for the special case of event processing inside a
single application. Currently the JMS APIs are utterly inappropriate
for this usecase, and EE offers no other alternative solution.
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. 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.
So at this point we are effectively left with a choice between:
(1) Do distributed events
(2) Drop events entirely from the spec.
(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.)
It's not difficult for guys like you and me, but it *is* the kind of
thing that is difficult for many developers.
(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?
Um, no, that's not what I meant at all. What I'm referring to is the
notion of persistent messages (DeliveryMode.PERSISTENT).
(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.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org