|
|
Introduction to Client Server Architectures
Shortly after computers were used in business, programmers realized that most business applications had three distinct components:
Most business applications have a Client software component that interacts with the user of the application and a Server software component that provides services to that user. Client/Server systems are those computer applications that are developed with a conscious effort to identify the three components above and to determine where these components reside in the a system of networked computers.
In this course the words Client and Server often have two meanings in the same context. The Client can be both a computer type and the software that contains the user interface code. The server can mean a computer type or the software that provides services. In a lot of cases you will need to look at the context to see which meaning is being used.
Information By Talal Ahmed Siddiqui have used the following Refrencess
To see comments about which portions of Talal Ahmed Siddiqui Designing Component Based Applications text are related to this Information click the link below.
Go to the Designing Component Based Applications text material?
A little History of Client/Server Computing
Most of the early computer applications were scientific. The main purpose of the computer was to intelligently evaluate a lot of scientific formulas. Many realized that these scientificcomputers might be helpful in nonscientific applications, like the payroll. The IBM 370 was the major business computer of the 70's. It had an intelligent terminal, the 3270, and a very good transactional processing system, CICS. Applications developed with CICS were called Online Applications and were the state of the art until the 80's. CICS is still a very good architecture for "thin" C/S computing and all newer systems owe a debt to CICS for their architectural ideas. I will give a more detailed discussion of CICS in the next section.
UNIX and its derivatives, like DEC's VMS operating system, was also first used by the scientific computing community. UNIX was better designed for a networking environment than the IBM 370 with MVS and as networking of computers became common place UNIX systems became viable C/S platforms. Business computing done on networked UNIX systems is called Interactive Computing. A user in an interactive UNIX system had much more control over the operating system than a user with a IBM 370 since the UNIX user could execute operating system commands and utilities at a workstation. Early UNIX systems were mainframes, just like the IBM 370, but later UNIX workstations supported real distributed processing. The high point of interactive computing came when the Open Software Foundation (OSF) developed a framework for distributed computing called the Distributed Computing Environment (DCE). This was a very well thought theory of distributed computing that has influenced many of the later developments in Object-Oriented Client/Server. I will describe some of the key features of DCE later. DCE as implemented by the computer industry had a couple of small problems:
The joint development of Microsoft Operating Systems and chip-based microcomputers has introduces a new era in C/S. We now have inexpensive client workstations with user-friendly interfaces that are powerful, reliable and easy to use. These new systems are also part of the networked world. This technology has enabled us to develop a new Client/Server architecture, the Object-Oriented Client/Server Architecture.
There are two flavors of OO C/S. For Microsoft an object is just the logical extension of a DLL. This isreasonable since Microsoft an Operating Systems company. I will refer to Microsoft's OO C/S architecture as ActiveX/DCOM/OLE. A competing architecture is being developed by the rest of the computing community. This architecture sees the run-time object more in terms of the classes that are used to instantiate them. Initially the architecture was driven by C++, but recently it has been driven by Java. The competing architecture is called the Common Request Broker Architecture (CORBA) and it is being developed zby the Object Management Group (OMG). We will look at some CORBA architecture ideas later.
About the time we thought that things had stabilized for C/S architectures along came the Internet. All at once almost everyone realized that a Web Browser could easily be the user interface for real OO C/S applications. Microsoft produced the Dynamic Internet Architecture very quickly and the CORBA camp followed with a similar architecture a little later. It is clear that web-based OO C/S will be important in the future, but it is not clear right now just how important this type of C/S will be.
As the personal computer industry moved forward over the past few years an interesting thing have happened. The computer, telephone and entertainment industries are all looking to use the same platform for both home and business. This integration has lead to considerations of government control of the resulting technology. It will be interesting to see how govermental influence will effect the development of C/S computing over the next few years.
Online Computing (CICS) and Client/Server
The Customer Information Control System (CICS) of IBM was developed to support transactional applications for IBM's MVS operating system. Features of MVS have appeared in some of the "new" micro kernel operating systems like Windows NT and OSF UNIX. Features of CICS have appeared in some "new" transactional monitors like MTS. Because of this any time spent looking at MVS and CICS is useful.
MVS is a batch-oriented operating system that supports multiple JOBs. Each JOB consists of multiple processes (JOB Steps) and each process can have multiple threads (TASKs). MVS supports complex file and database systems. Input to MVS programs is largely via file images. Programming support for MVS can be interactive via time-sharing options. CICS is loaded as a single MVS JOB that runs all the time. Users interact with a CICS application via an intelligent 3270 terminal that sends/receives entire screens of data between a user and the computer.
A CICS application has a simple structure that is based on screen-flow. The application puts an initial screen on the user's terminal. The user modifies all needed data on the screen . The user then submits the data of the screen to a Program-unit. Program-units are completely asynchronous in their execution with data saved by the system, or programmer, between program-unit executions. At the end of each program-unit's execution a new screen is transmitted to the user, unless the entire application has finished. The following flowchart describes a typical CICS application.
 |
