1

UNIT I CLIENT / SERVER CONCEPTS

What is Middleware?

• Middleware does not include the software that provides the actual service

that’s in the server’s domain.

• It also does not include the user interface or the application’s logic that’s in the

client’s domain.

• It starts with the API set on the client side that is used to invoke a service, and

it covers the transmission of the request over the network and the resulting

response.

• Middleware divided into two broad classes:

(a) General Middleware (b) Service-Specific Middleware

a) General Middleware

• It is the substrate for most client/server interactions

• It includes the communication stacks, distributed directories, authentication

stacks, distributed directories, authentication services, network time, remote

procedure calls, and queuing services.

• Products that fall into the general middleware category include DCE, ONC+,

NetWare, NamedPipes, LAN Server, LAN Manager, Vines, TCP/IP, APPC

and NetBIOS.

• Message Oriented Middleware (MOM) products from Peerlogic, Covia,

Message Express, System Strategies and IBM.

• These are depends on message queue system and increases portability,

interoperability, flexibility.

b) Service-Specific Middleware

• It is need to accomplish a particular client/server type of service.

• This includes

2

o Database-specific middleware such as ODBC, DRDA, EDA/SQL,

SAG/CLI and Oracle Glue.

o OLTP-specific middleware such as Tuxedo’s ATMI and /WS,

Encina’s Transactional RPC, and X/Open’s TxRPC and XATMI

o Groupware-specific middleware such as MAPI, VIM, VIC, SMTP

and Lotus Notes Calls

o Object-specific middleware such as OMG’s CORBA and Microsoft’s

Network OLE (or DCOM)

o Internet-specific middleware such as HTTP, S-HTTP and SSL

o System Management-specific middleware such as SNMP, CMIP and

ORBs.

Client/Server Concepts

Client-server is a computing architecture which separates a client from a

server, and is almost always implemented over a computer network. Each client or

server connected to a network can also be referred to as a node. The most basic type

of client-server architecture employs only two types of nodes: clients and servers.

This type of architecture is sometimes referred to as two-tier. It allows devices to

share files and resources.

Each instance of the client software can send data requests to one or more

connected servers. In turn, the servers can accept these requests, process them, and

return the requested information to the client. Although this concept can be applied

for a variety of reasons to many different kinds of applications, the architecture

remains fundamentally the same.

These days, clients are most often web browsers, although that has not always

been the case. Servers typically include web servers, database servers and mail

servers. Online gaming is usually client-server too. In the specific case of MMORPG,

3

the servers are typically operated by the company selling the game; for other games

one of the players will act as the host by setting his game in server mode.

The interaction between client and server is often described using sequence

diagrams. Sequence diagrams are standardized in the Unified Modeling Language.

Contents

• 1 Characteristics

o 1.1 Characteristics of a client

o 1.2 Characteristics of a server

• 2 Multi-tiered architecture

• 3 Comparison to Peer-to-Peer Architecture

• 4 Comparison to Client-Queue-Client Architecture

• 5 Advantages

• 6 Disadvantages

• 7 Examples

• 8 Notes

• 9 See also

Characteristics

Characteristics of a client

• Request sender is known as client

• Initiates requests

• Waits for and receives replies.

• Usually connects to a small number of servers at one time

• Typically interacts directly with end-users using a graphical user interface

Characteristics of a server

• Receiver of request which is send by client is known as server

• Passive (slave)

• Waits for requests from clients

4

• Upon receipt of requests, processes them and then serves replies

• Usually accepts connections from a large number of clients

• Typically does not interact directly with end-users

Multi-tiered architecture

Some designs are more sophisticated and consist of three different kinds of nodes:

clients, application servers which process data for the clients, and database servers

which store data for the application servers. This configuration is called a three-tier

architecture, and is the most commonly used type of client-server architecture.

Designs that contain more than two tiers are referred to as multi-tiered or n-tiered.

The advantages of n-tiered architectures is that they are far more scalable, since they

balance and distribute the processing load among multiple, often redundant,

