In this blog post lets see the different ways you can connect to a micro broker and some features in micro broker clients. The blog does not get into the details for every single client, but helps you understand various features of micro broker clients and some common configuration.
Here are micro broker clients currently available:
- IA93: C implementation of WebSphere MQ Telemetry transport (Version 3) – C source code provides an API implementation for the client side of the protocol.
- IA92: Java implementation of WebSphere MQ Telemetry transport (Version 3) - Java source code provides an API implementation for the client side of the protocol. (
- Micro broker JMS client (In Lotus Expeditor client) – JMS API implementation for the clients to communicate with micro broker.
- MQTT Version 5 client (In Lotus Expeditor client) – Java implementation of the MQTT Client API Version 5. (
Getting started with using the clients
Some links to resources in the web which help getting started with using the client side API.
Micro broker JMS client
- Samples are provided in IA93. Also a small GUI wmqttsample.jar.
- Inter- and Intra-process communications
What client should one use?
Although one cannot answer this question completely (as its dependent on the various factors), in this post, I will try to help answer this question based on some scenarios which I have come across.. Micro broker JMS clients are used in scenarios when extending enterprise applications usually based on WebSphere MQ to the pervasive world using micro broker as a messaging engine. Its easier to develop as the skill set is widely available and applications can be provider independent. For example, same application can be used with minimal changes to connect to WebSphere MQ or micro broker or any other JMS provider.
If you have a new device of your own, from which you would like to send and receive messages, then MQTT would be a right choice. You can implement MQTT client side using the specification in www.mqtt.org and communicate with the micro broker that implements the server side of MQTT. You can implement your own client having a subset of MQTT client features using the specification in any language and connect to the micro broker.
A driving force for MQTT I feel lies in its simplicity to use. Also MQTT client implementation that is already available can be used in many memory constraint environment. The client takes very less memory. For example, if you like your PDA or a smart phone to communicate with the micro broker, then MQTT would be right choice. Since MQTT has a very small header, it can be used networks where data transfer costs. You can see more use cases in the red book.
Micro broker client Interoperability
The messages sent to the broker from one client and be received by a different client. For example, messages sent from a MQTT V5 client can be received by a JMS client connected to the broker. If the user properties are set in the JMS client they are retained when received by MQTT V5 client. A message sent from a MQTT V3 client will be received as a bytes messages by the MQTT V5 or a JMS client. If a message sent from a JMS client is received by a MQTT V3 client only the payload can be seen.
Micro broker and its client implementations provides security features. Hence clients can connect securely to the broker using encryption, authentication and authorization features. Following links help in developing a secure micro broker V5 client:
- Quick guide to using SSL/TLS support in MQTT and the micro broker
- Developing and Deploying Applications using IBM Lotus Expeditor Micro Broker
- Configuring micro broker security
Securing a JMS client is much easier as its just a few connection factory properties that need to be set. There is another important thing to note about security is the platform support. The micro broker client can use the security features in Expeditor Device EE (jclDevice) and Expeditor Desktop EE (jclDesktop) java environment.
There are many security related configuration and features available. There have been discussed in the information center and redbook. Let’s not get into the details in this blog post.
There are scenarios where the micro broker and the client runs in the same JVM. Especially when developing Lotus Expeditor applications one bundle can run the micro broker and other applications can be developed to use the same micro broker. Micro broker provides a feature where client use local binding. This feature does not use the TCP/IP layers. It makes direct function calls for communication with the broker hence making the communication faster and simpler.
Remote broker administration client
The micro broker provides a administrative API can be used to create/modify/remove broker components. This admin client is also a MQTT client that uses micro broker system topics to administer the broker. In effect it uses the publish/subscribe feature of micro broker to administer the micro broker itself. Security features can be configured to ensure that only users having permissions can administer the micro broker.
Micro broker need no configuration for most of the scenarios. But in some cases, the micro broker configuration needs a little configuration. Let’s look at configuration from a scenario’s perspective as the information center and the javadoc explains every configurable parameter in detail.
- Getting a higher performance: Set the micro broker persistence to use memory persistence instead of disk persistence
BrokerDefinition.setPersistenceDefinition()… This boosts the performance at the risk of loss in messages on shutdown. Also if the application is design to shutdown correctly every time, the shutdown persistence can be used so that the messages are written to the disk message store only when application closes normally without a crash.
- Message sequence Vs Performance: The in-flight window size can be chosen as
MQTT_V3_HIGH_INTEGRITYif message sequence is really very important in all the scenarios when compared to performance. The parameter plays a very important role when there are frequent network disruptions.
- Keep alive time: This is specified using the client API. Plays a important role to keep the client connect to the micro broker. The keep alive messages are special messages that flow between the broker and client when there is no other data flow. If the client and broker are on the same machine, there keep alive can be a higher, this will reduce the flow of keep alive messages. In case of fragile networks where connection keeps dropping, the keep alive needs to be reduced to a low value.
- Last Will and Testament (LWT): Consider a scenario when running a MQTT client on a fire alarm, its important an administrator knows that client disconnected unexpectedly and requires attention. LWT is also a client side configuration that allows broker to publish a message to a topic when the client unexpectedly drops the connection. This usually happens after the keep alive message does not flow.
- MQTT persistence: If the messages should never be lost and also should never be delivered more than once, QOS 2 is a choice, but that’s not sufficient .. MqttPersistence is needs to be implemented. Consider a scenario where the client sends a message but doesn’t receive the acknowledgement and during this period the client goes down. The Mqtt persistence enables saving this message ensure once and only delivery happen even if there is a client side crash.
Now that you have seen different client features, the most interesting one is actually buffering… Simply put, its a way clients can save messages when the client is not connected to the broker. The buffering options are available with the JMS clients and can be enabled with simple connection factory properties (
com.ibm.msg.client.mqtt.MQTTConstants.MQTT_BUFFERED). With this option enabled, when the client looses the connection to the broker, and an attempt to send the message is made, it gets buffered without throwing any exception to the application. The connection control policies can be set on control the behavior of this buffering.
The buffering of messages won’t happen when the client to broker connection is alive. This comes into play only when the connectivity is to the broker is broken. Also its important to configure the buffering properties like buffer size to suite the needs.
RSMB bridge to Micro broker
RSMB can also bridge to micro broker allows messages to be passed between these broker. From a micro broker perspective its just like an MQTT C client connecting to micro broker.
Micro broker broker another Micro broker
When a bridge is created from one micro broker to another, from a remote micro broker perspective its like a client connection and can’t differentiate it from an another client connect to that micro broker. The bridge can use JMS, MQTT V5 or MQTT V3 to connect to the remote micro broker.
I hope you would have an idea of various micro broker client features and some common configuration.
Blog by,Neeraj Krishna (firstname.lastname@example.org)