The micro broker logically consists of three major components: the broker, the bridge, and the clients. In addition, an administration interface provides a method of controlling the behavior of the micro broker.
The broker is the component to which client applications connect to perform both point-to-point and publish and subscribe messaging. It handles putting and getting messages from queues, and the matching of publications to subscriptions and the subsequent distribution of publications to subscribing applications. The broker also manages the persistence of messages to ensure message delivery at the required quality of service.
It acts as a hub for routing messages between clients and with the aid of the bridge, other messaging servers. The broker can store messages destined for a client that is not connected and make them available to the client when it reconnects. In addition, it stores messages on behalf of the bridge and makes them available when the messaging servers that the bridge connects to are on line.
The broker supports three different types of persistence for storing messages and subscriptions. The type of persistence is selected when a broker is created and is based on how the broker is to be used in a particular situation. The types of persistence supported are:
Where data (messages and subscriptions) only ever reside in memory. In the event of a failure or the broker being shutdown, the data will be lost.Shutdown
Data resides in memory until the broker is shutdown, at which point the data is persisted. In the event of a failure, the data will be lost.Full persistence
Data is always written to a persistent store using transactions and will survive both a failure and shutdown. The persistent store is a purpose-designed high-performance message store that resides in flash memory, on disk, or where appropriate for the particular device running the micro broker.
The bridge is the component of the micro broker that connects and routes messages to and from other messaging servers to form more sophisticated messaging topologies. The bridge allows messages to be routed between the micro broker and the following messaging servers:
- Other micro brokers
- WebSphere® MQ
- WebSphere Message Broker
- WebSphere Application Server
- Any JMS provider
The bridge can route messages between the micro broker and one or more other messaging servers. If the bridge cannot connect to a specific messaging server, messages destined for that server can be stored by the broker. When the messaging server becomes available, the bridge will connect to it and transfer the stored messages. In addition, the bridge can transfer pending messages from the messaging server to the broker.
Typically, each type of messaging server supports its own messaging protocol and its own message formats. The bridge plays the role of intermediary, routing messages across different protocols and transforming messages to a format acceptable by each messaging server.
The bridge is a key component in the micro broker, as it is the link back into the enterprise. It performs the following functions:
- Allows administrators to define transformation logic to modify or discard messages as they flow to and from the micro broker
- Maps message flows from destinations within the micro broker to those of a remote messaging server and vice versa
- Allows local queues and topics to be routed to and from remote queues and topics - If desired, queues may be routed to topics and vice versa, as well as queues to queues and topics to topics
Three connectors are supplied to connect the bridge to remote endpoints. They consist of two types of JMS connector and an MQTT connector:
- WebSphere MQ JMS to connect to a remote WebSphere MQ queue manager
- JNDI JMS to bridge to a third-party JMS provider that supports JNDI administered objects
- Connects the micro broker to another messaging server that supports the MQTT protocol, such as WebSphere Message Broker or another micro broker
Application programs interact with the broker using a client library. The client library enables application programs to be executed in a number of ways:
- Within the same Java runtime process as the micro broker itself
- On the same machine as the micro broker but within a different runtime process
- On a different machine to the micro broker
In general, clients do not persist messages; they simply provide a means for an application to interact with other clients (applications and services) using a broker or an intermediary. Before a client can interact with a broker, the client must first connect to the broker. Once connected, messages can be sent and received. A client does not need to be continuously connected to a broker to receive messages to which it has subscribed. The broker can store messages on behalf of a client, allowing the client to receive stored messages when it next connects. This provides an additional level of decoupling between sending and receiving clients. Put another way, a client can send messages to other clients that may not be running when the message is sent. Two types of client are provided for use with the micro broker.
- JMS Client
This client supports the Java Messaging Service (JMS) API specification. JMS is a messaging standard supported by many enterprise level products.
The JMS Client provides a buffered mode in which an application is able to send messages regardless of the true state of the connection with the micro broker. This allows the client to operate in environments where the connection to the micro broker may not always be available. The client stores the messages, forwarding them to the broker when the connection is reestablished.
- MQTT Clients
These clients are used for more specialized situations such as in devices with constrained environments or where the full JMS API is not required.
There are two versions of the MQTT protocol supported by micro broker and its clients. They are:
- MQTTv3, which provides publish and subscribe capabilities to topic destinations using a simple bytes payload format
- MQTTv5, which provides both topic and queue destinations. Messages can have user properties defined on them and there are predefined payload formats. This version of the protocol provides improved interoperability with JMS messages.
Clients are provided in three languages:
- Java clients are provided for both v3 and v5. The v3 is provided for backwards compatibility. Users are encouraged to use the v5 client where possible. These clients can run on both Desktop and Device platforms.
- A .NET client is provided for v5. This client targets the .NET Compact Framework making it suitable to run on small devices such as mobile phones or PDAs.
- A C client is provided for v3. Each client provides complete API documentation that describes its full capabilities.
In addition to micro broker, the v3 clients can also be used to connect to other messaging servers including IBM® WebSphere Message Broker and IBM WebSphere Premises Server.
Parent topic: Lotus Expeditor micro broker overview: XPD622