Fig.2 illustrates several properties: SORMA facilitates easy SO-requests between several SO - within a single process, as well as across process and machine boundaries. A SO can be shared employing a RPC-TCP Internet Protocol. Then requests from distributed callers are served by a ``daemon'' in an hierarchical client-server model. Remote requests are handled by the optional COMM, the ``Communication Object Management Module'' using a proxy-SO, as explained below. A SORMA process may provide itself several service ``classes'', each enabling to instantiate one or more SOs, which we also call service flavors, see below.
The next paragraphs describe the SO interface, the local and remote instantiation, and available interactive tools SCOTT (Service COmmunicaTion Tools). But first, let us advertise one immediate advantage of complying to the SORMA interface idea.
SO Interface Incentives. SORMA supports the reuse of written and compiled code in four main process configurations depicted in Fig.3. The only prerequisite is, that the software interface follows the idea of a SORMA service class. (i) a regular self-contained, stand-alone program with local (fast intra-process) SO requests; (ii) by linking the SORMA ``server stub'' a network daemon is created, which can be interoperated by other SORMA clients, including the standard inspector tool ``scott''; (iii) interactive local (and remote) SO requests are conveniently facilitated in the line oriented inspector mode; (iv) The SORM-Tcl/Tk coupling allows easy configuration of an application specific GUI (Graphical User Interface) to communicate to local (and remote) services.
Figure 3: SORMA instant re-use scenarios. (i) a regular program with fast intra-process SO requests; (ii) a network daemon offers service to other processes via the internet; (iii) command-line access to all SO methods and options; (iv) GUIs by SORM-Tcl/Tk coupling.
Actually, by the help of the SCOTT standard tools (see below), the functionally of type (iii) and (iv) are already available when configuring the service in one single (ii) deamon. A daemon might be not sufficient, when tight real-time requirements occur. Then the protected invocation of a remote SO might take to much time and the alternative, direct code linking (type (i) Fig.3) is advantageous. The direct, intra-process invocation of a SO is time-optimal to the extent that it costs about the extra time of only one subroutine call. And, as already indicated, SORMA offers the identical call syntax for both invocation paradigms. This symmetry feature facilitates the flexible migration of service tasks from and to other processes.
SO Interface -- a Compact Pattern. How can SORMA combine the support level for real-time, interactivity, and re-use? One clue is the interface design of the service object. It is standardized and small - which allows extended support for the abstractor, the elaborator, as well as the final user.
SO -- Methods: Beside the OO standard constructor (new) and destructure (free) methods, the main procedural interfaces are subsumed in two major methods: EXEC and CTRL. Compared to a device driver interface, the EXEC method does the main job, like read() and write() for data exchange to a disk drive. The method can be designed to operate most rapidly - any special configuration when initializing the object (here SO or device). For re-configuring special properties (e.g. attributes, conditional behaviors) there is another interface. The CTRL method is conceptually comparable to the ioctl() call, but it is not likewise cryptic. E.g. CTRL is text-oriented and has a mandatory help and self-explaining dump option.
Two methods allow two separate parser mechanisms to optimize different design goals, usually mixtures involving ease-of-use, comfort, information hiding, fault-tolerance, parser effort, execution time, etc. A very time-critical service will abandon an EXEC parser and may instead specialize itself by dynamic binding of the desired EXEC method (run-time binding and re-binding upon CTRL calls).
SO -- General Data Structure: All methods share the same data structure for input and output. Sending a non-empty message (method request or reply) to another process involves three phases: the message gets packed in some standard format, introduced into a transmission medium, finally, the packet gets received at the target and unpacked. For three reasons SORMA employs one single standard data structure for the message transports: (i) standard packing/unpacking routines (XDR) are static and pre-compiled (speed); (ii) it simplifies text-conversion support (efficient translation mechanisms) to and from clear-text messages, and (iii) it simplifies their usage - since it is a pattern.
We found the following combination of data types a good compromise: a float tuple (real, for continuous values; a tuple is a vector or 1D array of dynamic length) an integer tuple (e.g. flags, counters, discrete signals), a text string ( for human-machine communication; char* null-terminated) and a character tuple (also ``opaque'' or ``any'', for e.g. image data or arbitrary complex data structures packed elsewise, e.g. [4, NDR,]). A result message makes use of an additional return value, indicating success or a fault id, and potentially a verbose human readable clear-text debug message for notification, warnings and errors. Receiver and sender id complete the transport data structure.
We found the described data type choice lean - but general enough to fit all our essential requirements. Herewith intra-process communication is organized as a time-optimal call-by-reference - while remote method calls can employ standard and rapid packer routines. Before the remote invocation mechanism, the next section explains the local instantiation.
Figure 4: The local service object instantiation and specialization procedure when the SORM is called for the name ``foo.a'' the first time. The registered class ``foo'' constructor function gets invoked ``newFoo("foo.a")'', which retrieves the ``recipe'' from a dictionary service. The ``recipe'' is a token list, denoting a sequence of state transitions. It gets parsed by the object's CTRL method and specializes the desired service object flavor.
Service Flavors by Name. One key concept of SORMA is the service object instantiation on the basis of a unique name. The name consists of possibly three parts, e.g. ``foo.a@daemon'': (i) the class name ``foo''; (ii) the (optional) SO flavor specialization ``foo.a''; (iii) the optional ``@daemon'' network address, if it is present, it indicates a remote service which is then resolved via the proxy mechanism to the SO name ``foo.a'' - then local at the daemon side, see below (for options on opaque network addressing see ).
At creation time, a local name (like ``foo.a'' without ``@'' part) gets expanded into a list of CTRL arguments - text tokens, which are interpreted by the service's CTRL method (see Fig.4). This provides a general hook for arbitrary configuration and state transition calls. Different names lead to the instantiation of different service objects according to their ``recipe''. Since the resulting SOs belong to the same service class but exhibit modified characteristics (attributes, configuration, properties etc.), we call them also ``service flavors''.
The flavor name concept solves the conflict between the three (before) opposed goals of: (i) serving hardware by shared server access, (ii) which is easy-configurable, (iii) but still state-free (as far as possible). Because the script is associated with the service object name, the COMM can efficiently manage the requested connections. The SO names, which are part of all initial SO reference calls, are not only sufficient to build, but also - in case of failing daemon - to re-establish the connections to the appropriate service flavors, served by a restarted SORMA daemon.
Beyond this robustness advantage, the name-to-script scheme is a versatile configuration and default mechanism. SORMA offers a central dictionary facility for expanding SO names. It offers various options - the most straight forward loads entries from a plain text file (lines plus commenting notes). Of course, also this service is implemented as SO, which has the immediate advantage, that dictionaries in daemons can be remotely edited - during run-time.
Proxy SO. Fig.5 illustrates how the connection to a remote service SO is created. The first request involves the dynamic construction and caching of the remote target SO (12), a proxy SO (3), and a Connection Object (``CO'',6). The upper scheme displays several steps: Since the client SORM fails to retrieve the requested SO in the SO-repository (1), the SO-plant (2) instantiates (3) a new proxy SO. The necessary daemon communication is handled by the Connection Object, CO (6), which is built (5), if not already available (4). The SO request reaches the daemon SORM on the right side via TCP Internet protocol and stubs 7 and 8. There, a SO-reference-by-name mechanism induces the instantiation of the desired SO.
The lower half of Fig.5 depicts how the cached objects accelerate all further calls. Requests to the remote SO look identical to local SO-requests - since they are local requests to the SO-proxy. The SO-proxy acts as substitution of the remote SO and completely mirrors its interface, including the input, potential exception, and output messages. The proxy does not mirror irrecoverable daemon failures, which facilitates protected invocation. Instead, its connection object and the COMM, the Connection Object Management Module would signal the problem and try to semi-autonomously reconnect to a newly started daemon.
Figure 5: Creation and later usage of a remote Service Object within the daemon process (rigth side) by a local Proxy SO at the caller side, see text.
Exception Message Support. To standardize exception message generation, SORMA has one universal, compact procedure, which knows about verbose, warning, and error messages. The transport back to the requester works likewise for local and remote method calls - in a cumulative way - also across process and machine boundaries. Human readable clear-text messages, but also unique identification codes (for error handlers) supplemented with context information (source code location) are standard.
Text Conversion turned out to be a very important ingredient for reducing communication costs with SORMA. It provides easy-to-use, unrestricted interactive access to each SO interface. Separated by reserved word tokens, the transport structure can be string converted in a bi-directional way (excluding the unspecified ``any'' tuple). By this verbatim translation, interactive exploration is quite more authentic as usual, ready-made test or demonstration programs. Applicability and limits of a component can be investigated in a very quick and efficient manner. The results can be 1:1 transfered to program code - always with the option to chose between protected and time-optimal invocation. Here, SORMA combines the advantages of interpreted interfaces (like Mathematica, Maple) and the benefit of real-time efficiency achieved by its SO-interface.
Interactive Service COmmunicaTion Tools (SCOTT). As mentioned before, two standard tool executables are readily available to remotely access all (possible) SO in the network. (i) A command line oriented inspector ``scott'' offers test-suite features like line completion, editing, and recent history matching. Furthermore, it invites to program service requests by simple scripts. (ii) Any desired SO method can be invoked via a mouse-click on a button, or a slider etc. The ``scottwish'' is a SORMA enhanced Tcl/Tk shell and facilitates graphical user interfaces (GUI), simply by writing short scripts, see Fig.6.
Figure 6: Example of a graphical user interface (GUI, by R.Rae), produced by the ``scottwish'' and a Tk script. The active stereo camera head can be interoperated by mouse clicks and drags