Java Distributed Computing Technology

Ernie Cohen

Telcordia Technologies

• what people are using today to build distributed systems in Java– largely industry consensus, hence representative

• typical engineering issue: what should be transparent to whom?– distribution, failures, replication, security, failover, …

• things to keep in mind– rocket science in systems rarely makes money

– most software is unreliable

– systems that do nothing can be arbitrarily complex

– COTS technology is often false economy

Subject

Technology du Jure

• at-most-once RPC – initiator recovery preferred

• reliable asynchronous messaging– often managed by workflow systems

• transactions only when necessary• leases to avoid resource leaks• warm/hot standby for high availability

– virtual host clusters an easy database solution

Outline

• Java background: serialization, meta-programming, security, naming

• RMI, Voyager, JMS

• Java Beans

• Servlets and EJB

• Jini

Object Serialization

• built-in marshaling for object structures• object stream – objects in/out, bytes out/in

– replaces repeated objects with references (preserves graph structure)

– includes object class info (but not the bytecode)

• reconstruction: load the class, invoke no-arg ctor; adjust fields

• customizable on a per-class basis

Serialization Caveats

• threads not serializable

• no easy way to checkpoint

• only one class of client

• serialized objects do not include their classes

Meta-programming

• reflection allows programs to access public members of an object– helps avoid method proliferation

• dynamic class loading allows new classes to be created on the fly– requires a small assembler (built into JDK1.3)– easy dynamic proxy construction

Java Security

• each class is “signed” by a set of principals• principals are granted permissions, which they can explicitly

invoke• access control algorithm:

for each frame in the call stack (working backward) {if caller unpermitted, throw an AccessControlException;if caller privileged, allow the access;

} allow the access

• JAAS allows access decision to be based also on the “effective user” (w. pluggable authentication)

JNDI

• uniform Java interface to many different naming services

• directories map names to objects + attributes• basic service: take a directory and find objects

with suitable attributes• JNDI vs. JDBC:

– no transactions– no joins– simpler federation

Glue

• RMI

• Voyager

• JMS

Remote References

• ordinary Java references point to entities within the same VM

• remote references can refer to objects in other VMs (includes URL, port and object id)

• using remote references exclusively makes transparent distribution easy but expensive

• question: when to pass by copy?

Remote Method Invocation (RMI)• RPC with objects as arguments• remote object interfaces

– must extend java.rmi.Remote (marker)– each remote method must throw java.rmi.RemoteException

• basic operation:– java.rmi.Remote object ob created in server VM– ob is exported (e.g., UnicastRemoteObject.export(ob) )– server creates stub to ob and relays it to the client– when a call is made to the stub, it marshals the arguments and sends them to

them to a server for ob

– RMI server unmarshals arguments, calls requested method on ob, marshals result and returns it to the stub

– stub unmarshals result and returns it to the caller

Marshalling

• uses object serialization• one stream (in each direction) per method call• stream replaces java.rmi.Remote objects with stubs

thereto• stream adds URLs of class files for included

objects • RMISecurityManager allows remote classes to be

retrieved; otherwise, they must be on the local classpath

• stubs generated by rmic compiler (for now)• transports: socket, HTTP, HTTP forwarding,

IIOP• lazy deserialization useful for objects not likely

to be referenced (could be made transparent)• callbacks to applets• RMIRegistry• custom stubs

RMI Caveats

• remote calls may be executed in a separate thread (can introduce new deadlocks)

• no coherence across repeated calls• distributed garbage collection (leased reference

counting); objects can disappear or leak• remote object implementations override equals to

object identity • implementing mobility requires a hack• security

Object activation

• idea: allow exported objects to be brought into a VM on demand

• implementation: remote reference to activatable object includes reference to a server that can recreate the object (in an appropriate VM)

• programmer responsible for persistence• also useful for fault tolerance

Voyager

• RMI alternative from ObjectSpace• ORB with transparent object mobility• in-band class loading• any interface can be remoted dynamically

(RemoteException unchecked)• explicit stubs (generated on-the-fly)• additional goodies: asynchronous messaging,

broadcast groups, applet-to-applet forwarding,…

Object Mobility

• block incoming calls and wait for synchronized methods to complete

• marshall the object and send it to the target• reconstruct the object on the target, loading any

missing classes that might be needed• add a forwarding pointer to the source registry• remove registry reference to the local object and

unblock its calls (from ordinary references)

JMS

• interface for asynchronous message delivery– provides batching, reliability, distribution, load

balancing, timeouts, priorities, transactions

• point-to-point or Pub Sub (flat topics)

• FIFO delivery within a sessions

• no fancy orderings

Other Communication Options

• Java Spaces– tuple spaces with typed templates and Java

objects for entries– leased entries– template notifications

• InfoBus– allow beans to exchange data asynchronously

without point-to-point registration

Java Beans

Java Beans

• standard architecture for java components• allows gradual specialization of a component

throughout its use cycle (developer, builder, user)– Development code discarded at the right time– Separate code and deployment issues

