On Tue, Jun 21, 2011 at 8:52 AM, John D. Ament <john.d.ament_at_gmail.com> wrote:
> Hello all, I finally made it to the EG! Most of my experience comes from
> the consulting realm, so I often times see what it is like for a client to
> deploy JMS as a messaging infrastructure.
>
> 1. CDI Integration
> I'm responsible today for a simple library for supporting JMS in CDI 1.0
> applications. In my opinion, it should be a core capability. This would
> include support for event management over JMS (firing CDI events results in
> messages being sent). In addition, JMS messages should be able to be
> forwarded and handled as observer methods.
> Being able to inject resources also seems very useful; allowing for a
> cleaner API to send messages to destinations that can be injected (ala
> @Inject @New Session session; )
>
> 2. Simplified APIs
> Today JMS requires a true javax.jms.Message instance to work against. For
> some reason, creating Message objects requires a session. It would be
> easier if you can just fire Serializables, byte[]s, Strings, etc. Obviously
> this wouldn't allow for setting properties, reply to's, etc so there is
> trade off. Maybe also providing a map of <String,Object> as parameters
> would be useful in the payload?
> It would be ideal to move away from needing to look up destinations and
> simply telling the API "send this data to this destination."
The fact that you use session.createMessage() is also because the
Session will know how to instantiate the message. You could maybe have
another method to instantiate messages somewhere else on the API?
Besides most provider will have optimizations on session.createMessage
to enable performance on sending the message. (creating proper
buffers,, ,etc).
>
> 3. Bootstrapping/Configuration
> It should be possible to bootstrap a JMS Container the same way you can
> bootstrap EJB in 3.1 and the proposed CDI 1.1 capability. I think doing
> something like javax.jms.spi.JMSContainer.startup() (with parameters for a
> config file, a config object, or similar) would make the most sense. Java
> SE 6's service providers are very powerful. In addition, it should be
> possible that if JMSContainer.startup returns a JMSContainer instance, then
> that also provides lookup capabilities for any destination provided,
> assuming that destinations still need to be looked up.
There's no such thing as JMS Container. Messaging systems are usually
message brokers.
Although it would be nice to have a support for a standalone message
system. (I'm not sure I would call it container)
>
> 4. MDB replacement
> Conceptually, I like MDBs for their built in transaction capabilities.
> However, an MDB should be able to run across multiple destinations; and
> should be able to operate independent of whether it is a queue or a topic.
> This ties in to my CDI capabilities, where MDBs could simply be reduced down
> to a CDI observer. A single class, supporting multiple observers within the
> same or different methods would allow for a lot more code reuse (as
> potentially the message could be intercepted by any old POJO or EJB and have
> direct access to the actual bean). One area of strong consistency is the
> "mappedName" attribute, where in some containers it is allowed to be a JNDI
> location of a destination that this MDB is bound to.
+1