Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

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.

<TBD> An example can be found in http://wiki.statsbiblioteket.dk/BitmagasinWiki/Sekvens1

DIAGRAM NOT UPDATED!

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. For example the Get operation consists of a sequence of 5 messages as illustrated below. Note that it is divided, since the GetTime part can cover request to several pillars while the Get part only concern one pillar. Note that the actual data transmission is not included here although it will be part of a full operation.

Reuse and overlap between operations

The operations are design to have as many similarities and overlapping definitions as possible. For instance the getChecksums must work simmilar to Get. Paging of data and parameters must work in the same way.

Paging af requests

It must be possible to make paging of request parameters. Paging of parameters can for instance be the case for object ids in a random check of files. It is needed since we cannot assume that clients can make prior pagination.

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.

  • No labels