Messaging in the cloud
Messaging is a technology that enables high-speed, asynchronous, program-to-program communication with reliable delivery. Programs communicate by sending packets of data called messages to each other.
You can enable loosely coupled integration for IBM Bluemix PaaS applications and components by using messaging services.
Messaging use cases and available APIs in the Message Hub service
Messaging services provide loose coupling between components of an application in several use cases. A common case is asynchronous worker offload of complex tasks that allows the processes handling these tasks to be scaled independently.
Messaging provides a natural event-driven service model and avoids polling inefficiencies. Messaging provides a way to delay processing, for example, to run a report at a specific time. Messaging can provide responsiveness in an application when integrating with third-party or external services by queueing requests. Across many of these use cases, components that use messaging services can be deployed in distributed locations to create hybrid cloud scenarios.
The IBM Message Hub service is based on Apache Kafka and supports the use of multiple APIs for messaging. Applications can use the Kafka API, Kafka REST API, and MQ Light APIs with this service.
Using publish-subscribe and queue models in Message Hub
In a publish-subscribe model, every message receiver (or consumer) gets a copy of messages published by the sender (or producer). In a queue model, messages are distributed among a pool of receivers (or consumers). When you use the MQ Light API to create a queue model, each receiver will join a destination with sharing enabled. When you use the Kafka API (or Kafka REST API) to configure a queue, each consumer should subscribe by using the same consumer group, and the number of partitions on the topic should be greater than or equal to the maximum number of consumers.
Rationale of the cf option
--no-route when creating a worker offload queue
An application component implementing the worker offload pattern through messaging services should not be configured with an application route in an environment such as IBM Bluemix PaaS. To avoid this, you can use the cf push command with the –no-route option to prevent the Cloud Foundry environment from creating a route on application startup.
Using the MQ Light API to implement topic hierarchies, fault tolerance, and QoS
MQ Light provides a higher level of abstraction than the Kafka API and enables apps to be written quickly and portably in a unified messaging model. It supports the creation of topic hierarchies with flexible subscription models. The MQ Light API provides services for defining message and destination time-to-live and has two delivery quality assurance models. Delivery assurance can be selected from either at most once or at least once with each subscription.