Java Distributed Computing Technology Ernie Cohen Telcordia Technologies.
-
date post
19-Dec-2015 -
Category
Documents
-
view
224 -
download
0
Transcript of Java Distributed Computing Technology Ernie Cohen Telcordia Technologies.
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