Important design decisions
Overall Description
The coordination layer offers communication through a message broker and a data transmission via https. This is illustrated in the below figure. In general communication is initiated and actions are coordinated via the message broker, while the actual transmission of data is done via data transmission.
There is no intelligence in the Coordination Layer and it is the clients that are responsible for choices that involves intelligence e.g. in choosing an alternative pillar for request of data (according to Service Level Agreement).
Message Broker
It is assumed that
- the underlying low level protocol for message transmission is specified as part of the message broker, and thus this will not be a addressed directly in this architecture
- the message broker software is persistent
Communication
Asynchronous communication
All communication is asynchronous, unless it is explicitly specified to be synchronous. This enables return of answers of transactions to be in arbitrary order.
Start communication via Topic
All communication via the Coordination layer starts via a Topic that is send to all. It is up to the individual subscribers to determine whether it is a message that concerns them, for example a GetTime message only concern the pillars involved in a certain service level agreement.
Atomic messaging in simple operations
Operation must be as simple as possible, based on atomic weldefined messages . This serves to give simplicity, and to get as little overlap between different operations as possible.
Operations are seen as a sequences of messages which collectively correspond to a full operation
a
Using Get
s example
The Get operation can begin by asking pillars who will be the fastest, or it can start by actually sending a get message for a specific default pillar.
In the strict interpretation of single operations this will be seen as two operations
- GetTime
- Get
The difference between the two get scenarios will be that the first will both consist of a GetTime and a Get operation, while the later will only consist of a Get.
The below figure illustrates the messages of the two operations, where messages belonging to the same communication in an operation is placed edge to edge. note that it only includes messages on the message bus, i.e. excluding the actual data transmission.
Since each communication is started via a (SLA) topic this means that the GetTime is sent to a topic. The Get operation is addressed to a specific pillar queue, but it usually preceded by a GetTime, such that the comunication is started via a topic. This is illustrated in the below sequence diagram
<TBD> See http://wiki.statsbiblioteket.dk/BitmagasinWiki/Sekvens1
DIAGRAM NOT UPDATED!
The advantages are:
- the communications work similar for different operations and scenarios
- it will be easy to handle shift in services, e.g. exchanging one primary pillar with another, exchanging pillars in a SLA etc.
The disadvantages can be:
- there may be a heavy load of messages on the SLA topic that all subscribers must go through in order to find the ones interesting for themselves.
Reuse and overlap between operations
- Overlap med protokolspecifikation
. Design skal baseres på så meget overlap mellem de enkelte operationer som muligt, f.eks. getchecksums og get. - Paging af requests
. Klienten indeholdertilstand nok til at paginere sine requests på forhånd, og sende dele via dataprotokollen
Software
Independence
In the design we need to ensure that we are as independent of the software chosen as possible. If special features are used, e.g. for optimisation, then the design must be flexible enough to skip use of the special features at a later stage.
Data Transmission
It is assumed that
- it is sufficient to identify a data transmission transaction by a token
- the token is sufficient information as basis for completion of a data transmission
Use of tokens
Tokens are used as designation of where the data can be put to or downloaded from.
Issuing of token is always done by client in client/pillar communications. Creation of the actual connection is done by the pillar.
Paging
Paging is in the first versions managed by a simple mechanism where a segment of a file is identified by parameters. Any Get command can contain an offset along with a length parameter, which defines the segment of the file. this is also sufficient to handle receival of divided files, and thus enabling rudimentary support of restart of an interrupted transmission.
Certifications
Encryption rules and credentials must be specified in special unit in organisation. This is partly treated in configuration of SLA data.