Web Services

Using EJBs with Axis

Read this article if you would like to learn how to use SOAP, WSDL, and the Web services stack with J2EE. The second of three parts, this section focuses on EJBs and Axis. It is excerpted from chapter 7 of the book Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418).

Apache Axis (and its predecessor, Apache SOAP) supports using a stateless session bean as the implementation of a service. One of the benefits of EJBs is the automatic persistence mapping layer for entity beans. To demonstrate, we're going to create a simple entity bean for SkatesTown, to capture prices of products. In order to expose this as a Web service, we'll create a front-end using a stateless session bean. This is shown in Figure 7.1.

Figure 7.1 High-level overview of the components

The stateless session bean offers a stateless interface to the entity bean and allows it to be easily mapped into a SOAP service via Axis.

This particular entity bean contains no business logic and simply acts as a mapping between the database and the object model. However, in other models, the entity bean could be mapped to more complex databases and could perform more logic. Alternatively (or in addition), there could be more logic in the session bean. However, this scenario demonstrates the aspects of EJBs simply.

Figure 7.2 shows the two components in our application graphically:

The Entity component has three properties: the productCode, which is the key field, description, and price. There are also two home methods that allow the creation and location of instances.

The front-end session bean represents the service interface to the entity bean. It references the entity bean locally and provides two main business methods to add or view product details.

If you aren't an EJB programmer, you're probably wondering at this point—where's the actual code? Although this code is effectively performing database lookups and inserts, you might expect that it would include SQL or other database query statements. There is no database code because the J2EE application server (and the deployment tools that ship with it) uses the DD and the interface to generate and run the code that implements the database logic. This CMPmeans the EJB container will manage the mapping of the properties of the entity bean component into the fields of the database table.

There are different possible mappings:

Bottom-up—The objects are created from a database schema.

Meet-in-the-middle—A set of existing objects is mapped to an existing database schema.

Top-down—The database tables are created from the object definitions.

In this case, we'll use top-down to automatically create a table in which to store our data.

Of equal importance to the classes that make up the EJB is the DD for the bean:

As you'll see later, the DD will be packaged together with the code into a JAR file, which the application server will use to configure the component and code.

In this fragment, the first tag, persistence-typeContainer, says that the programmer will delegate the storage of the object instances to the container. The other type, Bean Managed, requires the programmer to write logic to store the instance data in some form of database. The EJB 2.0 specification updated the object to relational mapping style. Generally speaking, new projects should use the new 2.x CMP version as defined by the <cmp-version> tag.

Each entity bean must specify a primary (or unique) key by which instances will be known. The rest of the tags identify database names for the schema and the columns of data.

The session bean won't have much more business logic in it, but it forms the place where the service interface is mapped into the data stored in the database.