Course Grading

1
Course Grading

• Course Grading Policy
• gt85 A
• gt75 B
• gt65 C
• gt45 D
• Examination Assignment Project
• Midterm 20 - Assignments 20
• Final 30 - Project 30

2
Course Materials

• TEXT BOOK
• Client/Server Architecture
• Alex Berson Second Edition McGraw-Hill
• LAN Architecture ( Thai Edition or English )
• UNIX - C Programming
• Transparency
• Client / Server and Distributed ProcessingCREDIT
  TOArranged from AIT02.07 Client/Server
  Distributed Systemsby Dr. Andrew Davidson

3
Course Outline

• PART A Introduction to Computer Network
• Fundamental of Data Communication
• LAN Architecture / Equipments
• Computer Network Standard and Terms
• PART B Client / Server Architecture and
  Practices
• Client / Server Models
• Client / Server with Programming Practices

4
Human Technology
KNOWN UNKNOWN PLACES
PLACE TO GO
HOUSE
UTILITIES
HUMAN
FOOD CLOTH
TRANSPORTATION
INFORMATION EXCHANGES
5
World of Information
6
Thing to Think ( Communication )

• What are requirement of communication ?
• How do you make communication understandable for
  each other ( in case of multiple transmitters /
  receivers) ?
• Discussion with Level of Communication ?

7
1. Outline of the Course

• An overview of client/server and distribution
  models.
• An emphasis on programming approaches
• sockets, remote procedure calls (RPCs)
• the use of concurrency
• Examples will use CUNIX

8
Details (subject to change)

• 1. Client/Server Distribution Architectures
• client/server models (DCE, CORBA, DCOM),
  distribution models, server architectures,
  language constructs for parallelism, distributed
  programming
• 2. UNIX Networking
• low-level file I/O, processes, networking
  overview (ISO, TCP, UDP), sockets programming
  (iterative, concurrent), RPCs
• 3. Distributed Data Management
• distributed data design, DBMS architectures,
  distributed transaction processing

9
Prerequisites

• Be able to program in C under UNIX
• many network functions use pointers to structs
• you will not have to create pointer-based data
  structures like linked lists or trees but you
  might have to be able to read code that uses such
  things
• required UNIX skill level create directories,
  files, compilation

10
1. The Client Server Model

• Objectives of these slides
• introduce the client/server model
• Background Reading
• Chapter 1 , 2 (Berson)
• LAN / WAN Architectures

11
Overview

• 1. Client/Server Basics
• 2. Client/Server in More Detail
• 3. Client/Server Summary
• 4. Standards Organisations
• 5. DCE
• 6. CORBA
• 7. DCOM
• 8. Frameworks
• 9. More Details

12
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).

13
1.1. Client/Server Environment
clients
LAN or WAN
Server
Data
Fig 1.4, p.8 (Berson)
14
1.2. Example

• The ATM network
• the clients are the ATM machines
• user interfacessome simple application
  processing
• the server is at the bank
• most application processingvery large database
  of customer accounts

15
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.

16
1.4. Recent Client/Servers Architectures

• More complex networking
• LAN, WAN ? Web , Internet Client mobility
• More complex data structures
• relational ? multimedia, OO, deductive
• size, 7distributed databases, parallelism
• Separation of business logic (i.e. program code
  for manipulating data) from the data
• 3-tier (multi-tier) architectures
• distributed business logic

continued
17
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
• 2.8. Peer-to-Peer

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

• 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

20
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

21
2.3. The 2-tier Model Fig. 2.3, p.41
Client
Server
Presentation Logic
Database Logic
Business Logic
DBMS
Database Logic
Database
22
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).

23
Drawbacks

• It is difficult to build heterogeneous database
  environments.
• Transaction processing is limited by the DBMS.
• Asynchronous processing is difficult
• i.e. the client doesnt wait for the servers
  answer
• Scalebability?

24
2.4. The 3-tier Model Fig. 1.6, p.12
UNIX
ServerData
ServerData
Clients
Win/NT
Application servers
Data Servers
25
The 3-tier Model Again Fig.2.6, p.48
Price/PerformanceFunctionalityLocal Autonomy
Greater IntegritySecurityCentral Control
Mainframehost(s)
Tier 1
Server
force
Tier 2
LAN
Tier 3
26
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 logic)
• sometimes called the middle-tier server

27
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

28
Problems

• Much more complex
• network management, data integrity, maintenance,
  development
• Still dependent on platforms.

29
Examples

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

continued
30

• 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

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

• 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

33
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
34

• 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

