Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Eric Gunnewegh at 9:14 on Tuesday 20 August    Add 'JMS 2.0' site to delicious  Add 'JMS 2.0' site to technorati  Add 'JMS 2.0' site to digg  Add 'JMS 2.0' site to dzone

Inleiding

Eén van de vernieuwde API’s in JEE7 is JMS 2.0. De JMS API is lang stabiel gebleven na de release van JMS 1.1 in 2002. Sinds JavaEE 1.4 maakt JMS 1.1 onderdeel uit van het Java EE platform. Twee zaken die opvallen in de nieuwe JMS API zijn het vereenvoudigde programmeermodel en het gebruik van de nieuwe features die het Java SE platform inmiddels biedt met Java SE 7. Daarnaast zijn er aan de JMS API ook een aantal nieuwe features toegevoegd.

Vereenvoudigd programmeermodel

In figuur 1 is het klassieke JMS programmeermodel weergegeven dat bestaat sinds 2002.

 

JMS 1.1

Figuur 1: Het klassieke JMS 1.1 programmeermodel

In JMS 2.0 is dit programmeermodel vereenvoudigd met de introductie van de JMSContext, zoals weergegeven in figuur 2. De JMSContext combineert de Connection en Session objecten in één object. Daarnaast bevat de nieuwe API de nieuwe JMSConsumer en JMSProducer objecten. De klassieke API wordt overigens niet vervangen door de nieuwe API. Beide API’s blijven naast elkaar bestaan. Wat dit vereenvoudigd programmeermodel betekent voor de Java code, laat zich goed illustreren door codefragment 1.

JMS 2.0

Figuur 2: Het vereenvoudigde JMS 2.0 programmeermodel

   @Resource(lookup = “java:comp/DefaultJMSConnectionFactory”)
   private static ConnectionFactory connectionFactory;

   @Resource(lookup = “jms/TestQueue”)
   private static Queue queue;

   String message = “Een test message”;
   try (JMSContext context = connectionFactory.createContext();) {
      context.createProducer().
         setDeliveryMode(DeliveryMode.NON_PERSISTENT).
         setPriority(9).
         setTimeToLive(10000).
         send(queue, message);
   } catch (JMSRuntimeException e) {
      System.out.println(e);
   }

Codefragment 1: Het versturen van een message

Codefragment 1 laat zien hoe je met de vernieuwde JMS API op vereenvoudigde manier een bericht kunt sturen. Vergeleken met de klassieke API vallen een aantal zaken op.

  1. Een Producer creëren gaat sneller via een JMSContext dan in het oude model via achtereenvolgens een Connection en een Session.
  2. Er hoeft niet eerst een TextMessage gecreëerd te worden. De Producer accepteert ook een String.
  3. Het creëren van JMSContext gebeurt in een try-with-resources block, een nieuw feature van het Java SE7 platform. De JMSContext interface extends de AutoCloseable interface, zodat bij het afsluiten van het try-with-resources block automatisch de close() methode wordt aangeroepen.
  4. Bij het creëren van de JMSProducer kan method chaining gebruikt worden voor het zetten van de diverse opties. In JMS 2.0 hebben de diverse setters voor het zetten van opties, headers en properties de JMSProducer als return value, wat method chaining mogelijk maakt.

Ook het ontvangen van berichten is vereenvoudigd. Zie ter illustratie het volgende codevoorbeeld waarbij het niet nodig is om een Message om te zetten naar een TextMessage om hier vervolgens de body uit op te vragen.

   String msg = context.createConsumer(queue).receiveBody(String.class, 1000);

Injectie van JMSContext

In een servlet of EJB is het mogelijk om direct de JMSContext te injecteren, in plaats van deze aan te maken via een geïnjecteerde ConnectionFactory.

   @Inject
   @JMSConnectionFactory(“jms/MyConnectionFactory”)
   private JMSContext context;

Wanneer gebruik gemaakt wordt van de default ConnectionFactory, kan de @JMSConnectionFactory achterwege gelaten worden.

sessionMode

