Skip to main content

[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

Hi,

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

* 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 
3a?

* 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 
mention it.

* 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 
related?

* 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!!!

Rüdiger

[jsr343-experts] JMS 2.0 Event Messaging

Nigel Deakin 08/17/2011

[jsr343-experts] Re: JMS 2.0 Event Messaging

Rüdiger zu Dohna 08/28/2011

[jsr343-experts] Re: JMS 2.0 Event Messaging

John D. Ament 08/30/2011
 
 
Close
loading
Please Confirm
Close