Distributed Objects

1
Distributed Objects

• Lecture on

2
Overview

• How did you like the Waldo paper a note on
  distributed computing?
• Local and remote object references
• Parameter passing
• Object invocation types
• Distributed Object Services
• Object Request Broker Architectures
• Interface Design
• Example Java RMI

3
Objects vs. Procedures
Object 2 identity
module data (optional)
Fields
Fields
Methods
Procedures
Object 1 Identity
Objects are supposed to have individual STATE and
IDENTITY. This is the fundamental difference to
e.g. procedure calls. Procedure calls can
simulate objects by storing state via a
parameter. Are stateless objects useful? What
does keeping state mean for a server? And how
does an object REFERENCE work ini DS?
4
Interface vs. Implementation
Implementation C (remote)
Interface
Implementation B (slow)
client
Implementation A (fast)
As long as the client only works with an
interface, the implementations can change without
breaking the client (or so the OO-theory says.)
5
Local objects
Program code
Data area (runtime)
Object ID (0xaabbccd0)
SOME
Class foo Private String fieldB String
getField() setField(String) Foo myFoo new
Foo() Myfoo.setField(SOME)
String MangledGetField(obj) MangledSetField(obj,
string)
Text area (runtime)
Early C compilers were really preprocessors
which generated mangled functions with an
additional parameter. This parameter was a
pointer to the state (where the fields are
stored) of the object
6
Calling Remote Objects some problems

• After creation through the language runtime, an
  object ID of a remote object will be specific to
  this machine (e.g. a memory address). This is
  fairly useless for a remote client.
• new ClassName() works only local. It cant
  create remote objects.
• Who creates remote objects?
• How do clients get access to remote objects?

