Distributed Applications in Java and Introduction to Enterprise Java Beans

1. Michael Factor factor@il.ibm.com Distributed Applications in Java andIntroduction to Enterprise Java Beans

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

3. Introduction to Distributed Computing

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

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

6. Client Server Interactions Client Server F(x) { return 5; } 2 y= F(x) 1 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 Network

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

8. Naming Services Name Server Client Server 1 2 F(x) { return 5; } 4 y= F(x) 3 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 Network

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

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

11. Parameter Passing Flow Client Server y= F(x) Marshal X Send Msg Receive Msg Unmarshal X F(x) { return 5; } Network Marshal Result Send Msg w/ Result Receive Msg w/ Result Unmarshal Result

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

13. Stubs and Skeletons: Flow Client Server F(x) { // stub Marshall X Send Msg F_skeleton() { Receive Msg Unmarshal X Call F(X) Marshal Result Send Msg w/ Result Network } Receive Result Msg Unmarshal Result }

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

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

16. Server Architecture (continued) Server Clients Dispatcher Worker Threads Call f_skel f Call g_skel network g f g

17. Java Object Serialization

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

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

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

21. writeObject(B) ==> throws java.io.NotSerializableException: java.lang.Thread B java.util.Hashtable java.lang.String java.lang.Thread not serializable Traversing The Graph writeObject(A) ==> succeeds A java.util.Hashtable java.lang.Integer java.lang.String

22. 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);

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

24. Java Remote Method Invocation (RMI)

25. 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., inter-JVM call

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

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

28. Remote Interface Client Server call getCount inc. count display result Sample Remote Interface public interface Count extends java.rmi.Remote { public int getCount() throws java.rmi.RemoteException; }

29. Remote Interface Client Server call getCount Remote Object inc. count display result 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

30. 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++; } // . . .

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

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

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

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

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

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

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

38. Introduction to EJBs

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

40. Method invocation Method Delegation Architecture Client Container Client Interface TX support Security Persistence . . . Bean Instance

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

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

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

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

45. Architecture with Remote Interfaces Source: Enterprise JavaBeansTM Specification, Version 2.0, page 386

46. Types of EJBs

47. Types of Beans • Session • Client and application logic focus • Entity • Persistent data focus • Message • Asynchronous message processing

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

49. lookup create method How a Client Uses a Session Bean JNDI Server Container Client Home Bean Instance Component

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