Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
![]() | Version 1.9 Build 1367 |
|
The control hub implements the functionality required to support distributed objects and the AIPS++ environment. The actual functionality available to the user is provided by standard service objects, which are described later.
The control-hub itself appears to be an object.
The environment is a simple hierarchical collection of ``keyword=value'' strings, similar in spirit to the X-window system resource files. It is implemented on top of the ``AIPS++ Resource Database.''5
These resources are maintained in text-only initialization files, and they are used to maintain information related to bootstrapping (such as paths to data directories) and user preferences.
An attached object reference may be associated either with a local object or a distributed object. Local objects exist in the address space of the object reference and member functions are invoked directly. Member functions of distributed objects are invoked via the control hub. Local objects are preferred when the communication overhead is important.6 It generally does not make sense to create objects which can only be invoked locally - in this case it is more convenient to create native-language library entities.
Objects exist in some server object. The most common use will be to create a transient instance of some particular ObjectType (``FFT server''). It is also possible to directly request a particular object instance, which might or might not be active. This is the method by which persistence is implemented in AIPS++.
An process can thus be regarded as a repository of objects. It can either create the objects, activate them from persistent state (i.e., disk files), or both.
Note that a given binary executable can result in more than one object server being active at one time, since the same executable may have more than one process associated with it.
An object server itself appears to be an object.
All objects, except the control hub pseudo object, reside in a process, including the object server objects from which all other objects are ultimately obtained. The object server for each process is special in that it is implemented by the run-time-system, not the object programmer.
Requests to create or restore an object are passed through the object server into callback functions registered with it. A list of active and persistent objects is maintained by the object server.
If the creator and user of an ObjectID are in the same process, then the ObjectID can resolve into a local reference to the object with some language bindings (e.g., in C++ a pointer to the actual object will be used behind the scenes). Method invocations for local objects use the native language invocation mechanisms.
Distributed object invocations proceed as follows:
A package is the organizing unit for collections of programs and associated documentation and system data files. Packages must be ``registered'' with the control hub, since all objects must ultimately be found and manipulated through the control hub. An initial package list is obtained from the environment.