A Practitioner s Approach to Understanding Session Beans

A Practitioner's Approach to Understanding Session Beans

Even if you are new to Enterprise JavaBeans, you should easily understand the conceptual purpose and development benefits they provide in enabling client-side business logic to exist as very portable and loosely coupled components. These components exist within the context of a robust, highly available, and performance-oriented application infrastructure, such as WebLogic Platform.

The aspect of EJBs that most people have difficulty understanding is the elements that constitute an EJB and how they exist and are carried out within the EJB container. This section of the chapter is dedicated to giving you a thorough understanding of a session bean's structural elements, explaining how and why they are developed and deployed in the manner they are, and describing how you can call methods on a session bean from a client. The following sections are a practitioner's approach to teaching you about session beans, so be prepared for some hands-on development.

The journey ahead will be fast-paced, as shown in Figure 20.2.

Figure 20.2. What you'll be learning in this section.

The following list expands on the items shown in Figure 20.2:

• You will become familiar with the class files associated with a session bean and develop the required class files for a simple session bean example.

• You will create a Java client to test the session bean after it has been deployed.

• You will learn about deployment descriptors ( ejb-jar.xml and weblogic-ejb-jar.xml ) by developing them for the session bean example.

• You will learn how to build an EJB deployment unit by compiling and packaging the associated class files and deployment descriptors for the session bean example into a single JAR module ready for deployment.

• You will deploy your session bean application and test its operations.

The Development Elements of a Session Bean

As shown in Figure 20.3, it's the bean developer's responsibility to supply the following class files that constitute a session bean:

Figure 20.3. The elements of a session bean.

• To provide a remote view of a session bean, you need to implement the following interfaces:

  • Remote interface Lists bean methods that are exposed to external clients .

  • Home interface Used by clients to manage a bean's life cycle.

  The remote view provides location independence to the session bean. For example, a client running in the same JVM as a session bean instance uses the same Java RMI API to access the bean as a client running in a different JVM on the same or different machine.

• To provide a local view of a session bean, you need to implement the following interfaces:

  • Local interface Lists bean methods that are exposed to external clients.

  • Local home interface Used by clients to manage a bean's life cycle.

  Unlike the remote view, the local view of the session bean is not location independent. Access to the bean requires the client to be located in the same JVM as the session bean. For example, a local client of a session bean can be another enterprise bean (a session bean, an entity bean, or a message-driven bean).

• The Implementation class, which implements the bean's actual business logic.

Note

The Implementation class is also commonly referred to as the SessionBean class, as it implements all available methods in the session bean's remote or local interfaces.

To develop a session bean, you provide the Implementation class file plus class files for the remote view or local view interfacesor even both. However, unless you are packaging the bean's client in the same JAR or EAR archive file as the session bean, you need to provide only the remote view interfaces for the bean. The remote view interfaces are required to enable a client to remotely access the bean via RMI/IIOP, which is the standard communication mechanism between distributed Java and J2EE objects, for example, Java clients calling methods on Java remote objects, such as EJBs.

To learn more about RMI, see Chapter 12, "Distributed Processing Using RMI," p. 385 .

Details on using local client view interfaces are discussed later in this chapter in "Using a Local View to Access a Session Bean." First, to get you better acquainted with the composition of a session bean, the following sections discuss the class files that constitute a simple stateless session bean. This example uses the infamous HelloWorld session bean, and you'll be creating the following class files:

• examples.sessionbean.HelloWorld (remote interface)

• examples.sessionbean.HelloWorldHome (home interface)

• examples.sessionbean.HelloWorldBean ( Implementation class)

To make sure this example is practical, you will also deploy the HelloWorld session bean to WebLogic Server and create a simple Java client to test the bean's operation.

To set up your working environment for this session bean example, create a working directory on your file system (for example, one named Helloworld ), and then create the following subdirectories:

• src (source files .java ).

• classes (compiled Java classes .class ).

• deployment (deployment descriptors for the session bean ejb-jar.xml and weblogic-ejb.xml ).

• lib (deployment module .jar ).

A build script, discussed later in "Building a Session Bean Deployment Unit," uses these subdirectories to compile and package the HelloWorld session bean. However, you can create your own specific working directory and subdirectories and modify the build script accordingly .

The Remote Interface

The remote interface acts as a proxy for the session bean instance in the EJB container. The methods defined by the remote interface are literally reflections of the public methods declared in the Implementation class. Each business method defined in the remote interface must have an identical (or counterpart ) method in the Implementation class. The business methods defined by the remote interface are what the client calls to process tasks on the session bean instance.

The class that implements a session bean's remote interface within the EJB container is known as the session EJBObject , which is generated at deployment. The EJBObject class implements the methods of the javax.ejb.EJBObject interface as well as methods specific to the Implementation class. Within the EJB container, it is the responsibility of EJBObject to delegate a client's method call to the session bean instance.

The following rules must be considered when creating a remote interface for a session bean:

• The remote interface must extend the javax.ejb.EJBobject interface.

• All methods must throw the java.rmi.RemoteException exception.

• Because the remote interface is a Java RMI type interface, all arguments and return values must also be valid types of RMI/IIOP.

• Each method defined by the interface must match a method in the SessionBean classsame name , number of arguments, argument types, return types, and throws clause.

• The interface and methods must be declared public.

• The parameter and return values must be serializable.

Listing 20.1 shows the remote interface for the HelloWorld session bean.

Listing 20.1 Remote Interface for the HelloWorld Session Bean

 package examples; import java.rmi.*; import javax.ejb.*; /* The methods defined in this interface are the public interface of the * HelloWorld session bean. */ public interface HelloWorld extends EJBObject { /** * This method is identical to the one defined in the Implementation class of * the Session Bean, except this method must throw a java.rmi.RemoteException. */ public String getHelloWorldMsg () throws RemoteException; } 

Create a Java class file using Listing 20.1, and save the file as HelloWorld.java in your working /src directory.

Tip

In a real-world scenario, you could start by creating the remote interface to define the methods required for implementation in the Implementation class. Alternatively, you could also define methods in the Implementation class first and then declare them via the remote interface. Either way, the main objective is that they are identical.

The Home Interface

The home interface acts as a factory for creating session bean instances and, therefore, exports the methods that provide life cycle services for the bean, such as creation and destruction of the bean. The home interface does not implement any business logic on behalf of the bean or possess any state.

The class that implements a session bean's home interface within the EJB container is known as the session EJBHome , which is generated at deployment. The EJBHome class implements the methods of the javax.ejb.EJBHome interface as well as the create< METHOD > methods, which call a matching ejbCreate< METHOD > method in the Implementation class. The EJB container makes the session bean's home interface available to a client through JNDI.

The following rules must be considered when creating a home interface for a session bean:

• The home interface must extend the javax.ejb.EJBHome interface.

• Each create method must be named create< METHOD > , and it must match one of the ejbCreate< METHOD > methods defined in the SessionBean class. The matching ejbCreate< METHOD > method must have the same number and types of arguments. However, a stateless session bean's home interface must define exactly one create() method with no arguments that's used to instantiate the bean.

• The return type for a create< METHOD > method must be the session bean's remote interface.

• The create< METHOD > must throw the javax.ejb.CreateException and java.rmi.RemoteException exceptions.

• The interface and methods must be declared public.

Listing 20.2 shows the home interface for the HelloWorld session bean.

Listing 20.2 The Home Interface for the HelloWorld Session Bean

 package examples; import java.rmi.*; import javax.ejb.*; /* Defines the methods for creating an instance of the HelloWorld session /* bean */ public interface HelloWorldHome extends EJBHome { /** * This create() method corresponds to the ejbCreate() method in the * Implementation class of the HelloWorld session bean. * The create() method returns the remote interface of the HelloWorld * session bean. */ public HelloWorld create() throws CreateException,RemoteException; } 

