Author Signature:


Approved by:




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

Institute: IJS, ESO


Management and Access Control Interface Specification

Software Specification

Klemen ZAGAR (



Gasper TKACIK (

KGB Team, Jozef Stefan Institute

Change Record











Matej Sekoranja



Applying ALMA template, changes in MACI





Klemen Žagar



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.





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.





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.





Matej Šekoranja



Ported to new ACS 3.0 MACI IDL.





Klemen Žagar



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





Matej Šekoranja

4.6, 5


Inter-domain Communication update.





Gianluca Chiozzi



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


This is the Management and Access Control Interface (MACI) Specification document. MACI is a part of Advanced Common Software (ACS) software.



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\].



  1. ALMA-SW-NNNN, Revision 0.0, Basic Control Interface Specification, Gašper Tkačik.
  2. CORBAservices – Property Service (chapter 13), OMG. Available at
  3. CORBAservices – Naming Service (chapter 3), OMG. Available at
  4. CORBA 2.3.1 Architecture and Specification, OMG. Available at:
  5. Interoperable Naming Service Specification, OMG. Available at
  6. ACS UML model. Available at
  7. ACS on-line documentation. Available at
  8. ACS Logging and Archiving Specification. Available at

The Motivation for MACI

In abstract terms, a control system can be viewed as a collection of services that enable the interaction between the controlled entities and the clients. Controlled entities are mostly physical devices and other instrumentation. Clients are usually human users that wish to manipulate the controlled entities.
When the control system is created as a collection of software components, two layers of functionality must be kept separate:

Figuratively speaking, services provide content of the control system, while meta-services provide its form. Such a separation, not only on the conceptual, but also on the programmatic level is necessary for the following reasons:

To reiterate, the realization of these goals depends on the successful separation of the service and meta-service layers, which is possible due to the following characteristics of the control systems:

Generally the services will be distributed – they will execute on a number of separate networked computers. Note that in the following discussion a service can also be a client to some other service. The distributed nature of the control system introduces these requirements into its design:

  1. A client can gain access to a desired service, provided that its access rights are adequate.
  2. A service can be relocated from one computer to another to improve performance of the control system or to recover from a failure, provided that the new host computer fulfils all service's requirements (e.g., controlled hardware device is physically connected to the computer).
  3. If a service is not used for a longer period of time, it can be destroyed.
  4. If a client requests a service that does not currently exist in the system, the required service is created on a computer where that specific service can exist.
  5. If a newer version of a service is available, or if service configuration data changes, it must be possible to upgrade or reconfigure the service without interfering with its clients.
  6. Users must have an overview and control over the current state of the system, including existing services and clients and the possibility to manually manage services.
  7. Services distributed over disconnected networks must seamlessly federate when the networks are joined, i.e. the meta-services must be able to form federations.

Meta-services implementing the enumerated functionality are known collectively as Management and Access Control Interface (MACI) services. A service that is controlled by MACI is a component.

Concepts of MACI

Management and Access Control Interface is centered around CORBA Objects (components), but places no programmatic restrictions on them. Nevertheless the component can implement some of the interfaces declared by MACI in which case MACI use this additional functionality to improve the interaction between the component and MACI infrastructure. To proceed with discussion, let us first define and clarify the following concepts related to components.


A component is a basic service provider in the control system. To the client a component is solely a certain CORBA interface that performs the declared functionality. To the management system, the component is an entity with a lifecycle that has to be managed. This document does not describe what mechanisms are used internally by the MACI implementation to control the component.
Regular components are instantiated on demand when they are first required, and released when they are no longer needed. There are tree other kinds of components:

CURLs and Domains

Since a component is essentially a service, it must be made available to the clients. In a distributed environment this means that every component must have a unique designation, which clients use to identify that component. As a meta-service, MACI then provides name resolution that from a well-formed component designation generates the component reference that can be returned to the client. Well-formed component designations are component URLs or CURLs. A CURL is a hierarchical name implemented as a string of arbitrary length that consists of static prefix curl:, domain identifier and the component name. An example of a CURL might be curl://alma.nrao/antenna1/mount, representing the mount component for ALMA antenna number 1. Uniqueness is guaranteed by CURL as a whole and not by any of its components.
Domains allow hierarchical organization of names. It should be emphasized, however, that CURLs and URLs are not similar in the respect that URL name denotes the actual machine where a resource is to be found. CURL does not directly name any machine, port or other network location. CURL serves as a key that allows MACI to look up all the relevant network data from its data structures. A component can only be in one domain, which means that the domains partition the component space into disjoint sets. Although domains are logical partitions of the name space, they are restricted by the physical layout of the network: a single domain may not span a disconnected network (for instance two LANs, connected only by a dial-up line).
When a request is issued from domain A to domain B, we speak of inter-domain communication; if the communication is restricted to a single domain, we speak of intra-domain communication.
Both the domain and name components of the CURL are hierarchical with special characters introducing the hierarchy (slashes in the name component, and dots in the domain component).
In the root of every domain, the following components may be found:

These names are reserved and no other component may be bound to them.
The set of characters used for CURLs is the same as that of URLs. It is recommended, however, that dots be used sparingly, as they have to be escaped in the Naming Service mapping.

Component Implementation

The knowledge that a component is a CORBA Object of a specific type suffices for the client. On the other hand MACI, which manages the components lifecycle, must also know where the actual component implementation resides. Upon request from the client, the piece of code that contains the component implementation is located, loaded and started. Information that MACI knows about the actual piece of code includes its name, the CORBA interface that is implemented and location from which it was loaded. This information is stored in the Configuration Database (CDB).
Such low-level management is highly centralized but is necessary for the purposes of reversible software upgrade and remote maintenance. A special object called Container, which serves as a component factory, manages the component implementation life cycle.
Aspects central to the component concept have been covered so far. MACI components that are responsible for realizing the described functionality are described below.


Every client of a component service that is not itself a component may implement an interface called Client. The interface allows the client to act as a secure party in the communication with the components, to receive general-purpose string messages from the MACI components and to be notified when any change happens to the components that the client utilizes. Each client logs in to the MACI system before any other requests are made, and in turn it obtains a security token, which it must use in every subsequent request to the MACI. The log in and other requests are issued to the Manager, which serves as a portal to other services.


Administrator is a special-purpose client that can monitor the functioning of the domain that it administers. Monitoring includes obtaining the status of the MACI components as well as notification about the availability of the component components. The administrator client is granted special access permissions. There is another condition tied to the Administrator interface: it must provide enough notifications about the state of the administrative domain so that the administrator client is always up-to-date with internal state of MACI components. In particular, notification of Manager's get_component and release_component requests must be issued, and login/logout notifications must supply all the necessary information that is required for authentication. This condition allows two uses:


Manager is the central point of interaction between the components and the clients requesting their services. A Manager can manage more than one domain. Note that it is not necessary that the domain also corresponds to a single LAN. There may be a number of domains on a single LAN, but there cannot be a single domain spanning multiple LANs that are not directly connected (e.g., if they are only connected through dial-up links). Manager has the following functionality:

Manager can serve as a broker for objects that were activated outside of MACI (non-components). It provides a mechanism for binding and resolving references to such objects.

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.


An Container serves as an agent of MACI that is installed on every computer in the control system. Every Container runs in its own process. Manager sends the Container the request to construct a specific component by passing it the name, type and the path of executable code of the component. The Container loads the executable code and begins executing it. If the dependant executables are not loaded automatically by the operating system (as is the case on the VxWorks platform), Container loads them prior to executing any code.
The Container also deactivates components, when so instructed by the Manager and is able to shutdown by disabling all components. Container maintains a list of all components it has activated and is able to return data about individual component's implementation.
Since the Container is a separate CORBA object, it can exist independently of the Manager, which provides another level of fault tolerance to the system. There must be at least one Container on every computer that is able to construct and export components. The means of bootstrapping Containers are implementation dependent and outside the scope of this document.
The Container is a self-contained object and must not hold any references to other objects except the components that it instantiated and the Manager of the Container's domain.
Container provides the components it hosts with an interface through which components can perform their MACI-related tasks, such as issuing requests to the Manager and activating other CORBA objects. This approach has two advantages:

Inter-domain Communication

When a Manager receives a request for a component that is not in the Manager's domain, the Manager forwards that request to the appropriate Manager, whose reference is obtained via central Naming Service. Central Naming Service holds references of all active domains where Naming Contexts hold references to the local domain Naming Service.

CURL-to-Naming Service Mapping

Naming Service (NS) is a collection of Naming Contexts (NC). Each NC holds named references to other objects (bindings), which may also be NCs. This allows one to build a hierarchy of object.
A name in the NC is composed of two strings: the id and the kind. The CURL-to-NS mapping uses three different values for kind:

The mapping is as follows:

  1. For every domain in the CURL hierarchy there exists a Naming Context (the domain NC) in the NS, which contains the following bindings:
  2. For every node in the component hierarchy there exists a NC (the folder NC). The NC contains:

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

  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.

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.

Accessing the Naming Service

Manager must be configured in such a way that when it issues an resolve_initial_references("NameService") standard CORBA call, it obtains the reference to the NC of the domain administered by the Manager.
Clients have two alternative ways to access the Naming Service:

  1. By using resolve_initial_references.
  2. By asking the Manager to retrieve a reference to the Naming Service via get_service("NameService").

In both cases, the domain's NC is returned.

Caveats when Using the Naming Service

Naming Service support is provided for greater interoperability with existing tools that use Naming Service for locating objects. Naming Service is not a replacement for Manager's get_component method. The following aspects have to be taken into account: