Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Developer's Guide to Enterprise JavaBeans Technology 

Chapter 1
Sun Java System Application Server and Enterprise JavaBeans Technology

This section provides an overview of how the Java™ 2 Platform, Enterprise Edition (J2EE™ platform) Enterprise JavaBeans™ (EJB™) technology works in the application programming model of the Sun Java™ System Application Server Standard and Enterprise Editions 7.1 environment.


Note

If you are unfamiliar with the EJB technology, refer to the Java Software tutorials:

http://java.sun.com/docs/books/tutorial/

and the J2EE specifications:

http://java.sun.com/products/

Overview material on the Sun Java System Application Server is contained in the Sun Java System Application Server Product Introduction.


This section addresses the following topics:

Relevant files supplied with the Sun Java System Application Server are contained in the following locations:


Summary of EJB 2.0 Changes

Sun Java System Application Server supports the Sun Microsystems Enterprise JavaBeans (EJB) architecture as defined by the Enterprise JavaBeans Specification, v2.0 and is compliant with the Enterprise JavaBeans Specification, v1.1.


Note

You can deploy existing 1.1 beans in the Sun Java System Application Server, but new beans should be developed as 2.0 enterprise beans.


This section summarizes the changes in the Enterprise JavaBeans Specification, v2.0 that impact enterprise beans in the Sun Java System Application Server environment:


EJB Architecture

The Sun Java System Application Server reduces the complexity of developing middleware by providing automatic support for middleware services such as transactions, security, database connectivity, and more.

The following figure illustrates where enterprise beans fit in the J2EE environment. In this figure the client machine is running a web browser or application client, the J2EE server machine is running (or hosting) the Sun Java System Application Server, and the database server machine hosts the databases, such as Oracle and LDAP. Enterprise beans reside in the business tier, with JavaServer Pages™ (JSP™ pages) and servlets providing the interface to the client tier, and the Sun Java System Application Server managing the relationships between the client and database machines.

Figure shows Sun Java System Application Server archtitecture. Illustrates client tier, web tier, business tier, EIS tier.

The Sun Java System Application Server is responsible for providing the base of the EJB execution systems, which include:

The following figure illustrates further details of the J2EE environment. The business logic layer shows the EJB flow.

Figure shows detailed J2EE environment. Illustrates the contents and flow of the client layer, the presentation layer,  the business logic layer, and the data access layer.


Value Added Features

The Sun Java System Application Server provides a number of value additions that relate to EJB development. These capabilities are discussed in the following sections (references to more in-depth material are included):

Read-Only Beans

Another feature that the Sun Java System Application Server provides is the read-only bean, an entity bean that is never modified by an EJB client. Read-0nly beans avoid database updates completely.

A read-only bean can be used to cache a database entry that is frequently accessed but rarely updated (externally by other beans). When the data that is cached by a read-only bean is updated by another bean, the read-only bean can be notified to refresh its cached data.

The Sun Java System Application Server provides a number of ways by which a read-only bean’s state can be refreshed. By setting the refresh-period-in-seconds element and the transaction attribute of the bean, it is easy to configure a read-only bean that is (a) always refreshed, (b) periodically refreshed, (c) never refreshed, or (d) programmatically refreshed.

Read-only beans are best suited for situations where the underlying data never changes, or changes infrequently. For further information and usage guidelines, see “Read-Only Beans” on page 65.

pass-by-reference

The pass-by-reference element in the sun-ejb-jar.xml file allows you to specify the passing method/argument type used by enterprise beans. This is an opportunity to improve performance. See “pass-by-reference” on page 191.

Pooling and Caching Features

The Sun Java System Application Server provides a highly configurable bean pooling mechanism that allows the deployer to configure bean pools according to the needs of the enterprise.

In addition, the Sun Java System Application Server supports a number of tunable parameters that can be used to control the number of beans cached as well as the duration they are cached. Multiple bean instances that refer to the same database row in a table can be cached.

Refer to Pooling and Caching for information on this functionality.

Monitoring

The Sun Java System Application Server supports monitoring of many aspects of the runtime environment, including various elements of the EJB container which can be useful for debugging your application's correctness as well as tuning its performance.

See the Sun Java System Application Server Administration Guide (Monitoring and Managing Sun Java System Application Server section) and the Performance Tuning Guide for more information on monitoring.

Integration with Sun ONE Studio 5

Sun ONE Studio 5, Enterprise Edition for Java is an integrated development environment (IDE) that allows you to create, assemble, deploy, and debug code in the Sun Java System Application Server from a single, easy-to-use interface. Behind the scenes, a plug-in integrates the Sun ONE Studio 5 IDE with the Sun Java System Application Server.

