Pete,
I think messaging systems provide much more than just load-balanced ipc, which you can get with remote EJB calls just as well. Messages are in addition persisted and transactional, i.e. the state change you do on the sender side are guaranteed to be atomic with the sending of the message... no duplicates and no missed messages. The same is true for the receiver side.
This is (currently) not true for CDI events, even when they are delivered after commit, if the delivery or the receiver fails, the message is lost. So it may be feasible to use JMS to route even intra-VM events.
I have experienced that designing your software in such an event-based style often leads to inverting the semantic coupling between the sender and the receiver. When you have an event, the sender doesn't care about the state of the receiver, it just fires and the receiver has to generally know about the state that the event was fired in. When you have a command OTOH, the sender assumes that the receiver is in a state valid for executing the command... the sender is coupled to the receiver. Mixing these two is IMHO dangerous.
That's why I prefer to hide JMS command messages behind a method call that returns void. The semantics are admittedly quite different from a synchronous method call, as it just generates the JMS message, but to me this approach seems rather helpful. This can be automated with the MessageApi project that I'm trying to promote.
I recently added the binding of CDI events as well, so event messages also have a more natural fit. It's only in the trunk and I haven't yet found the time to promote it, but it works just fine.
Rüdiger
On 06.12.2011, at 10:30, Pete Muir wrote:
> A message from Jurgen on this topic.
>
> AIUI his primary concern is be able to switch from intra-VM -> interVM and vs versa observer/observable pattern without adjusting his business code, simply through configuration. I would tend to agree with him, this is one reason why John, Gavin and I were interested in developing the JMS backend for the CDI event bus.
>
> Begin forwarded message:
>
>> From: Jürgen Krey <juergenkrey_at_yahoo.de>
>> Subject: Re: [jms-spec users] [jsr343-experts] Re: Slides from Devoxx 2011
>> Date: 6 December 2011 09:03:05 GMT
>> To: Pete Muir <pmuir_at_bleepbleep.org.uk>
>>
>> Hi Pete,
>>
>> sorry for answering so/too late - due to a stressful client and
>> two lessons I'm preparing.
>>
>> Well, my main point was
>> to be able to transparently leverage the intra-VM @Observer model
>> to some kind of ipc-based event-/message-passing only by configuration.
>>
>> Yes throttling may be one aspect of ipc to load-balance workload.
>>
>> A perfect solution for me includes the ability to switch from intra-vm communication
>> to ipc (via jms/ampq) during operation by simply add extra VMs and
>> re-route the events to additional (external) processors.
>>
>> Of course this requires the application to be desgined in a event-based style - which is quite
>> different from a rather functional / imperative style. The ideas and principles are
>> published as EDA/SEDA architectures...
>>
>> best regards
>> Juergen
>>
>> ps: what is the EG observers list?
>>
>>
>>
>> Am 02.12.2011 13:15, schrieb Pete Muir:
>>> Jurgen, could you comment?
>>>
>>> If you don't want to join the EG observers list, I can forward your reply for you!
>>>
>>> On 25 Nov 2011, at 17:28, Nigel Deakin wrote:
>>>
>>>> On 24/11/2011 08:27, Pete Muir wrote:
>>>>> On 24 November 2011 00:31, John D. Ament<john.d.ament_at_gmail.com> wrote:
>>>>>
>>>>>>> * It should be possible to build modular applications in a Java EE
>>>>>>> environment which use JMS to distribute work from one module to another.
>>>>>>> SEDA-style, perhaps. (This was mentioned at the Java EE BOF)
>>>>>>>
>>>>>> If you look at my old email regarding integrating CDI's event model, this
>>>>>> would be one of the capabilities.
>>>>> I chatted to Jurgen, who made this request, after the BOF, and
>>>>> suggested he look at this support in Seam JMS as it sound like exactly
>>>>> what he was after :-)
>>>> He also asked for some kind of "throttling" mechanism (his word) to control the rate at which work was delivered from one component to another. JMS doesn't define throttling or flow control, of course, but it's the kind of thing that JMS might cover in the future.
>>>>
>>>> It wasn't clear to me what was stopping existing JMS support in Java EE being sufficient for his purposes. Was he looking for more control over the flow of messages (flow control, throttling, load balancing etc) or was he simply looking for a different API? (Jurgen is welcome to join this discussion).
>>>>
>>>> Nigel
>>>
>