A flexible messaging system provides a variety of ways for building and deploying messaging applications and for clients to connect and communicate with one another and with message brokers. Fuse ESB Enterprise builds upon this basic flexibility with additional features.
Fuse ESB Enterprise's messaging service provides a variety network protocols that enable producers and consumers to communicate with a broker:[2]
Extensive Messaging and Presence Protocol (XMPP)—Enables instant messaging clients to communicate with the broker.
Hypertext Transfer Protocol/Hypertext Transfer Protocol over SSL (HTTP/S)—Favored protocol for dealing with a firewall inserted between the broker and its clients.
IP multicast—Provides one-to-many communications over an IP network. It enables brokers to discover other brokers in setting up a network of brokers, and clients to discover and establish connections with brokers.
New I/O API (NIO)—Provides better scalability than TCP for client connections to the broker.
Secure Sockets Layer (SSL)—Provides secure communications between clients and the broker.
Streaming Text Oriented Messaging Protocol (STOMP)—A platform-neutral protocol, it supports clients written in scripting languages (Perl, PHP, Python, and Ruby) in addition to clients written in Java, .NET, C, and C++.
Transmission Control Protocol (TCP)—For most use cases, this is the default network protocol.
User Datagram Protocol (UDP)—Also deals with a firewall inserted between the broker and its clients. However, UDP guarantees neither packet delivery nor packet order.
Virtual Machine (VM)—Provides connection between an embedded broker and its clients.
For details, see the Broker Client Connectivity Guide.
Fuse ESB Enterprise's messaging service provides client-side APIs for C, C++, and .NET, through OpenWire's binary encoding format. It provides client-side APIs for Perl, PHP, Python, and Ruby, through STOMP's simple text-oriented encoding format.
You can deploy a broker as a standalone that hosts clients running in other processes and other locations, or as an embedded broker that can run client and broker functions concurrently in one process, while still enabling connections to clients running in other processes at other locations. You can configure standalone and embedded brokers to work together to provide a more resilient network of brokers (see Network of brokers).
For complex messaging scenarios, you often need to implement message routing and mediation logic. Fuse ESB Enterprise's messaging service allows you to deploy routes using any of the Enterprise Integration patterns (EIPs), supplied by Apache Camel, directly into a broker instance. Deploying routes in the broker enables you to optimize performance by using the VM transport for routing messages between JMS destinations and to limit the number of artifacts you need to deploy and manage.
For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies) and Camel in Action (Ibsen and Anstey).
Provide a mechanism for producers to send the same message to multiple destinations at the same time.
A composite destination treats a string of multiple, comma-separated destinations as one destination, but sends messages to each of the individual destinations. You can create composite destinations that are homogeneous—made up of either all topics or all queues—or that are heterogeneous—made up of a combination of topics and queues.
For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).
Provide a mechanism for publishers to broadcast messages via a topic to a pool of receivers subscribing through queues.
To do so, consumers register a subscription to a queue that is backed by a virtual
topic, like this: Consumer.<qname>.VirtualTopic.<tname>.
When the producer publishes messages to the virtual topic, the broker pushes the messages out to each consumer's queue, from which the consumers retrieve them. This feature enables you to failover queue subscribers, to load balance messages across competing queue subscribers, and to use message groups on queue subscribers.
For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).
[2] The default wire protocol used to serialize data for transmission over the network connection is OpenWire (see Client-side APIs).
 |  |  |
 |
