You can send request messages directly to a client session, a set of
client sessions, or a message path. The recipient of a message can respond to the
Typed requests and responses
Each request and response messages has a data type. The data type can be one of the
The data type of the response is not required to be the same as the data type
of the request it responds to.
When you send a request, you specify the data type of the request message and the
data type of the response message it expects. When you register a handler or a
stream to receive requests and respond to them, you specify the data type of the
requests it receives and the data type of the responses it sends.
Data types are organized in a hierarchy of compatibility.
A request or response with a data type at a lower (more specific) level of
the hierarchy can be received by a stream, handler, or requester that is expecting a
message with a data type at a higher (more general) level of the hierarchy. For
example, a request message with a string data type, can be received by a stream or
handler that specifies string, JSON, or bytes as the request type.
The message path is made up of path segments separated by the slash character (/).
Each path segment can be made up of one or more Unicode characters. The slash
character (/) is not permitted in any path segment. The restrictions for message
paths are the same as those for paths at which topics can be bound. For more
information, see Topic naming.
However, messaging is entirely separate from streaming data through topics:
Message paths are unrelated topic paths. Sending a message does not change
the state of any topic and does not publish the message to topic
An application can bind a topic to a topic path and use the same path as a
message path. This is a useful convention where the messages are related to
the topic in some way. The messages sent to the message path do not interact
with the topic in any way.
If a topic is bound to the path used by messaging, the data type of the
topic does not affect the data type of any messages sent using the message
The security permissions required to use a path for messaging are separate
from those required to use a topic bound to that path to stream data.
One-way messaging (deprecated)
Note: One-way messaging was deprecated in Diffusion™ 6.2
and will be removed in a future release. Use request-response messaging instead.
Diffusion also provides a capability to send one-way
messages to a client session, a set of client sessions, or a message path. These
messages cannot be responded to directly.
In one-way messaging, the message data is not typed. Applications are responsible for
serializing messages to and from a binary format.
Messages sent using one-way messaging can include additional options, such as headers
and a message priority. These additional options are provided to allow compatibility
with messaging to publishers.
One-way messaging provides the following guarantees:
If sending to a message path completes successfully, the message was
definitely passed to a publisher or a message handler registered by a client
If sending to a session completes successfully, the message was definitely
passed to a message stream registered by the session.
When sending to a filter completes successfully and returns the number of sessions
that match the filter, one-way messaging cannot guarantee that the message has been
delivered to those sessions.