IBM Labs in Haifa

Enterprise Java Beans (part II)

Tal Cohen

tal@forum2.org

IBM Labs in Haifa

Outline of Part II

Developing EJB Clients Transactions EJB Query Language Exceptions in EJBs EJB Security

IBM Labs in Haifa

Developing EJB Clients

IBM Labs in Haifa

Reminder: Clients can be Applications or Servlets

Web server (running servlets, JSPs)

Acts as EJB clientEJB server Database/legacy server

Home user

Runs Internet Browser

Bank clerk, running a Java app (using

Swing, etc.) that acts as an EJB client

RMI/IIOP

RMI/IIOP

JDBC(over

TCP/IP?)

HTTP

IBM Labs in Haifa

Who Can Act as an EJB Client?

Other EJBs Servlets Java Applications

Require a special launcher (which provides services such as JNDI, etc.), or else a very careful setup (classpath, JVM version, etc.)

Java Applets Given the proper security permissions

Non-Java Clients EJBs are compatible with CORBA

IBM Labs in Haifa

Reminder: How an EJB Client Should Act

1. Client looks up a bean home object using JNDI 2. Client creates or finds EJB 3. Client uses EJB business methods from the component interface

IBM Labs in Haifa

Sample Code Step 1: JNDI Lookup

// Obtain an Initial Context:Hashtable properties = new Hashtable();properties.put(INITIAL_CONTEXT_FACTORY,

"com.ibm.websphere.naming.WsnInitialContextFactory");properties.put(PROVIDER_URL, "iiop://");InitialContext iCtx = new InitialContext(properties);

// Lookup, and narrow the object:Object homeRef = iCtx.lookup("AccountHome"); // JNDI nameAccountHome home = (AccountHome) PortableRemoteObject.narrow(homeRef, AccountHome.class);

Hashtable values are vendor- specific; read from configuration

file if possible.

In practice, a parameter-less version of this constructor can

often be used.

CORBA narrowing required since the object passed over an IIOP connection. For local home interfaces, a simple downcast can be used.

IBM Labs in Haifa

Sample Code Step 2: Using the Home Interface

// Use the home interface to create new EJBs:Account acc1 = home.create("Joe", "Average");

// Or use the finder methods to locate existing EJBs:Account acc2 = home.findByPrimaryKey(12345);

Collection fatAccounts = home.findClientsByMinimalBalance(100000);

Any find/create method, defined in the home interface and implemented in the bean class (or with EJB QL), can be used to create/locate EJBs.

IBM Labs in Haifa

Sample Code Step 3: Using the EJB References

// Simply invoke business methods:acc1.setBalance(acc1.getBalance() - 100);acc2.setBalance(acc2.getBalance() + 97); // Commission...

for (Iterator i = facAccounts.iterator(); i.hasNext(); ) {Account fatAccount = (Account) i.next();fatAccount.setMaxCredit(1000000);

}

IBM Labs in Haifa

Remember Possible Exceptions...

Finders can throw FinderException Create methods can throw CreateException Business methods can throw business-related exceptions Any of them could throw RemoteException

Use proper try/catch blocks

IBM Labs in Haifa

Serializing EJB References

Be careful when using EJB references in contexts that could require serialization e.g., HttpSession objects are often serializable

Use getHandle to obtain a handle to the EJB reference Handle object is serializable

Use getEJBObject method to recover EJB reference from the handle.

IBM Labs in Haifa

The Home Factory Pattern

The first step for every EJB client is JNDI lookup Common pattern: create a home factory Usage:

ClientHome = (ClientHome) HomeFactory.lookup("JNDI_Name", "ClientHome");

The factory class provides a single static method -- lookup Narrows the result and returns an Object to be downcast The second parameter is the class name, used for narrowing

Using "class.forName(name)" Internally, the factory caches the InitialContext object

Can also provide an API for obtaining it

IBM Labs in Haifa

The Session Facade Pattern

Used for minimizing: Client/entity bean coupling Risk of client using unapproved business methods

Or using approved business methods in unapproved ways Network delays Points of change if high-level business operations are modified

The idea: create a Session EJB that provides high-level business methods Client should only work with the session bean(s) Entity EJBs provide (possibly only) a local interface

Session EJB accesses entity EJBs locally

IBM Labs in Haifa

Session Facade Example: Transferring funds

