~pperalta

Following the example on the Lingo website, I set up a simple service and exposed it through JMS. Using Lingo, you can make RPC style (as well as asynchronous) calls to services using JMS as the transport. For my sample application, I used Tibco JMS (E4JMS) as the provider.

For the server side, I did this:

<beans>
  <!-- the server side -->
  <bean id="server" class="org.logicblaze.lingo.jms.JmsServiceExporter">
   <property name="service" ref="serverImpl"/>
   <property name="serviceInterface" value="ets.lingotest.Reverse"/>
   <property name="connectionFactory" ref="jmsFactory"/>
   <property name="destination" ref="requestDestination"/>
  </bean>

  <bean id="serverImpl" class="ets.lingotest.ReverseServerImpl" singleton="true"/>

  <!-- JMS ConnectionFactory to use -->
  <bean id="jmsFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName">
    <value>GenericConnectionFactory</value>
   </property>
 </bean>

  <bean id="requestDestination" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName">
   <value>queue.sample</value>
  </property>
  </bean>
</beans>

And the client looks like this:

<beans>
  <!-- client side proxy-->
  <bean id="client" class="org.logicblaze.lingo.jms.JmsProxyFactoryBean">
   <property name="serviceInterface" value="ets.lingotest.Reverse"/>
   <property name="connectionFactory" ref="jmsFactory"/>
   <property name="destination" ref="requestDestination"/>
  </bean>

  <!-- JMS ConnectionFactory to use -->
  <bean id="jmsFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName">
    <value>GenericConnectionFactory</value>
   </property>
  </bean>

  <bean id="requestDestination" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName">
    <value>queue.sample</value>
   </property>
  </bean>
</beans>

And here is the interface being exposed:

public interface Reverse {
  public String reverse(String s);
}

With this setup, a single MessageListener is set up to listen on the queue. Easy setup, but not very scalable. To do a proper setup, you can use Jencks to pool JMS resources and process the messages asynchronously.

Another option with Spring 2.0 is to use the new asynchronous JMS processing classes. These classes create and manage threads that hold connections to the JMS queue. For my example, I will use DefaultMessageListenerContainer.

I make this change to the server application context:

<beans>
  <!-- the server side -->
  <bean id="server" class="org.logicblaze.lingo.jms.JmsServiceExporter">
   <property name="service" ref="serverImpl"/>
   <property name="serviceInterface" value="ets.lingotest.Reverse"/>
   <property name="connectionFactory" ref="jmsFactory"/>
   <!--<property name="destination" ref="requestDestination"/>-->
  </bean>

  <bean id="serverImpl" class="ets.lingotest.ReverseServerImpl" singleton="true"/>

  <!-- JMS ConnectionFactory to use -->
  <bean id="jmsFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName">
    <value>GenericConnectionFactory</value>
   </property>
  </bean>

  <bean id="requestDestination" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiName">
    <value>queue.sample</value>
   </property>
  </bean>

  <!--Spring async message processing -->
  <bean id="messageListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
   <property name="connectionFactory" ref="jmsFactory"/>
   <property name="destination" ref="requestDestination"/>
   <property name="messageListener" ref="server"/>
   <property name="concurrentConsumers" value="5"/>
  </bean>

</beans>

The JmsServiceExporter no longer has the destination property configured; instead it is set as the messageListener property of DefaultMessageListenerContainer. Note the DefaultMessageListenerContainer knows all about the JMS connection and queue where the messages will be coming in. It also has the concurrentConsumers value set to 5, so there will be 5 threads listening for messages.

Previously, the server output was:

ReverseServerImpl [E4JMS Session Dispatcher (171)] INFO - Server got string: hello world
ReverseServerImpl [E4JMS Session Dispatcher (171)] INFO - Server returning: dlrow olleh

Now it is

ReverseServerImpl [DefaultMessageListenerContainer0] INFO - Server got string: hello world
ReverseServerImpl [DefaultMessageListenerContainer0] INFO - Server returning: dlrow olleh

Note that it is now DefaultMessageListenerContainer0 handling the message instead of E4JMS Session Dispatcher. I also noticed that the message processing is set up round robin, so executing the client multiple times yields:

ReverseServerImpl [DefaultMessageListenerContainer0] INFO - Server got string: hello world
ReverseServerImpl [DefaultMessageListenerContainer0] INFO - Server returning: dlrow olleh
ReverseServerImpl [DefaultMessageListenerContainer1] INFO - Server got string: hello world
ReverseServerImpl [DefaultMessageListenerContainer1] INFO - Server returning: dlrow olleh
ReverseServerImpl [DefaultMessageListenerContainer2] INFO - Server got string: hello world
ReverseServerImpl [DefaultMessageListenerContainer2] INFO - Server returning: dlrow olleh
ReverseServerImpl [DefaultMessageListenerContainer3] INFO - Server got string: hello world
ReverseServerImpl [DefaultMessageListenerContainer3] INFO - Server returning: dlrow olleh
ReverseServerImpl [DefaultMessageListenerContainer4] INFO - Server got string: hello world
ReverseServerImpl [DefaultMessageListenerContainer4] INFO - Server returning: dlrow olleh

