The InterAct Product Family



WHITE PAPER

InterAct FreshLook:

A Technical Briefing

Contents

Contents 2

Introduction 3

The InterAct Architecture 4

Architecture Components 4

Three-Tier vs. Two-Tier Models 6

The InterAct Data Document 8

The Object Request Broker 8

The Developer’s View of InterAct 10

Overview 10

The InterAct FreshLook API 11

Legacy Manager Scripts 12

An Example InterAct FreshLook Application 14

Using Standard Applications 16

Integrity of Information in InterAct 17

What do we mean by Integrity? 17

Ownership of Information 17

The InterAct Integrity Manager 18

InterAct’s Security System 19

Scalability, Performance and Availability 20

A. Example Legacy Manager Script 21

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.

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.

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.

[pic]

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 Availability on 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 API on page 11.

Three-Tier vs. Two-Tier Models

[pic]

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:

[pic]

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.

[pic]

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.

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

7. Microsoft Visual Basic (and Visual Basic Application)

8. C and C++(eg Microsoft, Borland, Symantec)

9. Java

10. Delphi

11. 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.

1. Open a User Document

This first action makes the user known to the InterAct hub. This process involves InterAct’s security system (see InterAct’s Security System, p19), ensuring that the user is known to the system and has certain levels of access to the central systems.

2. Open a Data Document

Once logged in to InterAct, the front-end GUI application will then open a data document in response to some transaction with the user (the user might, for example, execute a query through the GUI).

The action of opening a particular data document will make use of the services of a legacy manager which in turn will populate the data document under the control of the script configured for that data document. The GUI developer does not become involved at all with this process.

The GUI application is passed back a unique identifier to a data document once opened; this is used in all subsequent transactions with the data document until the document is closed.

3. Read / Write Tagged Data Items

Once a data document is opened its contents become available for reading by the GUI and for updating. Tagged data items can be formatted or unformatted strings or numbers in various formats, and appropriate API calls are provided to allow these to be manipulated.

4. Close Data Document

Once the GUI application has finished with a particular data document it closes it, which removes the document from InterAct’s cache.

5. Close the User Document

This action will log the user out from InterAct, and will close any open data documents for the user.

Steps 2, 3 and 4 can be repeated as often as needed within an InterAct session. Typically a front-end application will have several data documents open at the same time, and would use the individual document identifier in reads and writes.

Other methods provided in the API include:

19. List available data documents

20. List data items available within a data document

21. Log an event to InterAct’s central event log

22. Test the success or failure of a write

The API provides two mechanisms for the front-end application to be notified when information is available within a data document:

The application can poll for a read or write call to complete

The application can specify asynchronous operations that cause an ActiveX control event to be posted when the operation has been completed.

In addition, the GUI application can ‘subscribe’ to one or more data items. InterAct will then invoke an ActiveX control event either every n seconds and/or when the information in the data item changes. This is useful where unsolicited updates can happen, as might be found with a real-time financial information system.

Legacy Manager Scripts

A data document will have associated with it a legacy manager and a script which instructs the legacy manager how information for the data document is obtained. InterAct’s script system is essentially a high level programming language, but has been kept deliberately simple whilst retaining a powerful set of features which allow transactions with central legacy systems to be fully defined. The script syntax is similar to BASIC and can easily be understood by developers and system administrators. This is important as the legacy environment (for instance, screen formats) can change and the script needs to accommodate this without major disruption. Equally, business needs change and this might impact the scripts around which InterAct is based. So it is important that a script can be managed easily by the administrator of the InterAct hub.

The best way to illustrate the InterAct scripting system is by reference to an example. The script in Appendix A is a complete script (less some of the data document definition) which drives the GUI illustrated in the section An Example InterAct FreshLook Application.

Scripts are compiled using the compiler supplied with the InterAct system (the script compiler is not provided with InterAct when it is embedded in a vertical third party product).