Client code without the facade: Find Account home Find accounts a1, a2 by primary keys k1, k2 a1.setBalance(a1.getBalance() - amount); a2.setBalance(a2.getBalance() + amount);

Client code with the facade: Find TransferBean home, create TransferBean t1 t1.transfer(k1, k2, amount);

IBM Labs in Haifa

Resulting Benefits

Faster operation 1 JNDI lookup, 1 remote object lookup and 1 remote business

method vs. 1 JNDI lookup, 2 remote object lookups and 4 remote business methods in the old code

Easier maintenance If we have two different clients (servlet, application) and we wish to

change the transfer semantics (e.g., add logging), there's only one place to change

Increased security Client can't invoke Account.setBalance directly, since Account

has no remote component interface

IBM Labs in Haifa

Other Recommended Practices

Avoid calling EJB methods directly from JSP The need to catch remote exceptions would complicate the JSP

code Use wrappers or 'access objects'

Some can be generated automatically by WebSphere AD Avoid hard-coding JNDI properties

Store configuration hashtable values in a file Avoid hard-coding JNDI resource names

IBM Labs in Haifa

Transactions

IBM Labs in Haifa

What is a Transaction?

A transaction is a set of operations that moves data from one consistent state to another

The set of operations is considered indivisible Allows the bundling of discrete operations

If one or more operations fail, the entire set is undone Success: the transaction "commits" Failure: the transaction "rolls back"

The effect of the transaction preserves data invariants The effects of a committed transaction are persistent Transactions seem to execute serially

For example: transferring funds from one account to another

IBM Labs in Haifa

Transaction Definitions

Transactional Object: An object which is used (methods invoked) within a transaction Can only be associated with one transaction at a time EJBs can be transactional objects

Transactional Client: A problem which invokes methods on transactional objects

Transaction Manager: A program that coordinates transaction processing

IBM Labs in Haifa

The Transaction Context

A single transaction can involve multiple objects and operations A transaction context represents the transaction shared by all these

participants By default, it is automatically propagated between transactional objects

(EJBs).

IBM Labs in Haifa

Java APIs for Transactions

The Java Transaction API (JTA) is used by application developers Specifies the interface between the transaction manager and all

involved objects Main class: the UserTransaction interface.

The Java Transaction Service (JTS) is used by developers of transaction managers Developers of application servers, EJB containers, etc. Not used by application developers

IBM Labs in Haifa

Transaction Demarcation with EJBs

Normally, you simply do nothing: use container-managed transaction demarcation (CMT)

The EJB container manages transactions automatically Interaction with databases Starting and ending transactions Creating and propagating the transaction context Even two-phase commit (2PC)

For databases with JDBC drivers that support XA You can dictate the transactional behavior of specific methods

No programming required -- just edit the deployment descriptor XML In addition, bean-managed transaction demarcation (BMT) and client-

managed transaction demarcation are also available.

IBM Labs in Haifa

Transaction Attribute Values

When using CMT, beans (or specific methods within beans) have a transaction attribute

One of six possible values: NotSupported Supports Required RequiresNew Mandatory Never

IBM Labs in Haifa

Transaction Attribute Values: Supports and NotSupported

Supports: If the invoker (client, or a different method) has a transaction

context, it is propagated to the bean If not, no transaction context is used Use this for "don't care" situations

NotSupported: If the invoker has a transaction context, it is suspended for the

duration of this method's execution If not, no transaction context is used Either way, the method executes without transaction context

IBM Labs in Haifa

Transaction Attribute Values: Required and RequiresNew

Required: If the invoker has a transaction context, it is propagated to the bean If not, the container creates a new transaction context I.e., the method always executes within a transaction context, but

does not create a new transaction needlessly This is the default value

RequiresNew: If the invoker has a transaction context, it is suspended for the

duration of this method's execution Either way, a new transaction context is created Use when you want the method to execute within a transaction, but

you do not want failure to cause failure in a wider transaction

IBM Labs in Haifa

Transaction Attribute Values: Mandatory and Never

Mandatory: If the invoker has a transaction context, it is propagated to the bean Otherwise, an exception is thrown

TransactionRequiredException or TransactionRequiredLocalException

Use when you want the invoker to provide the transaction Does not necessarily imply BMT or client managed transactions: the

invoker can be a different method in the same EJB Never:

If the invoker has a transaction context, an exception is thrown RemoteException or EJBException

Otherwise, the method proceeds normally, without a context Used for non-transactional resources

IBM Labs in Haifa

