JMS ACTIVEMQ Research Document

1. Background

At present, CORBA, DCOM, RMI and other RPC middleware technologies have been widely used in various fields. But in the face of a distributed system that is growing in size and complexity, these technologies also show their limitations: (1) synchronous communication: After a client makes a call, it must wait for the service object to finish processing and return the result before it can continue; (2) tight coupling of customer and service object lifecycle: Client process and service object process Must work properly, if the customer receives an exception due to a crash in the service object or a network failure that causes the client's request to be unreachable; (3) Point-to-Point communication: A call from a customer is sent only to a single target object.
Message-oriented middleware (oriented Middleware,mom) solves the above problems better. The sender sends the message to the message server, which stores the message in several queues and forwards the message to the recipient at the appropriate time. In this mode, sending and receiving are asynchronous, the sender does not have to wait; the life cycle of the two is not necessarily the same: the receiver does not necessarily run when the message is sent, and the sender does not necessarily run when the message is received; One-to-many communication: There can be multiple receivers for a message.
Existing MOM systems include IBM's MQSeries, Microsoft's MSMQ, and Bea's Messageq. Without a common standard, it is difficult for these systems to interoperate and connect seamlessly. The Java message Service (JMS) is the specification that Sun proposes to unify the various MOM system interfaces, which includes point-to-point to POINT,PTP and publish/subscribe (publish/subscribe,pub/ Sub), which provides reliable message transmission, transaction and message filtering mechanisms. 2. JMS Overview 2.1 JMS Specification

The Java Messaging Service (JMS) defines the interface for accessing message middleware in Java. JMS is just an interface and is not implemented, and the message middleware that implements the JMS interface is called the JMS Provider, such as ACTIVEMQ. 2.2 Terminology

JMS Provider: Message middleware to implement JMS interface;

Ptp:point to point, a point-to-point message model;

Pub/sub:publish/subscribe, i.e. publish/subscribe message model;

Queue: Queues target;

Topic: Thematic objectives;

ConnectionFactory: Connect the factory, JMS uses it to create the connection;

CONNECTION:JMS the client to the JMS Provider connection;

Destination: The destination of the message;

Session: A thread that sends or receives messages;

MessageProducer: The object created by the session object to send the message;

Messageconsumer: An object created by the session object to receive messages;

Acknowledge: sign;

Transaction: Business.

2.3 JMS Programming Model

In the JMS programming model, JMS clients (components or applications) Exchange messages through the JMS messaging service. The message producer sends the message to the messaging service, and the message consumer receives the messages from the messaging service. These message transfer operations are performed using a set of objects that implement the JMS application programming Interface (API) (provided by the JMS provide).

In the JMS programming model, JMS clients use the ConnectionFactory object to create a connection, send messages to the messaging service, and receive messages from the message service through this connection. Connection is the active connection between the client and the messaging service. When you create a connection, the communication resources are assigned and the client is validated. This is a fairly important object, and most clients use one connection for all message delivery.

The connection is used to create the session. A session is a single-threaded context that is used to generate and use messages. It is used to create the sending producer and the consumer that receives the message, and to define the send order for the message sent. Sessions support reliable delivery through a large number of acknowledgment options or transactions.

The client uses MessageProducer to send a message to the specified physical target (represented in the API as the target identity object). The producer can specify a default delivery mode (persistent and non-persistent messages), priority, and expiration values to control all messages sent by the producer to the physical target.

Similarly, the client uses the Messageconsumer object to receive messages from the specified physical target (represented in the API as the target object). Consumers can use the message selector, which enables the messaging service to send only those messages that match the selection criteria to the consumer.

Consumers can support synchronous or asynchronous message reception. Asynchronous use can be achieved by registering MessageListener with the consumer. When the session thread invokes the OnMessage method of the MessageListener object, the client uses the message.

2.4 JMS Programming domain

JMS supports two distinct messaging models: PTP (point-to-point model) and pub/sub (that is, the Publish/subscribe model), which is called PTP domain and pub/sub domain, respectively.

PTP (using queue-that is, queuing destination) messages are sent from one producer to a consumer. In this routing model, the target is a queue. The message is first routed to the queue target, and then, based on the queue routing policy, the message is routed from the queue to a consumer who registers with the queue, sending only one message at a time. There is no limit to the number of producers who can send messages to the queue target, but each message can only be sent to and successfully used by a consumer. If no consumer has been registered to the queue, the queue retains the message it receives and passes the message to the consumer when a consumer registers with the queue.

pub/sub (using topic , the subject-goal) message is transmitted from one producer to any number of consumers. In this transport model, the target is a topic. Messages are first routed to the subject target and then routed to all active consumers who have subscribed to this topic. There is no limit to the number of producers who can send messages to subject targets, and each message can be sent to any number of subscribers. Theme goals also support the concept of persistent subscriptions. A persistent subscription indicates that the consumer has registered to the subject target, but the consumer can be inactive when the message is delivered. When this consumer is again active, it receives this information. If no consumer has been registered to the subject's target, the topic does not retain the messages it receives unless an inactive consumer registers a persistent subscription.

