Transactions in the Deployment Descriptor

Transactions in the Deployment Descriptor

The transactional properties of a bean are defined in three steps.

Step 1

In the first step the bean provider specifies whether transactions are to be managed by the EJB container or the bean. The bean provider gives these instructions exclusively in the bean's deployment descriptor.

In the case of explicit transaction management of the bean, the bean provider defines the transaction type Bean in the bean's deployment descriptor in the segment enterprise-beans:


In the case of declarative transaction management no specifications about the transactional properties are made in the bean's deployment descriptor. These are established only in the following steps, with the transaction attributes.

Step 2

In the second step the application assembler defines the transaction attributes. The application assembler makes specifications about the bean exclusively in the section assembly-descriptor.

A separate transaction attribute can be specified for each permitted method. This defines the transactional behavior of the bean with implicit transaction management by the EJB container.

The EJB specification gives precise instructions as to which methods from the home and remote interfaces can be assigned to a transaction attribute:

  • for session beans, only for the defined business methods;

  • for entity beans, for the defined business methods and also for the methods find, create, and remove from the home interface.

The EJB specification specifies three different forms for keeping the definition in the deployment descriptor simple and understandable:

  1. The same transaction attribute is assigned to all methods of a bean:


  2. One transaction attribute is assigned to one method name. If there are several methods with the same name but with differing parameters, then the transaction attribute is assigned to all these methods:


  3. One transaction attribute is assigned to exactly one method. The method is completely specified by its name and parameter types:


    It is possible that methods will exist with identical signatures in the home and remote interfaces. With the additional attribute method-intf one can differentiate between Home and Remote:


These three systems can also be used simultaneously. In this case the more precise definition always takes precedence over the less precise.

Step 3

In the third step the deployer can change and extend the instructions in the application assembler. The deployer must ensure that for each bean with implicit transaction management a unique transaction attribute is defined for each method.

Chapter 8: Security


This chapter is concerned with the protection of data against unauthorized access in an Enterprise JavaBeans application. The security of systems for implementation throughout an enterprise is a large and extensive topic. A strategy for addressing the following topics is necessary in the design of such systems:

  • Identification of users (authentication);

  • Access restriction (authorization);

  • Secure data transfer (encryption);

  • Management of user data, certification, etc.

The relevant security concepts are components of the Java 2 Enterprise Edition (J2EE) together with certain extensions. The most important extensions of the Java platform in the area of security are the Java Cryptography Extension (JCE; see the reference [30]), the Java Authentication and Authorization Service (JAAS; see [31]), and the Java Secure Socket Extension (JSSE; see [32]).

JCE might be considered a library for data encryption that allows seamless integration of the components of the Java run-time environment into the Java platform via the security API (package*). JSSE is a library for encrypted data transfer over network sockets (secure socket layer, or SSL), which allows integration into the Java platform as seamless as that of the JCE. Thanks to the flexible architecture of the Java run-time environment (see, normal network sockets can be replaced by secure network sockets of JSSE without the overlying layers being affected. JAAS is a service for the authentication and authorization of users that is provided to an application over a separate API.

A product that supports these security mechanisms enables the configuration and administration of the corresponding services and provides the developer the relevant Java interfaces. These security mechanisms are of a fundamental nature and affect Enterprise JavaBeans only indirectly. This chapter concentrates on the security concepts of the EJB architecture, which are specified for every EJB container by the EJB specification. Extensive information on these topics can be found in [11] and [16]. The EJB security management specification has a distinct focus on flexibility and portability.

In this chapter we consider the following topics:

  • Definition of roles: Enterprise Beans work with defined roles, which are mapped to users or user groups. Users and user groups are defined externally to the EJB container.

  • Access to the identity of a user and its roles: In the context of every Enterprise Bean (class EJBContext) there are methods available for access to the user. Furthermore, checking of role membership is possible.

  • Access protection for methods: For methods of the home and remote home interfaces of an Enterprise Bean one can define the roles that users must possess in order for them to be allowed to call the methods.

  • Execution of Enterprise Beans with a defined user context: It is possible to configure an Enterprise Bean in such a way that its methods are not executed in the context of the registered user, but in another user context.

The following sections are devoted to exploring these topics in detail. An overview is given in Figure 8-1.

click to expand
Figure 8-1: Schematic representation of EJB security.

In addition to the defined security concepts, the EJB container can offer additional services, such as certificate management or a key service. The EJB container offers such services via JNDI in the bean's environment. However, whoever uses such services risks limiting Enterprise Bean portability, since another EJB container may not offer those services, or offer them in a different form.