Each program-unit of a CICS application was reentrant code, that is it can be accessed by multiple threads. This is accomplished by CICS giving each user of a program-unit a separate data area. CICS allows programmers to define an application as transactional so that all data modifications to all data sources are either updated or rolled back. CICS is a very good transactional processor, but its popularity is down at the moment because it is seen as a mainframe utility. IBM has several approaches to transactional C/S, including an upgraded version of CICS, all of which use the key ideas of CICS. In fact all transactional processors have added similar functionality to CICS as we will see when we study MTS.
Interactive Computing and Client/Server
An interactive computing system is one that allows a user to interact with the operating system directly via an input device. The first popular interactive computing system was UNIX (and its close relatives DOS and VMS). There are two related C/S questions that one needs to consider for C/S systems implemented on interactive computing systems. These are
Implementing basic C/S capability for interactive computing systems is where the term Client/Server first came from. An IBM 370 type of computer gave good access to databases like IMS and DB2 via CICS. But all of the computing of business processes and data accesses took place on the server. There was no way to distribute the computing to a clients workstation because CICS treated a workstation like a terminal. UNIX systems, on the other hand, could move much of the business logic to a workstation and improve performance (the server slowed down with many users). The Microsoft also jumped on this bandwagon introducing Open Database Connectivity (ODBC) as a traditional C/S middleware. First you then added your ODBC driver and Data Source to allow you to access a database on the Client computer. Then you would write a program inserting Microsoft's dialect of SQL into the code. The following diagram illustrates run-time environment.
 |
||
| An ODBC application is written in a language like VC++. At
certain point in the program a SQL statement is placed in the code, like a
C++ function call. Earlier the correct ODBC driver was loaded on the
client computer and a data source that corresponds to the driver was
configured via Control Panel. At run-tine the ODBC Driver Manager then
selects the correct driver (and loads it if necessary), gets the data from
the database corresponding to the configured data source and returns the
data to an appropriate data structure of the application
This model is similar to that followed in all cases in traditional C/S. | ||
Traditional C/S is based on using SQL commands in your program to return the data. SQL commands are really just powerful function calls. If you need to add some functionality to this procedural SQL, like multi-database transactional capability, then you need to add something to the SQL. Database vendors have added their own extensions to SQL. Some of these extensions are Stored Procedures, Triggers and special transactional commands. If this were a pure database course we might spend a lot of time considering these. But since this is more of an architecture course we will just mention the existence of the traditional C/S solutions to SQLs limitations in building Enterprise Applications.
An architectural solution for SQL's lack of support for transactions is to add a Transaction Processor Monitor (TP Monitor) to an Enterprise Server. A TP Monitor is a piece of systems software that adds transactional processing commands either the programming language being use or to the operating system being used (or both). The programmers can use pure SQL but transactional support for multiple databases would also exist. The diagram below captures the architecture of transactional applications in an interactive computing environment.
 |
||
| Client programs send SQL data requests to Server. TP Monitor looks at commands and does what is necessary to guarantee that transactions are executed correctly (either roll-back or commit). This usually means that the TP Monitor places all data requests in a queue so that it knows which data request was first, second, ... for each application and the entire system as well. | ||
Object-Oriented Client/Server
A lot of people decided a few years ago that programming with objects was the way to go. I am one of those so we will concentrate on developing OO C/S systems with run-time objects rather than the other types of C/S described sbove. Actual the basic idea of OO C/S is fairly simple. You still write programs. On both the client and server events will be important, so your program generally has three parts
At run-time your application will use the properties, methods and events of a lot of distributed objects. Program development involves both creating run-time objects and using them in a higher level program. As with all business programs, data is important. Data will be represented by objects. When you instantiate a data object you often use a SQL method to get the data from a database. You may also want to work with data in E-mail, spreadsheets or on HTML pages. All of this type of data will also be represented by data objects. You will have to spend a fair amount of time giving the programming environment information about objects so that the expected objects will be in the place at run-time.
The operating systems, network environment and utilities need to be Object-Oriented so that you can get a hold of their objects at run-time. For example in ActiveX/DCOM/OLE MTS will be an OO TP Monitor, among other things, and you will create objects using MTS that will support transactional processing of multiple databases (like Oracle and SQLServer). You will also use ActiveX Data Objects (ADO) to get data objects from databases, E-mail, spreadsheets and other data sources.
When you develop a Client program in a language like VB and access an application on a Server written in a language like C++ that gets data from a database using ADO or ODBC, then you are doing OO C/S computing. There are a lot of good books that describe this type of computing now. Change all the Microsoft specific words to CORBA/Java Beans words and you get a similar model of developing OO C/S applications with run-time objects. The distributed objects lecture and the specific lectures on ActiveX/DCOM/OLE and CORBA/Java Beans will amplify on this later.
Web-based Object-Oriented Client/Server
Web-based OO C/S applications will be an important part of C/S computing in the future. I do not think that all C/S applications will be web-based, but I do believe that a major portion of the C/S applications will be web-based. The text by Mary Kirtland, Designing Component-based Applications, is essentially a complete description of web-based OO C/S as it exists in 1999.
As is often the case the main ideas of Web-based OO C/S are fairly simple extensions of OO C/S. While there are several architectures for web-based OO C/S the Dynamic Internet Architecture (DNA) of Microsoft is typical of all and I do not plan to study others in this class. Quite frankly, Microsoft did it first and there does not seem to be much difference between what Microsoft has done and what CORBA/Java Beans is doing.
On the Client side you replace the Client program (written in a language like J++) with a set of DHTML page that are interpreted on the Client computer by the Browser. You put scripting code (like VBScript) in the DHTML pages that execute under control of a component of the Browser. By using methods of ActiveX controls the scripting code can get the efficiency of machine code. With DHTML you can program the Browser object model and get near Windows like functionality. With the new ideas contained in VB WebClasses you can get as much security on the Client computer as you can with regular OO C/S.
On the Server you replace the C++ server program with and ASP file. The ASP file is interpreted by an Internet Information Server (IIS) and the ASP file's server-side script (really VBScript) is executed by a component of IIS. The server-side script can use ActiveX controls (with MTS as an Object Request Broker), DLL/EXE Automation Servers (called ISAPI things) and objects of BackOffice (I think that this object model is only getting started, but IIS and ADO objects are ready to go).
This page was last modified by Talal Ahmed Siddiqui on September 21, 2001