specialized server nodes. This in turn improves overall system performance and

reliability, since more of the processing load can be accommodated simultaneously.[1]

The disadvantages of n-tiered architectures include:

1. More load on the network itself, due to a greater amount of network traffic.

2. More difficult to program and test than in two-tier architectures because more

devices have to communicate in order to complete a client’s request.

Comparison to Peer-to-Peer Architecture

Another type of network architecture is known as peer-to-peer, because each node or

instance of the program can simultaneously act as both a client and a server, and

because each has equivalent responsibilities and status. Peer-to-peer architectures are

often abbreviated using the acronym P2P.

Both client-server and P2P architectures are in wide usage today

Comparison to Client-Queue-Client Architecture

While classic Client-Server architecture requires one of communication endpoints to

act as a server, which is much harder to implement, Client-Queue-Client allows all

endpoints to be simple clients, while the server consists of some external software,

5

which also acts as passive queue (one software instance passes its query to another

instance to queue, e.g. database, and then this other instance pulls it from database,

makes a response, passes it to database etc.). This architecture allows greatly

simplified software implementation. Peer-to-Peer architecture was originally based on

Client-Queue-Client concept.

Advantages

• In most cases, client-server architecture enables the roles and responsibilities

of a computing system to be distributed among several independent computers

that are known to each other only through a network. This creates an

additional advantage to this architecture: greater ease of maintenance. For

example, it is possible to replace, repair, upgrade, or even relocate a server

while its clients remain both unaware and unaffected by that change. This

independence from change is also referred to as encapsulation.

• All the data is stored on the servers, which generally have far greater security

controls than most clients. Servers can better control access and resources, to

guarantee that only those clients with the appropriate permissions may access

and change data.

• Since data storage is centralized, updates to those data are far easier to

administer than would be possible under a P2P paradigm. Under a P2P

architecture, data updates may need to be distributed and applied to each

“peer” in the network, which is both time-consuming and error-prone, as there

can be thousands or even millions of peers.

• Many mature client-server technologies are already available which were

designed to ensure security, ‘friendliness’ of the user interface, and ease of

use.

• It functions with multiple different clients of different capabilities.

Disadvantages

• Traffic congestion on the network has been an issue since the inception of the

client-server paradigm. As the number of simultaneous client requests to a

given server increases, the server can become severely overloaded. Contrast

that to a P2P network, where its bandwidth actually increases as more nodes

6

are added, since the P2P network’s overall bandwidth can be roughly

computed as the sum of the bandwidths of every node in that network.

• The client-server paradigm lacks the robustness of a good P2P network. Under

client-server, should a critical server fail, clients’ requests cannot be fulfilled.

In P2P networks, resources are usually distributed among many nodes. Even if

one or more nodes depart and abandon a downloading file, for example, the

remaining nodes should still have the data needed to complete the download.

Examples

Imagine you are visiting eCommerce web site. In this case, your computer and web

browser would be considered the client, while the computers, databases, and

applications that make up the online store would be considered the server. When your

web browser requests specific information from the online store, the server finds all of

the data in the database needed to satisfy the browser’s request, assembles that data

into a web page, and transmits that page back to your web browser for you to view.

Specific types of clients include web browsers, email clients, and online chat clients.

Specific types of servers include web servers, ftp servers, application servers,

database servers, mail servers, file servers, print servers, and terminal servers. Most

web services are also types of servers.

Notes

1. ^ This form of scalability is called horizontal scalability. There is substantial

and growing criticism that horizontal scalability is limiting as applications

become more complex and interdependent, particularly in the areas of network

latency, reliability, and manageability. IBM, in particular, takes this view and

promotes both vertical and horizontal scalability. Vertical scalability

implements fewer servers able to support multiple application and database

tiers, and multiple applications, concurrently. The IBM System z is the most

notable example of a vertically scalable system.

Fat Servers OR Fat Clients

7

• Client/Server applications can also be differentiated by how the distributed

application is split between the client and the server.

• The fat server model places more function on the server.

• The fat client does the reverse.

