Go up to Building CONCERT Instruments Go forward to Embedding Mathematica

Embedding External Applications

The facilities provided by Java, our intended programming and execution environment, for interfacing with external applications are the following:

• Starting a new process running externally to the interpreter (by specifying the command to be executed and its variable environment, communicating with it via the standard input/output/error streams, waiting for process termination and returning its exit value),
• Opening sockets for IP connections to other servers,
• Java IDL (Interface Definition Language) for the use of CORBA-compliant network services,
• Java JNI (Java Native Interface) for calling C/C++ code from Java programs,
• Java RMI (Remote Method Invocation) for interfacing with other Java applications,
• JavaBeans as an architecture to make Java programs distributed components of other applications.
• Java DBC (Database Connectivity) that similar to Microsoft's ODBC interface allows connection to external databases via an SQL interface,

From this side, many possibilities for interfacing with external applications are available. The basic question therefore is by which facilities the external application supports its embedding as a component into a larger framework. Here we can distinguish the following classes of programs:

Closed World

This category comprises applications that are essentially designed for interactive use only. Their embedding facilities are restricted to forking a separate process executing the application and communicating with it via

• command line arguments defined at startup time,
• environment variables defined at startup time,
• resource properties provided by the screen server (X11) at startup time,
• input/output files for files for file-based communication,
• standard input/output streams for stream-based communication,
• special hooks for allowing user-denoted applications to perform certain tasks (e.g. by providing the name of some program at the command line),
• the return code provided by the application.

Depending on the kind of "ad hoc" support provided by the application, its embedding into a general framework may range from manageable to hard to impossible.

External Links

Into this category we put applications that are mainly designed for interactive use but that also provide facilities such that their use as a component of an external program is facilitated (and vice versa). This includes in particular any provision to define channels for communication with other processes, possibly on other computers.

Such facilities especially designed for external communication and control may not make the embedding into a general framework easy but at least possible (in principle).

Dynamic Linking

These are facilities that are explicitly designed to serve as components of other applications by use of dynamic linking techniques that allow to "glue" together components to build larger frameworks. Components adhering to some distributed object standard typically fall into this category.

Dynamic linking facilities make the use of the individual services provided by an application (almost) as easy as a normal procedure call.

Applications of the "closed world" category are inherently difficult to integrate in distributed sessions; substantial redevelopments may be required. On the other hand, the integration of applications applying distributed object technology like CORBA is (via Java IDL) relatively straight-forward. We thus concentrate our further consideration on applications providing external links for which integration is feasible but for which the development of appropriate interfaces is required. In order to make the presentation more concrete, we sketch in the next section a strategy for embedding Mathematica [Wol96] [Wol97] as a component into our architectural framework.