Revision as of 20:15, 14 May 2009

JMS in the Edge Server

This page describes how JMS is used in the Edge Server

A very, very brief JMS Introduction

JMS (Java Messaging Service) is a standard for a messaging API as specified by JSR 914. A JMS Provider is an implementation of the JMS specification. The idea is that there is a server whose job it is to route messages. It is up to the provider to define exactly how this server works. For example, some providers require you to start the server administratively from the command line and allow you to control it using JMX. Other providers allow you to start the server in your source code.

There are two types of clients to the server. A JMS Consumer will consume JMS Messages. A JMS Producer will send messages to the server.

There are two ways to use JMS. You can either use a point-to-point model, or you can use a publish-subscribe model. The basic difference is that with the point-to-point model, for every message produced, there is at most one consumer. With the publish-subscribe model, there can be more than one consumer. Point-to-point implementations will use a JMS Queue as a destination. Publish-subscribe implementations will use a JMS Topic. For a better explanation, see: this article.

Rifidi Edge Server uses ActiveMQ as its provider. With ActiveMQ, the server is called a Broker. Rifidi uses spring to create and start the broker.

Overview

The Rifidi Edge Server uses JMS (ActiveMQ) to pass certain kinds of data from component to component. The edge server separates its usage of JMS into two logical components:

• Internal Message Bus - This is used for tag data that is collected by sensor plugins (e.g. Commands executing on an Alien9800 session). It is implemented using an ActiveMQ broker with one Destination (specifically a Topic). Since it is only used internally, clients (both producers and consumers) connect to it using a vm connection.
• External Notification - This is used to expose tag events and notification events to software outside the edge server. It is implemented using an ActiveMQ broker with two Destinations (one Topic for tag events and one for notification events). Clients to the broker (both producers and consumers) can connect to it using a vm connection. Clients external to the edge server can use a TCP connection.

There are two kinds of events used in the Rifidi Edge Server:

• Tag Events - These events consist of tag data produced by sensors (depicted in blue below)
• Notification Events - These are system events such as a new reader being created, a session state change, or a property on a reader changing. (depicted in red below)

The image above shows commands (JMS Producers) producing tag events and sending them to the internal topic. Other components (such as ReaderFactories) produce notification events. There are two consumers of events that are put on the internal topic: Esper (which uses the events as a stream for event stream processing) and the notification plugin (which simply relays the events to the external tags topic. External edge server clients can then connect to the two external topics to get notification and tag events.

Components

There several JMS objects that are automatically created when the edge server starts up (inside jms.xml in the spring folder of the core bundle). These objects should be reused when applicable. The objects that should be reused are made available as OSGi services.

Broker

As mentioned above, there are two brokers: an internal and and external one. You can connect to either broker within the edge server using a vm connection.

• For the internal broker use this url: vm://internalBroker
• For the external broker use this url: vm://externalBroker
• To create a connection to the external broker from outside the vm, you can use this url: tcp://localhost:1099

Destination

There are three topic automatically created:

• org.rifidi.edge.external.notifications - Used to send system messages to software outside of the edge server
• org.rifidi.edge.external.tags - Used to send tag events to software outside of the edgeserver
• org.rifidi.edge.internal - Used to collect tag messages from sensors

These three destinations are available as services in the osgi registry. The bean names are:

• externalNotificationsDest
• externalTagsDest
• internalDest

You can access them from another bundle as follows:

	
<!-- Get a reference to the internal Message Buffer -->
<osgi:reference id="internalMB" interface="javax.jms.Topic" bean-name="internalDest" />

Connection Factories

A connection factory allows JMS clients to create connections to the broker. There are two connection factories available in the OSGi service registry (one for each broker). Both connection factories use the vm transport.

• internalBrokerConFac allows you to create connections to the internal broker
• externalBrokerConFac allows you to create connections to the external broker

you can access them from another bundle as follows:

<!-- Get reference to connection factory to internal Broker -->
<osgi:reference id="confac" interface="javax.jms.ConnectionFactory" bean-name="internalBrokerConFac" />

Templates

A template is a class provided by spring that helps you produce messages. They are thread-safe and are intended to be used by multiple components. If used without any kind of pooling, templates will create a JMS Connection, a JMS Session, JMS Producer each time it sends a message. However, the two templates available in the OSGi registry wrap a connectionfactory in a PooledConnectionFactory to avoid this problem. These templates should usually not be used to consume messages and instead a </tt>SimpleMessageListenerContainer</tt> (see below) should be used instead. There are two templates available in the OSGi registry:

• internalJMSTemplate. This is used to produce messages and send them to the internal broker. It wraps the internalBrokerConFac and has its default destination set to org.rifidi.edge.internal.
• externalJMSTemplate This is used to produce messages and send them to the external broker. It wraps the externalBrokerConFac and does not have a default destination set.

You can access the templates from another bundle as follows:

<!-- Get a reference to the internal message bus -->
<osgi:reference id="internalMB" interface="org.springframework.jms.core.JmsTemplate" bean-name="internalJMSTemplate" />

Setting up a Producer

Tag Producer

General Producer

Setting up a Consumer

Future Work

References