Supported Inter-Language Communication Techniques in IDL

IDL supports a number of different techniques for communicating with the operating system and programs written in other languages. These methods are described, in brief, below.

Options are presented in approximate order of increasing complexity. We recommend that you favor the simpler options at the head of this list over the more complex ones that follow if they are capable of solving your problem.

It can be difficult to choose the best option — there is a certain amount of overlap between their abilities. We highlight the advantages and disadvantages of each method as well as make recommendations to help you decide which approach to take. By comparing this list with the requirements of the problem you are trying to solve, you should be able to quickly determine the best solution.

Translate into IDL

Advantages

All the benefits of using a high level, interpreted, array oriented environment with high levels of platform independence.

Disadvantages

Not always possible.

Recommendation

Writing in IDL is the easiest path. If you have existing code in another language that is simple enough to translate to IDL, this is the best way to go. You should investigate the other options if the existing code is sufficiently complex, has desirable performance advantages, or is the reference implementation of some standardized package. Another good reason for considering the techniques described in this book is if you wish to access IDL abilities from a large program written in some other language.

SPAWN

The simplest (but most limited) way to access programs external to IDL is to use the SPAWN procedure. Calling SPAWN spawns a child process that executes a specified command. The output from SPAWN can be captured in an IDL string variable. In addition, IDL can communicate with a child process through a bi-directional pipe using SPAWN. More information about SPAWN can be found in Using SPAWN and Pipes or in the documentation for "SPAWN" (IDL Reference Guide).

Advantages

Simplicity

Allows use of existing standalone programs.

Data can be sent to and returned by the program via a pipe, making sophisticated inter-program communication possible quickly and easily.

Disadvantages

Can be a slow when transferring large datasets.

Programs may not have a useful user interface.

Recommendation

SPAWN is the easiest form of interprocess communication supported by IDL and allows accessing operating system commands directly.

Microsoft COM and ActiveX

IDL supports the inclusion of COM objects and ActiveX controls within IDL applications running on Microsoft Windows systems by encapsulating the object or control in an IDL object. Full access to the COM object or ActiveX control's methods is available in this manner, allowing you to incorporate features not available in IDL into IDL programs. For more information, see Overview: COM and ActiveX in IDL (IDL Connectivity Bridges).

Advantages

Integrates easily with an important interprocess communication mechanism under Microsoft Windows.

May support a higher level interface than the function call interfaces supported by the remaining options.

Disadvantages

Only supported under Microsoft Windows.

Recommendation

Incorporate COM objects or ActiveX controls into your Windows-only IDL application if doing so provides functionality you cannot easily duplicate in IDL.

Use the IDL ActiveX control if you are writing a Windows-only application in a language that supports ActiveX and you wish to use IDL to perform computation or graphics within a framework established by this other application.

Sun Java

IDL also supports the inclusion of Java objects within IDL applications by encapsulating the object or control in an IDL object. Full access to the Java object is available in this manner, allowing you to incorporate features not available in IDL into IDL programs. For more information, see Using Java Objects in IDL (IDL Connectivity Bridges).

Advantages

Integrates easily with all types of Java code.

Can easily leverage existing Java objects into IDL.

Disadvantages

Only supported under Microsoft Windows, Linux, Solaris, and Macintosh platforms supported in IDL.

Recommendation

Incorporate Java objects into your IDL application if doing so provides functionality you cannot easily duplicate in IDL.

UNIX Remote Procedure Calls (RPCs)

UNIX platforms can use Remote Procedure Calls (RPCs) to facilitate communication between IDL and other programs. IDL is run as an RPC server and your own program is run as a client. IDL's RPC functionality is documented in Remote Procedure Calls.

Advantages

Code executes in a process other than the one running IDL, possibly on another machine, providing robustness and protection in a distributed framework.

API is similar to that employed by Callable IDL, making it reasonable to switch from one to the other.

Possibility of overlapped execution on a multi-processor system.

Disadvantages

Complexity of managing RPC servers.

Bandwidth limitations of network for moving large amounts of data.

Only supported under UNIX.

