Builder is a variation on the application link theme. Its revisable data is a script, or blueprint, that allows applications to be integrated at the user-interaction level. In addition to being a conforming Livelink application, it can also stand by itself. In fact , Builder is also a component of the DEC decision family of applications .
The remainder of this paper presents an overview of Builder and its design and infrastructure.
Digital Tecbnlca/]ournal Vol. 2 No. 1, Winter 1990
Builder Overview
A user typically performs a series of steps to accom plish a logical task or, in Builder's terminology, a blueprint. Each blueprint may entail invoking many different applications and dealing w it h an equal or greater number of files or data objects. Builder uses a tape recorder paradigm as a model for describing application integration . The user turns on Builder to start a task, and applications are transparently recorded as they are used. T h is blueprint recording may be played back to repro duce the task.
Builder is one of five DECdecision components that run on the DEC windows platform. The others are as follows:
• Access - a table-oriented, database access tool
T o o l s
D a t a Link
Figure 5 Sample Blueprint Diagram
• Calc - a spreadsheet package
• DEC chart - a charting package
• Control - the manager for theother components Builder ties together one or more of these compo nents into a single task.
As applications are recorded, Bui.lder graphically represents their activity with a series of boxes and arrows as shown in Figure 5. Each box represents an application instance; and each arrow, or data link, represents the flow of data (e.g. , cut and paste) between a pair of applications. The user may select and display the contents of an object to see the operations that correspond to it, as shown in Figure 6.
54
Early in the project, we decided that a record of keystrokes and mouse tracks was of limited use and could not always be counted on to reproduce the intended task . For example, if the application was run on a workstation with a different display size, or the menu choices were rearranged, many such recordings would be invalidated. We found that a functional record of operations, that is, a description of the intended operations , was much more useful and could be relied upon to represent user tasks.
The record and playback mechanism is therefore a cooperative effort between Builder and inte grated applications. Applications that understand Builder are referred to as client applications. In record mode, a client application provides Builder with a functional representation of each user-level operation, which is recorded in the blueprint. Since only the application knows what a series of keystrokes and mouse tracks means, this coopera tion is essentiaL
In addition to the basic record and playback capabilities, Builder also allows users to debug a blueprint during playback (e .g. , single stepping), and to splice new operations into existing blueprints (a combined record and playback mode for modi fying a blueprint).
Goals and Considerations
Besides the end-user goals, we designed Builder to meet key integration goals.
The main goal of Builder was to provide a facility for the recording and playback of operations that span more than one application. This included maintaining a record of the ordering of operations to account for concurrent applications.
Another goal was to support both procedural and nonprocedural applications. Many applications are process-oriented and are only controllable in a procedural or command-oriented way. Others are nonprocedural in nature or deal with objects, not commands. Both types of applications are sup ported . (Note: This paper refers to any operation that is recorded as a command, even if that opera tion was produced by a nonprocedural application.)
Further, we felt that introducing yet another command language would be detrimental to appli cation integration and would discourage support for existing and future applications. Instead, Builder adopted an ecumenical doctrine with respect to command languages - any one is just as good as any other. With this method, appl ication developers do not need to recode applications and cultural bias in command languages is avoided.
A prime goal for Builder was to support interna tional applications . We had tO recognize that app l i cations can be translated to various degrees . Some areas that we addressed were as follows:
• Character set support : 8-bir strings, ! 6-bit strings, ISO Latin I , etc. Blueprints are files encoded in the DDIF document interchange format. Com mands can be recorded as compound strings to support a wide variety of character sets.
• Translatable and nontranslatable command lan guages. Applications may record a translatable and/or a nontranslatable command string for every operation, corresponding to the type(s) of language interfaces they support. If both string types are specified, they are treated as a logical entity . A scheme is provided for language independent command execution that does not sacrifice the native language command interface. • Language environment verification. Builder and
client applications can verify that the record mode language is compatible with that of play back. For example, a blueprint recorded in German is meant to be played back using the German language version of an application.
Another goal was to ensure reusability . To mini- mize the impact of process startup and application initialization, Builder supports a mode of reusabil ity whereby application processes are reused after task completion.
Digital Technical journal Vol. 2 No. I, Winter 1990
Jnterapplication Access and Integration
Builder a lso allows blueprints to be shared . Blueprints must be able to be mailed and used by other users. Since blueprints may contain refer ences to other, embedded, blueprints, it was highly desirable for them to be shared as a whole. The
DDIF data format encoding made this goal achievable. Embedded blueprints are named as external references in the DDIF data format file. The DOTS data object transport syntax packages and unpackages the resulting encapsulation.
Two final considerations shaped the design. One is support for nonintegrated appl ications. An appli cation that does not support Builder may still be incorporated into a blueprint in a limited way by using it as a black box. The application is invoked and run to completion without the benefit of a con tinuous dialog with Builder.
The second consideration is coexistence with event-driven environments. Increasingly, applica tion environments are centered around event driven mechanisms that handle asynchronous events in an operating system-independent manner. Call backs seem to be the most common and good solution to support this environment. Builder provides a callback registry for dispatching of operations. This mechanism also works well in a non-event driven environment .