The Builder Communication Model

The Builder communication model is basically a classic client-server model . The server is the Builder process, and the client is the client applica­ tion. In Figure 7, the Server is labeled as Builder executive and the client as Builder client executive. Builder Executive The Builder executive acts as a central dispatcher for sessions, handles all session­ level operations, and communicates session infor­ mation (updates) to client applications. Some examples of this include:

• Identifying which application starts next • Invoking applications (and processing startup

and termination information)

• Synchronizing cross-application events (e.g. ,

which command executes next?) • Handling errors during playback

The Builder executive can also start, stop, and pause a session, and reuse applications. However, it has absolutely no user interface. Instead, Builder uses the Builder executive as a session manager to derive the information needed to maintain the blueprint diagram. This is done by means of a call interface and callbacks, which are triggered when

56

the Builder executive processes certain session events. These are separate and distinct layers, as depicted in Figure 7 .

The Builder executive communicates with all client applications through a communication layer

in the Builder client executive. (See Figure 8.)

Builder Client Executive The Builder client execu­ tive maintains the Builder context for applications, and does the actual communication between the client application and Builder. Client applications use Builder's runtime services as the interface to join a session, record commands, and indirectly communicate with Builder.

During record mode, the client application translates user operations into a command which it then passes to the client executive through the runtime services. The client executive assigns a unique, ordered sequence identifier, and records the result. These sequence identifiers represent the order in which the blueprint was recorded.

During playback, the client executive either determines or is notified when the next command in its command cache may be executed. When this occurs, the command callback registered by the client code is invoked and given the cached com­ mand . The application then parses and executes the command.

Blueprint File Blueprints are recorded on disk as a DDIF-encoded file. The blueprint file has a table of contents section and an application command table section. Figure 9 shows the file's logical layout.

APPLICATION PROGRAM AND USER INTERFACE r - - - , BUILDER RUN-TIME SERVICES COM MAND I CALLBACKS

I

CLI ENT TO B U I LDER COM M U N ICATION I NTERFACE CONTROL AND DISPATCH COMMAND CAC H E

I

I

I

I

I

I

I

I

I

Figure 8 Builder Client Executive

Jnterapplication Access and Integration

APPLICATIONS

APPLICATION INVOCATION NATURAL

NAME STRING LANGUAGE SUBTITLE

EVENTS COMMAND TABLE OF CONTENTS EVENT TYPE A PPLICATION SEQUENCE IDENTIFIER IDENTIFIER COMMAND TABLE A GLOBAL SEQU ENCE

I DENTIFIER COMMAND CODE

COM MAND STRI NG(S) APPLICATION COM MAND TABLES COMMAND TABLE Z GLOBAL SEQU ENCE IDENTIFIER COMMAND CODE COM MAND STR I N G(S)

Figure 9 Blueprint File Layout

The table of contents section describes the appli­ cations that comprise the blueprint and their inter­ relationship. Included are application name invocation strings, and native language identifiers, among other application instance attributes . This information provides a framework description from which the user interface constructs a dia­ gram. The table of contents also describes the cross-application events w ithin the blueprint. The Builder executive uses these events when calculat­ ing application ordering.

One command table for each application is listed in the table of contents. All commands associated with a given application instance are grouped together. This grouping makes it easy to select and process all commands for a given application instance.

Digital Technical journal Vol. 2 No. I, Winter 1990

Translatability Applications may record one or two variants of command syntaxes:

• A n a ti v e l a nguage-oriented and translatable

syntax

• A common and nontranslatable syntax (which

may or may not be culturally biased)

The advantage of supporting a native language interface is that the command language always addresses the end user in the local language. The disadvantage is that a series of commands recorded by an application in one country may not be under­ stood by the same application in another country (assuming the product and command language have been translated).

The advantage of supporting a common com­ mand language syntax is that the same syntax is

understood across all application variants. The dis­ advantage is that common command languages tend to be heavily, culturally biased and, as a result, are only understood by a subset of users.

If an application supports a common and a native language interface, then the disadvantages of either in isolation are eliminated. This support also avoids the necessity of u nderstanding all language variants of a command syntax. In essence, commands wi11 execute regardless of application variant and with­ out sacrificing the native language interface.

When an application supports both language syntaxes, Builder displays the native language com­ mands but gives client applications the common language to execute. In addition, a degree of auto­ matic translation may be achieved.