Enterprise JavaBeans Concepts and the Sun ONE Studio 5 IDE

Enterprise JavaBeans components (enterprise beans) are key building blocks in the the Java 2 Platform, Enterprise Edition (J2EE) architecture. This chapter introduces:

• The main ideas behind the J2EE architecture
• The roles of enterprise beans and other elements of the J2EE model's EJB tier
• The components and work flow of an EJB application
• The EJB Builder, which is a collection of wizards and other GUI support in the Sun ONE Studio 5, Standard Edition software (Sun ONE Studio 5 IDE, the integrated development environment)

If you are already conversant with J2EE and developing enterprise beans, and you want to know specifically how to use the IDE to create and work with your enterprise beans and EJB modules, see Chapters 3 through 7 and the appendixes. For deployment-related information, see Chapter 8. For information on using the IDE's testing feature on individual beans, see Chapter 9.

In general, an enterprise bean is useful only when it has been placed with any related beans in an EJB module, assembled into an application, and deployed on an application server. The tasks of development, assembly, and deployment can be distributed among developers or working units according to their expertise. Much of this document focuses on the work that the EJB developer does on an enterprise bean or related group of beans before they are assembled into an EJB module and an application and are deployed on a server. Chapter 8 discusses the configuration of individual beans and their EJB modules. Another document in this series, Building J2EE Applications, discusses J2EE application design, assembly, configuration, and deployment in more detail.

---

Note - The Sun ONE Studio 5 IDE supports Enterprise JavaBeans Specification, version 2.0. For the supported versions of the IDE's underlying platform and associated software, refer to the Sun ONE Studio 5, Standard Edition Getting Started Guide.

---

---

The J2EE Architecture

The Java 2 Platform, Enterprise Edition (J2EE) documents describe a services-based application architecture within which transactional, scalable, secure, portable Java components can be deployed and redeployed. Combining tiers of databases, servers, and client-access mechanisms on the J2EE model, your organization can develop applications that support your entire enterprise.

A J2EE application architecture typically has the following major features:

• A client tier. According to the J2EE specification, this tier can contain HTML or Java applets running in a browser, Extensible Markup Language (XML) documents transmitted through HTTP, and Java clients running in a client container.

The Sun ONE Studio 5 IDE supports the execution and deployment of applications that use Java clients, JSP pages, servlets, and other enterprise beans as clients.

• One or more EJB or server tiers. These tiers can contain:
• Presentation logic. Servlets or JavaServer Pages (JSP pages) running in web servers.
• Application logic. Enterprise JavaBeans components (enterprise beans) running in application servers.

• A database tier.

The server tiers of a typical J2EE application can contain any or all of the elements shown in FIGURE 1-1.

 FIGURE 1-1 Model J2EE Application as Supported by the Sun ONE Studio 5 IDE

[ D ]

An enterprise bean is a Java component, a set of Java interfaces and classes that make up a business entity. These interfaces and classes contain methods that implement business logic on an application server. One type of enterprise bean also contains fields that can be mapped to database columns. Another type of enterprise bean can manage interactions between other enterprise beans in the same application. Enterprise beans can be combined with any of the different types of components shown in FIGURE 1-1 to create applications.

Although both enterprise beans and JavaBeans components are written in the Java programming language, they are not the same. You can use JavaBeans components with design tools to customize instances of Java classes, and you can link the customized objects through events. Enterprise beans, on the other hand, implement distributed, container-managed transactional services for multiple users.

The design of the EJB tier carries the modularity and portability of Java components several steps farther. For that reason, your job as an EJB developer is more modular: You can focus more on the business data of an application than on distributed computing. When you build an application using JavaBeans components, you must also build the server framework. However, when you build an application on the J2EE model using enterprise beans, the server-side infrastructure is already built into the application server. You don't need to provide generic services such as support for transactions, security, or remote access.

---

The Roles of EJB Components

The most basic configuration for a typical EJB application is shown in FIGURE 1-2: an application client, an application server, the EJB container, at least one enterprise bean, and a data store of some kind. In this figure, a database is used.

 FIGURE 1-2 Typical Basic Configuration for an EJB Application

[ D ]

The contracts (that is, the interaction and implied agreements) between an enterprise bean, its EJB container, and the application server lend flexibility and power to the J2EE application, while simplifying the task of creating enterprise beans.

The EJB container is more a concept than an object. It's the environment that surrounds the enterprise beans on the application server to provide life-cycle management, security, distributed transaction support, and other services.

