Technologies for an Information Age: . opennet Enterprise JavaBeans

1. Technologies for an Information Age:.opennetEnterprise JavaBeans Computer Science, Informatics, Physics Indiana University Bloomington IN 47404 gcf@indiana.edu dbc@csit.fsu.edu Fall Semester 2001 MW 5:00 pm - 6:20 pm CENTRAL (not Indiana) Time Geoffrey Fox and Bryan Carpenter (with help from: Xi Rao) PTLIU Laboratory for Community Grids

2. Basic .opennet Architecture Database (Virtual) XML Layer Enterprise Javabeans Java Servlet • This is .opennet structure Persistent Managed Store Object layer Virtual Machine Control Form Output Page viewed by user JSP

3. Background

4. What is EJB? • Enterprise JavaBeans (EJB) combines server-side components with distributed object technologies such as CORBA and Java RMI to simplify the task of application development • in a specialized, albeit economically crucial, domain of application.

5. Component Transaction Monitors • EJB is a specification for Component Transaction Monitoring (CTM) software. • CTMs provide an infrastructure that can automatically manage transactions, object distribution, concurrency, security, persistence, and resource management. • They can handle huge user populations and mission-critical work.

6. Transaction Processing • Transactional integrity is important in business environments. • It is important to ensure that particular sets of events occur atomically or not at all. • For example a single transaction may involve: • Billing a customer • Dispatching the goods • Updating a database of orders • If any one of these operations fail for any reason we should ensure that none of them proceed. • Dispatching goods if billing failed costs a company money; billing the customer if the goods cannot be dispatched loses customers. . .

7. TP Monitors • TP (Transaction Processing) Monitors automatically manage the entire environment that a business system runs in, including transactions, resource management, and fault tolerance. • Advantage: • a long time in service, with solid technology • Disadvantage: • Not object oriented (may use RPC—Remote Procedure Call—but not remote method invocation) • Thus not flexible, extensible, reusable

8. Distributed Objects • Different objects reside on different servers and interact to get the job done. • Allow “business logic” and data to be accessed from remote locations. • Important implementations of distributed objects: • Java RMI, • CORBA, • DCOM.

9. Server-side Components • Advantage of OOP: • flexible • extensible • reusable • The encapsulation of business logic into a business object is important. • For purposes of this course, “business logic” will just mean the application code in the methods of an object, or bean.

10. Distributed Object Architecture

11. Remote Method Invocation

12. Object Request Brokers • A distributed object technology. • They allow unique objects that have state and identity to be distributed across a network. • Advantage: • Object Oriented • Disadvantages: • Leave to developer burdens of managing concurrency, transactional integrity, resource management and fault tolerance.

13. Component Transaction Monitors • Component Transaction Monitors (CTMs) are an extension of traditional transaction monitors (IBM CICS, etc.) • CTM industry builds on both ORBs (object request brokers) and TPMs. • CTMs are a hybrid of these technologies that provides powerful, robust, distributed object platforms. • They provide an infrastructure that can automatically manage transactions, object distribution, concurrency, security, persistence, and resource management. • They may also incorporate instance swapping, resource pooling, and activation, etc. • Thus CTMs can handle large user populations and “mission-critical” work.

14. Example CTMs • Microsoft Transaction Server (MTS): • Only runs on the Microsoft platform—limited opportunity for other vendors. • CORBA: • Both language and platform independent. • Transaction processing, concurrency, persistence, security are services additional to the basic model, and hard to use. • Enterprise JavaBeans: • Services integrated into basic model. • Specification deliberately loose enough to be implemented as wrappers to “legacy” software from many vendors. • First appeared in Dec, 1997. • Most recent update is Oct, 2000 (EJB specification 2.0). • Strongly committed vendors include Oracle and BEA.

15. JavaOne, June 2001 • Consecutive keynotes by Bill Coleman of BEA and Larry Ellison of Oracle. • Coleman claimed that in a poll of Fortune 500/Global 500 companies, 85% were using EJB for new applications. • BEA had (then) 250,000 registered developers for WebLogic. • Larry Ellison equally aggressive, especially on performance issues. • He claimed Oracle have a better implementation :-)

