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

2. 240-322 Cli/Serv.: Models/12 Overview 1.Client/Server Basics 2.Client/Server in More Detail 3.Client/Server Summary 4.Standards Organisations 5.DCE

3. 240-322 Cli/Serv.: Models/13 1. Client/Server Basics v A first examination of client/server functionality. v 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. 240-322 Cli/Serv.: Models/14 1.1. Client/Server Environment LAN or WAN Server Data Berson, Fig 1.4, p.8 clients network

5. 240-322 Cli/Serv.: Models/15 1.2. Example v The ATM network: –the clients are the ATM machines u user interfaces; some simple application processing –the server is at the bank u most application processing; very large database of customer accounts

6. 240-322 Cli/Serv.: Models/16 1.3. Architectural Requirements v Reliable, robust communication between the clients and server. v Client/server cooperation –started by the client v Application processing is usually distributed between a client and the server. v Server controls services/data that the client accesses. v Server handles conflicting requests.

7. 240-322 Cli/Serv.: Models/17 1.4. Recent Client/Servers Architectures v More complex networking –LAN, WAN  Web, Internet –client mobility v More complex data structures –relational  multimedia, OO, deductive –size –distributed databases –parallelism continued

8. 240-322 Cli/Serv.: Models/18 v Separation of ‘business logic’ (i.e. program code for manipulating data) from the data –3-tier (multi-tier) architectures –distributed business logic

9. 240-322 Cli/Serv.: Models/19 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. 240-322 Cli/Serv.: Models/110 2.1. Converting a Database App. Presentation Logic Business Logic Database Logic DBMS Data base Stand-alone Application

11. 240-322 Cli/Serv.: Models/111 v Different client/server models are obtained by locating different components and combinations of the application on the client and server(s). v 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. 240-322 Cli/Serv.: Models/112 2.2. Component Placement? v How much data is required by the local application? v How many application users require the same data? v How many interactions occur between the application parts? v Technical issues –platforms, networking

13. 240-322 Cli/Serv.: Models/113 2.3. The 2-tier Model Fig. 2.3, p.41 Presentation Logic Business Logic Database Logic DBMS Data base Database Logic Client Server

14. 240-322 Cli/Serv.: Models/114 Points v The database is on the server –could some of it be moved to the client? v Distributed database logic –most of it is on the client v The client does the presentation. v ‘Fat’ versus ‘thin’ clients. v Much simpler if all the database servers are the same (homogenous).

15. 240-322 Cli/Serv.: Models/115 Drawbacks v It is difficult to build heterogeneous database environments. v Transaction processing is limited by the DBMS. v Asynchronous processing is difficult –i.e. the client doesn’t wait for the server’s answer v Scaleability?

16. 240-322 Cli/Serv.: Models/116 2.4. The 3-tier Model Fig. 1.6, p.12 Server Data Application serversData Servers Server Data UNIX Win/NT Clients

17. 240-322 Cli/Serv.: Models/117 The 3-tier Model Again Fig.2.6, p.48 Server Mainframe host(s) Tier 1 Tier 2 Tier 3 LAN Price/Performance Functionality Local Autonomy Greater Integrity Security Central Control

18. 240-322 Cli/Serv.: Models/118 Points v The “Mainframe host” is usually a very large database (or databases) –sometimes called a back-end server v The “server” usually holds shared applications (application/business logic) –sometimes called the middle-tier server

19. 240-322 Cli/Serv.: Models/119 Benefits of 3-tier over 2-tier v The application logic in the middle-tier is more independent of the client and the back-end server –it should be more robust v The application logic in the middle-tier can work more easily with data from multiple sources. v Encourages multiple back-end servers –encourages data distribution

20. 240-322 Cli/Serv.: Models/120 Problems v Much more complex: –network management, data integrity, maintenance, development v 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. 240-322 Cli/Serv.: Models/121 Examples v A ‘real’ ATM network –the ATM machines are the clients (as before) –the middle-tier servers provide certain processing u checking balances, money transfer requests u directing queries to the relevant back-end server –back-end server(s) u specialized by account type u very robust concurrency control, transaction processing continued

22. 240-322 Cli/Serv.: Models/122 v 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. 240-322 Cli/Serv.: Models/123 2.5. Locating the Business Logic Fig.2.12, p.60 Presentation Logic Business Logic DBMS Data base Database Logic Client Server Business Logic

24. 240-322 Cli/Serv.: Models/124 v 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. 240-322 Cli/Serv.: Models/125 Fat Server Advantages v Easier to update the application logic since clients not involved. v Data is better hidden from clients. v Easier to manage and debug since data and code is centrally located. v Reduces bandwidth problems since data processing stays on the server. continued

26. 240-322 Cli/Serv.: Models/126 v Better for mission-critical applications when fault-tolerance and stability are important. v Encourages client simplicity and compatibility since the server must be able to work with many types of client. –e.g. serve Web pages ActiveX –e.g. serve Web pages without ActiveX

