EJB Java Enterprise Edition Java EE

1. EJBJava Enterprise Edition (Java EE) FMIS 3202 Enterprise System Architectures Nik R. Hassan Spring 2007

2. 2 Java Beans A Java Bean is a special kind of class. There are three major types of Java Beans Entity Beans They can be used to map an entry in a database table to a class. They become the “Data Layer” of the 3-tier client/server system replacing result sets from a database query. The application server provides the functionality to load, update or delete the values of a class instance to the database. Session Beans Session beans are used to implement the functionality of your application. There are two kind of session beans: Stateful and Stateless. A stateful session bean is for example a shopping cart class. The state is the cart holding the shopping items and the quantity. The cart class is hold in your application session and disposed at the end when the user checked out. A stateless bean is a short living class. A typical example is a MailSender class sending a message. You call a method and dispose it. With a application server you do not instantiate the class each time you need it. The application server passes an instance from a pool. This is more efficient. Message Driven Beans Message beans provide functionality to implement messaging in your business logic. When you want to send a message to one or more recipients to start another business logic, you can use message beans. A Shop application could send a order message to the Warehouse management. Once the warehouse management software is started, it receives the orders from the shop application.

3. 3 Why Enterprise Java Beans (EJB)? Enterprise Java Beans (EJB) is a heavyweight industry-strength framework. If the application is not as heavy, you should choose simple applications, Hibernate, or just straight databases/SQL. Advantages of EJB: Many vendor application servers conform to the J2EE specification allowing one to select a best-of-breed solution. To handle fluctuations in resource demand server-side resources can easily be scaled by adding or removing servers. Application servers provide access to complex services, namely transaction and security management, resource pooling, JNDI (Java Naming and Directory Interface), component lifecycle management, etc. Disadvanatges of EJB: EJB has a large and complicated specification. EJBs take longer to develop. Also, when things go wrong they can be more difficult to debug. Occasionally the bug may not be in your code but in the application server itself. New specifications may force modifications When NOT to use EJB? Do not choose EJB when there is no need for scalability, transaction management, or security. Do not choose EJB if you anticipate low numbers of read-only users. Do not choose EJB if your team lacks EJB experience or cannot quickly obtain that experience. The EJB learning curve is steep and overcoming it can easily derail an otherwise viable project.

4. 4 Java Components and Application Servers EJBs are a kind of component-packaged software object with standardized interface that is reusable in multiple applications E.g. a customer component can be used in EBay as well as in Amazon with only minor modifications A set of specifications that details how components interact with each other and with other software tools The application server: Is a process which manages one or more EJB containers Provides access to system services for EJB containers Provides J2EE services for naming, transactions and security The EJB container: Manages EJB classes and instances and access to beans Enforces transactional requirements Manages bean life cycle May manage persistence for entity beans

5. 5 Encapsulation Simplifies Complexity The whole idea is to simplify the complex enterprise system by hiding (encapsulating) that complexity The client shouldn’t have to worry about which components it needs to connect to when changes are necessary (loosely coupled) The components on the server side shouldn’t have to worry about other components regardless where they reside (location transparency) Each component need only to focus on their business logic (cohesiveness) When the client calls the server, the call is intercepted by a request interceptor that is created by the EJB container. This interceptor takes care of the low-level API functions and passes the call to the correct distributed object (enterprise bean) The EJB container creates multiple instances of the bean as is needed and spawning threads in which these instance are executed. This wrapping process appears to the client as the EJB object which knows about networking, transactions, security, and more. The EJB container creates stubs and skeletons it requires to service the call.

6. 6 Remote Method Invocation (RMI) When you call a method (e.g. myAccount.transfer(tran) in your homework), the reference variable is usually local which means it is running on the same machine (same java heap/JVM). In an enterprise system, you cannot assume so (e.g. clients could be browsers or beans on another machine). Enterprise systems must allow for remote clients that can pass message across machines. That means the reference variable is not only out of scope (remember the familiar “cannot find symbol” error?), but on another machine. Java’s RMI solves this problem by giving the client a proxy (called a stub) helper object that acts as the go-between and takes care of the low-level communication (sockets and streams) with the remote object. On the server side there is also a helper object that accepts the socket connection from the stub called the skeleton. This skeleton unpacks the message and invokes the real method on the real object, appearing like a local client. Both helper objects accepts calls and transfer the message to the real distributed object. That is why EJBs need to implement the Serializable interface so that the stub can flatten them (make them like primitives) and then ship them off to the skeleton. All classes that can be called remotely must extend the java.rmi.Remote marker interface (which is why stubs and skeletons are necessary as interface proxies for the real classes since concrete classes cannot “extend” interfaces, so they “implement” their helper interfaces). What happens if the server is down? Or if the connection drops? How is the client to know what is happening (especially in the typical asynchronous fashion which does not immediately provide feedback?)