16. References • Enterprise JavaBeans, 2nd Edition, Richard Monson-Haefel, O’Reilley, 2000. • Enterprise JavaBeans, specification documents: http://java.sun.com/products/ejb/docs.html

17. Enterprise JavaBeans

18. Sun’s Definition of EJB • The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These application may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification.

19. Relation to JavaBeans • Enterprise JavaBeans is somewhat unrelated to “ordinary” JavaBeans. • They are both component architectures, and they share some basic ideas about properties, naming conventions, etc. • But the associated technologies are specialized to their particular domains of applicability: • In practice, standard JavaBeans technology is mostly geared to rapid development of GUIs (though, as we saw, JSP also uses a simplified version of JavaBeans). Enterprise Javabeans is geared to the (very different) area of distributed transaction processing. • A conventional bean is a local object. An Enterprise bean is always (part of) a distributed object.

20. Comparision of JavaBeans and EJB

21. Enterprise Bean Component • There are two distinct kinds of Enterprise beans: entity beans and session beans. • Entity beans: • typically model business concepts that can be expressed as nouns, e.g. “customer”. • model real world objects that usually have associated persistent record in the company database. • Session beans: • are an extension of the client application and manage processes or tasks such as making a reservation. • do not represent something in a database, they may change update the database

22. Classes and Interfaces for RMI • A client interacts with an Enterprise bean by invoking remote methods in Java RMI-style remote interfaces. • A remote interface is a normal Java interface that extends the java.rmi.Remotemarker interface. • In Java RMI the remote object implementation class (written by the application developer) and the local stub class (automatically generated) both implement the same interface.

23. Java RMI Architecture Remote object implementation class and stub both implement same interface Call stub method locally Call remote object method locally Send marshaled arguments RMI “Run-time” System Remote Object Stub Client Code Send marshaled result or exception Return value or throw exception Return value or throw exception

24. Classes and Interfaces for EJB • EJB is more complicated. • The application developer supplies two remote interfaces: • the home interface, • the bean remote interface, and in addition to the bean implementation class. • In EJB, the bean implementation class itself does not directly implement either of the interfaces. • Instead they are implemented by classes generated by the EJB container.

25. Roles of EJB Classes and Interfaces • The remote interface: • Defines bean’s business methods. • Extends javax.ejb.EJBObject which in turn extends java.rmi.Remote • The home interface: • Define bean’s life cycle methods. • Extends javax.ejb.EJBHome which in turn extends java.rmi.Remote • The bean class: • Actually implements the bean’s business and initialization methods. • May inherit from javax.ejb.SessionBean or javax.ejb.EntityBean.

26. EJB Interfaces and Classes

27. Container and Server • The client does not interact with a bean class directly. • The client always uses the methods of the bean’s home and remote interfaces to do its work • There may also be various kinds of interaction between the bean and its server. • This interaction interaction managed by a “container”, which is responsible for presenting a uniform interface between beans and server. • The container is responsible for creating new instances of bean, making sure that they are stored properly by the server, and so on. • The concepts “container” and “server” are closely related, but they are considered distinct.

28. Example Remote Interface • The remote interface for an Enterprise bean defines its so-called “business methods”, e.g.: import java.rmi.RemoteException; public interface Book extends javax.ejb.EJBObject { public String getName() throws RemoteException ; public void setName(String str) throws RemoteException ; } • Here,getName()and setName() are the business methods. • They are remote methods, and in Java RMI and EJB all remote methods must be declared to throw RemoteException.

29. Example Home Interface • The home interface defines “life-cycle” methods, used for managing a bean, e.g.: import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.FinderException; public interface BookHome extends javax.ejb.EJBHome { public Book create(int isbn) throws CreateException, RemoteException; public Book findByPrimaryKey(BookPK pk) throws FinderException, RemoteException; }

