TEORIA DE LA JURISPRUDENCIA Capítulo

The DEC write and DECdecision Live Link functions automate the processing of external information and free the user from these manual application transfer chores .

Simply put, LiveLink software is a connection to external data that is stored independently from a document. This external data can be stored locally or distributed over a network. LiveLink software provides the mechanism to streamline accessing and managing this information. The LiveLink con­ nection can also be used to share information in a work group in an orderly and managed way.

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

There are two types of connections: data link and application link. A data link is a direct l ink to some external data. The data, in this case, is in final form format (e.g. , an illustration) that is usable directly by a document processing application. An applica­ tion link is a link that involves an external application, referred to as a LiveLink application. The applica­ tion link is responsible for performing appropriate manipulations on the external data, which is nor­ mally revisable form data. It then converts this data to final form result for inclusion into a document .

Conceptually, the data used in a LiveLink con­ nection is point to information. This approach is unlike the DECwrite menu feature include, where data (text and/or graphics) is included and becomes a permanent part of the document.

One advantage of the Live Link connection is that it uses the latest information w ithout requiring a manual user update. By definition, data l inks are always up-to-date because they are direct links to the current final form data.

There are some complications with application links because the referenced data is revisable data for another application. To solve this problem, we implemented an automatic update feature in the DECwrite editor, to maintain the latest information characteristic offered by Live Link connection. This feature tracks the revision time of the external data (the revisable data, in this case), and, upon user consent , updates the data when the source data has been revised. The update process is automatic and requires no user intervention. The LiveLink appli­ cation to which the data belongs regenerates the final form result for use in the document.

The LiveLink connection in the DEC write editor uses a special object called a data block as a con­ tainer for Live link information .z To the user, a data block is a rectangular region on a page which is used to display information (such as a picture, table, or flow diagram) from an external source. It can be manipulated just like other document objects.

AlL Library

As noted earlier, the purpose of A I L is to support the implementation of the Livelink function. A I L is a subroutine library that contains a standard set of functions. It defines a set of rules for application interactions and provides a common interface for integrating applications.

Following are some basic design considerations:

• Subroutine interface. The AIL library provides a simp le-to-use interface. Although a message­ based service migh t be more flexible and exten­ sible, it requires more programming effort. A subroutine interface tends to be more conven­ ient to the programmer and easier to use. • Operating system independence. The AIL inter­

face is designed to be operating system-indepen­ dent in order to be more portable. It hides all the operating system-specific features, such as low­ level communication services, within its imple­ mentation.

• Reusable application. The startup time for some applicuions can be quite time-consuming. The All. library has an operation model which allows an application to be reused to perform multiple application sessions. In between sessions, an application remains in the system in a clean state and waits for reuse. A reuse session can typically come up in one-third the time of image startup. • Single library for parent and child. Both the AIL

library parent and child functions are combined into one library, which makes it more convenient for those applications that want to support both parent and child functions.

• Single application image. For maintenance and packaging issues, it is desirable to minimize the number of itnage versions released for a particu­ lar application. An application built with the AIL libr;1ry can be run :IS a stand-alone image and as a child application.

• Asynchronous environment . Target applications

arc supposed to operate u nder an asynch ro­ nous or event-driven environment, such as the

50

DECwindows environment. In an event-driven envirorunent, an application is required to service multipl e activities at the same time. In particu­ lar, it is not acceptable for an application or a ser­ vice to engage in a time-consuming task. To suit this environment, the AIL library is designed with nonbl ocking calls.

Application Interaction Model

We adopted a parent and child model for applica­ tion interaction under the AIL library. Because of this model's simplicity and conceptual cleanliness, we could accompl ish what we wanted to do for the current functionalities i n the DEC write and

DEC decision products.

As shown in Figure 1 , a parent application can have one or more child applications. A child appli­ cation can itself be a parent application to other child applications. General ly, a user starts with one application. From this application, the user can invoke another application to perform functions that are not available in the first application. Depending on the nature of the first application, the invocation of the second application can be ini­ tiated either explicitly by the user or transparently by the first application . Expanding the hierarchy further, the second application can, in turn, invoke some other applications.

In theory, the invocations follow a sitnple tree structure that can be extended to many layers. However, in practice, the number of application layers will generally not get higher than two. Data Exchange between Applications

The ability to exchange data is an itnportant part of application integration. Depend ing on the nature and capability of participating applications, the

Figure 1 Parent and Child Application Interaction Model

requirements for data exchange can range from a simple input/output black box level to an ongoing dynamic data dialog level.

Input/output Black Box Model We believe that the classic input/output black box model can satisfy a large class of data exchange situations between applications. In this model, a child application is treated as a black box in wh ich input data is sup­ plied at the beginning of a session, and output data is produced at the end of the session. The input data to the child application is the child applica­ tion's own input data, normally in revisable form or in a command script.

The output data consists of final form data and possibly updated revisable data. The parent appli­ cation would be interested in the end result only (i.e. , the final form data). An advantage of this model is that all child applications interact the same way with a parent application, and the parent application does not need special programming to deal differently with each child application. It also enables conforming applications, present and future, to be easily adapted to work with one another.

Dynamic Data Dialog Model Although the input/

output black box model is simple and universal, i t has l imitations . Applications that wish t o work closely with each other need more flexible and more efficient ways to exchange data. Just as the more two people know about each other, the more topics of interest they find to discuss, the more details applications know about each other, the more specific they can request and provide needs to each other. The dynamic dialog model supports applications that communicate with each other with frequent dialog and numerous topics identi­ fied as items.