Version 1.9 Build 1556

News	FAQ
Search	Home

Next: Conclusions Up: AIPS/AIPS++ INTEROPERABILITY Previous: Interoperability options

Technical solutions

This section describes a design that has already been implemented as a prototype to meet the objectives discussed above. A technical solution to the question of AIPS/AIPS++ interoperability is best approached through the formalism of distributed objects, a key element of the global AIPS++ design. Distributed object methodology has many uses in developing client-server applications in heterogeneous network environments using object-oriented software design methods. In this model an object request broker (ORB) is available to locate and invoke methods on a collection of distributed software components or objects. This allows the integration and re-use of multiple software components of unknown implementation or network location to form coherent integrated software applications.

This methodology is also commonly used to allow the co-existence of legacy code with modern distributed object systems. In this case a dedicated object adaptor presents an object-based interface to the rest of the system for the legacy code components, defining an arbitrary high-level set of methods or accessors as required by the global design. Private data and other implementation specifics are left undisturbed in the legacy code component as far as possible.

The design adopted here for AIPS/AIPS++ interoperability is related closely to this approach, and represents a limited implementation of a true distributed object system. The criteria listed in the preceding sections can be met using a global design shown schematically in Fig. 1.

**Figure 1:**
$\begin{figure}\begin{center} \epsfxsize=15truecm \epsfysize=15truecm \leavevm... ...already been demonstrated in a working prototype. }\end{center} \end{figure}$

In this design a central component is a set of AIPS++ classes defining an active object interface to the AIPS system. These classes communicate with an AIPS daemon that provides access to the command line interpreter, and with specialized AIPS servers using an event messaging system. The message system is based on standard internet protocol messaging (IPC), with XDR encoding for network independence and a simple request-reply model.

The AIPS daemon is a specialized version of the POPS interpreter AIPS.FOR modified to communicate with the C++ classes rather than accepting keyboard POPS input. The content of events recognized by this daemon, called DAIP.FOR, constitute standard ASCII strings containing POPS commands; in most other respects there is little difference from the standard interactive interface. The daemon can launch standard AIPS tasks if it receives a POPS GO command. This allows, for example, the implementation of a simple GUI interface for AIPS from Glish.

In addition, the AIPS daemon can be used to launch specialized AIPS servers for passing image, uv or table data from AIPS to the active C++ classes and vice versa. The AIPS servers are tasks in the standard AIPS format that implement event communication with the C++ classes using a subset of IPC and XDR routines in the AIPS library. The AIPS servers and daemon can be implemented as part of standard AIPS and do not impact the AIPS distribution as a stand-alone package. They can however use the full AIPS library in a direct and standard fashion and reflect high-level functionality to the rest of the AIPS++ system at an arbitrary level of abstraction. The format of supported events defines the dedicated object interface to the C++ classes. Thus, this is a simple distributed object system with a hard-wired object adaptor and messaging system. The AIPS XDR event format consists of the following general fields: i) message length; ii) event name; iii) event version number, and; iv) multiple fields of the form (name, type, dimension, value), where type can accommodate most of the basic C++ data types.

An ancillary feature is the availability of a slightly modified form of the standard AIPS start-up script which starts only the AIPS TV, tape and Tekronix servers and creates a checkpoint file of global defined logicals which need to to known later to the process launching DAIP.FOR. The changes to the startup script do not compromise the functioning of standard AIPS. This startup script can be implemented as a global function in the C++ interoperability classes and invoked as needed.

The active C++ classes can be used directly by AIPS++ Glish clients to reflect the AIPS events to the Glish CLI for direct manipulation, or to other CLI environments such as IDL or Mathematica. The C++ classes can also be used directly by standard AIPS++ applications to create test and bridging utilities during the transition period without duplicating significant parts of the AIPS infrastructure in AIPS++. The C++ interoperability classes shown in Fig. 1 consist of the basic messaging classes to support AIPS events, and higher level classes that provide access to AIPS data structures and algorithms.

It is important to stress here that the primary user access to the AIPS data and methods will be at the AIPS++ CLI level and that the corresponding Glish closure objects need to present the same programming interface for both AIPS and AIPS++ data. For example, access to AIPS image data will only be supported for a subset of the methods available for AIPS++ data but the method and function names will be identical apart from the constructor. This will allow the direct re-use of the Glish scripts. This objective is best achieved by closely basing the AIPS C++ classes on their AIPS++ counterparts and enforcing the same naming conventions. Direct inheritance from the AIPS++ base classes may be possible in some cases but the AIPS C++ classes and Glish proxy objects will be kept completely separate and will have no influence on the general AIPS++ class library development.

As an example, access to AIPS image data may be obtained through an aipsimage class, which supports a subset of the features of the standard AIPS++ image class, either with the same method and function names or through direct inheritance. The aipsimage class uses the event messaging classes for IPC/XDR communication with a specialized AIPS image server to access the AIPS image data. The aipsimage class is made available to Glish through the standard DO formalism, as part of the image server. This ensures a common programming and user interface.

In closing it is noted that parts of this design could be implemented using industry standard distributed object implementations, such as CORBA or OLE. However, the AIPS C++ interoperability classes could easily be incorporated in such an implementation if this were to be adopted within the AIPS++ project as a whole, as might be considered at some later time. The same consideration applies to the object adaptor to AIPS, but in this case the interface issues discussed in Section 3 would need to be resolved.

Note that the design discussed in this document could be used for other data reduction packages such as MIRIAD, as appropriate.

Next: Conclusions Up: AIPS/AIPS++ INTEROPERABILITY Previous: Interoperability options