Messaging
Messaging enables reliable, asynchronous communication between cloud and on-premises systems. It supports publish/subscribe and queuing models, helping ensure secure, scalable, and real-time data exchange across hybrid environments.
Messaging is one of the integration patterns that are used by the enterprise applications to solve integration challenges. Messaging systems allow independent applications to work together to accomplish some common tasks by exchanging messages without requiring direct connections. Messaging is also known as message-oriented middleware (MOM).
MOM uses a messaging provider to mediate messaging operations. MOM systems are composed of three basic components: clients, messages, and a MOM provider, including an API and administrative tools. The basic process of message exchange is as follows.
- A client (publisher) sends a message by using an API call to a destination managed by a messaging provider. The client continues to do other tasks while the message is being processed.
- The messaging provider routes and delivers the message to one or more clients (subscribers).
- The client (subscribers) receives the message and acknowledges after processing the message successfully.
Using the webMethods Integration messaging solution, you can implement the send or receive (publish or subscribe) or point-to-point messaging styles by bringing the JMS-based messaging capabilities. It provides the infrastructure for implementing message-based solutions that are built on the publish-and-subscribe model.
Key terms in messaging
- Publisher
- A flow service or a workflow that is configured to publish messages to the messaging provider. Other names for a Publisher are Sender or Producer.
- Subscriber
- A flow service or a workflow that is configured to receive messages from the messaging provider. Other names for Subscriber are Receiver or Consumer.
- Destination
- A virtual location through which the clients exchange messages. The publisher publishes messages
to a destination that the messaging provider manages. The subscriber accesses that destination to
consume the messages. The types of destinations are,
- Queue
- A queue is used when a message is intended to be consumed by only one subscriber. Messages are saved in the queue and delivered to subscribers. Thus, a queue guarantees that each message is delivered to one subscriber only. This type of messaging model is known as point-to-point messaging.
- Topic
- A topic is used when a message is intended to be consumed by more than one subscriber. When you send a message to a topic, all subscribers that are associated to that topic receive the message. This type of messaging model is known as publisher-subscriber.
- Message
- A message is a data packet that is sent to a destination. A data packet can contain simple text and documents. A message has three parts: Header, Properties, and Body. The header is the part of the message that is used for routing messages through the system. The properties include application-specific properties that are used to facilitate communication between applications. The body of a message is called the payload.
- Messaging provider
- A messaging provider is a communication platform that receives, stores, and delivers messages
between applications, and can be either internal or external.
- Internal messaging provider
- The internal messaging provider is maintained by IBM. You can publish and consume messages only from workflows or flow services in webMethods Integration. You can manage messaging destinations such as queues and topics from webMethods Integration only. You can publish messages to the internal messaging provider by using the messaging connector.
- External messaging provider
- The external messaging provider is provided by an external vendor, and is hosted on an external system other than webMethods Integration for you to publish or consume messages. You can publish messages to an external messaging provider by using the JMS (Java™ Messaging Service) connector.
- Messaging provider account
- An account that enables the user to establish a connection to the messaging provider. Users can create accounts from the Connectors page. To connect to an internal messaging provider, you must use a preconfigured default account.
- Messaging service trigger
- A trigger for starting a workflow when a message arrives (when a subscriber receives a message).
- Message routes
- A list of routing rules that can be added to a subscriber. An arriving message is evaluated against each rule in the specified order by the subscriber. If an evaluation criterion is met, the invocation that is specified in the routing rule is initiated to do further tasks.
- Routing rule
- A rule that defines how messages must be handled as they arrive at the destination. It consists
of the following components.
- Filter
- An expression that is used for evaluating an incoming message.
- Invocation
- A subscriber-initiated workflow or flow service that does more tasks.
- Default invocation
- The default workflow or flow service that is started by the subscriber if no rules match.
Message exchange process in webMethods Integration
- The publisher publishes messages that are received to a destination, that is, a queue or topic
specified in the publisher's workflow or flow service by using the messaging or JMS connectors.
- The messaging connector is used to publish messages to the internal messaging provider.
- The JMS connector is used to publish messages to the external messaging provider.
- The messaging provider (internal or external) sends the messages to the registered subscribers in the order that they are received.
- The subscriber evaluates the messages in accordance to the routing rules defined. If no rule satisfies the criteria, the default invocation is initiated. If default invocation is not specified, then the subscriber acknowledges the message and no invocation happens.
- The initiated workflow or flow service does the subsequent tasks as configured in webMethods Integration.
Message restrictions in cloud messaging
The following section lists the message limits that are supported in cloud messaging:
- Maximum pending messages
-
The messaging provider can hold up to 10000 messages per queue or topic. The messaging provider drops all messages arriving at the destinations after the hold capacity limit is reached until the number of waiting to be delivered messages decreases. The dropped messages cannot be recovered. Delivered messages are no longer available for consumption by any other subscriber. If there are no subscribers, based on the destination type, the message retention is as follows for internal messaging providers.
- Queue - Messages are retained for 30 days.
- Topic - Messages are removed immediately. However, if there are registered subscribers that are not in the active state, then the message is retained for 30 days. During this period, if the subscriber returns to the active state, the message is delivered and removed from the topic.
Note: For external messaging providers, the retention period is based on the configurations set in the external messaging provider. - Message limits
-
The maximum message limit is 50 MB. However, depending on the situation, the limit might vary as follows.
- If you are using the body/string and body/object fields, then the size limit is less than or equal to 50 MB.
- If you are using the body/data fields for complex messages, then the size limit is slightly less than 25 MB. The decrease is because during encoding, metadata is included for each field or value in the body/data and published. Thus, pay attention to the cumulative size of all fields and values.
- If you want to run a workflow on receiving messages, the maximum message size can be up to 10 MB.