Create a Java class file using Listing 20.2, and save the file as HelloWorldHome.java in your working /src directory.

The Implementation Class

As a bean developer, you implement all business logic for a session bean within the Implementation class, which is defined by the remote interface. All Implementation classes must implement the javax.ejb.SessionBean interface. The EJB container uses the setSessionContext() method of the SessionBean interface to associate a session bean instance with its context.

The following rules must be considered when creating the Implementation class for a session bean:

• The class must implement the javax.ejb.SessionBean interface.

• The class must be declared as public.

• The class must have a public constructor that takes no parameters; this constructor is used to create the session bean instance.

• The class must implement the business methods defined in the remote interface and the ejbCreate() methods in the home interface.

• Each business method must be defined as public.

Note

The SessionBean class is allowed to implement other methods (for example, helper methods called internally by business methods) in addition to methods the EJB specification requires.

• If the class is a stateful session bean, it can optionally implement the javax.ejb.SessionSynchronization interface.

• The bean developer must implement all the following methods defined in the SessionBean interface:

  • The ejbActivate() and ejbPassivate() methods must be implemented. For stateless session beans, the EJB container does not use these callback methods, so they can be left empty.

  • The ejbRemove() method must be implemented.

  • The setSessionContext() method must be implemented.

The following rules must be considered when creating ejbCreate() methods for the Implementation class:

• The ejbCreate() method must be implemented as it corresponds to the create() method on the home interface.

• The ejbCreate() method must be declared as public.

• The ejbCreate() method must not be declared as final or static.

• The ejbCreate() method must return void.

• The ejbCreate() method can throw javax.ejb.EJBException or javax.ejb.CreateException exceptions.

Listing 20.3 shows the Implementation class for the HelloWorld session bean.

Listing 20.3 The Implementation Class for the HelloWorld Session Bean

 package examples; import javax.ejb.*; /** The Implementation class for the HelloWorld session bean */ public class HelloWorldBean implements SessionBean { /** * The session context is provided by the EJB container. A session bean must * retain its context. . */ private SessionContext ctx; /** An EJB must have a public, parameterless constructor */ public HelloWorldBean() {} /** Implement a simple logging mechanism to stdout */ private void log(String s) { if (true) System.out.println(s); } /** * This method is required by the EJB specification, * but is not used in this example. The container uses this method * to activate a stateful session bean after the bean has been * passivated using the ejbPassivate() method. */ public void ejbActivate() {} /** * This method is required by the EJB specification, * but is not used in this example. The container uses this method * to passivate an active stateful session bean. */ public void ejbPassivate() {} /** * This method is called by the EJB container to remove the * session bean from the EJB container. */ public void ejbRemove() { log("ejbRemove() called"); } /** Called by the EJB container to set the bean's session context. */ public void setSessionContext(SessionContext ctx) { log("setSessionContext called"); this.ctx = ctx; } /** * Called by the EJB container when a client calls the create() method in * the home interface. This method corresponds to the create() method * in the home interface of the HelloWorld session bean (HelloWorldHome.java). */ public void ejbCreate() throws CreateException { log("ejbCreate() called"); } public String getHelloWorldMsg () { log("Bean Method called"); return ("Stateless SessionBean says Hello World"); } } 

Create a Java class file using Listing 20.3, and save the file as HelloWorldBean.java in your working /src directory.

The Stubs and Skeletons of Session Bean Interfaces

When you deploy your session bean, method calls to the bean are never handled directly by the remote or home interfaces. Instead, your remote method call to the bean is performed through the collaboration of two EJB container-generated classes called the stub and the skeleton for each interface you implement. Stubs are client-side objects, and skeletons are server-side objects. These classes are responsible for marshaling parameters and return values across the network connection, as shown in Figure 20.4.

Figure 20.4. The roles of a stub and skeleton in remote communication.