Recommendation

Use RPC if you are coding in a distributed UNIX-only environment and the amount of data being moved is reasonable on your network. CALL_EXTERNAL might be more appropriate for especially simple tasks, or if the external code is not easily converted into an RPC server, or you lack RPC experience and knowledge.

CALL_EXTERNAL

IDL's CALL_EXTERNAL function loads and calls routines contained in shareable object libraries. IDL and the called routine share the same memory and data space. CALL_EXTERNAL is much easier to use than either system routines (LINKIMAGE, DLMs) or Callable IDL and is often the best (and simplest) way to communicate with other programs. CALL_EXTERNAL is also supported on all IDL platforms.

While many of the topics in this book can enhance your understanding of CALL_EXTERNAL, specific documentation and examples can be found in Using CALL_EXTERNAL and the documentation for "CALL_EXTERNAL" (IDL Reference Guide).

Advantages

Allows calling arbitrary code written in other languages.

Requires little or no understanding of IDL internals.

Disadvantages

Errors in coding can easily corrupt the IDL program.

Requires understanding of system programming, compiler, and linker.

Data must be passed to and from IDL in precisely the correct type and size or memory corruption and program errors will result.

System and hardware dependent, requiring different binaries for each target system.

Recommendation

Use CALL_EXTERNAL to call code written for general use in another language (that is, without knowledge of IDL internals). For safety, you should call your CALL_EXTERNAL functions within special IDL procedures or functions that do error checking of the inputs and return values. In this way, you can reduce the risks of corruption and give your callers an appropriate IDL-like interface to the new functionality. If you use this method to incorporate external code into IDL, We highly recommend that you also use the MAKE_DLL procedure and the AUTO_GLUE keyword to CALL_EXTERNAL.

If you lack knowledge of IDL internals, CALL_EXTERNAL is the best way to add external code quickly. Programmers who do understand IDL internals will often write a system routine instead to gain flexibility and full integration into IDL.

IDL System Routine (LINKIMAGE, DLMs)

It is possible to write system routines for IDL using a compiled language such as C. Such routines are written to have the standard IDL calling interface, and are dynamically linked, as with CALL_EXTERNAL. They are more difficult to write, but more flexible and powerful. System routines provide access to variables and other objects inside of IDL.

This book contains the information necessary to successfully add your own code to IDL as a system routine. Especially important is Adding System Routines. Additional information about system routines can be found in Using CALL_EXTERNAL and in the documentation for "LINKIMAGE" (IDL Reference Guide).

Advantages

This is the most fully integrated option. It allows you to write IDL system routines that are indistinguishable from those written by ITT Visual Information Solutions.

In use, system routines are very robust and fault tolerant.

Allows direct access to IDL user variables and other important data structures.

Disadvantages

All the disadvantages of CALL_EXTERNAL.

Requires in-depth understanding of IDL internals, discussed in Part II of this manual.

Recommendation

Use system routines if you require the highest level of integration of your code into the IDL system. UNIX users with RPC experience should consider using RPCs to get the benefits of distributed processing. If your task is sufficiently simple or you do not have the desire or time to learn IDL internals, CALL_EXTERNAL is an efficient way to get the job done.

Callable IDL

IDL is packaged in a shareable form that allows other programs to call IDL as a subroutine. This shareable portion of IDL can be linked into your own programs. This use of IDL is referred to as "Callable IDL" to distinguish it from the more usual case of calling your code from IDL via CALL_EXTERNAL or as a system routine (LINKIMAGE, DLM).

This book contains the information necessary to successfully call IDL from your own code.

Advantages

Supported on all systems.

Allows extremely low level access to IDL.

Disadvantages

All the disadvantages of CALL_EXTERNAL or IDL system routines.

IDL imposes some limitations on programming techniques that your program can use.

Recommendation

Most platforms offer a specialized method to call other programs that might be more appropriate. Windows users should consider the ActiveX control or COM component. UNIX users should consider using the IDL RPC server. If these options are not appropriate for your task and you wish to call IDL from another program, then use Callable IDL.