7. 7 Handling Exceptions During risky remote calls Java’s built-in exception handling takes over. Exception handling is useful (and required by the compiler) in instances that things can go wrong (e.g. calling a remote object that you didn’t write). You need to know that the method you are calling is risky so that you can write code that can handle the failure if it does happen. Two structures support this situation (e.g. look up the public Socket() constructor of the java.net.Socket documentation. Every time you create a new socket to connect, you need to declare that it is risky): If you write a method that involves risky behavior you must declare it using the throws keyword (e.g. the Socket constructor), or If you call a method that throws an exception, you must acknowledge that it is risky by wrapping the call in a try-catch block or ducks what is thrown by ignoring the exception and passing it to the methods higher up the calling stack What is being thrown is an exception object that can be handled by the catch block. private void setUpNetwork() { //doesn’t have a throws keyword-so must have try-catch try { //start of try-catch socket = new Socket(“127.0.0.1”, 8080); //creates a new socket on the localhost on port 8080 writer = new PrintWriter(socket.getOutputStream());// if successful, a new PrintWriter object is created System.out.println(“networking established!”); } catch(IOException ex) { //if not successful –maybe server is down System.out.println(“Failed to connect”); //prints out a message ex.printStackTrace(); //prints out a stack trace } } //end of try-catch block, execution continues after this

8. 8 EJBHome and EJBObject To wrap it all up, how does a client know which methods to call? Or more importantly which objects to reference? What happens next? It makes sense that the object must be identified first before the methods of that object can be called. Two interfaces must be coded to extend the following interfaces (NB Your interfaces extends standard Java interfaces--see documentation for javax.ejb). Your interfaces will then be implemented by the EJB container to construct EJBObjects and EJBHome objects The Home interface (EJBHome) This interface defines the methods that allow a remote client to create, find, and remove distributed bean objects In this program you define a create() method. The Remote Interface (EJBObject) This interface provides the client view of the EJB object (it contains the same exact methods as the distributed bean object) The Remote interface extends java.rmi.Remote and every method declares a RemoteException (from the java.rmi package) Arguments and return types must be shippable (Serializable, primitive, array of Serializable or primitives or Remote objects) The EJBObject class becomes the bodyguard to all the distributed bean objects. All services that are required are started up by the EJBObject before a local call is made to the bean. The EJBObject does the following Checks to see if the client is authorized (Java security services) Checks to see if the call is part of the right transaction (Java transaction services) Checks to see if the bean needs to load info from the database before running the method (persistence)

9. 9 What Happens after Deployment Using the EJBHome interface you created, the EJB container creates a new EJBHome object and registers it with Java Naming Directory Interface (JNDI). This way, any client can look it up in a directory The client does a JNDI lookup using its registered name. JNDI sends back a stub of the EJBHome object. Now the client has local access to its create() method. The client invokes create() and the actual distributed bean is created on the server. The stub may be destroyed. Using the EJBObject interface you created, the EJB container creates a new EJBObject object (which becomes the bodyguard to the newly created distributed bean) and its stub is returned to the client (this stub has exactly the same methods as the distributed bean) Now the client can make local calls using the stub

10. 10 EJB Clients Almost any type of program can be an EJB client Another EJB The client bean can be deployed in the same or a different EJB container A Java Servlet or JavaServer Page The Servlet or JSP provides a server-side interface to the EJB logic A Java application A stand-alone Java application can make use of centralized business logic through EJBs Security considerations make this most attractive for Java applications which run inside a corporate firewall Non-Java clients EJBs are compatible with, for example, CORBA

11. 11 Types of EJB

12. 12 Types of EJB Session Bean A non-persistent object that implements some business logic and runs on a server (similar to business layer components) Reused by different clients, but not shared concurrently Stateless session beans retain no conversational state between method calls, e.g. a credit card verification method performs the task on invocation and does not retain any information about the credit card. Stateful session beans retain conversational state between method calls, e.g. an ATM could perform operations like checking an account balance, transferring funds, or making a withdrawal could be performed, one by one, by the same customer. So the bean needs to keep track of the state for each of these operations. Message-driven beans A message-driven bean instance is an asynchronous message consumer Message-driven beans have no client visibility

13. 13 Types of EJB.. Message-driven beans act as a Java Messaging Service (JMS) message listener, like how an event listener listens to events, message-driven beans listens to messages. The messages may be sent by any J2EE component--an application client, another enterprise bean, a Web component--or by a JMS application or system that does not use J2EE technology. Entity beans An entity bean instance represents an object-oriented view of data in a persistent storage E.g. a program can create an entity bean and then the program can be stopped and restarted--but the entity bean will continue to exist. After being restarted, the program can again find the entity bean it was working with and continue using it. Plain old Java objects (POJO) are used only by one program. An entity bean, on the other hand, can be used by any program on the network. Client programs just need to find the entity bean via JNDI in order to use it. Entity beans must have a unique primary key that is used to find the specific entity bean they want to manipulate. For example, an "employee" entity bean may use the employee's social security number as its primary key. Methods of an entity bean run on a "server" machine. When a client program calls an entity bean's method, the client program's thread stops executing and control passes over to the server. When the method returns from the server, the local thread resumes execution. Container-managed persistence (CMP) and bean-managed persistence (BMP) are available

14. 14 Structure of an EJB To become an EJB, a Java class needs to implement specific interfaces: Session beans must implement javax.ejb.SessionBean Entity beans must implement javax.ejb.EntityBean Message-driven beans must implement javax.ejb.MessageDrivenBean All these interfaces extend the marker interface javax.ejb.EnterpriseBean. This is how the system knows the class is an enterprise bean. Also, because this interface extends java.io.Serializable, all enterprise beans can be converted to a bit-blob (a class that can be saved as a flat file).

15. 15 Deployment The EJB specification mandates that: EJBs be packaged in EJB JAR files The deployment descriptor be included in an EJB JAR in the file META-INF/ejb-jar.xml Deployment descriptor contains Structural information The structure of an enterprise bean The external dependencies of the enterprise bean Application assembly information How the enterprise beans in the ejb-jar file are assembled into a larger application deployment unit (usually an Enterprise Archive or EAR file) The fundamental element within the ejb-jar contains the declarations of one or more EJBs An EJB is declared as <entity>, <session> or <message-driven>