JMS 2.0 – Eine neue Version nach über zehn Jahren!

Eine Message kann dann über einen Einzeiler verschickt werden, wie Listing 3 zeigt. Ein vom Container injizierter JMSContext muss auch nicht mehr manuell geschlossen werden, weil auch das der Container einem dann abnimmt. Hierzu wird der Scope eines Container-managed JMSContext von der JMS-Spec spezifiziert: Wenn es sich um einen transaktionalen JMSContext handelt (d. h., es existiert eine JTA-Transaktion), ist der Context @TransactionScoped, d. h. er wird am Ende der Transaktion automatisch geschlossen. Wenn es sich um einen JMSContext handelt, der nicht transaktional ist, dann ist der Context @RequestScoped, d. h. er wird am Ende des jeweiligen Requests geschlossen. Selbstverständlich ist es zusätzlich möglich, sich über eine ConnectionFactory selbst einen JMSContext zu erzeugen, der dann aber auch selbst geschlossen werden muss.

Eine weitere positive Eigenschaft hat der neu eingeführte JMSContext: Im Gegensatz zu ihren Pendants in der Connection und Session, werfen die Methoden keine checked Exceptions, wodurch das bereits angesprochene Exception Handling komplett wegfällt. Hierzu wurde eigens zu jeder checked JMSException eine semantisch äquivalente RuntimeException spezifiziert.

Listing 3
@Inject
@JMSConnectionFactory("jms/connectionFactory")
private JMSContext context;
@Resource(lookup = "jms/queue")
private Queue inboundQueue;

public void sendMessage(String message) {
  context.send(queue, message);
}
Weitere Neuerungen

Neben dem „Simplified API“ hat JMS 2.0 zwei „echte“, wenn auch kleinere neue Features: Erstens kann jetzt beim Senden von Nachrichten optional ein Delivery-Delay angegeben werden. Mit diesem kann das Senden einer Nachricht bewusst verzögert werden. Das zweite Feature ist das (ebenfalls optionale) asynchrone Versenden. Bisher musste der sendende Client immer darauf warten, bis die JMS-Queue die Nachricht entgegengenommen hatte. Bei Nachrichten, deren Auslieferung nach Fire-and-forget-Manier nicht zwingend sichergestellt sein muss, ist dieses Warten oft eine ärgerliche Zeitverzögerung. In einem solchen Fall kann die Nachricht ab JMS 2.0 asynchron versendet werden, um dann sofort mit dem Applikationscode fortfahren zu können.

Fazit

JMS 2.0 wird die Java-EE-Welt nicht revolutionieren. Vielmehr ist es die solide Weiterentwicklung eines vorher schon soliden Standards. Abwärtskompatibilität bleibt komplett erhalten, weshalb sich niemand um eine Migration bestehender JMS-Anwendungen Gedanken machen muss. Wer einen JMS-Client neu schreibt, wird in Zukunft sicherlich auf das „Simplified API“ setzen und damit einige Zeilen Boilerplate-Code sparen. Auch gelingt die Integration mit den anderen Java-EE-Technologien, wie z. B. CDI gut und ist folgerichtig.

JMS ist seit Jahren ein fester Bestandteil des Java-EE-Portfolios und vor allem bei der Integration von SOA-Landschaften eine gern genutzte Technologie. Diese wird mit der vorliegenden Version modernisiert, die aller Voraussicht nach Teil von Java EE 7 sein wird. An der Bedeutung von JMS wird sich dadurch weder im Positiven noch im Negativen etwas ändern.

Lars Röwekamp ist Geschäftsführer der open knowledge GmbH und berät seit mehr als zehn Jahren Kunden in internationalen Projekten rund um das Thema Enterprise Computing (Twitter: @mobileLarson).

Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.