JavaEJBDeveloping Session EJBs with Borland JBuilder Enterprise

Developing Session EJBs with Borland JBuilder Enterprise content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In the current Web application development world, to keep up with the cornucopia of the Web technologies, developers need to keep up with the tools. Some newer technologies, such as, AJAX don’t yet have a widely accepted IDEs, even though some promising tools are starting to appear. The more seasoned technologies, such as J2EE or .NET, have many mature tools on the market. J2EE, in particular, has been around for a while and many of the Java development environments are sophisticated enough to offer a substantial reduction in the development/debugging time and simplify software life cycle management. The modern tools usually feature visual designers, code completion and auto generation, in-memory and remote debugging and other features.

In this article, I will discuss the creation and use of an Enterprise Java Beans that are J2EE server components and put their role in the perspective with the whole J2EE application. The sample project will be done with the Borland JBuilder 2006 and I will use BEA WebLogic 9 as an application server. I will rely mostly on the excellent visual designers provided by JBuilder to create enterprise modules, such as WAR, EAR, and EJB, but I will note what is available with other tools, such as Eclipse. I will assume that you are comfortable with the Java language and know the basic concepts of J2EE application packaging and structure.

J2EE IDEs Background

Presently, the dominant player in the Java IDE marketplace is the free Eclipse IDE. It is a first-rate development IDE and a plug-in platform with its own SDK, and it has obtained the largest market share* extremely quickly since its release. I have described it briefly in “Modern Java Frameworks for Web Development.” However, in the form in which it is currently available, Eclipse does not contain many of the integration and design components, such as UML modeling, App server integration, visual designers, Swing editing, and so forth that other Java IDEs provide. Many such components exist, but need to be installed as a plug-in. However, some of them may not work peacefully with others, and there is always a research and integration time involved, as well as learning how to use the plug-in itself.

* Counting the usage of Eclipse IDE itself and all other IDEs that are based on it.

Many of the commercial IDEs, such as IBM WebSphere Studio (currently renamed “WebSphere Developer for zSeries”), NitroX, or Exadel Studio use Eclipse framework at their core. They add many custom plug-ins targeting different aspects of J2EE application development that are designed to work together. On the other hand, Borland’s JBuilder IDE is using a custom framework, but its future versions also will be based on Eclipse. Presently, JBuilder is a well-designed tool that offers everything needed for Java development in one package. All of JBuilder’s modules are tightly integrated and offer a rewarding design and development experience with substantially less coding. This is mostly attributed to its visual designers and well thought-out interface. All of the features are beyond the scope of this article, but I will talk about the visual EJB designer, GUI WAR and EAR structure editors, and JBuilder’s integration with the application servers to run and debug Web apps.

Setup and Environment

For the purposes of this article, I am using BEA WebLogic’s EJB and servlet containers, but JBuilder can easily integrate with other application servers out of the box, such as, Tomcat, JBoss, and so on. After installing WebLogic (and configuring a domain and a server), you need to enable it and point to its location under Enterprise Menu -> Configure Servers Window.

After that, JBuilder will ask whether you will want to use this server to deploy and run your applications during the configuration steps of the WAR and EAR modules. The setting that tells JBuilder which server to use is stored per project and can be changed at any time from the project’s Properties -> Server option.

Additionally, JBuilder will correctly create/modify xml deployment descriptors for the Web application to match the target application server. The XML descriptor also can be changed later on, either by hand or using GUI editor. JBuilder provides start/stop and debug run options for the target server, called “runtime configuration,” and even an internal browser to run and test the application.

Sample Project

The purpose of the sample project will be to get weather information from a Stateless Session Bean; it will have a getWeatherData method that takes a zip code. The method returns a static string, but in a real application it can go out to RDBMS, read from a Web service, XML stream, or any other data feed.

Here is the general structure of the project:

To invoke interaction to the Bean (which I’ll discuss shortly), the application needs to process user requests and a form to accept input. The first will be accomplished with the Java Servlet and the second will be done via a simple HTML page. I will not actually code either of them, but create them with the JBuilder. In a real enterprise application, the input could be a JSP page or any other front end technology.

According to the J2EE specification, the Servlet and all the HTML resources will be packaged in a Web module (WAR file), the bean will be placed in a separate jar, and both of them will be included in an EAR archive and deployed to the server. Again, JBuilder will do most of the work for me, including the packaging and deployment steps.

Before creating the servlet, I have created a project with the name EJB_WL and added a package with the same name ejb_wl,, which will hold my Servlet and the Bean. On the file system, both will be located under the src folder in the project directory (see the Appendix).

WAR: Web Application Archive Module

