2.3 Platform Services

J2EE platform services simplify application programming and allow components and applications to be customized at deployment time to use resources available in the deployment environment. This section gives a brief overview of the J2EE platform naming, deployment, transaction, and security services.

2.3.1 Naming Services

J2EE naming services provide application clients, enterprise beans, and Web components with access to a JNDI (described in Section 2.4.3) naming environment. A naming environment allows a component to be customized without the need to access or change the component's source code. A container implements the component's environment, and provides it to the component as a JNDI naming context.

A J2EE component locates its environment naming context using JNDI interfaces. A component creates a javax.naming.InitialContext object and looks up the environment naming context in InitialContext under the name java:comp/env. A component's naming environment is stored directly in the environment naming context, or in any of its direct or indirect subcontexts.

A J2EE component can access named system-provided and user-defined objects. The names of system-provided objects, such as JTA UserTransaction objects, are stored in the environment naming context, java:comp/env. The J2EE platform allows a component to name user-defined objects, such as enterprise beans, environment entries, JDBC DataSource objects, and message connections. An object should be named within a subcontext of the naming environment according to the type of the object. For example, enterprise beans are named within the subcontext java:comp/env/ejb and JDBC DataSource references in the subcontext java:comp/env/jdbc.

2.3.2 Deployment Services

J2EE deployment services allow components and applications to be customized at the time they are packaged and deployed.

J2EE applications are deployed as a set of nested units. Each unit contains a deployment descriptor, an XML-based text file whose elements declaratively describe how to assemble and deploy the unit into a specific environment. Deployment descriptors contain many elements related to customizing J2EE platform services such as transactions and security.

The following sections give an overview of J2EE platform deployment services. Deployment services are discussed in detail in Chapter 7.

2.3.2.1 Deployment Units

A J2EE application consists of one or more J2EE modules and one J2EE application deployment descriptor. An application deployment descriptor contains a list of the applications's modules and information on how to customize the application. A J2EE application is packaged as a Java Archive (JAR) file with an .ear (Enterprise ARchive) extension.

A J2EE module consists of one or more J2EE components for the same container type and one component deployment descriptor of that type. A component deployment descriptor contains declarative data to customize the components in the module. A J2EE module without an application deployment descriptor can be deployed as a stand-alone J2EE module.

The three types of J2EE modules are:

• Enterprise JavaBeans modules contain class files for enterprise beans and an EJB deployment descriptor. EJB modules are packaged as JAR files with a .jar extension.
• Web modules contain JSP files, class files for servlets, GIF and HTML files, and a Web deployment descriptor. Web modules are packaged as JAR files with a .war (Web ARchive) extension.
• Application client modules contain class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a .jar extension.

2.3.2.2 Platform Roles in the Deployment Process

Each J2EE platform role performs specific activities related to deployment. An Application Component Provider specifies component deployment descriptor elements and packages components into modules. An Application Assembler resolves references between modules and assembles modules into a single deployment unit. A Deployer creates links between entities referred to by the application and entities in the deployment environment.

2.3.3 Transaction Services

Transactions divide an application into a series of indivisible or "atomic" units of work. A system that supports transactions ensures that each unit fully completes without interference from other processes. If the unit can be completed in its entirety, it is committed. Otherwise, the system completely undoes (rolls back) whatever work the unit had performed. Transactions simplify application development because they free the Application Component Provider from the complex issues of failure recovery and multi-user programming.

Transactions, as provided by the J2EE platform, have the following characteristics:

• J2EE transactions are flat. A flat transaction cannot have any child (nested) transactions.
• The J2EE platform implicitly handles many transaction details, such as propagating information specific to a particular transaction instance, and coordinating among multiple transaction managers.

The following sections give an overview of J2EE platform transaction services. Transaction services are discussed in detail in Chapter 8.

2.3.3.1 Accessing Transactions

A JTA transaction is a transaction that can span multiple components and resource managers. A resource manager local transaction is a transaction that is specific to a particular enterprise information system connection.

JTA transactions are created and managed using the javax.transaction.UserTransaction interface. Different types of components access UserTransaction objects in different ways:

• Enterprise beans provide a mechanism for JTA transactions to be started automatically by their containers. Enterprise beans that use bean-managed transactions (described in Section 2.3.3.3) use the method EJBContext.getUserTransaction to look up the UserTransaction object.
• Applets and application clients may or may not be able to directly access a UserTransaction object depending on the capabilities provided by the container. However, they can always invoke enterprise beans that use a UserTransaction object.
• Web components use JNDI to look up the UserTransaction object.

A resource manager local transaction is created and managed in a manner specific to a particular connection. For example, each SQL statement executed on a JDBC connection has its own transaction.

2.3.3.2 Web Component Transactions

Web components (JSP pages and servlets) are not designed to be transactional. Because of this, Application Component Providers should only perform transactional work directly in Web components on a very limited basis. Preferably, an Application Component Provider should delegate transactional work to the appropriate enterprise beans. When an enterprise bean is used to perform transactional work, the enterprise bean or container takes care of properly setting up the transaction.

