CAPITOL SEGON. ORDENACIÓ DELS SECTORS DE SÒL URBANITZABLE

TÍTOL VII. REGULACIÓ DEL SÒL URBANITZABLE

CAPITOL SEGON. ORDENACIÓ DELS SECTORS DE SÒL URBANITZABLE

ActiveMQ is an open source JMS broker that we use in our examples together with Mule and ServiceMix. You might ask yourself, “Why would we need a separate JMS

Listing 3.13 JiBXUtil class showing how to unmarshal and marshal XML messages

Unmarshals XML to a Java object

Marshals Java object to XML

broker, when we’ve already got a complete ESB?” The answer is rather simple. Mule doesn’t focus on the transport layer; its focus is to provide ESB functionality such as routing and transformation. In other words, for Mule it doesn’t matter whether all the messages are transported over HTTP, JMS, TCP, SMTP, or any of the other sup- ported transports.

If you’re in a production environment you want a reliable transport mechanism, and you may choose JMS. With JMS you can support reliable messaging and ensure that your messages arrive at the target destination. Another advantage of using JMS

is that it’s easily pluggable. You can, for instance, replace ActiveMQ with a different

JMS-compliant broker such as Joram, WebSphere MQ, JBoss MQ, or any of the other dozen implementations.

So what about ServiceMix? Does ServiceMix also require a JMS broker for reliable messaging? Yes, it does. When you run ServiceMix using the default Staged Event- Driven Architecture (SEDA) flow, the message exchanges are routed using the default, nonpersistent, normalized message router. ServiceMix also has the option to run its normalized message router based on a JMS flow, which uses ActiveMQ. The JMS flow provides reliability, clustering, and fail-over capabilities to ServiceMix. ActiveMQ is delivered as part of the ServiceMix distribution, so you don’t have to perform a separate installation as you would with Mule.

EXPLAININGTHE JMS SPECIFICATION

For those of you not familiar with JMS, let’s quickly discuss how JMS works (see figure 3.4).

With JMS it’s possible to create clients that receive messages from a JMS broker and cli- ents that put messages on a JMS broker. These clients are called, respectively, Message- Consumers and MessageProducers. Before creating these clients, follow these steps: Figure 3.4 The important concepts of the JMS specification. The JMS classes that are common when developing JMS-based functionality are shown as well.

1 Obtain a ConnectionFactory —There are two ways to get a connection factory.

The official way is to use JNDI to look up a ConnectionFactory in a JNDI regis- try. We don’t bore you with all the details, but this is the most flexible method and allows you to easily change the JMS broker without altering the client code. The other (not recommended) way is to create a ConnectionFactory program- matically. This may be easier to do, but you’re pretty much wiring yourself to a specific JMS broker.

2 Create a connection —Once you have a ConnectionFactory you can use it to cre-

ate a connection. The ConnectionFactory contains the information on how to connect to the JMS broker.

3 Create a session —Another abstraction layer used by JMS is the session. We can create multiple sessions on a connection, and sessions themselves can have multiple providers and consumers.

4 Create the MessageConsumer or MessageProducer —Now you can create a Message-

Consumer (or a MessageProducer) to receive (or send) on a specific destination via the session instance.

In JMS we have two types of destinations. The first is a queue, which is used to implement point-to-point message channels. With a queue, you can have many different message producers and many different message consumers (though a JMS message can be consumed by only one consumer). In addition to queues, you can use topics, which can implement publish-subscribe message channels. You can have multiple publishers sending messages to a topic, and all the subscribers on that topic will receive the published messages. Note that when no subscribers are listening on the topic, the message may get lost.

We’ve only skimmed the surface of JMS, but this should be enough information to comprehend the JMS-related topics in this and upcoming chapters.

Apache ActiveMQ is a popular JMS broker, which can be used with both Mule and ServiceMix. The ServiceMix distribution even includes an ActiveMQ distribution out of the box. ActiveMQ is a very mature JMS broker and is simple to use and configure. We first look at some of the features of ActiveMQ, and then we show you an example configuration.

ACTIVEMQ FEATURES

So what are the features that are interesting to us?

■ _{Full support of}_JMS_{1.1 —Since we’ll be using the default}_JMS_API_{, we need a}_JMS broker that supports the JMS specification; ActiveMQ provides full support for this specification.

