Skip to content

Latest commit

 

History

History
81 lines (56 loc) · 2.8 KB

README.md

File metadata and controls

81 lines (56 loc) · 2.8 KB
Raw

O5 Messaging

Messaging defines the way o5/j5 applications share data. There are three topologies available, defined below.

Applications are called Workers when they are the recipient of messages, Senders are the ... sender.

Workers expose gRPC endpoints for each group of messages they receive, and an rpc endpoint for each specific message type.

The gRPC definition for all messaging endpoints must return google.protobuf.Empty - even for Reply type queues - as no service should ever be waiting for a reply.

service FooTopic {
  option (pentops.messaging.v1.config).broadcast.topic_name = "foo";
  rpc Bar(BarMessage) returns (google.protobuf.Empty);
}

Senders fall into two broad categories: Those with databases and those without.

Any sender with a database should use the Outbox pattern, where outbound messages are stored in a table, and committed atomically with other database changes. The platform will then take messages from the outbox table and send the message through the messaging infrastructure.

Senders without databases, e.g. a translation service, or even senders which have a database but do not mutate state in message processing (e.g. a read-only lookup reply) can instead send messages to the messaging infrastrcutre using gRPC requests intercepted by the platform. The platform will expose the gRPC service as defined in the protos and foward the messages as required. The platform returns OK + Empty when the message has been safely stored in the messaging infrastructure.

Broadcast

Broadcast Topology

  • Zero or more Sender applications
  • Exactly one 'Topic'
  • Zero or more Worker applications

Unicast

Unicast Topology

  • Zero or more Sender applications
  • Exactly one Worker application

Reply

Reply Topology

  • Exactly one Worker application
  • Exactly one Input Queue
  • Zero or more Sender applications

Request Reply Flow

Both the Request and Reply messages contain a field 'request' of type j5.messaging.v1.RequestMetadata, which has 'context' - a free byte field, and 'replyTo'.

A replier must set the 'request' field in the reply message to the 'request' value in the request message.

The request field is in the application space so that it can be accessed and stored by the worker.

The value of replyTo in the initial request is handled by the platform, not the application code.

The platform will set the replyTo field in the request to the unique service name used in subscriptions.