Developing Session EJBs with Borland JBuilder Enterprise
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.
<web-app> <display-name>WebModule</display-name> <servlet> <servlet-name>mainservlet</servlet-name> <servlet-class>ejb_wl.MainServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>mainservlet</servlet-name> <url-pattern>/mainservlet</url-pattern> </servlet-mapping> </web-app>
You also can click on the Web module and then use the "Structure Pane" to visually edit this file.
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.
Page 2 of 4