Java Distributed Computing Technology

1. Java Distributed Computing Technology Ernie Cohen Telcordia Technologies

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

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

23. Bean Events class 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); } }

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