Component-based development (CBD) has been around for years. Anyone who has been a developer for any length of time has no doubt leveraged some form reuse in an application.

It may have been as simple as using a Swing component on the form of a client application. As with many areas of technology, software development and the evolution of developer tools is marked not so much by huge, dramatic leaps forward, but rather by constant innovation and improvement. When Sun Microsystems first introduced the Enterprise JavaBean (EJB) specification in 1997, no one thought that managing persistence would be such a big deal. But a big deal it was. Sun listened, and introduced Container-Managed Persistence (CMP) in the EJB 2.0 specification.

More recently, BEA has listened to its customers and provided an integrated development environment for the WebLogic platform that goes a long way toward facilitating effective CBD: BEA WebLogic Workshop. Over the course of this article, I'm going to talk about some of the challenges you face when utilizing components in Enterprise Java development and how the process can be simplified by utilizing the BEA control framework.

Planning

The time to think about how to leverage reuse in your application is at the project-planning phase. As with most aspects of software development, proper planning is essential to success. Once the program requirements are established, the first thing you should do is look in your repository and identify component candidates that can possibly be leveraged. In addition to providing the required functionality, the component must also meet the technical requirements of your application. As you go through the planning stages, be prepared with the answers to some very specific questions: Is the application intended to be Web based? Will a JavaServer Pages application in conjunction with servlets be adequate, or should you also include Web services for scalability and cross-platform flexibility? Are you building a distributed, thin-client app? Will this need the scalability and/or ease of deployment/updating provided by EJBs?

Assuming that your component repository is well documented, you should have no trouble identifying which components will be useful once these questions are answered and the program requirements are established. In many cases, the amount of "glue code" needed to integrate the component into the new project will be minimal. In other cases, there may be a fair amount of work involved. If that work estimate exceeds the amount of time it took to create the component originally, you won't see any reuse cost avoidance and you'll need to either look for another component or create one from scratch.

Another part of the planning process is determining what development environment you will use to create the individual pieces of your application. You have some flexibility here. For instance, when building an n-tier distributed app, you will probably use an IDE such as JBuilder for the client portion. You might use JBuilder for the server-side development as well, or you might decide to go with WebLogic Workshop.

WebLogic Workshop and the BEA Control Framework

BEA WebLogic Server is a powerful platform for Enterprise Java development. BEA WebLogic Workshop is tightly integrated to provide an integrated development and testing environment for Web services (and, soon, Web applications) for the WebLogic platform. As such, it is important for you to consider the added benefits that the BEA control framework provides.

For example, let's assume that as a result of your project planning, you have identified several EJB components that you wish to leverage in your new project. By taking advantage of WebLogic Workshop and the BEA control framework, as well as the inherent flexibility of the J2EE platform, you can create a distributed, scalable, back-end system that supports a variety of client deployments, including a Web application, a thin-client Java application, cross-platform deployment, and more!

To demonstrate this, I'm going to take you through some sample applications that utilize EJBs to provide back-end business logic. We'll also look at how the BEA control framework simplifies the process of integrating these EJBs into our Web services and Web applications.

Note: The sample applications referenced here come packaged with WebLogic Workshop. This allows me to focus on the component-specific aspects within the broader context of a JWS project and enables you to reference the sample projects in your own Workshop environment and experience a working demo.

Entity Beans

Entity beans represent data. They are usually mapped either to records of a relational database or to objects of an object-oriented database. They are transactional in that changes to their state typically occur within the context of a transaction. An instance of an entity bean may be referenced by multiple clients. The container--in this case WebLogic Server--is responsible for ensuring that the data in the bean and the corresponding database are synchronized. Figure 1 shows the sample project, "AccountEJBClient.jws", loaded into WebLogic Workshop. As you can see, Workshop has wrapped the bean as an EJB control and has implemented control interfaces that map to corresponding EJB methods.

[FIGURE 1 OMITTED]

If we were using this bean in another environment, we would have to go through a bit of a process in order to use it. First, we would have to look up the EJB in the JNDI registry and obtain the home interface. Next, we would need to obtain an instance of the EJB. Finally, we could invoke its methods. While this is by no means a difficult or complicated process, utilizing the control framework makes instantiating and accessing the bean even simpler. All we have to do is add a new EJB control (see Figure 2), point to the EJB (see Figure 3), and we're done. As you can see, once you've browsed to the EJB, Workshop automatically finds the home and remote interfaces. It takes every method of the bean and creates a corresponding control interface. It creates a corresponding control file (.CTRL) for each control created. Listing 1 shows the control file for this EJB control.

[FIGURES 2-3 OMITTED]

Listing 1

package ejbControl;

import weblogic.jws.*;
import weblogic.jws.control.*;
/**
 * @jws:ejb home-jndi-name="ejb20-containerManaged-AccountHome"
 * @editor-info:ejb home="AccountEJB.jar" bean="AccountEJB.jar"
 */
public interface AccountEJBControl
         extends examples.ejb20.basic.containerManaged.AccountHome, //
home interface
                  examples.ejb20.basic.containerManaged.Account, //
bean interface
                  weblogic.jws.control.EntityEJBControl      // control
interface
{

Note: Some controls can be modified by editing the CTRL file. Do not edit an EJB's CTRL file. It is created by Workshop based upon information it obtains from the EJB's code.

Now that the control has been created, it automatically handles the J2EE plumbing such as instantiating and destroying the bean, accessing the methods, and the like. Please remember that you must have a local copy of the EJB's JAR file in the WEB-INF\lib directory of your Workshop project in order for Workshop to discover the EJB's home and remote interfaces.

Listing 2 shows how WebLogic Workshop accesses the EJB and is the code for the createNewAccount operation. It calls the Create method of the EJB control (which wraps the J2EE interfaces of the EJB's Create method). As you can see, Workshop has done the work of specifying the method parameters as well as putting in exception handling. Since this is a simple "Web Service method to EJB method" mapping, there is little else to do (assuming you trust the functionality of the EJB). However, you can add custom validation code here if you wish.

Listing 2

/**

      * Invokes the target EJB's create method and returns
          the result.
      *
      * 

      * 
key is the account identifier (must be unique for
          each account).
      * 
openingBalance is the starting balance of the
          account.
      * 
type is the account type, e.g. "checking" or
          "savings".
      * 
      *
      * @return A String describing the result of the account creation.
      *
      * @jws:operation
      */
     public String createNewAccount(String key, double openingBalance,
          String type)
     {
          try
          {
               /** We can add custom validation code here
                 * if we so desire, prior to calling the
                 * create method.
                 */
               account.create(key, openingBalance, type);
          }
          catch (CreateException ce)
          {
              /** We can put code to process the exception
                * here (or below), prior to returning the
                * error message.
                */
               return "Error " + ce.getLocalizedMessage();
          }
          catch (RemoteException re)
          {
              return "Error " + re.getLocalizedMessage();
          }
          return "Successful";
     }