Weblogic - Getting Started EJB with a stateless session enterprise JavaBean


A complete stateless session enterprise JavaBean

Clients access a session or entity bean through the bean's interfaces. The EJB container generates the interface implementations to enforce and manage this behavior, acting as a conduit for communication between the client and the bean.

Internally, J2EE uses the Java Remote Method Invocation to enable remote, distributed method calls and applications.

When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both.

The code for the bean should work in any Enterprise JavaBeans-compliant container or server. The only changes required should be in the deployment process and perhaps the client code. Enterprise JavaBeans components run inside Enterprise JavaBeans containers, which are supplied by Enterprise JavaBeans server vendors.

The EJB 3.1 specification provides simplified programming and packaging model changes. The mandatory use of Java interfaces from previous versions has been removed, allowing plain old Java objects to be annotated and used as EJB components. The simplification is further enhanced through the ability to place EJB components directly inside of Web applications, removing the need to produce separate archives to store the Web and EJB components and combine them together in an EAR file.


Remote Interface

The remote interface is the client's view of the Enterprise JavaBeans, and the task of the Enterprise JavaBeans developer is to declare this interface using Java RMI syntax.

It is the responsibility of the Enterprise JavaBeans' container tools provider to generate the code of this interface.

Te code below is the “remote” interface of our Enterprise Java Bean, it defines only one simple method called demoSelect() which as this is a stateless simplistic bean example it just returns a string, no database lookup is even done.

package ejb.demo;

import java.rmi.RemoteException;
import java.rmi.Remote;
import javax.ejb.*;

public interface Demo extends EJBObject, Remote {

	// NB this simple example does not even do a lookup in the database
	public String demoSelect() throws RemoteException;


The implementation of this interface is provided by the container tools but the demoSelect() method and any other methods in this interface will need to have equivalent implementations in the DemoBean.java implementation.

Home Interface

The home interface for a session bean provides the mechanism by which the container creates new session beans on behalf of the client.

The home interface, just like the remote interface, is declared by the bean developer in RMI syntax, and again, is implemented by the container provider's tools.

The Home interface it must extend javax.ejb.EJBHome and define one or more create() methods for the bean.

package ejb.demo;

import javax.ejb.*;
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.*;

 * This interface is extremely simple it declares only one create method.
public interface DemoHome extends EJBHome {

	public Demo create() throws CreateException, RemoteException;


There is little-to-no coding to be done by the programmer–it is really just declarative work at this point.

The implementation of this interface is generated by the container tools.

The Component Interface

The application (business logic) is done in the bean.

One important thing to notice about the bean implementation, is just how little code you have to author. Most of this code is simply implementing methods from the Enterprise JavaBeans specification.

 * DemoBean -- This is implemented by the EnterPrise
 * Bean author This class must extend
 * javax.ejb.SessionBean and implement
 * the methods in this interface as well as providing
 * the implementation of the business methods.
package ejb.demo;

import javax.ejb.*;
import java.io.Serializable;
import java.util.*;
import java.rmi.*;

public class DemoBean implements SessionBean {
	static final boolean verbose = true;

	private transient SessionContext ctx;
	private transient Properties props;

	// Implement the methods in the SessionBean
	// interface
	public void ejbActivate() {
		if (verbose)
			System.out.println("ejbActivate called");

	public void ejbRemove() {
		if (verbose)
			System.out.println("ejbRemove called");

	public void ejbPassivate() {
		if (verbose)
			System.out.println("ejbPassivate called");

	 * Sets the session context.
	 * @param SessionContext
	public void setSessionContext(SessionContext ctx) {
		if (verbose)
			System.out.println("setSessionContext called");
		this.ctx = ctx;
		props = ctx.getEnvironment();

	 * This method corresponds to the create method in the home interface
	 * DemoHome.java. The parameter sets of the two methods are identical. When
	 * the client calls DemoHome.create(), the container allocates an instance
	 * of the EJBean and calls ejbCreate().
	public void ejbCreate() {
		if (verbose)
			System.out.println("ejbCreate called");

	 * **** HERE IS THE BUSINESS LOGIC ***** Do the demoSelect() but don't even
	 * go to the database in this eg but instead just return a String. The
	 * really BIG thing to notice here is that this is the only code we have
	 * invented at all the rest of the code has been declarations or simply
	 * implementing methods which are part of the EJB interfaces and in this
	 * example are not even used.
	public String demoSelect() throws RemoteException {
		return ("hello world");




Set your classpath:

  • to use the imported class
    • with Weblogic
set CLASSPATH=Oracle_Middleware\wlserver_10.3\server\lib\weblogic.jar
  • J2EE.. set J2EE_HOME and JAVA_HOME path.
  • to your class directory.


set CLASSPATH=G:\Oracle\Middleware\wlserver_10.3\server\lib\weblogic.jar;F:\workspace\demo\ejbModule

Class Compilation

Compile the .java Files

javac ejb/demo/DemoBean.java
javac ejb/demo/DemoBeanLocal.java
javac ejb/demo/DemoBeanRemote.java

Deployment Descriptor

As of EJB 3.0, you are no longer required to create the EJB deployment descriptor files (such as ejb-jar.xml). However, you can still use XML deployment descriptors if you want. In the case of conflicts, the deployment descriptor value overrides the annotation value.


Java EE cleanly separates the development and deployment roles to ensure that modules are portable between EJB servers that support the EJB specification. Deploying an EJB in WebLogic Server requires running the WebLogic Server appc compiler to generate classes that enforce the EJB security, transaction, and life cycle policies.

Documentation / Reference

Powered by ComboStrap