The Interact Product Family

A Technical Briefing

Table of Contents

WHITE PAPER

InterAct FreshLook:
A Technical Briefing

A Technical Briefing

Table of Contents

Contents

Introduction

The InterAct Architecture

Architecture Components

Three-Tier vs. Two-Tier Models

The InterAct Data Document

The Object Request Broker

The Developer’s View of InterAct

Overview

The InterAct FreshLook API

Legacy Manager Scripts

An Example InterAct FreshLook Application

Using Standard Applications

Integrity of Information in InterAct

What do we mean by Integrity?

Ownership of Information

The InterAct Integrity Manager

InterAct’s Security System

Scalability, Performance and Availability

A.Example Legacy Manager Script

The information presented in this briefing paper is based on a family of products which are under continual development and enhancement. While Cavendish has endeavoured to ensure the information here accurately reflects the use, operation and specification of the InterAct products it addresses this cannot be guaranteed. We will be happy to discuss specific aspects of InterAct in the context of the current status of the product.

A Technical Briefing

Introduction

InterAct is a family of related middleware products from Cavendish which allows an organisation to very effectively extend the life of existing ‘legacy’ IT systems and help to ultimately migrate smoothly to newer platforms and applications. This involves little or no change to the existing, proven systems which lie at the heart of most companies.

