This page summarizes the deliverables of iteration 1 of the Messaging Service prototype and related efforts.
I. Models
AMQP Analysis
Overview
AMQP provides standardized messaging capabilities between multiple peers. The latest specification (version 1.0) is currently under development, with little expectations for a full implementation into open-source/commercial frameworks until the end of Iteration 2. Hence, the focus of Iteration 1 effort was on version 0.9.1 and the changes it brings from the 0.8 specification used for the FDR prototype implementation of the DDN.
Models
At the meta-model level, the specification defines a protocol with three layers: transport, session, and amqp model. The recommended architecture has more layers including asynchronous I/O, connection manager and framing, API, and application layer. The protocol distinguishes between clients (active/passive) and brokers (exchange) as peers exchanging messages.The 0.9.1 version of the specification distinguishes between multiple instances of exchanges through the concept of virtual hosts, which is removed from later specifications (version 1.0+). Data publishers provide messages to the exchange with the intention of having them stored into message queues for clients. Depending on the intended functionality, an exchange can be durable, temporary or auto-deleted and may have different types. The Direct (amq.direct) and Fanout (amq.fanout) types are expected as defaults from any implementation of the AMQP specifications, with System (amq.*) and Headers (amq.match) as optional types.
Based on the exchange type, the exchange applies a specific routing criteria (e.g., routing key vs routing pattern) to identify the message queue for each received message. Routing criteria is specified via string matching for routing keys or pattern (wildcards are accepted) for topics. Message queues can be exclusive or durable and may be stored in memory or on permanent storage (e.g., disk). There are several lifecycles possible for a message queue including durable, temporary (private), shared (special case of temporary) depending on the intended behavior when dealing with one or more clients.
Consumers subscribe to message queues (may also create them on demand) and listen for incoming messages. Messages may carry both command and data, with a set of predefined commands and expected interaction patterns described within the AMQP specification. Data can be encapsulated into atomic data types such as integers, floats, or complex data types such as field tables.