Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Distributed Applications in Java and Introduction to Enterprise Java Beans Michael Factor [email protected] IBM Labs in Haifa IBM Labs in Haifa Outline Distributed Applications in Java Introduction to Distributed Computing Java Object Serialization Java Remote Method Invocation (RMI) Introduction to Enterprise Java Beans (EJB) Architecture Types of EJBs Enterprise Attributes Putting it all Together Introduction to Distributed Computing IBM Labs in Haifa IBM Labs in Haifa Basic Concepts Client-Server: The client is the entity accessing the remote resource and the server provides access to the resource. Operationally, the client is the caller and the server is the callee. In Java terms: The client is the invoker of the method and the server is the object implementing the method. IBM Labs in Haifa Basic Concepts (continued) The client and the server can be heterogeneous: Different implementation languages Different operating systems The roles can be transient The definition is with respect to a particular interaction. Client and Server refer both to the code and the system on which the code is running IBM Labs in Haifa Client Server Interactions Client Server 2 y= F(x) 1 1. 2. 3. 4. Send message to call F with parameter X Receive message that F was called with the given parameter Send message with the result of calling F Receive message with the result of calling F 3 4 Network F(x) { return 5; } IBM Labs in Haifa Finding the Server How does the client find a server? One approach is a Name Service: Associate a name with each server When server starts, it registers with a naming service using the name When the client wants to find the server, it asks the naming service Naming service can itself be a server How does the client find the naming server? IBM Labs in Haifa Naming Services Name Server Client Server 1 2 4 y= F(x) F(x) { return 5; } 3 5 6 Network 1. 2. 3. 4. 5. 6. Register "F" with name server Lookup "F" using name server Send message to call F with parameter X Receive message that F was called with the give parameter Send message with the result of calling F Receive message with the result of calling F IBM Labs in Haifa Parameter Passing Distribution complicates parameters passing Parameters are passed via a message and not via a local stack Issues include: Different representations of primitive types convert representation Pointers are address space relative Composite Types (e.g., structures) embedded pointers need to be flattened and reconstructed IBM Labs in Haifa Marshaling/Unmarshaling Marshaling: done by client (i.e., caller) packing the parameters into a message flatten structures (e.g., objects) perform representation conversions if necessary also done by server (i.e., callee) for results Unmarshaling: done by receiver of message to extract parameters IBM Labs in Haifa Parameter Passing Flow Client Server y= F(x) 1. 2. Marshal X Send Msg 3. 4. F(x) { return 5; } Network 5. 6. 7. 8. Receive Msg w/ Result Unmarshal Result Receive Msg Unmarshal X Marshal Result Send Msg w/ Result IBM Labs in Haifa Stubs and Skeletons Encapsulate marshaling and communication Enable application code in both client and server to treat call as local Stub is on the client implements original interface contains information to find the server in an OO language, the stub object is a proxy for the real object Skeleton is on the server calls original routine IBM Labs in Haifa Stubs and Skeletons: Flow Client Server F(x) { // stub 1. 2. Marshall X Send Msg F_skeleton() { Network 3. 4. 5. 6. 7. } 8. 9. } Receive Result Msg Unmarshal Result Receive Msg Unmarshal X Call F(X) Marshal Result Send Msg w/ Result IBM Labs in Haifa Where do Stubs and Skeletons come from? Writing (un)marshaling code is bug-prone communication code has many details structure of code is very mechanical Answer: Stubs and Skeletons can be generated from a description of the code to be remotely invoked A separate Interface Definition Language (IDL) Description can be generated from code to be distributed IBM Labs in Haifa Server Architecture Servers can typically handle concurrent requests from multiple clients Typically the same address spaces provides multiple interfaces A common server architecture: accept a request (i.e., a call from a client) determine which routine is being invoked dispatch request to a thread of execution start the thread executing in the appropriate skeleton IBM Labs in Haifa Server Architecture (continued) Server Clients Dispatcher Call f_skel f Call g_skel network g g f Worker Threads Java Object Serialization IBM Labs in Haifa IBM Labs in Haifa Goals of Serialization Provide a means of writing/reading the state of an object to/from a stream Preserve inter-object relationships Enable marshaling/unmarshaling Do not require per-class implementation Allow per-class customization IBM Labs in Haifa Serialization Basic Concepts All primitive types can be saved in a stream The class of an object to be saved in a stream must implement one of: java.io.Serializable java.io.Externalizable Externalizable allows a high degree of customization Not discussed further Not all standard Java classes are serializable Classes that provided access to system resources are not serializable most of java.io.*, java.net.*, etc. IBM Labs in Haifa ObjectOutputStream java.io.ObjectOutputStream is used to save the state of an object writeObject(Object o) method on the stream which writes the indicated object to the stream traverses references to other objects referenced objects must also be serializable in event of a cycle an object is only written to stream once default does not write static or transient data write<Type>(<Type> t) methods support writing primitives to stream IBM Labs in Haifa Traversing The Graph writeObject(A) ==> succeeds A writeObject(B) ==> throws java.io.NotSerializableException: java.lang.Thread B java.util.Hashtable java.lang.String java.lang.Integer java.util.Hashtable java.lang.String java.lang.Thread not serializable IBM Labs in Haifa Serialization Example import java.net.*; import java.io.*; // . . . // Create the ObjectOutputStream Socket s = new Socket(host, port); ObjectOutputStream oos = new ObjectOutputStream(s.getOutputStream()); // Call writeObject on the Stream to write a Date object oos.writeObject(new java.util.Date()); // Call writeInt to write an int oos.writeInt(3); IBM Labs in Haifa ObjectInputStreams java.io.ObjectInputStream is used to restore the state of an object readObject() returns next object in the stream creates a new object graph structurally equivalent to the graph that was originally written to the stream objects in graph are distinct from original graph, i.e., don't compare ==. Java Remote Method Invocation (RMI) IBM Labs in Haifa IBM Labs in Haifa What is RMI? Java Remote Method Invocation is a mechanism that allows calls between objects in different JVMs Basic concepts: Remote Interface defines the methods that a client can invoke on a server Remote Object an object whose methods can be invoked from another JVM Remote Method Invocation invoking a method of a remote interface on a remote object, i.e., interJVM call IBM Labs in Haifa RMI Running Example To motivate this discussion, we will use a simple running example of a count server. server supports a single method, getCount(), that returns the number of times it has been called client calls the method and displays the results Client Server call getCount inc. count display result IBM Labs in Haifa Remote Interface Extends java.rmi.Remote java.rmi.Remote is an empty interface Flags methods that can be called remotely Client is coded to remote interface Invoking a remote method uses normal Java syntax All methods of a remote interface must throw java.rmi.RemoteException Thrown when a remote invocation fails, e.g., a communications failure Used in generating stubs and skeletons IBM Labs in Haifa Sample Remote Interface public interface Count extends java.rmi.Remote { public int getCount() throws java.rmi.RemoteException; } Client Remote Interface Server call getCount inc. count display result IBM Labs in Haifa Remote Object Implements a remote interface Can add additional methods Typically extends (a subclass of) java.rmi.server.RemoteObject Client uses a stub to refer to remote object Never access remote object directly Client Remote Interface Server call getCount inc. count display result Remote Object IBM Labs in Haifa Sample Implementation Class public class CountImpl extends java.rmi.server.UnicastRemoteObject implements Count { private int count; public CountImpl() throws java.rmi.RemoteException { super(); count = 0; } public int getCount() throws java.rmi.RemoteException { return count++; } // . . . IBM Labs in Haifa RMI Parameter Passing There are two types of parameters to consider Remote objects, i.e., implement java.rmi.Remote Non-remote objects This applies both to inputs and return results IBM Labs in Haifa Remote Objects as Parameters The target receives a reference to the client stub implementing the remote interface Enables access to unnamed remote objects Client creates a remote object and passes it as a parameter on a remote method Server returns a remote object as the result of a remote method Enables peers and not just client-server Client invokes a remote method, passing a remote object that it implements as a parameter When server invokes a method on this parameter it is using a client stub, this results in a callback to original client IBM Labs in Haifa Passing Non-Remote Objects as Parameters Objects are passed by value A copy of object is sent to the server Java Object Serialization used to copy parameters: Non-remote-object parameters of a remote interface must be Serializable Use of Serialization gives different semantics than normal Java parameter passing: given remote method: Object identity(Object o) { return o; } then: o != remote.identity(o) IBM Labs in Haifa RMI Stubs and Skeletons Stubs and skeletons are mechanically generated, e.g., by rmic (RMI Compiler) input is a class file containing a remote object, e.g., CountImpl.class output is class files for stub and skeleton for the remote object CountImpl_Stub and CountImpl_Skel optionally can keep Java source files stub class extends RemoteStub stub thus has remote semantics for equals, toString and hashCode IBM Labs in Haifa Issues We Did Not Discuss Partitioning an application Where is the dividing line between client and server Security Class Loading, Firewalls, RMI over HTTP, etc. Remote Object Activation Socket Factories RMI Runtime Architecture Distributed Garbage Collection Class Loading RMIClassLoader JavaIDL Mapping of Java to CORBA IDL IBM Labs in Haifa RMI's Strengths Relatively easy to develop a distributed application But harder than a non-distributed application No need to learn a separate language or object model But need to learn subtle differences A pure Java solution "Write Once, Run Anywhere" IBM Labs in Haifa RMI's Weaknesses Loss of object identity If an object is passed by value, a new copy of the object is created Performance If one is not very careful, the use of serialization can result in sending very large messages Potential for Deadlock if Callbacks are used System A makes a remote call to system B B makes a callback to A The thread that will process the callback in A is not the thread that made the original call to B If A was holding a lock when it made the initial call, deadlock may result. Introduction to EJBs IBM Labs in Haifa IBM Labs in Haifa Enterprise Java Beans: Components and Containers An Enterprise Java Bean (EJB) is a component the provides reusable business logic functionality and/or a representation of a persistent business entity An EJB Container executes an EJB due to a client request. Provides the plumbing necessary to execute the EJB including non-business logic related functionality such as transactions, security, concurrency, remote access, etc. life cycle functions, e.g., creating, destroying, etc. Client uses an interface to access the Bean indirectly A deployment descriptor describes the structure of the Bean and how to execute the Bean as part of an application IBM Labs in Haifa Architecture Client Container Method invocation Client Interface Method Delegation TX support Security Persistence ... Bean Instance IBM Labs in Haifa EJB Roles Bean Provider Produces a component of reusable business logic in an ejb-jar file Application Assembler Combines multiple beans into an application described by a deployment descriptor Deployer Customizes the application for a specific server/container E.g., map security roles defined in deployment descriptor to real users Server and Container Provider Provides the tools to allow deploying an application and the runtime support to execute the application according to the deployment descriptor System Administrator IBM Labs in Haifa Local vs. Remote Interfaces Entity and Session Beans can support local and remote interfaces Client is written to a specific interface Interface(s) supported is not transparent to Bean provider Local interface Not location independent Client and EJB run in the same JVM Example: A Bean always accessed by other Beans Parameter passing is by reference (same as standard Java) Supports fine grained access Remote interface Location independent Parameters passed by value (RMI semantics) Supports coarse grain access IBM Labs in Haifa Local vs. Remote Interfaces (Continued) Reasons for Choosing Local vs. Remote Access Type of client If client is always a Web Component or another EJB, choose local Coupling If tightly coupled, choose local Scalability requirements If strong scalability requirements, choose remote IBM Labs in Haifa EJB Interfaces Home Interface Can be viewed as a collection of Beans Lifecycle functions, e.g., create, remove, find Home business methods Business methods that are not instance specific Component Interface Business logic Define client’s view of the Bean Client never directly access Bean instance Client finds home interface via JNDI Client uses home interface to obtain a reference to the Bean’s component interface Defined by the Bean Provider Client side implementations are generated when the Bean is deployed Delegate invocations to Bean instance IBM Labs in Haifa Architecture with Remote Interfaces Source: Enterprise JavaBeansTM Specification, Version 2.0, page 386 Types of EJBs IBM Labs in Haifa IBM Labs in Haifa Types of Beans Session Client and application logic focus Entity Persistent data focus Message Asynchronous message processing IBM Labs in Haifa Session Beans Executes on behalf of a single client Focus on functionality, application logic and application state May be transaction aware May access shared data in an underlying DB but does not directly represent this shared data Is relatively short-lived Is removed when the EJB Container crashes Typically have state maintained across multiple requests from the same client Stateless session beans are a special case IBM Labs in Haifa How a Client Uses a Session Bean JNDI Server Container Client Home Bean Instance Component IBM Labs in Haifa Stateless Session Beans Not tied to any particular client Can use instance variables only if they are not client related All Stateless Session Beans are equivalent A container can choose To serve the same instance of a Bean to multiple clients To serve difference Bean instances to the same client at different times A container may maintain a pool of Stateless Session Beans No necessary relation between when a client creates the Bean and when the Container creates the Bean Provide very high scalability IBM Labs in Haifa Stateful Session Beans Assigned to a particular client Maintain per client state across multiple client requests May be “passivated” – allows a degree of pooling The container serializes the state of a Bean non currently being used and writes state to secondary storage Frees JVM resources held for Bean When a new request arrives for Bean, it must be activated State read from secondary storage and deserialized Can only passivate a Bean if it is not in a transaction More on transactions later IBM Labs in Haifa Lifecycle of a Stateful Session Bean Container Perspective create Does Not Exist passivate Ready remove activate start transaction commit or rollback In Transaction timeout Passive IBM Labs in Haifa Entity Beans Represent persistent data Typically represent a row from a database Can also represent entities implemented by legacy applications Can be shared across multiple users Long lived Lifetime is tied to life of data and not to a particular client Entity objects (not Beans) can be created outside of a Container, e.g., from a pre-existing database. Data persistence can managed either by Bean or Container Client can either create a new Entity Bean of find an existing Bean Home interface provides finder methods findByPrimaryKey – unique key within a home Application specific finder methods IBM Labs in Haifa Persistence Two kinds Bean Managed Programmatic Container Managed Declarative Bean Managed Bean provider must write routines to access the data store Declares instance variables to contain the persistent data Finder method implementation written by Bean provider Container invokes these routines at an appropriate times in lifecycle More common when underlying store is an application IBM Labs in Haifa Persistence (Continued) Container Managed Allows Bean to be logically independent of data source e.g., same code for relational database, IMS database, etc. Container generates code to access the data store Deployer maps the fields of the Bean to the columns of the database Bean provider describes Bean’s fields and relationships to other Beans in deployment descriptor Container may use lazy access methods and caching Finder methods are described in the deployment descriptor Description is in EJB QL Implementation is generated when Bean is deployed Virtual fields are used in the Bean to contain the persistent data Access is via getXXX/setXXX methods. IBM Labs in Haifa Container Managed Relationships Relationship between Beans Similar to foreign keys in relational databases Types of relationships One to one Many to one One to Many Many to Many Allows container to ensure referential integrity e.g., setting a Bean in field for a one to one relationship will atomically remove the Bean from a prior relationship IBM Labs in Haifa EJB QL A query language Similar to a subset of SQL Used in the deployment descriptor to describe the behavior of finder (and other) methods for Beans with Container Managed Persistence IBM Labs in Haifa Entity Beans and Database Tables Order Bean Table 1 Customer Key: Customer ID * Order Bean 1 Key: Order ID Customer ID Product ID 1 Product Key: Product ID 1 Invoice Order ID 1 3 Customer ID Product ID 76 9 2 1212 Invoice Table Invoice ID 1001 1003 Order ID 1 3 ... Key: Invoice ID Order ID Customer Table Customer ID Orders 76 1 1002 2 Address . . . ... IBM Labs in Haifa Message Beans Executes upon receipt of a client JMS message Asynchronous No return value Stateless and short lived May access persistent data but does not represent persistent data Not tied to a client A single Message Bean can process messages from multiple clients Has neither Home nor Component interface Client Destination Msg Bean Msg Bean Instance Msg Bean Instance Instance Enterprise Attributes IBM Labs in Haifa IBM Labs in Haifa Transactions Ensure all-or-nothing semantics In EJB only addresses persistent data Application code required to rollback changes in application variables Either Bean or Container Managed Transaction Demarcation Bean Managed Explicit use of the Java Transaction API by the Bean Container Managed Completely declarative in deployment descriptor Container invokes business method in specified scope Entity Beans must use Container Managed transactions Session and Message Beans may use Bean Managed Clients can also establish transactional scope IBM Labs in Haifa Transaction Attributes Associated with methods in deployment descriptor Specifies how container manages transaction when client invokes a method Types of attributes NotSupported Method never called within a transaction Container suspends client context if it exists Required Runs in client’s context if it exists otherwise Container create a new context Used for a method that requires transaction, but can participate in a broader unit of work Example: depositing money in an account Can be atomic by itself or part of a greater transaction involving other operations IBM Labs in Haifa Transaction Attributes (Continued) Supports Uses client’s context if it exists otherwise runs without a context Needs to be used with caution RequiresNew Container always runs the method in a new transaction Useful for work that commits regardless of results of outer unit of work Mandatory Client must invoke the method from within a transaction Container uses this context Never Client must not invoke the method from within a transaction Container does not provide transaction context IBM Labs in Haifa Security Transport Secure Socket Layer Transport Layer Security Application assembler and deployer specify security in deployment descriptor Security Roles Logical roles defined by application assembler Mapped to principles by deployer Method Permissions Set of methods that can be invoked by a security role Run-as Specifies identity (security role) a Bean uses when it calls other EJBs Putting it All Together IBM Labs in Haifa IBM Labs in Haifa Deployment Descriptor Captures declarative information Well-formed XML Contains Structural information Name of Bean, class, interfaces, Bean type, persistence type, container managed fields, . . . Not all combinations of structural information make sense Application assembly information Security roles, method permissions, transaction attributes, etc. IBM Labs in Haifa ejb-jar Standard format for packaging enterprise Beans Contains Deployment descriptor Class files Bean Interfaces . . . Does not contain subs generated by container ejb-client jar Jar file for client visible files IBM Labs in Haifa Making This More Real – 8 Steps Trivial stateless Session bean, that prints on server console: outputError(String s); To implement a bean, you (or tools!!) need to: Specify (not implement) the Remote interface Specify (not implement) the Home interface Specify (and implement!) the Bean’s Implementation class Compile the above Create a Deployment Descriptor, in this case a Session Descriptor for a Session bean Create a Manifest/EJB-jar file Run the deployment tool, which processes the ejb-jar file and processes and stores the code, etc Start the server. Develop the client (no different than any other client...) IBM Labs in Haifa Items not covered APIs Interoperability between servers Relationship to CORBA IBM Labs in Haifa Specifications RMI: http://java.sun.com/j2se/1.4.1/docs/guide/rmi/index.html Serialization: http://java.sun.com/j2se/1.4.1/docs/guide/serialization/index.html EJB ftp://ftp.java.sun.com/pub/ejb/947q9tbb/ejb-2_0-fr2-spec.pdf Backup IBM Labs in Haifa IBM Labs in Haifa RemoteObject Hierarchy RemoteObject provides basic remote object semantics redefines equals, hashCode and toString Client extends RemoteStub remote object semantics of stubs Server extends RemoteServer abstract server extends run-time UnicastRemoteObject access to concrete RMI server run-time for singleton, nonpersistent, remote objects this is the class remote objects typically extend All classes in package java.rmi.server IBM Labs in Haifa A Remote Object Implementation Implements remote interface(s) Can add additional methods If does not extend UnicastRemoteObject must redefine equals, hashCode and toString must explicitly tell RMI run-time about object UnicastRemoteObject.exportObject(Object o) Client never uses implementation class IBM Labs in Haifa Remote Objects as Parameters: An Example Remote Interface B Remote Interface A int g() int f(Remote b) System B AInterface a; a.f(new B()); System A Client Stub A Marshal B as a Stub Remote Object A f(Remote b) { b.g() } Remote Object B Client Stub B IBM Labs in Haifa RMI Stubs and Skeletons Example Portion of machine generated CountImpl_Stub public final class CountImpl_Stub extends java.rmi.server.RemoteStub implements Count, java.rmi.Remote { // Removed lots of code public int getCount() throws java.rmi.RemoteException { // Removed the code to make the call int $result; try { java.io.ObjectInput in = call.getInputStream(); $result = in.readInt(); } catch (java.io.IOException ex) { throw new java.rmi.UnmarshalException("Error unmarshaling return", ex); // Removed Additional Error Handling Code } return $result; } IBM Labs in Haifa Characteristics of EJBs Contain business logic that operates on enterprise’s data Bean provider defines a client view Client view is independent of of the container in which the bean is deployed Beans are created and managed at runtime by a Container which mediates client access Client never directly accesses the Bean Since container involved in path between client and Bean instance it can implement pragmatics and lifecycle functions If Bean uses only services defined by EJB Spec., it can be deployed in any compliant Container Specialized containers with extended functionality can be defined Can be assembled into an application without requiring source code IBM Labs in Haifa EJB Goals For Bean Provider, Application Assembler and Deployer Simplicity Productivity Reuse Merchant market for components Enterprise qualities Distribution Integrity Security Transactions . . .