1 / 54

Client/Server Distributed Systems

Client/Server Distributed Systems. 240-322, Semester 1, 2005-2006. Objectives introduce the client/server model give an overview of DCE and Java RMI. 1. The Client Server Model (Chapters 1 and 2, Berson). Overview. 1. Client/Server Basics 2. Client/Server in More Detail

emilie
Télécharger la présentation

Client/Server Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Client/Server Distributed Systems 240-322, Semester 1, 2005-2006 • Objectives • introduce the client/server model • give an overview of DCE and Java RMI 1. The Client Server Model(Chapters 1 and 2, Berson)

  2. Overview 1. Client/Server Basics 2. Client/Server in More Detail 3. Client/Server Summary 4. Standards Organisations 5. DCE

  3. 1. Client/Server Basics • A first examination of client/server functionality. • A brief definition: • A server is a program (or collection of cooperating programs) that provides services and/or manages resources on the behalf of other programs (its clients).

  4. 1.1. Client/Server Environment clients LAN or WAN network Server Data Berson,Fig 1.4, p.8

  5. 1.2. Example • The ATM network: • the clients are the ATM machines • user interfaces;some simple application processing • the server is at the bank • most application processing;very large database of customer accounts

  6. 1.3. Architectural Requirements • Reliable, robust communication between the clients and server. • Client/server cooperation • started by the client • Application processing is usually distributed between a client and the server. • Server controls services/data that the client accesses. • Server handles conflicting requests.

  7. 1.4. Recent Client/Servers Architectures • More complex networking • LAN, WAN --> Web, Internet • client mobility • More complex data structures • relational --> multimedia, OO, deductive • size • distributed databases • parallelism continued

  8. Separation of ‘business logic’ (i.e. program code for manipulating data) from the data • 3-tier (multi-tier) architectures • distributed business logic

  9. 2. Client/Server in More Detail 2.1. Converting a Database App. 2.2. Component Placement? 2.3. The 2-tier Model 2.4. The 3-tier Model 2.5. Locating the Business Logic 2.6. Locating the Data 2.7. Multi-tier Model

  10. 2.1. Converting a Database App. Presentation Logic Business Logic Stand-aloneApplication Database Database Logic DBMS

  11. Different client/server models are obtained by locating different components and combinations of the application on the client and server(s). • In general: • presentation logic stays on the client • DBMS and database move to the server • parts of the business and database logic that can be used by several clients are placed on the server

  12. 2.2. Component Placement? • How much data is required by the local application? • How many application users require the same data? • How many interactions occur between the application parts? • Technical issues • platforms, networking

  13. 2.3. The 2-tier Model Fig. 2.3, p.41 Client Server Presentation Logic Database Logic Business Logic DBMS Database Logic Database

  14. Points • The database is on the server • could some of it be moved to the client? • Distributed database logic • most of it is on the client • The client does the presentation. • ‘Fat’ versus ‘thin’ clients. • Much simpler if all the database servers are the same (homogenous).

  15. Drawbacks • It is difficult to build heterogeneous database environments. • Transaction processing is limited by the DBMS. • Asynchronous processing is difficult • i.e. the client doesn’t wait for the server’s answer • Scaleability?

  16. 2.4. The 3-tier Model Fig. 1.6, p.12 UNIX ServerData ServerData Clients Win/NT Application servers Data Servers

  17. The 3-tier Model Again Fig.2.6, p.48 Price/PerformanceFunctionalityLocal Autonomy Greater IntegritySecurityCentral Control Mainframehost(s) Tier 1 Server Tier 2 LAN Tier 3

  18. Points • The “Mainframe host” is usually a very large database (or databases) • sometimes called a back-end server • The “server” usually holds shared applications (application/business logic) • sometimes called the middle-tier server

  19. Benefits of 3-tier over 2-tier • The application logic in the middle-tier is more independent of the client and the back-end server • it should be more robust • The application logic in the middle-tier can work more easily with data from multiple sources. • Encourages multiple back-end servers • encourages data distribution

  20. Problems • Much more complex: • network management, data integrity, maintenance, development • Still (partially) dependent on platforms • e.g. the client may still be restricted to a certain application server, but not (maybe) to any data server

  21. Examples • A ‘real’ ATM network • the ATM machines are the clients (as before) • the middle-tier servers provide certain processing • checking balances, money transfer requests • directing queries to the relevant back-end server • back-end server(s) • specialized by account type • very robust concurrency control, transaction processing continued

  22. Many Web applications are 3-tier: • the Web browser is the client software • the embedded components in Web pages (e.g. Java applets) come from the middle-tier • the back-end server contains the database/groupware

  23. 2.5. Locating the Business Logic Fig.2.12, p.60 Server Client Business Logic Presentation Logic Database Logic Business Logic DBMS Database

  24. Three ways of distributing the ‘business logic’ (i.e. the program code): • locate it entirely on the client (‘fat’ client) • locate it entirely on the server (‘fat’ server) • split it between the client and server

  25. Fat Server Advantages • Easier to update the application logic since clients not involved. • Data is better hidden from clients. • Easier to manage and debug since data and code is centrally located. • Reduces bandwidth problems since data processing stays on the server. continued

  26. Better for mission-critical applications when fault-tolerance and stability are important. • Encourages client simplicity and compatibility since the server must be able to work with many types of client. • e.g. serve Web pages without ActiveX

  27. Fat Client Advantages • The server is unaffected when updates are done to the client’s application logic • the server will be more stable • Easier to program • less networking • more direct access to client platform features, such as GUI

  28. 2.6. Locating the Data Fig.2.14,p.69 Multiple Servers Client Database Logic Presentation Logic DBMS Business Logic Database Logic Database Database DBMS Database

  29. Issues • Dividing up the data. • Transparency of the distribution. • Data integrity / synchronisation / consistency. • Data administration / management.

  30. Transaction Processing • A transaction is a sequence of actions which takes a system (usually a database) from one consistent state to another. • e.g. change a customer’s record • A transaction should possess the “ACID” properties: • Atomicity, Consistency, Isolation, Durability continued

  31. Recovery and concurrency mechanisms are necessary, typically implemented in a Transaction Processing Management (TPM) system. • TPMs become very complex when data is distributed. • ACID must be distributed as well

  32. 2.7. Multi-tier Model Fig.2.9,p.53 Middleware Physical Network

  33. Common New Features • Asynchronous connectivity • e.g. asynchronous RPCs • Data distribution using replication • Name/directory services for resource location independence • More complex data types continued

  34. More complex analysis • e.g. data mining, network characteristics • Authentication services • you must 'prove' who you are to the system • Distributed file system(s) • Time services

  35. Examples • Domain-specific: • ODBC, SQL, Oracle Glue • Groupware middleware: • Microsoft Exchange, Lotus Notes • Object middleware: • CORBA, DCOM (more on these in part 2)

  36. Mult-tier Web Applications • The Web browser is the client software on the first tier. • Web page components come from the second tier. • The third tier is a database front-end for a series of fourth tier heterogeneous databases • the third tier database may have been constructed with data mining techniques

  37. 3. Client/Server Summary 3.1. Recurring Issues 3.2. Advantages of Client/Server 3.3. Disadvantages of Client/Server

  38. 3.1. Recurring Issues • LAN, WAN, Internet scaling • Data distribution/replication • Distributed processing • System management/maintenance • Choice of middleware • Standards / open systems

  39. What’s an Open System? • An open system: • complies with industry standards for programming, communication, networking, presentation, etc. • is designed with portability/interoperability in mind • is scaleable

  40. 3.2. Advantages of Client/Server • Mainframe functionality can be made widely available • cost benefits • Processing and data are localised on the server • reduces network traffic, response time,bandwidth requirements • Business logic can be distributed (in 3-tier model) • reuse, portability continued

  41. Encourages open systems • Present-day systems are too large and involve too many users to be located on one machine.

  42. 3.3. Disadvantages of Client/Server • The server becomes a bottleneck • Distributed applications are much more complex than non-distributed ones • i.e. in development, run time, maintenance, upgrades • Requires a shift in business practises • local, simple data --> distributed, open, complex data

  43. 4. Standards Organizations • POSIX: Portable Operating Systems Interface • family of standards developed by IEEE • POSIX working groups have standardised C, UNIX shell, networking API for sockets, real-time, threads, etc. continued

  44. The Open Group • consolidation of X/Open company and Open Software Foundation (OSF) • consortium of vendors and industrial/government users • developed API for UNIX, including XTI (X/Open Transport Interface) network protocol continued

  45. Internet Engineering Task Force (IETF) • community of network designers, operators, vendors, and researchers • concerned with the evolution of the Internet architecture • e.g. sockets API for IP version 6 (IPv6) • 128-bit addresses, simpler header, multicasting, authentication and security continued

  46. ISO (International Organization for Standards) • main standards organization • e.g. communications protocol: the Open Systems Interconnection (OSI) reference model • OMG (Object Management Group) • object-oriented standards • e.g. CORBA

  47. 5. DCE • The Distributed Computing Environment • developed by the OSF (late 1980’s) • open • very extensive features (and complex) • Basic programming feature is the Remote Procedure Call (RPC) • other features: name/directory services, authentication, security, data pipes

  48. DCE RPC Server Client RemoteProcedure Applicationcode Applicationcode RPC Stub Code Stub Code RPC runtime library RPC runtime library Input Output Network

  49. Using RPC • The data structures to be passed as arguments of the RPC call are used by a compiler to generate the client and server stub code. • The data structures are written in a special high-level language (simplified C types), which are easily converted to network packets.

  50. DCE Client/Server Model (v.2) Fig 1.10, p.27 Client Server DistributedDCE Application DistributedDCE Application Executive Services Data Sharing OS and NetworkInterface OS and NetworkInterface Network

More Related