c. Enable loosely coupled integration for IBM Bluemix PaaS applications and components by using Messaging Services
1. Understand MQ Light messaging use-cases and benefits
Messaging services provide loose coupling between components of an application in several use-cases. A very common case is asyncronous worker offload of complex tasks allowing 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 3rd party or external services by queueing requests. Across many of these use-cases, components using messaging services can be deployed in distributed locations to create hybrid cloud scenarios.
MQ Light messaging provides two models for delivery assurance, at most once, and at least once. The first is appropriate when occasional loss of data caused by a communication disruption is acceptable, and the second is required when there can be no loss of data. When using at least once, duplicate messages may appear around communication disruptions and they should to be programmatically discarded. MQ Light buffers messages based upon message and destination time-to-live. When an application subscribes to a topic it may specify a destination time-to-live which will cause MQ Light to store messages at the destination in the event of a receiving application crash. After the destination time-to-live exipres, MQ Light will discard all held messages and stops storing new messages.
2. Handling pub/sub messages in MQ Light with sharing
When two clients attach to the same topic pattern and the destination is configured for sharing, messages sent to the topic are sent to each client in sequence
3. Explain rationale of the cf option –no-route when using the worker offload pattern
An application component implementing the worker offload pattern through messaging services should not be configured with an application route in an envrionment like IBM Bluemix PaaS. To avoid this, you may use cf push with the –no-route option to prevent the Cloud Foundry envrionment from creating a route on application startup.
4. Monitor client health and troubleshoot using the MQ Light service dashboard
Because it is a fully managed messaging service provided by IBM Bluemix, the monitoring and operational capabilities are directly displayed and accessed on the messaging dashboard (see image below). Monitoring and operational capabilities such as ‘client health,’ sent and received messages, filtered messages, problem determination, etc. are displayed by the web-based MQ Light User Interface (UI) that is built into Bluemix.
1. Understand MQ Light messaging use-cases and benefits
Messaging services provide loose coupling between components of an application in several use-cases. A very common case is asyncronous worker offload of complex tasks allowing 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 3rd party or external services by queueing requests. Across many of these use-cases, components using messaging services can be deployed in distributed locations to create hybrid cloud scenarios.
MQ Light messaging provides two models for delivery assurance, at most once, and at least once. The first is appropriate when occasional loss of data caused by a communication disruption is acceptable, and the second is required when there can be no loss of data. When using at least once, duplicate messages may appear around communication disruptions and they should to be programmatically discarded. MQ Light buffers messages based upon message and destination time-to-live. When an application subscribes to a topic it may specify a destination time-to-live which will cause MQ Light to store messages at the destination in the event of a receiving application crash. After the destination time-to-live exipres, MQ Light will discard all held messages and stops storing new messages.
2. Handling pub/sub messages in MQ Light with sharing
When two clients attach to the same topic pattern and the destination is configured for sharing, messages sent to the topic are sent to each client in sequence
An application component implementing the worker offload pattern through messaging services should not be configured with an application route in an envrionment like IBM Bluemix PaaS. To avoid this, you may use cf push with the –no-route option to prevent the Cloud Foundry envrionment from creating a route on application startup.
4. Monitor client health and troubleshoot using the MQ Light service dashboard
Because it is a fully managed messaging service provided by IBM Bluemix, the monitoring and operational capabilities are directly displayed and accessed on the messaging dashboard (see image below). Monitoring and operational capabilities such as ‘client health,’ sent and received messages, filtered messages, problem determination, etc. are displayed by the web-based MQ Light User Interface (UI) that is built into Bluemix.
0 comments:
Post a Comment