[Springframework-developer] Re: new jms development, request for comments.

[Rod J. <rod...@in...>]

Some thoughts--and I've copied this to the dev list.

----- Original Message -----
From: "Mark Pollack"
Sent: Friday, April 09, 2004 6:00 PM
Subject: new jms development, request for comments.


> Hi everyone,
>
>
> I wanted to get some feedback on the spring JMS support I was planning to
> implement and put in the sandbox.  If you feel this should get send to the
> dev mailing list just let me know. It is a long emai....
>
> At the high level send and recieve functionality are handled seprately, as
> they are currently in the sandbox code.  This makes sence especially in
> the case of J2EE usage since all J2EE users are interested in doing in
> client code is sending since the container creates the receiving
> infrastructure.
>
> JmsTemplate
> -----------
>
> I was thinking that the JmsTemplate class/classes should be changed to an
> interface.
+1.

>The main motivation for this right now is because of the
> changes between JMS 1.0.2 and 1.1. Not only has the api changed, which in
> itself maybe isn't so important, but the new API adds news functionality
> such as the ability to mix sending on topics and queues using the same
> session and within the same transaction.  Other reasons relate to more
> advanced usage of how we might handle session management - more on that
> later.
>
> I was also thinking of a name change, to JmsSender or JmsProducer, to have
> commonality with the existing spring mail package and it seems to express
> better what functionality the class offers.  This interface would offer
> methods much like those in the JMS 1.1 MessageProducer interface, various
> send methods and also provide methods for use with a MessageCreator and
> do perform a sync request/reply.  The reason a Destination object should
> be in the signatures is in the case of sending to a destination defined in
> an incoming messages Message.getJMSReplyTo() It will also be possible to
> send to a destination specifying the jndi string of the destinaton,
> proably the most common usage.  There should also be some accomdation to
> allow transactional sending of multiple messages.
I like JmsSender.
>

> MDB Helper Classes
> ------------------
> The most basic of which would make it easy to get at the spring app
context.
There is an existing superclass for MDBs in the ejb.support package. Might
be best to improve that if necessary, or add a new subclass with whatever
extra functionality you want. It allows access to the context.

I guess there are 2 cases we need to support for message consumers: making
MDBs easier to use (via easy access to IoC etc.) and providing some level of
convenient JMS consumption ability without EJB.


> Connection and Session management.
> ----------------------------------
> Just like in the case of jdbc, you really don't want to actually create
> and close a connection for each send operation, so a JMS connection pool
> is necessary.  One straightforward way to do this is to provide
> implementations of the ConnectionFactory interface that perform the
> pooling, much like how connection pooling is done is jdbc using the
> Datasource interface.
> There is definetly value for us to provide implementations of the
> ConnectionFactory that will perform connection/session pooling for any
> vendors JMS impl.  The Weblogic JMS impl provides JMS connections/session
> pooling features as do others.  However, some don't and support varies in
> the details.  I need to look into this more.
So long as we don't make it hard to use efficient application server pooling
I think having our own ConnectionFactory implementations makes sense.

> Session pooling is more significantly more complicated and I need to look
> into it more. Unlike JDBC, JMS connections are thread safe and not the
> focal point of JMS functionality. JMS sessions are where all the action
> occurs are not thread safe.  Sessions are considered to be 'lightweight'
> objects, as mentioned in the JMS spec, but Weblogic considers them to
> be 'heavyweight', and so they are reused.  Other reasons to reuse the same
> session over and over again is to ensure message ordering and to group
> multiple sends in the same transaction. The JMS spec states that ordering
> is only done if sending from the same session. This is where some other
> JmsTemplate/JmsProducer implementation might be necessary.  This case
> could also potentially be handled by a SessionFactory or strategy pattern
> inside
> an existing impl.  Session pooling would then be on a per thread and
> destination basis.
+1 for a strategy approach

>
> Exceptions
> ----------
> I guess it is a spring mandate to use runtime exceptions, though the
> existing exception heirarchy is much better than in the case of jdbc.
> There is a vendor code, but I've really seen it used much to classify
> errors.  The work here would be to preserve the existing heirarchy but
> switch them all to runtime.... this gives me a wierd feeling..

Interesting problem. Indeed, the JMS hierarchy is much better than
SQLException (not too hard). With JDBC we add value in 2 ways: making the
exceptions unchecked, and providing a meaningful hierarchy. If there is a
meaningful hierarchy the value proposition is reduced. Clearly having JMS
related exceptions unchecked is consistent with the rest of Spring however,
which is important.

>
> Stand-alone Usage
> -----------------
> This relates to the creation of message listeners and also the
> 'mini-container' or JmsService that would be used to set it all up.  More
> on this another time.
>
> Client Side Selector
> --------------------
> Use the client side selector in a MDB or stand-alone message listener to
> aid in message routing/processing.
>
>
> JMS Marshalling
> ----------------
> I have robust JMS<->Bean converter which we have found to be incredibly
> useful.  Might add some send methods to the JmsProducer in order to
> automatically convert....
>
>
> Misc
> ----
> A pretty printer for messges, always nice for debugging purposes.
>
>
>
> Why not to use commons-messenger.
> ---------------------------------
>
> I reviewed the commons-messenger API and while it does offer 'domain
> unfication' it falls short in other areas.
>
> 1) The approach they took in managing/caching the connections/sessions
> does not use the approach of using a different implementation of the
> ConnectionFactory interface. Instead is done inside each 'messenger'
> instance with their own custom classes. This means that people could not
> leverage advanced features offered by weblogic and other vendors
> since that use the ConnectionFactory approach to pooling resources.
>
> However, for advanced usage, we might need to do something similar, though
> I'd like to see how far we can go with the ConnectionFactory approach.
>
> 2) Use of checked exceptions.
>
> 3) Combines in one class the send and receive stuff, which I think is more
> naturally done in seperate clasess/interfaces.

Regards,
Rod