1. Terrence Jose Montanes

2.  Clients and servers are separate logical
entities that work together over a network to
accomplish a task

3.  Service
 Shared resources
 Asymmetric protocols
 Transparency of location
 Mix-and-match
 Message based exchanges
 Encapsulation of services
 Scalability
 Integrity

4.  File Servers

5.  Database Servers

6.  Transaction Servers

7.  Groupware Servers

8.  Object Servers

9.  Web Servers

10. Fat Clients: File & Database Fat Servers: Groupware, Transaction & Web

12. 2-Tier 3-Tier
System administration Complex (more logic on the client to manage) Less complex
Security Low (data-level security) High
Encapsulation of data Low (data tables are exposed) High (the client invokes services or methods)
Performance Poor Good
Poor (limited management of client Excellent (concentrates incoming sessions; can
Scale communications links) distribute loads across multiple servers)
Application reuse Poor (monolithic application on client) Excellent (can reuse services and objects)
Ease of development High Getting better
Server-to-server infrastructure No Yes (via server-side middleware)
Yes (via gateways encapsulated by services or
Legacy application integration No objects)
Internet support Poor Excellent
Heterogeneous database support No Yes
No (only synchronous, connection-oriented
Rich communication choices RPC-like calls) Yes
Hardware architecture flexibility Limited (you have a client and a server) Excellent
Availability Poor Excellent

14.  You can develop big applications in small
steps
 Applications can reuse components
 Clients can access data and functions easily
and safely
 Custom applications can incorporate off-the-
shelf components
 Component environments don't get older—
they only get better

15.  More than 50 applications
 Written in different languages or by different
organizations
 Heterogeneous data sources
 Life longer than three years
 Many modifications or additions
 A high-volume workload
 Significant inter-application communication
 Expectation of growing the application

17. Intergalactic Era
Application Characteristics Client/Server Ethernet Era Client/Server
Number of clients per application Millions Less than 100
100,000+ "Server-mania" with many
heterogeneous servers performing different
Number of servers per application roles 1 or 2
Geography Global Campus-based
Server-to-server interactions Yes No
Middleware ORBs on top of Internet SQL and stored procedures
Client/server architecture 3-tier (or N-tier) 2-tier
Transactional updates Pervasive Very infrequent
Multimedia content High Low
Mobile agents Yes No
OOUIs, JavaBeans, Webtops, browsers, and
Client front-ends shippable places Fat GUI clients
Timeframe 1998 and beyond 1985 till present

18.  Rich transaction processing
 Roaming agents
 Rich data management
 Intelligent self-managing entities
 Intelligent middleware

25.  The client building block
 The server building block
 The middleware building block

27.  A hodgepodge of s/w technologies
 A buzzword
 A key to developing client/server applications
 Middleware is a vague term that covers all
the distributed software needed to support
interactions b/w clients and servers.

28.  Starts with API
 Covers transmission from request to result
 Not includes
-S/w that provide the actual service
- Database
- User interface.

30.  General pipes
 Service-specific pipes
-Database-specific
-OLTP-specific
-Groupware-specific
-Object-specific
-Internet-specific
-System management

32.  The stack sandwich
 The logical network driver
 The transport-independent APIs

35. Content Bandwidth Requirements Remarks
Audio
44,100 samples/sec, 16-bit per
п CD quality 706 Kbit/s sample
п Digital phone quality 64 Kbit/s 8,000 samples/sec, 8-bit samples
Minimum-quality, full-motion 1024 × 768 pixels, 30 frames/sec
video 566 Kbit/s 3 colors; 8 bits each
TV-quality, full-motion video
п Uncompressed 96 Mbit/s
п MPEG-2 compression 6 Mbit/s
Data requirements 2 Mbit/s For LAN-speed responsiveness

37.  Waits for client-initiated requests
 Executes many requests at the same time
 Takes care of VIP clients first
 Initiates and runs background-task activity
 Keeps running
 Grows bigger and fatter

