Session Beans

Session beans represent particular business process steps. They capture the interaction or conversation between the user and the system. Session beans come in two flavors: stateful and stateless. Stateful session beans maintain state across multiple remote method invocations by a client on the same client-proxy of the session bean. Every method invocation by the client is routed to the same session bean instance on the server. These are useful when you need to carry out a long conversation with the server and you need the server object to save the conversational state. An example of a stateful session bean is an online shopping cart, where a client might use remote methods to add, remove, or modify the products in the shopping cart.

Stateless session beans do not maintain any state that the client can depend on between multiple remote method invocations. These are useful for situations where the duration of the method execution constitutes a complete unit of work from the client's perspective. For an example of a Stateless Session Bean, open the 'TraderEJBClient.jws' sample project in WebLogic Workshop. As you can see from the JWS operations (see Figure 4), this component has only two methods: Buy and Sell.

[FIGURE 4 OMITTED]

The EJB control (which wraps the interfaces of the EJB itself) actually has a third interface: Create. In fact, every session and entity EJB contains this method. This is how the instance of the bean is actually created. When dealing with entity beans, this method must be explicitly called--since creating an instance of an entity bean actually creates a new row in the corresponding datasource. However, with WebLogic Workshop it is not necessary to fire off the Create method of session beans. The BEA control framework automatically creates an instance of the bean when any of the methods are called. Even if you do explicitly call the Create method, you might not get a new instance. WebLogic Server may simply return an existing instance of the bean.

Since this is a fine-grained component, I have included both the Buy and Sell method calls in Listing 3. You'll notice that there is very little (if any) validation going on here. One glaring weakness is the lack of any validation that the user actually owns a sufficient quantity of shares to cover the sale. This validation is best added into the client portion of your application, or as part of a larger Web service--one that integrates an entity bean for account management and a stateful session bean to handle an extended conversation with the server (perhaps for transacting multiple stock sales). You want this validation complete before you even instantiate this bean.

Listing 3

/**

      * Invokes the target EJB's <b>buy</b> method and returns the
          result.
      * Trades are restricted to 500 shares.
      *
      * @return A String describing the result of the transaction.
      *
      * @jws:operation
      */
     public String buy(String tickerSymbol, int numberOfShares)
     {
         TradeResult tr;
         try
         {
              tr = trader.buy(tickerSymbol, numberOfShares);
         }
         catch (RemoteException re)
         {
             return "Error " + re.getLocalizedMessage();
         }
         return String.valueOf(tr.getNumberTraded()) + " shares of " +
              tr.getStockSymbol() + " bought.";
     }
     /**
      * Invokes the target EJB's <b>sell</b> method and returns the
          result.
      * Trades are restricted to 500 shares.
      *
      * @return A String describing the result of the transaction.
      *
      * @jws:operation
      */
     public String sell(String tickerSymbol, int numberOfShares)
     {
         TradeResult tr;
         try
         {
             tr = trader.sell(tickerSymbol, numberOfShares);
         }
         catch (RemoteException re)
         {
             return "Error " + re.getLocalizedMessage();
         }
         return String.valueOf(tr.getNumberTraded()) + " shares of " +
         tr.getStockSymbol() + " sold.";
     }
}

Message-Driven Beans

Message-driven Beans (MDBs) enable the development of asynchronous applications. They essentially sit on the server and wait for Java Message Service (JMS) messages. They are anonymous in that no client may hold a reference to an MDB--only the EJB container may access the bean directly. They have neither a home nor a remote interface. As such, they cannot be used inside WebLogic Workshop. There is, however, an alternative. The BEA control framework includes a JMS control that you can add to your Workshop project. It can then listen for callbacks. Figure 5 shows a JWS project for credit reporting that uses a JMS control to receive credit information from the queue. Listing 4 shows the receiveMessage callback handler that processes the callback. This provides the same basic functionality of an MDB from within the Workshop environment.

[FIGURE 5 OMITTED]

Listing 4

/**
      * Callback handler for the CreditScoreControl JMS control's
      * receiveMessage callback. This handler is invoked when the
      * CreditScoreControl invokes its receiveMessage callback.
      */
     private void creditScoreJMS_receiveMessage(int score)
         throws java.rmi.RemoteException
     {
         /*
          * Add the score received by the credit scoring application to
          * the data known about the applicant.
          */
         m_currentApplicant.creditScore = score;

         /*
          * Using the ValidateCreditControl EJB control, request a
             credit
          * rating from an Enterprise Java Bean (EJB). Store the return
          * value in the approvalLevel field of the m_currentApplicant
          * object.
          */
         m_currentApplicant.approvalLevel =
            validateCreditEJB.validate(m_currentApplicant.creditScore);
         /*
          * If the member variable m_callbackURL has value other than
          * null, then send a message to the client via the callback

          */
         if( m_callbackURL != null )
         {
              callback.onCreditReportDone(m_currentApplicant, "Credit
            score received.");
         }
         /*
          * If the member variable m_callbackURL has the value null,
          * then the client cannot accept callbacks.
          * Make the message available to the client through the
          * synchronous method checkForResults.
          */
         else
         {
             /*
              * Mark the investigation as complete by setting the
              * isInvestigationComplete field to "true". Clients that
              * cannot accept callbacks will call checkForResults to
              * poll for investigation results;
              * m_isInvestigationComplete is used to determine what
                checkForResults should return.
              */
             m_isInvestigationComplete = true;
         }
     }

Summary

Mission-critical applications that depend on tried-and-tested code benefit greatly from component reuse. WebLogic Server--in conjunction with WebLogic Workshop--can make the integration of these components a breeze.

Chris Brooke is director of Enterprise Technology for ComponentSource, a software asset value provider and global award-winning marketplace for reusable software assets for all platforms. He has contributed to both books and periodicals, and speaks regularly on reuse methodologies and technologies at conferences around the country.

CONTACT... chrisb@componentsource.com