Transaction Attribute Values: Summary

Invoker's transaction context Method's action

Supports T1 Use T1

None Work with no transaction context

NotSupported T1 T1 suspended

None Work with no transaction context

Required T1 Use T1

None Create and use T2

RequiresNew T1 T1 suspended, create and use T2

None Create and use T2

Mandatory T1 Use T1

None Throw exception

Never T1 Throw exception

None Work with no transaction context

IBM Labs in Haifa

Aborting a Transaction

If a business method wishes to abort a transaction, it should invoke setRollBackOnly on its EJB context object Usually done before throwing an application exception

Use getRollBackOnly to find out if you're "running on empty"

IBM Labs in Haifa

Bean-Managed Transactions

This feature is available for session and message-driven EJBs only A business method can use JTA create a new UserTransaction

object (effectively initiating a transaction), and use it as its own transaction context UserTransaction methods of note: begin, commit, rollback, setRollbackOnly

This method will be propagated when invoking method on other EJBs (depending on the invoked methods' settings)

The bean that created the transaction is responsible for committing/rolling it back In stateless session beans, the method that initiated the transaction

must end it. An instance that starts a transaction must complete it before starting a

new one.

IBM Labs in Haifa

Client-Managed Transactions

Don't.

IBM Labs in Haifa

Concurrent Access to Entity Beans

Concurrent access by multiple clients is allowed if: Each client has its own transaction, or Clients share a transaction and all calls are local

i.e., all clients access the entity bean via its local interface Concurrent access by multiple clients might fail if clients share a

transaction, use remote calls Support is not required by the EJB specification If the container does not support this, RemoteException will be

thrown

IBM Labs in Haifa

Loopbacks and Reentrancy

An entity bean may not be entered twice simultaneously from within the same transaction:

Note that the client can itself be an EJB, and the transaction could have been automatically initiated by the container

To detect and prevent this, entity EJBs are normally marked as non-reentrant.

Client(initiates transaction)

Session

Session

Entity

Exception

thrown

IBM Labs in Haifa

Loopbacks and Reentrancy (cont.)

But sometimes reentrancy is required, for valid loopbacks:

To enable such loopbacks, you should mark the entity bean as reentrant In the deployment descriptor

Problem is, now illegal concurrent access will not be detected Try to avoid algorithms that require loopbacks.

Client Entity Session

IBM Labs in Haifa

The SessionSynchronization Interface

Stateful session EJBs (only) that use container-managed transactions can request notifications for transaction events Enables the bean to maintain a cache that will remain synchronized

with the DB To do this, the bean should simply implement

SessionSynchronization There are three methods in this interface:

afterBegin beforeCompletion

Your chance to abort the transaction by calling setRollbackOnly on the session context

afterCompleteion(boolean) The parameter indicates commit (true) or rollback

IBM Labs in Haifa

Recommended Practices for Using Transactions

Always prefer container-demarcated transactions. Prefer Required, RequiresNew and Mandatory over other options

Supports, NotSupported and Never are not implemented by all containers - compromises portability

WebSphere implements them all

IBM Labs in Haifa

EJB Query Language

IBM Labs in Haifa

What is EJB QL

A query language used with CMP mappings For finders and select methods

(Note: We did not cover entity EJB select methods; details later) Technically, a "modified subset" of SQL More portable than SQL

Supported by all J2EE servers Normally compiled to the application server's native query language

In other words, compiled to the app server's SQL variant

IBM Labs in Haifa

An EJB QL Query

EJB QL includes only SELECT queries Each query includes three parts:

SELECT FROM WHERE (optional)

The query may have parameters The parameters passed to the finder methods

IBM Labs in Haifa

EJB QL Example 1

SELECT DISTINCT Object(c) FROM Customer c

Finds all customers Returns a collection Will not return duplicates (because of DISTINCT) "Object" is required for all stand-alone identification variables in a

SELECT clause "Customer c" declares the identification variable "c" of type

"Customer" Type defined by abstract schema "Customer AS c" has the same meaning

IBM Labs in Haifa

EJB QL Example 2

SELECT DISTINCT Object(c) FROM Customer c, IN (c.accounts) a WHERE a.balance < 0.0

Returns all customers with at least one account in overdraft "IN (c.accounts) a" follows Customer's container-managed

relationship "accounts" "WHERE a.balance < 0.0" has the same semantics as a regular

SQL WHERE clause, limiting the result set

IBM Labs in Haifa

EJB QL Example 3

SELECT DISTINCT Object(c) FROM Customer c WHERE (c.address.country = ?1) AND (c.address.city = ?2)

This SQL query accepts two parameters Appear as "?1" and "?2" in the code

Can be used to implement a finder method that accepts two parameters Would return all customers from a given city in a given country

IBM Labs in Haifa

Select Methods

Select methods are similar to finders: In entity bean class, must begin with "ejbSelect" In CMP entity beans, define as abstract

And provide relevant EJB QL statement in deployment descriptor In BMP entity beans, implement manually Return type is the bean's component interface, or a collection

Unlike finders, select methods are not reflected in the home interface They are for the bean's own use

IBM Labs in Haifa

Exceptions in EJBs

IBM Labs in Haifa

Exception Types

In J2SE, there are two types of exceptions: Runtime exception Checked exceptions

For EJBs, we use a completely different distinction: Application exceptions

Business-logic related System exceptions

Represent system-level problems Note that J2SE Errors still loom in the background (JVM-level problems)

IBM Labs in Haifa

Application Exceptions

Normal exceptions to report business-logic problems e.g., public void withdraw(float amount) throws OverdraftException

It is the client's role to recover (or just report) such exceptions "The client" here doesn't refer to the client application, but to

whomever invoked the method -- client application, or just another EJB method

Application exceptions must be subclasses of Exception, but must not be subclasses of RuntimeException (i.e., must be checked)

IBM Labs in Haifa

Application Exceptions (cont.)

If an application exception is thrown, and not caught, on the server, it is send to the client As with regular RMI, the client simply invokes a method and gets an

exception in return -- completely transparent.

CreateException, FinderException and RemoveException are all considered application exceptions

IBM Labs in Haifa

System Exceptions

Used to report system-level problems Failure to locate a JNDI context Failure to obtain a database connection Communications problem ... etc.

Clients are not supposed to handle system exceptions In case of a system exception, the bean should:

Runtime exceptions: propagate the exception to the container All other cases: wrap in a new EJBException, and rethrow

IBM Labs in Haifa

Exceptions and Transactions

An application exception does not abort the transaction However, note that if the exception causes the method that initiated

the transaction to end, than the transaction will be stopped If the client invokes m1, m1 initiates the transaction (due to its

Requires attribute) and invokes m2, and m2 throws an application exception, then m1 can try to continue the transaction

If m1 throws (or does not catch) an application exception, the transaction will roll back

A system exception aborts the transaction The container will log the error and mark the transaction "rollback

only" Any attempt to proceed with the transaction would be futile

IBM Labs in Haifa

The "Generic Application Exception" Pattern

A common pattern suggests defining a superclass for all your application exceptions "MyAppException" or whatever

All business methods should be declared as "throws MyAppException" in the bean class and the component interface Even if they throw no exception whatsoever

This way, the clients will have to be written with proper try/catch block surrounding all business calls Should your beans evolve and methods suddenly do throw

exceptions, the clients need not be modified Through they could be modified to be aware of the specific possible

exception In practice, makes all application exceptions work like runtime

exceptions.

IBM Labs in Haifa

EJB Security

IBM Labs in Haifa

Security Goals

Portability should not be affected Transparency, Isolation and Abstraction

Application developers should not need to know anything about security

Application deployers can manage security without modifying the code

Extensibility Flexibility

The security mechanism should not impose a specific policy Implementation Independence Secure Interoperability

Across servers, server vendors, etc.

IBM Labs in Haifa

J2EE Security Terminology

A principal is something that can be authenticated For example, a user or a server

Each principal has an associated set of security attributes Used to identify which resources the principal can access Also used for auditing

A principal is identified using credentials A credential contains or references security attributes Credentials are acquired via authentication Credentials can also be acquired through delegation from another

principal

IBM Labs in Haifa

Container-Based Security

Security for components is provided by the container in which they run Declarative security: defined using deployment descriptors

Includes definition of security roles, access control rules and authentication requirements

Mapped by the application deployer to the specific runtime environment

Programmatic security: explicit use of security APIs by application code Provides increased flexibility

e.g., the same method can function differently for different pricipals Key methods: getCallerPrincipal and isCallerInRole,

defined in EJBContext.

IBM Labs in Haifa

Authentication in J2EE

J2EE does not dictate any authentication method Each implementation should provide its own authentication tools Common solutions include authentication via HTTP, HTTPS (HTTP over

SSL), and form-based authentication There are also solutions for non-web-based authentication An implementation could rely on OS-provided authentication services

e.g., user login under Unix or NT

IBM Labs in Haifa

Responsibilities in EJB Security

IBM Labs in Haifa

The Bean Provider's Role

Security mechanisms should not be implemented in EJBs Security policies should not be hard-coded

The same application, when deployed by different companies, could use different policies

Conclusion: The bean provider should not be involved in EJB security. The bean provider can convey security requirements (e.g., what roles he

assumes are defined) via the deployment descriptors

IBM Labs in Haifa

APIs Available for the Bean Provider

getCallerPrincipal returns the current caller's principal name Can be used for logging, or as a key for accessing database

information No assumptions should be made regarding specific names

i.e., avoid code like if (principal.equals("root")) ... isCallerInRole(String roleName) allows the bean provider to

code security checks that cannot be defined using method permissions A method that will behave differently for different users In many cases, it is better to simply provide different methods, each

with its own role requirements

IBM Labs in Haifa

Role References

The bean provider cannot assume that any specific role name (e.g., "superuser", "administrator", etc.) will be defined in the runtime environment

Thus, the bean provider defines and uses only role references The definition appears in the deployment descriptor For example:

<security-role-ref><description>Security role for customers</description>

<role-name>customer</role-ref></security-role-ref>

The references are mapped to available roles by the application assembler.

IBM Labs in Haifa

The Application Assembler's Role

The application assembler defines security roles Often, the application assembler and the bean provider are the

same person (or company) Maps these security roles to role references (defined by the bean

provider) Specifies method permissions for each security role

This is sometimes left to the application deployer Requires that the application deployer be familiar with the nature of

all EJB methods

IBM Labs in Haifa

Method Permissions

The application assembler (or deployer) can specify which methods can be invoked by which roles

For example:<method-permissions>

<role-name>client</role-name><method>

<ejb-name>Account</ejb-name><method-name>getBalance</method-name>

</method>... more methods ...

</method-permissions><method-permissions>

<role-name>clerk</role-name><method>

<ejb-name>Account</ejb-name><method-name>*</method-name>

</method></method-permissions>

IBM Labs in Haifa

Security Identities

When an EJB method is invoked, it is always with a given security identity A principal and one or more roles

Normally, when EJB method m1 invokes method m2, m2 is invoked with the same security identity

However, the application assembler can specify that a given method is always invoked using some specific identity Only applies when the method is invoked by another bean method Does not apply to direct invocation

Cannot be used to bypass security limitations

IBM Labs in Haifa

J2EE Security in WebSphere

WebSphere provides two authentication mechanisms: Simple WebSphere Authentication Mechanism (SWAM)

Easy to configure Well-suited for a single-server environment

Lightweight Third-Party Authentication (LTPA) Works by generating security tokens Tokens can be passed between servers

Enables "single sign-on" -- user does not have to logon multiple times

Works well in single- and multiple-server environments

IBM Labs in Haifa

J2EE Security in WebSphere (cont.)

WebSphere supports three different user registries: Local OS registries

Unix, NT login authentication Limited support for distributed environments

Lightweight Directory Access Protocol (LDAP) registries Industry standard (IBM SecureWay, Sun ONE, Microsoft Active

Directory, Lotus Domino, ...) Preferred registry

Custom user registry Role your own Must implement WebSphere-supplied interfaces Can be used to implement a JDBC-based registry

IBM Labs in Haifa

Conclusion

IBM Labs in Haifa

What Are EJBs

The J2EE Component Model Can be used to manage session information or to represent persistent

data Allows the developer to focus on each aspect independently

The business logic is unaffected by security policies, transaction management, etc.

Complies well with Aspect-Oriented Software Development notions and buzzwords

Helps prevent code tangling Cross-cutting concerns (security, concurrency, etc.) are handled in a

centralized manner

IBM Labs in Haifa

Should EJBs Be Used?

EJBs have proved to be a powerful, scaleable solution in many large applications

However, not all J2EE applications must use EJBs Sometimes, you can use only part of the technology (esp. session beans

without entity beans) There are other solutions to mapping persistent data

e.g., Java Data Objects But entity beans are more mature, complete, flexible and scaleable

EJBs are extremely useful in multiple-client type scenarios e.g., web and Java application clients In some applications, Web Services are sometimes viewed as an

additional possible EJB client