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
Klemen ZAGAR (klemen.zagar@ijs.si)
...
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
...
- Manager – The Manager of the domain.
- CDB – Database Access Layer (DAL) component as an Configuration Database (CDB) for the domain. CDB contains configuration information for individual components, as well as MACI meta-services. CDB is to be defined in a separate document.
- PDB – Persistence Database component for the domain. PDB exposes the same interface as CDB, but it used for persisting internal state of objects. To be defined along with CDB (not implemented).
Wiki Markup Log - Centralized Logger \[8\] of the domain. Implements Telecom Logging Service's Log interface.- NameService – The Naming Context of the domain. See page .
...
- It performs as a name service, resolving CURLs into object references. Multiple CURLs can be resolved in one network call, either by enumerating them or using regular expressions. If a CURL is passed that is outside the current Manager's domain, the Manager forwards the request to the Manager closest to the destination domain to resolve it (see the chapter Inter-domain Communication).
- It delegates the component life cycle management to the Container object and therefore creates no components directly. However, it does maintain a list of all available Containers.
- The Manager uses the configuration database to retrieve relevant configuration for individual components in the domain, as well as locations of other Managers. Manager persists its internal state (such as references to activated components) in its portion of the persistent database.
Wiki Markup In environments with low security requirements maintains a hierarchy of CORBA Naming Service's Naming Contexts (see \[3\]). The Naming Contexts are arranged in such a way that they mirror the hierarchy of components in the domain, as well as relationships between domains (see chapter on Naming Service starting on page<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="810d3ab2-e371-4c0e-b2e6-9997edb3a078"><ac:parameter ac:name="">_Hlt510238890</ac:parameter></ac:structured-macro><ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="d30bac01-15fc-44f5-be86-bc12dde9744c"><ac:parameter ac:name="">_Hlt510238891</ac:parameter></ac:structured-macro> ).
Note: Besides losing security, component lifecycle management and on-demand activation are also not available when relying on the Naming Service alone to provide references to components.
Clients locate Managers by obtaining references to them from well-known locations, such as the web, configuration files and similar.
A Manager is named by a special syntax CURL and can return a reference to itself and other Managers.
Manager is the only interaction that clients have with MACI. Thus, neither component implementers nor GUI client developers need concern themselves with aspects of MACI other than the Manager.
...
- 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).
- Manager of domain sub.root (curl://sub.root/) is accessible as sub.D/Manager resolved at the root NC.
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.
...