Apache ActiveMQApache ActiveMQ

Contents

1. Introduction

2. About JMS

3. Messaging Domains

4. Why ActiveMQ?

5. Benefits

Introduction

● ActiveMQ is used in enterprise service bus implementations such as Apache ServiceMix and Mule.

● Apache ActiveMQ is a message broker which fully implements the Java Messaging Service API. It can be used by programs written Java,C/C++,.NET,PHP etc.

JMS (Java Messaging Service)The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients. It is a messaging standard that allows application components based on the Java Enterprise Edition (Java EE) to create, send, receive, and read messages. An application can communicate with any number of applications using JMS.This communication is loosely coupled. Instead, those applications are communicated by connecting to a common destination. An application can send messages to the destination and can take messages from the same destination.The concept is shown below as a schematic.This technology is too simple and it can be easily integrated with existing applications so that those applications can communicate each other.

Destination Type

Description

Topic In JMS a Topic implements publish and subscribe semantics. When you publish a message it goes to all the subscribers who are interested - so zero to many subscribers will receive a copy of the message. Only subscribers who had an active subscription at the time the broker receives the message will get a copy of the message.

Queue A JMS Queue implements load balancer semantics. A single message will be received by exactly one consumer. If there are no consumers available at the time the message is sent it will be kept until a consumer is available that can process the message. If a consumer receives a message and does not acknowledge it before closing then the message will be redelivered to another consumer. A queue can have many consumers with messages load balanced across the available consumers.

A session is a single-threaded context for producing and consuming messages. We use sessions to create the following:

● Message producers

● Message consumers

● Messages

● Destination

When a client creates a JMS session it must specify the mode in which the Session will acknowledge the messages that it receives and dispatches. The modes supported are summarized in the table below.

JMS Sessions

Acknowledge Mode

Description

AUTO_ACKNOWLEDGE

With this acknowledgement mode, the session automatically acknowledges a client's receipt of a message either when the session has successfully returned from a call to receive or when the message listener the session has called to process the message successfully returns.

CLIENT_ACKNOWLEDGE

With this acknowledgement mode, the client acknowledges a consumed message by calling the message's acknowledge method. Acknowledging a consumed message acknowledges all messages that the session has consumed. When client acknowledgement mode is used, a client may build up a large number of unacknowledged messages while attempting to process them. A JMS provider should provide administrators with a way to limit client overrun so that clients are not driven to resource exhaustion and ensuing failure when some resource they are using is temporarily blocked.

DUPS_OK_ACKNOWLEDGE

This acknowledgement mode instructs the session to lazily acknowledge the delivery of messages. This is likely to result in the delivery of some duplicate messages if the JMS provider fails, so it should only be used by consumers that can tolerate duplicate messages. Use of this mode can reduce session overhead by minimizing the work the session does to prevent duplicates.

SESSION_TRANSACTED

Session is Transacted and the acknowledge of messages is handled internally.

INDIVIDUAL_ACKNOWLEDGE

Acknowledges are applied to a single message only. Unlike CLIENT_ACKNOWLEDGE where the acknowledgement applies to all messages received up to that point for the entire session, this mode applied only to a single message allowing the client to be more selective about which messages are acknowledged.

Messaging DomainsJMS API supports Point-to-Point and Publish-Subscribe approaches.

Point-to-Point Approach :

The point to point approach consists of a sender , a receiver and a queue.The sender addresses a message to the queue, and the receiving clients extract messages from the queues established to hold their messages. The queue keeps the message till a receiving client receives it or till the message expires. While any number of producers can send messages to the queue, each message is guaranteed to be delivered, and consumed by one consumer.

Publish/Subscribe Approach :

The publish/subscribe model supports publishing messages to a particular message topic. Subscribers may register interest in receiving messages on a particular message topic. In this model, neither the publisher nor the subscriber knows about each other. A good analogy for this is an anonymous bulletin board.

● Zero or more consumers will receive the message. ● There is a timing dependency between publishers and subscribers. The publisher

has to create a message topic for clients to subscribe. The subscriber has to remain continuously active to receive messages, unless it has established a durable subscription. In that case, messages published while the subscriber is not connected will be redistributed whenever it reconnects.

A JMS message has 3 parts

a)header :- The header contains meta-information about the message—

who sent it, where it’s going, and so on.

b)body :- As the name suggests it is the body of messages. JMS API allows five types of message bodies.

1. TextMessage :- Body contains String data

2. ByteMessage :- Body contains byte data

3. MapMessage :- Body contains data in key/value pair

4. StreamMessage :-Body contains a stream of primitive values

5. ObjectMessage : – Body contains an object

6. Message :- Nothing in body. Only header and properties.

c)properties :- Additional properties other than header.

Why Messaging as Communication Style?

● File Transfer and Shared Database enable applications to share their data but not their functionality.

