Perhaps the most straightforward and portable option for using a server that supports only session beans is direct database access. We did some of this with the ProcessPayment bean and the TravelAgent bean in Chapter 12. When entity beans are not an option, we simply take this option a step further. The following code is an example of the TravelAgent bean’s bookPassage() method, coded with direct JDBC data access instead of using entity beans:

public Ticket bookPassage(CreditCard card, double price)
    throws RemoteException, IncompleteConversationalState {
    if (customerID == 0 || cruiseID == 0 || cabinID == 0) {
        throw new IncompleteConversationalState();
    }
    Connection con = null;
    PreparedStatement ps = null;;
    try {
        con = getConnection();

        // Insert reservation.
        ps = con.prepareStatement("insert into RESERVATION "+
            "(CUSTOMER_ID, CRUISE_ID, CABIN_ID, PRICE) values (?,?,?,?)");
        ps.setInt(1, customerID);
        ps.setInt(2, cruiseID);
        ps.setInt(3, cabinID);
        ps.setDouble(4, price);
        if (ps.executeUpdate() != 1) {
            throw new RemoteException ("Failed to add Reservation to database");
        }

        // Insert payment.
        ps = con.prepareStatement("insert into PAYMENT "+
            "(CUSTOMER_ID, AMOUNT, TYPE, CREDIT_NUMBER, CREDIT_EXP_DATE) "+
            "values(?,?,?,?,?)");
        ps.setInt(1, customerID);
        ps.setDouble(2, price);
        ps.setString(3, card.type);
        ps.setLong(4, card.number);
        ps.setDate(5, new java.sql.Date(card.experation.getTime()));
        if (ps.executeUpdate() != 1) {
            throw new RemoteException ("Failed to add Reservation to database");
        }
        Ticket ticket = new Ticket(customerID,cruiseID,cabinID,price);
        return ticket;
        
    } catch (SQLException se) {
        throw new RemoteException (se.getMessage());
    }
    finally {
        try {
            if (ps != null) ps.close(); 
            if (con!= null) con.close(); 
        } catch(SQLException se){
            se.printStackTrace();
        }
    }
}

No mystery here: we have simply redefined the TravelAgent bean so that it works directly with the data through JDBC rather than using entity beans. This method is transactionally safe because an exception thrown anywhere within the method will cause all the database inserts to be rolled back. Very clean and simple.

The idea behind this strategy is to continue to model workflow or processes with session beans. The TravelAgent bean models the process of making a reservation. Its conversational state can be changed over the course of a conversation, and safe database changes can be made based on the conversational state.

Object-to-relational mapping provides another mechanism for “direct” access to data in a stateful session bean. The advantage of object-to-relational mapping tools is that data can be encapsulated as an object-like entity bean. So, for example, an object-to-relational mapping approach could end up looking very similar to our entity bean design. The problem with object-to-relational mapping is that most tools are proprietary and may not be reusable across EJB servers. In other words, the object-to-relational tool may bind you to one brand of EJB server. Object-to-relational mapping tools are, however, an expedient, safe, and productive mechanism for obtaining direct database access when entity beans are not available.