• Groupware, transaction and the web servers are examples of fat servers;

database and file servers are examples of fat clients.

• Distributed objects can be either.

Fat Client

• Fat clients are the more traditional form of client/server.

• The bulk of the application runs on the client side of the equation.

• In both the file server and database server models, the clients know how the

data is organized and stored on the server side.

• Fat clients are used for decision support and personal software.

• They provide flexibility and opportunities for creating front-end tools that let

end-users create their own applications.

Fat Server:

• Fat Server applications are easier to manage and deploy on the network

because most of the code runs on the servers.

8

• Fat servers try to minimize network interchanges by creating more abstract

levels of service.

• Transaction and object servers, for example, encapsulate the database.

• The client in the fat server model provides the GUI and interacts with the

server through remote procedure calls (or method invocations)

• These are used for mission-critical applications, represent the new growth area

fro PC-based client/server computing.

What is Client/Server?

• The name implies that clients and servers are separated logical entities that

work together over a network to accomplish a task.

• All client/server systems have the following distinguishing characteristics.

1. Service

2. Shared Resources

3. Asymmetrical Protocols

4. Transparency of location

5. Mix – and – Match

6. Message based exchanges

7. Encapsulation of Services

8. Scalability

9. Integrity

1. Service:

9

• Client/Server is primarily a relationship between processes running on

separate machines

• The Server process is a provider of services. The client is a consumer of

services.

• The client and server is separated clearly based on the idea of service.

2. Shared Resources:

• A server can service many clients at the same time and regulate their access to

shared resources.

• Have different mechanisms in allocating files and hardware like printer,

scanner etc.

3. Asymmetrical Protocols:

• There is a many-to-one relationship between clients and server

• Clients always initiate the dialog by requesting a service.

• Servers are passively awaiting requests from the clients.

4. Transparency of Location:

• The server is a process that can reside on the same machine as the client or on

a different machine across a network.

• Client/Server software usually masks the location of the server from the

clients by redirecting the service calls when needed.

• A program can be a client, a server or both.

5. Mix-and-Match:

• The ideal client/server software is independent of hardware or operating

system

• You should able to mix and match the client and server platforms.

6. Message based exchanges:

• Clients and servers are loosely coupled systems that interact through a

message-passing mechanism.

10

• The message is the delivery mechanism for the service requests and replies.

7. Encapsulation of Services:

• A message tells a server what service is requested; it is then up to the server to

determine how to get the job done.

• Servers can be upgraded without affecting the clients as long as the published

message interface is not changed.

8. Scalability:

• Client/Server systems can be scaled horizontally or vertically.

• Horizontal scaling means adding or removing client workstations with only a

slight performance impact.

• Vertical scaling means migrating to a larger and faster server machine or

multi-servers.

9. Integrity:

• The server code and data is centrally maintained, which results in cheaper

maintenance and the guarding of shared data integrity.

• The clients remain personal and independent

Server Types

1. File Server

2. Database Server

3. Transaction Server

4. Groupware Server

5. Object Server

6. Web Server

11

. File Servers

• The client passes requests for file records over a network to the file server.

• This is a very primitive form of data service.

• File Servers are useful for sharing files across a network.

• These are acting as a repository of documents, images, engineering drawings

and other large data objects.

Database Servers

• The client passes SQL requests as messages to the database server.

• The result of each SQL command are returned over the network to the client.

• The code in the server process will processes the SQL request and the data

reside in the same machine.

• Distributed database servers may increase the efficiency of the processing

power.

• These servers provide the foundation for decision-support systems that require

adhoc queries and flexible reports.

12

Transaction Servers

• The client invokes remote procedures that reside on the server with an SQL

database engine.

• These remote procedures on the server execute a group of SQL statements.

• The network exchange consists of a single request/reply message.

• The SQL statements either all succeed or fail as a unit. These grouped SQL

statements are called Transactions.

• The server component usually consists of SQL transactions against a database

• These are called Online Transaction Processing or OLTP.

• OLTP applications also require tight controls over the security and integrity of

the database.

• Two forms of OLTP: based on the TP Monitors provided by the OLTP

Vendors

o TP Lite

o TP Heavy

•

o

4. Groupware Servers

• Groupware addresses the management of semi-structured information such as

text, image, mail, bulletin boards, and the flow of work.

• These client/server systems place people in direct contact with other people.

• Lotus Notes is the Leading Example.

13

• In most cases, applications are created using a scripting language and form-

based interfaces provided by the vendor.

• The communication middleware between the client and the server is vendor-

specific.

Object Servers

• The client/server application is written as a set of communicating objects.

• Client objects communicate with server objects using an Object Request

Broker (ORB).

• The client invokes a method on a remote object.

• The ORB locates an instance of that object server class, invokes the requested

method, and returns the results to the client object.

• Server objects must provide support for concurrency and sharing. The ORB

brings it all together.

• Example: Digital’s Object Broker, IBM’s SOM 3.0, Sun’s NEO, HP’s ORB

Plus, Expersoft’s Power Broker, Microsoft’s DCOM or Network OLE.

Web Servers

• WWW is the first truly intergalactic client/server application.

14

• This model of client/server consists of thin, portable, “universal” clients that

talk to Superfast Servers.

• The clients and servers communicate using an RPC-like protocol called

HTTP.

• This protocol defines a simple set of commands, parameters are passed as

strings.

• The collection of HTML documents are stored in the Web Server.

Messaging and Queuing : The MOM Middleware

• MOM is a key piece of middleware that is absolutely essential for a class of

client/server products.

• If the application can tolerate a certain level of time-independent responses,

MOM provides the easiest path for creating enterprise and inter-enterprise

client/server systems.

• This accumulates outgoing transactions in queue and do a bulk upload when a

connection can be established with an office server.

• MOM allows general purpose messages to be exchanged in a client/server

system using message queues.

15

• Applications communicate over networks by simply putting messages in

queues and getting messages from queues.

• MOM hides all the nasty communications from applications and typically

provides a very simple high-level of API to its services.

• A MOM consortium was formed in mid-1993 with the goal of creating

standards for messaging middleware.

• Members are product providers including

o IBM – MQSeries

o Covia – Communications Integrator

o Peerlogic – PIPES

o Horizon Strategies – Message Express

o System Strategies – ezBridge

• MOM’s messaging and queuing allows clients and servers to communicate

across a network without being linked by a private, dedicated, logical

connection.

• The clients and servers can run at different times.

• Everybody communicates by putting messages on queues and by taking

messages from queues.

• MOM products provide their own NOS services – including hierarchical

naming, security, and a layer that isolates applications from the network.

• They use virtual memory on the local OS to create their queues.

16

• Most messaging products allow the sender to specify the name of the reply

queue.

• The products also include some type of format field that tells the recipient how

to interpret the message data.

• MOM enabled programs do not talk to each other directly, so either program

can be busy, unavailable, or simply not running at the same time.

• The target program can even be started several hours later.

• Many clients are sending requests to one server queue.

• The messages are picked off the queue by multiple instances of the server

program that are concurrently servicing the clients.

• The server instances can take messages off the queue either on a FIFO basis or

accounting to some priority to load-balancing scheme.

• The message queue can be concurrently accessed.

• The servers can also use messaging filters to throw away the messages they

don’t want to process, or they can pass them on to other servers.

• The MOM messaging products provide persistent (logged on disk) and non-

persistent (in memory) message queues.

• Persistent messages are slower, that they can be recovered in case of power

failures after a system restart.

• A message queue can be local to the machine or remote.

• System administrators can usually specify the number of messages a queue

can hold and the maximum message size.

17

Remote Procedure Call

RPCs are not procedure calls at all, they are truly process invocations. The invoked

program runs across the wire in a different resource domain”

• A client process calls a function on a remote server and suspends itself until it

gets back the results.

• Parameters are passed like in any ordinary procedure.

• The RPC, like an ordinary procedure is synchronous.

