The phrases 'client/server', 'distributed computing' and 'cooperative processing' have been in use for some time, but in many ways they are open to interpretation. In fact, the principle behind client/server computing has been a fundamental part of the COBOL language since the very beginning, but today's jargon tends to mask the actual functions being performed.
Essentially, a client is a consumer of services, and a server provides services. Thus the term 'client' could be more accurately defined as 'service requester', and server as 'service provider', with the requester 'calling' the provider for the required service.
In COBOL, the CALL statement is the method used to invoke such requests, but the similarity between the standard CALL statement and client/server functionality may not always be immediately apparent.
The CALL statement is usually associated with calls to local functions (that is, CALLed programs which reside on the same machine as the CALLing program), which can be regarded as services. Thus, CALLing a date validation routine is actually requesting a validation service from a particular module.
CALLs don't necessarily have to be to local functions; they can be made to remote functions (that is, CALLed programs located on a different machine from the CALLing program). These are often referred to as 'remote procedure CALLs' or RPCs.
The client/server model extends the COBOL CALL scenario in the following ways:
Several distributed processing functions, such as presentation logic (screen handling), business logic (data processing) and data access (file/database manipulation), logically suggest themselves as candidates for the client/server model. Middleware (communications/transaction processing) is then needed to connect these distributed functions.
Micro Focus provides products and technologies to address all of the client/server application development and deployment areas listed above.
This section looks at the benefits of a client/server architecture.
If your mission-critical applications suffer from heavy processor burden, poor or outdated user interfaces, total reliance on one or two pieces of hardware, or are just not taking advantage of newer and faster technology, then it is worth considering migrating to a client/server architecture to resolve some or all of these problems.
By using Micro Focus tools and services, you can implement a complete application solution that leverages the power of existing servers, while exploiting the large installed base of desktop lower-end client systems.
You should consider creating an application or migrating existing code to a client/server architecture if you wish to fulfill one or more of the following strategic criteria:
The respective benefits and strategic criteria will depend upon your existing business system architecture and available resources.
This section discusses common client/server architectures - that is the structure or design for distributing the different application elements: presentation logic, business logic and data access. These distributed architectures are commonly referred to as two-tier, three-tier, or n-tier. There are generally two schools of thought regarding the definition of a tier:
Once the application has been modularized, the tiers can be put on separate machines and connected via networks. However, tiers don't have to be distributed, they can be run on a single machine as a standalone application.
For example, the data access element typically resides on a data server (for example, a mainframe), the business logic element on an application server (for example, a UNIX machine, Windows NT or OS/2 PC) and the presentation logic element on a client (for example, a Windows PC).
Regardless of the school of thought, the application must be logically partitioned. This document assumes that logical partitions are also physically partitioned.
There are typically two models of a two-tier client/server architecture:
In a three-tier architecture, the application is typically partitioned into three separate units: presentation logic, business logic and data access.
Tiers located on separate machines are connected via networks, such as Local Area Networks (LANs), Wide Area Networks (WANs), Systems Network Architecture (SNA) or telephone networks.
Figure 1-1 illustrates some typical client/server
architectures; it doesn't show every conceivable distribution
of application elements or platform choice. The models can be
combined or extended beyond 3-tier to n-tier architectures
as best suits your needs. Further details on the platforms available
are provided in the section Platform
Choices.
Figure 1-1 : Typical Client/Server Architectures
As noted in the previous section, tiers located on separate machines are connected via networks. Middleware products typically provide a range of services which allow transparent access to resources in a network.
Micro Focus technology allows you to mask the individual network APIs found with every network protocol provider and to mask the operating system APIs for each of these network providers. This is achieved by providing a single common interface on all protocols and operating systems.
This section examines the variety of platforms you can use in implementing a typical client/server solution. Since one of the primary benefits of a client/server architecture is the ability to use the best machine for each job, you can choose the most suitable platform for your presentation logic, business logic and data access.
For client platforms, which typically contain the presentation logic (and perhaps portions of the business logic), the choice is typically made from DOS, Windows 3.1, Windows 95, Windows NT, or OS/2.
Server platforms, which typically contain the business logic and data access elements, are selected according to application throughput requirements. Depending on your needs, you can select from a range of low- to medium-end platforms, such as Windows NT, OS/2, NetWare or single or multiprocessor UNIX systems through to high-end servers such as superminis or mainframes.
Most platforms could function as both client or server, but Table 1-1 lists the types of platforms commonly used in implementing a Micro Focus Client/Server solution.
| Platform | ||
| Dumb Terminal | ||
| DOS | ||
| Windows 3.x, Windows 95 | ||
| Windows NT | ||
| OS/2 | ||
| NetWare | ||
| UNIX | ||
| Mainframe |
The platform you choose for each tier depends upon the particulars of your application, such as where your existing application currently resides; where your presentation logic, data access and business logic currently reside and where you plan to relocate them; what type of platforms are currently available or planned for your users; and what your level of experience is in client/server development. The following sections describe a number of scenarios experienced by Micro Focus customers.
Often a large mainframe-oriented company first decides to test the waters of client/server by using the DS3270 facility of Dialog System to implement a graphical front end for existing 3270 applications. DS3270 maps the 3270 screens on the mainframe to Dialog System screensets on PCs; that is, the GUI interface is deployed on PCs, while the application itself remains on the mainframe.
The next stage is often to rehost all or part of the existing application from the mainframe. For example, the application's business rules are migrated to a UNIX server.
Finally, experienced development organizations anticipate these changing requirements, so they design and create new applications based on a flexible client/server architecture from the outset, deploying application components on the most suitable platform.
A UNIX oriented MIS department or an ISV may have a standalone UNIX application which it decides to extend to a client/server architecture to meet its users' needs.
The application's character user interface may have been hardcoded for display on a UNIX dumb terminal. A typical first step is to separate out the user interface using character Dialog System to provide a more user friendly interface using Dialog System's windowing facilities.
The next step is often to replace the character interface with a graphical user interface using GUI Dialog System in order to take full advantage of graphical PCs.
Separating out the data access portion of the application onto a server to allow improved data sharing or to host the data access on a more appropriate data server may be the following step.
There may also be demand to move data access to the mainframe or to integrate departmental data with existing corporate data on the mainframe; that is, to have the data server or part of the data server located on the mainframe.
Finally, experienced development organizations again, will want to anticipate these changing requirements, so they design and create new applications based on a flexible client/server architecture from the outset.
Often a small company's MIS department or an ISV may have developed a standalone PC application which it needs to extend to a client/server architecture to meet its users' needs.
The application may have been created with a hardcoded character user interface. The first step may often be to modernize the application by splitting out the user interface in order to implement a GUI interface or just to ease application maintenance.
The next step may be to separate out the business logic and host this on a high performance multi-user UNIX server, thereby taking advantage of the higher processing power and easing the roll out of fixes or new versions of the application business logic.
There is then often demand to move data access to the mainframe or to integrate departmental data with existing corporate data on the mainframe; that is, to have the data server or part of the data server located on the mainframe.
Again, experienced development organizations anticipate these changing requirements, so they design and create new applications based on a flexible client/server architecture from the outset.
Whether you are migrating to client/server from a mainframe, UNIX or PC background, you will typically end up creating new applications based on a client/server architecture.
The remainder of this document focuses on how you create a new Dialog System client/server application, describing the Micro Focus tools you need and how you actually implement an application.
Much of the information will still be of use to anyone
trying to understand how to migrate existing applications.