27. 240-322 Cli/Serv.: Models/127 Fat Client Advantages v The server is unaffected when updates are done to the client’s application logic –the server will be more stable v Easier to program –less networking –more direct access to client platform features, such as GUI

28. 240-322 Cli/Serv.: Models/128 Data base 2.6. Locating the Data Fig.2.14,p.69 Presentation Logic Business Logic DBMS Data base Database Logic Client Multiple Servers DBMS Database Logic Data base

29. 240-322 Cli/Serv.: Models/129 Issues v Dividing up the data. v Transparency of the distribution. v Data integrity / synchronisation / consistency. v Data administration / management.

30. 240-322 Cli/Serv.: Models/130 Transaction Processing v 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 v A transaction should possess the “ACID” properties: –Atomicity, Consistency, Isolation, Durability continued

31. 240-322 Cli/Serv.: Models/131 v Recovery and concurrency mechanisms are necessary, typically implemented in a Transaction Processing Management (TPM) system. v TPMs become very complex when data is distributed. –ACID must be distributed as well

32. 240-322 Cli/Serv.: Models/132 2.7. Multi-tier Model Fig.2.9,p.53 Middleware Physical Network

33. 240-322 Cli/Serv.: Models/133 Common New Features v Asynchronous connectivity –e.g. asynchronous RPCs v Data distribution using replication v Name/directory services for resource location independence v More complex data types continued

34. 240-322 Cli/Serv.: Models/134 v More complex analysis –e.g. data mining, network characteristics v Authentication services –you must 'prove' who you are to the system v Distributed file system(s) v Time services

35. 240-322 Cli/Serv.: Models/135 Examples v Domain-specific: –ODBC, SQL, Oracle Glue v Groupware middleware: –Microsoft Exchange, Lotus Notes v Object middleware: –CORBA, DCOM (more on these in part 2)

36. 240-322 Cli/Serv.: Models/136 Mult-tier Web Applications v The Web browser is the client software on the first tier. v Web page components come from the second tier. v 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. 240-322 Cli/Serv.: Models/137 3. Client/Server Summary 3.1. Recurring Issues 3.2. Advantages of Client/Server 3.3. Disadvantages of Client/Server

38. 240-322 Cli/Serv.: Models/138 3.1. Recurring Issues v LAN, WAN, Internet scaling v Data distribution/replication v Distributed processing v System management/maintenance v Choice of middleware v Standards / open systems

39. 240-322 Cli/Serv.: Models/139 What’s an Open System? v An open system: –complies with industry standards for programming, communication, networking, presentation, etc. –is designed with portability/interoperability in mind –is scaleable

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

41. 240-322 Cli/Serv.: Models/141 v Encourages open systems v Present-day systems are too large and involve too many users to be located on one machine.

42. 240-322 Cli/Serv.: Models/142 3.3. Disadvantages of Client/Server v The server becomes a bottleneck v Distributed applications are much more complex than non-distributed ones –i.e. in development, run time, maintenance, upgrades v Requires a shift in business practises –local, simple data  distributed, open, complex data

43. 240-322 Cli/Serv.: Models/143 4. Standards Organizations v 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. 240-322 Cli/Serv.: Models/144 v 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. 240-322 Cli/Serv.: Models/145 v 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) u 128-bit addresses, simpler header, multicasting, authentication and security continued

46. 240-322 Cli/Serv.: Models/146 v ISO (International Organization for Standards) –main standards organization –e.g. communications protocol: the Open Systems Interconnection (OSI) reference model v OMG (Object Management Group) –object-oriented standards –e.g. CORBA

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

48. 240-322 Cli/Serv.: Models/148 DCE RPC Client Application code RPC Stub Code RPC runtime library Server Network Input Output Application code Remote Procedure Stub Code RPC runtime library

49. 240-322 Cli/Serv.: Models/149 Using RPC v 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. v The data structures are written in a special high- level language (simplified C types), which are easily converted to network packets.

50. 240-322 Cli/Serv.: Models/150 DCE Client/Server Model (v.2) Distributed DCE Application Executive OS and Network Interface Distributed DCE Application ServicesData Sharing OS and Network Interface ClientServer Network Fig 1.10, p.27

51. 240-322 Cli/Serv.: Models/151 DCE Architecture Applications PC IntegrationDist. Services MgmtSecurity DFS: Dist. File Services Naming Services Time Services Future Core Services RPCs Presentation Services Threads Services OS Network Services Fig. 1.9, p.23

52. 240-322 Cli/Serv.: Models/152 5.1. Distributed File System (DFS) v Problem: how to allow a user on one system to modify data stored on a file in another system? –User = client –Distant data is managed by a file server

53. 240-322 Cli/Serv.: Models/153 Issues v Access security and protection –user authentication (Kerberos) + user control v Data reliability v Data availability v Performance v Management

54. 240-322 Cli/Serv.: Models/154 5.3. More Details v There are several books from O’Reilly on different aspects of DCE: –"Understanding DCE" –"Guide to Writing DCE Applications" –"Distributed Applications Across DCE and Windows NT" –"Introduction to OSF DCE"(in PSU library) v We will look at simple RPC on UNIX later in the course.