● Remote Procedure Invocation enables applications to share functionality, but it tightly couples them as well. Often the challenge of integration is about making collaboration between separate systems as timely as possible, without coupling systems together in such a way that they become unreliable either in terms of application execution or application development.

● The data transfer should be asynchronous so that the sender does not need to wait on the receiver, especially when retry is necessary.

● Use Messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats.

Why ActiveMQ?

Imagine you need to communicate with two or more systems. A common approach these days will be web services which is fine if you need an answers right away.

However: web services can be down and not available - what do you do then? Putting your message into a message queue (which has a component on your machine/server, too) typically will work in this scenario - your message just doesn't get delivered and thus processed right now - but it will later on, when the other side of the service comes back online.

The Message Queue receives the message, places it in the proper queue, and waits for the application to retrieve the message when ready.

Connect an application to a messaging channel using a Message Endpoint, a client of the messaging system that the application can then use to send or receive Messages.We need a message endpoint to connect the system explicitly to the integration solution. The endpoint can be a special piece of code or a channel adapter provided by an integration software vendor.

For example, one data format may store the customer name in two fields, called FIRST_NAME and LAST_NAME, while the other system may use a single field called Customer_Name. Likewise, one system may support multiple customer addresses while the other system only supports a single address. Because the internal data format of an application can often not be changed the middleware needs to provide some mechanism to convert one application’s data format in the other’s. We call this step translation.

So far we can send data from one system to another and accommodate differences in data formats. What happens if we integrate more than two systems? Where does the data have to be moved? We could expect each application to specify the target system(s) for the data it is sending over the channel. For example, if the customer address changes in the customer care system we could make that system responsible for sending the data to all other systems that store copies of the customer address. As the number of systems increases this becomes very tedious and requires the sending system to have knowledge about all other systems. Every time a new system is added, the customer care system would have to be adjusted to the new environment. Things would be a lot easier of the middleware could take care of sending messages to the correct places. This is the role of a routing component such as a message broker.

Integration solutions can quickly become complex because they deal with multiple applications, data formats, channels, routing and transformation. All these elements may be spread across multiple operating platforms and geographic locations. In order to have any idea what is going on inside the system we need a systems management function. This subsystem monitors the flow of data, makes sure that all applications and components are available and reports error conditions to a central location.

When a standard message is sent to a queue from a producer, it is sent to the broker, which persists it in its message store. By default this is in KahaDB, but it can configured to be stored in memory, which buys performance at the cost of reliability. Once the broker has confirmation that the message has been persisted in the journal (the terms journal and message store are often used interchangeably), it responds with an acknowledgement back to the producer. The thread sending the message from the producer is blocked at this time.

On the consumption side, when a message listener is registered or a call to receive() is made, the broker creates a subscription to that queue. Messages are fetched from the message store and passed to the consumer; it’s usually done in batches, and the fetching is a lot more complex than simply read from disk, but that’s the general idea. With the default behaviour, assuming the Session.AUTO_ACKNOWLEDGE is being used, the consumer will acknowledge that the message has been received before processing it. On receiving the acknowledgement, the broker updates the message store marking that message as consumed, or just deletes it (this depends on the persistence mechanism).

This figure also illustrates two important messaging concepts:

1. Send and forget

—In step 2, the sending application sends the message to the message channel. Once that send is complete, the sender can go on to other work while the messaging system transmits the message in the background. The sender can be confident that the receiver will eventually receive the message and does not have to wait until that happens.

2. Store and forward

—In step 2, when the sending application sends the message to the message channel, the messaging system stores the message on the sender’s computer, either in memory or on disk. In step 3, the messaging system delivers the message by forwarding it from the sender’s computer to the receiver’s computer, and then stores the message once again on the receiver’s computer. This store-and-forward process may be repeated many times as the message is moved from one computer to another until it reaches the receiver’s computer.

Benefits :Using messaging as an integration or communication style leads to many benefits such as:

● Allowing applications built with different languages and on different operating systems to integrate with each other

● Location transparency – client applications don’t need to know where the service applications are located

● Reliable communication – the producers/consumers of messages don’t have to be available at the same time, or certain segments along the route of the message can go down and come back up without impacting the message getting to the service/consumer

● Scaling – can scale horizontally by adding more services that can handle the messages if too many messages are arriving

● Asynchronous communication – a client can fire a message and continue other processing instead of blocking until the service has sent a response; it can handle the response message only when the message is ready

● Reduced coupling – the assumptions made by the clients and services are greatly reduced as a result of the previous 5 benefits. A service can change details about itself, including its location, protocol, and availability, without affecting or disrupting the client.

Apache CamelApache Camel

Contents

1) Introduction

2) About Camel

3) Messaging Models

4) Example

5) Architecture

Introduction

● Apache Camel “a powerful open source integration framework based on known Enterprise Integration Patterns with powerful Bean Integration”.

● Camel is a mediation and routing engine that lets you implement EIP’s. It uses a simple URI notation to identify the different transport and messaging models.