And last but not least what is a remote object?
7
The Broker Pattern
A broker introduces and mediates communication
between de-coupled entities. (diagram from
http//www.eli.sdsu.edu/courses/spring04/cs635/)
8
Remote Objects
Object Model And Types
Remote Object
Interface
Implementation
Systemwide Identity
A servant that need not be an object
Object Reference
Public Methods
A remote object is the combination of system-wide
unique identity, interface and implementation
with the special twist that clients KNOW the
interface, USE the identity but do NOT KNOW about
the implementation. To clients, the interface IS
the implementation.
9
Interface Definition Language (IDL)
Module Count interface Count attribute
long sum long increment()
From Orfali, Harkey, Client/Server Programming
with Java and CORBA
CORBAs way to specify language independent
remote objects. An interface is part of a type.
It describes the externally visible part of an
object. A class implements a type (and its
interface). Please note CORBA has no notion of a
class!
10
Object Model and Type System
CORBA
Java-RMI

• Basic Types sequence, string, array, record,
  enumerated, union
• Value Objects
• Remote Object References

• Basic Types of language (int, byte etc.)
• Serializable non-remote Objects
• Remote Object References

To achieve language independence, CORBA defines
its own types. Nothing else can show up in the
interfaces of remote objects. Especially no user
defined classes. Only compositions of basic types
and the OR. Note that Java-RMI allows classes if
they are serializable!
11
Interface Design

• Respect the possibility of concurrent calls in
  your interface design Do not keep state across
  method calls.
• Do not perform staged initialization e.g. the
  infamous half-baked object anti-pattern
  (B.Scheffold).
• Dont use complicated or unclear orders of calls
  for your interface (what comes first? Shake hands
  with the king or kiss the queens hand?)

Have a look at Mowbray, Malveau, Corba design
patterns. The patterns are important for other
object based middleware too.
12
Construction of an Remote Object Reference
Host,port,protcocol Object adapter, object ID,
OID10xffee OID2.,
Active Object Map (remote object table)
Create unique OID
Create system-wide object reference
Object Implementation (Servant)
Object Adapter
Object Request Handler (ORB)
Register OID
Register memory address
Memory address 0xffee
Map objectname with address
The new object reference can be marshaled and
sent to clients. This reference is NOT the
physical address of the object implementation!
13
Structure of an remote Object Reference
Host, port, protocol information
Object Adapter, Object ID (key)
Fault tolerance information additional hosts etc.
Activation Information
To achieve interoperability, all participants
(Object Request Brokers) need to use the same
format!
14
CORBA Remote Object Reference

• The organization of an IOR with specific
  information for IIOP. (from van Steen, Tanenbaum)

15
Direct Registration of an Remote Object Reference
Remote Object table
Server process
Object Implementation (Servant)
Object Adapter Interface
OID10xffee OID2.,
In direct mode, before clients can bind, somebody
has to start the server process which registers
itself with the object adapter and ORB. The
servant consumes memory resources! The servants
address exists before the remote object address
is built! The object reference points directly at
an activated servant!
16
Indirect bind of an Remote Object Reference
Remote Object table
Servant INSTALLATION process
Register objects For later activation
Object Adapter Interface
OID1TBD
In indirect mode, somebody has to start the
registration process to generate an OID. This OID
does NOT point to a running servant. Instead, the
generated Object Reference points to an
implementation repository. Object stores e.g.
are registered this way.
17
Indirect activation of a Remote Object Reference
OR1 OA server file host, port process mode
Client activation OR
Lookup servant file
Implementation repository
Client redirected OR
Start
Send back redircect OR
Servant process
Connect to servant
In indirect mode, the client uses an OR that
points to an implementation repository. When
the client binds, the repository starts the
requested servant and returns its real OR. This
is then used by the client to connect directly to
the servant. (Details are implementation
specific, see MIKO ORB in resources.
18
How do clients get access to remote objects?

• A Naming Service (like a directory)
• A web server (serialized OR)
• Via mail or a piece of paper
• From another remote object which servers as a
  Factory.

This really is the question where do clients
get the Remote Object Reference for a remote
object from?
19
Static Invocation
Remote object Interface Definiton
Compiled into stub and skeleton
client
stub
skeleton
servant
Client host
Servant host
Stubs may be statically linked or dynamically
downloaded. Clients KNOW the remote object
interface IN ADVANCE of the use!
20
Dynamic Invocation
Remote object Interface Definition (e.g from
Interface Repository)
Request object built from meta-information
client
Request Object
Dispatcher (DSI)
servant
Client host
Servant host
Clients fill in a request object (built from
meta-information of the remote object) and send
it to a dispatcher on the servant host. The
servant does not know that the request was
dynamically built.
21
Asynchronous Invocations

• Most invocations are synchronous, the client
  waits for the results from the servant. Three
  asynchronous types are frequenty used
• one-way calls (they cannot have return values or
  out parameters. Delivery guarantee is
  best-effort.
• Deferred synchronous (client continues and later
  checks for results (blocking). At-most-once
  delivery.
• True asynchronous with server callbacks (server
  sees difference between sync. And async. Calls)
  Needs messaging middleware to achieve
  at-most-once delivery guarantees.

It depends on the implementation whether calls
are really asynchronous (the client disconnects
and the server later on builds a new connection
to the client) or simulated (client continues but
one client thread blocks waiting for the
synchronous response from the server (In this
case the server does not see a difference between
sync. And async. Calls)
22
CORBA System Architecture
The orb interface solves bootstrap problems (e.g.
where to get initial object references) and
string2object/object2string conversions. (from
van Steen, Tanenbaum). Not shown Interface
Repository, Naming Service etc.
23
Main Distributed Object Services

• Finding Objects
• Naming service (maps names to references),
• Trading service (object offer services, clients
  search by constraint)
• Preserving Object State
• Persistence service to store object state
  transparently (and load it on demand)
• Transaction Service preserve object consistence
  across changes (several objects, distributed,
  nested or flat)
• Concurrency Service provide locks for shared
  objects
• Grouping of Objects

Please read van Steen/ Tanenbaum Chapter 9 for
next session!
24
Services vs. Frameworks
Transaction service
object
Framework
Persistence Service
Security Service
Transaction service
Security Service
object
Persistence Service
Licensing Service
Licensing Service
Service based code turned out to be less
re-usable as expected. By letting the framework
call services, objects dont need to know WHAT
services to call or WHEN! (see OMGs Business
System Application Architecture BSAA for a
detailed explanation). Transparency taken even
further!)
25
Portable Interceptors 1
By intercepting calls additional (context)
information can be added and transported
transparently between ORBs. The original protocol
already knows security and transaction contexts
but applications can define custom context
information. The same technique is used in
servlet filters, Aspect Oriented Programming etc.
Diagram from Marchetti et.al, see resources)
26
Portable Interceptors 2
two ways to realize interception and call
extension. Note that interceptors need to have
access to the original call information and that
subtle ordering problems can occur. Application
Servers use this method e.g. to realize
delegation of security information to
backends.(from Marchetti et.al, see resources)
27
Beyond Replicated Data

• Replicated Objects (data plus computation) for
  collaborative Worlds Croquet
• Delayed asynchronous transparent remoting
  Promises in E

The usual proxy/stub pattern is not the only way
to realize distributed objects. Croquet avoids
the master approach of traditional C/S systems
and replicates an object across machines. Not
only data but also computations are replicated.
E allows remote objects to be handled in a
delayed way which optimizes roundtrip times and
makes the API easier. No special multithreading
needed.
28
What is Croquet?
Imagine you are a graduate student in astronomy
asked to demonstrate your knowledge of Keplers
Laws. You launch a software application on your
computer and enter a three-dimensional online
world. Inside this environment, you use the
drop-down menu to quickly design and deploy a
dynamic simulation of the solar system. As your
simulation runs, you see your professor enter the
lab and move in for a closer look. Your professor
downloads a file from his own hard drive into the
virtual laboratory and it appears inside a
display window he just created with a click of
the mouse. Remarkably, you and your professor are
now able to see one another make additions and
changes to the same document, all the while
keeping up a steady banter with the help of
network-enabled telephony built into the software
system. Your professor is impressed by your work
and so he invites his entire introductory
astronomy class to a viewing and discussion of
your simulation. From across campus, hundreds of
students gather inside the virtual lab. The
instructors video image (captured by the web
camera on his laptop) is visible to the groups of
students he guides through the demonstration.
Classmates wander among the planets, adjusting
the timing and motion of the celestial machinery,
talking with one another over network-enabled
telephony, gaining an unprecedented appreciation
for Keplers laws in action.
M.Lombardi, Standing on a Plateau..
29
Replicated Collaborative Objects and Activities
User portals are shared (replicated) across
machines. (Alan Kay et.al, Croquet A
collaboration system)
30
Teatime
Teatime is the distributed objects framework
within Croquet. It provides replication of
behavior, synchronization etc.
31
Key Elements and Assumptions

• A coordinated universal timebase embedded in
  communications protocol
• Replicated, versioned objects - unifying
  replicated computation and distribution of
  results
• Replication strategies - that separate the
  mechanisms of replication from the behavioral
  semantics of objects
• Deadline-based scheduling extended with failure
  and nesting
• A coordinated distributed two-phase commit that
  is used to control the progression of
  computations at multiple sites, to provide
  resilience, deterministic results, and adaptation
  to available resources. Uses distributed sets
• Low latency network
• local rendering and massive computing power

From Croquet Architecture and David P.Reeds
presentation (see ressources)
32
World Structure
Event distribution needs to be carefully
minimized.
33
Routers, Controllers, Time based Replication
Islands are replicated. Controllers interface
Islands with Routers. (From Croquet Programmers
Guide, see Ressources)
34
Secure Distributed Objects E

• Capability based distributed computing
• VATs as runtime containers
• Promises as delayed references

See www.erights.org for a tutorial and further
information.
35
Object Capabilities
References ARE the ONLY way to get authority.
Mechanisms include parenthood, initial
conditions, conversation, endowment (see
erights.org)
36
VAT as Runtime Container
From Stefan Reich, Escape from multithreaded
hell (ressources)
37
References in E
References can be created and handled without the
need to have them resolved or calculated right
away. They can be communicated as well. Language
statements allow synchronization points to be
defined. At those points programs need to wait
for e.g. remote calculations to finish. Results
are simply represented as promises as well (data
flow).
38
Remote Pipes with Promises
B represents a promise to a future result and is
already forwarded to X this saves a roundtrip
from VatL to get the result from Y and formward
it to X
39
Back to the Basics
Example Java Remote Method Invocation (RMI)
40
Java Remote Method Invocation (RMI)

• Architecture
• Request/reply protocol
• External data representation
• Parameter passing conventions
• Stub/Skeleton generation
• Important classes and tools
• Remote Object Registration
• Remote Object Activation
• Object finding/client bootstrap
• Garbage Collection
• Specials

41
Java-RMI System Architecture
Remote interface
client
servant
Tooling Rmic compiler
stub
Skele ton
Activator
Registry
RMI Runtime (rmiregistry, rmid)
Java VM
Java VM
OS
OS
42
Java RMI Request/Reply Protocols (1)

• JRMP first, totally incompatible protocol for
  RMI.
• Bandwidth problems due to distributed garbage
  collection with short term leases and permanent
  reference counting
• Dynamic download of code

If you want to understand garbage collection
read Paul Wilsons seminal paper on GC (see
resources)
43
Java RMI Request/Reply Protocols (2)

• RMI-IIOP RMI over CORBAs Internet Inter-Orb
  Protocol
• uses Java Naming and Directory Interfaces (JNDI)
  to lookup object references (EJB etc. all use it
  too). Persistent!
• Requires code changes PortableRemoteObject
• Need to generate code for IIOP (rmic iiop xxxxx)
• Need to generate IDL file(s) for CORBA systems
  (rmic idl JavaInterfaceName (Interface!!)
• Code shipping?

Advantage Move the idl file of your Java Remote
Object Interface to a CORBA system, generate the
CORBA stub with its IDL compiler and now the
CORBA system can call your remote object. Or call
into CORBA systems by yourself.
44
Java RMI External Data Representation
Who cares? Java RMI is only between Java objects
and the virtual machine protects applications and
middleware from hardware differences!
client
client
RMI layer
RMI layer
Java VM
Java VM
The Java VM hides the differences in hardware and
OS. A concept widely used e.g. in IBM
OS
OS
Hardware
Hardware
45
Java RMI parameter passing rules
Note that CORBA e.g. does not support non-remote
serialized objects at all! (New value objects?)
46
Java RMI Stub/Skeleton Generation

• RMI connects implementations, not interfaces
  you must run the stub generator (rmic) on the
  implementation class!
• Stubs can be dynamically downloaded from the
  registry or from a web-server
• Skeletons are generated dynamically on the
  server side using reflection. (need to learn
  about meta-object protocols and reflection? Read
  Gregor Kiczales, Andreas Paepcke Open
  Implementations and Metaobject Protocols. A free
  and very easy tutorial available on the web)

What happens if you downloaded a stub to a client
and it gets changed afterwards?
47
Java RMI Important Classes and Tools
Remote Object Interfaces extend this class (tag
interface)
Remote
RemoteException
All Remote Object methods throw this class
Clients use it to find remote object references,
Servers register their objects with it.
Naming
UnicastRemoteObject
Remote Object Implementations extend it
rmic
Stub/skeleton/idl file generator
registry
Simple name server for java objects
48
Java Remote Interface Example
package soccer interface Team extends Remote
public String name() throws RemoteException
Trainer coached_by() throws RemoteException
Club belongs_to() throws RemoteException
Players players() throws RemoteException void
bookGoalies(Date d) throws RemoteException void
print() throws RemoteException
From W.Emmerich
49
Java RMI Activation
Java VM
Stub
Java VM
2
1
2 create object
Faulting
in VM
Reference
Live
Activa-
3 pass
ref
tion ID
object ref
AG
AG
1
2
Activator
1 activate
Activation Descriptors
ActGroup

ClassName

URL

Init
AG
Team
www.bvb.de/
1
AG
Player
www.bvb.de/
2
AG
Player
www.bvb.de/
2
4 update
AG
Player
www.bvb.de/
2
live ref
Client Host
Host
www.bvb.de
From W. Emmerich, Engineering Distributed Objects
50
Resources

• Van Steen, Tanenbaum Chapter 9 (slides plus pdf
  from http//www.prenhall.com/divisions/esm/app/au
  thor_tanenbaum/custom/dist_sys_1e/
• Middleware für verteilte Systeme (MIKO ORB) mit
  Source Code. (dpunkt verlag hat noch ein Buch
  direkt zum MIKO angekündigt.
• Orfali/Harkey, Client/Server Programming with
  Java and CORBA (covers RMI as well, very good
  reading with lots of code by the fathers of C/S
  computing)
• Paul Wilson, Garbage Collection
• Gregor Kiczales, Andreas Paepcke Open
  Implementations and Metaobject Protocols. A free
  and very easy tutorial available on the web about
  reflection etc.)
• CORBA Request Portable Interceptors A
  Performance Analysis C. Marchetti, L. Verde and
  R. Baldoni

51
Resources

• Stefan Reich, Escape from Multi-threaded Hell
  http//www.drjava.de/e-presentation/html-english/i
  mg0.html (good intro to event-loops and E)
• www.erights.org Portal to all things E a
  secure, distributed object communication language
  with delayed references and capabilities

52
Resources

• www.opencroquet.org Portal to all things Croquet,
  a behavior sharing object replication plattform
  designed for collaboration
• Doug Lead, Design for open Systems in Java
  http//gee.cs.oswego.edu/dl/coord/index.html
• Carl Hewitt's seminal paper The Challenge of Open
  Systems (http//citeseer.nj.nec.com/context/221753
  /0) explains the constraints of large scale
  mutually suspicious radically distributed
  systems.

53
Resources

• David A. Smith, Croquet Programming (guide)
  www.opencroquet.org
• David P. Reed, Teatime Framework Design
  (presentation) www.opencroquet.org