38.  Base Services

39.  Task Preemption
 Task Priority
 Semaphores
 Interprocess Communications (IPC)
 Local/Remote Interprocess Communications
 Threads
 Intertask Protection
 Multiuser High-Performance File System
 Efficient Memory Management
 Dynamically Linked Run-Time Extensions

40.  Extended Services

41.  Ubiquitous Communications
 Network Operating System Extensions
 Binary Large Objects (BLOBs)
 Global Directories and Network Yellow Pages
 Authentication and Authorization Services
 System Management
 Network Time
 Database and Transaction Services
 Internet Services
 Object-Oriented Services

46.  Non-GUI clients that do not need multitasking
 Non-GUI clients that need multitasking

49. Feature Grapical User Interface (GUI) Object-Oriented User Interface (OOUI)
A graphic application consists of a collection of
cooperating user objects. Everything that you see is an
object. Each object is represented by an icon and has at
A graphic application consists of an icon, a primary window with
least one view. Objects can be reused in many tasks. The
a menu bar, and one or more secondary windows. The focus is
application's boundaries are fuzzy. The user defines
on the main task. Ancillary tasks are supported by secondary
Application Structure what's an application by assembling a collection of
windows and pop-ups. Users must follow the rigid task structure
objects. These objects may come from one or more
(and may get trapped in a task). An application represents a
programs and are integrated with the desktop objects the
task.
system provides (likes printers and shredders). The users
can innovate and create their own "Lego-like" object
collections.
Icons Icons represent a running application. Icons represent object that may be directly manipulated.
Starting an Users open the object on the desktop, which causes a
Users start application before selecting an object to work with.
Application window view of the object to be displayed.
Users open a primary window and then specify the objects they A window is a view of what's inside an object. There is a
Windows want to interact with. The same window can be used to display one-to-one relationship between a window and an
other objects. object.
Each object has a context menu. You navigate within an
Menus provide the primary method for navigating within an application or across applications by directly manipulating
Menus
application. objects. The desktop functions as one big menu; icons
represent the objects that you can manipulate.
Active Application Icons are augmented with the in-use emphasis to
Icons represent minimized windows of active applications.
Visual represent an active object.

50. Object-Oriented User Interface
Feature Grapical User Interface (GUI)
(OOUI)
Objects are created, communicated with,
An application may provide direct manipulation
Direct Manipulation moved, and manipulated through drag-and-drop
on an ad hoc basis.
manipulation.
Objects are created in an application-specific A templates folder contains a template for every
manner, usually through some form of copy object type. To create a new instance of an
Creating New Objects
mechanism or using the menu choices: new or object, drag its template to where you want the
open. new object to reside.
In addition to choosing actions from menus, a
Choose object; then choose action from menu user can drag objects to icons to perform
Actions
bar. operations; for example, dragging a file to a
printer icon.
In addition to list boxes, OOUIs provide
container objects, including folders and
Text-based list boxes provide the primary form
Containers notebooks. These in turn can contain other
of containment.
objects. Actions performed on container objects
affect all the objects inside them.
Focus Focus is on the main task. Focus is on active objects and tasks.
All the applications behave the same and the
Control alternates between the user and the
Who Is In Control? user acts as the conductor. Think of the user as
application.
the visual programmer of the desktop.
NextStep/Mac OS X, Mac OS, Windows 98, OS/2
Product Examples Windows 3.X, Motif, and simple Web pages. Workplace Shell, and Web pages that take
advantage of Java 2 JavaBeans.

53. Requirements From an Non-GUI Client Simple GUI
Without OOUI Client
OS With Multitasking Client
Multitasking
Request/reply mechanism
(preferably with local/remote Yes Yes Yes Yes
transparency)
File transfer mechanism to
move picture, text, and Yes Yes Yes Yes
database snapshots
Pre-emptive multitasking No Yes Desirable Yes
Task priorities No Yes Desirable Yes
Inter-process communications No Yes Desirable Yes
Threads for background
communications with server Yes (unless you like
No Yes Yes
and receiving callbacks from the hourglass icon)
servers
OS robustness, including
intertask protection and No Yes Desirable Yes
reentrant OS calls

