Mit Spring 1.X war das asynchrone Empfangen von JMS Nachrichten noch nicht möglich. So musste man in diesem Bereich eine Message Driven Bean einsetzen. Der Nachteil der Lösung ist, das diese nur innerhalb eines Application Servers funktioniert. So muss man für eine Anwendung welche im J2SE und JEE Bereich verteilt wird, zwei unterschiedliche Implementierungen vorhalten.

Seit Spring 2.x existiert eine – meiner Meinung – sehr elegante Lösung für das Empfangen von asynchronen Nachrichten mithilfe von Spring Boardmitteln. Diese wird in der Spring Referenzdokumentation ausführlich dokumentiert. (siehe hier )

Der Vorteil der Lösung liegt auf der Hand, eine Anwendung welche mittels Spring MDPs Nachrichten empfängt kann im J2SE sowie JEE Bereich eingesetzt werden. Für die beiden Umgebungen ist lediglich eine Änderung in der Spring Konfiguration notwendig.

In einem Post innerhalb des developerworks unter hier wird vor dem Einsatz eines Spring MDP Listeners unter Websphere gewarnt. Da die Komponente eigene Threads erzeugt, welche nicht durch den Applikationsserver verwaltet werden. Die Aussage ist in der Form richtig, allerdings ignoriert der Beitrag das die Spring MDP Listener Komponente perfekt mit der Websphere CommonJ Abstraktion zusammenarbeitet. Somit erzeugt die Komponente keine “native Threads” im Websphere, da die Threadverwaltung nun in der CommonJ Abstraktion statt findet. Diese wird im Websphere Application Server konfiguriert und angelegt. Entgegen dem Bericht ist die Implementierung der Spring MDP JEE Konform, solange man einen DefaultMessageListenerContainer anstelle eine SimpleMessageListenerContainers einsetzt.

Einrichten des WorkManagers

Damit die Spring MDP Lister Komponente die CommonJ WorkManager Abstraktion einsetzt, muss zuerst der Workmanager in der Spring Konfiguration definiert werden. Dies geschieht über folgende bean Definition

<bean id="taskExecutor" 
class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
	<property name="workManagerName" value="wm/WorkManager" />
	<property name="resourceRef" value="true" />
</bean>

Durch die oben stehende Bean Definition wird aus dem JNDI Kontext die CommonJ WorkManager Implementierung abgerufen. Unter dem JNDI Namen “wm/WormNagaer” existiert eine default WorkManager Konfiguration innerhalb der ApplicationServers. Es können aber auch Problemlos eigene WorkManagers im Websphere Application Server angelegt werden. Durch die Eigenschaft resourceRef = true, wird der Bean mitgeteilt den Lookup als Resource durchzuführen, generell sollten im JEE Bereich Resource Referenzen verwendet werden, da diese während dem Deplyoment eine höhere Flexibilität bieten.

Konfigurieren des MessageListenerContainer
Die Konfiguration des MessageListenerContainers erfolgt mithilfe folgender Bean Definition

<bean id="container"
	class="org.springframework.jms.listener.DefaultMessageListenerContainer">
	<property name="connectionFactory" ref="queueConnectionFactory" />
	<property name="messageListener" ref="messageListener" />
	<property name="destination" ref="requestQueue" />
	<property name="taskExecutor" ref="taskExecutor" />
	<property name="cacheLevel" value="0" />
</bean>

In der obenstehenden Bean Definition findet die Konfiguration des MessageListenerContainers statt. Die definierte Bean verweist über die Eigenschaft taskExecutor auf den zuvor definierten CommonJ WorkManager. Dadurch das der Konfigurierte Container keine Transaktionen verwendet muss die der CacheLevel explizit auf 0 gesetzt werden, andernfalls kommt es zu Fehler beim Verbindungsaufbau zum Queue Manager. Die anderen Eigenschaften des Containers sind in der Spring Dokumentation (siehe oben) beschrieben.