JBuilder lets you create most of the J2EE components via wizards and project, servlet, and even an HTML form is no exception. It’s a very convenient feature that removes the need to type standard doPost(), doGet(), and EJB create methods or any other template code. Before creating the servlet, the project needs a Web module to hold it. The Web module will be a logical entity correlating to the WAR archive.

I created a new Web module using a wizard from the Web object gallery, with all the default settings and the name WebModule. Note that the server choice is automatically presented when the wizard starts (see below).

On the file system, JBuilder also created a folder with the name WebModule and put the default WEB-INF subfolder with XML deployment descriptors, customized there for WebLogic server.

To add the servlet ,I used another wizard, “Standard Servlet,” under the same Web object gallery.

I indicated that I want an HTML file with the form to accept input. The servlet will deal with one request parameter of type String, which will be the zip code. At the end, I named my servlet MainServlet and indicated that I wanted to create a runtime configuration, so that the application can be tested. The runtime configuration can simultaneously be used to start the server from JBuilder and invoke the HTML file. I will put all the logic in to the template Servlet class after creating the EJB module, such as EJB lookup from the Java Naming and Directory Interface (JNDI) context, and an actual call to get the weather information.

Here are the shots of the wizard that created the servlet:

After the wizard completed, I had my servlet and the HTML file, both in a working state. When a runtime configuration was created, it automatically added servlet info to the web.xml file to let the application server know how to find and run the servlet.


You also can click on the Web module and then use the “Structure Pane” to visually edit this file.

EJB Module

The idea behind Enterprise Java Beans is very straightforward: to implement reusable Java components capable of doing some part of enterprise business logic on the server. The main word is “reusable;” if the EJB is created according to the EJB specification (currently version 2, but version 3 JSR 220 PFD is almost complete), it should be able to run on any Application Server supporting EJB without any changes. There are several types of EJB, all of which can be created visually in JBuilder 2006.

The EJB can be an entity, session, or be message driven. The entity bean usually represents a row in a database and its state can be persisted or stored there. The persistence mechanism can be CMP—Container Managed Persistence or BMP—Bean Managed Persistence. In the first case, the SQL and all transaction state management is done by the EJB container and is application-server specific. In the second case, the developer needs to write all of the transaction code and bean lookup code. The Message Driven beans mainly work in conjunction with a messaging service such as JMS (Java Messaging Service).

Session Beans can be either stateful or stateless. They usually correspond to a unit of operation or work done on the server per instance of a request from the client. If the bean is stateful, it keeps the state between requests and is “attached” to the client session. If the bean is stateless, it is reused from the pool of other stateless beans on each new request. In general, all beans are pooled to improve performance. Also, an application server is supposed to provide security, scalability, transaction management (JDBC), relationship management, and other EJB features.

To actually use the beans, clients need a way to access them. For this purpose, the EJB specification defines a public interface schema of the EJBs. The remote clients running on different JVMs will use a “remote” interface, and local clients will use a “local” interface. The interfaces represent the client’s view of an EJB. There is a third type of an interface, called a “home” interface. According to the specification, the home interface defines life cycle methods, such as, create(), remove(), findByPrimaryKey(), and the remote. A local interface usually defines business methods. Therefore, EJB that are accessed remotely should have “remote” and “home” interfaces, and EJBs accessed on the same JVM should have “local” and “local home” interfaces.

I used the remote interface to resolve my EJB. If the EJB and Web module that uses them are deployed to the same logical server (same JBM), it is preferred to resolve session beans by their “local” and “local home” interfaces because a remote interface can add additional overhead.

Before creating any beans, I added the EJB module with the wizard, where I chose “EJB Module” from the enterprise object gallery.

After the wizard completed, I used JBuilder’s EJB Designer to create the Stateless Session Bean WeatherBean. The EJB Designer is a visual tool that opens automatically after the EJB wizard completes or by clicking on the EJB module in the project pane. The designer visually adds any type of EJB to the project based on J2EE EJB specification. It even can import database schema and create an entity EJB from it. In this case, I chose to create session bean, entered its name, and added the business logic method getWeatherData(String zip) to the interface. The Bean’s interface’s and concrete class’s source were created automatically.

The only remaining task was to add the actual implementation of the business method to the concrete bean object.

Note: Because it is a stateless session bean, its home interface only has a single create() method.

The added code is in bold.

