Client Server Technology

INDEX 1.Abstract 2. Client Sever Architecture 2.1 Evolution 2.2 Evolution of Architectures: 2.2.1 Mainframe architecture 2.2.2 File sharing architecture: 2.2.3 Client/server architecture: 2.3 Client Server Architecture Models: 2.3.1 FAT Vs THIN 2.3.2Two-tier and Three-tier Architectures: 2.4 Characteristics 2.5 General Issues in client-server computing 3. Distributed System Architecture 3.1 Remote Procedure Call (RPC): 3.2 Object Management Architecture (OMA): 3.3 Distributed Resource Architecture: 3.3.1. Distributed data Architecture: 3.3.2 Distributed Server Architecture: 3.3.3 Distributed Computing Architecture: 4. Distributed Architecture Requirements 5. Conclusions 6. Bibliography

1. ABSTRACT The evolution of networking technology has necessitated simpler and efficient technologies to share the various resources; the resources include data, hardware and computing power. Two technologies that enabled this are Client/server and Distributed Systems architecture. Client server architecture, which was introduced in the early 1970s, became a subset of newer and emerging Distributed Systems architecture. The following pages will trace this evolutionary path all the while discussing the intricate technologies involved, their advantages, limitations, applications and their future scope. It will also discuss the Software Engineering concepts as applied to these technologies.

2. Client Server Technology 2.1 Evolution: The term client/server was first used in the 1980s in reference to personal computers (PCs) on a network. The actual client/server model started gaining acceptance in the late 1980s. The client/server software architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability, and scalability as compared to centralized, mainframe, time sharing computing. A client is defined as a requester of services and a server is defined as the provider of services. A single machine can be both a client and a server depending on the software configuration.

2.2 Evolution of Architectures: 2.2.1

Mainframe

architecture

:

With

mainframe

software

architectures all intelligence is within the central host computer. Users interact with the host through a terminal that captures keystrokes and sends that information to the host. Mainframe software architectures are not tied to a hardware platform. User interaction can be done using PCs and UNIX workstations. A limitation of mainframe software architectures is that they do not easily support graphical user or access to multiple databases from geographically dispersed sites. In the last few years, mainframes have found a new use as a server in distributed client/server architectures 2.2.2 File sharing architecture: The original PC networks were based on file sharing architectures, where the server downloads files from the shared location to the desktop environment. The requested user job is then run (including logic and data) in the desktop environment. File sharing architectures work if shared usage is low, update contention is low, and the volume of data to be transferred is low. In the 1990s, PC LAN (local area network) computing changed because the capacity of the file sharing was strained as the number of online user grew (it can only satisfy about 12 users simultaneously) and graphical user interfaces (GUIs) became popular (making mainframe and terminal displays appear out of date). PCs are now being used in client/server architectures. 2.2.3 Client/server architecture: As a result of the limitations of file sharing architectures, the client/server architecture emerged. The client is the software component that requests a service. The server is the component that provides the service. In a file sharing network, for example, the workstation contains the client and the file server contains the server. The service is file access, and includes read and write access as well as file locking. Communication between the client and server occurs over the network. Software that carries on the communication between client and server is sometimes called middleware. Client/server doesn't necessarily

imply a network. A client/server architecture can exist on a single machine. An example of this in Windows is the Print Manager. Print Manager is a server that exists on most Windows computers. Client/server does imply a many-toone relationship between clients and server. One server offers specialized services to multiple clients. In the example of Print Manager, the clients are all applications that perform printing. A client/server network is a network that uses a client/server architecture, with servers existing on specialized, usually dedicated, computers. The servers run in a software environment that is specially designed to support the needs of the server component. 2.3 Client Server Architecture Models: Client/server systems can also be classified based on the amount of processing that happen on the client machine and on the server machine and the method of processing. 2.3.1 FAT Vs THIN: The processing location based Clients and servers may be ``fat’’ or ``thin’’. Fat clients use up space on each client they run on, may have complex installation requirements, etc (e.g. Netscape 3.0). Thin clients have reduced functionality, but are easier to manage .The network computer model favours thin clients. A fat client is a client that contains a lot of software and does a lot of processing. An example of a fat client is a workstation running Microsoft Word, editing a document that is stored on a file server. Although a server is involved, most of the software and processing occur on the client workstation. A fat server is a server that runs a lot of software and does a lot of processing. A classic mainframe application is an example of a fat server. Almost all the processing occurs on the server. The client simply displays data and accepts user input. (In mainframe applications, even input editing is done on the server.)

