RGI

Overview

The basic idea of this product is to separate the design of an application graphic layout, from the design of the algorithmic part.

Now, applications running on traditional departmental systems expect an output displayed on character-based terminals. With the coming of multimedia technologies, there is an increasing need to take advantage of new product capabilities, such as browsers and new generation languages, which can manipulate these new data types.

Along with these new trends, we should mention a variety of other programs, already developed on server machines and the know-how of the engineers who have developed these programs over the years.

RGI wants to mediate these two requirements in order to gradually switch from a traditional development to a more advanced way to show data.

While1 suggests a series of solutions, which can be executed systematically or individually and which offers a wide choice to the customer.

All these solutions have the same basic architecture and want to give the customer a wholly new developing tool. On this tool they can create new programs, then provide other tools, which can easily interface with old departmental applications (AS/400), and produce dedicated client for graphic representation of data.

Architectural Overview of the Product

Basic architecture for the above purposes implies three main logical environments. The first, a low-level environment, is the so-called client environment, which will run the graphic interface. The second will be used to develop new programs, which will interact with client level. The third environment (optional) includes a set of libraries and tools, which, with the necessary changes, will let the current customer programs interact with the new graphic programs.

The picture below shows these three environments. The first includes Java applets, which will be the program graphic interfaces. These applets might be developed using tools that will help to design the mask layout.

In the center there is the real engine of the architecture. It is composed by some elements: the client interface (always present) and the Library for interfacing with the departmental system and TSMART (these two ones are optional.

On the leftmost side of the picture there is the DEPARTMENTAL environment (e.g. AS/400), which includes all programs currently used. If you are developing new parts only, this part will not be used.

Let's now describe each individual component in more detail.

Client

Java applets stay in the center of the client level. These programs work referring to data description tables and talk to the server side through appropriate APIs. Once launched, they connect to the server level using these APIs.

They will not operate until the first server application (or DEPARTMENTAL system) output comes. Then they will interpret and represent data following the rules of the data description tables. After representation on screen (or other multimedia tools), they will wait for both user commands (from mouse or keyboard) and possible updates from the server application.

These applets will not take any algorithmic decision since they will act as simple starters of programs running on server or DEPARTMENTAL system.

Whenever an element represented on the client machine changes its status, a message will be sent to the server machine.

Server

It is the real architecture core, including three main elements:

• Client Interface,
• A library which interfaces with the DEPARTMENTAL system (optional)
• TSMART (optional)

The first element only is the essential part of the architecture.

Client interface

This element interacts with Java applets through a protocol, which is able to define the fields to be represented, in case of transmission to the client, and the fields that were changed, in case of transmission to the server.

In case of transmission to the client, not only data, but also their behavioral attributes (for example: only visible, modifiable etc.) will be transferred.

As for the fields which have been changed on client machine, this module will check if their syntax is correct. In other words, whenever the screen on the client machine is modified, a piece of information comes and is checked. Then an error message or a validation message is sent to the client, if necessary.

There are basically three types of event which can be sent from the client:

• Inquiry
• Choose
• Validate

The first event (Inquiry) is generated by a data request from a Java applet. The client interface, which can be the program itself, will send the value for the requested data.

When the user selects one of the elements displayed by the Java applet on the screen, the Choose event will be invoked. The program will be able to provide all the variations of the above field or other fields on the screen.

The Validate event causes one or more data to be sent. The interface will receive this data, will elaborate them and will continue to manage the application.

RGI interface library

This element will be developed if the client wants to use the current applications, available on the DEPARTMENTAL system, with the slightest changes. In practice, you will have to replace read and write operations to video-terminals with some RGI calls. This will make it easy to interface with the RGI environment and will keep the current application logic. The library on the server side must have its software layer on DEPARTMENTAL system communicating with it.

The library, on its turn, will interact with the client interface within the above context.

TSMART

This element, the last on the server, allows the customer to leave the applications on the DEPARTMENTAL system unchanged. To do this, it acts as the output of these applications, interpreting their description files through a default metalanguage, the description files of the screens.

In practice, it is a real video interpreter, which receives screens from programs (through HLLAPI interface), isolates their significant fields and is able to send to the program changes made by the user to form fields.

This is the cheapest solution from the development point of view, but it slightly increases the workload at run time.

Conclusions

These are some possible solutions:

• Developing new programs using the so-called event mode with the algorithms placed within the client-side interface. So it is possible to exploit this new architecture, but programmers who used a sequential programming will have to change their habits.

• Developing new programs in server environment using transactional mode. We do not wholly exploit the full power provided by event driven, but we keep a more traditional programming logic. At the same time this approach allows you to work on a new operating system and to get away from the classical environment of the DEPARTMENTAL system (e.g. AS/400)

• Interface of the current programs on DEPARTMENTAL system with libraries and interfaces on the same system; it lets you keep the current programs and the know-how of programmers with little adapting effort.

• TSMART; it lets you keep on developing programs using the current mode and maintaining programs that were developed without changing the DEPARTMENTAL system, in spite of a little loss of performance.

Up to LAN * TSI  *   HSI  *  HOME