This briefing paper describes the operation and use of InterAct, and in particular InterAct FreshLook and InterAct Unify. It is aimed at the technical reader, though a detailed knowledge of the technology used by InterAct is not expected. The paper should be read alongside the InterAct brochure (which provides a high level overview of the InterAct family) and the interactive presentation An Introduction to InterAct, available on disk or from Cavendish’s site on the World Wide Web ( We have structured the paper to look at InterAct from a developer’s standpoint, and have also included a ‘frequently asked questions’ section based on feedback we receive about the InterAct system.

A Technical Briefing

The InterAct Architecture

Architecture Components

InterAct implements a middleware ‘hub’ scheme which separates, or decouples, users of central, corporate IT systems from the systems themselves. Its overall aim is to make the information those systems hold more accessible and useable by business users while at the same time having little or no effect on the central legacy systems.

Figure 1: InterAct architecture

Importantly, InterAct operates at the application level. Most middleware solutions are concerned with moving data around a network of disparate systems and applications. This in itself is of limited use in a corporate environment where people need to handle and manage business information rather than simply a flow of data. InterAct understands the context of information - it works at what can be regarded as the transaction layer, where information gathered from one or possibly many sources is gathered into an entity meaningful at a business level. This is one of the reasons for InterAct adopting a ‘three-tier’ architecture rather than a ‘two-tier’ model, which is discussed in more detail in the following section.

A further important distinction between InterAct and lower-level middleware approaches is that an InterAct solution will always involve an element of customisation to meet the requirements of a particular customer situation. This might be as simple as building a front-end graphic user interface (GUI) or may involve lower level work around the periphery of the InterAct architecture for particularly demanding needs. InterAct encourages straightforward application development by removing the complexities of information flow between disparate systems: developers are free to concentrate purely on high level business logic using fast, widely available development tools such as Visual Basic or standard products such as spreadsheets.

InterAct products share a common core architecture, are supported on Windows NT™ and Unix platforms and can be centralised or distributed across a network. The InterAct architecture is illustrated in Figure 1.

The architecture is illustrated graphically in the multimedia presentation An Introduction to InterAct. For clarity, we summarise the building blocks of the architecture here.

InterAct is entirely object based, though this is largely hidden from the user and from the front-end application developer. As noted earlier, the InterAct architecture is common across all InterAct products. However, certain aspects are only relevant to some products; where this is the case it is noted below.

The architecture consists of several layers, each of which are responsible for a particular aspect of InterAct’s operation.

Kernel

The kernel is responsible for orchestrating the operation of the various processes that make up InterAct. This involves much ‘behind the scenes’ work that the user or developer never sees and in general need not be concerned with.

The Data Document cache

The Data Document is the central ‘object’ around which the functionality of InterAct is based. This entity is fully described in the section The InterAct Data Document, p8. InterAct maintains a sophisticated caching mechanism designed to optimise the performance of front-end business applications and reduce load on the central legacy systems. Currently the cache, and InterAct in general, handles purely transient information en route from central system to user and vice versa. A future enhancement to InterAct will include options for ‘persistence’, providing the ability for InterAct to store information medium- and long-term.

Communications Managers

InterAct implements ‘communications managers’ which handle low-level communications with central systems and work at the protocol level. For instance, to handle communications with a TCP/IP-connected legacy system a TCP/IP comms manager would be configured into the InterAct solution. Each comms manager is dedicated to a particular central system, and unifies the flow of data to and from the scripting layer within InterAct (see below).

The vast majority of InterAct solutions will use some pre-existing access method into the central system(s). For example, this might be via a terminal interface or by an existing computer-to-computer link. The modular comms managers however can also be customised where a particularly demanding need exists. This might be, for instance, to optimise data transport for a real time system, or maybe where no suitable existing interface exists. This area of customisation is the responsibility of Cavendish due to the tight bonding between comms managers and the rest of the InterAct system.

Scripting Layer

This layer consists of one or more ‘legacy managers’ whose job is to handle transactions with the central systems and to populate one or more data documents with the results (the same is also true in the reverse direction when updating host information). Legacy managers operate under the control of InterAct scripts (these are fully described in the section Legacy Manager Scripts, p12). A legacy manager can be thought of as simulating the human user of a legacy system (in the case where there is an existing human interface).

Session Layer

The session layer, consisting of a session manager for each user connected to the InterAct system, is responsible for all transactions with the user (or more correctly with the user’s application).

Terminal handling(FreshLook)

InterAct FreshLook is equally capable of creating a new, simpler front-end to existing systems using dumb terminals. It uses the services of the session layer; the operation of InterAct behind the session layer is identical for both dumb terminal support and for workstation support.

Workstation handling(FreshLook)

The majority of InterAct applications involve some form of distributed application environment running on PC workstations. In this environment, InterAct provides a client/server based architecture between the InterAct hub and the user workstations, carrying with it many of the benefits of a fully-fledged client/server environment without the massive redevelopment of legacy systems that this would involve.

This area of InterAct makes extensive use of an ‘Object Request Broker’ (ORB). The ORB allows InterAct to be easily distributed across physical server systems whilst maintaining the logical central-hub model. It also promotes load sharing and resilience to single- or multiple-point failure. This aspect is discussed in the section Scalability, Performance and Availabilityon page 20 in this briefing.

Information is delivered to the front-end user application via a simple ActiveX control-based programming interface (API). The InterAct FreshLook API is discussed fully, with examples of its use, in section The InterAct FreshLook APIon page 11.

Three-Tier vs. Two-Tier Models

Figure 2: The two-tier model

There are two models commonly used to implement front-ends to corporate IT environments, usually referred to as ‘two tier’ and three tier’. The two tier approach is illustrated in Figure 2. Front-end clients are connected directly to the back-end host systems, by direct connections or more often across a network.

Two-tier models are most commonly adopted by network-level technology (allowing simply connection of disparate systems) and by client-server solutions which are aimed at organisation who have decided on wholesale replacement of existing systems, and where a two-tier model is quite appropriate.

However, for firms who wish to retain the value of existing systems, or who are looking to integrate packaged applications from disparate vendors the two-tier model has distinct drawbacks, despite its apparent simplicity. It is difficult to manage, with a confused set of information paths; it is difficult for front-end application developers who have to deal with individual back-end systems, and since users have direct access to the back-end systems security can be an issue, especially if wider access to corporate information is needed (for example, by customers).

For these reasons InterAct implements a three-tier model, as illustrated in Figure 3.

We chose this approach based on experience for several reasons:

Figure 3 : The three-tier InterAct model

Ease of Maintainability. InterAct presents a central ‘hub’ to users, where all information of interest to all users is maintained. System administration is therefore centralised, minimising the risk of out of date configurations being used in production. In contrast, a two-tier model distributes configurations such as screen maps to the workstations, with more risk of workstations becoming out of step with each other and with the host systems. This could result in incorrect information being passed to the user, or a transaction ‘locking up’ by getting out of step with its mainframe counterpart.
Simpler Connections. With a two-tier model, each workstation will normally need its own connection to each central system (even if it is virtualised through a server). InterAct on the other hand maintains a pool of available sessions to central systems which can be used on a contention basis to support a far larger number of users. This means that host resources are preserved, physical comms lines are reduced and mainframe access charges minimised.
Enhanced Performance. Mainframe response times usually determine overall performance. InterAct can exploit its sophisticated data document cache and scripting to actually enhance the overall system’s performance:

A user can re-request information which InterAct can service from its cache, rather than involving the mainframe.

InterAct's scripting can pre-fetch a set of transactions so that by the time the user asks for follow-on information, there is a good chance it is already available within InterAct. This is extremely effective for dealing with telephone enquiries which statistically tend to centre around a limited set of host transactions.

The result of this is a great improvement in response times to customer enquiries, with normally no application development or impact on host applications.

The InterAct Data Document

The Data Document is the central concept around InterAct and is unique to the InterAct system.

Figure 4: The InterAct data document

A Data Document is a collection of related information for an entity. For instance, a data document might be configured to hold all client account information gathered from various host applications. The data document can then be considered an ‘object’ which contains items of information accessible using unique ‘tag’ names by the front-end application. This can be seen in. Information from host application(s) is used to populate the data document under control of a legacy manager script (the example here shows a couple of screen-based transactions and a record feed providing the host information). The user’s application only needs to be concerned with managing the tagged data items within the data document and does not need to be aware of how the information has been obtained or how updates are passed back to the host application. The format of data items within the data document is also normalised, so for instance all dates conform to a common standard. This makes front-end application development easier and the resulting applications more rugged.

The Object Request Broker

InterAct uses the services of an Object Request Broker (ORB) as part of its underlying operating environment. The ORB provides several significant advantages:

The ORB promotes the scalability and resilience of the InterAct hub through transparently managing the promulgation of objects InterAct uses internally around the server architecture (particularly where the hub uses multiple physical servers).
Underlying operating system specifics are handled largely by the ORB, meaning that InterAct can easily exploit the platforms supported by the ORB.
The ORB facilitates the object design and implementation of InterAct, which in turn enhances the ruggedness of InterAct with obvious benefits to an InterAct user.

The ORB used by InterAct is PowerBroker from Expersoft, Inc. Cavendish includes the necessary PowerBroker licences in all InterAct solutions.

The developer of front-end applications using InterAct does not need to be aware of the ORB at all; access to InterAct services is purely via the InterAct API described later in this briefing.

However, the imminent introduction of version 4.0 of PowerBroker into InterAct brings with it CORBA 2 compliance. For organisations committed to a CORBA strategy for distributed systems our product plans include exposing the InterAct API at the ORB layer, making it possible for external applications to interwork with InterAct at the ORB layer with any CORBA 2- compatible ORB such as those from Iona, Visigenics, TIBCO, ICL and many other vendors.

A Technical Briefing

The Developer’s View of InterAct

In this section we look at InterAct as the system is seen by a developer building a front-end application using its services. We focus on InterAct FreshLook as this provides the environment easiest to understand. Furthermore, we assume that the application involves PC workstation support.

Again, the reader is referred to the interactive presentation An Introduction to InterAct as this shows the sequence of operation of InterAct and the flow of information within the hub and between the central system(s), the hub and the user environment.

Overview

InterAct is designed to insulate the developer who needs to build user-level applications from the intricacies of dealing with complex central systems with the wide variations of communications, user interfaces and application sophistication that these legacy systems exhibit.

Instead, the developer can concentrate on the business issues that his or her application needs to address, very much in an abstract sense.

The developer can take advantage of a wide range of low cost, rapid development tools to build front-end applications. These include

Microsoft Visual Basic (and Visual Basic Application)
C and C++(eg Microsoft, Borland, Symantec)
Java
Delphi
Jscript (Javascript) and VBscript
…and any development tool supporting ActiveX controls or DLL access.

So, not only does the developer not have to worry about the complex nature of the central legacy systems, but he or she is also able to take advantage of the latest software tools and techniques.

There are two aspects to implementing an InterAct solution:

designing and implementing the front-end application
designing and implementing the legacy manager scripts which deal with the central legacy systems

Cavendish will often complete the second of these and then train the client in the ongoing maintenance and enhancement of the scripting system (though this is not always the case as sometimes a user or third party developer will wish to be more deeply involved at the outset).

Clients will usually prefer to handle the front-end application development themselves as this will involve an intimate knowledge of their business and InterAct decouples the client’s developers from the complexities of the legacy systems.

It should be noted that both Cavendish and other third party software and systems houses are able to deliver complete turnkey InterAct solutions should the client prefer this.

The InterAct FreshLook API

The InterAct FreshLook application programming interface (API) is the developer’s main point of entry into the InterAct system and is implemented as a Microsoft ActiveX control. It is therefore compatible with virtually all PC development tools and applications and is deliberately very simple, with methods that are called to

Open a data document
Read information from a data document
Write information to a data document
Close a data document

InterAct is entirely based around the concept of documents. Each user known to the InterAct system has an associated user document (a special form of the data document) which contains all information about that user. Thereafter the user accesses host information through data documents, as discussed earlier. The sequence of operations that any FreshLook front-end application will go through is as follows.