Hi all,
most people on the EG seem to like the idea of using CDI events to bind
to JMS. I like that idea, too, as I love CDI, but there may be reasons
to use JMS without even that container. Namely starting the CDI context
takes a noticeable amount of time, and this may be too much for some use
cases.
I also prefer to have a verb for messages, not only a message object.
I.e. I prefer
createCustomer("Joe", "Doe")
to
event.fire(new CreateCustomer("Joe", "Doe"))
This feels more natural to me. I think the only differences between a
JMS and an EJB call should be that JMS is always and completely
asynchronous, i.e.
1) JMS methods return void and don't declare any Exceptions,
2) transactions are only local,
3) for the sender no business logic runs directly in the method call, and
4) for the receiver no business logic runs directly outside of the
method call.
For more details, please take a look at
https://messageapi.java.net
And I don't think that we should force all JMS implementations to run
outside of "their" environment, e.g. in plain vanilla Java SE. If we
instead would make sure that all JMS client code really runs without any
modification in any JMS implementation, that would be a *big* win. If
the JMS implementations specify the exact environment they need, clients
would be free to choose and change their minds at any time.
Regards
Rüdiger