30. Remarks • The create() method will be responsible for initializing an instance of our bean. If your application needs it, you can provide multiple create() methods, with different arguments. • BookPK stands for “book primary key”—primary keys will be discussed shortly. • In addition to the findByPrimaryKey(), you are free to define other methods that provide convenient ways to look up already-existing Book beans.

31. Example Bean Class import javax.ejb.EntityContext; public class BookBean implements javax.ejb.EntityBean { public int isbn ; public String name ; public BookPK ejbCreate(int isbn) { this.isbn = isbn; return null ; // Assumes “container managed persistence” } public void ejbPostCreate(int isbn) {} public String getName() { return name; } public void setName(String str) { name = str; } . . . Other life cycle methods—see later slide . . . }

32. Bean Class • The business methods are the only methods that are directly visible to the client application; other methods are visible only to the EJB container. • TheejbCreate() and ejbPostCreate() methods initialize the instance of bean class. • The are invoked indirectly by the container, when the client invokes create() on the home interface. • ejbCreate() creates a record in the database. • After ejbCreate() succeeds, the container establishes a primary key for the entity. • ejbPostCreate() can be used to do any necessary “post-initialization”—for example, initialization operations that rely on the existence of a primary key.

33. Example Bean Class (Continued) • The EntityBean interface also requires one to implement a series of so-called call-back methods. For now we can leave their bodies empty, e.g.: public class BookBean implements javax.ejb.EntityBean { . . . public void setEntityContext(EntityContext ctx){} public void unsetEntityContext(){} public void ejbActivate(){} public void ejbPassivate(){} public void ejbLoad(){} public void ejbStore(){} public void ejbRemove(){} } • The EJB Server invokes the setEntityContext(), unsetEntityContext(),ejbActivate(),ejbPassivate(),ejbLoad(),ejbStore(), ejbRemove() methods when important state management events occur.

34. Primary Key • When a entity bean is deployed in an EJB server, it’s persistent fields are mapped to a database. • The primary key is a “pointer” that helps locate the unique record or entity in a database that describes the bean. • The bean can be retrieved from the database by using its primary key. • Using the findByPrimaryKey() method in home interface. • For every field of the primary key, the associated bean class must have a public field with exactly the same name and type.

35. Example Primary Key public class BookPK implements java.io.Serializable { public int isbn; public BookPK() {} // required! public BookPK(int isbn) { this.isbn = isbn ; } public int hashCode(){ // required! return isbn; } public boolean equals(Object obj){ // required! if (obj instanceof BookPK){ if (((BookPK) obj).isbn == isbn) return true; } return false; } }

36. Using the Bean • Armed with the specification of the two remote interface classes, the bean class, and the public key class, we can write the client code. • We still have some way to go before we can deploy this bean, but the deployment details in general shouldn’t change the code for the client.

37. Example EJB Client public static void main(String [] args) throws RemoteException { Context initial = new InitialContext() ; Object objref = initial.lookup(“MyBook”) ; BookHome home = (BookHome) PortableRemoteObject.narrow(objref, BookHome.class); Book book1 = home.create(735710201) ; book1.setName(“Inside XML”); // Business method Book book2 = home.create(1565928695) ; book2.setName(“Enterprise JavaBeans”); // Business method // . . . then, perhaps much later, perhaps in a different program . . . BookPK pk = new BookBK(1565928695); Book book3 = home.findByPrimaryKey(pk); System.out.println(book3.getName()) ; // Prints “Enterprise JavaBeans” }

38. Obtaining the Remote Reference • The first few lines are used to obtain a remote reference to the home interface of the bean. • We use the lookup() method from generic JNDI (Java Name and Directory Interface) services. • For reasons of CORBA-compliancy, the stub object returned by the initial.lookup() call does not implement the BookHome remote interface. • A subsequent call to PortableRemoteObject.narrow() is needed to generate a stub that does implement this interface.

39. Creating and Finding Entity Beans • Once we have the reference to the home object, the rest is straightforward. • We create a couple of Book entities, and call the setName() business methods on them. • The created Book bean is implicitly persistent. • It will live forever, unless it is explicitly deleted (or the underlying database is destroyed!) • Clients that run subsequently can retrieve a bean created earlier through suitable find methods—the most common way is to pass a suitable primary key object to the findByPrimaryKey() method.

40. The Deployment Descriptor • A very important point to notice is that that the Java classes need not deal with properties like: • Transactional nature of the code • Persistence • Resource pooling (for scalability) • Security management • Instead, a deployment descriptor allows us to customize the behavior of enterprise bean at deployment time (or “run-time”), without having to change the Java program itself. • EJB 1.1 Deployment descriptors use a flexible file format based on XML. • EJB containers would normally provide GUIs to generate the XML documents “automatically”.

41. Example Deployment Descriptor <?xml version="1.0"?> <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN” "http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd"> <ejb-jar> <enterprise-beans> <entity> <ejb-name> BOOKEJB </ejb-name> <home>BookHome</home> <remote>Book</remote> <ejb-class>BookBean</ejb-class> <prim-key-class>BookPK</prim-key-class> <persistence-type>Container</persistence-type> <reentrant>False</reentrant> </entity> </enterprise-beans> </ejb-jar>

42. Elements of the Deployment Descriptor • ejb-jar • root of deployment descriptor. Describes contents of a jar archive file. • enterprise-beans • may contain descriptions of entity beans and session beans. • entity • describes an entity bean and its deployment information. • ejb-name • descriptive name of the bean. • home • the name of the home interface class. • remote • the name of the remote interface class . • ejb-class • the name of the bean class • prim-key-class • the name of bean’s primary key class

43. Session Beans

44. Session Beans • Session beans do not model (persistent) data. • session beans do not have a primary key. • Instead (as the name suggests), they a supposed to abstract some sequence of operations associated with a session between client and server. • Connected ideas: • Conversation—between client and server, • Workflow—a slightly abstruse (to me) business concept. . . • If the most important part of an entity bean was considered to be its persistent fields, the most important part of a session bean would presumably be its methods. • Note EJB session beans are not especially closely related to the “session beans” we used with JSP (although they may have a parallel role).

45. Workflow With Session Beans • Session beans are “remote agents” for the client, managing business processes or tasks; they are an appropriate place for “business logic”. • Session bean work with entity beans, data, and other resources to control “workflow”. • Session bean is not persistent like an entity bean; nothing in a session bean maps directly into a database or is stored between sessions

46. Rationale for Session Beans • Business logic can be reused easily. • Moving workflow logic into a session bean helps to thin down the client application, and reduce network traffic and connections. • Decrease number of remote method invocations by client. • Decrease the the number of network connections by client. • Without use of session beans, a client might be expected to manage hundreds or even thousands of remote references at one time.

47. A Simple Session Bean • In general the importance of session beans is that they can manipulate data (entity beans) on a server without additional network communications. • The following (unrealistically simple) example just manipulates its own instance variables. • Example adapted from one of Sun’s tutorials. • The use of instance variables to save information (“conversational state”) between consecutive method invocations implies that this is a stateful session bean.

48. Bean Class import java.util.*; import javax.ejb.*; public class CartEJB implements SessionBean { String customerName; Vector contents; public void ejbCreate(String person) throws CreateException { customerName = person; contents = new Vector(); } . . . business methods (next slide) and callback methods . . . }

49. Business Methods public void addBook(String title) { contents.addElement(title) } public void removeBook(String title) throws BookException { boolean result = contents.removeElement(title); if (!result) throw new BookException(title + “ not in cart.”); } public Vector getContents() { return contents; }

50. Stateful and Stateless Session Bean • Stateful session beans maintain conversational state when used by a client. This state is saved in the instance variables of the bean. • Conversational state is only kept for as long as the client application is actively using the bean. • Stateful session beans are not shared among clients • Stateless session beans do not maintain any conversational state. Each method is completely independent and uses only data passed in its parameters. • If values are saved in instance variables of a stateless session bean, these values generally are not preserved between successive method invocations. • Stateless session beans provide the highest performace in terms of throughput and resource consumption of all the bean types