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 31 Next »

General overview of the system architecture and functionalities


Below is given a general overview general overview of the system followed by principles for information between system components . A more detailed example of such a system is given on the Bitrepository frontpage.

General overview

There are the following types of clients (and services):* Clients which can be used to perform operations on the bit repository, e.g. PutFile, GetFile

  • Services which actively perform tasks without user triggering, e.g. Alarm Serviceto handle errors and notifications and Monitoring Service to assist in operation of the coordination layer.

There are the following types of pillars seen from the data perspective:

  • A full copy pillar, which contains full copies of delivered files identified uniquely with a service level agreement
  • A checksum pillar (with specific checksum type), which contains derived copies of delivered files, in form of a checksum. The checksums are identified uniquely with a service level agreement in the same way as for full copies pillars.

Principles for information between system components

The necessary information for clients, pillars and coordination layer is:

  • The Clients know how to communicate via the coordination layer. Knowledge of how to identify pillars is defined in the Service Level Agreement (possibly via certificate and psudoname)
  • The Coordination Layer has no direct knowlegde of Pillars or Clients
  • The Pillars know how to communicate via the coordination layer, and can respond to messages according to definitions of certification and possible operations as specified in Service Level Agreements serviced by the pillar.

All need for specific knowledge of components in the system, e.g. physical location of pillars, must be avoided.

  • No labels