public class WeatherBean
      implements SessionBean {
   SessionContext sessionContext;
   public void ejbCreate() throws CreateException {

   public void ejbRemove() {

   public void ejbActivate() {

   public void ejbPassivate() {

   public void setSessionContext(SessionContext sessionContext) {
      this.sessionContext = sessionContext;

   public String getWeatherData(String zip) throws RemoteException {
      return "Tonight: Partly cloudy skies early will give way to
      cloudy skies late. Low 38F. Winds SSE at 5 to 10 mph.
      Tomorrow: Showers early becoming less numerous later in the
      day. High 51F. Winds SSE at 10 to 15 mph. Chance of rain 40%.
      Tomorrow night: Cloudy skies. Low 46F. Winds S at 5 to 10 mph.";

Another feature that is worth mentioning is the EJB module’s DD (data definition) Editor and the Structure Pane. They work in tandem and give a high-level overview of all the beans grouped in the EJB module. EJB’s properties, such as container transactions, security, method permissions, and the like, and general options relating to the target application container can be viewed and changed with the DD Editor. Under the hood, they modify the XML deployment descriptor files ejb-jar.xml and other app-server specific files.

During the application deployment, one of configuration files in the EJB module tells the application server the name of the EJB that needs to be registered with the JNDI. This name will be used to look up the Bean’s interface and create the object. Because the project’s target is WebLogic, the file is weblogic-ejb-jar.xml. The lookup name can be edited manually.


Here is the view of WebLogic’s JNDI directory with the Weather bean listed after deployment.

To locate and tie EJB with the Servlet, I added its definition to the servlet class.

private static WeatherHome weatherHome = null;
private Weather weatherObj             = null;
private Context mContext               = null;

The lookup code to locate the bean via its Home interface went in to the init() method of the servlet.

Note: The name must match the one from weblogic-ejb-jar.xml.

public void init() throws ServletException {
   try {
   mContext    = new InitialContext(System.getProperties());
   weatherHome = (WeatherHome) mContext.lookup("ejb/WeatherBean");
   catch (NamingException ex) {

The create method call went to the doGet() method of the Servlet. This way, the lookup of the bean and initiation is done once, in the init(), but on each new request an object is acquired from the pool maintained by the EJB container, and reused.

In doGet() {
   String weatherData = null;
   String zip         = request.getParameter("zip");
   weatherObj  = weatherHome.create();
   weatherData = weatherObj.getWeatherData(zip);

EAR: Enterprise Application Archive Module

To combine all of the parts of a J2EE application that I have created into the final application, I created an Application Module, a logical entity corresponding to the EAR archive. When the application is built, the JBuilder will jar all of the components and place the final EAR archive file in the project folder. The file then can be deployed to the application server for execution, via JBuilder or a server-provided utility.

The application module wizard is located in the Enterprise object gallery. Notice that in JBuilder, if Web Module and EJB module already exist in the project, including them in the EAR is a matter of selecting a check box next to their names on the wizard.


If the EAR module is created first, the other components can be added later on through Application Module properties. But, I find it easier to add the EAR module last and simply include the already existing parts in it.

Here is the final view of the build project structure. JBuilder compiled EJB stubs for the Weather Bean and created all files automatically. They are under the package of the project.

The logical Application, Web, and EJB entities show three things:

  • The final compiled and packaged file
  • A logical grouping of J2EE deployment descriptors corresponding to the application server associated with the project
  • A view to the file system for that module

The only thing that remains is to deploy ApplicationModule.ear.

Note: You don’t always need to create a application module. Some projects that don’t use EJB or other Server components can be deployed with just a WAR file or Web Module.

The application.xml deployment descriptor tells the app-server which modules are included in the EAR.


The entire project creation and configuration was done fairy quickly, mainly due to the visual designers and editors. The JBuilder’s visual project representation also follows the J2EE structure closely. To do the same project with other tools, such as Eclipse, you will need additional plug-ins. Usually, plug-ins for a particular app-server from one vendor will integrate together, but their sophistication will depend on the vendor. However, if you decide to switch your app-server from Tomcat to JBoss, you will need to search for and install new ones.

Running the Application

After deployment, I ran the application from the runtime configurations menu. This has automatically started the server and invoked the HTML form. The form automatically loaded in the JBuilder’s internal browser, but at this point the URL can be loaded in any browser. Here is the screen shot of the running application and what it returns when the form is submitted.

To recap, the string object “zip code” was posted to the servlet, which in turn located one of the session EJBs from the pool maintained by the WebLogic server. The bean was located by its public interface. The servlet then invoked the getWeatherMethod() method on the bean, passed the zip code parameter, and retuned its response to the client.


In this article, I have covered the basics of a complete J2EE project with all the main components, such as a Web module containing Servlet and WAR deployment descriptors and other resources, an EJB module containing a Session Stateless Bean, an Application Module containing application deployment descriptors, and both the WAR and the EJB archives. The main emphasis was on EJBs and visual designers built into the JBuilder IDE. The whole project did not require a lot of writing. The visual designers eliminated the tediousness of the template code associated with the Servlet and the EJB, and tremendously reduced coding time. The modern development tools offer a lot of flexibility when it comes to enterprise Web development, and they are certainly mature enough to eliminate low-level plumbing, allowing developers to concentrate on the overall architecture of the project.

Source Code

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories