Security options, interceptor methods, and transaction management for session beans and message-driven beans in EJB 3.0 projects

You can use domain modeling class diagrams to define security options, create interceptor methods, and add transaction management on session beans and message-driven beans in Enterprise JavaBeans 3.0 (EJB 3.0) projects.

Security options

For session beans, you can define the following security options:
  • Declare roles
  • Run as
  • Roles allowed
  • Permit all
For session bean methods, you can define the following security options:
  • Declare roles
  • Roles allowed
  • Permit all
  • Deny all

You must define declare roles before you set roles allowed.

When you use permit all, deny all, and roles allowed annotations, observe the following restrictions:
  • permit all, deny all, and roles allowed annotations cannot apply to the same method or class
  • In the following cases, the method level annotations take precedence over the class level annotation:
    • Permit all is specified at the class level while roles allowed or deny all are specified on methods of the same class
    • Deny all is specified at the class level while permit all or roles allowed are specified on methods of the same class
    • Roles allowed is specified at the class level while permit all or deny all are specified on methods of the same class
  • The use default security option applies only to a method; this option clears all the security settings on the method and uses the class level for security settings

Interceptor methods

You can use domain modeling class diagrams to create simple Java™ class and add interceptor methods on method calls or the life-cycle event of EJB 3.0 session and message-driven beans.

You can use interceptor methods to intercept either a business method or a life-cycle event. You can use the following Interceptor methods to define methods:
  • AroundInvoke
  • PreConstruct
  • PrePassivate
  • PostActivate
  • PreDestroy
An interceptor that intercepts a business method is called an AroundInvoke method because it can be defined by annotating the method with an @AroundInvoke annotation. For example, you can define an AroundInvoke method by annotating the method with an AroundInvoke annotation, or you can define it through an element in the deployment descriptor. An AroundInvoke method must meet the following requirements:
  • One AroundInvoke method is allowed for each class
  • It must have a no arg public constructor
  • It must take a javax.interceptor.InvocationContext object as an argument and return a java,lang.Object object
  • It can throw any application exception that is specified in the business interface, or any runtime exception
  • It can be declared private, package private, protected, or public
  • It must call InvocationContext.proceed() to signal its intention to continue the invocation

Transaction management

You can use domain modeling class diagrams to create transaction management types for session or message-driven beans. The transaction management annotation specifies the transaction management demarcation type of a session bean or message-driven bean. If the transaction management annotation is not specified for a session bean or message-driven bean, the bean is assumed to have container-managed transaction demarcation.

Transaction attributes

You can use class diagrams to add transaction attributes to session or message-driven beans. The javax.ejb.TransactionAttribute annotation, or @TransactionAttribute, can be applied to bean methods. This only applies if the bean transaction management type is a container.

When you use the @TransactionAttribute annotation, you must specify one of the six different transaction attribute types that are defined by the javax.ejb.TransactionAttributeType enumeration:
  • TransactionAttributeType.MANDATORY
  • TransactionAttributeType.REQUIRED
  • TransactionAttributeType.REQUIRES_NEW
  • TransactionAttributeType.SUPPORTS
  • TransactionAttributeType.NOT_SUPPORTED
  • TransactionAttributeType.NEVER

Feedback