Client/Server Software Architectures Yonglei Tao.

Client/Server Software Architectures

Yonglei Tao

Overview

Multi-Client/Multi-Service

Design Issues1. Support communication between clients and

servers 2. Hide details of the communication

mechanism• The proxy pattern

3. Manage various service requests• The façade pattern

4. Support services that need access to databases

• Wrapper classes (the Adapter pattern)

1. Support Communication Synchronous message communication with

reply

Asynchronous message communication with callback

2. Hide Communication Mechanism Problem

Direct access to a real subject is not desirable or possible

The proxy pattern Provides a local representative for an object in a

different address space Hides details of accessing the real object (used

in Java RMI)

The Proxy Pattern

Client

+makeRequest()-s : ISubject

«Interface»ISubject

+request()

Proxy

+request()-r : ISubject

RealSubject

+request()

1

1

1

1

void makeRequest () { s.Request(); ...}

void request () { r.request(); ...}

The Proxy Pattern Adding a level of indirection with a surrogate

for the real subject to control access to it A proxy is an object with the same interface

as the real object it represents A client object interacts with the proxy even

it intends to talk to the real object The proxy forwards a request from a client

object to the real object to fulfill the request

Proxy - Applicability Protection proxy

Provide different objects with different level of access to the original object

Protect local clients from outside world as a firewall

Virtual proxy Create/access expensive objects on demand

Middleware as Proxy Provides standard services to software applications such as RPC, RMI, COM, CORBA, etc.

3. Manage Service Requests Problem

How to provide a unified interface to a set of interfaces within a subsystem

Using the Façade pattern Define a single entry point to the subsystem (a

facade object that wraps the subsystem) Let it be responsible for coordinating subsystem

components Clients interface the facade class to deal with

the subsystem

The Façade Pattern

Client 1

C lient 2

C leint 3

subsystem s subsystem s

Client 1

C lient 2

C lient 3

Facade

Façade – an Example

Façade - Consequences A high-level interface that makes

subsystem easy to use and more independent Hide implementation of the subsystem from

clients It reduces coupling between a subsystem

and its clients A Façade class does not add new

functionality to the subsystem

Manage Service Requests

(1) Sequential Service Using a single object to handle various

requests from clients A coordinator object or façade

Processing client requests one by one Client uses synchronous message communication

with reply to raise a request

Manage Service Requests

(2) Concurrent Service Sharing service functionality among several

concurrent objects Processing multiple client requests

concurrently Client uses asynchronous message

communication with callback to raise a request On completion, the responsible object remotely

invokes the callback Used where client demand for services is high

Improve throughput

4. Needs for Database Services Query

View data Perform computations on the data Send data from one place to another

Manipulation Add, modify, and delete data

Logging Activities on the server Interactions with the database

From a Static Model to a Relational Database Mapping an entity class to a relational table

Relate attributes to columns, objects to rows Identify primary key

Mapping associations to foreign keys One-to-one, zero-to-one, and one-to-many

Mapping association classes Mapping a whole/part relationship

Composite and aggregate Mapping a generalization/specialization

relationship Superclass and Subclasses together Subclasses Only Superclass Only

Database Wrapper Classes Entity classes

Likely to be designed on the client side Occasionally used to temporarily store data on the

server side Database wrapper classes

Manage the data that is stored in a database Primarily designed on the server side Provides object-oriented interface to the database Hides how the data is accessed and maintained

The Adapter Pattern Problem

How to resolve incompatible interfaces or provide a stable interface to similar components with different interfaces

Solution Convert the original interface of a component

into another interface, through an intermediate adapter object

Also known as Wrapper

Motivation Sometimes a toolkit or third party system

cannot be used because its interface is incompatible with the interface required by an application

We cannot change the system Even if we can we probably should not do

for each domain-specific application

Structure

Example of Using Adapter In the original CGI web server programs

CGIVariables ref = …;

ref.get(x); ref.get(y);

A new version of the web server supports servlets, which provide similar functionality but are more efficient

HttpServletRequest ref = …;

ref.getX();ref.getY();

Should we rewrite all of the existing CGI programs in order to use servlets? Want to minimize rewriting

Example (Cont.) Design a CGIAdapter class

Has the same interface as the original CGIVariables class Serves a wrapper around the HttpServletRequest class Allow to use servlets with a CGI like interface

Modify code

CGIVariables ref = …;

ref.get(x);

ref.get(y);

CGIAdapter

Consequences Provide a consistent interface within an

application Allow to change external components

without affecting the clients Introduce a level of indirection – extra

overhead