■ _{Supports easy persistence —We need a reliable transport to complement the Mule} and ServiceMix ESBs. For a reliable transport, we need a way to persist messages so that when the ESB goes down, the messages on the JMS broker can be recov- ered. ActiveMQ provides an easy way to use JDBC for persisting messages.

■ _{Spring support —This is a very important feature for us. Since we’re going to} specify most of our reusable components in Spring, being able to configure ActiveMQ with Spring makes it all a lot more understandable.

■ _In-memory_JMS_{provider —Active}_MQ_{can be used as an in-memory}_JMS_provider. This means we can easily start a complete JMS broker from our code. This approach makes testing much more efficient.

Now let’s look at how we can configure ActiveMQ to be used as a reliable message broker.

EXAMPLEOFAN ACTIVEMQ CONFIGURATION

ActiveMQ is configured with an XML file named activemq.xml. Listing 3.14 shows an example ActiveMQ configuration using a PostgreSQL database for persistency.

</beans>

The example ActiveMQ configuration consists of the following parts:

■ Persistency configuration

B

—This section specifies that ActiveMQ must persist the messages in the queues and topics. We also specify the working directory of ActiveMQ (work/activeMQ in this example) where the journal files are being stored. The final configuration here is the database that’s going to be used to persist the messages.

■ Transport connectors configuration

C

—In this section we define how to connect to

the ActiveMQ broker. This is an important section, since it specifies how Mule Listing 3.14 ActiveMQ configuration using a PostgreSQL database for persistency

Configures persistency

B

Defines transport connectors

C

Defines data source

D

and ServiceMix connect to ActiveMQ as their JMS provider. In this example we show that we can connect to this broker over TCP using the port 61616 (this is also the default configuration of ActiveMQ).

■ _{Data source definition}

D

_{—Finally, we configure how Active}_MQ_{can connect to} our PostgreSQL database. These are the common properties you see with any data source configuration.

Because ServiceMix delivers ActiveMQ out of the box, a standard ActiveMQ configuration is already present. By default, ServiceMix doesn’t use database persistency for its message exchanges. When you download ActiveMQ for use with Mule, the default configuration also doesn’t include database persistency. Let’s look at the details of using ActiveMQ with Mule and ServiceMix.

USING JMS AND ACTIVEMQ IN MULEAND SERVICEMIX

If you want to use ActiveMQ in Mule and Servicemix, we need to configure the ESBs in such a way that they can get a reference to the ActiveMQ connection factory. We need this functionality to be able to send and receive messages via a JMS transport.

Let’s start by looking at how to do this in a Mule configuration (see listing 3.15).

In listing 3.15 we specify the configuration of a connection to ActiveMQ by creating a connection factory specific for ActiveMQ

C

. We also configure the connection factory to connect to the default location ActiveMQ is running on: tcp://localhost:61616. Notice that the activemq-conector element is namespace-qualified with a Mule JMS

namespace

B

C

. For each transport Mule provides a transport-specific set of ele- ments and a corresponding namespace. Now we can use the JMS transport functionality to create JMS endpoints. (We show you how to do this in section 3.3, when we present an extensive Mule example.)

Configuring a connection to the ActiveMQ broker in ServiceMix isn’t that much harder. Again we only need to configure a connection factory to use JMS functionality in the ServiceMix environment. Listing 3.16 shows how to configure a connection to ActiveMQ as part of a servicemix-jms xbean.xml configuration.

Listing 3.15 Definition of an ActiveMQ connection in a Mule configuration

B

<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"> <bean id="connectionFactory"

class="org.apache.activemq.ActiveMQConnectionFactory"> <property name="brokerURL" value="tcp://localhost:61616" /> </bean>

</beans>

The ServiceMix configuration is quite similar to the Mule configuration we saw in listing 3.15. The main difference is that ServiceMix doesn’t provide an element for defin- ing an ActiveMQ broker connection, but it uses a Spring bean to create the connection

B

. We show a detailed example of how to define JMS consumers and providers in a servicemix-jms configuration in section 3.4.

In the last couple of sections, we’ve introduced three technologies: Spring, JiBX, and ActiveMQ. This information provides a common background for the examples in this book. In the next section, wel look at setting up the development environment to be able to start working with the book’s examples.

In document AJUNTAMENT DE LES FRANQUESES DEL VALLÈS. TEXT REFÓS REVISIÓ DEL PLA GENERAL D ORDENACIÓ URBANA. NORMES URBANÍSTIQUES. TEXT REFÓS. (página 127-133)