• The process (or threads) that issue the call waits until it gets the results.

• Under the covers, the RPC run-time software collects values for the

parameters, forms a message, and sends it to the remote server.

• The server receives the request, unpacks the parameters, calls the procedure,

and sends the reply back to the client.

• While RPCs make life easier for the programmer, they pose a challenge for the

NOS designers who supply the development tools and run-time environments.

• The Common issues are:

How are the Server functions located and started?

18

• Server starts the process, when a remote invocation is received with necessary

parameters and returns the response to the client.

• What happens when multiple clients invoke the same function? Now an

environment is needed to start and stop servers, prioritize requests, perform

security checks, and provide some form of load-balancing.

• Each incoming requests invokes a thread in the server side.

• A server loop is created to manage the pool of threads waiting for work rather

than create a thread for each incoming request.

• TP Monitors are really need on the server side, which provides more functions

than a NOS.

How are parameters defined and passed between the client and the server?

• The better NOSs provide an Interface Definition Language (IDL) for

describing the functions and parameters that a server exports to its clients.

• An IDL compiler takes these descriptions and produces source code stubs (and

header files) for both the client and server.

• These stubs can then be linked with the client and server code.

• The client stubs packages the parameters in an RPC packet, converts the data,

calls the RPC run-time library and waits for the server’s reply.

• On the server side, the server stubs unpacks the parameters, calls the remote

procedure, packages the results, and sends the reply to the client.

How are failures handled?

19

• Both the sides of the RPC can fail separately, it is important for the software to

be able to handle all the possible failure combinations.

• If the server does not respond, the client side will normally block, timeout, and

retry the call.

• The server side must guarantee only once semantics to make sure that a

duplicate request is not re-executed.

• If the client unexpectedly dies after issuing a request, the server must be able

to undo the effects of that transition.

How is security handled by the RPC?

• Modern NOSs, like DCE – make it easy to automatically incorporate their

security features into the RPC.

• All you need to specify is the level of security required; then the RPC and

security feature will cooperate to make it happen.

How does the client find its server?

• The association of a client with a server is called binding.

• The binding information may be hardcoded in the client.

• The client can find its server by consulting a configuration file or an

environment parameter.

• A client can also find its server at run time through the network directory

services. The server must, of course, advertise their services in the directory.

• The process of using the directory to find a server at runtime is called

dynamic binding

• RPC can be used to find a server. The RPC client stub will locate a server

from a list of servers that support the interface. This is called automatic

binding.

20

How is data representation across systems handled?

• The problem here is that different CPUs represent data structures differently

(Ex: bigendian Vs little endian)

• To maintain machine independence, the RPC must provide some level of data

format translation across systems.

• Example: Sun RPC requires that clients convert their data to a neutral

canonical format using the External Data Representation (XDR) APIs.

• In contrast, DCE’s Network Data Representation (NDR) service is

multicanonical, meaning that it supports multiple data format representations.

• The client chooses one of these formats, tags the data with chosen format, and

then leaves it up to the server to transform the data into a format it

understands.

• In other words, the server makes it right. It lets the client to do translation,

which makes the life easy for the server.

• With Sun, all clients look the same to the server: The Client makes it right.

Peer – to – Peer Communications

21

• Most early client/server applications were implemented using low-level,

conversational, peer-to-peer protocols – such as sockets, TLI, CPIC/APPC,

NetBIOS and Named Pipes.

• These low-level protocols are hard to code and maintain.

• Instead now, the programmers are using RPCs, MOMs, and ORBs, which

provide high level abstraction.

• The term, “peer-to-peer” indicates that the two sides of a communication link

use the same protocol interface to conduct a networked conversation.

• The protocol is symmetrical, and it is sometimes called “program-to-

program”.

• The peer-to-peer interface not fully mask the underlying network from the

programmer.

• Programmer have to handle the transmission timeouts, race conditions, and

other network errors.

• The peer-to-peer protocols started as stack-specific APIs.

a) Sockets

• Sockets were introduced in 1981 as the UNIX BSD 4.2 generic interface that

