Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Author Signature:

Date:

Approved by:

Signature:

Institute:

Date:

Keywords: ALMA, ACS, MACI, software|Released by: Mark Plesko, Gianluca Chiozzi|Signature:|

Institute: IJS, ESO

Date:

Management and Access Control Interface Specification


Software Specification

...

KGB Team, Jozef Stefan Institute





Change Record

REVISION

DATE

AUTHOR

SECTIONS/PAGES AFFECTED

 

REMARKS

 

 

0.0

2001-03-16

Matej Sekoranja

All

 

Applying ALMA template, changes in MACI

 

 

0.1

2001-03-20

Klemen Žagar

All

 

Added references. Changed CURL syntax. Introduced Startup and Immortal COBs. Classified three types of databases (CDB, LDB, PDB). Defined Configurable and Constructable interfaces. Extended Administrator interface (get_COB and release_COB notification). Extended Manager interface (get_DB_record). MACI-to-Naming Service mapping.

 

 

0.2

2001-03-06

Klemen Žagar

3, 4, 4.1, 4.6, 5.5, 6

 

Mark Plesko's comments taken into account. Chapters 3 and 4 renamed. Immortal COBs explained. Additional requirements for the Administrator interface added. Code-base manipulation methods of the Activator explained. Naming Service mapping rewritten.

 

 

1.0

2001-04-01

Klemen Žagar

5, 4.2, 4.6, 4.7, 6

 

Database removed from core MACI specification. Interface definitions moved to UML models. Inter-domain communication. Dependancy resolution on VxWorks. Naming Service mapping. Support for retrieving non-COB objects through the Manager.

 

 

1.1

2003-11-11

Matej Šekoranja

All.

 

Ported to new ACS 3.0 MACI IDL.

 

 

1.2

2004-10-08

Klemen Žagar

5.1

 

Manager does not have the "O" kind in the Naming Service.

 

 

1.3

2004-11-15

Matej Šekoranja

4.6, 5

 

Inter-domain Communication update.

 

 

1.4

2005-09-08

Gianluca Chiozzi

5

 

Added note about passing Component references directly between components.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



Table of Contents
1 Summary
2 Introduction
2.1 Scope
2.2 Glossary
2.3 References
3 The Motivation for MACI
4 Concepts of MACI
4.1 Component
4.2 CURLs and Domains
4.3 Component Implementation
4.4 Client
4.5 Administrator
4.6 Manager
4.7 Container
5 Inter-domain Communication
5.1 CURL-to-Naming Service Mapping
5.2 Accessing the Naming Service
5.3 Caveats when Using the Naming Service

...

Anchor
_Toc56321485
_Toc56321485
Scope


Wiki Markup
The scope of this document is restricted to the discussion of MACI interfaces. The requirements for component behavior are a separate topic, discussed in Basic Control Interface Specification (BACI). MACI interfaces are static (in contrast to BACI interfaces, where only the design patterns are known in advance).
This document focuses on the MACI concepts and is not concerned with details such as definitions of interfaces and method signatures. Those can be found in the UML model\[6\] and the on-line documentation\[7\].


Anchor
_Toc56321486
_Toc56321486
Glossary

...

  1. For every domain in the CURL hierarchy there exists a Naming Context (the domain NC) in the NS, which contains the following bindings:
    • NCs of sub-domains (kind "D").
    • For non-root domains, the NC of the parent domain. Such bindings' ID is "Parent" and kind is "D".
    • Bindings to domain's root components, including the Manager. The kind of these bindings is "O".
    • Manager's name is "Manager". Manager does not have a kind!
    • Other objects. Kind must not be "D", "F" or "O".
    • For each root object that has sub-objects, the domain's NC also contains a binding to a NC that contains the sub-objects. The kind of this binding is "F", and ID is the same as the CURL name of the object.
  2. For every node in the component hierarchy there exists a NC (the folder NC). The NC contains:
    • A NC whose ID is "Domain" and whose kind is "D". This binding links to the domain NC of the domain to which the folder belongs.
    • A link to the parent's NC. The ID is "Parent", and the kind is "F".
    • NCs of subordinate hierarchical levels. The kind of these NCs is "F".
    • Other objects. Kind must not be "D", "F" or "O".
    • Components in the node's hierarchical level. The kind of these NCs is "O".


Wiki Markup
Bindings in a hierarchy of NCs are stringified according to the rules given in the Interoperable Naming Service specification \[5\], section 2.4.
*Examples:*


  1. curl://sub2.sub.root/obj/subobj maps to sub.D/sub2.D/obj.F/subobj.O in the NS, resolved at the root domain's NC (notice the reversal of domain name components and the usage of dots and slashes).
  2. Manager of domain sub.root (curl://sub.root/) is accessible as sub.D/Manager resolved at the root NC.



Image AddedImage Removed
Figure 1:Left: Hierarchy of domains (ovals) and components (rectangles). Right: Equivalent hierarchy stored in the Naming Service. Naming Contexts are denoted as ovals, whereas squares represent other objects. Lines denote the bindings.

...