RabbitMQ Message Broker

The RabbitMQ Message Broker is the heart of the Sepia architecture. It routes all event messages from authors to recipients. The RabbitMQ Message Broker is implemented by RabbitMQ. RabbitMQ is a widely deployed open source message broker and completely independent from the Eiffel community. In other words, there is no Eiffel specific message broker implementation. Instead, Sepia lists a small number of requirements on RabbitMQ servers and clients.

Server Requirements

The RabbitMQ Message Broker SHALL use RabbitMQ version 3.0.0 or later.

Note that Sepia places no requirements on deployment architecture (e.g. distributed or not), authentication enforcement or exchange configuration. These aspects of the message broker are up to the demands in each specific case.

Client Requirements

• Client implementations MAY use any RabbitMQ Client API compatible with the identified RabbitMQ server version (see Server Requirements).
• Client implementations SHALL support RabbitMQ PLAIN authentication.
• Client implementations MAY support other types of authentication in addition to PLAIN.
• Unless stated otherwise in their documentation, client implementations SHALL NOT make any assumptions with regards to server deployment or configuration.
• Unless stated otherwise in their documentation, client implementations SHALL NOT make any assumptions with regards to exchange topology, types or configurations.
• Unless stated otherwise in their documentation, client implementations SHALL NOT make any assumptions with regards to routing scheme.
• Unless stated otherwise in their documentation, client implementations SHALL NOT make any assumptions with regards to queue configurations.
• Any Event Publishing service or pipeline actor implementation accessing the message broker via Direct Publishing SHALL act as a RabbitMQ producer publishing to a RabbitMQ exchange.
• It SHALL ensure that published event types defined in edition-arica of the Eiffel protocol comply with protocol definitions.
• It MAY publish messages on Eiffel-like syntax, containing event types not defined in the Eiffel protocol, as well as other other types of messages completely unrelated to the Eiffel protocol.
• It SHALL support routing keys.
• It SHOULD use a routing key on the form eiffel.<family>.<type>.<tag>.<domainid>, where:
  • family is the non-empty name of a group of Eiffel events to which the current event belongs. The families have not been defined in Sepia but may be in the future. Implementations may choose to use a fixed string in this field.
  • type is the type of the published Eiffel event (i.e. its meta.type member), e.g. EiffelArtifactCreatedEvent.
  • tag is an implementation-specific tag. It can be any non-empty string but must not contain a period.
  • domainid is the non-empty string representing the domain the event applies to. It corresponds to the meta.source.domainId member of an Eiffel event.
• It SHALL support named exchanges.
• Unless stated otherwise in its documentation, it SHALL NOT make any assumptions as to the presence, absence or nature of other producers connected to the same exchange.
• Any Event Persistence service, Event Analysis service, Event Presentation service or pipeline actor implementation accessing the message broker via Real Time Event Parsing SHALL act as a RabbitMQ consumer consuming from a RabbitMQ queue.
• Unless otherwise stated in its documentation, it SHALL NOT make any assumptions as to the presence, absence or nature of other consumers connected to the same queue.

Tutorials for creating RabbitMQ clients are available for multiple languages. These tutorials are highly recommended, as they explain concepts such as routing, exchanges, producers, consumers and queues.