would provide Unix-to-Unix communications over network.

• In 1985, SUN OS introduced NFS and RPC over sockets.

• Sockets are supported on virtually every OS.

• The windows socket API, known as WinSock, is a multivendor specification

that standardizes the use of TCP/IP under windows.

• In BSD Unix System, sockets are part of the Kernel and provide both a

standalone and networked IPC service.

Socket = Net_ID . Host_ID . Port_ID = IP Address + Port Address.

• The three most popular socket types are

o Stream

o Datagram

o Raw

• Stream and datagram sockets interface to the TCP and UDP protocols, and

raw sockets interface to the IP protocol.

22

• A port is an entry point to an application that resides on the host.

• It is represented by a 16-bit integer.

• Ports are commonly used to define the entry points for services provided by

the server applications.

b) TLI

• In 1986, AT&T introduced the Transport Layer Interface that provides

functionality similar to sockets but in a more network-independent fashion.

• Sockets and TLI are very similar from a programmer’s perspective.

• TLI is just cleaner version of the sockets.

• It should run on IPX/SPX (or) TCP/IP with very few modifications.

• The TLI API consists of 25 API calls.

• Later standardized as XTI, X/Open Transport Interface.

c) NetBIOS:

• It is the premier protocol for LAN-based, program-to-program

communications.

• Introduced by IBM and Sytek in 1984 for the IBM PC network.

• It is used as an interface to a variety of stacks – including NetBEUI, TCP/IP,

XNS, Vines, OSI and IPX/SPX.

• The NetBIOS services are provided through a set of commands, specified in a

structure called the Network Control Block (NCB)

• It does not support the routing of messages to other networks.

d) Named Pipes:

• Provide highly reliable, two-way communications between clients and a

server.

• They provide a file-like programming API that abstracts a session-based two-

way exchange of data.

• Using named pipes, processes can exchange data as if they were writing to, or

reading from, a sequential file.

23

• These are suitable for implementing server programs that require many-to-one

pipelines.

• Important benefit of named pipes are part of the base interprocess

communications service.

• Named pipes interface is identical, whether the processes are running on an

individual machine or distributed across the network.

• Named pipes run on NetBIOS, IPX/SPX, and TCP/IP stacks.

• Named pipes are built-in networking features in Windows NT, Windows for

Workgroups, Windows 95 and Warp Server.

• Unix support for Named Pipes is provided by LAN Manager/X.

e) CPI-C/APPC:

• Common Programming Interface for Communications (CPI-C) build on top of

APPC and marks its complexities and irregularities.

• Writing to the CPI-C API allows you to port your programs to all SNA

platforms.

• The CPI-C API consists of about 40 calls; APPC consists of over 60 calls.

• Most of these calls deals with configuration and services.

• Advanced program-to-program communication is a protocol which computer

programs can use to communicate over a network.

• APPC was developed as a component of IBM’s Systems Network

Architecture (SNA).

• APPC is linked with the term LU6.2.

• LU6.2. (Logic Unit Version 6.2) is a device independent SNA Protocol.

• It was developed to allow computers in IBM environments to setup their own

communications sessions, rather than rely on a hos computer to do so.

• Contrary to TCP/IP, in which both communication partners always possess a

clear role, the communication partners in APPC are equal, i.e., everyone can

be both servers and clients equally.

• With the wide success of TCP/IP, APPC has declined.

24

Inside the Building Blocks

The Client Building Block

• Runs the client side of the application

• It runs on the OS that provides a GUI or an OOUI and that can access

distributed services, wherever they may be.

• The client also runs a component of the Distributed System Management

(DSM) element.

The Server Building Block

• Runs the server side of the application

• The server application typically runs on top of some shrink-wrapped server

software package.

25

• The five contending server platforms for creating the next generation of

client/server applications are SQL database severs, TP Monitors, groupware

servers, Object servers and the Web server.

• The server side depends on the OS to interface with the middleware building

block.

• The server also runs DSM component