The scripting system can be used to implement very simple analysis of screens and/or records received from the host system(s), but can also support more sophisticated uses. For example, take a customer call centre support system. The requirement will be to bring summary customer information onto one screen from wherever it is held, and then to make one or several subsequent transactions based on the progress of the call.

InterAct, though its scripting system, can handle this in two stages:

First the script would populate a customer data document in much the way that the example referred to above does. Information can be drawn, for instance, from several application screens to compose a complete customer summary document. This will then support the initial customer response.

From here, the script can continue to gather information for the next likely transactions. This is on the basis that statistically there are often only a few commonly used transactions that follow an initial query. A banking customer may, for instance, ask for details of her most recent debits and credits. The script can therefore be configured to pre-fetch this information in the dead time between ‘human’ transactions (between the customer and the call centre representative) in the expectation that the user, through the front-end application, will ask for it. Then when the user finally requests the information, it is already in the InterAct hub and a short network delay away from the user’s workstation. This avoids the main likely delay in the overall system - that of mainframe response times.

In this way InterAct can actually enhance the performance of the overall system (as far as the user is concerned, which of course is the important metric), without needing any change to legacy environment.

An Example InterAct FreshLook Application

To illustrate how an InterAct FreshLook application is constructed we will take a look at a real example of a simple system which Cavendish demonstrates, based on the fictitious bank Midshires Bank.

[pic]

Figure 5: Example FreshLook GUI screen

The scenario is that of a bank which needs to simplify access from branch counters to account information held on central systems. Customer information is quite commonly spread across many different screens, several applications and, often, different host systems. Our example demonstrates FreshLook bringing customer account information together from five different IBM CICS transaction screens into a single screen graphic front-end interface written in Visual Basic. This, though simple, is a typical example of the use of FreshLook and provides a convenient illustration of how a FreshLook solution is engineered to meet this need.

The Visual Basic form providing the user interface is shown in Figure 5. The various fields draw information from the same data document in InterAct, which in turn is populated by the legacy manager script from the five host screens. The Visual Basic program which runs behind this form can be seen in Figure 6 and Figure 7. The relationship between the code and the form fields should be fairly obvious, and for clarity only the fragments necessary to illustrate the use of the FreshLook API are shown. The references to Freshlook in the code are actually to the InterAct FreshLook ActiveX control which is embedded into the Visual Basic form. The example given shows InterAct being used in a polling fashion – the ActiveX control also offers asynchronous events to deliver information as it is retrieved.

Freshlook.ClearTags

Freshlook.AddTag("USERID", UserForm.UserId )

Freshlook.AddTag("PASSWORD", UserForm.Password )

RetVal = Freshlook.OpenDocument ("UserDetails",

Freshlook.InTagData,

FALSE,

0)

If RetVal 0 Then

MainForm.Status.Caption = "Failed to log on to InterAct"

Else

MainForm.Status.Caption = "Connected to InterAct"

End If

Figure 6: Example Visual Basic code for User Connect

Figure 6 shows the code which is used to log the user on to the InterAct FreshLook hub. This is done by opening a special data document (called UserDetails) with an appropriate user name and password as parameters. This can be seen in the highlighted section in the example. The data document which is returned can contain general information which can be used by the GUI application to set up a user environment on the workstation. For instance, the GUI could use information passed back to set up the desktop appearance of the application for the specific user, meaning that the user can use the application (and the services of InterAct) from any workstation on the network and still retain his or her own environment. This is useful in environments such as trading floors, call centres and suchlike.

MainForm.Status.Caption = "Opening Document"

RetVal = Freshlook.OpenDocument ("BankDetails",

MainForm.AccountNo,

FALSE,

0)

DataDocId = Freshlook.DocId

If RetVal 0 Then

MainForm.Status.Caption = "Failed to open user account"

Else

MainForm.Status.Caption = "Collecting Balances"

RetVal = IAR_DATA_UNAVAILABLE

Do While RetVal = IAR_DATA_UNAVAILABLE

