• Objects can be implemented in many different ways
• Compile-time objects
• e.g., instance of classes written in object-oriented language like Java, C++
• Data-base objects
• Procedural languages like C,with an appropriate “wrapper code” that gives it the appearance of an object
• System like Java RMI support compile-time objects
• Not possible or difficult in language-independent RMI middleware such as CORBA
• These systems use object adapters
• Implementations of object interfaces are registered at an object adapter, which acts as an intermediary between the client and the object implementation

Persistent vs. Transient Objects

• Persistent objects 
• continue to exist even if they are not contained in the address space of server process
• the “state” of a persistent object has to be stored on a persistent store, i.e., some second storage
• invocation requests result in an instance of the object being created in the address space of a running process
• many policies possible for object instantiation and (de)instantiation
• Transient objects
• Only exist as long as their container server process are running
• i.e., only exist in memory

Static vs Dynamic Remote Method Invocations

• Static invocation
• Typical ways for writing code that uses RMI is similar to the process for writing RPCC
• declare the interface in IDL, compile the IDL file to generate client and server stubs, link them to client and server side code to generate the client and the server executables
• requires the object interface to be known when the client is being developed
• Dynamic invocation
• The method invocation is composed at run-time
• invoke (object, method, input_parameters, output_parameters)
• Useful for applications where object interface are discovered at runtime
• e.g., object browser, batch processing systems for object invocations

Design Issues for RMI

• RMI invocation semantics
• Invocation semantics depend upon implementation of Request-Reply protocol used by RMI
• Could be Maybe, At-least-once, At-most-once

• Transparency
• Should remote invocations be transparent to the programmer?
• Partial failure, higher latency
• Different semantics for remote objects, e.g., difficult to implement “cloning” in the same way for local and remote objects or to support synchronization operations e.g., wait/notify
• Current consensus
• Access transparency
• Remote invocations should be made transparent in the sense that syntax of a remote invocation is the same as the syntax of local invocation
• Distinguish
• But programmers should be able to distinguish between remote and local objects by looking at their interfaces, 
• e.g., in Java RMI, remote objects implement the Remote interface

Implementing Issues for RMI

• Parameter Passing
• Representation of a remote object referece

• Request/Reply protocol
• Handling failures at client and/or server
• Issues in marshaling of parameters and results
• Input, output, inout parameters
• Data representation
• handling reference parameters
• Distributed object references
• handling failures in request-reply protocol
• Partial failure
• Client, server, network
• Supporting persistent objects, object adapters, dynamic invocations, etc

Marshalling

• Client unable to locate server
• Reasons
• Server has crashes
• Server has moved
• (RPC systems) client compiled using old version of service interfance
• System must report error (remote exception) to client 
• Loss of transparency
• Request message lost
• Retransmit a fixed number of times before throwing an exception
• Reply message lost
• Client resubmits request
• Server choices
• Re-execute procedure
• Server should be idempotent so that it can be repeated safely
• Filter duplicates
• Server should hold on to results until ackowledged
• Server crashes after receiving a request
• At least once
• Keep trying till server comes up again
• At most once
• Return immediately
• Exactly once impossible to achieve
• Client crashes after sending a request
• If a client crashes before RPC returns, we have an “orphan” computation at server
• Waste resources, could also start other comutations
• Orphan detection
• Reincarnation
• Client broadcasts new epoch when it comes up again
• Expiration
• RPC has fixed amount of time to do work

Note

• Implementing the request-reply protocol on top of TCP
• Does not help in providing applications with different invocation semantics
• TCP does not help with server crashes
• If a connection is broken, the end points do not have any guarantees about the delivery of messages that may have been in transit

RMI Software Components

• Communication module
• Implements the request-reply protocol
• Remote reference module
• Responsible for translating between local and remote object references and for creating remote object references
• Maintains remote object table that maintains a mapping between local&remote object references
• E.g., Object Adapter in CORBA

• Activation of remote objects
• Some applications require that information survive for long periods of time
• However, objects not in user all the time, so keeping them in running processes is a potential waste of resources
• Object can be activated on demand
• E.g., standard TCP services such as FTP on UNIX machines are activated by inetd
• Active and passive objects
• Active objects
• Instantiated in a running processes
• Passive objects
• Not currently active but can be made active
• Implementation of its methods, and marshalled state stored on disk
• Activator responsible for
• Registering passive objects that are available for activation
• Starting named server processes and activating remote objects in them
• Keeping track of locations of servers for mote objects that it has already activated
• Examples
• CORBA implementation repository
• JAVA RMI has once activator on each server computer

RMI – Other Topics

