Presentation is loading. Please wait.

Presentation is loading. Please wait.

Client/Server Software Architectures Yonglei Tao.

Similar presentations


Presentation on theme: "Client/Server Software Architectures Yonglei Tao."— Presentation transcript:

1 Client/Server Software Architectures Yonglei Tao

2 Overview

3 Multi-Client/Multi-Service

4 Design Issues 1. 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)

5 1. Support Communication  Synchronous message communication with reply  Asynchronous message communication with callback

6 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)

7 The Proxy Pattern

8  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

9 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

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

11 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

12 The Façade Pattern

13 Façade – an Example

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 Structure

23 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

24 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

25 Consequences  Provide a consistent interface within an application  Allow to change external components without affecting the clients  Introduce a level of indirection – extra overhead


Download ppt "Client/Server Software Architectures Yonglei Tao."

Similar presentations


Ads by Google