Enterprise Java Beans

1. Enterprise Java Beans Introduction

2. Enterprise Java Beans • Enterprise JavaBeans, known as EJBs for short. • A powerful facility dedicated to expressing the business logic of an application and for accessing a database using a JavaBeans-like concept. • A server-side component architecture that simplifies the process of building distributed component applications in Java

3. By using EJB, you can write scalable, reliable, and secure applications.

4. Characteristics of Enterprise Applications • Remote Method Invocations • Logic that connects a client and a server • Load Balancing • Transparent Fail-over • Back-end Integration • Integration with DB and legacy systems • Clustering • Dynamic Redeployment • Redeployment with maximum availability

5. Characteristics of Enterprise Applications • Clean Shutdown • Logging and Auditing • Processing Multiple Client Requests • Object pooling • The objects need to be created or destroyed when client traffic increases or decreases • Resource Pooling • Security • Caching • Transactions, …

6. Component Architectures - Evolution • Since the time of introduction of component architectures, a number of application servers have appeared. • At first, each AS provided its own component architecture • The code became AS dependent • Reduced portability • Need • A standard set of interfaces between AS and components

7. Component Architecture

8. Enterprise Java Beans • A specification • http://java.sun.com/products/ejb/docs.html • Lays out rules of engagement between components and AS • A set of Java interfaces • Components and AS must conform to these interfaces

9. Enterprise Java Beans • Enterprise Java Beans is a standard for building server-side components in Java • Defines a set of interfaces between components and application servers • Enterprise Beans are deployable, and can be imported and loaded into an application server, which hosts those components.

10. EJB Benefits • Agreed upon by the industry • Portability is easier • Rapid Application Development • Provides support for characteristics required by an Enterprise Application

11. EJB Execution Environment • Enterprise beans run in the EJB container, a runtime environment within the Application Server

12. EJB Container • The EJB container provides system-level services such as transactions and security to its enterprise beans. • These services enable you to quickly build and deploy enterprise beans, which form the core of transactional Java EE applications.

13. Why Java? • Java is one of the best-suited languages for building components for the following reasons: • Interface/Implementation Separation • Safe and Secure • Cross-platform

14. Other Choices • If you don’t want to go to the EJB route, you have two choices • Lightweight open source Java Frameworks • Spring • Microsoft’s .Net Managed Components

15. EJB components • EJB components are not presentation-tier components • They sit behind the presentation tier components and do all the hard work

16. EJB Clients • Thick Clients • Execute on user’s desktop • Applets or Applications • Dynamic Web-pages • JSPs and Servlets can connect to EJBs for business services • Web-service Clients • Applications requiring a service over the internet

18. Kinds of EJBs • Session Beans • Entity Beans • Message Driven Beans

19. Session Beans • Model Business Processes • A session bean represents a single client inside the Application Server. • To access an application that is deployed on the server, the client invokes the session bean’s methods. • The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server.

20. Session Beans • As its name suggests, a session bean is similar to an interactive session • A session bean is not shared • it can have only one client, in the same way that an interactive session can have only one user. • Like an interactive session, a session bean is not persistent • When the client terminates, its session bean appears to terminate and is no longer associated with the client

21. Session Beans - State Management Modes • There are two types of session beans: • Stateless Session Beans • Stateful Session Beans

22. Stateless Session Beans • A stateless session bean does not maintain a conversational state for the client. • These beans do not declare any instance (class-level) variables, so that the methods contained within can act only on any local parameters. • There is no way to maintain state across method calls.

23. Stateful Session Beans • These beans can hold client state across method invocations. • This is possible with the use of instance variables declared in the class definition. • The client will then set the values for these variables and use these values in other method calls.

24. Entity Beans • Model Business Data • An entity bean represents a business object in a persistent storage mechanism. • Some examples of business objects are customers, orders, and products. • Typically, each entity bean has an underlying table in a relational database, and each instance of the bean corresponds to a row in that table.

25. Message Driven Beans • Perform actions • Similar to Session Beans • Called by sending messages • A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. • It normally acts as a JMS message listener, which is similar to an event listener except that it receives JMS messages instead of events. • The messages can be sent by any J2EE component—an application client, another enterprise bean, or a web component—or by a JMS application or system that does not use J2EE technology. • Message-driven beans can process either JMS messages or other kinds of messages.

26. Distributed Objects: The Foundation for EJB • EJB Components are based on distributed objects • A Distributed Object is an object that is callable from a remote system

28. Distributed Objects – The Stub • The client calls a stub • Client-side proxy object • Stub is responsible for masking network communications from the client • Stub knows how to call over the network using sockets, massaging parameters into their network representation

29. Distributed Objects - Skeleton • The Stub calls over the network to a skeleton • A server-side proxy object • Masks network communication from the distributed object • Knows how to receive calls on a socket

30. Distributed Object – Implementation Object • The skeleton delegates the call to the appropriate implementation object • This object does its work, and then returns control to the skeleton, which returns to the stub, which then returns control to the client

