Un encuentro personal desde el examen de conciencia y el arrepentimiento

The ActiveMQ publishing task is one of the crucial parts of our research, because it plays such an important role in the new transient notification architecture that we have proposed. Under the Publisher/Subscriber (Pub/Sub) context this role is publishing the VOEvent packet to the topic (moa.voevent) that has been created in the ActiveMQ.

The ActiveMQ publishing task will publish the entire VOEvent packet that is inputted from the VOEGenerator to the “moa.voevent” topic, rather than using the

transientParametersSet hashtable as the email publishing task and Twitter

publishing task did.

In fact, the VOEvent packet is the major data that MOA wants to deliver to end users, because the VOEvent packet is typically designed for new transient notification, and it contains all of the metadata about the new transient. End users can utilise the VOEvent packet to do lots of different operations (such as driving robotic telescopes, archiving searches, or a transient analysis processes).

Implementing the ActiveMQ publishing task in Java requires the use of the JMS API under the javax.jms namespace. The JMS API is a fully implemented JMS specification and it can be used for communicating with every message oriented middleware that implements the JMS specification.

Thus, the ActiveMQ publishing task can be used for publishing the VOEvent packet to any JMS based message oriented middleware, rather than only working with the ActiveMQ server.

The VOEvent packet publishing process can be divided into three steps; establishing a connection with ActiveMQ, publishing messaging to the ActiveMQ server, and the close

124

connection between the publishing task and the ActiveMQ server. Each step will be explained in detail below and illustrated using example codes.

Two JMS objects need to be created in order to establish a connection between the ActiveMQ publishing task and the ActiveMQ server; these are connectionFactory object, and connectionobject. The connectionFactory object encapsulates a set of connection configuration parameters that are necessary to establish a connection with the ActiveMQ server, including a login user name, login password and the IP address of ActiveMQ server. After the connectionFactory object has been created, the

connection object will use it and invoke the start() method to establish a new

connection with the ActiveMQ. The following code shows the establishment of a connection with ActiveMQ in the publishing task.

1 ConnectionFactory factory = new ConnectionFactory(username,

2 password, serverIP);

2 Connection connection = factory.createConnection();

4 connection.start();

Code example 10: Creates ConnectionFactory object and establish a new connection with ActiveMQ

Once the publishing task has successfully established a connection with ActiveMQ, the second step is publishing the VOEvent packet to the ActiveMQ server. Four objects need to be created in order to complete this step. The first is the Session object. The session is a single-threaded context for producing and consuming messages, and it also provides a transactional context with which to group a set of sends and receives into an atomic unit of work. We need to use the method provided by the Session object to create message producers, message consumers and messages.

The second object we need to create is the Destination object. The destination is the object that is used to specify the target of the messages it produces and the source of the messages it consumes. In our experimental architecture, the target of the messages is the “moa.voevent” topic we created in the previous section.

125

The third object that needs to be created is the message object, because JMS uses the message object tostore the message that needs to be sent. There are in total five different types of message objects that can be created through using the JMS API, and these five different types of message objects can be used for storing different types of data in the messages (i.e., we can deliver image files to end users through converting the image file to binary codes and storing it in a binary message object). The type of message object we use for storing the VOEvent packet is TextMessage. The TextMessage object is typically designed for storing and dealing with pure string messages. As is well-known, the VOEvent packet is based on an XML document and an XML document consists of a pure string, so the TextMessage object is adequate to fulfill our requirements.

After the VOEvent packet has been stored in the TextMessage object, the last object that needs to be created is the MessageProducer object. The

MessageProducer is an object that is created by a Session and used for sending

messages to a topic. Please note that we also need to define the message delivery mode before sending a message to a topic, otherwise MessageProducer will send messages through using default delivery mode (Non-Persistent).

There are two delivery modes supported by the JMS API; Non-Persistent, and Persistent. The Non-Persistent delivery mode is the lowest-overhead delivery mode because it does not require that the message be logged to stable storage. However, if any errors occur on the message oriented middleware, the messages that come from the message sender will be lost and never delivered to the receivers.

On the other hand, the Persistent delivery mode performs a very different operation when compared with the Non-Persistent delivery mode. In the Persistent delivery mode, the message oriented middleware will log a message to stable storage, guaranteeing that the message be delivered once, and only once, to the message receiver. Any message that is marked as Persistent delivery will not be lost unless hardware storage failure occurs. The Persistent delivery mode is very useful when the publisher wants to deliver every published message to the message receiver without missing.

126

We have used the Persistent delivery mode in our architecture, because we need to ensure delivery of every VOEvent packet to all end users without any being lost.

After the message delivery mode has been defined, we can than invoke the send

method to send a message to the topic. The example codes below show how to create and use MessageProducerto send a message to the topic.

1 Session session = connection.createSession(false,

2 Session.AUTO_ACKNOWLEDGE);

3 //Specifing message destination

4 Destination destination = session.createTopic(“moa.voevent”);

5 //Creating message producer object

6 MessageProducer producer = session.createProducer(destination);

7 //Setup delivery mode as persistent

8 producer.setDeliveryMode(DeliveryMode.PERSISTENT);

9 //Creating TextMessage object

10 TextMessage eventMsg = session.createTextMessage();

11 eventMsg.setText(VOEvent packet string);

12 //Sends VOEvent packet to the topic

13 producer.send(eventMsg);

Code example 11: Sends a new VOEvent packet string to “moa.voevent” topic through using

persistent delivery mode

Once a VOEvent packet has been successfully sent to the topic in the ActiveMQ server, the final step involves invoking the close method provided by the

Connection object to disconnect the connection between the ActiveMQ publishing

task and the ActiveMQ server, in order to save the resources of the ActiveMQ server and host machine. The example code of the close connection operation is as shown below:

connection.close();

Code example 12: Disconnects dispatcher application from ActiveMQ server

After the code connection.close() has been executed, the entire ActiveMQ publishing task is completed, the VOEvent packet should reach the “moa.voevent” topic and the ActiveMQ server will forward the VOEvent packet to all online topic subscribers immediately (topic subscribers will be described in detail in the next section).

127

4.5 Subscriber Application for Receiving New Transients’ Information