Enterprise Java Beans Instructors Geoffrey Fox and Bryan
Enterprise Java. Beans Instructors: Geoffrey Fox and Bryan Carpenter Dept. of Computer Science School of Computational Science and Information Technology 400 Dirac Science Library Florida State University Tallahassee Florida 32306 -4120 http: //www. csit. fsu. edu Acknowledgements: Xi Rao http: //aspen. csit. fsu. edu/webtech/xml/ 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 1
What is EJB? • Enterprise Java. Beans (EJB) combines server-side components with distributed object technologies such as CORBA and Java RMI to greatly simplify the task of application development – in a specialized, albeit pervasive, domain of application. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 2
References • Enterprise Java. Beans, 2 nd Edition, Richard Monson-Haefel, O’Reilley, 2000. • Enterprise Java. Beans, specification documents: http: //java. sun. com/products/ejb/docs. html 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 3
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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 4
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. . . 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 5
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 running with solid technology • Disadvantage: – Not object oriented (may use RPC—Remote Procedure Call— but not remote method invocation) – Thus not flexible, extensible, reusable 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 6
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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 7
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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 8
Distributed Object Architecture 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 9
Remote Method Invocation 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 10
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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 11
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 “missioncritical” work. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 12
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 Java. Beans: – 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). 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 13
Enterprise Java. Beans 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 14
Sun’s Definition of EJB • The Enterprise Java. Beans architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise Java. Beans 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 Java. Beans specification. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 15
Relation to Java. Beans • Enterprise Java. Beans is somewhat unrelated to “conventional” Java. Beans. • They are both component architectures, and they share some basic ideas about properties, naming conventions, etc. • But the associated technologies are highly specialized to their particular domains of applicability: – In practice, standard Java. Beans technology is mostly geared to rapid development of GUIs. Enterprise Javabeans is geared to the (radically different) area of distributed transaction processing. – A conventional bean is a local object. An Enterprise bean is always (part of) a distributed object. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 16
Comparision of Java. Beans and EJB 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 17
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 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 18
Classes and Interfaces • A client interacts with an Enterprise bean by invoking remote methods in Java RMI-style remote interfaces. • In simple Java RMI, the application developer supplies a remote interface and a remote implementation class that implements this interface. • In EJB, the application developer supplies two remote interfaces and one class: – the home interface, – the bean remote interface, and – the bean implementation class. • The bean class itself does not directly implement either of the interfaces. – Instead they are implemented by classes generated by the EJB container. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 19
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. Session. Bean or javax. ejb. Entity. Bean. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 20
EJB Interfaces and Classes 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 21
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 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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 22
Container vs Server • The EJB server-provider is a specialist in the area of distributed transaction management, distributed object, and other lower-level system-level services. • The EJB container-provider provides deployment tool and runtime support for deployed enterprise bean instances. • Currently the container-provider and server-provider are the same vendor, but it is foreseen that eventually vendors may specialize, and supply EJB servers and EJB containers as separate, plug in components. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 23
Example Remote interface • The remote interface for an Enterprise bean defines its socalled “business methods”, e. g. : import java. rmi. Remote. Exception; public interface Book extends javax. ejb. EJBObject { public String get. Name() throws Remote. Exception ; public void set. Name(String str) throws Remote. Exception ; } • Here, get. Name() and set. Name() are the business methods. – They are remote methods, and must throw Remote. Exception. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 24
Example Home interface • The home interface defines “life-cycle” methods, used for managing a bean, e. g. : import java. rmi. Remote. Exception; import javax. ejb. Create. Exception; import javax. ejb. Finder. Exception; public interface Book. Home extends javax. ejb. EJBHome { public Book create(int isbn) throws Create. Exception, Remote. Exception; public Book find. By. Primary. Key(Book. PK pk) throws Finder. Exception, Remote. Exception; } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 25
Home interface • The create() method will be responsible for initializing an instance of our bean. If your application needs it, you can provide other create() methods, with different arguments. • In addition to the find. By. Primary. Key(), you are free to define other methods that provide convenient ways to look up already-existing Book beans. • Book. PK stands for “book primary key”—primary keys will be discussed shortly. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 26
Example Bean class import javax. ejb. Entity. Context; public class Book. Bean implements javax. ejb. Entity. Bean { public int isbn ; public String name ; public Book. PK ejb. Create(int isbn){ this. isbn = isbn; return null ; // Assumes “container managed persistence” } public void ejb. Post. Create(int isbn){} } 12/12/2021 public String get. Name(){ return name; } public void set. Name(String str){ name = str; }. . . it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 27
Bean class • The business methods are the only methods that are directly visible to the client application; the other methods are visible only to the EJB container. • The ejb. Create() and ejb. Post. Create() methods initialize the instance of bean class. • The are invoked indirectly by the container, when the client invokes create() on the home interface. • ejb. Create() creates a record in the database. • After ejb. Create() succeeds, the container establishes a primary key for the entity. • ejb. Post. Create() can be used to do any necessary “postinitialization”—for example, initialization operations that rely on the existence of a primary key. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 28
Example Bean class (continued) • The Entity. Bean 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 Book. Bean implements javax. ejb. Entity. Bean {. . . public void set. Entity. Context(Entity. Context ctx){} public void unset. Entity. Context(){} public void ejb. Activate(){} public void ejb. Passivate(){} public void ejb. Load(){} public void ejb. Store(){} public void ejb. Remove(){} } • The EJB Server invokes the set. Entity. Context(), unset. Entity. Context(), ejb. Activate(), ejb. Passivate(), ejb. Load(), ejb. Store(), ejb. Remove() methods when important state management events occur. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 29
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 find. By. Primary. Key() method in home interface. • A primary key class must be a Serializable object. • A primary key class must override the hash. Code() and equals() methods from java. lang. Object. • For every field of the primary key, the associated bean class must have a public field with exactly the same name and type. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 30
Example Primary Key public class Book. PK implements java. io. Serializable { public int isbn; public Book. PK() {} // required! public Book. PK(int isbn) { this. isbn = isbn ; } } 12/12/2021 public int hash. Code(){ return isbn; } public boolean equals(Object obj){ if (obj instanceof Book. PK){ if (((Book. PK) obj). isbn == isbn) return true; } return false; } it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 31
Compound Primary Keys • In general the primary key can have more than one field. These must identically match fields in the associated bean class. • For example, here is an alternative, more complex, organization for a book bean: public class Book. Bean implements javax. ejb. Entity. Bean { String Title ; String Author ; } public class Book. PK implements java. io. Serializable { } String Title ; String Author ; String publisher ; String price ; . . . etc, etc – The assumption is that every book is uniquely characterized by the combination of title and author. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 32
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. • Of course 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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 33
Example EJB Client public static void main(String [] args) throws Remote. Exception { Context initial = new Initial. Context() ; Object objref = initial. lookup(“My. Book”) ; Book. Home home = (Book. Home) Portable. Remote. Object. narrow(objref, Book. Home. class); Book book 1 = home. create(735710201) ; book 1. set. Name(“Inside XML”); // Business method Book book 2 = home. create(1565928695) ; book 2. set. Name(“Enterprise Java. Beans”); // Business method //. . . then, perhaps much later, perhaps in a different program. . . Book. PK pk = new Book. BK(1565928695); Book book 3 = home. find. By. Primary. Key(pk); System. out. println(book 3. get. Name()) ; // Prints “Enterprise Java. Beans” } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 34
Obtaining the Remote Reference • The first few lines are used to obtain a remote reference to the home interface of the bean. • Roughly this corresponds to looking up a remote reference in an RMI registry, but it is more complicated for a couple of reasons: – We use the generic JNDI (Java Name and Directory Interface) services rather than rmiregistry. – For reasons of CORBA-compliancy, the stub object returned by the initial. lookup() call does not implement the Book. Home remote interface. – A subsequent call to Portable. Remote. Object. narrow() is needed to generate a stub that does implement this interface. – Why could the two operations not be combined? 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 35
Locating Beans with JNDI • JNDI allows the application client to view the EJB server as a set of directories, like directories in a common filesystem. • JNDI allows us to find access beans regardless of their location on the network. • After the client application locates and obtains a remote reference to the EJB home using JNDI, the client can use the EJB home to obtain a remote reference to a bean. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 36
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 set. Name() business methods on them. – This is somewhat different from raw RMI, which has no intrinsic method for creating a remote object from a client—a remote object is usually deployed “manually” on the server. • 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 find. By. Primary. Key() method. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 37
The Deployment Descriptor • A deployment descriptor serves a function similar to a property file. It allows us to customize the behavior of enterprise bean at deployment time (or “run-time”), without having to change the program itself. • EJB 1. 1 Deployment descriptors use a flexible file format based on XML. • Many EJB containers will provide GUIs to generate the XML documents “automatically”. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 38
Example Deployment Descriptor <? xml version="1. 0"? > <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc. //DTD Enterprise Java. Beans 1. 1//EN” "http: //java. sun. com/j 2 ee/dtds/ejb-jar_1_1. dtd"> <ejb-jar> <enterprise-beans> <entity> <ejb-name> BOOKEJB </ejb-name> <home>Book. Home</home> <remote>Book</remote> <ejb-class>Book. Bean</ejb-class> <prim-key-class>Book. PK</prim-key-class> <persistence-type>Container</persistence-type> <reentrant>False</reentrant> </entity> </enterprise-beans> </ejb-jar> 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 39
Elements of the Deployment Descriptor • ejb-jar – root of XML 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 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 40
JAR Files • JAR (Java archive) files are archive files that are used specifically for packaging Java class (and other resources, such as images) which are ready for use in some type of application. • In particular, JARs are used for packaging Enterprise Java. Beans. They may contain that bean class, remote interface, home interface, primary key and descriptor file. • The Container can read JAR file. The it use the deployment descriptor to learn about the beans contained in the JAR file. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 41
Deploying an Entity Bean 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 42
Deploying an EJB Application • Download SDK, Enterprise Edition, from • • http: //java. sun. com/j 2 ee/j 2 sdkee Unpack the file in a suitable directory. Follow the installation instructions: edit the bin/userconfig. sh script. Run bin/deploytool. Select new application from the file menu. Give application “display name” (eg Book. App) and a project file name. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 43
12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 44
Adding a Bean • Under the file menu, choose new enterprise bean. • You get a New Enterprise Bean Wizard. • Choose a JAR display name—a logical name for the JAR file we are creating. • Add the “contents” to the JAR file—the class files for your interface and bean classes—and other requested fields. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 45
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 46
Define Interfaces and Classes • In the next screen of the wizard you specify which class files in the JAR correspond to the home and remote interfaces, and the bean class. • Specify we are defining an entity bean (or session bean). 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 47
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 48
Choose Persistence Mechanism • In the next screen we will choose “container managed persistence”. • You select which of the public fields in the class are two be persisted by the container. • You also define the primary key class. – If we are using a compound primary key like Book. PK, the Primary Key Field Name box should be left empty! 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 49
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 50
Define Resources • We skip the next two screens and go to the “Resource Factories Referenced” selector. • Click Add. • A record referencing a Data. Source factory should appear. • Fill in the Coded Name field. A suitable name here is jdbc/Book. DB. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 51
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 52
Transaction Management • We skip a screen, and go to the “Transaction Management” selector. • We assume container-managed transactions, and set the transaction attribute for the business methods to Required. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 53
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 54
Review the Generated XML • That is the end of this sequence. The next screen just lets you review the generated XML for the deployment descriptor. • Assuming it looks OK, click finish. • Back in the main Application Deployment Tool window, you may want to save the jar using Save As on the File menu, e. g. you may save as Book. App. jar. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 55
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 56
Deploying the Application • With the application jar file—including the XML for the deployment descriptor—created, we can now physically deploy the bean in J 2 EE server and database. • If necessary, start the server, by issuing the command j 2 ee -verbose & • If necessary, start the database server, by issuing the command cloudscape -start • In the application deployment tool, select Add from the Server menu, and add a server, e. g. sirah. csit. fsu. edu 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 57
Generating SQL • We must generate the SQL commands for container managed persistence. • Back in the main tool, select the JAR file display name from the menu on the left. • Select the Entity tab. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 58
12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 59
Generating SQL • Click on Deployment Settings. • Enter the Database JNDI name, then click on Generate SQL Now. • In this example the container successfully generates all required—we do not need to define any SQL of our own. • You can study the generated SQL by clicking on an EJB Method item. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 60
Deployment Settings Dialog 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 61
Deploy the Application • Choose Deploy Application from the Tools menu. • Check Return Client jar, then click next. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 62
Deploy Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 63
Specify JNDI Names • We specify a couple of JNDI names: – The name for looking up the home interface is going to be My. Book. – We map jdbc/Book. DB to jdbc/Cloudscape. • Click next then finish. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 64
Deploy Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 65
Deploy Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 66
Run the Client • Add Book. App. Client. jar to your CLASSPATH $ CLASSPATH=${CLASSPATH}: Book. App. Client. jar • Then, at last, . . . $ java Book. Client Enterprise Java. Beans 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 67
Session Beans 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 68
Session Beans • Session beans do not model (persistent) data. • 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 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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 69
Session Beans Do Not. . . • Session beans do not have: – ejb. Post. Create() – ejb. Load() – ejb. Store() because they are not persistent. • Similarly, session beans do not have a primary key. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 70
Workflow with Session Beans • Session bean are 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 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 71
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 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 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 72
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 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 73
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. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 74
Bean Class import java. util. *; import javax. ejb. *; public class Cart. EJB implements Session. Bean { String customer. Name; Vector contents; public void ejb. Create(String person) throws Create. Exception { customer. Name = person; contents = new Vector(); } } 12/12/2021 . . . business and callback methods it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 75
Business Methods public class Cart. EJB implements Session. Bean {. . . public void add. Book(String title) { contents. add. Element(title) } public void remove. Book(String title) throws Book. Exception { boolean result = contents. remove. Element(title); if (result == false) throw new Book. Exception(title + “ not in cart. ”); } public Vector get. Contents() { return contents; }. . . } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 76
Callback Methods public class Cart. EJB implements Session. Bean {. . . public void ejb. Remove() {} public void ejb. Activate() {} public void ejb. Passivate() {} public void set. Session. Context(Session. Context sc) {} } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 77
Home Interface import java. rmi. Remote. Exception ; import javax. ejb. * ; public interface Cart. Home extends EJBHome { Cart create(String customer. Name) throws Remote. Exception, Create. Exception ; } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 78
Remote Interface import java. util. * ; import java. rmi. Remote. Exception ; import javax. ejb. * ; public interface Cart extends EJBObject { public void add. Book(String title) throws Remote. Exception ; public void remove. Book(String title) throws Book. Exception, Remote. Exception ; public Vector get. Contents() throws Remote. Exception ; } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 79
Deploying the Session Bean • This is similar to—but simpler than—the case of deploying an entity bean (discussed in the preceding lecture) • Run deploytool. • Select new application from the file menu. • Give application “display name” (eg Book. App) and a project file name. • In this case, we must remember to include the class file for the application exception, Book. Excepion, in the jar file. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 80
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 81
Basic Info • As before, select class files for Bean, home interface and remote interface. • Ensure Session is selected, then click the Stateful box. • In this example we will just click finish—we don’t have any database resources or transactional behavior to declare. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 82
New Enterprise Bean Wizard 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 83
Deployment • This example has no persistence, so we don’t have to define any SQL methods. • Select Deploy Application from the tools menu, and follow the same recipe as before. • In this case the only JNDI name is the home interface for the bean. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 84
Specify JNDI names 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 85
A Client import java. util. *; import javax. naming. Context; import javax. naming. Initial. Context; import javax. rmi. Portable. Remote. Object; public class Cart. Client { public static void main(String[] args) { try { Context initial = new Initial. Context(); Object objref = initial. lookup("My. Cart"); Cart. Home home = (Cart. Home)Portable. Remote. Object. narrow(objref, Cart. Home. class); Cart shopping. Cart = home. create("Duke De. Earl"); . . . Calls to business methods shopping. Cart. remove(); } catch (. . . ) {. . . } } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 86
…Calls to Business Methods shopping. Cart. add. Book("The Martian Chronicles"); shopping. Cart. add. Book("2001 A Space Odyssey"); shopping. Cart. add. Book("The Left Hand of Darkness"); Vector book. List = new Vector(); book. List = shopping. Cart. get. Contents(); Enumeration enumer = book. List. elements(); while (enumer. has. More. Elements()) { String title = (String) enumer. next. Element(); System. out. println(title); } shopping. Cart. remove. Book("Alice in Wonderland"); 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 87
Running the Client • In contrast to our first example, we illustrate here how to run an EJB client program on a machine different from the host running the EJB server. • The client machine should also have the J 2 EE software installed (even though it is not running a server). • Copy Cart. App. Client. jar and Cart. Client. class to this machine. • Then: % java -Dorg. omg. CORBA. ORBInitial. Host=sirah. csit. fsu. edu Cart. Client The Martian Chronicles 2001 A Space Odyssey The Left Hand of Darkness Caught a Book. Exception: Alice in Wonderland not in cart. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 88
Instance Pooling and Activation 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 89
Resource Management • The problem: – As client populations increase, the number of distributed objects and resources required increase. This may reduce performance or throughput. • EJB explicitly support two mechanisms that make it easier to manage large number of beans at runtime: instance pooling and activation. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 90
Instance Pooling • A commonly used technique is to pool database connections so that the business object in the system can share database access. • CTM apply resource pooling to server-side components. • Since the client never accesses beans directly, there is no fundamental reason to keep a separate copy of each bean for each client. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 91
How Pooling Works • When a client uses an EJB home to obtain a remote interface to a bean, the container responds by creating an EJB object. • Once created, the EJB object is assigned (perhaps only temporarily) a bean instance from the instance pool. • When a bean instance is assigned to an EJB object, it officially enters what is called the ready state. • From the ready state, a bean instance can receive requests from the client and callbacks from the container. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 92
Binding Bean Instance to EJB Object 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 93
Instance swapping • A bean instance can be returned to the instance pool during a lull between client requests to the EJB object. This allows for reuse of instances, and thus reduces the total number of instances that must exist simultaneously in the server. • When a client request is eventually received, a free instance is retrieved from pool and assigned to the EJB object. • This is called instance swapping. • The events associated with returning an instance to the pool, and retrieving a new instance as required, are called passivation and activation. – These operations are especially efficient for stateless session beans—using the swapping strategy allows a few stateless session beans to serve hundreds of client. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 94
12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 95
Bean Life Cycles • Each kind of bean—entity bean, stateful session bean, or stateless session bean—has a characteristic life cycle. • Important events in particular bean life cycles include creation, deletion, passivation, activation. • For each important event in the life cycle, the container will dispatch one or more call-back methods on the bean class. • This allows the bean class to carry out any operations peculiar to its own implementation that should accompany these transitions. – For example one may wish to free resources while in the passive state. – An especially important case is saving and restoring the bean’s own persistent state, in the case of bean classes implementing bean-managed persistence. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 96
Entity Beans • Entity beans have the most complex life cycle, so we will discuss them first. : -( • Three possible states are does not exist, pooled and ready. • A bean transitions from does not exist to pooled when the container decides it needs more instances. – Initially some fixed number of instances will be created. • A bean transitions from pooled to ready when a client invokes a suitable create() method. – And also during activation, see below. • A bean transitions from ready to pooled when the container determines it is not busy, and passivates it. – And also when a client invokes a remove() method on a bean, or the bean throws a system exception. • If a client (or another bean) invokes a business method on a passivated bean, it is activated again. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 97
The Life Cycle of an Entity Bean 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 98
Load and Store • The container will call the ejb. Load() and ejb. Store() whenever it determines that the state of the bean must be synchronized with the state of the underlying database. • This may be in response to transitions between pooled and ready states. • It may happen before or after random business methods, if the container thinks there is a possibility the database may be accessed and or changed by other agents. • It may be required at various points in a transaction processing protocol. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 99
Session Beans • A session bean is an agent that operates inside the EJB server, on behalf of some fixed client. The client can access remote services by invoking the session bean’s methods. • Session beans are divided into two basic types: stateless and stateful. • A stateless session bean is a collection of related services, each represented by a method. The bean maintains no state from one method invocation to the next. – It essentially provides an RPC service. • A stateful session bean is an extension of the client application. It performs tasks on behalf of the client and maintains state related to that client. – This is volatile state, preserved in the instance variables of the bean (not in a database). 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 100
Stateful Session Beans • Session beans are not pooled in the same way as entity beans, but they may still be passivated if the container determines too many sessions are active. • The three possible states are now does not exist, method-ready and passive. • A bean transitions from does not exist to method-ready when a client invokes a suitable create() method. • A bean transitions from method-ready to passive when the container determines it is not busy. • If the client invokes a business method on a passive session bean, it is activated again—returned to the method-ready state. • A bean returns to the does not exist state when a client invokes a remove() method on a bean, or the bean throws a system exception, or the container considers that the session has timed out. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 101
Life as a Stateful Session Bean 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 102
Stateful Session vs Entity Beans • Stateful session beans do not use instance pooling. – They are dedicated to one client for their entire life, so there is no swapping or pooling of instances. • Instead of pooling, stateful session beans are simply evicted from memory when this is necessary to conserve resources. – Instance variable holding conversational state are serialized. • If the bean class wants to manage this eviction and serialization process itself—or release resources while it is in the passive state—it can again do so in the ejb. Passivate() and ejb. Activate() methods. • Because there is no need to synchronize with a database, there are no ejb. Load() or ejb. Store() methods. • Sessions and thus session beans may time out. – Timeout intervals are declared at deployment time. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 103
Conversational State • To support passivation, the conversational state (instance variables) of a stateful session bean are limited to the following field types: – Primitive values, – Objects that are serializable, and the following special types: – javax. ejb. Session. Context – javax. ejb. EJBHome (home interface types) – javax. ejb. EJBObject (remote interface types) – javax. jta. User. Transaction (bean transaction interface) – javax. naming. Context (only when it references the JNDI ENC) • Fields declared transient will not be preserved when the bean is passivated. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 104
Stateless Session Bean • A stateless session bean is lightweight and fast. • Stateless session beans can’t remember anything from one method invocation to the next, which means that they have to take care of the entire task in one method invocation. • They can be pooled in a way similar to entity beans, but they need have no distinct “active” state. – The pooled state is the active state. • Any activity that can be accomplished in one method call is a good candidate for the high-performance stateless session bean. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 105
Life and Death of a Stateless Session Bean 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 106
Call-backs and All That 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 107
set. Entity. Context() • The first method called after an entity bean instance is created is set. Entity. Context(Entity. Context ctx) • It is called prior to the bean instance’s entry into the instance pool. • The Entity. Context allows the bean instance to obtain its own primary key and a remote reference to the EJB object • At the end of the bean instance's life, before the bean instance is garbage collected, the unset. Entity. Context() method is called. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 108
Entity Context • When a bean enters the ready state, it is populated with the appropriate data and assigned to the EJB object. • Its Entity. Context object changes state, so that the primary key and EJB object it returns match the EJB object the bean instance is now associated with. • The methods on Entity. Context are: public EJBObject get. EJBObject() throws Illegal. State. Exception public Object get. Primary. Key() throws Illegal. State. Exception • Because the bean instance's identity changes every time the bean is swapped into a different EJB object, the values returned by its Entity. Context change over its lifetime. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 109
Session Context • For a session bean the corresponding call-back is set. Session. Context(Session. Context ctx) • The Session. Context interface only supports the get. EJBObject() method (there is no primary key). • There is no unset. Session. Context() call-back. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 110
The ejb. Create() methods • For every create() method in a bean's home interface, there must be a matching ejb. Create() method in the bean instance class. • For entity beans the declared return type is the primary key type (although the actual value returned should be null unless the bean implements bean-managed persistence). – For session beans, the return type is void. • For entity beans, the ejb. Create() method is called just prior to writing the bean's container-managed fields to the database, in a new record. – The bean developer must ensure that the ejb. Create() method sets the persistent fields that correspond to the fields of the primary key. • Defined for entity beans only, the ejb. Postcreate() method may perform any post-processing on the new DB record. – Its return type is void. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 111
ejb. Load() and ejb. Store() • The are defined for entity beans only. • Just before the container read any container-managed fields, it calls the ejb. Store(). • Just after the container update any such fields, it call ejb. Load(). • They provide an opportunity to format the data from user input format to database field format. • They also play an essential role in bean-managed persistence. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 112
Bean-Managed Persistence • Bean-managed persistence is more complicated than container-managed persistence because you must explicitly write the persistence logic into the bean class. • Disadvantage – It ties the bean to a specific database type and structure • Advantage – It can better accommodate a complex or unusual set of data. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 113
A Bean-managed Book Entity • Referring back to our original Book example, we outline the changes necessary to implement bean-managed persistence. • The first requirement is a mechanism for connecting to the underlying database. • Then we have to reimplement various call-back methods to explicitly manipulate the database. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 114
Finding a Database • In the XML deployment descriptor for our application, we give a “resource reference name” for any databases to be accessed. – Typical naming convention is something like jdbc/Book. DB. • Any bean has an associated JNDI Environment Naming Context (ENC). – At deployment time an ENC name will be bound to a more global JNDI name, e. g. jdbc/Cloudscape. – The ENC is returned by the no-args constructor for Initial. Context. • Resource names accessed through ENC are prefixed by java: comp/env/. • The lookup() operation typically returns a javax. sql. Data. Source factory object. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 115
Data Source Factories • The details are outside our current scope, but in general Data. Source is an “enterprise” alternative to use of the Driver. Manager familiar from simple applications of JDBC. • The Data. Source interface supports simple JDBC connections as well as advanced services like connection pooling and distributed transactions. • Data. Source supports a get. Connection() method similar to Driver. Manager, but we don’t need to give a URL. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 116
Making the Connection • We may define a private method get. Connection() in our bean managed Book. Bean class for making the JDBC connection: private Connection get. Connection() throws SQLException { try { Context ctx = new Initial. Context() ; Data. Source ds = (Data. Source) ctx. lookup(“java: comp/env/jdbc/Book. DB”) ; return ds. get. Connection() ; // optionally pass DB account details } catch (Naming. Exception e) { throw new EJBException(e) ; } } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 117
ejb. Create() Method • A possible implementation of the ejb. Create() method, implementing bean-managed persistence: public Book. PK ejb. Create(int isbn){ this. isbn = isbn; try { Connection con = get. Connection() ; Statement s = con. create. Statement() ; s. execute. Update( “INSERT INTO Book (id, name) VALUES (” + id + “, ‘’)”) } catch (SQLException e) { throw new EJBException(e) ; } return Book. PK(isbn) ; } • In this case one must “manually” create a Book table in the database before deploying the bean. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 118
ejb. Load() Method • A possible implementation of the ejb. Load() method, implementing bean-managed persistence: public void ejb. Load(){ try { Connection con = get. Connection() ; Statement s = con. create. Statement() ; Result. Set rs = s. execute. Query( “SELECT name FROM Book WHERE id = ” + isbn) ; if(rs. next()) name = rs. get. String(1) ; else throw new EJBException(“. . . ”) ; } catch (SQLException e) { throw new EJBException(e) ; } } 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 119
Remarks • We can assume that the container has set the primary key field, isbn, before invoking ejb. Load(). • We must similarly define ejb. Store() in terms of an SQL UPDATE statement, and ejb. Remove() in terms of an SQL DELETE statement. • The method ejb. Find. By. Primary. Key() operation should be defined in terms of a SELECT method, but note that all it needs to do is check if the selected record exists in the table, throw an Object. Not. Found. Exception if it does not, otherwise return the input primary key. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 120
Transactions 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 121
A Transaction • Suppose our Cart. EJB session bean is extended with a business method that actually places an order for its current contents. • It does this by delegating the tasks of billing the customer and shipping the books to two other session beans: public void order. Contents() { Shipping. Home ship. Home = (Shipping. Home) get. Home(“Shipping. Home”, Shipping. Home. class) ; Shipping ship. Sess = ship. Home. create() ; Billing. Home bill. Home = (Billing. Home) get. Home(“Billing. Home”, Billing. Home. class) ; Billing bill. Sess = bill. Home. create() ; } ship. Sess. ship. To. Customer(contents) ; bill. Sess. bill. Customer. For(contents) ; 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 122
Atomic Transactions • The method order. Contents() must occur atomically. – If we are unable to ship the goods (for example, if they are not in stock) we must not bill the customer. – Conversely if the anything goes wrong in the billing operation (for example, the customer’s credit is not good) we should not ship the goods. • Guaranteeing this behavior in the presence the partial failures can that occur in distributed systems is surprisingly complicated. • A large industry and a huge literature has developed around this kind of issue. • EJB can be characterized as a system for transaction processing—in which case the business of guaranteed transactional behavior is a critical issue. – Not clear whether this is a very good characterization. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 123
ACID • It is known that a transaction must be: – Atomic – Consistent – Isolated – Durable • Few people understand what all this means, but it is presumably important. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 124
Declarative Transaction Management • Transaction management is relatively straightforward under EJB. • One simply declares a set of transactional attributes for the business methods. – The container will understand these attributes and make your software transactionally secure. • Behind the scenes the container may be using APIs like – OTS from OMG – JTS, the Java binding of OTS – JTA, a higher level Java Transaction API. • As with persistence, you can override container managed transactions, and implement bean-managed transactions by explicitly calling JTA. – Only experts are supposed to do this. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 125
Transaction Scope • In declarative transaction management, the most critical issue is to define the scope of a transaction—the set of operations that is collected together in a transaction. • Once the scope of individual transactions is defined, the container can arrange that the operations concerned are either all committed, i. e. made permanent, or all rolled back, when the transaction finishes. – Exactly how “commitment” or “rolling back” are achieved in general is not obvious. In general it presumably requires that the entities responsible for the operations engage explicitly in JTA or OTS protocols. – However, in the case of database operations handled through container-managed persistence, things should be relatively straightforward, since JDBC supports transactional operations. • All operations will be rolled back if a system error like EJBException is thrown during the transaction. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 126
Transaction Attributes • In EJB 1. 1 there are 6 possible transaction attributes that can be specified for a business method: – Not. Supported – Supports – Required – Requires. New – Mandatory – Never • These attributes are specified in the deployment descriptor. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 127
The Deployment Descriptor <ejb-jar>. . . <assembly-descriptor>. . . <container-transaction> <method> <ejb-name>Cart. EJB</ejb-name> <method-name>order. Contents</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar> 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 128
The Not. Supported Attribute • The Not. Supported Attribute means that the method will have no transactional context even if it is called from a method that does. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 129
The Supports Attribute • The Supports attribute means that the method will inherit the transactional context of its calling method. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 130
The Required Attribute • The Required Attribute means that the method will start a new transaction if there is none on-going in the calling method. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 131
The Requires. New Attribute • The Requires. New attribute means that the method will start a new transaction even if it is called from a method that is already executing in a transaction. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 132
The Mandatory Attribute • The Mandatory attribute means that an exception will be thrown if the method is called from a method that has no transactional context. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 133
The Never Attribute • The Never attribute means that an exception will be thrown if the method is called from a method that has a transactional context. 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 134
Life Cycle with Transactions 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 135
Security 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 136
Security • Authentication – authentication validates the identity of the user. – It is fairly crude because it doesn’t police an authorized user’s access to resources within the system. • Access control – apply security policy that regulate what a specific user can and can not do within a system. – different users have different right to access the resources (such as customer and manager) • Secure communication – encrypting the communication between the client and server ( such as SSL). 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 137
Access control example <security-role> <description> This role is allowed to execute any method on the bean. They are allowed to read and change any cabin bean data. </description> <role-name> Administrator </role-name> </security-role> <description> This role is allowed to locate and read cabin info. This role is not allowed to change cabin bean data. </description> <role-name> Read. Only </role-name> </security-role> 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 138
Access control example <method-permission> <role-name>Administrator</role-name> <method> <ejb-name>Book. EJB</ejb-name> <method-name>*</method-name> </method-permission> <role-name>Read. Only</role-name> <method> <ejb-name>Book. EJB</ejb-name> <method-name>get. Name</method-name> </method> <method> <ejb-name>Book. EJB</ejb-name> <method-name>find. By. Primary. Key</method-name> </method-permission> 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 139
Access control example • First we define the role: Read. Only and Administrator • Second we use the role to define every method. • We put this piece of code inside XML deployment descriptor so that specific user groups have access privileges to specific methods on specific beans 12/12/2021 it 2 ejb http: //aspen. csit. fsu. edu/it 2 spring 01 140
- Slides: 140