The two messaging models work with API objects that represent different programming domains, with slightly different semantics, as follows:

Basic type (unified domain)	PTP field	pub/sub domain
ConnectionFactory	queueconnectionfactory	Topicconnection Factory
Connection	queueconnection	Topi Cconnection
Session	queuesession	TOPICP ublisher
Destination (Queue or Topic)	Queue	P>topic
MessageProducer	Queuesender
Messageconsumer	Queuereceiver,queuebrows ER	TopicSubscriber

Use the unified domain objects listed in the first column of the chart to write point-to-point and publish/subscribe message delivery. This is the preferred method (JMS 1.1 specification). however, to conform to the early JMS 1.02b specification, you can use the PTP domain object to write point-to-point messaging and use Pub/sub domain objects for publish/subscribe messaging.

2.5 JMS Message Structure

A JMS message consists of the following parts: message headers, attributes, and message bodies. 2.5.1 Message Header (header)

The message header contains the identification and routing information of the message, and the header contains some standard attributes such as Jmsdestination,jmsmessageid.

Message headers	by WHO set
Jmsdestination	Send method
Jmsdeliverymode	Send method
Jmsexpiration	Send method
Jmspriority	Send method
Jmsmessageid	Send method
Jmstimestamp	Send method
Jmscorrelationid	Customer
Jmsreplyto	Customer
Jmstype	Customer
Jmsredelivered	JMS Provider

2.5.2 Property (properties)

In addition to the standard attributes defined in the message header, JMS provides a mechanism for adding new attributes to the header, which includes the following kinds of properties:
1. Applications need to use the attributes;
2. Some optional attributes of the message header;
3. JMS Provider The properties you need to use.
The standard JMS message headers contain the following properties:

Message headers	Describe
Jmsdestination	Destination of message Sent
Jmsdeliverymode	Transfer mode, there are two modes: persistent and non_persistent,persistent indicate that the message must be sent to the destination, otherwise it will cause an application error. Non_persistent indicates that accidental loss of the message is allowed, which allows developers to find a balance between the reliability and throughput of message delivery.
Jmsexpiration	The message expiration time equals the TimeToLive value in the destination Send method plus the GMT time value for the sending time. If the TimeToLive value is equal to zero, the jmsexpiration is set to zero, indicating that the message never expires. If the message has not been sent to the destination after the message expires after it is sent, the message is cleared.
Jmspriority	Message priority, from 0-9 10 levels, 0-4 is normal message, 5-9 is expedited message. JMS does not require the JMS Provider to send messages in strict accordance with these 10 priorities, but must ensure that expedited messages arrive before normal messages.
Jmsmessageid	The unique identification of each message is generated by the JMS Provider.
Jmstimestamp	A message is submitted to the JMS Provider the time the message was sent.
Jmscorrelationid	Used to connect to another message, a typical application is to connect to the original message in the reply message.
Jmsreplyto	Provides the destination address of this message reply message
Jmstype	The identifier for the message type.
Jmsredelivered	If a client receives a message with the jmsredelivered attribute set, it indicates that the client may have received the message earlier, but did not sign (acknowledged).

2.5.3 message bodies (body)

The JMS API defines 5 message body formats, also known as message types, that can be used in different forms to send receive data and can be compatible with existing message formats, as described in the following 5 types:

Message type	Message body
TextMessage	Java.lang.String objects, such as XML file contents
Mapmessage	A collection of name/value pairs, with a string object, and a value type that can be any of the Java basic types
Bytesmessage	Word throttling
Streammessage	Input and output streams in Java
ObjectMessage	Serializable objects in Java
Message	No message body, only message headers and attributes

2.6 PTP Model

The PTP (point-to-point) model is based on queues, where producers send messages to queues, consumers receive messages from queues, and the presence of queues makes the asynchronous transmission of messages possible. As with mailboxes in the messaging system, queues can contain various messages, and the JMS Provider provides tools to manage the creation and deletion of queues. The JMS PTP model defines how clients send messages to queues, receive messages from queues, and browse messages in queues.
The following describes the key concepts and objects in the JMS PTP model:

Name	Describe
ConnectionFactory	The client creates the connection object with ConnectionFactory.
Connection	A connection to a JMS Provider in which the client can create a session with connection to send and receive messages.
Session	Clients use session to create MessageProducer and Messageconsumer objects. If some messages have been received while the session is closed, but have not yet been signed (acknowledged), the message will be received again the next time the consumer connects to the same queue.
Destination (queue or temporaryqueue)	The client creates the destination object with session. The target here is a queue, and the queue is identified by the queue name. A temporary queue can only be consumed by consumers created by the connection that created it, but any producer can send a message to a temporary queue.
MessageProducer	The client sends messages to the queue with MessageProducer.
Messageconsumer	The client uses Messageconsumer to receive messages in the queue, and if the user sets the message selection criteria in the Receive method, messages that are not eligible will remain in the queue and will not be received.
Reliability (Reliability)	Queues can hold messages for a long time until the consumer receives a message. Consumers do not need to worry about the message will be lost and the queue to maintain the activation of the connection state, fully embodies the advantages of the asynchronous transmission mode.

