|
|
This topic includes the following sections:
The Enterprise JavaBeans Specification 1.1, published by Sun Microsystems, Inc., defines a component architecture for building distributed, object-oriented business applications in Java. The EJB architecture addresses the development, deployment, and run-time aspects of an enterprise application's lifecycle.
An EJB encapsulates business logic inside a component framework that manages the details of security, transaction, and state management. Low-level details, such as the following, are handled by the EJB container:
Overview of the WLE EJB Programming Environment
This built-in, low-level support allows the EJB to focus on the business problem to be solved.
With the WLE EJB model, you can write or buy business components (such as invoices, bank accounts, and shipping routes) and, during deployment into a certain project, specify how the component should be used -- which users have access to which methods, whether the container should automatically start a transaction or whether it should inherit the caller's transaction, and so on. In this scenario, an EJB contains the business logic (methods) and the customization needed for a particular application (deployment descriptor), and the EJB will run within any standard implementation of the EJB container. An EJB is, in essence, a distributed object for which transactions and security can be specified declaratively in deployment descriptors.
The spirit of "write once, run anywhere" carries through into EJB: any vendors's EJB container (that conforms to the EJB Specification) can run any third-party EJBs (that also conform to the EJB Specification) to create an application. Nuances of the security mechanisms and specific distributed transaction monitors are entirely abstracted out of the application code (unless the Bean Provider chooses to make such calls explicitly).
With the WLE system, you can build and deploy standard, portable EJBs. The EJB Specification defines three types of beans:
Types of Beans Supported in WLE
An entity EJB can save its state in any transactional or nontransactional persistent storage, or it can ask the EJB container to save its nontransient instance variables automatically. The WLE system allows both choices. An EJB that manages its own persistence is referred to as having bean-managed persistence; an EJB that delegates to the EJB container the saving and restoring of its state is referred to as having container-managed persistence.
You control the persistence characteristics of a bean, such as where its data is maintained in durable storage, in its deployment descriptor; in the case of bean-managed persistence, you implement the specific method invocations in the bean that load and store state.
For more information about development and deployment considerations with regards to persistence, see the following sections in this guide:
EJBs and Persistence
The Enterprise JavaBeans Specification describes the six roles regarding who develops, builds, deploys, and administers an EJB application. These roles are summarized in the following table to help clarify what needs to be done, by whom, and when during the entire life cycle of an EJB in a way that is consistent with the EJB Specification.
Roles of People Who Develop, Build, Deploy, and Administer EJBs
This section summarizes all the items you need to create for an EJB application that runs in the WLE environment, regardless of which role you are assuming, and explains where you can find more information about creating the item.
Items You Create for an EJB Application
To help application programmers and deployers build EJBs that fully leverage the WLE system, the WLE software provides the tools and facilities listed in the following table:
Tools and Facilities Provided for Building and Deploying EJBs
For more information about deploying and administering EJB applications in the WLE environment, see Building and Deploying Enterprise JavaBeans (EJBs).
The WLE system provides the following failover characteristics of EJB applications deployed in a WLE domain. Note that client applications cannot control where EJBs are instantiated. The following figure shows how, in the instance of a machine crash, failover is managed wholly by the WLE system.
Stateless session beans. If the server process hosting a stateless session bean fails, the bean is automatically instantiated in a different server process (on the same server or on another group within the domain), provided that the server process that is capable of supporting the session bean is available.
Entity beans. If one group that hosts one or more entity beans fails and in cases when the client application receives a RemoteException
, the client application can invoke the findByPrimaryKey
method to find the home interface for the entity bean, with the specified unique key, on another group in the domain. This works as long as the other group is configured to support that entity bean. Application developers can write client application code within a loop that begins by invoking the findByPrimaryKey
method; this way, if a group fails, the client application retries the invocation on a different group.
Note that, for bean-managed persistence, the Bean Provider must implement this method explicitly; for container-managed persistence, this method is generated automatically.
Stateful session beans. If one group fails, the administrator must dynamically configure the group on a different machine. For more information, see Configuring a Running System in the WebLogic Enterprise online documentation.
For file-based persistence, recovery depends on whether persistence storage resides on a file system that is still network accessible (for example, an NFS-mounted volume). Because the persistence-store-directory-root
element in the WLE EJB extensions to the deployment descriptor DTD specifies the path for persistent storage, the bean's state can be recovered. (Note that this file persistence mechanism is internal to the WLE system.)
For JDBC-based persistence, the application simply reconnects to the database, as long as the DBMS node is running and the network is accessible to the new node.
Note:
In general, you should use JDBC-based persistence for production applications because it is more robust than file-based persistence. File-based persistence is typically appropriate only for development and prototyping purposes.
EJBs and Failover in the WLE Environment
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|