1. Java Distributed Computing Technology Ernie Cohen Telcordia Technologies

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

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

4. Outline Java background: serialization, meta- programming, security, naming RMI, Voyager, JMS Java Beans Servlets and EJB Jini

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

6. Serialization Caveats threads not serializable no easy way to checkpoint only one class of client serialized objects do not include their classes

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

8. 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)

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

10. Glue RMI Voyager JMS

11. 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?

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

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

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

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

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

17. 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,…

18. 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)

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

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

21. Java Beans

22. 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 reflection BeanInfo optional ingredients: events, properties, methods, property editors, customizers, descriptors

23. Bean Events class ev {…} interface evListener { public void evOccur( ); } 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); }

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

25. 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 + descriptor BeanContext allows beans to publish a service, find a service, list all services suitable only for local contexts

26. Enterprise Technology Enterprise Architecture Containers Applets Servlets/JSP EJB Jini

27. Enterprise Architecture

28. Containers provide a warm context for an object to run in –value-added services –lifecycle management –security –management late, declarative deployment choices

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

30. Applets Java programs that run in the browser container: AppletContext –access to applets on the same page –server authentication

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

32. Servlet deployment map URLs to applications map identities to principals and roles configure security error handling component parameters initialization: where, when, how many

33. 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)

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

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

36. 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)

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

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

39. EJB Security principals mapped to roles (groups) deployment descriptors say which roles can call which methods programmatic security also available: getCallerPrincipal isCallerInRole(roleName) security contexts can pass between mutually trusting servers/components

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

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

42. Jini Distributed events (via RMI) single registration-callback interface asynchronous, unreliable event notification subscriptions are leased limited callback interface

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