54.  Clients are becoming more intelligent
 These "New Age" clients must provide a server
lite function
 It should still be able to download shippable
places, run Java applets, and receive calls from
a server
 A server lite implementation does not need to
support concurrent access to shared resources,
load balancing, or multithreaded
communications

55.  The desktop is becoming more fragmented
 The universal client is really a Web browser
 There will be a huge demand for super-fat PCs
 There will be a huge demand for ultra-thin PCs
 Shippable places will become the new desktops
 Embedded clients will be everywhere

57. Application vs Mixed Server File/Print Server
Unix 83.00% 17.00%
Windows NT 46.00% 54.00%
OS/2 Warp
31.80% 68.20%
Server
NetWare 18.00% 82.00%

59.  Location transparency
 Namespace transparency
 Logon transparency
 Replication transparency
 Local/remote access transparency
 Distributed time transparency
 Failure transparency
 Administration transparency

63.  Immediate replication causes any update to
the master to be immediately shadowed on
all replicas
 Skulking causes a periodic propagation (for
example, once a day) to all the replicas of all
changes made on the master

64.  Directory-specific APIs and class libraries
 LDAP and X.500 APIs
 Java classes
 Distributed object interfaces
 Meta-directory services and scripts

65.  It periodically synchronizes the clocks on every
machine in the network
 It introduces an inaccuracy component to
compensate for unequal clock drifts that occur
between synchronizations

67.  Authentication: Are you who you claim to be?
 Authorization: Are you allowed to use this
resource?
 Audit Trails: Where have you been?

68.  Integrity: Is My In-Transit Data Safe?
- Encryption
- Cryptographic checksums
 Non-Repudiation: Can You Prove It in Court?
-Evidence of message creation
- Evidence of message receipt
- An action timestamp
- The evidence long-term storage facility
- The adjudicator
.

70.  How Do You Like your Keys?
- Shared Private Keys
- Public Keys

75.  Jeri must first obtain a certificate
 Jeri applies for a store account
 Merchant determines if the certificate is OK
 Jeri's certificate is OK
 Jeri can now shop, shop, shop

77.  Jeri places an order
 Merchant asks bank for authorization
 The bank asks the credit card issuer for
authorization
 The credit card company approves the
transaction
 The bank says it's OK
 The merchant sends Jeri a receipt and ships
goods
 Jeri receives her monthly credit card bill

79.  A 'networking operating system ' is an
operating system that contains components
and programs that allow a computer on a
network to serve requests from other
computers for data and provide access to
other resources such as printer and file
systems.

80.  Add, remove and manage users who wish to use
resources on the network.
 Allow users to access to the data on the network. This
data commonly resides on the server.
 Allow users to access data found on other network
such as the internet.
 Allow users to access hardware connected to the
network.
 Protect data and services located on the network.
 Enables the user to pass documents on the attached
network.

81.  basic support for hardware ports
 security features such as authentication,
authorization, login restrictions, and access control
 name services and directory services
 file, print, data storage, backup and replication
services
 remote access
 system management
 network administration and auditing tools with
graphic interfaces
 clustering capabilities
 fault tolerance and high availability

83.  Sockets
 NetWare: IPX/SPX and TLI
 NetBIOS and NetBEUI
 Named Pipes

85.  An essential problem is that RPCs are not
procedure calls at all; they are truly process
invocations. The invoked program runs across
the wire in a different resource domain

86. Remote Procedure Call
Binding server
binder
(0)
recv req
program stub (2) register stub procedure
or search
return
LPC Bind req recv req execute
(1) (3) (5) (5)
(1) Recv bind unmarsh
marshal (4)
Send req LPC
Recv marshal
result (6)
(8) send
(8) unmarsh (7) result
(6) return
return
client server

