Thus far we’ve seen how to set up broker networks and connect to them by explicitly specifying broker URIs (both transport and network connectors). As you’ll see in this section, ActiveMQ implements several mechanisms that can be used by brokers and clients to find each other and establish necessary connections.
MULTICAST CONNECTOR
IP multicast is a network technique used for easy transmission of data from one source to a group of interested receivers (one-to-many communications) over an IP network. One of the fundamental concepts of IP multicast is the so-called group address. The group address is an IP address in the range of 224.0.0.0 to 239.255.255.255 used by both sources and receivers. Sources use this address as a destination for their data, whereas receivers use it to express their interest in data from that group.
When IP multicast is configured, ActiveMQ brokers use the multicast protocol to advertise their services and locate the services of other brokers for the purpose of creating networks of brokers. Clients, on the other hand, use multicast to locate brokers and establish a connection with them. This section discusses how brokers use multicast; the use of multicast by a client will be discussed later.
The URI syntax for the multicast protocol is as follows:
This is no different than the previous URIs with the exception of the scheme portion.
Here’s a snippet from the default ActiveMQ configuration that makes use of multicast:
In the example, the group name default is used instead of a specific IP address. There are two important things achieved with this configuration snippet. First, the transport connector’s discoveryUri attribute is used to advertise this transport’s URI on the default group. All clients interested in finding an available broker would use this connector. This will be demonstrated in the following section.
Next, the uri attribute of the network connector is used to search for available brokers and to create a network with them. In this case, the broker acts like a client and uses multicast for lookup purposes. You can find a complete reference of this protocol at the ActiveMQ website (http://mng.bz/14yJ).
EXAMPLE USE OF THE MULTICAST PROTOCOL
The multicast protocol is somewhat different from the TCP protocol. The difference is the automatic discovery of other brokers instead of using a static list of brokers. Use of the multicast protocol is common where brokers are added and removed frequently, and in cases where brokers may have their IP addresses changed frequently. In these cases, instead of reconfiguring each broker manually for every change, it’s often easier to utilize a discovery protocol.
One disadvantage to using the multicast protocol is that discovery is automatic. If there are brokers that you don’t want to be automatically added to a given group, you must be careful in setting up the initial configuration of the broker network. Careful segmentation of broker networks is important, as you don’t want messages to wind up in a broker network where they don’t belong. Another disadvantage of the multicast protocol is that it can be excessively chatty on the network. For this reason, many network administrators won’t allow its use. Please check with your network administrator before taking the time to configure a network using the multicast protocol.
DISCOVERY PROTOCOL
The discovery transport connector is on the client side of the ActiveMQ multicast functionality. This protocol is basically the same as the failover protocol in its behavior. The only difference is that it’ll use multicast to discover available brokers and randomly choose one to connect to. The syntax of this protocol is:
Its complete reference could be found at the ActiveMQ website (http://mng.bz/96wI).
Using the multicast broker configuration explained earlier, you can run the broker with the following command:
Once the broker is started, run the stock portfolio publisher with the following command:
You’ll notice the following log messages at the application startup:
These messages tell you that the publisher client has successfully used multicast to dis- cover and connect to the local broker.
PEER PROTOCOL
As we’ve seen before, networks of brokers and embedded brokers are useful concepts that allow you to fit brokers to your infrastructure needs. Of course, it’s theoretically possible to create networks of embedded brokers, but this would be quite cumbersome to configure manually. This is why ActiveMQ provides the peer transport connector, as it allows you to more easily network embedded brokers. The peer connector is a utility transport that is a superset of a VM connector that creates a peer-to-peer network of embedded brokers.
The URI syntax of this protocol is as follows:
You can find its complete reference at the ActiveMQ website (http://mng.bz/bIaH).
When started with the peer protocol URI, the application will automatically start an embedded broker (just as was the case with the VM protocol), but will also configure the broker to establish network connections to other brokers in the local network with the same group name.
Let’s walk through a demonstration of this using the stock portfolio example with the peer protocol. In this case, both the publisher and the consumer will use their own embedded brokers that will be networked automatically. Figure 4.7 provides a better perspective of this solution.
Advise the stock portfolio publisher to create its own embedded broker using group1 like this:
Also advise the stock portfolio consumer to create its own embedded broker using group1 like this:
The two commands start two embedded brokers (one for each application) and create a peer-to-peer broker network named group1 between these two brokers. All messages sent to one broker will be available in the other broker as well as any other brokers that might join group1. Note that the overall system operates as if these two applications were using the same centralized broker.
EXAMPLE USE OF THE PEER PROTOCOL
Consider an application that resides on the laptop of a field sales representative who often disconnects from the company network but still needs the application to run successfully in a disconnected mode. This is a common scenario where the client application needs to continue working regardless of whether the network is available. This is a case where the peer protocol can be utilized for an embedded broker to allow the application on the laptop to keep running successfully. In reality, while in disconnected mode, the application is simply sending messages to the local broker, where they’re queued up to be sent at a later time when the network is available again.The sales rep can still log client calls, visits, and so on while the laptop is disconnected from the network. When the laptop is again connected to the network, all of the queued messages will be sent along based on the demand from consuming clients.
FANOUT CONNECTOR
Fanout is another utility connector used by clients to simultaneously connect to multiple brokers and replicate operations to those brokers. The URI syntax as follows:
You can find its complete reference at the ActiveMQ website (http://mng.bz/J7i0).
The fanoutURI can utilize either a static URI or a multicast URI. Consider the following example:
In figure 4.8, the client will try to connect to three brokers statically defined using the static protocol
The same effect could be accomplished by simply using the following URI:
This assumes that the brokers are configured to use multicast to advertise their transport connectors.
By default, the fanout protocol will wait until it connects to at least two brokers and won’t replicate commands to queues (only topics). Both of these features are, of course, configurable with appropriate transport options.
Finally, there are a couple of things you should be aware of if you plan to use the fanout protocol. First of all, it’s not recommended for consuming messages. Its only purpose is to produce messages to multiple brokers. Also, if the brokers you’re using are in the same network of brokers, it’s likely that certain consumers will receive duplicate messages. So basically, the fanout protocol is only recommended for publishing messages to multiple nonconnected brokers.
With the fanout protocol, we come to the end of the discussion on networks of brokers and network connectors. For reference purposes, table 4.2 provides a summary of all the protocols covered in this section.
沒有留言:
張貼留言