• It may be a simple agent or a shared object database etc.

The Middleware Building Block

• Runs on both the client and server sides of an application

• This broken into three category

o Transport Stacks

o NOS

o Service-specific middleware

• Middleware is the nervous system of the client/server infrastructure

• This also has the DSM component

DSM

• Runs on every node in the client/server network.

• A managing workstation collects information from all its agents on the

network and displays it graphically.

• The managing workstation can also instruct its agents to perform actions on its

behalf.

Server-to-server Middleware

• Server-to-server interactions are usually client/server in nature – servers are

clients to other servers.

• However, some server-to-server interactions require specialized server

middleware. For example, Two-Phase commit protocol may be used to

coordinate a transaction that executes on multiple servers.

• Servers on mail backbone will use special server-to-server middleware for

doing store-and-forward type messaging.

26

• But most modern software follows the client/server paradigm.

Client/Server : A one size fits all model

The building blocks of client/server applications are:

1. Client

2. Middleware

3. Server

These building blocks can be rearranged to use them in the following situations:

1. Client/Server for tiny shops and nomadic tribes – This is a building-block

implementation that runs the client, the middleware software, and most of the

business services on the same machine. It is the suggested implementation for the

one-person shops, home offices, and mobile users with well-endowed laptops.

2. Client/Server for small shops and departments - This is the classic Ethernet

client/single-server, building block implementation. It is used in small shops,

departments, and branch offices. This is the predominant form of client/server today.

27

3. Client/Server for intergalactic enterprises – This is the multiserver building-

block implementation of client/server. The servers present a single system image to

the client. They can be spread out throughout the enterprise, but they can be made to

look like they are part of the local desktop. This implementation meets the initial

needs of intergalactic client/server computing.

4. Client/Server for a post-scarcity world – This model transforms every machine

in the world into both a client and a server. Personal agents on every machine will

handle all the negotiations with their peer agents anywhere in the universe. This

dream is almost within reach.

1) Client/Server for Tiny Shops and Nomadic Tribes

• It is easy to run the client and server portion of an application on the same

machine.

• Vendors can easily package single-user versions of a client/server application.

• The business critical client/server application runs on one machine and does

some occasional communications with outside servers to exchange data,

refresh a database and send or receive mail and faxes. Ex: Internet.

2) Client/Server for small shops and departments

• The client/server architecture is particularly well-suited for the LAN-based

single server establishments.

• It consists of multiple clients talking to a local server.

28

• This is the model used in small businesses.

• The single-server nature of the model tends to keep the middleware simple.

• The client only needs to look into a configuration file to find its server’s name.

• Security is implemented at the machine level and kept quite simple.

• The network is usually relatively easy to administer; it’s a part-time job for a

member of the group.

• There are no complex interactions between servers, so it is easy to identify

failures- they’re either on the client or on the local server.

3) Client/Server for Intergalactic Enterprises:

• The client/server enterprise model addresses the needs of establishments with

a mix of heterogeneous servers.

• These models are upwardly scalable.

• When more processing power is needed for various intergalactic functions,

more servers can be added, or the existing server machine can be traded up for

the latest generation of superserver machine.

• The servers can be partitioned based on the function they provide, the resource

they control, or the database they own.

• The servers can be replicated to provide a fault-tolerant service or to boost an

application’s performance.

• Multiserver capability, when properly used, can provide an awesome amount

of compute power and flexibility, in many cases rivaling that of mainframes.

• To exploit the full power of multiservers, we need low-cost, high-speed

bandwidth and an awesome amount of middleware features -including

o network directory services

o network security

29

o remote procedure calls and

o network time services.

• Middleware creates a common view of all the services on the network called a

single system image.

• Good software architecture for intergalactic enterprise client/server

implementations is all about creating system “ensembles” out of modular

building blocks.

• Intergalactic client/server is the driving force behind middleware standards as

distributed objects and the Internet.

4) Client/Server for a Post-Scarcity World

• Every machine is both a client and a full-function server.

• Because every machine is a full-function server, it will run, at a minimum, a