Note

The only restriction for remote methods is that all parameters and return values must be serializable.

A stub is basically a proxy of the remote object and has the same interface as the remote object. The stub is also located on the same machine as a calling client, which enables the client to use its methods in the same manner that it would use methods on the remote object directly. The stub is responsible for marshaling method calls into network messages to a target skeleton object.

Note

Marshal means to serialize parameters so that they can be written to the remote object, which in turn deserializes them back into objects. Marshaling is built into the Java language through the Serializable interface.

The skeleton is an object that deconstructs a network message into its method call. After deconstructing a message, the skeleton handles the logic for calling an equivalent method on the remote object that runs on the same machine as the skeleton.

The skeleton also takes the return value of the method call and converts it to a network message that can be sent back to the stub.

Because a session bean implements two interfaces (remote and home), all remote method calls to a session bean are handled through two sets of stubs and skeletons:

• The home stub and home skeleton

• The remote stub and remote skeleton

These stubs and skeletons are auto-generated and implemented by the EJB container when the session bean is deployed to WebLogic Server.

These home and remote stubs and skeletons work in concert to enable a client to remotely call a method on the session bean (see Figure 20.5).

Figure 20.5. The roles of home and remote stubs and skeletons.

The following list explains the numbered callouts in Figure 20.5:

1. During the startup of WebLogic Server, the home stub of every deployed bean is placed into the JNDI naming service. From here, a client can download the home stub to access a bean's home interface.

2. The client uses the home stub to communicate with its home skeleton, which is controlled by the EJB container, to perform the following tasks:

   • Create a bean instance.

   • Provide state to the bean.

   • Associate a client context with the bean.

   • Create a remote skeleton and stub.

3. The home skeleton returns the remote stub specific to the client via its associated home stub.

   Note

   The skeleton acts as a listener for calls made on the home interface.

   
   

4. After the client has obtained the remote stub, any operations called on the remote stub are communicated to the remote skeleton, which is then delegated to the bean in the container.

Using a Local View to Access a Session Bean

The primary difference between local and remote views of a bean is that a local view is optimized for accessing a bean by bypassing the need to use RMI for communicating with the bean. Because RMI is not used for communication, a local client accesses a session bean through the bean's local interface or accesses an entity bean through the bean's local home interface.

The container provides classes that implement the bean's local and local home interfaces, as follows :

• The class that implements a session bean's local interface within the EJB container is known as the session EJBLocalObject , which is generated at deployment. The EJBLocalObject class implements the methods of the javax.ejb.EJBLocalObject interface as well as business methods specific to the session bean. EJBLocalObject is the local version of EJBObect , which is used to delegate requests to the session bean.

• The class that implements a session bean's local home interface within the EJB container is known as the session EJBLocalHome , which is generated at deployment. The EJBLocalHome class implements the methods of the javax.ejb.EJBLocalHome interface as well as the create< METHOD > methods specific to the session bean. EJBLocalHome is the local version of EJBHome , which is used to manage the session bean's life cycle.

Table 20.2 explores some additional differences between local and remote views to provide guidance on which view you should use to implement a session bean.

Table 20.2. Differences Between Local and Remote Views of Session Beans

Remote Calls to a Bean (Remote View)	Local Calls to a Bean (Local View)
Remote calls involve pass- by-value . The objects passed as parameters on remote calls must be serializable.	Local calls involve pass-by-reference and do not need to be serializable. Hence, the state of any Java object passed as an argument or a result can potentially be shared by the object or client.
The remote programming model provides location independence and flexibility for distributing components within a networked environment, so it provides a loose coupling between the client and bean.	Because local calls involve pass-by-reference, the local client and the bean providing the local view must be located in the same place. The local client and bean, therefore, are tightly coupled. The client must be in the same JVM and application as the bean.
Remote calls can be expensive, involving network latency; network, client, and server software overhead; argument copying; and so on. Because of this overhead, the remote programming model is typically used for relatively coarse-grained component access between a client and a bean, in which only a few method calls are required to complete a task.	Method calls are optimized and faster because they do not use RMI and occur in the same JVM as the client and remote object. This lightweight access is ideal for fine-grained component access, in which a large number of method calls to a bean are required to complete a task.
The client must explicitly program handlers for remote exceptions.	Remote exceptions are not applicable ; however, application exceptions still are.
Remote interfaces can implement load balancing or failover.	Local interfaces cannot implement load balancing or failover.