35
Fat Client Advantages

• The server is unaffected when updates are done to
  the clients application logic
• the server will be more stable
• Easier to program
• less networking
• more direct access to client platform features,
  such as GUI

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

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

38
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 customers record
• A transaction should possess the ACID
  properties
• Atomicity, Consistency, Isolation, Durability

continued
39

• 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

40
2.7. Multi-tier Model Fig.2.9,p.53
Middleware
Physical Network
41
Common New Features

• Asynchronous connectivity e.g. asynchronous RPCs
• Data distribution using replication
• Name/directory services for resource location
  independence
• More complex data types
• More complex analysis e.g. data mining, network
  characteristics
• Authentication services
• Distributed file system(s)
• Time services

42
Examples

• Domain-specific
• ODBC, SQL, Oracle Glue
• Groupware middleware
• Microsoft Exchange, Lotus Notes
• Internet middleware
• HTTP, Secure Socket Layer (SSL)
• Object middleware
• CORBA, DCOM (more on these later)

43
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

44
2.8. Peer-to-Peer

• Not a client/server model.
• All participant systems are equals, and can
  request/provide services to each other.
• Encourages cooperative processing.

continued
45

• It is useful if a server can initiate certain
  communications with clients
• e.g. update client-side software
• If there are multiple servers (e.g the ATM
  example), then they will probably communicate
  between themselves using peer-to-peer
• account sharing, messaging

46
3. Client/Server Summary

• 3.1. Recurring Issues
• 3.2. Advantages of Client/Server
• 3.3. Disadvantages of Client/Server

47
3.1. Recurring Issues

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

48
Whats 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

49
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
50

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

51
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

52
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
53

• 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
54

• 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
55

• 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

56
5. DCE

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

57
DCE RPC
Server
Client
RemoteProcedure
Applicationcode
Applicationcode
RPC
Stub Code
Stub Code
RPC runtime library
RPC runtime library
Input
Output
Network
58
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-level language (simplified C types),
  which are easily converted to network packets.

59
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
60
DCE Architecture
Fig. 1.9, p.23
61
5.1. Distributed File System (DFS)

• 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

62
Issues

• Access security and protection
• user authentication (Kerberos) user control
• Data reliability
• Data availability
• Performance
• Management

63
5.2. Directory Services

• All distributed systems must support a mechanism
  whereby entities (files, programs) can be found
  easily
• naming services
• directory/trading services based on entity
  attributes(something like the telephone yellow
  pages)
• Directories must be ordered
• hierarchical

64
5.3. Threads

• A thread is a light-weight process (inexpensive
  to create), that can execute at the same time as
  other threads.
• Requires quite complex synchronisation mechanisms
  (e.g. semaphores) to control access to shared
  resources (e.g. to files).

65
5.4. More Details

• There are several books from OReilly Assoc. on
  different aspects of DCE
• Understanding DCE
• Guide to Writing DCE Applications
• Distributed Applications Across DCE and Windows
  NT
• We will look at simple RPC (and maybe threads)
  later in the course.

66
6. CORBA

• The Common Object Request Broker Architecture
  (CORBA).
• The Object Management Groups (OMG) aim
• specify a distributed computing environment
  within an object-oriented framework
• i.e. using objects, methods, message passing,
  etc.
• They developed the Object Management Architecture
  (OMA).

67
OMA Fig. 1.11, p.29
Application Objects
Common Facilities
Object Request Broker
Object Services
68
6.1. Important CORBA Features

• An objects interface (service) is completely
  separated from its implementation.
• An objects location is completely hidden.
  Consequently, CORBA provides
• Naming service (white pages)
• Trading service (yellow pages)
• Interface Repository (IR)

continued
69

• Object communication is greatly simplified
• uses messgaes, written in an Interface Definition
  Language (IDL)
• similar idea to in DCE RPC
• IDL is a superset of C data structures
• An object can find other objects at run-time by
  using the Dynamic Invocation Interface (DII)
• but usual approach is to already know the other
  object

continued
70

• Objects can be built more easily by using
  pre-existing CORBA services for
• message encoding, object locating, security
• Advanced services
• persistent objects, transactions, concurrency
  control, etc.
• CORBA facilities
• horizontal and vertical application frameworks
• e.g. OpenDoc variant, printing, mobile agents

continued
71

• Objectify legacy code with object adaptors.
• CORBA is an open standard
• ensures its continued innovation and evolution

72
6.2. ORBs

• An Object Request Broker (ORB) contains the
  features specified by CORBA.