87. Remote Procedure Call: steps
(0) Remote procedures registration;
(1) Client procedure calls client stub in normal way;
(2) Client stub sends a binding request asking for information;
(3) Binding server searches for binding and reply to client stub;
(4) Client stub packs a message (marshalling) and send to server stub;
(5) Server stub unpacks parameters (unmarshalling), invokes LPC;
(6) Server procedure executes and returns results to server stub;
(7) Server stub packs results (marshalling) and sends to client stub;
(8) Client stub unpacks results and returns to client procedure.
Call-by-value: parameter is a straight value (int, float, …)
Call-by-reference: parameter is a pointer to anything (int,
record, array, pointer, …)
Distributed Systems 87

88. Stubs
The stub is application-specific code, but it is
not directly generated by the application
writer and therefore appears as a separate
layer from the programmer's point of view.
The function of the stub is to provide
transparency to the programmer-written
application code.

89. 1.On the client side:
The stub handles the interface between the
client's local procedure call and the run-time
system, marshaling and unmarshaling data,
invoking the RPC run-time protocol, and if
requested, carrying out some of the binding
steps.
2. On the server side:
The stub provides a similar interface between the
run-time system and the local manager
procedures that are executed by the server.

90.  How are the server functions located and
started
 How are parameters defined and passed
between the client and the server
 How are failures handled
 How is security handled by the RPC
 How does the client find its server
 How is data representation across systems
handled

93.  Every DAD needs a MOM
 DAD stands for Distributed Application
Development
 MOM stands for Message-Oriented
Middleware

98. Feature MOM: Messaging and Queuing Remote Procedure Call (RPC)
Metaphor Post office-like. Telephone-like.
Asynchronous. Clients and Synchronous. Clients and servers
servers may operate at different must run concurrently. Servers
Client/Server time relationship times and speeds. must keep up with clients.
Servers must first come up
Client/Server sequencing No fixed sequence. before clients can talk to them.
Style Queued. Call-Return.
Partner needs to be available No. Yes.
Single queue can be used to
implement FIFO or priority based
Load-balancing policy. Requires a separate TP Monitor.
Yes (some products). Message
queue can participate in the
Transactional support commit synchronization. No. Requires a transactional RPC.
Message filtering Yes. No.
Slow. An intermediate hop is
Performance required. Fast.
Yes. Queues and triggers are Limited. Requires threads and
Asynchronous processing required. tricky code for managing threads.

99. Dynamic Data Exchange or DDE is a Windows feature that allows
Windows applications to communicate with each other. DDE is
based on the messaging system built into Windows. Two Windows
programs can carry on a DDE "conversation" by posting messages to
each other. These two programs are known as the "server" and the
"client". A DDE server is the program that has access to data that
may be useful to other Windows programs. A DDE client is the
program that obtains this data from the server.

100.  Common Object Request Broker Architecture
 Communication infrastructure for distributed
objects
 Allows a heterogeneous, distributed
collection of objects to collaborate
transparently

101.  Developing distributed applications
 Locating remote objects on a network
 Sending messages to those objects
 Common interface for transactions, security,
etc.
 CORBA Services (more later)

102.  Data is distributed
 Administrative and ownership reasons
 Heterogeneous systems
 Shared by multiple applications
 Scalability

103.  Computation is distributed
 Scalability: multiprocessing
 Take computation to data
 Heterogeneous architectures
 Users are distributed
 Multiple users interacting and communicating
via distributed applications

104.  All entities are modeled as objects
 Systems support location transparency
 Interfaces, not implementations, define
objects
 Good distributed object systems are open,
federated systems

105.  Designers of CORBA
 Consortium of 700+ companies
 Not including Microsoft
 Members:
▪ platform vendors
▪ database vendors
▪ software tool developers
▪ corporate developers
▪ software application vendors