• design patterns allow tools to identify bean structure using reflectionBeanInfo optional

• ingredients: events, properties, methods, property editors, customizers, descriptors

Bean Eventsclass ev {…}interface evListener {

public void evOccur(<ev>);}class Foo {

private Collection _evListeners = new ArraySet();public synchronized void addEvListener(evListener l) {_evListeners.add(l);}public synchronized void removeEvListener(evListener l) {

_evListeners.remove(l);}private void signalEv(ev event) {

List list;synchronized(this) {list= new ArraySet(_evListeners);}for (Iterator it = (list.iterator(); it.hasNext();) ((evListener) it.next()).evOccur(event);

}}

Bean Properties• T – valued property prop exposed with

public T getProp();

public void setProp(T value);

• indexed properties – add an index argument• bound properties alert listeners of changes

public void addPropertyChangeListener(PropertyChangeListener l);public void addPropertyChangeListener(String property, PropertyChangeListener l);public void addPropListener(PropertyChangeListener l);

• constrained events allow veto listeners to reject changes– veto listeners reject change by throwing PropertyVetoException

– bean polls vetoable listeners first, then propagates update

BeanContext

• idea: give a bean access to services from the surrounding environment

• protocols follow Java GUI structure – Beans cannot reside in multiple containers– Adding/removing a bean requires a global tree lock

• service described by interface + descriptorBeanContext allows beans to publish a service, find a

service, list all services

• suitable only for local contexts

Enterprise Technology

• Enterprise Architecture

• Containers

• Applets

• Servlets/JSP

• EJB

• Jini

Enterprise Architecture

Containers

• provide a warm context for an object to run in– value-added services– lifecycle management– security– management

• late, declarative deployment choices

Container Patterns

• multistep construction

• instance pooling; factories instead of ctors

• external access mediated through a façade– often requires generic services + casts

• mediating outgoing calls often requires thread hacks

Applets

• Java programs that run in the browser

• container: AppletContext – access to applets on the same page– server authentication

Servlets/JSP

• client-side connectors (typically for browsers, generating html/xml/javascript)

• faster than CGI (no process creation)• container facilities

– authentication (basic/digest/SSL/custom)– session + state tracking (URL/cookie/SSL)– protocols, MIME assembly– access control: getUserPrincipal, isUserInRole, getRemoteUser

• concurrency, distribution• JSP: server side scripts, compiled on the fly to servlets

Servlet deployment

• map URLs to applications

• map identities to principals and roles

• configure security

• error handling

• component parameters

• initialization: where, when, how many

Enterprise Java Beans• container services:

– persistance– replication– load balancing– resource pooling– transactions

• no direct thread/socket/file operations• many weird restrictions• interbean communication through RMI-IIOP (so

distribution/scaling is easy)

EJB Lifecycles

• beans are created and destroyed as needed

• home interfaces allow beans to be created/found/destroyed

• stateful beans can be passivated (outside of transactions) and later reactivated

• stateful session beans can participate in only one transaction at a time

Entity Beans

• represent long-lived business entities (“a row of a table”)

• shared between all clients

• persistent (container- or bean-managed)

• transactional (managed by container)

• home interface provides finder methods

• can be reentrant

Session Beans

• transient

• transaction aware – (bean- or container-managed)

• client-private

• single threaded (no loopback calls)

• “stateless” session beans provide common services (private transactions only)

Java Transaction API• defines how a transaction manager coordinates

transactions between applications and resources (using 2-phase commit)

• independent of component semantics• Transaction

– commit, rollback, enlist, delist, registerSynchronization,..• XAResource

– start, end, commit, rollback, prepare, …

• JTS: Java mapping of OTS; takes care of transaction context propogation between servers

Transaction support in EJB

• initiated by clients, session beans, or the container• selectable isolation levels (no dirty reads, repeatable

reads, serializable)• transactions can span EJB servers• transactions can be managed by the container or the

bean• resources use thread id to determine which transaction• deployment options (per bean/method)

– require/allow surrounding transaction– join/suspend

EJB Security

• principals mapped to roles (groups)• deployment descriptors say which roles can

call which methods• programmatic security also available:

getCallerPrincipalisCallerInRole(roleName)

• security contexts can pass between mutually trusting servers/components

Jini Goals

• allow dynamic communities of devices and services to form collaboration, without explicit management

• fault-tolerance (read: stabilizing) in face of network and device failures

• avoid explicit software installation

Jini – basic operation

• discovery: provider locates a lookup service (by broadcast) (alt: peer lookup)

• join: provider sends service object (= driver), with service parameters, to the lookup server (leased)

• lookup: Client queries lookup servers to find service (by interface/properties)

• client downloads and installs service object, and use it to talk to the server

Jini Distributed events

• (via RMI)

• single registration-callback interface

• asynchronous, unreliable event notification

• subscriptions are leased

• limited callback interface

JavaCard

• stripped-down JVM for multi-application smart cards– no threads, dynamic class loading, security

manager, goodies, …– contexts replace classLoaders– no garbage collection– object sharing– persistent/transient data; transactions