• Persistent object stores
• An object that is guaranteed to live between activations of process is called a persistent object
• Stored the state of an object in a marshalled (serialized) form on disk
• Location service
• Objects can be migrated from one system to another during their lifetime
• Maintains mapping between object references and the location of an object
• Distributed Garbage Collection
• Needed for reclaiming space on servers
• Passing “behavior”
• Java allows objects (data+code) to be passed by value
• If the class for an object passed by value is not present in a JVM, its code is downloaded automatically
• Use of reflection in Java RMI
• Allows construction of generic dispatcher and skeleton

• Java approach based on reference counting
• Each server process maintains a list of remote processes that hold remote object references for its remote objects
• When a client first acquires a remote reference to an object, it make addRef() invocation to server before creating a proxy
• When a clients local garbage collector notices that a proxy is no longer reachable, it makes a removeRef() invocation to the server before deleting the proxy
• When the local garbage collector on the server notices that the list of client processes that have a more reference to an object is empty, it will delete the object (unless there are any local objects that have a reference to the object)
• Other approaches
• Evictor pattern
• Leases

• Integrate with Java language and libraries
• Security, write once run anywhere, multithreaded
• Object oriented
• Can pass “behavior”
• Mobile code
• Not possible in CORBA, traditional RPC systems
• Distributed garbage collection
• Remoteness of objects intentionally not transparent
• Good for handling failures

Remote Interfaces, Objects, and Methods

• Object becomes remote by implementing a remote interface
• A remote interface extends the interface java.rmi.Remote
• Each method of the interface declares java.rmi.RemoteException in its throws clause in addition to any application-specific clauses

Creating distributed applications using RMI

1. Define the remote interfaces
2. Implement the remote objects and server
3. Implement the client
4. Compile the remote interface, server and client 
5. Generate the stub and skeleton using rmic
6. Start the RMI registry
7. Start the server
8. Run the client

• Definition
• Middleware is a set of common business-unaware services that enable applications and end-users to interact with each other across a network
• Distributed system services that have standard programming interfaces and protocols 
• Services sit in the middle above OS and network software
• and below industry-specific applications

• Information exchange services
• Application-specific services
• Specialized services
• e,g,m transaction services and replication services for distributed databases
• group services for collaborative applications, specialized services for multimedia applications
• business-unaware
• Management and support service
• needed for locating distributed resources and administrating resources acorss the network

• Clients
• Interacts with users through a user interface
• Performs application functions
• Interacts with client middleware using middleware API
• Receives response and display it if needed
• Servers
• Implement services
• Invoked by server middleware
• Provide error-recovery and failure handling service

 Overview

• Common communication patterns in distributed applications
• Client-Server
• Group (multicast)
• Function-shipping/Applets
• Client
• Process that requests services
• Server
• Process that provides services
• Details
• Client usually blocks until server responds
• Client usually invoked by end users when hey require services
• Server usually waits for incoming requests
• Server can have many clients making concurrent requests
• Server is usually a program with special privileges

Application Software Architectures

• Many applications can be considered to be made up of three software components or logical tiers

• user interface
• processing layer
• data layer

• Client/server architecture

• Single-physical tiered, two physical tiered
• multi-tiered

• Distributed Data
• e.g., distributed database
• Remote data
• e.g., network file system 
• Distributed programs
• e.g., world wide web
• Remote presentation
• e.g., telnet
• Distributed presentation
• e.g., X Windows

• Motivation for multi-tier architectures

• Frees clients from dependencies on the exact implementation of database
• It allows business logic to be concentrated in one place
• software updates are restricted to middle layer
• Performance improvements possible by batching requests from many clients to database
• Database and business logic tiers could be implemented by multiple servers for scalability

• Layered architectures
• Pros
• Division of task
• Scalability
• Transparency
• Potability
• Cons
• e.g., layer 1 and layer 3 cannot talk directly

• Object-based architectures
• Pros
• Independent components
• Free to talk to anyone

• Data-centered architectures
• e.g., google docs

• Event-based architectures
• e.g., facebook

3. System Architecture

• Centralized architecture
• client-server applications
• Decentralized architecture
• Peer-to-peer applications
• Hybrid architecture

• Distributed System
• Tannenbaum
• A distributed system is a collection of independent computers that appears to its users as a single coherent system
• Lamport
• You know you have one when the crash of a computer you’ve never heard of stops you from getting any work done.

• Distributed Applications

• Applications that consist of a set of processes that are distributed across a network of machines and work together as an ensemble to solve a common problem.

• Types of Distributed Systems
• Distributed computing systems
• Cluster computing: homogeneous
• Grid computing: heterogenous via virtual organizations
• Cloud computing: everything as a service
• Distributed Information Systems
• Transaction processing system (Transaction RPC)
• Enterprise Information integration
• Publish/Subscribe systems (message oriented v.s. RPC/RMI)
• Distributed Pervasive Systems
• Home systems
• Healthy care systems
• Sensor networks

Characteristic properties of transactions (ACID)

Goal/Beneftis

Communication

Distributed Software

Fundamental/Abstract Models