106.  Has never been fully implemented
 Probably never will be
 Industry moves quickly and spec has to keep
up

107. Client Server
request response
ORB ORB
“Object Bus”

108.  Examples
 Service
 Client
 Component
 Business object
 CORBA objects approach universal accessibility
 Any Language
 Any Host on network
 Any Platform

109.  The client IDL stubs
 The Dynamic Invocation Interface (DII)
 The Interface Repository APIs
 The ORB Interface

110.  The Server IDL Stubs (OMG calls them
skeletons)
 The Dynamic Skeleton Interface (DSI)
 The Object Adapter
 The Implementation Repository
 The ORB Interface

111. 1. ORB
2. CORBA Services
3. CORBA Facilities
4. Application Objects

112.  Object Request Broker
 “Object Bus”
 Handles all communication among objects
 Each host (machine) has its own ORB
 ORBs know how to talk to each other
 ORB also provides basic services to client

113.  Find the object implementation for the
request
 Prepare the object implementation to receive
the request
 Communicate the data making up the
request
 Retrieve results of request

114.  There’s an ORB on the server too
 ORB receives request

115.  With an RPC, you call a specific function (the
data is separate).
 In contrast, with an ORB, you're calling a method
within a specific object.
 ORB method invocations have "scalpel-like"
precision. The call gets to a specific object that
controls specific data, and then implements the
function in its own class-specific way.
 RPC calls have no specificity—all the functions
with the same name get implemented the same
way. There's no differentiated service here.

117.  Internet Inter-Orb Protocol
 Network or “wire” protocol
 Works across TCP/IP (the Internet protocol)

118.  Method invocations
 Static and Dynamic
 Remote objects or CORBA services
 High-level language bindings
 Use your favorite language; ORB translates
 Self-describing
 Provides metadata for all objects and services

119.  Local or remote
 Same API wherever target object lives
 Preserves context
 Distributed security and transactions
 Coexistence with legacy code
 Just provide a wrapper object

120.  Not a separate process
 Library code that executes in-process
 Listens to TCP ports for connections
 One port per local object
 Opens TCP sockets to other objects
 N ports per remote machine

121.  Interface Definition Language
 Defines protocol to access objects
 Like a contract
 Well-specified
 Language-independent

122. module Calc {
interface Adder {
long add(in long x, in long y);
}
}
 Defines an object called Adder with a method
called add

123.  Stub
 lives on client
 pretends to be remote object
 Skeleton
 lives on server
 receives requests from stub
 talks to true remote object
 delivers response to stub

124. Client Host Machine Server Host Machine
Client Object Remote
Object
Stub Skeleton
ORB IIOP ORB

125.  in CORBA, a client is a client relative to a
particular object i.e. an object with a
reference to a “server” object
 A client may also act as a server
 If it has an IDL and stubs and skeletons
 Technically, a CORBA server contains one or
more CORBA objects

126.  Host machine
 Program running on host machine
 CORBA object running inside program
 has IDL, stub, skeleton
 Sometimes called a Servant

127.  Client code has no knowledge of the
implementation of the object or which ORB is
used to access the implementation.

128.  APIs for low-level, common tasks
 Life Cycle Service
 creating, copying, moving, removing objects
 Naming Service
 Register objects with a name
 Look up objects by name

129.  Concurrency Control Service
 Obtain and release exclusive locks
 Transaction Service
 Two-phase commit coordination
 Supports nested transactions
 Persistence Service
 Storing objects in a variety of databases
 RDBMS, OODBMS, file systems

130.  Security Service
 Authentication, ACLs, encryption, etc.
 Event Service
 Uncoupled notifications

131.  Relationship
 Externalization
 Query
 Licensing
 Properties
 Time
 Trader
 Collection
 … and so on…
 See what I mean about it never being
implemented?

132.  Frameworks for specialized applications
 Distributed Document Component Facility
 OpenDoc
 In progress:
 Agents
 Business Objects
 Internationalization