2.3.2 Two-tier and Three-tier Architectures: The processing method based While "fat" and "thin" refer to how much occurs on the client or server, "two-tier" and "three-tier" refer in a more specific way to how functionality is split. In a two-tier architecture, software functionality is split into two components, one of which runs on the client, the other on the server. The two tier client/server architecture is a good solution for distributed computing when work groups are defined as a dozen to 100 people interacting on a LAN simultaneously. It does have a number of limitations. When the number of users exceeds 100, performance begins to deteriorate. This limitation is a result of the server maintaining a connection via "keep-alive" messages with each client, even when no work is being done. A second limitation of the two tier architecture is that implementation of processing management services using vendor proprietary database procedures restricts flexibility and choice of DBMS for applications. Finally, current implementations of the two tier architecture provide limited flexibility in moving (repartitioning) program functionality from one server to another without manually regenerating procedural code. In a three-tier architecture, the software functionality is split into three components: the user interface, the application logic, and resource (data) management. The phrase "three-tier" has had several different meanings. It has also been used to describe partitioning an application between (1) a PC client, (2) a departmental server, and (3) an enterprise server, and to describe partitioning between (1) a client component, (2) a local database, and (3) an enterprise database.. The most basic type of three tier architecture has a middle layer consisting of Transaction Processing (TP) monitor technology .The TP monitor technology is a type of message queuing, transaction scheduling, and prioritization service where the client connects to the TP monitor (middle tier) instead of the database server. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client. When the capability is

provided by third party middleware vendors it is referred to as "TP Heavy" because it can service thousands of users. When it is embedded in the DBMS (and could be considered a two tier architecture), it is referred to as "TP Lite" because experience has shown performance degradation when over 100 clients are connected. TP monitor technology also provides •

the ability to update multiple different DBMSs in a single transaction

•

connectivity to a variety of data sources including flat files, nonrelational DBMS, and the mainframe

•

the ability to attach priorities to transactions

•

robust security

Using a three tier client/server architecture with TP monitor technology results in an environment that is considerably more scalable than a two tier architecture with direct client to server connection. 2.4 Characteristics Client/server is a software model of computing, not a hardware definition. Because the client/server environment is typically heterogeneous, the hardware platform and operating system of the client and server are not usually the same. In such cases, the communications mechanism may be further extended through a well-defined set of standard application program interfaces (APIs) and remote procedure calls (RPCs). This architecture has the following characteristics.  A client-user relies on the desktop workstation for all computing needs. Whether the application runs totally on the desktop or uses services provided by one or more servers—be they powerful PCs or mainframes —is irrelevant.  Effective

client/server

computing

is

fundamentally

platform-

independent. The user of an application wants the business functionality it provides; the computing platform provides access to this

business functionality. There is no benefit, yet considerable risk, in exposing this platform to its user.  Changes in platform and underlying technology should be transparent to the user. Training costs, business processing delays and errors, staff frustration, and staff turnover result from the confusion generated by changes in environments where the user is sensitive to the technology platform. 2.5 General Issues in client-server computing  Wise Use of Existing Investments Successful

client/server

solutions

integrate

with

the

existing

