There's a fifth that I missed.
5. Support a criteria builder style for message selectors. If we abstract
JPA's criteria builder to separate the where clause of a query into the
selector style, We'd end up annotating POJO's to use a typesafe value via a
metamodel style precompiler.
Some more comments embedded.
On Tue, Jun 21, 2011 at 11:09 AM, Clebert Suconic <clebert.suconic_at_gmail.com
> wrote:
> 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).
>
I don't disagree, there are performance enhnacements. However, for a very
simple message we should be able to just wrap the message (e.g. no
properties) within the API.
> >
> > 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)
>
>
I know. My recommendation here is along the lines of EJB 3.1 and JPA 1.0's
capabilities to start up on their own in a standard way. In general, I
think this makes integration across application servers much easier. This
could allow an MDB-replacement to be deployed when the container starts.
>
> >
> > 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
>