For more information about using the Sun ONE Studio 5, see the Sun ONE Studio 5, Enterprise Edition tutorial and CMP Mapping with the Sun ONE Studio 5 Interface.

Dynamic Deployment and Reloading

You can deploy, redeploy, and undeploy an application or standalone module. If this is done while the server is running, it is considered dynamic. The following dynamic processes are available in Sun Java System Application Server:

For more information on dynamic deployment, refer to the Sun Java System Application Server Developer’s Guide and Administration Guide.

High Availability and Load Balancing

Stateful session bean sessions and HTTP sessions can be saved in a persistent store in case a server instance fails. For more information, see “Stateful Session Bean Failover (Enterprise Edition)” on page 51, the Sun Java System Application Server Administration Guide, and the Sun Java System Application Server Developer’s Guide to Web Applications.

Sticky round-robin load balancing is supported in the Sun Java System Application Server through the load balancer plug-in for web servers. For information about the load balancer plug-in, see the Sun Java System Application Server Administration Guide.


About Enterprise JavaBeans

If you are already familiar with enterprise beans and how they work, you may prefer to proceed to About Developing an Effective Application.

The following topics are discussed in this section:

What Is an Enterprise JavaBean?

An enterprise bean, or Enterprise JavaBean (EJB), is a self-contained, reusable component that has data members, properties, and methods. Each enterprise bean encapsulates one or more application tasks or objects, including data structures and operation methods.

For several reasons, enterprise beans simplify the development of large, distributed applications.

Types of Beans

There are three distinct types of enterprise beans:

EJB Flow

When a user invokes a Sun Java System Application Server servlet from a browser, the servlet may invoke one or more enterprise beans. For example, the servlet may load a JavaServer Page (JSP) to the user’s browser to request a user name and password, then pass the user input to a session bean to validate the input.

Figure shows EJB flow, from user interface to database and back.

After a valid user name and password combination is accepted, the servlet might instantiate one or more entity and session beans to run the application’s business logic, then terminate. The beans themselves might instantiate other entity or session beans to do further business logic and data processing.

Sample Scenario

A servlet invokes a session bean that gives a customer service representative access to an order database. This access might include the ability to:

As part of the customer order process, a servlet creates a session bean that manages a shopping cart to keep temporary track of items as a customer selects them. When the order completes, the shopping cart data transfers to the order database and the shopping cart session bean is freed.

The EJB Container

Enterprise beans always work within the context of a container. The container serves as a link between the enterprise beans and the hosting server. The EJB container enables distributed application building using your own components and components from other suppliers.

Through the container, the Sun Java System Application Server provides high-level transaction management, security management, state management (persistence), multithreading, and resource pooling wrappers, thereby shielding you from having to know the low-level API details. By handling concurrency, the container shields you from worry about entities (hence, threads) simultaneously accessing an enterprise bean. This container provides all standard container services denoted by the Enterprise JavaBeans Specification, v2.0, and also provides additional services specific to the Sun Java System Application Server.

The Sun Java System Application Server services include remote access, naming service, security service, concurrency, transaction control, and database access. The following figure illustrates the EJB container provided by the Sun Java System Application Server.

Figure shows EJB container components.

Interfaces

A client never accesses session or entity EJB instances directly. Instead, a client uses the bean’s remote interface to access a bean instance. The EJB object class that implements a bean’s remote interface is provided by the container.

Home Interface

The home interface provides a mechanism for clients to create and destroy and find EJBs. The EJB supplies a home interface for the container that extends the javax.ejb.EJBHome interface defined in the EJB specification. At its most basic, the home interface defines zero or more create methods for each way to create a bean.

Entity beans must define finder methods for each way that can be used to look up a bean or a collection of beans.

Remote Interface

A remote interface (and remote home interface) provides a mechanism for remote clients to access session or entity beans. A remote client can be another EJB deployed in the same or a different container, or a Java program, such as an application, applet, or servlet. The remote client view of an EJB is location independent and can be mapped to non-Java client environments.

The remote home interface is defined by the EJB developer and implemented by the EJB container.

Local Interface

A local interface (and local home interface) provides a mechanism for a client that is located in the same Java™ Virtual Machine (JVM™) with the session or entity bean to access that bean.This provides the local client view. A local client may be tightly coupled to the associated bean; session and entity beans can have many local clients.

The container provides the class that implements the local home interface and local interface. The objects that implement these interfaces are local Java objects. The local client view of an EJB is not location independent.

The following diagram shows a local client connecting through the local interfaces within the two enterprise beans in the container.

Figure shows a client on the Java Virtual Machine using local interfaces in the container to connect to EJBs.