sleep (2)

RetVal = Freshlook.ReadString (DataDocId,

"CurrentBalance",

0)

Loop

MainForm.CurrentBalance = Freshlook.Data

End If

Figure 7: Example Visual Basic code for reading

Once successfully logged on the GUI application may open data documents and read and write information from and to them. This is illustrated by the code fragment shown in Figure 7, which is part of the code that drives the example Midshires Bank screen.

The first step is to open an appropriate data document. In this example we are assuming that each customer account will have its own data document, based on the document we have defined in InterAct (see the sample legacy manager script in Appendix A). Once opened, the contents of the data document are available for reading and writing by the GUI application. Being a very simple system, this example handles read enquiries only, and the format of the items in the customer account data document are simple strings. Furthermore, the example here is written in Visual Basic and uses a simple polling scheme.

After this point, the GUI application can open further data documents and close documents it no longer needs. Individual open documents are identified by the unique document id passed back by InterAct when the document was opened. Repeated reads from a data document are serviced from InterAct’s cache (unless the cached document has been invalidated by ageing, by the data document being closed or by intervention of the Integrity Manager (see Integrity of Information in InterAct, p17).

Finally, when the user closes down the GUI application or wishes to disconnect from InterAct the GUI application issues a close request on the user document. This closes the user session and removes any cached documents that were being used by the session (this is not shown in the example).

Using Standard Applications

[pic]

As well as supporting a wide range of development tools, InterAct can also support standard applications such as the Microsoft Office family of productivity tools. Microsoft Excel, for example will allow access to the InterAct API via its VBA language. It is a simple task to build a set of function calls that allow cell formulas to link to information held in InterAct data documents using the InterAct FreshLook ActiveX control which can be embedded into the spreadsheet just as if it were Visual Basic (see Figure 8).

Function Int_GetValue(TagName As String) As String

Dim retval As Integer

retval = IAR_DATA_UNAVAILABLE

Do While retval = IAR_DATA_UNAVAILABLE

retval= Sheet1.FreshLook1.ReadString

(DataDocId, TagName, 0)

Loop

If retval = IAR_SUCCESS Then

Int_GetValue = Sheet1.FreshLook1.Data

Else

Int_GetValue = "#N/A"

End If

End Function

Figure 8: Example Microsoft Excel VBA function

Furthermore, InterAct supports standard browsers such as Microsoft Internet Explorer and Netscape in a variety of ways, providing a simple way to integrate existing central IT systems into a corporate intranet or for access by customers over the Internet itself. The available approaches are described in the white paper Supporting intranets and the Internet with InterAct, available on request from Cavendish.

Integrity of Information in InterAct

One of the benefits of existing legacy systems, and a driving reason for them to be maintained in a corporate environment is the security and integrity they provide for critical corporate information. The design of InterAct stresses the importance of the integrity of information passing through the InterAct hub and takes a number of measures to ensure that this critical aspect of core system is not compromised.

What do we mean by Integrity?

The integrity of information in a corporate computing environment can be defined at several levels:

1. The accuracy of information within a database record - ie do the 1’s and 0’s represent the information stored?

2. The accuracy of information at the application level (eg is a customer’s name held correctly, does his stored account balance reflect his actual position correctly, etc)

3. The accuracy (or consistency) of information held for a particular entity across different applications and/or systems (eg does a customers name on one system tie up with his customer record held on a customer database).

There is a further consideration in a multi-user environment - that one user cannot conflict with another if the two users access and try to update the same transaction or record.

Existing systems have usually been built to cater for all these issues. Low level integrity is assured through proven database systems and suchlike. Applications will have been designed to understand the context of the information they handle, and the impact of an update to one part of, for instance, a customer’s record. Sophisticated transaction monitors, developed and proven over the years, assure the integrity of information accessible by many users at the same time.

Less commonly, however, have legacy systems been designed to co-operate with each other, with the result that integrity (or possibly more correctly, consistency) of corporate information across different applications is less guaranteed.

These are the issues of which InterAct takes account.

Ownership of Information

A cornerstone of the InterAct concept is that the existing host systems and the applications that run on them are proven and should be disturbed to the least extent possible. The same is true of the information they hold.

InterAct therefore does not attempt to take control or ownership of this information. This is in marked contrast to, say, a data warehousing system, where information is physically moved or copied to a parallel database. This creates obvious potential for a breakdown in the integrity of information between systems and requires sophisticated and expensive hardware and software to avoid this.

InterAct therefore handles information in a purely transient mode. The data document cache (described in section The InterAct Data Document, p8) does not act as a distributed host database, with the attendant technical problems that would result. Absolute authority for corporate information is therefore left where it should be - with the core central systems on which it is stored and maintained.

The InterAct Integrity Manager

InterAct can handle both enquiry and update transactions between host systems and the user (whether that user is human or another computer system, in the case of FreshLook and Unify respectively). Enquiry transactions are straightforward and are illustrated in the example given in An Example InterAct FreshLook Application on page 14. From the user’s standpoint (or more correctly the front-end application he or she is using in the case of FreshLook) then update transactions are equally simple. However, there is more work that InterAct does behind the scenes to ensure the integrity of information passing back to the host system(s) and information available to other InterAct users.

To do this, there is a process in InterAct known as the Integrity Manager. Its role is to monitor the flow of information within the InterAct hub to identify situations where there is a potential clash between two or more users sharing the same piece of information.

In itself, this is no problem - InterAct can distribute the same information to a number of users at the same time. However, should one of these users modify a data item which is currently available to other users then the Integrity Manager will invalidate the cached data document(s) being used by the other users and prevent further updates to them. InterAct can then be instructed automatically to refresh the data document(s) when the update has been committed to the appropriate legacy system and this fact recognised by InterAct. In the meantime, should another user attempt to update the same piece of information the write request will be rejected via the InterAct API.

In this way InterAct ensures that host information is not compromised by users unwittingly updating old information.

InterAct’s Security System

One of the major benefits of the hub approach used by InterAct is the single point of access users have into their corporate IT systems. No longer do users have to remember different user names and passwords for different systems, or how to navigate through different access methods and screen formats. However, in no way must the central hub prejudice the security of the legacy environment - this is after all a major reason for keeping these systems in operation.

InterAct therefore provides a front-end security system which allows users to log in once, to one central point, and be given access, at the appropriate level, to each system which they need to use.

To do this, InterAct maintains a set of user profiles within the hub. These profiles dictate which systems a particular user is allowed access to, together with appropriate user names and passwords for those systems. When a user first connects to the InterAct hub, his front-end application must present a valid user name and password for authorisation by InterAct’s Security Manager before being allowed to proceed further and gain access to host information (an example of this process is shown in An Example InterAct FreshLook Application on page 14).

The security environment in InterAct is maintained by the system administrator and is naturally itself protected against unauthorised access. Passwords stored in the InterAct hub are encrypted for security.

In this way InterAct allows very simple user access to a multi-host legacy environment while at the same time protecting the security of those systems.

Scalability, Performance and Availability

The InterAct architecture is based around a single, central hub which supports on the one side links to central systems and on the other links to users or consumers (other computer systems) of the information maintained by InterAct.

[pic]

Figure 9: InterAct's scalability

However, this is a logical representation of the InterAct model. In physical terms, as shown in Figure 9, the InterAct hub function can be distributed across a number of co-operating servers. This aids load sharing, makes performance of the entire system easier to manage and enhances the availability of the InterAct hub.

Servers are linked via a TCP/IP network (usually the network supporting links to the front-end users).

The InterAct configuration specifies how many sessions (or potential sessions) are allocated to each server (this configuration is under the control of the InterAct system administrator). When users connect InterAct allocates a free session on an arbitrary server on a round-robin basis, in so doing spreading load across the hub.

Should a particular server fail while users are connected, InterAct will maintain the service available to those users by accepting a reconnection and assigning users to a different server.

Some elements of InterAct are critical to the overall system, such as the Security Manager. These processes are replicated on separate servers so that should one server that happens to be running one of these processes fail, the operation of InterAct continues.

This approach allows the InterAct administrator to control and measure the operation of InterAct very easily. He or she can allocate limits to particular InterAct processes to prevent part of the system hogging system resource at the expense of other services. Through this system the administrator can see how much system resource is being used by each InterAct service, based on which he or she can modify the system’s configure appropriately.

7.1.1.1.1.1.1.1.1 Example Legacy Manager Script

// +-----------------------------------------------------------------+

// | |

// | Cavendish InterAct FreshLook Demonstration |

// | ------------------------------------------ |

// | |

// | An example FreshLook Script for the Banking Application |

// | |

// | (c) 1998 The Cavendish Organisation Ltd |

// | |

// +-----------------------------------------------------------------+

// ==> This is a read-only demo so no integrity categories apply

// ==> This section defines the tags, each collection of tags

// are gathered from separate application screens.

// ==> Each call to the bankapp application will be tested for

// success, and will be retried a number of times before it is

// failed and bankapp is exited (by setting the exit code)

// --------------------------------------------------------------------

// Specify the type of legacy manager that this script will need to

// run on. In this case we need to use a telnet session to the bank

// application.

[LegacyManager]

ServerType=Telnet

// --------------------------------------------------------------------

// This is a list of all the tags used within the bank application

// script, declaring all of the relevant information associated with

// each tag declared.

[DataItem0]

Tag=AccountNo

Mode=R

Format=SIMPLE

[DataItem1]

Tag=Type

Mode=R

Format=SIMPLE

[DataItem2]

Tag=AccountName

Mode=R

ScanText=TITLE

ReadPosition=+8,+0

Length=38

Format=SIMPLE

…. Etc etc

[DataItem17]

Tag=Tran1Amount

Mode=R

ReadPosition=+2,+0

Length=12

Format=SIMPLE

// --------------------------------------------------------------------

[TopScript]

SCRIPT "READ"

// --------------------------------------------------------------------

// Declare the list of variables used within this read script.

// Upon the script starting, the account number should be passed.

PARAM STRING AccNo

DECLARE STRING CB

DECLARE STRING FB

DECLARE STRING XX

DECLARE INT Pos

// --------------------------------------------------------------------

// Include the FlushType and Sleep functions from utility library.

INCLUDE "BankUtilities.ini"

// --------------------------------------------------------------------

TRACE ON

// Set up the account number tag information, and the type of account.

SET AccountNo = AccNo

SET Type = "Current"

// Test that there is something in the account number first.

IF (AccountNo = "") THEN GOTO Exitapp

// Assuming that a logon has been perfomed to the ifltest user

// we now want to start up the bank application.

PUT "cd /home/projects/interact/bankapp ; fe2\x0d"

FLUSH

// Now logon for a user in the bank application.

CALL FlushType ("0000405355\x09")

CALL FlushType ("wombat\x0d")

// First shove the fixed tag information that we don't

// get from the backend to the cache.

SHOVE AccountNo, Type

// --------------------------------------------------------------------

// Start by specifying the account number and navigating

// to the first menu and selecting option 1.

CALL FlushType (AccNo)

CALL FlushType ("1\x0d")

// --------------------------------------------------------------------

// OK, now go to the first screen and collect the name of

// the account, the date the account was opened and the

// current cleared balance.

// Get the information from the first screen.

CALL FlushType ("1\x0d")

GET AccountName

GET DateOpened

GET CurrentBalance

// Find out the current state of the account.

SET CB = SUBSTR (CurrentBalance, 16, 2)

IF (CB = "CR") THEN GOTO cr1

IF (CB = "DR") THEN GOTO dr1

// Now go back to the parent menu.

CALL FlushType ("\x1bOR")

GOTO exitapp

// If the account is in credit extract the balance.

LABEL cr1

SET CurrentBalance = SUBSTR (CurrentBalance, 0, 14)

GOTO shoves1

// If the account is overdrawn then get the balance and prepend a -

LABEL dr1

SET CurrentBalance = SUBSTR (CurrentBalance, 0, 14)

SET CurrentBalance = "-" + CurrentBalance

// Now shove the information to the cache.

LABEL shoves1

SHOVE AccountName, DateOpened, CurrentBalance

// --------------------------------------------------------------------

// Now go and collect the forecast balance from the forecast screen

// Go to the parent menu and select option 3

CALL FlushType ("\x1bOR")

CALL FlushType ("3\x0d")

// Get the forecasted balance and find its current balance

// state.

GET ForecastBalance

SET FB = SUBSTR (ForecastBalance, 12, 2)

SET RetTest = RetTest + 1

IF (FB = "CR") THEN GOTO cr2

IF (FB = "DR") THEN GOTO dr2

CALL FlushType (“\x1bOR”)

GOTO Exitapp

// The forecast balance will be in credit, extract the value.

LABEL cr2

SET ForecastBalance = SUBSTR (ForecastBalance, 0, 10)

GOTO shoves2

// The forecast balance will be overdrawn, extract value and prepend -

LABEL dr2

SET ForecastBalance = SUBSTR (ForecastBalance, 0, 10)

SET ForecastBalance = "-" + ForecastBalance

// Shove the forecast balance to the cache.

LABEL shoves2

SHOVE ForecastBalance

// --------------------------------------------------------------------

// Now we need to go the transactions screen to collect account

// information.

// Get the first set of information.

// Go back to the parent menu and select option 2

CALL FlushType ("\x1bOR")

CALL FlushType ("2\x0d")

// Get all of the information for the transaction.

GET Tran0Date

GET Tran0Details

GET Tran0Amount

SET XX = SUBSTR(Tran0Amount, 10, 2)

IF (XX = "CR") THEN GOTO t0acr

IF (XX = "DR") THEN GOTO t0adr

CALL FlushType (“\x1bOR”)

GOTO Exitapp

// Extract the credit amount from the information.

LABEL t0acr

SET Tran0Amount = SUBSTR (Tran0Amount, 0, 10)

GOTO gett1

// Extract the debit amount from the information and prepend a -

LABEL t0adr

SET Tran0Amount = SUBSTR (Tran0Amount, 0, 10)

SET Tran0Amount = "-" + Tran0Amount

// --------------------------------------------------------------------

// Get second information on account.

LABEL gett1

// Get the information from the screen.

GET Tran1Date

GET Tran1Details

GET Tran1Amount

SET XX = SUBSTR(Tran1Amount, 10, 2)

IF (XX = "CR") THEN GOTO t1acr

IF (XX = "DR") THEN GOTO t1adr

CALL FlushType (“\x1bOR”)

GOTO Exitapp

// Extract the credit information

LABEL t1acr

SET Tran1Amount = SUBSTR (Tran1Amount, 0, 10)

GOTO gett2

// Extract the debug information and prepend a -

LABEL t1adr

SET Tran1Amount = SUBSTR (Tran1Amount, 0, 10)

SET Tran1Amount = "-" + Tran1Amount

LABEL gett2

// Removed Tran 2 to Tran 10 to shorten script for simplicity

SHOVE Tran0Date, Tran0Details, Tran0Amount,

Tran1Date, Tran1Details, Tran1Amount

// --------------------------------------------------------------------

// Finally, go and get the latest account address details

// Go back to the parent menu and select option 2.

CALL FlushType ("\x1bOQ")

CALL FlushType ("2\x0d")

// Now get the address information for this account.

// Get the address information from the screen

CALL FlushType ("1\x0d")

GET StateMentAddress1

GET StateMentAddress2

GET StateMentAddress3

GET StateMentAddress4

GET MajPost

GET MinPost

// Test that the data does not contain any unwanted characters

// from the screen.

SET Pos = FIND (StateMentAddress1, "|")

IF (Pos 0) THEN GOTO baddata

SET Pos = FIND (StateMentAddress2, "|")

IF (Pos 0) THEN GOTO baddata

SET Pos = FIND (StateMentAddress3, "|")

IF (Pos 0) THEN GOTO baddata

SET Pos = FIND (StateMentAddress4, "|")

IF (Pos 0) THEN GOTO baddata

// Now shove the information to the cache.

SHOVE StateMentAddress1, StateMentAddress2, StateMentAddress3,

StateMentAddress4, MajPost, MinPost

GOTO alldone

// If the data contains any | characters try it again.

LABEL baddata

CALL FlushType ("\x1bOR")

GOTO Exitapp

// The information was shoved and we must now leave the comms handler

// in a valid state for future use.

LABEL alldone

// Now set the application ready for the next user

CALL FlushType ("\x1bOQ")

CALL FlushType ("\011")

EXIT 0

// --------------------------------------------------------------------

// Exit the application.

LABEL exitapp

LOG 0, "Script has failed, returning error"

EXIT 1

// --------------------------------------------------------------------

INDEX

A

Access control. See Security System

Access methods, 5

ActiveX/OCX controls, 10

API. See Application Programming Interface

Application Programming Interface, 6, 11

Architecture, 4

Communications Handlers, 5

Components, 4

Data Document, 5

Kernel, 5

Scripting Layer, 5

Session Layer, 6

Terminal Handling, 6. See Terminal Interface

Three tier model, 4, 7

Two-tier model, 4, 7

Workstation handling, 6

Availability, 20

C

C/C++, 10

Cache, 5, 7, 11, 15, 18, 22, 23, 24

Callback functions, 12, 15

Comms Handlers

Communications Handlers. See Architecture: Communications Handlers

CORBA, 9

Customisation, 5, 11

D

Data document. See Architecture: Data Document

Cache. See Cache

Data Document, 5, 7, 8, 11, 12, 13, 14, 15, 16, 18

closing, 15

Data item, 18

Data items, 8, 11, 12, 15

opening, 15

Tags, 8

Data items. See Data Document: Data items

Delphi, 10

E

Event log. See Events

Events, 12

Example application, 14

Excel, 16

G

Graphic User Interfaces, 4

GUI. See Graphic User Interfaces

I

Integrity, 15, 17, 18

definition, 17

Integrity Manager. See Integrity

InterAct FreshLook, 3, 6, 10, 11, 14, 21

InterAct Unify, 3

J

JAVA, 10

L

Legacy manager, 5, 8, 10, 11, 12, 14, 15, 21

M

Microsoft Excel, 16

Microsoft Office, 16

Microsoft Visual Basic. See Visual Basic

Middleware Hub, 4

O

Object Request Broker, 6, 8

ORB. See Object Request Broker

P

Passwords, 19

Performance, 13, 20. See System Performance

PowerBroker. See Object Request Broker

Publish / subscribe. See Subscription

R

Real-time systems, 12

S

Scalability, 20

Scripts, 5, 7, 8, 10, 11, 12, 13, 14, 15, 18, 21, 24

Security system, 11, 17, 19

Servers

distributed functions, 20

failure, 20

resource, 20

sessions, 20

Software tools, 10

Subscription, 12

System administration, 7

System performance, 7

T

Tagged data item. See Data Document: Data items

Tags. See Data Document: Tags

TCP/IP, 5, 20

Terminal interface, 5

Three-tier model. See Architecture

Two-tier model. See Architecture

U

Unix, 4

User document, 11, 14

User profiles, 19

V

VB. See Visual Basic

VBA. See Visual Basic Application

Visual Basic, 4, 10, 14, 15

Visual Basic Application (VBA), 16

W

Web Site, 3

Windows NT, 4

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download