Before discussing the details of connectors and their role in the overall ActiveMQ architecture, it’s important to understand connector URIs. Uniform resource identifiers(URIs), as a concept, aren’t new, and you’ve probably used them over and over again without realizing it. URIs were first introduced for addressing resources on the World Wide Web. The specification (http://mng.bz/8iPP) defines the URI as “a compact string of characters for identifying an abstract or physical resource.” Because of the simplicity and flexibility of the URI concept, they found their place in numerous internet services. Web URLs and email addresses we use every day are just some common examples of URIs in practice.
Without going too deep into discussing URIs, let’s briefly summarize the URI structure. This will serve as an ideal introduction to URI usage in ActiveMQ in regard to connectors. Basically, every URI has the following string format:
Consider the following URI:
Note that the mailto scheme is used, followed by an email address to uniquely identify both the service we’re going to use and the particular resource within that service. The most common form of URIs are hierarchical URIs, which take the following form:
This kind of URI is used by web browsers to identify websites. It’s a type of URI known as a URL (Uniform Resource Locator). Below is an example:
Because of their flexibility and simplicity, URIs are used in ActiveMQ to address specific brokers through different types of connectors. If we go back to the examples discussed in chapter 3, you can see that the following URI was used to create a connection to the broker:
This is a typical hierarchical URI used in ActiveMQ, which translates to “create a TCP connection to the localhost on port 61616.”
ActiveMQ connectors using this kind of simple hierarchical URI pattern are sometimes referred to as low-level connectors and are used to implement basic network communication protocols. Connector URIs use the scheme part to identify the underlying network protocol, the path element to identify a network resource (usually host and port), and the query element to specify additional configuration parameters for the connector. The anatomy of a URI is shown in figure 4.1. This URI extends the previous example by also telling the broker to log all commands sent over this connector (the trace=true part). This is just one example of an option that’s available on the TCP transport.
The failover transport in ActiveMQ supports automatic reconnection as well as the ability to connect to another broker just in case the broker to which a client is currently connected becomes unavailable. As will be discussed in chapter 10, ActiveMQ makes this easy to use and configure through the use of composite URIs. These composite URIs are used to configure such automatic reconnection. In figure 4.2, you can see an example of a typical composite URI.
Note that the scheme part or the URI now identifies the protocol being used (the static protocol will be described later in this chapter) and the scheme-specific part contains one or more low-level URIs that will be used to create a connection. Of course, every low-level URI and the larger composite URI can contain the query part providing specific configuration options for the particular connector.
Transport connectors:
In order to exchange messages, producers and consumers (clients) need to connect to the broker. This client-to-broker communication is performed through transport connectors. ActiveMQ provides an impressive list of protocols clients can use to exchange messages. The requirements of ActiveMQ users in terms of connectivity are diverse. Some users focus on performance, others on security, and so on. ActiveMQ tries to cover all these aspects and provide a connector for every use case.
Here you’ll learn how transport connectors are configured in the ActiveMQ configuration files and adapt the stock portfolio example to demonstrate various connectors. In the following sections, we’ll go through protocols available for connecting to the broker over the network, as well as introduce the concept of the embedded broker and Virtual Machine Protocol used for communicating with brokers inside your application (a topic that will be continued in chapter 7).
Configuring transport connectors
From the broker’s perspective, the transport connector is a mechanism used to accept and listen to connections from clients. If you take a look at the ActiveMQ demo configuration file (conf/activemq-demo.xml), you’ll see the configuration snippet for transport connectors similar to the following example:
As you can see, transport connectors are defined within the
The preceding snippet defines four transport connectors. Upon starting up ActiveMQ using such a configuration file, you’ll see the following log in the console as these connectors start up:
From the client’s perspective, the transport connector URI is used to create a connection to the broker in order to send and receive messages. Sending and receiving messages will be discussed in detail in chapter 7, but the following code snippet should be enough to demonstrate the usage of the transport connector URIs in Java applications:
- ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616");
- Connection connection = factory.createConnection();
- connection.start();
- Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
With this basic understanding of configuring transport connectors, it’s important to become aware of and understand the available transport connectors in ActiveMQ. But before we start explaining particular connectors, we must first adapt our stock portfolio example so it can be used with different transport connectors.
Adapting the stock portfolio example
Chapter 3 introduced a stock portfolio example that uses ActiveMQ to publish and consume stock exchange data. There, we used the fixed standard connector URI since we wanted to make those introductory examples as simple as possible. In this chapter, we’ll explain all protocols and demonstrate them by running the stock portfolio example using each of them. For that reason, we need to modify the stock portfolio example so it will work using any of the protocols.
- Listing 4.1 is a modified version of the main() method from the stock portfolio publisher.
- public static void main(String[] args) throws JMSException {
- if (args.length == 0) {
- System.err.println("Please define a connection URI!");
- return;
- }
- Publisher publisher = new Publisher(args[0]);
- String[] topics = new String[args.length - 1];
- System.arraycopy(args, 1, topics, 0, args.length - 1);
- while (total < 1000) {
- for (int i = 0; i < count; i++) {
- publisher.sendMessage(topics);
- }
- total += count;
- System.out.println("Published '" + count + "' of '" + total
- + "' price messages");
- try {
- Thread.sleep(1000);
- } catch (InterruptedException x) {
- }
- }
- publisher.close();
- }
Note that one more argument has been added to the publisher: the URL to be used to connect to the appropriate broker.
The same principle can be used to modify the stock portfolio consumer. In the following listing, you’ll find the stock portfolio consumer’s main() method modified to accept the connection URI as a first parameter.
- Listing 4.2 Modifying stock portfolio consumer to support various connector URIs
- public static void main(String[] args) throws JMSException {
- if (args.length == 0) {
- System.err.println("Please define connection URI!");
- return;
- }
- Consumer consumer = new Consumer(args[0]);
- String[] topics = new String[args.length - 1];
- System.arraycopy(args, 1, topics, 0, args.length - 1);
- for (String stock : topics) {
- Destination destination = consumer.getSession().createTopic(
- "STOCKS." + stock);
- MessageConsumer messageConsumer = consumer.getSession()
- .createConsumer(destination);
- messageConsumer.setMessageListener(new Listener());
- }
- }
Note that the message flow between the producer and the consumer is the same as in the original example. With these changes, the examples are now ready to be run using a variety of supported protocols. Let’s now dig into the particular transport connectors. In the following section we’ll see what options you have if you want to connect to the broker over the network.
沒有留言:
張貼留言