Ajay Kumar Shrivastava

• 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

What Does a Server Need From an
OS?
• Base Services

• 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

What Does a Server Need From an
OS?
• Extended Services

Extended Services
• 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

• Non-GUI clients that do not need multitasking
• Non-GUI clients that need multitasking

Object-Oriented User Interface
(OOUI) Clients

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

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

Compound Documents: OOUIs on
Steroids

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

• 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

• 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

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

NOS Middleware: The Transparent
Illusion

What Does Transparency Really
Mean?
• Location transparency
• Namespace transparency
• Logon transparency
• Replication transparency
• Local/remote access transparency
• Distributed time transparency
• Failure transparency
• Administration transparency

NOS: Extending the Local OS's Reach

• 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

How Do You Interface to These
Directories?
• Directory-specific APIs and class libraries
• LDAP and X.500 APIs
• Java classes
• Distributed object interfaces
• Meta-directory services and scripts

Distributed Time Services
• 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

Can We Obtain C2-Level Security on the Intergalactic Net?
• Authentication: Are you who you claim to be?
• Authorization: Are you allowed to use this resource?
• Audit Trails: Where have you been?

Can We Do Better Than C2 on the
Intergalatic Net?
• 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
.

The Internet: In Certificates We Trust
• How Do You Like your Keys?
- Shared Private Keys
- Public Keys

The Shared Private Key Approach to
Encryption

The Public/Private Key Approach to
Encryption

Using Public/Private Keys to Send
Signed Documents and Contracts

So What Exactly Is a Digital
Certificate?

• 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

What a Certificate Authority Does
Today

Electronic Payments: The SET Protocol
• 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

SET: The Next Electronic Shopping and
Payment Infrastructure

Network operating system
• 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.

Features
• 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.

• 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

Where the Most Popular Stacks Fit in the OSI
Reference Model

• Sockets
• NetWare: IPX/SPX and TLI
• NetBIOS and NetBEUI
• Named Pipes

The "New" SNA: APPC, APPN, and
CPI-C

Remote Procedure Call (RPC)
• 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

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

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 52

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.

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.

• 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

The Mechanics of an RPC Stub Compiler

Getting a Seat for a Madonna Concert Using RPCs

Messaging And Queuing: The Mom
Middleware
• Every DAD needs a MOM
• DAD stands for Distributed Application
Development
• MOM stands for Message-Oriented
Middleware

MOM: Save Your Messages Until You
Get to a Server

MOM: Many-to-Many Messaging via
Queues

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

Dynamic Data Exchange (DDE)
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.

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

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

Why Distributed Applications?
• Data is distributed
– Administrative and ownership reasons
– Heterogeneous systems
– Shared by multiple applications
– Scalability
Copyright © 1998 Purple Technology, Inc.

Why Distributed Applications?
• Computation is distributed
– Scalability: multiprocessing
– Take computation to data
– Heterogeneous architectures
• Users are distributed
– Multiple users interacting and communicating via distributed applications
Copyright © 1998 Purple Technology, Inc.

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

• Designers of CORBA
• Consortium of 700+ companies
– Not including Microsoft
• Members:
• platform vendors
• database vendors
• software tool developers
• corporate developers
• software application vendors

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

request
Client
ORB
ORB
Server response
“Object Bus”

• Examples
– Service
– Client
– Component
– Business object
• CORBA objects approach universal accessibility
– Any Language
– Any Host on network
– Any Platform
Copyright © 1998 Purple Technology, Inc.

what CORBA does on the client side
• The client IDL stubs
• The Dynamic Invocation Interface (DII)
• The Interface Repository APIs
• The ORB Interface

what CORBA elements do on the server
• The Server IDL Stubs (OMG calls them
skeletons)
• The Dynamic Skeleton Interface (DSI)
• The Object Adapter
• The Implementation Repository
• The ORB Interface

1. ORB
2. CORBA Services
3. CORBA Facilities
4. Application Objects
Copyright © 1998 Purple Technology, Inc.

• 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
Copyright © 1998 Purple Technology, Inc.

• 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
Copyright © 1998 Purple Technology, Inc.

• There’s an ORB on the server too
• ORB receives request
Copyright © 1998 Purple Technology, Inc.

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

Copyright © 1998 Purple Technology, Inc.

• Internet Inter-Orb Protocol
• Network or “wire” protocol
• Works across TCP/IP (the Internet protocol)
Copyright © 1998 Purple Technology, Inc.

• 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
Copyright © 1998 Purple Technology, Inc.

• Local or remote
– Same API wherever target object lives
• Preserves context
– Distributed security and transactions
• Coexistence with legacy code
– Just provide a wrapper object
Copyright © 1998 Purple Technology, Inc.

• 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
Copyright © 1998 Purple Technology, Inc.

• Interface Definition Language
• Defines protocol to access objects
• Like a contract
• Well-specified
• Language-independent
Copyright © 1998 Purple Technology, Inc.

module Calc { interface Adder { long add(in long x, in long y);
}
}
• Defines an object called Adder with a method called add
Copyright © 1998 Purple Technology, Inc.

• 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
Copyright © 1997 Alex Chaffee

Client Host Machine
Client Object
Server Host Machine
Remote Object
Stub
ORB IIOP
Copyright © 1997 Alex Chaffee
Skeleton
ORB

• 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

• Host machine
• Program running on host machine
• CORBA object running inside program
– has IDL, stub, skeleton
– Sometimes called a Servant
Copyright © 1998 Purple Technology, Inc.

Stubs and Skeletons -> Platform
Independence
– Client code has no knowledge of the implementation of the object or which ORB is used to access the implementation.

• 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
Copyright © 1998 Purple Technology, Inc.

• 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
Copyright © 1998 Purple Technology, Inc.

• Security Service
– Authentication, ACLs, encryption, etc.
• Event Service
– Uncoupled notifications
Copyright © 1998 Purple Technology, Inc.

• Relationship
• Externalization
• Query
• Licensing
• Properties
• Time
• Trader
• Collection
• … and so on…
• See what I mean about it never being implemented?
Copyright © 1998 Purple Technology, Inc.

• Frameworks for specialized applications
• Distributed Document Component Facility
– OpenDoc
• In progress:
– Agents
– Business Objects
– Internationalization
Copyright © 1998 Purple Technology, Inc.