The local interface may be defined for a bean during development, to allow streamlined calls to the bean if a caller is in the same container.

Pooling and Caching

The EJB container of the Sun Java System Application Server pools anonymous instances (message-driven beans, stateless session beans, and entity beans) to reduce the overhead of creating and destroying objects. The EJB container maintains the free pool for each bean that is deployed. Bean instances in the free pool have no identity (that is, no primary key associated) and are used to serve the method calls of the home interface. The free beans are also used to serve all methods for stateless session beans.

Bean instances in the free pool transition from a Pooled state to a Cached state after ejbCreate and the business methods run. The size and behavior of each pool can be controlled using the pool-related properties in the server.xml and sun-ejb-jar.xml files.

The EJB container caches "stateful" instances (stateful session beans and entity beans) in memory to improve performance. The EJB container maintains a cache for each bean that is deployed.

To achieve scalability, the container will selectively evicts some bean instances from the cache, usually when cache overflows. These evicted bean instances return to the free bean pool. The size and behavior of each cache can be controlled using the cache-related properties in the server.xml and sun-ejb-jar.xml files.

Pooling and caching parameters for the sun-ejb-jar.xml file are discussed in “Pooling and Caching Elements” on page 208.

Pooling Parameters

One of the most important parameters of Sun Java System Application Server pooling is steady-pool-size. When steady-pool-size is set to greater than 0, the container not only pre-populates the bean pool with the specified number of beans, but also attempts to ensure that there is always this many beans in the free pool. This ensures that there are enough beans in the ready to serve state to process user requests.

Another parameter, pool-idle-timeout-in-seconds, allows the administrator to specify, through the amount of time a bean instance can be idle in the pool. When pool-idle-timeout-in-seconds is set to greater than 0, the container removes/destroys any bean instance that is idle for this specified duration.

Caching Parameters

Sun Java System Application Server provides a way that completely avoids caching of entity beans, using commit-c option. Commit-c option is particularly useful if beans are accessed in large number but very rarely reused. For additional information, refer to “Commit Options” on page 153.

The Sun Java System Application Server caches can be either bounded or unbounded. Bounded caches have limits on the number of beans that they can hold beyond which beans are passivated. For stateful session beans, there are three ways (LRU, NRU and FIFO) of picking victim beans when cache overflow occurs. Caches can also be configured to passivate beans that were idle (not accessed for a specified duration) to be passivated.

How Enterprise Beans Access Resources

Enterprise beans can access a wide variety of resources, including databases, JavaMail™ sessions, JMS objects, and URLs. The J2EE platform provides mechanisms that allow you to access all of these resources in a similar manner.

This section discusses the following:

JNDI Connection

J2EE components locate the objects they need to access by invoking the lookup method of the Java Naming and Directory Interface™ (JNDI) API. The value returned by this call represents the object that the caller wants to access. In the case of an enterprise beans, the lookup call returns an object reference to the home interface of the bean. This reference may be used for all future invocations on the EJB home interface.

Context initial = new InitialContext();
  Object objref =
initial.lookup("java:comp/env/ejb/CompString");

A J2EE component on the server (a JSP, servlet, or enterprise bean) that wants to access a deployed enterprise bean, uses an EJB reference element in its deployment descriptor to specify this access. The EJB reference is mapped at deployment time to the JNDI name corresponding to the enterprise bean that the component wishes to access. This mapping serves to decouple components accessing enterprise beans from the JNDI names of the beans being accessed. Thus, the JNDI name to which an EJB's home is bound may be changed at deployment time without requiring the caller's code to change.

Database Connection

The persistence type of an enterprise bean determines whether or not you will code the connection routine for accessing a database.

URL Connections

A Uniform Resource Locator (URL) specifies the location of a resource on the web, such as web pages. These URLs then can be mapped to JNDI names so that developers can lookup the URLs.

Transaction Management

By dividing the application’s work into units called transactions, you are freed from dealing with the complex issues of database failure recovery and maintaining database integrity.

As a developer, you can choose between using programmatic transaction demarcation in the EJB code (bean-managed) or declarative demarcation (container-managed). Regardless of whether an enterprise bean uses bean-managed or container-managed transaction demarcation, the burden of implementing transaction management is on the EJB container and the Sun Java System Application Server. The container and the server implement the necessary low-level transaction protocols, such as the two-phase commit protocol, between a transaction manager and a database system or Sun Java™ System Message Queue.

For information on transaction handling, refer to “Handling Transactions with Enterprise Beans” on page 149.

How Application Security Works

The J2EE application programming model insulates developers from mechanism-specific implementation details of application security. For the most part, the container provides the implementation of the security infrastructure. J2EE provides this insulation in a way that enhances the portability of applications, allowing them to be deployed in diverse security environments with no additional coding.