● Camel is open-source integration framework which allows you to build routes for integration scenario's quickly and efficiently. You can deploy these routes directly on ServiceMix by deploying the plain Spring XML route or by packaging the route in an OSGi bundle.

● The best thing about Camel is that it can be embedded into your current java application to implement integrations. On a larger scale Camel is part of Apache ServiceMix ESB.

● The Camel project was started in early 2007.

About Camel

● Building complex systems from scratch is a very costly endeavor, and one that’s almost never successful. Apache Camel is such an integration framework that provides simple, manageable abstractions for the complex systems you’re integrating and the “glue” for plugging them together seamlessly.

● Camel’s most important features: message routing. At the core of the Camel framework is a routing engine, or more precisely a routing engine builder. It allows you to define your own routing rules, decide from which sources to accept messages, and determine how to process and send those messages to other destinations.

For example: JMS -> JSON, HTTP -> JMS or funneling FTP -> JMS, HTTP -> JMS, JSON -> JMS

● Camel has two main ways of defining routing rules: the Java-based domain specific language (DSL) and the Spring XML configuration format.

● One of the fundamental principles of Camel is that it makes no assumptions about the type of data you need to process. This is an important point, because it gives you, the developer, an opportunity to integrate any kind of system, without the need to convert your data to a canonical format.

● Camel isn’t an enterprise service bus(ESB), although some call Camel a lightweight ESB because of its support for routing, transformation, monitoring, orchestration, and so forth. Camel doesn’t have a container or a reliable message bus, but it can be deployed in one, such as Open-ESB or the ServiceMix. For that reason, we prefer to call Camel an integration framework rather than an ESB. Camel was designed not to be a server or ESB but instead to be embedded in whatever platform you choose.

Camel’s message model

In Camel, there are two abstractions for modeling messages,

■ org.apache.camel.Message

—The fundamental entity containing the data being carried and routed in Camel.

—The Message interface provides an abstraction for a single message, such as a request, reply or exception message. In Camel terminology, the request, reply and exception messages are called in, out and fault messages.

■ org.apache.camel.Exchange

—The Camel abstraction for an exchange of messages. This exchange of messages has an “in” message and as a reply, an “out” message.

—The Exchange interface provides an abstraction for an exchange of messages, that is, a request message and its corresponding reply or exception message.

Example on Routing Files:Suppose you need to read files from one directory (data/inbox), process them in some way, and write the result to another directory (data/outbox). For simplicity, you’ll skip the processing, so your output will be merely a copy of the original file. Below figure illustrates this process.

It looks pretty simple, right? Here’s a possible solution using pure Java (with no Camel) but it still results in 34 lines of code. You have to use low-level file APIs and ensure that resources get closed properly, a task that can easily go wrong. But if an integration framework like Apache Camel is used, we can create a file-polling route in just one line of Java code

Architecture

CamelContextA CamelContext object represents the Camel runtime system. CamelContext is the heart of Camel its where all the routes, endpoints, components, etc. is registered. You typically have one CamelContext object in an application. A typical application executes the following steps.

● Create a CamelContext object.● Add endpoints – and possibly Components, to the CamelContext object.● Add routes to the CamelContext object to connect the endpoints.● Invoke the start() operation on the CamelContext object. This starts

Camel-internal threads that are used to process the sending, receiving and processing of messages in the endpoints.

● Eventually invoke the stop() operation on the CamelContext object. Doing this gracefully stops all the endpoints and Camel-internal threads.

Components

Component is confusing terminology; EndpointFactory would have been more appropriate because a Component is a factory for creating Endpoint instances.

Processor

The Processor interface represents a class that processes a message. Notice that the parameter to the process() method is an Exchange rather than a Message.

RouteBuilders

A route is the step-by-step movement of a Message from an input queue, through arbitrary types of decision making (such as filters and routers) to a destination queue (if any). A DSL wires Endpoints and Processors together to form routes. Camel provides two ways for an application developer to specify routes. One way is to specify route information in an XML file. A discussion of that approach is outside the scope of this document. The other way is through what Camel calls a Java DSL (domain-specific language).

Here are some examples of the DSL using different languages and staying functionally equivalent:

Java DSL

from("file:data/inbox").to("jms:queue:order");

Spring DSL

<route>

<from uri="file:data/inbox"/>

<to uri="jms:queue:order"/>

</route>

Scala DSL

from "file:data/inbox" -> "jms:queue:order"

These examples are real code, and they show how easily you can route files from a folder to a

JMS queue.

Content Based Router

The Content Based Router from the EIP patterns allows you to route messages to the correct destination based on the contents of the message exchanges.

The Content-Based Router examines the message content and routes the message onto a different channel based on data contained in the message.

Message Filter

The Message Filter from the EIP patterns allows you to filter messages.

The Message Filter has only a single output channel. If the message content matches the criteria specified by the Message Filter, the message is routed to the output channel. If the message content does not match the criteria, the message is discarded.

Thank You