OpenMessaging is a cloud-oriented, vendor-neutral open standard for distributed messaging.
Messaging and Streaming products have been widely used in modern architecture and data processing, for decoupling, queuing, buffering, ordering, replicating, etc. But when data transfers across different messaging and streaming platforms, the compatibility problem arises, which always means much additional work. Although JMS was a good solution during the past decade, it is limited in java environment, lacks specified guidelines for load balance/fault-tolerance, administration, security, and streaming feature, which make it not good at satisfying modern cloud-oriented messaging and streaming applications.
An administered object that encapsulates the identity of a message destination for pub/sub messaging.
An object that sending a message to all subscribers of a topic.
An object that is used for receiving messages sent to a topic.
An administered object that encapsulates the identity of a message destination.
At least once: a message will be consumed at least once.
At most once: a message will be consumed at most once, in this semantics, messages may be lost.
Exactly once: a message will be consumed once and only once.
A message that whose body contains a stream of uninterpreted bytes. This message type is for literally encoding a body to match an existing message format. It will be use one of self-defining message types to encode the message body, and users are responsible for decode these bytes in a custom rules.
All messages support the same set of header fields, and these header fields are used by system, which are usually used for such as identify and route messages.
In addition to the system header, OMS provide a built-in user header for adding optional header fields to a message, and these attributes are represented as key-value forms.
This field contains the user's business data.
An unique identifier for a message.
An identity of a message logic destination.
An identity of a message physical destination.
The timestamp of the birth of the message. When a message is sent, this field will be set with current timestamp as the born timestamp of a message in client side.
The host that generated this message. When a message is sent, this field will be set with the local host info of server.
The timestamp stored by the broker. when a message is stored by server, this field will be set with current timestamp of server.
The host info of the server that stores this message. when a message is stored by server, this field will be set with the host info of server.
The startup timestamp that a message can be delivered to consumer client.
The stop timestamp that a message should be discarded after this timestamp.
It represents a message time-to-live value. If the this field is specified as zero, that indicates the message does not expire, and this field has higher priority than START_TIME/STOP_TIME header fields.
OMS defines a ten level priority value with 1 as the lowest priority and 10 as the highest, and the default priority is 5. The priority beyond this region will be ignored. OMS does not require or provide any guarantee that the message should be delivered in priority order strictly, but the vendor should provide a best effort to deliver expedited messages ahead of normal messages.
OMS defines two modes of message delivery:
PERSISTENT: the persistent mode instructs the vendor should provide stable storage to ensure the message won't be lost.
NON_PERSISTENT: this mode does not require the message be logged to stable storage, in most cases, the memory storage is enough for better performance and lower cost.
The keyword indexes will be built by the search keys, users can query similar messages through these indexes and have a quick response.
The message will be delivered by the specified SCHEDULE_EXPRESSION, which is a CRON expression.
This identifier represents a global and unique identification, to associate key events in the whole lifecycle of a message, like sent by who, stored at where, and received by who. And, the messaging system only plays exchange role in a distributed system in most cases, so the TraceID can be used to trace the whole call link with other parts in the whole system.
In BytesMessage, the body is just a byte array, may be compressed and uncompressed, and this field represents the message body compress level, 0 represents uncompress, but vendors are free to choose the compression algorithm and define compression levels, but they must ensure that the decompressed message is delivered to the user.
The oms class provides some static methods to create a MessagingAccessPoint from the specified OMS driver url and some useful util methods.
An instance obtained from OMS, which is capable of creating Producer, Consumer, ResourceManager and other facility entities.
The Connection String describes the details to connect a specific OMS service provider, more details please refer to this doc.
This interface which created by MessagingAccessPoint aims to provide a unified interface of resource management, allowing developers to manage the namespace, queue and routing resources.
A simple object created by MessagingAccessPoint that is used for sending messages on behalf of MessagingAccessPoint.
A simple object created by MessagingAccessPoint that is used for receiving messages sent to a topic, and OMS provides three forms of consumer:
PullConsumer: a consumer which receives messages in using of long polling mechanism，and it also supports submit the consume result by acknowledgement.
PushConsumer: a consumer which receives messages from multiple queues, these messages are pushed from server.
StreamingConsumer: a consumer which can open multiple streams from a specified queue and then retrieve messages from them.
It can be used to intercept message send operation, and view