The declarative security mechanisms used in an application are expressed in the deployment descriptor. The deployer then uses specific Sun Java System Application Server tools to map the application requirements that are in a deployment descriptor to the security mechanisms that are implemented by the container.

Refer to “Developing Secure Enterprise Beans” on page 165 for further information. For information on security realms, refer to the Sun Java System Application Server Developer’s Guide.


About Developing an Effective Application

Partitioning a Sun Java System Application Server application’s business logic and data processing into the most effective set of servlets, JSPs, session beans, entity beans, and message-driven beans is the crux of your job as a developer. There are no specific rules for object-oriented design with enterprise beans, other than that entity bean instances tend to be long lived, persistent, and shared among clients, while session bean instances tend to be short lived and used only by a single client. Message-driven beans are in their own category as the only asynchronous receivers of JMS messages.

In general, your goal is to create a Sun Java System Application Server application that effectively balances the need for execution speed with the need for sharing enterprise beans (among applications and clients) and easily deploying applications across servers.

High-level information and guidelines which can help you develop enterprise beans in the Sun Java System Application Server environment are addressed in the following sections:

General Process for Creating Enterprise Beans

The procedure in this section outlines the general process of creating an enterprise bean. Specific instructions on creating the various types of enterprise beans are contained in the sections referenced in the following steps.

To create an enterprise bean:

  1. Create a directory for all the enterprise bean’s files.
  2. Decide on the type of enterprise bean you are creating:
  3. Write the code for the enterprise bean according to the EJB specification, including:
  4. Compile the interfaces and classes.
  5. Create the META-INF directory and the other structural requirements of an enterprise bean.
  6. Create the deployment descriptor files, ejb-jar.xml and sun-ejb-jar.xml. (Refer to “Assembling and Deploying Enterprise Beans” on page 173.)
  7. If the bean is an entity bean with container-managed persistence, you must also create a sun-cmp-mappings.xml file and a .dbschema file. (Refer to Using Container-Managed Persistence.)

  8. Package the class and the XML files to a JAR file, if desired. If you are using directory deployment, this is optional.
  9. Deploy the bean by itself or include it in a J2EE application. (Refer to the Sun Java System Application Server Developer’s Guide.)

It’s a good idea to verify the structure of these files using the verifier tool as described in the Sun Java System Application Server Developer’s Guide.

Bean Usage Guidelines

Deciding which parts of an application are candidates for entity beans and which are candidates for session beans (stateful or stateless) or message-driven beans will have a significant impact on the effectiveness of your application. In general:

For further information on EJB developer guidelines, refer to “Using Session Beans” on page 39, “Using Entity Beans” on page 61, and “Using Message-Driven Beans” on page 135.

Client View Guidelines

The choice between the use of local and remote interfaces is a design decision that you, the developer, make when developing an enterprise bean. The following facts should be taken into account in determining whether the local or remote programming model should be used:

For additional information, refer to the Enterprise JavaBeans Specification, v2.0.

Remote or Local Interface Guidelines

With all object-oriented development, you must determine the granularity level needed for your business logic and data processing. Granularity level refers to how many pieces to divide an application into.

Accessing Sun Java System Application Server Functionality

You can develop entity beans that adhere strictly to the Enterprise JavaBeans Specification, v2.0, or you can develop entity beans that take advantage of both the specification and additional, value-added Sun Java System Application Server features.

The Sun Java System Application Server offers several features available only in the Sun Java System Application Server container. The Sun Java System Application Server APIs enable applications to take programmatic advantage of specific Sun Java System Application Server environment features.


Note

Use these APIs only if you plan on using those beans exclusively in a Sun Java System Application Server environment.



About EJB Assembly and Deployment

The process of assembling modules and applications in Sun Java System Application Server conforms to all customary J2EE specifications. However, you can include Sun Java System Application Server-specific deployment descriptors that enhance the functionality of the Sun Java System Application Server beyond the J2EE specifications.

A J2EE module is a collection of one or more J2EE components with two deployment descriptors of that type. One descriptor is J2EE standard, the other is specific to Sun Java System Application Server. For enterprise beans, the following deployment descriptor files apply:

Information on the EJB DTDs and XML files is contained in “Assembling and Deploying Enterprise Beans” on page 173. An alphabetical list of all EJB-related elements is contained in Elements Listings.

General information on assembly and deployment is contained in the Sun Java System Application Server Developer’s Guide.

Deployment procedures are contained in the Sun Java System Application Server Administration Guide and the Administration interface online help.



Previous      Contents      Index      Next     


Copyright 2004 Sun Microsystems, Inc. All rights reserved.