applications and provide a gradual migration to the new platforms and business models.  Connectivity—Management of Distributed Data Resources Information must be made available to the data creators and maintainers by providing the connectivity and distributed management of enterprise databases and applications. The technology of client/server computing should support the movement of information processing to the direct creators and users of information  Online Transaction Processing (OLTP) OLTP applications traditionally have been used in insurance, financial, government, and sales-related organizations. These applications are characterized by their need for highly reliable platforms that guarantee that transactions will be handled correctly, no data will be lost, response times will be extremely low (less than three seconds is a good rule of thumb), and only authorized users will have access to an application. The IS industry understands OLTP in the traditional mainframe-centered platforms but not in the distributed client/server platforms. The other considerations are  Systems Administration  Availability  Reliability  Serviceability

 Software Distribution  Performance  Network Management  Remote Systems Management  Security There a number of tradeoffs that must be made to select the appropriate client/server architecture. These include business strategic planning, and potential growth on the number of users, cost, and the homogeneity of the current and future computational environment.

3. Distributed System Architecture “A distributed system is a system designed to support the development of applications and services which can exploit a physical architecture consisting of multiple, autonomous processing elements that do not share primary memory but cooperate by sending asynchronous messages over a communication network” – Blair & Stefani In any system two aspects may be distributed, these are a.) Components of the application running on the system and b.) System resources, thus client/server technology becomes a general case of (a) which may be rephrased as distributed component computing or as distributed object computing. Which are basically client/server models with middleware the various types of middleware are: 3.1 Remote Procedure Call (RPC): This has the following characteristics: a. Uses the well-known procedure call semantics. b. The caller makes a procedure call and then waits. If it is a local procedure call, then it is handled normally; if it is a remote procedure, then it is handled as a remote procedure call. c. Caller semantics is blocked send; callee semantics is blocked receive to

get the parameters and a non-blocked send at the end to transmit results. This middleware architecture may be depicted as in the following diagram

3.2 Object Management Architecture (OMA): This is an object oriented architecture and may be depicted as follows:

The various OMA Modules that may be identified from the above diagram are Object Request Broker: directs requests and answers between objects Object Services: basic functions for object management (e.g., name service) Common Facilities: generic object-oriented tools for various applications (e.g., a class browser) Application Objects: classes specific to an application domain (e.g., a CASE tool) Here we may define an object and a request as follows: An object is an abstraction with a state and a set of operations

A request is an operation call with one or more parameters, any of which may identify an object (multi-targeting); Arguments and results are passed by value. The following are the features of CORBA •

Communications substrate

•

A specific programmer interface (no implementation)

•

Multi-vendor ORBs to interoperate (CORBA-2)

•

Layered on top of other communication substrates (RPC, byte streams, IPC,…)

•

Language mapping (C, C++, Ada, Smalltalk, Java,Cobol)

•

ORB interface.

3.3 Distributed Resource Architecture: The term distributed can be applied to any resource that can be shared., this includes data, services, hardware, computing power. Thus there are 3 types of distributed architectures. 1. Distributed data architecture 2. Distributed Server architecture 3. Distributed computing architecture 3.3.1. Distributed data Architecture: This consists of distributed file systems and distributed databases. Distributed file systems allow the application to have an integrated logical view of data spread over several computer systems. These use the operating systems native system call mechanism, including RPC to achieve this effect. An example of this is the coda file system. It is a state of the art experimental system developed at CMU. It has been ported to Linux, Net BSD, Free BSD. Currently a large portion of Coda had been ported to Win95 and efforts are being made to understand the feasibility of porting to NT. Distributed Database: It is a set of databases stored on multiple computers at different locations and it appears to the user as a single database. Those computers are in a network environment and the user (or

application) can access, update, or modify the data in several databases through the network. The locations of the distributed database may be spread over a large area around the world, or over a small area such as one building One of the major objectives of a distributed database is to provide the users with easy access to data at many different locations. They are several reasons that encourage the use of a distributed database: •

Distribution and autonomy of business units: Divisions, department, and facilities of modern organizations are geographically distributed.

•

Data sharing: Data sharing will always be there, so it must be convenient and consolidated.

•

Data communications costs and reliability: Transferring large amount of data across the network can be very costly and will affect the network performance. Also, dependence on data communication can be risky.

An example of Distributed database is oracle this concept is described below: Oracle Client/Server Concept

The

software

that

manage

the

