The demand for client/server and distributed applications has placed new demands on Cobol. In the past, Cobol applications were monolithic and executed on a single system. Today's Cobol applications must be able to execute with part of the application on a client, and the rest on a server. Some implementations require multiple servers. Other implementations may not use Cobol on the client, but still require Cobol on the server.
Cobol-RPC provides a simple solution for all these situations. With Cobol-RPC, Cobol and non-Cobol programs running on clients can call Cobol programs executing on servers. Cobol programs running on a server can call Cobol programs running on other servers. Standard data types can be passed between these programs. The calls are made using standard techniques. With some implementations existing Cobol applications can even be executed as client/server without any source changes!
But, before we examine how this is accomplished, let's review the concepts of client/server and distributed computing.
Client/server applications combine the capabilities of two computer systems. The client computer provides the user interface and some or all of the processing. The server computer stores the application's data and may do some of the processing. The most common type of client/server application is based on an architecture where the client system handles the user interface and business logic and the server handles the data. The advantage of this type of architecture is its simplicity. The disadvantage is that the client is responsible for the business logic as well as the user interface.
A more sophisticated type of client/server application is based on an architecture where the client system handles the user interface, the business logic executes on a server, and the data resides on that or another server. This architecture has the advantage of placing business logic in a central location where it can be more easily administered, has faster access to data, and is scaleable to faster systems as user demands increase, without affecting the clients.
Client/server is a form of distributed processing, since the processing of the system is distributed between the client and server. Distributed processing can also describe a still more advanced architecture involving the distribution of an application across multiple servers. This type of architecture is sometimes referred to as a three-tier architecture.
Obviously, the physical implementation of each of these architectures is quite different. Ideally, the application should be developed in a way that allows the deployment of the application in any of these architectures without changing the application code. That's exactly what Cobol-RPC does.
Cobol-RPC allows you to configure the environment the application executes in without altering the application code. This is accomplished by using a configuration file that specifies the location of programs that are executed remotely. To deploy an application in a different architecture, you simply change the configuration file information.
A number of standards have evolved to address the challenges of client/server and distributed processing.
ODBC has evolved as a standard for implementing client/server by providing clients with access to data on a server. Several products are available that add ODBC capabilities to Cobol applications. ODBC provides the ability to access data on a server but does not effectively address the relocation of business logic.
CORBA provides a specification for, and DSOM an implementation of, the use of objects in a distributed environment. These are of little relevance to current Cobol development practices.
The Open Software Foundation's (OSF) Distributed Computing Environment (DCE) is a comprehensive approach to client/server and distributed systems based on remote procedure calls (RPC). Remote procedure calls are a way of executing logic on a remote computer.
DCE can be utilized for 'C' programming. While it is a workable approach to distributed processing, it is an enormous task to develop a DCE based application. Development and debugging with DCE are extremely difficult. DCE is not an option for Cobol developers.
DCE's remote procedure calls are a simple idea, but the implementation is extremely complicated. This is due to the nature of 'C' programs and data types. Cobol-RPC takes advantage of the characteristics of the Cobol language to implement a simple corollary, remote program calls.
The program is the functional unit of Cobol applications. Cobol applications are built by Cobol programs calling other programs. What Cobol-RPC does is allow this call mechanism to function across any network with TCP/IP protocol support, including the Internet.
This means that a Cobol or non-Cobol application running on a client can call and execute a Cobol program on a server as easily as if it were locally available. Let's step through the process.
Let's begin with the client. At some point in its execution the client application wants to call a Cobol program on a server. The client application calls Cobol-RPC and passes the name of the program it wants to call and the data to pass to the program.
Cobol-RPC checks its configuration file to see where that program is available. Then it contacts the appropriate server with a request to execute the program.
Now we move to the server. When the server receives the request, it checks to see if it already has a conversation established with the client. If not, it starts one by initiating a Cobol runtime. This runtime remains dedicated to the client throughout multiple calls for optimum performance.
After ensuring the server has a conversation with the client, the server receives the data items from the client and executes the requested program. When the server program has completed execution, the server returns the updated values of the data items to the client.
When the client receives the returned data items from the server, the client program continues execution.
Note that with Cobol-RPC multiple levels of remote program calls are supported. The server program could have called a program on a completely different server while servicing the call from the client! This would not effect the client in any way.
Cobol-RPC server programs require no special coding. They are called by clients just as if they were called locally. Many Cobol programs can function as server programs without modification.
Cobol-RPC client programs require little or no special coding. With some implementations server programs are called with the standard CALL statement, just as if they were local. With other implementations a special Cobol-RPC function must be used to call server programs.
Since Cobol-RPC does not change the structure of your application, migrating legacy applications is simple. You select which programs should execute on the client and which on the server.
You may have to make some modifications to programs that will execute on the server. These programs should not contain ACCEPT or DISPLAY statements. In some cases you may split a legacy program into two separate programs, one that accepts information from the user, then calls the second that processes the information. The first program would be placed on the client, the second on the server.
If you are developing client applications in Cobol, Cobol-RPC allows you to develop new client/server and distributed applications using the same language, techniques, and application architecture you already know. It makes client/server and distributed processing a deployment issue, rather than a development issue.
If you are developing client applications in a language other than Cobol, Cobol-RPC lets your application directly utilize the large base of legacy business logic encapsulated in Cobol programs, without reengineering those Cobol programs.
Distributors | Library | Register
Copyright 1996 by England Technical Services, Inc.