The local and local home interfaces for the HelloWorld session bean are provided in Listings 20.4 and Listing 20.5.

Listing 20.4 The Local Interface for the HelloWorld Session Bean

 package examples; import javax.ejb.*; /** * This is the HelloWorld bean's local interface. */ public interface HelloWorldLocal extends EJBLocalObject { /** * This method is identical to the one defined in the remote interface of the * session bean, except this method does not throw a java.rmi.RemoteException. */ public String getHelloWorldMsg(); } 

Listing 20.5 The Local Home Interface for the HelloWorld Session Bean

 package examples; import javax.ejb.*; /** * This is the local home interface for the HelloWorld bean. */ public interface HelloWorldLocalHome extends EJBLocalHome { /** * This create() method corresponds to the ejbCreate() method in the * Implementation class of the HelloWorld session bean. * The create() method returns the local interface.of the HelloWorld * session bean. As you can see, remote exceptions are not applicable for * local home interfaces. */ HelloWorldLocal create() throws CreateException; } 

Developing a Test Java Client for Your Session Bean

Unit testing your J2EE components after they're deployed is always the best practice, and this simple session bean is no exception. Because the HelloWorld session bean has only one business method, getHelloWorldMsg() , a simple Java client is required to test this method's operation. Listing 20.6 shows the code for this Java client, and it has been fully commented to explain the processes of locating the home and remote interfaces and implementing the session bean's method.

