This web application is a three-tiered, web-based, client/server front end to a DOS-based COBOL database. It can accommodate multiple users.

History:

The Web Application communicates with the same back end as X and Y. When the system was first proposed, there was some resistance against building a web front-end connected to a DOS-based back-end. The requirement was to use the same API. The goal of the application was simple: to issue a function call from a web environment and bring back data from the DOS back end. However, the inherited architecture was originally designed for a single user and it had to be modified to accommodate multiple users.

It was determined to make black box approach. The intention was that the operations inside the black box would be hidden, but they would produce the correct results. The same function calls would be invoked, would be carried out in the black box, and the results returned.

In the X and Y package, a COBOL .DLL exposes the function calls to Z. However, the .DLL is single-threaded and could not service multiple users. Consequently, a middleware program had to be built to direct multiple instances of the function calls to the correct back-end location. A consulting agency was contracted to create this middleware platform, which is a separate box. They built the COM boxes: COM1, COM2, etc. BERT was the traffic cop, UBERT directed Sybase calls, and HARRIET directed mainframe calls. There were 10 services in the box: ABC1, ABC2, CDE1, CDE2, etc.. That meant that there could be a maximum 10 transactions concurrently. However, the middleware that the consultant produced was buggy and the performance was poor.

CS_Assist has a classic two-tier client/server architecture. Basically, it invoked a function call that brought back data. X first calls the .DLL which resides on actual work station. X then calls the middleware BERT from another machine. The requirement for the web front end was that it had to work in the same way: call first .DLL then BERT.

The first attempt to create this application failed during stress testing. A new middleware program solved the problem. The Web Application now bypasses the middleware. It calls BERT, which issues function calls with an H object via an H server, replacing the COM boxes. This change preserved the integrity of the function calls. For the completed system, see Figure 1.

Web applications lend themselves well to 3-tiered client/server applications. The browser is the presentation layer. You can use an Application Service Provider (ASP), JASP (Java ASP), IIS, Java, and HTML. You can access it from a handheld computer, a MAC, a wireless laptop, etc. The middleware layer can contain custom business objects that will pre-process the information before entering the data layer. Three-tiered client/server architecture was the fundamental principle in building the Web Application.

For the presentation layer, it was decided to use a Windows NT IIS Web-server, mainly since IIS is packaged with NT. ASP, HTML, and JavaScript are used in the presentation layer. That�s what user sees. The middleware, or custom business layer, is composed of Visual Basic (VB) COM objects running with MTS.

However, VB is only for single-user systems and doesn�t support multi-thread programming. Microsoft has provided a work-around to solve this problem. Microsoft Transaction Server (MTS), which resides on the NT server and is managed by IIS, intercepts a VB object and makes an instance of it. That instance is then sent to the middleware program as a separate COM object. With MTS, if a function call fails, only that one instance will fail.

The custom business object middleware has about 11 method calls. These correspond to the function calls. The four types of object are:

• System objects (core operating system)
• Database objects
• Logging objects
• Error objects

The .DLLs are wrapped by H servers. In order to connect the middleware, or business layer with the database, an H bridge was built by the vendor Rochelle (previously Nutly). It creates one instance that appears and disappears, since the DOS database doesn�t support concurrency.

In order to implement the Web Application, Client X was the first client and they were very concerned with security. They wanted to use a frame relay instead of the public internet. Consequently, any new client must use this frame relay.

In this section there is additional data specific to the web application.

RECORDLAYOUT.LAY