file server, database server, workflow agent, TP Monitor, and Web server – all

connected via an ORB.

• This is in addition to all the client software and middleware.

• In next few years, a hundred million machines or more may be running almost

all the forms of client/server software

• In this model instead of mobile agents, personal agents will be used.

30

Permalink Leave a Comment

Intergalactic Client/Server

January 13, 2008 at 5:38 pm (Unit 1) (Client/Server)

Intergalactic client/server is a new threshold of client/server applications and this is

because of

1. the exponential increase of low-cost bandwidth on Wide Area Networks – for

example, the Internet and CompuServe

2. a new generation of network-enabled, multi-threaded desktop operating

systems – for example, OS/2 Warp Connect and Windows 95.

This new threshold marks the beginning of a transition from Ethernet client/server to

intergalactic client/server that will result in the irrelevance of proximity.

31

The center of gravity is shifting from single-server, 2-tier, LAN-based departmental

client/server to a post-scarcity form of client/server where every machine on the

global “information highway” can be both a client and a server.

Application

characteristics

Intergalactic Era

client/server

Ethernet Era

client/server

Number of clients

per application

Millions Less than 100

Number of servers

per application

100,000+ <5

Geography Global Campus-based

Server-to-server

Interactions

Yes No

Middleware ORBs on top of

Internet

SQL and stored

procedure

Client/server

architecture

3-tier (or n-tier) 2-tier

Transactional

updates

Pervasive Very infrequent

Multimedia content High Low

Mobile Agents Yes No

Client front-ends OOUIs, compound

documents, and

shippable places

GUI

Time-frame 1997 onwards 1985 till present

The major key technologies in intergalactic client/server model are:

a) Rich transaction Processing – supports the nested transactions that span across

multiple servers, long-lived transactions that executes over long periods of time as

they travel from server to server, and queued transactions that can be used in secure

business-to-business dealings. Most nodes on the network participates in the secured

transaction; super-server nodes handle the massive transaction loads.

32

b) Roaming agents – the environment is populated with all types of agents. This

agent technology includes cross-platform scripting engines, workflow, and Java-like

mobile code environments that allow agents to live on any machine on the network.

c) Rich data management – This includes active multimedia compound documents

that can move, store, view and edit in-place anywhere on the network. Most nodes on

the network provides compound document technology for example, OLE or

OpenDoc-for mobile document management.

d) Intelligent self-managing entities – With the introduction of new multi-threaded,

high-volume, network-ready desktop operating systems, increased the workload on

the server operating system. This type of distributed software knows how to manage

and configure itself and protect itself against threats.

e) Intelligent Middleware -The distributed environment must provide the semblance

of a single system-image across potentially millions of hybrid client/server machines.

The middleware creates this illusion by making all servers on the global network

appear to behave like a single computer system. Users and programs should be able to

dynamically join and leave the network, and then discover each other.

2-Tier Vs 3-Tier

January 13, 2008 at 5:15 am (Unit 1) (Middleware)

• Instead of Fat clients and fat servers these terms can be used.

• It is all about how you split the client/server applications into functional units.

• These functional units can be assigned to either the client or to one or more

servers.

• The most typical functional units are:

o User Interface

o Business Logic and

o the Shared Data

• In 2-tier, the application logic is either buried inside the User Interface on the

client or within the database on the server (or both)

33

• 2-tier system examples: File Servers and Database Servers with stored

procedure.

• In 3-tier, the application logic (or) process lives in the middle-tier, it is

separated from the data and the user interface.

• 3-tier systems are more scalable, robust and flexible. In addition, they can

integrate data from multiple sources.

• Examples: TP Monitors, Distributed Objects and the Web.

Different Meanings for 3-tier:

First:

tier 1 – Application in PC

tier 2 – Departmental Servers

tier 3 – Enterprise Servers

Then:

tier 1 – Partitions across client

tier 2 – local database

tier 3 – enterprise database

Now:

tier 1 – Client

tier 2 – Application Server

tier 3 – Database Server