Listing 20.6 The Test Java Client for the HelloWorld Session Bean

 package examples; import java.rmi.*; import javax.rmi.PortableRemoteObject; import javax.naming.*; import java.util.*; /** * This class is an example of client code that calls * methods on a simple stateless session bean. */ public class HelloWorldClient { private static Context createJNDIContext() throws NamingException, RemoteException { Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); env.put(Context.PROVIDER_URL,"t3://localhost:7001"); Context context = new InitialContext(env); return context; } /** * Main method to unit test the HelloWorld API */ public static void main(String[] args) { try { // use JNDI to look up the home interface for HelloWorld Context context = createJNDIContext(); // You could use the following statement to retrieve // the HelloWorld home /* HelloWorldHome home = (HelloWorldHome) context.lookup("examples.HelloWorldEJB"); * / // However, using javax.rmi.PortableRemoteObject // allows you to narrow the scope // to the home interface HelloWorldHome home = (HelloWorldHome) PortableRemoteObject.narrow(context.lookup("examples.HelloWorldEJB"), examples.HelloWorldHome.class) ; HelloWorld hello = home.create(); /* * The EJBObject will delegate the call to the HelloWorld * session bean, receive the result, and return it to this client. */ System.out.println(hello.getHelloWorldMsg()); /* * Remove the EJBObject. * The container will mark the EJBObject for destruction. */ hello.remove(); } catch(Exception err) { System.err.println(err.toString()); } } } 

Developing Deployment Descriptors

Two deployment descriptors are applicable to your session bean example:

• The ejb-jar.xml deployment descriptor file, which includes information on the session bean's structure, internal dependencies, and application assembly information, per the J2EE specification.

• The weblogic-ejb-jar.xml deployment descriptor file, which includes specific information on the session bean's behavior (such as concurrency, caching, clustering, and security) after it is deployed into WebLogic Server's EJB container.

Note

The weblogic-cmp-rdbms-jar.xml file is applicable only if you are using Container-Managed Persistence.

The following sections describe these deployment descriptors in the context of the session bean example.

The ejb-jar.xml File

Listing 20.7 provides the ejb-jar.xml deployment descriptor file for the HelloWorld session bean example.

Listing 20.7 The ejb-jar.xml File for the HelloWorld Session Bean Example

 <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'> <!-- Generated XML! --> <ejb-jar> <enterprise-beans> <session> <ejb-name>HelloWorldEJB</ejb-name> <home>examples.HelloWorldHome</home> <remote>examples.HelloWorld</remote> <local-home>examples.HelloWorldLocalHome</local-home> <local>examples.HelloWorldLocal</local> <ejb-class>examples.HelloWorldBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <container-transaction> <method> <ejb-name>HelloWorldEJB</ejb-name> <method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </ assembly-descriptor > </ejb-jar> 

Table 20.3 describes the primary tag elements in Listing 20.7's deployment descriptor that you should become familiar with.

Table 20.3. Tag Elements in the ejb-jar.xml File for the Session Bean Example

Element	Description
<ejb-name>	Specifies a unique name for the EJB, used to identify the bean in deployment descriptors.
<home>	Specifies the fully qualified name of the home interface.
<remote>	Specifies the fully qualified name of the remote interface.
<local-home>	Specifies the fully qualified name of the local home interface.
<local>	Specifies the fully qualified name of the local interface.
<ejb-class>	Specifies the fully qualified name of the EJB class.
<session-type>	Specifies the type of session beanstateless or stateful.

Create your ejb-jar.xml file using Listing 20.7, and save the file in your working /deployment directory.

The weblogic-ejb-jar.xml File

Listing 20.8 provides the weblogic-ejb-jar.xml deployment descriptor file for the HelloWorld session bean example.

Listing 20.8 The weblogic-ejb-jar.xml File for the HelloWorld Session Bean Example

 <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN' 'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'> <!-- Generated XML! --> <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>HelloWorldEJB</ejb-name> <stateless-session-descriptor> <pool> <initial-beans-in-free-pool>5</initial-beans-in-free-pool> </pool> <stateless-clustering> <home-is-clusterable>False</home-is-clusterable> <stateless-bean-is-clusterable>False</stateless-bean-is-clusterable> <stateless-bean-load-algorithm>RoundRobin</stateless-bean-load-algorithm> </stateless-clustering> </stateless-session-descriptor> <transaction-descriptor> </transaction-descriptor> <enable-call-by-reference>True</enable-call-by-reference> <jndi-name>examples.HelloWorldEJB</jndi-name> <local-jndi-name>examples.HelloWorldEJBLocal</local-jndi-name> </weblogic-enterprise-bean> </weblogic-ejb-jar> 

Table 20.4 describes the primary tag elements in Listing 20.8's deployment descriptor that you should become familiar with.

Table 20.4. Tag Elements in the weblogic-ejb-jar.xml File for the Session Bean Example

Element	Description
<ejb-name>	Specifies the name of the bean assigned in the ejb-jar.xml file.
<initial-beans-in-free-pool>	Specifies how many instances of the bean should be created by the EJB container and placed into the free pool when the bean is deployed.
<home-is-clusterable>	When true, the home interface can be deployed on multiple WebLogic Servers in a cluster for high availability.
<stateless-bean-is-clusterable>	When true, the bean can be deployed on multiple WebLogic Servers in a cluster for high availability.
<stateless-bean-load-algorithm>	Specifies the algorithm to use for load balancing between replicas of the EJB home ( round- robin , random , or weight-based ).
<enable-call-by-reference>	Allows EJB methods called from within the same server to pass arguments by reference.
<jndi-name>	Specifies a JNDI name for a bean.
<local-jndi-name>	Specifies a JNDI name for a bean's local home.

Create your weblogic-ejb-jar.xml file from Listing 20.8 using a text editor or an XML editor, and save the file in your working /deployment directory. You can also use WebLogic Builder to create and validate your deployment descriptors.

Building a Session Bean Deployment Unit

Now that you have created your HelloWorld session bean class files and deployment descriptors, the next step is to build your deployment unit (JAR file), which requires you to do the following:

1. Compile the EJB classes by using the javac compiler from the command line.

2. Add the deployment descriptor files to the compiled unit by using the jar utility to create a temporary archive file.

3. Generate a deployment unit (JAR) that includes the following:

   • The container's classes, which are internal WebLogic Serverspecific class files that WebLogic Server uses to access the bean.

   • The implementation of the home, remote, and local interfaces.

This task is performed with the weblogic.ejbc utility, which generates container classes and implementation classes by inspecting the bean's Implementation class file and remote and home interfaces and by examining the session bean's deployment descriptors (see Figure 20.6).

Figure 20.6. Use weblogic.ejbc to generate the WebLogic container classes.

To perform these tasks, it is a good practice to create a build/make script that can automate the whole build process for you. The build script ( build.cmd ) for compiling, packaging, and generating the container classes is shown in Listing 20.9.

Listing 20.9 An Example of a Build Script

 @rem ******************************************************* @rem Cleaning working area @rem ******************************************************* echo y  rmdir /s classes echo y  rmdir /s lib mkdir classes mkdir lib @rem ******************************************************* @rem Compiling the session bean files @rem ******************************************************* javac -d classes src\*.java @rem ******************************************************* @rem Copy deployment descriptors into the META-INF directory @rem ******************************************************* mkdir classes\META-INF copy deployment\*.xml classes\META-INF @rem ******************************************************* @rem Create the temporary .jar file @rem ******************************************************* cd classes jar cf ..\lib\temp.jar * cd .. @rem ******************************************************* @rem Generating the container classes and creating the deployment @rem unit @rem ******************************************************* cd lib java weblogic.ejbc -keepgenerated temp.jar HelloWorld.jar del temp.jar cd .. 

Tip

You can view the contents of the generated container class in HelloWorld.jar by using a decompression utility, such as WinZip.

Deploying Your Session Bean

You can use two techniques to deploy your HelloWorld session bean. The easiest is simply copying the HelloWorld.jar file into the applications directory within your WebLogic Server domain directory. If your WebLogic Server is started in development mode, which is the default, WebLogic Server auto-deploys the JAR file.

The other deployment technique is a more formal procedure using WebLogic Builder or the Administration Console. Follow these steps to deploy your HelloWorld.jar file to WebLogic Server using the Administration Console:

1. Launch and log in to the Administration Console.

2. Expand the Deployments node in the left pane.

3. Right-click the EJB node and click the Configure a New EJB option.

4. Locate the HelloWorld.jar archive on your file system using the Administration Console's directory navigation mechanism.

5. Click [select] to the left of the HelloWorld.jar file.

6. Select a target server from the Available Servers list box.

7. Enter a name for the session bean application, such as HelloWorld , to identify it in the Administration Console.

8. Click Configure and Deploy. The Administration Console displays the Deploy tab, which lists deployment status and activities.

After your session bean has been deployed to WebLogic Server, the EJB container creates five instances of the bean in the free pool, as specified by the <initial-beans-in-free-pool> element in weblogic-ejb-jar.xml . Because logging was enabled in each method of the HelloWorld bean (see Listing 20.6), the methods called to instantiate the bean into the free pool are displayed in WebLogic Server's stdout .

To test your HelloWorld session bean, follow these steps:

1. Open a command-prompt window and set your Java environment.

2. Set the CLASSPATH to include the location of the HelloWorld.jar file, as shown in this statement:

     Set CLASSPATH=HelloWorld.jar;%CLASSPATH%  

3. Run the application using the following command, as shown in Figure 20.7:

   Figure 20.7. Running the test Java client against the HelloWorld session bean.

   

     java examples.HelloWorldClient