const string DeleteEventK = "Tc:TerminalControl:Deletion";
typedef CosNaming::Name DeleteEventD;
Applets must separately register for the events in which they are interested:
CosEventChannelAdmin::ConsumerAdmin register_event(in Typ::EventKey key) raises (Ex::NoSuchEvent);
The user session object maintains one event channel per event. This means that an applet must filter the create and delete events that it receives. This is acceptable because it can be assumed that there will be rarely more than one applet per application on the terminal. If this assumption should turn out to be wrong it would be necessary to add functionality to Tc::TerminalCon-trol that allows applets to maintain their own event channels, in which case the user session object needs to keep track about the requester of every registered event.
An application that is about to terminate, or that dismisses the terminal from the application session, deletes all terminal servers. Once this is done it calls the terminal control to indicate that the terminal is no longer part of the application session:
void terminated();
This operation may actually be called by the application in the application pool, or by an applet in an applet handler shortly before it terminates. The operation is also called if the termination of the application was initiated by the user via thequit() orkill() operation in theTc::
UserSession interface, or by the terminal control itself.
7.6 Terminal Server and Applet Handler Interfaces
This section presents the terminal server base interface and as special cases of terminal servers the interfaces of applet handlers for Tcl/Tk and Java.
7.6.1 Interface Ts::TerminalServer
The module Ts contains the definitions of the terminal server base interface Ts::Termi-nalServer and some types that are related to it. Two of the types defined inTs shall be pre-sented here:
enum TerminalServerState {NORMAL,HIDDEN,PAUSED, HIDDEN_PAUSED,EXITING};
struct TermServDescription { Typ::InfIdent type;
Typ::Date started;
Typ::StringRef termservref;
TerminalServerState state;
};
The definition of the terminal server state is identical to the one of the user session state. The terminal server description contains the interface name of the terminal server, the time it was started, a stringified reference to it, and its state. It can be retrieved via an attribute in the inter-face of the terminal server:
readonly attribute TermServDescription description;
Terminal servers are always started by the terminal control. The terminal control initializes a terminal server with the following operation:
void set_terminal_control(in Typ::StringRef termcont);
The parameter termcont is a stringified reference to theTc::TerminalControl interface of the application that started the terminal server. The terminal server may consequently access this interface and find out about the context in which it is running.
The remaining operations of theTs::TerminalServer interface are already known from theTc::UserSession interface:
void hide();
void show();
void pause();
void continue();
void remove();
They can be called by the control panel, by the application, or by the user session object, for instance following a call in the Tc::UserSession interface. It is possible to register for a change event which allows all interested clients to be kept up-to-date about the state of a termi-nal server. As for now it does not seem necessary to define a separate termitermi-nal server interface towards the terminal control that is hidden from the application and the control panel.
7.6.2 The Tcl/Tk Applet Handler
There is no standard language mapping for OMG-IDL to Tcl, but it is possible to design a sim-ple mapping for the purposes of APMT. This mapping may for instance build on the one pro-posed by the Web* project [Alma95]. Tcl/Tk is fine for the development of graphical user interfaces that can be downloaded into the terminal. It is therefore an option for the develop-ment of centralized applications as shown in Figure 6.12 on page 119. Since it is weakly typed it should not be used for complex applets as found in completely distributed applications.
Another limitation of Tcl is the bad performance of the Tcl interpreter. However, starting with version 8.0 the Tcl interpreter contains an on-the-fly bytecode compiler with which the execu-tion speed of a Tcl script can be considerably improved. An appealing feature of Tcl is the Safe-Tcl interpreter [Oust96] which isolates a Tcl script from the system that is housing it, making it the natural choice for the interpreter in the Tcl/Tk applet handler.
An APMT applet handler is defined by an IDL interface and a secure system services API, as was explained in Section 6.5.2. This section only presents the IDL interface of the Tcl/Tk applet handler. The internal API is left open here, but it is stated that its specification is neces-sary, for applets need a standard environment within the applet handler. The module TclTk contains all definitions that are relevant for the Tcl/Tk applet handler. This includes the defini-tion of an applet handler interface, and the definidefini-tion of a code and media object loader for the application pool:
module TclTk { ....
interface TclTkLoader {...};
interface TclTkApplethan : Ts::TerminalServer {...};
};
The application itself does not need to download Tcl/Tk scripts into an applet handler. Tcl/Tk applet handlers maintain a cache of downloaded scripts and media objects, and access the Tcl/
Tk loader in the application pool if they need scripts or media objects that are not in the cache.
The moduleTclTk defines a unique identifier for scripts and media objects:
struct Downloadable {
Atyp::ApplicationName appname;
Typ::Name objname;
string version;
};
A downloadable object can either be a script or a medium object like a digital image that is part of the graphical user interface generated by a Tcl/Tk script. The globally unique application name and the object name in the Downloadable structure form together with the version number a unique identifier for a downloadable object. It allows Tcl/Tk applet handlers to find out if they hold the exactly required version of an object in their cache, and if not, to retrieve it from a loader.
The module TclTk also defines two types that represent a script and a binary medium object:
typedef string TclTkScript;
typedef sequence<octet> MediumObject;
Scripts and media objects are both downloaded via IIOP. This simplifies the architecture of the applet handler and the loader, but is slower than a transmission directly on top of TCP1. It can be envisaged to compress Tcl/Tk scripts for the purpose of downloading. This reduces the load on the network and the code loader, but results in additional delay on the client side where received applet code must be decompressed before it can be executed.
1. [Pyar96] reports a considerable performance loss when using CORBA/IIOP for the transfer of binary large objects (BLOB) rather than TCP via Berkeley sockets. On an ATM link, the CORBA/IIOP transfer of a BLOB only reached 66% of the throughput measured for Berkeley sockets.
Applet Handler Interface
TclTk::TclTkApplethan inherits from the Ts::TerminalServer interface. An applica-tion launches a Tcl/Tk applet handler with a call to theget_terminal_server() operation of the Tc::TerminalControl interface. It initializes the applet handler with the following operation:
void init(in Downloadable script, in Downloadables libraries, in Downloadables media_objects, in Typ::StringRef loader,
in Typ::StringRef application);
The parameter script is the identifier for the script that is to be executed. The libraries that are used by this script are communicated via the second parameter. The parameter media_
objects identifies the media objects that are used. The applet handler must have the men-tioned libraries and media objects at hand when it starts to evaluate the script. The parameter loader is a reference to the loader in the application pool where the applet handler can retrieve scripts and media objects that it does not have in the cache. The parameter applica-tion finally is a stringified reference to a callback interface in the application that can be accessed by the script once it is running. Theinit() operation returns immediately because the applet handler is searching asynchronously for scripts, script libraries and media objects.
The next operation the application calls isstart(): void start()
raises (TclNok, NoScript);
This causes the script handler to evaluate the script. Start() blocks until the script has been found and evaluated by the interpreter. Once the Tcl/Tk script in the applet handler is running it may access the terminal control, retrieve object references to other objects of the application in the terminal, and communicate user input back to the application in the application pool. The application controls the applet with the following two operations:
Result eval_script(in TclTkScript script) raises (TclNok);
void as_eval_script(in TclTkScript script);
Thescript parameter is a small Tcl script, typically not more than the name of a Tcl proce-dure that is to be executed, and some string arguments to it. The Result is the string result that is returned by the Tcl interpreter. The first operation blocks until the script is evaluated, whereas the second operation evaluates the script asynchronously. These two operations are a surrogate for a server side IDL language mapping, which means that the Tcl/Tk applet handler only needs to implement a client side mapping1. A Tcl/Tk script in the applet handler can therefore access CORBA objects without any problems, but it cannot implement CORBA interfaces. Its services are accessed directly in Tcl with the two evaluation operations of the applet handler. These operations are supplemented with two further operations that allow to get or set the value of a variable in the applet:
Result get_variable(in string variable) raises (TclNok);
1. It is assumed that a Tcl client uses the Dynamic Invocation Interface for requests. The advantage of this is that no stub code needs to be shipped over the network. A server-side language mapping could be implemented on top of the Dynamic Skeleton Interface.
void set_variable(in string variable, in string value) raises (TclNok);
These two operations can be considered as a replacement for CORBA attributes.
Loader Interface
The interface TclTk::TclTkLoader contains two operations that allow applet handlers to retrieve scripts and media objects. A complete script or script library is retrieved with theget_
script() operation:
TclTkScript get_script(in Downloadable script) raises (NoSuchObject);
Media objects can be downloaded with the following operation:
MediumObject get_medium_object(in Downloadable obj) raises (NoSuchObject);
It is assumed that digital images and other objects in the graphical user interface are medium-sized, and that it is not necessary to stream them from the application pool to the terminal.
The Tcl interpreter calls theunknown command whenever it stumbles over a command that it does not know. The applet handler code may intercept calls tounknown, retrieve the missing procedure from a cached library, and make it available to the script without that an error is gen-erated. This procedure can be extended to allow the dynamic downloading of procedure code from the loader. A similar procedure can be added for the dynamic downloading of media objects.
7.6.3 The Java Applet Handler
The integration of Java into APMT is straightforward, first of all because of the existence of a standard Java language mapping in CORBA, and then because Java is designed to be shipped across the network and to be executed remotely. Java can be used in APMT the same way as in the Web. This means that APMT Java applets are classes that extend the standard class java.applet.Applet. What is different with respect to the Web is the bootstrapping proce-dure, the class loader, and the security policies. APMT uses IIOP rather than HTTP to down-load applet code into the terminal. This requires the definition of a Java code down-loader interface in addition to an applet handler interface, and the development of an APMT class loader that extends the default class loader java.lang.ClassLoader. The Java applet handler must access CORBA interfaces on the terminal, in the application pool, and possibly in remote ter-minals. This requires a relaxation of the current security policies for Java applets.
The Java code loader and applet handler interfaces are defined in the module Java. The Java applet handler inherits from the general terminal server interface:
module Java {
typedef string ClassName;
typedef string PackageName;
typedef sequence<octet> Package;
....
interface JavaLoader {...};
interface JavaApplethan : Ts::TerminalServer {...};
The Java applet handler interface contains the two operations init() and start(). The application calls the init() operation in order to communicate the applet name to the applet handler:
void init(in ClassName applet, in Typ::StringRef loader,
in Typ::StringRef application);
The parameter applet is a globally unique Java class name. The parameter loader is a stringified reference to the Java code loader in the application pool. The parameter applica-tion is a stringified reference to an interface implemented by the application. The applet han-dler looks asynchronously for the Java packages that are necessary to run the applet, and downloads them from the code loader in the application pool. This includes not only the pack-age of the applet itself, but also packpack-ages containing stub code for the application-specific interfaces that the applet accesses, and skeleton code for the application-specific interfaces that it implements. The following operation defined inJava::JavaLoader is used for download-ing packages:
Package get_package(in PackageName name) raises (NoSuchPackage);
At some point the application starts the execution of the applet by callingstart(). This oper-ation blocks until the applet handler is ready to execute the applet, and returns just before the start() method of java.applet.Applet is called. There are two possiblities how the contact between the applet and the application can be established. One possibility is to have the applet call an operation in the application interface to which it holds a reference. The other possiblity is to have the application call an operation in the applet right afterstart() returns.
Due to the existence of a Java server-side mapping there is no need for special evaluation operations like the ones implemented by the Tcl/Tk applet handler. Once the applet is running, the application can directly communicate with it, and does not need to pass through the inter-face Java::JavaApplethan. The only interface that remains to be defined is the internal APMT system services interface of the applet handler that allows applets to find out about the environment in which they are running.