This setup is pretty simple, but I’m not sure what the implications are as far as performance and scalability, especially given the usage patterns of JmsTemplate as documented by James Strachan. I’m curious to hear from anyone that has a similar setup or from anyone that has suggestions/feedback.

It looks like the pending transit strike in New York is causing all sorts of anxiety among New Yorkers. Today the New York Times reported that no deal had been struck at the end of the current contract; as a result the TWU plans to call a strike with two private bus companies in Queens, Triboro and Jamaica Buses, Inc.. The reason is because these routes have not been taken over by the city yet, thus the Taylor Law does not apply to them. One side effect of this that nobody in the media has mentioned yet (and the first thing that came to mind) is that these buses serve many areas that are not exactly affluent. It is somewhat ironic that this strike would affect primarily working and lower class citizens. Queens residents in the middle class and higher are much more likely to own a car, unlike their Manhattan counterparts.

A little late, but here are my closing thoughts on The Spring Experience 2005. The last session that I attended was my own, the Symantec case study. This session focused on our call center case tracking application and how it has evolved over time while making use of Spring. As Jim Moore mentioned, the project that was discussed during the Accenture case study had many similarities to ours, including:

• infrastructure, such as JBoss, Tomcat, Oracle 9i
• multiple Spring configuration files, swapped out for testing and production
• extensive unit testing of all layers outside of the container
• migration from hard coded dependencies to dependency injection, which makes all of this testing possible

In our case study we cover the evolution of our application from client/server to multi-tier, the issues that we ran into when creating a middle tier, and how Spring helped us along the way. A reoccurring theme throughout the conference was how non invasive Spring is and how easy it is to use bits and pieces at a time instead of having to migrate to DI, AOP, DAO, security and everything else Spring has to offer all at once. This was the case with our middle tier, where we adopted pieces of Spring as time went on. Before we knew it, we had a very flexible and stable solution that was portable to any J2EE container.

We had a small crowd, but had some good questions and dialog about our experiences. I look forward to the JavaLobby guys putting session audio (and hopefully video) on their site in the coming weeks. For those interested, we have posted our slides.

I must say that TSE was one of the best conferences that I have attended, if not the best. When filling out my survey, one of the questions asked which speaker(s) were the best. My honest answer was all of them, because I was able to learn something at each of the talks that I attended. The speakers and attendees alike were very intelligent and articulate; clearly these folks are the leaders of our industry. The accommodations and location were excellent, and to repeat what has already been said by others, Jay Zimmerman and Keith Donald pulled this conference off to perfection. I look forward to returning next year.

The Quick Start with Acegi talk by Ben Alex was a beginner’s guide to Acegi. The focus was on the limitations of container managed security and how Acegi addresses them, including:

• Not portable at WAR level. Each container has vastly different methods of implementing security (Tomcat realms, JBoss LoginModules, etc.)
• Only web requests at the URL level can be secured; Acegi allows method level authorization
• No support for nice features such as “remember me”

One of the issues that I had with Acegi when I first started using it (version 0.7) was how verbose the configuration was. This is supposed to have improved recently, and it is supposed to be even better when it is integrated with Spring 2.0. I’m looking forward to the Acegi 1.0 release.

The remoting talk covered all sorts of remoting technology, such as RMI, IIOP, Hessian, Burlap, SOAP, and Spring’s HTTPInvoker. In general, the proxy based solutions that Spring provides for remoting makes it easy to choose the right remoting technology for your project.

Speaking of remoting, I had an interesting conversation with Mark Pollack regarding JMS remoting. A concept that he has worked on is to use JMS for interoperability with .NET and Java. His project maps object properties to nested map messages in JMS. Using a tool to convert Java to .NET, he generates the .NET version of the data objects and uses proxies to translate between the JMS messages and objects. That sounds like an interesting alternative to IIOP for interoperability.

The dinner time keynote by Rod Johnson announced BEA realtime server which is a new product by BEA targeted to customers that require very high performance for server side processing. This is meant for applications that have not moved off of C++ yet because GC pause time is not an option. The core of this BEA product is Spring, which is quite the validation of the performance that Spring can provide.

A partnership with Geronimo was also announced. I noticed that quite a few demos during the conference were using Geronimo. Rod also mentioned the TopLink DAO support that was donated by Oracle. A major theme with Spring is that it does not try to lock you into a specific vendor; in fact they strive to be as vendor neutral as possible in order to have wide acceptance.

Next Adrian Coyer gave a talk on AOP and its role in making Java simpler yet more powerful. You can throw a lot of money at software, but no amount of money will ensure high quality. The best chance at success is simplicity, but real world software is complex. Using the combination of dependency injection, aspects, and annotations/metadata, we can make software in a simple and modular way, yet allow for complex interactions at the same time. It is for this reason that aspects and AOP will be the next paradigm shift to follow after OOP. As Rod says, knowing and using AOP is a competitive advantage today, tomorrow it will be a competitive necessity.

This morning was Advanced Spring MVC with Rob Harrop, which consisted of a deep dive of Spring MVC form processing, controller testing, i18n, exception handling, and using multiple view technologies in the same project. The slides are very comprehensive and do a good job describing all of these features.

Today’s coverage of the lunchtime expert panel has been brought to you by Jim Moore.