De introductie van de sessionMode biedt de ontwikkelaar een duidelijker keuze in het gebruik van een transactionele sessie of een acknowledge mode. In de klassieke JMS API bevat het Connection object de volgende methode die de ontwikkelaar op het verkeerde been kan zetten.

   Session createSession(boolean transacted, int acknowledgeMode) throws JMSException;

Het probleem met deze methode is dat niet alle combinaties valide zijn. Bij een transactionele sessie (transacted=true) vindt een acknowledgement automatisch plaats na een commit. In deze situatie heeft het geen zin om een acknowledgeMode op te geven. Andersom geldt ook dat een acknowledgeMode alleen betekenis heeft bij transacted=false.

De vernieuwde JMS API biedt meer duidelijkheid met de volgende methode in het Connection object

   Session createSession(int sessionMode) throws JMSException;

of de volgende methode in het ConnectionFactory of JMSContext object.

   JMSContext createContext(int sessionMode);

De sessionMode kan één van de volgende waarden hebben, waardoor de ontwikkelaar moet kiezen tussen een transactionele sessie of een acknowledgement mode.

   Session.SESSION_TRANSACTED
   Session.CLIENT_ACKNOWLEDGE
   Session.AUTO_ACKNOWLEDGE
   Session.DUPS_OK_ACKNOWLEDGE
   Session.TRANSACTED

Hoewel dit een stuk duidelijker is dan in de klassieke JMS API, geldt ook hier dat niet elke waarde in alle situaties geldig is. Bijvoorbeeld, als de methode wordt aangeroepen in een Web of EJB container in een actieve transactionele JTA context, wordt de sessionMode genegeerd. Voor de details wordt verwezen naar de Javadoc, die met betrekking tot dit onderwerp in JMS 2.0 ook een stuk uitgebreider is geworden, zie http://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#createSession(int).

Shared subsriptions

Eén van de nieuwe features in de JMS 2.0 API zijn de shared subscriptions op topics. Voor wat betreft topics waren er voorheen twee varianten, durable en non-durable topics, die beiden alleen unshared subscriptions ondersteunden. In JMS 2.0 kunnen subscriptions ook shared zijn.

In de JMS 1.1 API konden meerdere consumers een eigen subscription hebben op hetzelfde topic. Elke consumer met een eigen subscription (unshared subscription) ontving dan elk bericht dat op het topic gepubliceerd werd. Pas in JMS 2.0 is het mogelijk dat meerdere consumers een subscription kunnen delen (shared subscription). De berichten die op een topic met een shared subscription gepubliceerd worden, worden door de JMS provider verdeeld over de consumers die bij de shared subscription horen, waarmee het mogelijk wordt berichten parallel af te handelen in meerdere threads.

Exception handling

In de JMS 2.0 API wordt de unchecked JMSRuntimeException gebruikt in plaats van de checked JMSException, zie bijvoorbeeld ook codefragment 1. Dit betekent dat de aanroeper van de methodes in de JMS 2.0 API niet verplicht is deze Exception af te vangen.

Zie ter illustratie ook de createTextMessage() methode in respectievelijk de objecten Session en JMSContext.

   //klassieke API
   TextMessage createTextMessage() throws JMSException;

   //JMS 2.0
   TextMessage createTextMessage();

Wat ook een verbetering is in de JMS 2.0 API is dat de JMSRuntimeException nu ook een constructor heeft met een Throwable als argument. Bij de klassieke JMSExcepion ontbrak een dergelijke contstructor. In plaats daarvan heeft de JMSExcepion een linkedException, die in de praktijk vaak over het hoofd wordt gezien.

Aan de slag met JMS 2.0

Voor wie zelf wil ontdekken wat JMS 2.0 nog meer te bieden heeft, kan snel aan de slag met GlassFish en de JEE 7 SDK. De downloads bevatten diverse examples. Wie gebruik maakt van de built-in JMS Provider van GlassFish, is QBrowser een handige tool voor het bekijken van queues, topics en berichten.

http://www.oracle.com/technetwork/java/javaee/downloads/index.html
http://sourceforge.net/projects/qbrowserv2/
http://docs.oracle.com/javaee/7/tutorial/doc/partmessaging.htm#GFIRP3
https://jms-spec.java.net/2.0/apidocs/


© 2019 Java Competence Network. All Rights Reserved.