One or more enterprise beans can be deployed in a single container, which uses the standard Java Naming and Directory Interface (JNDI) API to locate an individual bean and make it available to a client.

The container intercedes between its beans and their clients. When a client needs work done by an enterprise bean, the container intercepts the method call. Working on behalf of many enterprise beans and their clients, the container can manage services (such as security and transactions) across calls, components, and even other containers running on other servers. This design feature allows the container to apply its services flexibly and transparently.

For individual enterprise beans, the container is designed to manage database persistence and transactions. This ensures a standard approach to state-management events. It also means that your beans can perform database-access operations without you, the EJB developer, having to write the SQL code or use the JDBC API directly (unless you need to override the container's default behaviors).

The container's services ensure that persistent data in an enterprise bean is saved if a client terminates or if the server shuts down.

The application server provides lower-level support such as naming, directory, and email services.

Enterprise beans are of three main types: session beans, entity beans, and message-driven beans. These types are discussed in more detail starting in Chapter 2, but to briefly describe the role of each type:

• A session bean manages the conversation between a client and the application server, and can direct complex interactions with entity beans. For example, a session bean can pass in requests for data to entity beans, package the resulting data, and pass it back out to a client.
• An entity bean usually represents an entity, or a table of data, in a database. Many entity beans can work cooperatively inside a Java virtual machine (JVM) on an application server.
• A message-driven bean forms a functional layer between client and server. This type of bean receives client message notifications and starts asynchronous interactions among other enterprise beans that are deployed to the server.

Finished enterprise beans are packaged into an EJB module (which is a logical construct for an EJB JAR file) for assembly into an application and deployment on a server. An application server can house one or more J2EE applications, a J2EE application can house one or more EJB modules, and an EJB module can house one or more enterprise beans.

---

The Roles of Application Builders

The J2EE architecture implies a methodology and supports the division of responsibilities in the application-building process into different roles. In a typical development organization, some team members have more knowledge of the business, while others are more adept at systems-level development. If the J2EE model is applied to an organization where not everyone is responsible for the same kind of work, the business or domain experts might take the role of bean provider or EJB developer, while the more systems-minded developers might do the assembly and deployment work.

At least three roles are common in development environments:

• EJB development. The EJB developers (who are application developers and, often, domain experts) builds enterprise beans without having to focus on the surrounding framework. For testing purposes and for convenience, these people might also package finished beans into EJB modules.
• EJB module assembly. The assembler or assemblers can make final groupings of finished enterprise beans into EJB modules, and combine those and other J2EE building blocks into applications. The modularity of J2EE design enables container-neutral decisions at this stage.
• Deployment. One or more deployers can deploy J2EE applications in a specific environment, making container-specific and server-specific decisions.

The IDE, with its built-in support for enterprise beans, is designed to serve the J2EE approach to building applications. When you use this IDE to build your enterprise beans, you can concentrate on writing the business logic your application needs. In the EJB development role, you need to make only minimal gestures toward the assembly and deployment steps.

However, when necessary, one person can assume all three roles. The IDE provides seamless support for all stages of enterprise bean development, assembly, and deployment.

---

Inside an EJB Application

In the typical EJB application shown in FIGURE 1-3, many client programs can get access simultaneously to the heart of the application, which resides on the application server and is managed by the EJB container. Within the EJB tier, instances of two different session beans (one prompted by a message-driven bean) manage interactions with instances of four different entity beans to let clients look up calendar appointments and schedule meeting spaces. Data from the database is read into instances of the entity beans, and clients' updates to the entity-bean instances are posted to the database.

 FIGURE 1-3 Example of an Application With All Three Kinds of Enterprise Beans

[ D ]

The Elements of an Enterprise Bean

Every enterprise bean has at least one class.

• A message-driven bean needs only its bean class, with no interfaces.
• A session bean typically is composed of three elements: its bean class and two remote-type interfaces (the home interface and the remote interface). However, a session bean can have local-type interfaces as well.
• An entity bean typically has three elements: its bean class and two local-type interfaces (the local home interface and the local interface). An entity bean can also have remote-type interfaces, and it might have a primary-key class.

For more information about enterprise bean interfaces, see Types of Interfaces.

Responsibilities in regard to the elements of an EJB application are as follows:

• As the EJB developer, you use the IDE to generate the bean class and the interfaces for each enterprise bean. For an entity bean, you also define a primary-key class, if needed. You complete the code that the IDE generates, and you declare deployment information.
• The container in which the bean is deployed implements the bean's interfaces and manages interactions between components and the data storage.
• The client using the bean creates its own stubs to call the bean's interfaces, which interact with the bean class to get the application's work done. Or, the client sends messages to a destination, and a message-driven bean listens for those messages and interacts as requested with a session bean.

Bean Methods

A J2EE application gets its work done through methods that the client calls on the bean. The kinds of methods that an enterprise bean includes are briefly discussed next (and are discussed in detail in Chapters 3 through 7). All method declarations are added either automatically by the IDE or explicitly by the developer. To add all necessary parts of a method declaration, you follow a single, short sequence of actions in dialog boxes. The IDE generates the corresponding parts of the method and places them in the appropriate classes.

• Finder Methods. The client goes through the home interface to find an entity bean instance by its primary key. The developer can also add other finder methods.

The IDE automatically generates a findByPrimaryKey method declaration in the local home interface of every entity bean (and in the bean's home interface, if it has one). The IDE also places a corresponding ejbFindByPrimaryKey method declaration in the bean class of every entity bean that manages its own persistence (that is, a bean-managed persistent entity bean, or BMP entity bean). If the developer adds another finder method, the IDE automatically places the corresponding method declarations in the local home (and home) interface and, for BMP entity beans, in the bean class.

An entity bean that delegates its persistence to the container is called a container-managed persistent entity bean, or a CMP entity bean. Finder methods that are added to CMP entity beans include EJB Query Language (EJB QL) statements, which the bean's application server plugin converts automatically to the kind of SQL code the server needs.

• Create Methods. The container initializes the enterprise bean instance, using the create method's arguments.

The IDE automatically generates a create method declaration in the home interface of every session bean (and in the bean's local home interface, if it has one). The IDE places a corresponding ejbCreate method declaration in the bean class.

The IDE also generates an ejbCreate method declaration in the bean class of every message-driven bean.

Since an entity bean doesn't have to contain a create method, the IDE doesn't automatically generate a declaration for an entity bean. However, if the developer adds a create method to an entity bean, the IDE generates the corresponding create, ejbCreate, and ejbPostCreate method declarations in the appropriate classes. An entity bean or a session bean that maintains state (a stateful session bean) can have more than one create method.

• Business Methods. A client calls business methods on a bean through the bean's remote interface (or local interface, as applicable).

The developer explicitly adds business methods to the bean; the IDE doesn't generate any default business method declarations. However, when the developer does specify a business method, the IDE places matching method declarations in the bean class and in the remote, local, or remote and local interfaces.

• Home Methods. An entity bean can use a home method for a lightweight operation that doesn't require access to any particular instance of the bean. (By contrast, a business method does require access to a particular instance.) The developer explicitly adds a home method, and the IDE generates the corresponding method declaration in the bean class and the bean's local home or home interface. An entity bean can have any number of home methods.
• Select Methods. A CMP entity bean can use a select method. Like a finder method, a select method can query the database and return a local or remote interface or a collection. In addition, a select method can query a related entity bean within the same EJB module and return values from its persistent fields. Select methods aren't exposed in remote-type interfaces and can't be invoked by a client.

The developer explicitly adds one or more select methods to the bean class. Select methods include EJB Query Language (EJB QL) statements, which the bean's application server plugin converts automatically to the kind of SQL code the server needs.

• OnMessage Methods. A client sends a message through a Java Message Service (JMS) destination to call an onMessage method on a message-driven bean.

The IDE automatically generates the onMessage method declaration in the bean's class. The developer completes the method body.

• Life-cycle Methods. The container calls several methods to manage the life cycle of an enterprise bean. Depending on the type of bean, the container works through the methods in slightly different ways. The developer has the option of specifying parameters for some of these methods.

The IDE automatically generates the appropriate life-cycle method declarations for each type of bean and places them in the bean class.

Types of Interfaces

Since session beans are often called by application clients, which live outside the enterprise beans' application server, the IDE offers remote-type interfaces (that is, a remote interface and a home interface) as a default for each session bean. However, depending on how a particular session bean will be called, the developer can choose either or both types of interfaces when creating the bean.

Entity beans are normally called by session beans and by other entity beans inside the same application server. Such entity beans need only local-type interfaces (that is, a local interface and a local home interface). Local-type interfaces save processing time because they pass parameters by reference instead of serializing the parameter values. However, again, depending on the situation, the developer can apply either or both kinds of interfaces to an entity bean.

---

Note - Any bean that will be tested using the IDE's testing feature must have remote interfaces.

---

All four of these interface types are discussed next.

The Remote Interface

A client views and gets access to the enterprise bean through the bean's remote interface. Signatures for the business methods that the client can call on the bean are in the remote interface, but the complete code for the business methods is in the bean class. The container creates a class that implements the remote interface.

The remote interface extends javax.ejb.EJBObject. A client uses this interface to locate the home interface through a JNDI lookup call, calls a method on the home interface to retrieve a specific instance of the bean (with the remote interface as the return type), and then calls business methods on that instance.

When you use the Sun ONE Studio 5 IDE to create an enterprise bean with the remote-type interfaces (through which the bean can be called from outside the server), the EJB Builder's GUI support and validation help ensure that the remote interface's methods follow the rules defined in the J2EE documents. Those rules include the following:

• The method signatures in the remote interface have corresponding methods in the bean class.
• The arguments and return values are valid RMI types.
• The methods' throws clauses include the appropriate exception classes.

The interface node looks like this in the IDE's Explorer window: The default label is the name of the enterprise bean.

The Home Interface

The enterprise bean's home interface extends javax.ejb.EJBHome and defines the create, finder, and home methods that the client can call on the enterprise bean. A client uses JNDI to locate the home interface, and the container provides a class that implements the home interface.

When you use the IDE to create an enterprise bean with remote-type interfaces, the EJB Builder's GUI support and validation help ensure that the home interface's methods follow the basic rules for enterprise beans. Those rules include the following:

• The method signatures in the home interface have corresponding methods in the bean class (except in the case of finder methods in an enterprise bean that relies on the container to manage its persistence).
• The arguments and return values are valid RMI types.
• The methods' throws clauses include the appropriate exception classes.

The interface node looks like this in the IDE's Explorer window: The default label is bean_nameHome.

The Local Interface

The local interface is similar to the remote interface in some respects. This type of interface contains signatures for the business methods that can be called on the bean. The methods' complete code is in the bean class. The container creates a class that implements the local interface. However, a call to a bean's local interface must come from another bean or a web component inside the same server.

The local interface extends javax.ejb.EJBOLocalObject. A client uses this interface to locate the local home interface through a JNDI lookup call, calls a method on the local home interface to retrieve a specific instance of the bean (with the remote interface as the return type), and then calls business methods on that instance.

When you use the Sun ONE Studio 5 IDE to create an enterprise bean with local-type interfaces, the EJB Builder's GUI support and validation help ensure that the local interface's methods follow the rules defined in the J2EE documents. Those rules include the following:

• The method signatures in the local interface have corresponding methods in the bean class.
• The methods' throws clauses include the appropriate exception classes.

The interface node looks like this in the IDE's Explorer window: The default label is Localbean_name.

The Local Home Interface

Similar in some ways to the home interface, the enterprise bean's local home interface extends javax.ejb.EJBLocalHome and defines the create, finder, and home methods that can be called on the enterprise bean by another bean within the same server. The container provides a class that implements the local home interface.

When you use the IDE to create an enterprise bean with local-type interfaces, the EJB Builder's GUI support and validation help ensure that the local home interface's methods follow the basic rules for enterprise beans. Those rules include the following:

• The method signatures in the local home interface have corresponding methods in the bean class (except in the case of finder methods in an enterprise bean that relies on the container to manage its persistence).
• The methods' throws clauses include the appropriate exception classes.

The interface node looks like this in the Explorer window: The default label is Localbean_nameHome.

The Bean Class

The bean class is the heart of the enterprise bean, containing the implementation defined in the other two classes. The bean class of an entity bean extends the javax.ejb.EntityBean interface, the bean class of a session bean extends javax.ejb.SessionBean, and the bean class of a message-driven bean extends javax.ejb.MessageDrivenBean.

The bean class implements the enterprise bean's finder, create, business, and home methods. The class also implements life-cycle methods that the container calls.

Method implementation varies by bean type. In the bean class of a CMP entity bean, select and finder methods are defined as abstract, not implemented. Instead, EJB QL statements are stored in the bean's deployment descriptor. (Both EJB QL and deployment descriptors are described in the following sections.)

When you use the Sun ONE Studio 5 IDE to create an enterprise bean, the EJB Builder's GUI support and validation help ensure that the bean class follows these and other basic rules for enterprise beans:

• The class is defined as public and abstract.
• The class contains a public constructor with no parameters.
• The class implements an ejbCreate method to match each create method defined in the home or local home interface.
• The class, if it is an entity bean that manages its own persistence, contains an ejbFind method to match each finder method in the home or local home interface.

A bean class node looks like this in the IDE's Explorer window: The default label is the name of the enterprise bean plus Bean.

EJB QL

When you add a finder method or a select method to a CMP entity bean, you embed a statement in the EJB Query Language to define the method's query. In a query written in EJB QL, your bean can navigate over the relationships defined in its abstract schema, that is, the part of your bean's deployment descriptor that defines the bean's persistent fields and relationships. An EJB QL query can span the abstract schemas of all related entity beans that are packaged in the same EJB JAR file.

When your bean is deployed to an application server, your EJB QL queries are translated into the target language of the underlying data store. Thus, an entity bean that uses EJB QL is portable across different data stores.

The Deployment Descriptor

The enterprise bean's deployment descriptor states how the bean is to be deployed in the server. The deployment descriptor, which is an XML file, lists and describes the classes that compose the enterprise bean, the bean's references to other beans, settings for the environment in which the bean will operate, and how the bean should be managed at runtime. This file also lists the persistent fields of an entity bean that delegates its persistence management to the container.

When you use the Sun ONE Studio 5 IDE to create an enterprise bean, the EJB Builder automatically creates a deployment descriptor and ensures that it follows the J2EE standard. (Because you normally work through the enterprise bean's property sheets rather than manipulating the deployment descriptor directly, the descriptor file does not appear in the IDE's Explorer window. However, you can open the descriptor file through the Explorer.)

The Work Flow of an EJB Application at Runtime

At runtime, the application client communicates first with the enterprise bean's home interface and then with the remote interface, but never directly with the enterprise bean object. All work is done for the client through the EJB container.

At runtime, these application elements interact as shown in FIGURE 1-4. The figure's numbered steps are explained next. (Notice that this is a generic view of the work flow. The example uses only one enterprise bean with remote-type interfaces. Some steps, for example, instance pooling, do not apply to certain types of enterprise beans.)

 FIGURE 1-4 Work Flow Inside the Application at Runtime

1. The client finds the enterprise bean in the application server and container. (That is, the client uses a JNDI lookup method to get a remote reference to the enterprise bean's home interface.) A corresponding home stub is created in the client.

2. A home object is created on the server side to implement the bean's home interface. The home stub asks the bean's home object (which acts as a factory) to have an instance of the enterprise bean created for the use of this client in this session.

3. The container takes a bean instance from the pool.

4. A remote object is created on the server side to implement the bean's remote interface. The client works through its remote stub and the remote object to call business methods on the bean instance.

5. Data is read from the database into the bean instance and transmitted to the client. Any updates are written to the database in transactions.

6. The client has received the results it asked for, and the container returns the instance to the pool.

Notice how this architecture supports multiple concurrent users without multithreaded programming. Because enterprise bean users get their own instances of the bean from the pool, the developer can write simple, single-threaded code.

An Enterprise Bean's Development Life Cycle

As depicted in FIGURE 1-5, an enterprise bean goes through several steps after you create it, but before it is ready for use.

 FIGURE 1-5 Development, Assembly, and Deployment of an Enterprise Bean

[ D ]

As an EJB developer using the Sun ONE Studio 5 IDE, you follow these basic steps to create an enterprise bean and prepare it for assembly and deployment:

1. Use the EJB Builder wizard and other GUI support (as described in Chapters 3 through 7) to generate the enterprise bean's classes.

2. Use the IDE's Source Editor and GUI support to code the enterprise bean. If you can let the EJB container manage your session bean's transactions and your entity bean's persistence, you have much less code to write.

3. Use the IDE to package the enterprise bean, along with any other related enterprise beans, in an EJB module. Use the EJB's property sheets to add your beans' external dependencies to the deployment descriptor.

4. Use the IDE's EJB test application as described in Chapter 9 to create an EJB web test client for the bean and to run tests. To prepare for this step, you perform some assembly and deployment steps. Notice that the bean can be deployed later in a production environment to a different server.

---

The IDE's Support for Enterprise Beans

The Sun ONE Studio 5 IDE invisibly takes care of, or automates, many tasks that you would be obliged to do if you developed your enterprise beans by hand. Here are a few of the tasks you do not have to do when you use the IDE:

• Write method declarations for the basic classes. The IDE generates the necessary classes for each bean and the method declarations within those classes.
• Provide code to manage persistence. The application server takes care of those tasks for you when you create CMP beans.
• Provide code to manage transactions. The application server takes care of those tasks for you when you create CMP beans or when you choose to let the container manage transactions for your session beans and message-driven beans.
• Keep your bean classes, interfaces, and methods in synch. The IDE maintains consistency for you.
• Write XML code for the deployment descriptor. The IDE generates this file.
• Manually create a test client to test the enterprise bean. The IDE provides comprehensive, GUI-based support for testing session and entity beans.
• Search the J2EE documentation. The enterprise bean source code generated by the IDE conforms to J2EE standards. The code automatically includes comments and references to related documentation. The IDE also provides the following:
• Code completion for the application programming interface (API) encompassed by the J2EE standard. (Press Ctrl-Space when you're editing code.)
• Convenient access to the pertinent Javadoc documentation. (Press Shift-F1 on the selected class or interface name.)

Developing Enterprise Beans in the IDE

You use the EJB Builder Wizard to generate the infrastructure of your enterprise bean. The wizard is tailored to the type of bean you've chosen: a session, entity, or message-driven bean, with options for the source of the bean's persistent data and for management of the bean's transactions and persistence. The wizard leads you through the steps of creating all the basic components.

FIGURE 1-6 shows the elements of a typical enterprise bean that the IDE generates for you, and how the elements appear in the IDE's Explorer window. This figure uses the example of a session bean with remote-type interfaces.

 FIGURE 1-6 Generated Elements of an Enterprise Bean Shown in the Explorer Window

[ D ]

After using the wizard to generate these basic elements, you use the EJB Builder's other GUI features to add methods to your bean, and you use the Source Editor to finish coding the bean.

Creating Sets of Related CMP Entity Beans

The EJB Builder Wizard allows you, in one process, to generate the infrastructure of an entire set of CMP entity beans along with an EJB module to house them. This feature is particularly useful if the database tables that your beans represent are related by foreign keys. In the entity bean set, these foreign keys are preserved as container-managed relationships.

Providing Transactions

In the enterprise bean model, transactional behavior is designed to be handled both implicitly and declaratively. When a method is invoked on a bean instance, the EJB container intervenes and manages the transaction for you. You don't have to be expert in writing transactions; you don't have to write or debug code that controls transaction boundaries. By making a simple selection in the EJB Builder wizard, you can declare your bean's transactional attributes, and you can fine-tune those attributes later using the property sheets of the bean's EJB module.

Sometimes, however, you might need to program transactions explicitly in a session bean. The IDE lets you declaratively override the container and supports the use of the JDBC API and the Java Transaction API (JTA) to manage your beans' transactional behavior.

Providing Persistence

As with transactions, the IDE allows you to delegate your beans' persistence handling entirely to the EJB container, or to code persistence yourself. If you handle it yourself, you can write JDBC code. If you want container-managed persistence, you start by making a few selections in the EJB Builder wizard, and finish by making a few declarations in a property sheet to enable the container to find your underlying data store.

The IDE comes packaged with the database server PointBase Server 4.2 Restricted Edition. With the standard installation of the IDE, the PointBase JDBC driver is installed automatically, and some associated services are automatically set up for you, for example, JDBC connection pools, persistence managers, and connections to the database itself. The examples in this manual use PointBase as the database.

Providing Security

If you want only users in certain roles to call certain methods in your enterprise bean, you can add programmatic security to your bean. However, you don't have to write full security routines in your bean's source code. A security reference in your bean code matches a security role that you declare for a method. To make that match, you simply change a field in the bean's property sheet, and the security information is added to the bean's deployment descriptor.

When a client tries to call a secured method on your bean, the EJB container compares the user's role with your access control list (the user roles that you have authorized to execute the bean's methods). The container then allows or refuses execution.

Creating Application Clients

In addition to developing the enterprise beans that make up the EJB tier of your application, you can use the IDE to create an application client. In this context, an application client is a stand-alone Java program that starts with its own main method, runs in a J2EE client container, and interacts with other J2EE application components including EJB modules. For details on the design and development of clients, refer to Building J2EE Applications.

Providing for Deployment

The IDE comes packaged with Sun ONE Application Server 7, Standard Edition application services, on which you can deploy your J2EE applications for testing purposes or for production. The examples in this book, especially in Chapter 8 and Chapter 9, uses these application services, in general referring to them as the application server.

The application server software is automatically installed at the same time as the IDE, and some associated services are automatically set up for you. For details, refer to the documentation for the application server.

---

Further Reading

For details on the design of enterprise beans and the EJB tier, refer to Enterprise JavaBeans Specification, version 2.0 at:
http://java.sun.com/products/ejb/docs.html

Other information sources are listed in Before You Read This Book.