31. Distribution Transparency • The stub and the server-side implementation object implement the same interface – The remote interface • The stub clones the distributed object’s method signatures

32. Distribution Transparency • A client who calls a method on the stub thinks he is calling the distributed object directly • In reality, the client is calling an empty stub that knows how to go over the network • The distributed object is an abstraction that is created by the cooperation between the stub, skeleton, and implementation objects • No single entity in the scenario is the distributed object

33. Distributed Object Technologies • Distributed Objects can be achieved by using a number of technologies • Corba • DCOM • Java RMI-IIOP

34. Distributed Objects and Middleware • Distributed objects enable us to distribute the application across a network • As distributed applications grow larger, they require middleware services, such as transaction and security • There are two way to get Middleware: • Explicit • Implicit

35. What constitutes an Enterprise Bean? • The Enterprise Bean Class • The Remote Interface • The Home Interfaces

36. Java RMI-IIOP and EJB Objects • javax.ejb.EJBObject extends javax.rmi.Remote • javax.rmi.Remote is part of Java RMI over the Internet Inter-ORB Protocol (RMI-IIOP) • Any object that implements this interface is a remote object and is callable from a different JVM

37. Java RMI-IIOP • Java RMI-IIOP is J2EE’s de-facto mechanism for performing simple, powerful networking. • Using RMI-IIOP you can write distributed objects in Java, enabling objects to communicate in memory across JVM and physical devices

38. RMI-IIOP is a special version of RMI that is compliant with CORBA • EJB and J2EE mandate the use of RMI-IIOP

39. Remote Method Invocations • A Remote Procedure Call (RPC) is a procedural invocation from a process on one machine to a process on another machine • A Remote Method Invocation in Java takes the RPC concept one step further and allows for distributed “object” communication

40. RMI-IIOP enables you to invoke not merely procedures, but also methods on objects remotely • This yields the benefits of object-oriented programming

41. Distributed Objects-Issues • Marshalling & Unmarshalling • Different machines may have different way to represent data • The memory layout may be entirely different • The process is packaging and unpackaging of parameters so that they are usable in two heterogeneous environments • Passing by reference & Passing by value • Network or machine instability • Error Reporting

42. Back to Session Beans • Session EJB relates to business objects • Not necessarily associated with a database • May themselves use entity Beans • Session EJB contains methods to provide business logic • No concern with facilities or utilities • Created on a per-client basis • Can be stateful • Attributes retain data between calls • Can be stateless • Attributes always at initial values • Session EJBs are not persistent • Data is lost on system crash

43. Creatinga Session EJB • There are several steps required to create an EJB • Most are common between entity and session beans • In this section, we concentrate on Session EJB • Three items are required for deployment • EJB class implementation • Implements the methods to support EJB interfaces and provides business logic • Remote EJB interface • A remote interface describing services the EJB supplies • Home interface • Describes methods for constructing and finding EJB • Notice that only one set of implementation code is required • The business logic implementation. Everything else is generated by the EJB server • The developer simply defines the interfaces

44. The EJB Remote Interface • Defines services provided by the Session EJB • Extends javax.ejb.EJBObject interface • All methods must throw RemoteException • All return types must be Serializable • Named after class; e.g., Cart • This is the definition of services available to client • Client requests an object matching this interface • You specify methods in the interface • And implement matching methods in implementation class • Server generates intermediate objects

45. Must extend EJBObject Importing both EJB and RMI import javax.ejb.*; import java.rmi.*; import java.util.*; public interface Cart extends EJBObject { public void addTicket(String ticket) throws RemoteException; public Vector getTickets( ) throws RemoteException; } Define EJB services for Session EJB Session EJB Remote Interface: Example

46. The Session EJB Home Interface • Every Session EJB has an associated Home interface • Interface describes the methods available to control life cycle • Creation methods • Does not define methods for locating specific EJB instances • Session EJBs are created on a per-client basis . • They are not persistent • The Home interface must conform to EJB specification • All methods must be Create methods • Create methods must be named create (... ) • Only mandatory method is at least one Create method-- Returns the EJB instance that is created from supplied data

47. Name is EJB name + 'Home' Must extend EJBHome import javax.ejb.*; import java.rmi.*; public interface CartHome extends EJBHome { Cart create ( ) throws CreateException, RemoteException; } Define create services The Session EJB Home Interface: Example

48. The Session Bean Class • Finally, we need to implement the EJB Remote interface • This is where we carry out the services specified • The Session EJB class itself • The Session EJB is a lengthy class • Needs to implement support for • Home Interface • Remote Interface • Bean Lifecycle service methods

49. The Session Bean Class • Contains the logic • A simple Java class that conforms to a well-defined interface and obeys certain rules • The EJB Class must implement javax.ejb.EnterpriseBean interface • javax.ejb.SessionBean, javax.ejb.EntityBean • The interface forces the class to implement certain methods the all beans must provide

50. EJB Implementation: Remote Services • This is the actual implementation of the EJB Remote interface • Methods are implemented same as any other Java interface • Again, the class itself does not implement the interface