1 / 43

Java Distributed Computing Technology

Java Distributed Computing Technology. Ernie Cohen Telcordia Technologies. 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?

wandabailey
Download Presentation

Java Distributed Computing Technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related