• ORBs can be written in any language.
• CORBA 2.0 specifies ORB compatibilty between
  vendors using the Internet Inter-ORB Protocol
  (IIOP)
• an extension to TCP/IP

73
Major ORB Components
74
6.3. Usual way of using CORBA
Client
Server
IDL client stub
IDL server skeleton
ORB interface
ORB interface
ORB internals
ORB internals
Network
75
6.4. CORBA versus HTTP

• The most typical way of programming on the Web is
  by using HTTP and CGI.

76
CGI Characteristics

• Call Program means send a string from a form to
  a fixed host and program.
• The server invokes the program for each client
  request
• a heavy overhead for anything but small programs
• each client request is treated dependently
• no record of previous requests is stored

77
CORBA Advantages over CGI

• CORBA allows real parameter passing
• Objects do not necessarily have to be re-invoked
  for every message (client request).
• Objects can be coded to record patterns of
  previous requests.
• CORBA allows more flexible object relationships.

78
6.5. More Details

• Java Programming with CORBAA. Vogel K.
  DuddyWiley, 1997
• CORBA 3.0 articles inCommunications of the
  ACMOctober 1998
• There are several CORBA books in the library.

79
7. DCOM

• Microsofts approach to Internet computing
• first shipped with Windows/NT 4.0
• primarily used in ActiveX components, which are
  DCOM objects
• A DCOM object is not a traditional kind of
  object (as seen in Java, C, etc)
• has no unique name/ID
• contains no state
• programmer must code up inheritance

continued
80

• A DCOM object is a collection of interfaces to
  object implementations, written in real
  programming languages.
• DCOM has been integrated with C, C, Visual
  Basic, and an emasculated Java (Visual J).

81
7.1. Using DCOM objects

• When a DCOM client needs an object, it issues a
  request for an object with the specified
  interface needs.
• A DCOM server containing an object with a
  matching interface uses a class factory to invoke
  the necessary object.

82
7.2. DCOM Features

• DCOM cleanly separates an objects interface from
  its implementation
• the IDL is based on DCE RPC
• there is added support for Object Linking and
  Embedding (was OLE, now called COM).
• An objects location is hidden
• but the buggy Windows registry is used to
  advertise object interfaces

continued
83

• Limited interoperability with other client/server
  and distributed models (e.g. DCE, CORBA).
• Security model closely tied to Windows/NT.
• Platform is open so long as you use Windows
• (an example of irony)

84
7.3. CORBA versus DCOM

• CORBA advantages
• portability, security, its object model, (OO)
  language support, its IDL, openness, innovation
• tests show that DCOM is 20 slower than CORBA
  even though it has a much simpler object model
• DCOM advantage
• promoted by Microsoft

85
7.4. More Details

• Understanding ActiveX and OLED.
  ChappellMicrosoft Press, 1996.
• ActiveX DemystifiedD. Chappell, D.S.
  LinthicumBYTE, Sept. 1997, pp.56-64

86
8. Frameworks

• A framework is a way to manage a system of
  interacting objects (components).
• It suggests patterns for how to design objects
  and have them communicate and collaborate.
• The resulting objects tend to have a consistent
  design and common code/attributes
• improves their maintainability, reuse

87
8.1. Components

• A software component performs a common task in a
  standard way
• e.g. user-interface controls (ActiveX)
• Components speed up application development.
• They have a high-degree of customisability, which
  is accessible to (non-technical) users.

continued
88

• Inexpensive to develop.
• Should provide reliable service across a wide
  range of platforms.
• Increasingly coded using distributed objects.

89
8.2. Compound Documents

• A compound document is a tool for organising
  components which integrates their visual and
  containment relationships
• e.g. Apples OpenDOC, Microsofts OLE
• The document idea is very familiar to users, so
  is a good way of introducing object frameworks
  (to naïve users).

90

• A compound document can contain components that
  are themselves made from other components
• recursive definition
• Examples
• a spell checker consists of components for dialog
  boxes, buttons, dictionary, database
• a word processor consists of components for text,
  graphics, grammar checker, spell checker, etc.

91

• A compound document must support
• document layout
• structured storage (using objects)
• a way of scripting the relationships between the
  components
• a communication layer for components
• could use CORBA so that components/objects can be
  distributed

92
The Future of Compound Documents

• Mobile/distributed documents.
• New user environments
• extended desktop
• new views of the Web

93
9. More Details

• See the end of each section for specific
  references.
• A good overview article
• Frameworks for Component-based Client/Server
  ComputingScott M. LewandowskiACM Computing
  SurveysVol. 30, No. 1, March 1998