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 An operation is defined as the communication that takes place in order to make an operation on the bit repository. Examples are get and put of data.

Operations must be as simple as possible, based on . They will be based on simple message primitives and data transmission. A primitive is a single request message to the system and the following replies. The primitives are defined on basis of 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

Image Removed

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

...

An example of the Get operation is given in the below figure.

Image Added

Here the full communication will result in an operation. The message communication is divided into two parts, each representing a primitive (identification of pillars and the actual get).

Note that the primitive for identification of pillars can cover request to several pillars, while the primitive for the actual get part only concerns one pillar.

Note also that there can be a number of different reponses, in cases where the pillar want to give information of the progress of the ioperation at pillar level. This can for instance be interesting for DVD pillars where there are several possibly time consuming phases in finding the data - even more so for a put operation.

Conversation Id

We generate a unique conversation id at initiation of a conversation such that it is possible to identify which conversation a message belongs to.