1 technologies for an information age:.opennet enterprise javabeans fall semester 2001 mw 5:00 pm -...
TRANSCRIPT
1
Technologies for an Information Age: .opennet
Enterprise JavaBeans
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 Computer Science,
Informatics, Physics
Indiana University
Bloomington IN 47404
2
Basic .opennet Architecture This is .opennet
structureDatabase
(Virtual) XML Layer
Enterprise Javabeans
Java
Servlet
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.Remote marker 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
ClientCode Stub
RMI“Run-time”
System
RemoteObject
Call stub methodlocally
Return valueor throw exception
Call remote object method locally
Return valueor throw exception
Send marshaledarguments
Send marshaledresult or
exception
Remote object implementation classand stub both implement same interface
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
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.
Remarks
31
Example Bean Classimport 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.
The ejbCreate() 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
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.
Example Bean Class (Continued)
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 Keypublic 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 Clientpublic 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
51
Instance Pooling and Activation
52
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 supports two mechanisms that make it easier to manage large number of beans at runtime: instance pooling and activation.
53
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.
54
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.
55
Binding Bean Instance to EJB Object
56
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.
57
Instance Swapping
58
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.
59
Entity Beans Entity beans have the most complex life cycle—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.
60
The Life Cycle of an Entity Bean
61
Load and Store
The container will call the ejbLoad() and ejbStore() 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.
62
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).
63
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.
64
Life As a Stateful Session Bean
65
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 ejbPassivate() and ejbActivate() methods.
Because there is no need to synchronize with a database, there are no ejbLoad() or ejbStore() methods.
Sessions and thus session beans may time out.– Timeout intervals are declared at deployment time.
66
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.SessionContext – javax.ejb.EJBHome (home interface types)– javax.ejb.EJBObject (remote interface types)– javax.jta.UserTransaction (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.
67
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.
68
Life and Death of a Stateless Session Bean
69
Transactions
70
A Transaction
Consider a session bean with a business method that places an order for its currently selected items.
It does this by delegating the tasks of billing the customer and shipping the books to two other session beans:
public void orderContents() { ShippingHome shipHome = (ShippingHome) getHome(“ShippingHome”,
ShippingHome.class) ; Shipping shipSess = shipHome.create() ; BillingHome billHome = (BillingHome) getHome(“BillingHome”,
BillingHome.class) ; Billing billSess = billHome.create() ;
shipSess.shipToCustomer(contents) ; billSess.billCustomerFor(contents) ;}
71
Atomic Transactions The method orderContents() 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 large literature, has developed around this kind of issue.
EJB can be characterized as a system for transaction processing—in which case the issue of guaranteed transactional behavior is a critical issue.
72
ACID
It is widely considered that a transaction must be:– Atomic– Consistent– Isolated– Durable
73
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.
74
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.
75
Transaction Attributes
In EJB 1.1 there are 6 possible transaction attributes that can be specified for a business method:– NotSupported– Supports– Required– RequiresNew– Mandatory– Never
These attributes are specified in the deployment descriptor.
76
The Deployment Descriptor
<ejb-jar> . . . <assembly-descriptor> . . . <container-transaction> <method> <ejb-name>CartEJB</ejb-name>
<method-name>orderContents</method-name> </method> <trans-attribute>Required</trans-
attribute> </container-transaction> </assembly-descriptor></ejb-jar>
77
The NotSupported Attribute
The NotSupported Attribute means that the method will have no transactional context even if it is called from a method that does.
78
The Supports Attribute
The Supports attribute means that the method will inherit the transactional context of its calling method.
79
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.
80
The RequiresNew Attribute
The RequiresNew 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.
81
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.
82
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.
83
Life Cycle With Transactions
84
Security
85
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).
86
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>
<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> ReadOnly </role-name></security-role>
87
Access Control Example
<method-permission> <role-name>Administrator</role-name> <method> <ejb-name>BookEJB</ejb-name> <method-name>*</method-name> </method></method-permission></method-permission> <role-name>ReadOnly</role-name> <method> <ejb-name>BookEJB</ejb-name> <method-name>getName</method-name> </method> <method> <ejb-name>BookEJB</ejb-name> <method-name>findByPrimaryKey</method-
name> </method></method-permission>
88
Remarks
First we define the role: ReadOnly 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