[webbeans-dev] Re: Distributed event channels

[Scott Ferguson]

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.

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

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

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

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

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

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

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

Gotcha.

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

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

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

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

-- Scott

> (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 at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
>