database is called the database server and the application that requests information from that server is the client or a node. A client can connect to the database server either directly or indirectly. For example, client A can connect to server B directly and to server C indirectly through server B. Server C here will be the remote site for the data.

Overview Oracle Distributed Database System: The Network Connection: Net8 is an Oracle's network software that provides the inter-database communications across the network. It connects clients and servers through the network in a distributed database system. Net8 performs all it's operations independent of the network operating system (NOS). Database Replication It is the process of storing a copy of the database at each location of the distributed database system. It has several advantages: •

Reliability: If one site containing the database fails, a copy can always be accessed at another site.

•

Fast response time: Each site has a local copy of the database, so queries can be executed faster.

•

Node decoupling: Transaction may proceed without coordination across the network.

•

Improve performance by minimizing the network traffic at prime time

The Disadvantages are:

•

Storage requirements: Each site must storage capacity to store copy of the database.

•

Complexity and cost of updating: When updating the database, all sites must be updated.

Heterogeneous Distributed Database One of the database systems may not be an oracle database system, this is called heterogeneous distributed database system. Oracle uses a component within the software called Heterogeneous Services to provide the common architecture and the administrative tools for this type of a distributed database. The communications between the non-Oracle system and the Heterogeneous Services are handled by Oracle software called Oracle Gateway. 3.3.2 Distributed Server Architecture: Modern networking services require high-availability(HA) and high-reliability, these maybe served by system level distributed servers such as piranha and Linux virtual server architecture described below: Piranha is strictly a software HA implementation. Piranha is the name of the cluster package, and also of the GUI administrative tool for the cluster interface to the entire cluster system. The clustering system is quite modular in nature and can be completely configured and run from a text mode, command line interface. Requests for service from a Piranha cluster are sent to a virtual server address: a unique triplicate consisting of a protocol, a floating IP address, and a port number. Depending on the role it performs, a computer in a Piranha cluster is either a router or a real server. A router receives job requests and redirects those requests the real servers that actually process the requests. This architecture thus ensures fail-over and hence reliability 3.3.3 Distributed Computing Architecture:

The complexity and size of software are increasing at a rapid rate. This results in the increase in build time and execution times. Cluster computing is proving to be an effective way to reduce this in an economical way. Currently, most available cluster computing software tools which achieve load balancing by process migration schemes. They share processing power, memory and network resources, software such as MOSIX enable this. This system is described below: Mosix is a software that was specifically designed to enhance the Linux kernel with cluster computing capabilities. It is a tool consisting of kernel level resource sharing algorithms that are geared for performance scalability in a cluster computer. Mosix supports resource sharing by dynamic process migration. It relieves the user from the responsibility of allocation of processes to nodes by distributing the workloads dynamically. The resource sharing algorithm of Mosix attempts to reduce the load differences between pairs of nodes (systems in the cluster) by migrating processes from higher loaded nodes to lesser loaded nodes. This is done in decentralized manner i.e. all nodes execute the same algorithms and each node performs the reduction of loads independently. Also, Mosix considers only balancing of loads on processors and responds to changes in loads on processors as long as there is no extreme shortage of other resources such as free memory and empty process slots.

4.Distributed Architecture Requirements The following are the requirements of a distributed architecture: 1. Enable client application transparency 2. Enable server application transparency 3. Support dynamic client operation request patterns 4. Maximize scalability and equalize dynamic load distribution 5. Increase system dependability 6. Support administrative tasks 7. Incur minimal overhead

8. interoperability and portability 9. application-defined load metrics and balancing policies

5. CONCLUSION Client-Server

Architecture,

Distributed

object

architectures

and

Distributed Resource Architectures are not independent but interrelated concepts, this can be seen in concepts such as Coda-FS which use the OS level RPC mechanism. Newer versions of CORBA are being released, the latest being CORBA v3, the current versions of MOSIX is focusing on thread migration and interoperability between various operating systems. Other products such as the Globus Toolkit from IBM focus on standardization of some distributed service architectures such as FTP. The development thus in the distributed systems is growing while client-server architecture is taking on newer dimensions.