Nevertheless, there are times when a Web component may need to directly demarcate transactions. It can do so using the javax.transaction.UserTransaction interface. You should however, be aware of limitations in transaction propagation and state isolation, as described in the following discussions.

Transaction Propagation

Transactions are propagated from a Web component to an enterprise bean only when the Web component starts the transaction using the UserTransaction interface. Since Web components are server-side components, Web browsers and other clients don't have direct access to transactions and so a transaction initiated by a Web component cannot be propagated from the client of the component or between Web components and transactional resources such as JDBC connections.

State Isolation

A Web component can keep state for the lifetime of a client session or component. However, because Web components are not transactional components, their state cannot be isolated based on transactions. For example, separate servlets will see the same state of a client session even if they each start their own transaction.

2.3.3.3 Enterprise Bean Transactions

The J2EE platform provides two styles of transaction demarcation for enterprise beans: bean-managed and container-managed.

With bean-managed transaction demarcation, the enterprise bean is required to manage all aspects of a transaction. This entails operations such as:

• Creating the transaction object
• Explicitly starting the transaction
• Completing the transaction. There are two basic ways of completing a transaction:

With container-managed transaction demarcation, the EJB container handles transaction management. The container performs the transaction demarcation based on the Application Assembler's deployment instructions; it handles starting and ending the transaction, plus it maintains the transaction context throughout the life of the transaction object. This greatly simplifies an Application Component Provider's responsibilities and tasks, especially for transactions in distributed environments.

Session beans, both stateful and stateless varieties, can use either container- or bean-managed transactions. However, a bean cannot use both types of transaction at the same time. The Application Component Provider decides the type of transaction demarcation that a session bean will use and must declare the transaction style via attributes in the enterprise bean's deployment descriptor. The attributes indicate whether the bean or container will manage the bean's transactions and, if the latter, how the container will manage the transactions. Entity beans can only use container-managed transaction demarcation.

2.3.4 Security Services

The J2EE platform security services are designed to ensure that resources are accessed only by users authorized to use them. Access control involves two steps:

1. Authentication--An entity must establish its identity through authentication. It typically does so by providing authentication data (such as a name and password). An entity that can be authenticated is called a principal. A principal can be a user or another program. Users are typically authenticated by logging in.
2. Authorization--When an authenticated principal tries to access a resource, the system determines whether the principal is authorized to do so based on the security policies in force in the application's security policy domain.

The following sections give an overview of J2EE platform security services. Security services are discussed in detail in Chapter 9.

2.3.4.1 Security Methodologies

Containers provide two security methodologies: declarative and programmatic. Declarative security refers to the means of specifying an application's security structure in a form external to the application. An Application Component Provider specifies declarative security in a component's deployment descriptor. Programmatic security refers to security mechanisms accessed within a program. An Application Component Provider accesses programmatic security for EJB and Web components with J2EE platform security APIs.

2.3.4.2 Authentication

The J2EE platform allows an Application Component Provider to choose how a principal is authenticated. A Web client can provide authentication data to a Web container using HTTP basic authentication, digest authentication, form-based authentication, or certificate authentication.

With basic authentication, the Web server authenticates a principal using the user name and password obtained from the Web client. Like basic authentication, digest authentication authenticates a user based on a user name and a password. However, the authentication is performed by transmitting the password in an encrypted form, which is much more secure than the simple base64 encoding used by basic authentication. With form-based authentication, the Web container can provide an application-specific form for logging in. With certificate authentication, the client uses a public key certificate to establish its identity and maintains its own security context.

There is no way to authenticate to an EJB container. However, authentication data is also often required when an enterprise bean accesses an external resource. An enterprise bean can provide authentication data to a resource directly, or it can request the container to perform this service for it. If the Application Component Provider specifies that the container should propagate authentication data, the Deployer specifies the authentication data for each resource factory reference declared by the enterprise bean, and the container uses the authentication data when obtaining a connection to the resource.

2.3.4.3 Authorization

J2EE platform authorization is based on the concept of security roles. A security role is a logical grouping of users that is defined by an Application Component Provider or Application Assembler. Each security role is mapped by a Deployer to principals in the deployment environment. A security role can be used with declarative security and/or programmatic security.

An Application Component Provider or Application Assembler can control access to an enterprise bean's methods by specifying the method-permission element in the enterprise bean's deployment descriptor. The method-permission element contains a list of methods that can be accessed by a given security role. If a principal is in a security role allowed access to a method, the principal may execute the method. Similarly, a principal is allowed access to a Web component only if the principal is in the appropriate security role. An Application Component Provider controls access programmatically by using the EJBContext.isCallerInRole or HttpServletRequest.isRemoteUserInRole methods.

For example, suppose a payroll application specifies two security roles: employee and administrator. Salary update operations are executable only by a principal acting in the role of administrator, but salary read operations are executable by both roles. When the payroll application is deployed, the Deployer provides a mapping between the set of administrator and employee principals (or groups) and their respective roles. When the salary update method is executed, the enterprise bean's container can check whether the principal or group propagated from the Web server is in a role that can execute that method. Alternatively, the method itself could use one of the security APIs to perform the check.