[jsr343-experts] Re: JMS 2.0 Event Messaging
- From: Rüdiger zu Dohna <ruediger.dohna@...>
- To: "jsr343-experts@..." <jsr343-experts@...>
- Subject: [jsr343-experts] Re: JMS 2.0 Event Messaging
- Date: Sun, 28 Aug 2011 22:52:22 +0200
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
sorry for taking so long to reply... I was on vacation with the family, i.e.
offline for two weeks.
Nigels comments on the AtInject proposal seem quite comprehensive and
detailled, while the Event Messaging proposal goes quite uncommented, yet, so
I'll concentrate on that. CDI event binding is obviously a viable solution
and seems to have support in the EG. As I've stated before, I'd prefer to
instead bind to a business interface, but I'll leave that discussion to a
separate thread. Here are my suggestions to improve the current proposal, in
no particular order:
* ObjectMessages seem an obvious choice, but I think that they are not a good
default. Asynchronous messages are very different from synchronous calls,
also in that there may be intermediate instances that need to read them,
namely tools to debug e.g. error queues, or content based routers. With
ObjectMessages containing application specific classes, these tools require
the proper class files of the message objects being sent. But it's often not
feasible to share with them all versions of all message objects; so it seems
to me to be a better default to use generic message formats, like xml or
* How are the qualifiers mentioned as Annotation in the code examples on
page 5 transported from the sender to the receiver?
* I think it's worth to mention that it's a required change to allow
MessageListeners in an EE environment.
* Defining all defaults, e.g. the default factory attribute of the
JmsConnection annotation, would improve portability, wouldn't it? The spec
doesn't have to define the exact value in this case, but the exact semantics
should be set, shouldn't it?
* I think that it would be more consistent with the EJB behavior of
automatically managing transactions, if the default of the
JmsConnection#transacted attribute were true.
* Maybe it would be easier and suffice if "transacted" were not a separate
attribute but a fourth acknowledge mode (as I understand it, this is what
Nigel suggests in JMS_SPEC-45).
* The JmsCredentials annotation (used literal as well as plain) is not really
an improvement over the current security situation of JMS client code. But
the only real solution that I can think of may be out of scope, as it's a
general EE issue: Every application has some identity and required privileges
to e.g. send messages to some queue. The deployer checks this identity and
grants it the requested privileges. So the developer only defines what the
application needs, while the deployer checks and fulfills these needs.
* Page 4, 2nd client guarantee, 2nd sentence is unclear to me... and what's
* Page 4 (and later on): The MessageObject type irritates me. Isn't it meant
to be the StatusIdMessage used before?
* Page 4, SomeQueueLiteral: If it's a singleton, the constructor should be
public... and as it may be serialized it would be better to use a
one-value-enum (cf. Effective Java). If it's not a singleton, you'd need
equals and hashCode, so it's a proper value object. Don't have to code it but
* Page 5, 2nd (non-code) sentence (and last code snippet and paragraph on the
same page): The property name is not "someProperty" but "eventType", isn't it?
* Page 5, 2nd "contract" bullet point: Do you really suggest that messages
that can't be converted for some reason be dropped with only an optional
waring in some logs?!?
* Page 5, last paragraph, 2nd to last sentence: I just don't get it. Why is
the message selector supposed to be an interceptor? How it it supposed to do
the routing, if there are multiple message selectors? How is transactionality
* Page 6-8, API Changes: I'd prefer to read (eventually commented) code for
all annotations and enumerations.
And I really like the improvement over the 1.1 spec!!!