WebLogic Server EJB Container


Our discussion of WebLogic Server EJB features will concentrate on features useful in the creation of classic n -tier J2EE applications using EJB components for the business tier of the application. We ll start with a brief review of the EJB container and the life cycle of EJB components in the WebLogic Server container implementation. The next section documents WebLogic Server EJB features common to many of the EJB component types. The bulk of the chapter is then spent discussing features applicable to specific types of EJB components.

There are so many EJB- related features and configuration parameters in WebLogic Server that we had to make some choices in the interest of space. The theme for this book is best practices, after all, and some advanced features and capabilities represent more useful and important concepts for typical J2EE applications than others. The next chapter is intended to apply the best practices discussed here in a realistic J2EE application.

EJB Container Basics

The EJB container is a fundamental part of the EJB architecture. In a nutshell , the EJB container provides the environment used to host and manage the EJB components deployed in the container. The container is responsible for providing a standard set of services, including caching, concurrency, persistence, security, transaction management, and locking services. The container also provides distributed access and lookup functions for hosted components, and it intercepts all method invocations on hosted components to enforce declarative security and transaction contexts.

The EJB container is not a single Java class, nor is it a single API or service accessible to the contained components or external client code. It is more of an abstract concept implemented by each server vendor in a unique fashion. Note that most of the unique features of WebLogic Server described in the remaining sections of this chapter are actually features of the EJB container itself.

EJB Life Cycle in WebLogic Server

One of the key responsibilities of the EJB container is the management of EJB component life cycles. Bean instances are pooled and reused by the container to host specific beans in an effort to reduce the number of object instantiations . Rather than spend time reviewing the complex and confusing processes involved in pooling, passivation, activation, and other memory-management issues, we ll take a more pragmatic approach by concentrating on the key life-cycle events of an EJB component from the point of view of a client of the component.

Given that approach, the life cycle of a standard entity bean, for example, becomes fairly simple:

  1. The client obtains a reference to the entity bean in some way, possibly using a finder method or by traversing a bean relationship.

  2. The client invokes a business method on the reference. We ll assume no transaction is active.

  3. The container starts a transaction, if appropriate.

  4. The container reuses an existing instance from the pool, if available, or instantiates a new bean instance and initializes its context by calling setEntityContext() .

  5. The container loads the bean s state from the persistent store, either automatically or by calling ejbLoad() .

  6. The container invokes a desired business method on behalf of the client. The bean performs the desired operation.

  7. The container saves bean attributes to the persistent store, either automatically or by calling ejbStore() .

  8. The container commits the transaction created for this life cycle, if appropriate.

  9. The results of the business-method call are returned to the client.

Everything revolves around the transaction boundaries. By default, the container always loads and stores standard entity beans on transaction boundaries. The life cycle described here should be taken as the baseline or worst case for an entity bean, and many EJB optimization and caching techniques are intended to improve performance by reducing the work in each step or eliminating steps completely. Note that we ve used the term standard entity bean in this section to indicate a normal, read-write entity bean with no special configuration flags or deployment descriptors used to modify the default life cycle, as described by the EJB specification.

The life cycle of a stateless session bean is simpler than an entity bean because there are no persistence requirements:

  1. The client obtains a reference to the stateless session bean home interface.

  2. The client uses the create() method on the home interface to create an SLSB and obtain a reference.

  3. The client invokes a business method on the bean reference.

  4. The container reuses an existing instance from the pool, if available, or instantiates a new bean instance and initializes its context by calling setSessionContext() .

  5. If the bean instance was newly created in Step 4, the container invokes ejbCreate() on the bean instance; otherwise , it skips this step.

  6. The container starts a transaction, if appropriate.

  7. The container invokes a business method on the bean instance, and the bean performs the desired operation.

  8. The container commits the transaction, if appropriate.

  9. The results of the business-method call are returned to the client.

  10. The client may invoke additional business methods on the bean reference, each of which may end up invoking methods on a different bean instance.

  11. The client calls remove() on the bean reference when it is done with the SLSB as a way of letting the container know that the client is through with the reference.

  12. At some point, if the container decides to reduce the size of the bean instance pool, the container invokes ejbRemove() on the bean instance. It is important to understand that this decision is not related to the client calling remove() .

Note that setSessionContext() or ejbCreate() are good places to preload cached data in an SLSB instance or perform other initialization steps such as JNDI lookups. Although SLSBs are stateless from the point of view of the client, the bean instances are reused and may take advantage of cached data in internal member variables .

The life cycle of a stateful session bean is controlled by the client explicitly through the create() and remove() methods:

  1. The client obtains a reference to the stateful session bean home interface.

  2. The client uses one of the create() methods on the home interface to create an SFSB and obtain a reference.

  3. The container instantiates a new bean instance and initializes its context by calling setSessionContext() .

  4. The container invokes the corresponding ejbCreate() method on the bean instance.

  5. The client invokes a business method on the bean reference.

  6. The container starts a transaction, if appropriate.

  7. The container invokes a business method on the bean instance, and the bean performs the desired operation.

  8. The container commits the transaction, if appropriate.

  9. The results of the business-method call are returned to the client.

  10. The client may invoke additional business methods on the bean reference and is assured that these additional calls will go to the same instance of the bean.

  11. The client calls remove() on the bean reference when it is done with the SFSB.

  12. The container calls ejbRemove() on the bean instance, allowing it to clean up any resources before it is removed.

Like SLSB components, setSessionContext() and ejbCreate() are called once when a SFSB instance is created and are appropriate places for creating internal caches or performing other initialization steps. Of course, the cache is specific to the particular client s session so you could just as easily use lazy initialization because, either way, the client will be waiting on the initialization work.

This very brief introduction to the life cycle of various EJB components represents a simplified view of the process. Additional complexities are introduced by limitations in the pool and cache sizes that you need to understand to configure your application properly. We ll cover some of these complexities in a subsequent section on setting pool sizes and configuring passivation.




Mastering BEA WebLogic Server. Best Practices for Building and Deploying J2EE Applications
Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications
ISBN: 047128128X
EAN: 2147483647
Year: 2003
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net