2.7 Pub/sub Model

The JMS pub/sub model defines how to publish and subscribe messages to a content node, which is called a theme (topic).
A topic can be considered a transport intermediary for a message, a publisher (publisher) publishes a message to a topic, and a Subscriber (subscribe) subscribes to a message from a subject. Themes make it possible for message subscribers and message publishers to remain independent of each other and to guarantee the delivery of messages without contact.
The following describes the key concepts and objects in the JMS pub/sub model:

Name	Describe
Subscribe to (subscription)	Message subscriptions are divided into Non-persistent subscriptions (non-durable subscription) and persistent subscriptions (durable subscrip-tion), and non-persistent subscriptions only when the client is active, that is, and the JMS Provider Keep the connection status to receive messages sent to a topic, and when the client is offline, the message to the topic will be lost and never received. A persistent subscription, the client registers an ID with the JMS, and when the client is offline, the JMS Provider saves all messages sent to the topic for that ID, and when the customer connects to the JMS Provider, it will be based on its own ID Get all messages that are sent to the subject when you are offline.
ConnectionFactory	The client creates the connection object with ConnectionFactory.
Connection	A connection to a JMS Provider in which the client can create a session with connection to send and receive messages.
Session	Clients use session to create MessageProducer and Messageconsumer objects. It also provides a persistent subscription topic, or uses the Unsubscribe method to cancel a persistent subscription to a message.
Destination (topic and temporarytopic)	The client creates the destination object with session. The goal here is the theme, and the theme is identified by the topic name. A temporary theme can only be consumed by consumers created by the connection that created it. Temporary topics cannot provide a persistent subscription feature. JMS does not give a definition of the organization and hierarchy of the subject, as defined by the JMS Provider itself.
MessageProducer	Clients use MessageProducer to publish messages to topics.
Messageconsumer	The client uses Messageconsumer to receive messages published to the topic. You can set the message filtering function in receive so that messages that do not meet the requirements are not received.
Recovery and re-Dispatch (Recovery and Redelivery)	An unsigned message cannot be recovered or dispatched under a Non-persistent subscription state. Only persistent subscriptions can recover or dispatch an unsigned message.
Reliability (Reliability)	When all messages must be received, the persistent subscription mode is used. When a lost message can be tolerated, a non-persistent subscription pattern is used.

2.8 JMS supports concurrency

JMS objects	Whether concurrency is supported
Destination	Is
ConnectionFactory	Is
Connection	Is
Session	Whether
MessageProducer	Whether
Messageconsumer	Whether

3. ACTIVEMQ installation 3.1 version

JDK version: Jdk1.5.0_11

ActiveMQ version: ActiveMQ 4.2 beta

C + + client version: ActiveMQ CPP 1.1 release 3.2 ActiveMQ binary installation

Gunzip apache-activemq-4.2-20070328.130210-35.tar.gz

Tar xvf Apache-activemq-4.2-20070328.130210-35.tar

Setting ACTIVEMQ Environment variables: Activemq_home= installation directory

Setting CLASSPATH environment variables, classpath= $CLASSPATH: $ACTIVEMQ _home/apache-activemq-4.2-snapshot.jar 3.3 ACTIVEMQ transplantation

Simply package the $activemq_home to the new machine.

3.4 C + + client compilation

Install perl-5.8.8.tar.gz

Tar xzvf perl-5.8.8.tar.gz

CD perl-5.8.8

Rm-f config.sh policy.sh

SH configure-de-dprefix=/usr

Make

Make Test

Make install

Reboot

System reboot, login system can perform PERL-V view Perl version information

Check to see if/usr/bin/perl or/usr/local/bin/perl points to a new version of Perl

Install m4-1.4.8.tar.gz

Tar xzvf m4-1.4.8.tar.gz

CD m4-1.4.8

./configure

Make

Make install

Install autoconf-2.59.tar.gz

Tar xzvf autoconf-2.59.tar.gz

CD autoconf-2.59

./configure

Make

Make install

Install automake-1.9.6.tar.gz

Tar xzvf automake-1.9.6.tar.gz

CD automake-1.9.6

./configure

Make

Make install

Install libtool-1.5.22.tar.gz

Tar xzvf libtool-1.5.22.tar.gz

CD libtool-1.5.22

./configure

Make

Make install

Install cppunit-1.10.2.tar.gz

Tar xzvf cppunit-1.10.2.tar.gz

CD cppunit-1.10.2

./configure

Make

Make install

Install e2fsprogs-1.38.tar.gz

Note: This item only SOLARIS8 need to be installed, SOLARIS9 has brought this UUID header file and library file

Tar xzvf e2fsprogs-1.38.tar.gz

CD e2fsprogs-1.38

./configure

Make

Make install

Install gcc-3.4.6

Note: You can download the Solaris version and CPU gcc-3.4.6 package files directly from http://www.sunfreeware.com without compiling yourself

Gunzip gcc-3.4.6-sol8-sparc-local.gz

Pkgadd–d gcc-3.4.6-sol8-sparc-local