|
|
In order to get automation within the Chronopolis Architecture we
|
|
|
have a variety of messages sent with RabbitMQ for communication
|
|
|
between nodes. Messages are comprised of two parts, the header and
|
|
|
the body, each of which is mostly just key/value pairs. We will be
|
|
|
converting messages to JSON when transferring in case we move off
|
|
|
of Java in the future.
|
|
|
|
|
|
Exchanges
|
|
|
----------------
|
|
|
The current exchange that Chronopolis will use is chronopolis-control.
|
|
|
It is a topic exchange from which each consumer will bind queues to. Producers
|
|
|
do not need queues and will only write to the exchange with a routing key.
|
|
|
We'll add some set up information soon for clarity. It should be durable too.
|
|
|
|
|
|
### chronopolis-control setup
|
|
|
|
|
|
1. One
|
|
|
2. Two!
|
|
|
|
|
|
Message Prototype
|
|
|
-----------------
|
|
|
Prototype for each message. The header will always be the same for messages
|
|
|
so only the body will be included in examples below.
|
|
|
|
|
|
__Message Header__
|
|
|
The Correlation ID will follow [RFC-4122][2].
|
|
|
|
|
|
|
|
|
| Key | Value | Type |
|
|
|
| ---------- | ------------ | ------ |
|
|
|
| origin | node name | String |
|
|
|
| timestamp | datetime | String |
|
|
|
| correlationId | Message ID | String |
|
|
|
| returnKey | ??? | String |
|
|
|
|
|
|
__Message body__
|
|
|
|
|
|
| Key | Value | Type |
|
|
|
| ------ | -------- | ------ |
|
|
|
| Key 1 | Value 1 | String |
|
|
|
| ... | ... | ... |
|
|
|
| Key n | Value n | String |
|
|
|
|
|
|
Message Flows
|
|
|
-------------
|
|
|
Links to the various message flows within Chronopolis
|
|
|
|
|
|
Within DPN, message flows follow the format of
|
|
|
|
|
|
flowtype-step-messagetype
|
|
|
|
|
|
Useful Stuff (TBD)
|
|
|
------------
|
|
|
* [Adding Messages](MessageCreation)
|
|
|
* [Adding Message Processors](MessageProcessors)
|
|
|
|
|
|
|
|
|
Current open questions:
|
|
|
----------------------------------
|
|
|
1. Do we want to ask a node if it is ready to receive files?
|
|
|
* This will cause the ingestion node to wait before sending off the
|
|
|
messages for each file in a new collection.
|
|
|
* We can also pull files from the Ingest Service since the Distribution
|
|
|
Service receives a list of all the tokens.
|
|
|
2. For topic names and exchange names, do we want to have a set [naming scheme][1]?
|
|
|
* Would help to organize the flow of messages into a more logical pattern.
|
|
|
3. When replicating files would we want a topic chron.replicate.file.host?
|
|
|
* Would allow each host to listen for files independent of others. On a
|
|
|
successful collection init, the producer can easily route to the host w/
|
|
|
the new routingKey.
|
|
|
|
|
|
Closed questions (can be reopened if needed):
|
|
|
1. Should message headers be the same for all messages?
|
|
|
* Yes
|
|
|
|
|
|
[1]: http://thoai-nguyen.blogspot.com/2012/05/rabbitmq-exchange-queue-name-convention.html
|
|
|
[2]: http://www.ietf.org/rfc/rfc4122.txt |
|
|
\ No newline at end of file |