Getting Started Documentation Glish Learn More Programming Contact Us
Version 1.9 Build 1367
News FAQ
Search Home


next up previous contents
Next: Standard Environment Up: Note 186: The Tasking Environment of AIPS++ Previous: Distributed Objects

Subsections


Control Hub

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.

Environment

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.

Object references

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.

Type and Object Servers

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.

Object Creation and Method Invocation

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:

1.
The method is invoked on the object reference.
2.
The function arguments, method name, and ObjectID are bundled up into a record, and passed to the dynamic invocation interface. The caller blocks until the DII returns. (If asynchronous behaviour is desired, the DII should be used directly).
3.
The method and its arguments are passed to the control hub.
4.
If the object server is single-threaded and already processing a request, the new request is queued until the server is available. Otherwise the request is sent on to the object server.
5.
The object server server calls a dispatch method in the implementation object. The dispatch method demultiplexes the function arguments, and calls the desired object method.
6.
The dispatch mechanism bundles up the return result and modified parameters, or thrown exception, and sends them back to the calling object.
7.
The function return is handled much like the function invocation.
8.
In the event of an error in the system, an exception is returned from the point ``closest'' to the error:
(a)
From the control hub if the object server crashes.
(b)
From the calling processes run-time-system if the control hub crashes.

Packages

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.


next up previous contents
Next: Standard Environment Up: Note 186: The Tasking Environment of AIPS++ Previous: Distributed Objects   Contents
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc., Washington, D.C.

Return to AIPS++ Home Page
2006-03-28