59.1.1 The events Project

Events are one of the core components of Duke's Forest. The events project, included in all three of the main projects, is the most simple project of the application. It has only one class, OrderEvent, but this class is responsible for most of the messages between objects in the application.

The application can send messages based on events to different components and react to them based on the qualification of the event. The application supports the following qualifiers:

• @LoggedIn: For authenticated users

• @New: When a new order is created by the shopping cart

• @Paid: When an order is paid for and ready for shipment

The following code snippet from the PaymentHandler class of Duke's Store shows how the @Paid event is handled:

@Inject @Paid Event<OrderEvent> eventManager;

...
public void onNewOrder(@Observes @New OrderEvent event) {

    if (processPayment(event)) {
        orderBean.setOrderStatus(event.getOrderID(), 
                String.valueOf(OrderBean.Status.PENDING_PAYMENT.getStatus()));
        logger.info("Payment Approved");
        eventManager.fire(event);
    } else {
        orderBean.setOrderStatus(event.getOrderID(), 
                String.valueOf(OrderBean.Status.CANCELLED_PAYMENT.getStatus()));
        logger.info("Payment Denied");
    }
}

To enable users to add more events to the project easily or update an event class with more fields for a new client, this component is a separate project within the application.

59.1.2 The entities Project

The entities project is a Java Persistence API (JPA) project used by both Duke's Store and Duke's Shipment. It is generated from the database schema shown in Figure 59-3 and is also used as a base for the entities consumed and produced by the web services through JAXB. Each entity has validation rules based on business requirements, specified using Bean Validation.

Figure 59-3 Duke's Forest Database Tables and Their Relationships

Description of "Figure 59-3 Duke's Forest Database Tables and Their Relationships"

The database schema contains eight tables:

• PERSON, which has a one-to-many relationship with PERSON_GROUPS and CUSTOMER_ORDER

• GROUPS, which has a one-to-many relationship with PERSON_GROUPS

• PERSON_GROUPS, which has a many-to-one relationship with PERSON and GROUPS (it is the join table between those two tables)

• PRODUCT, which has a many-to-one relationship with CATEGORY and a one-to-many relationship with ORDER_DETAIL

• CATEGORY, which has a one-to-many relationship with PRODUCT

• CUSTOMER_ORDER, which has a one-to-many relationship with ORDER_DETAIL and a many-to-one relationship with PERSON and ORDER_STATUS

• ORDER_DETAIL, which has a many-to-one relationship with PRODUCT and CUSTOMER_ORDER (it is the join table between those two tables)

• ORDER_STATUS, which has a one-to-many relationship with CUSTOMER_ORDER

The entity classes that correspond to these tables are as follows.

• Person, which defines attributes common to customers and administrators. These attributes are the person's name and contact information, including street and email addresses. The email address has a Bean Validation annotation to ensure that the submitted data is well-formed. The generated table for the Person entity also has a DTYPE field that represents the discriminator column. Its value identifies the subclass (Customer or Administrator) to which the person belongs.

• Customer, a specialization of Person with a specific field for CustomerOrder objects.

• Administrator, a specialization of Person with fields for administration privileges.

• Groups, which represents the group (USERS or ADMINS) to which the user belongs.

• Product, which defines attributes for products. These attributes include name, price, description, associated image, and category.

• Category, which defines attributes for product categories. These attributes include a name and a set of tags.

• CustomerOrder, which defines attributes for orders placed by customers. These attributes include an amount and a date, along with id values for the customer and the order detail.

• OrderDetail, which defines attributes for the order detail. These attributes include a quantity and id values for the product and the customer.

• OrderStatus, which defines a status attribute for each order.

59.1.3 The dukes-payment Project

The dukes-payment project is a web project that holds a simple Payment web service. Since this is an example application, it does not obtain any real credit information or even customer status to validate the payment. For now, the only rule imposed by the payment system is to deny all orders above $1,000. This application illustrates a common scenario where a third-party payment service is used to validate credit cards or bank payments.

The project uses HTTP Basic Authentication and JAAS (Java Authentication and Authorization Service) to authenticate a customer to a JAX-RS web service. The implementation itself exposes a simple method, processPayment, which receives an OrderEvent to evaluate and approve or deny the order payment. The method is called from the checkout process of Duke's Store.

59.1.4 The dukes-resources Project

The dukes-resources project contains a number of files used by both Duke's Store and Duke's Shipment, bundled into a JAR file placed in the classpath. The resources are in the src/main/resources directory:

• META-INF/resources/css: Two style sheets, default.css and jsfcrud.css

• META-INF/resources/img: Images used by the projects

• META-INF/resources/js: A JavaScript file, util.js

• META-INF/resources/util: Composite components used by the projects

• bundles/Bundle.properties: Application messages in English

• bundles/Bundle_es.properties: Application messages in Spanish

• ValidationMessages.properties: Bean Validation messages in English

• ValidationMessages_es.properties: Bean Validation messages in Spanish

59.1.5 The Duke's Store Project

Duke's Store, a web application, is the core application of Duke's Forest. It is responsible for the main store interface for customers as well as the administration interface.

The main interface of Duke's Store allows the user to perform the following tasks:

• Browsing the product catalog

• Signing up as a new customer

• Adding products to the shopping cart

• Checking out

• Viewing order status

The administration interface of Duke's Store allows administrators to perform the following tasks:

• Product maintenance (create, edit, update, delete)

• Category maintenance (create, edit, update, delete)

• Customer maintenance (create, edit, update, delete)

• Group maintenance (create, edit, update, delete)

The project also uses stateless session beans as façades for interactions with the JPA entities described in The entities Project, and CDI managed beans as controllers for interactions with Facelets pages. The project thus follows the MVC (Model-View-Controller) pattern and applies the same pattern to all entities and pages, as in the following example.

• AbstractFacade is an abstract class that receives a Type<T> and implements the common operations (CRUD) for this type, where <T> is a JPA entity.

• ProductBean is a stateless session bean that extends AbstractFacade, applying Product as Type<T>, and injects the PersistenceContext for the EntityManager. This bean implements any custom methods needed to interact with the Product entity or to call a custom query.

• ProductController is a CDI managed bean that interacts with the necessary enterprise beans and Facelets pages to control the way the data will be displayed.

ProductBean begins as follows:

@Stateless
public class ProductBean extends AbstractFacade<Product> {
    private static final Logger logger =
        Logger.getLogger(ProductBean.class.getCanonicalName());

    @PersistenceContext(unitName="forestPU")
    private EntityManager em;

    @Override
    protected EntityManager getEntityManager() {
        return em;
    }
    ...

59.1.6 The Duke's Shipment Project

Duke's Shipment is a web application with a login page, a main Facelets page, and some other objects. This application, which is accessible only to administrators, consumes orders from a JMS queue and calls the RESTful web service exposed by Duke's Store to update the order status. The main page of Duke's Shipment shows a list of orders pending shipping approval and a list of shipped orders. The administrator can approve or deny orders for shipping. If approved, the order is shipped, and it appears under the Shipped heading. If denied, the order disappears from the page, and on the customer's Orders list it appears as cancelled.

There is also a gear icon on the Pending list that makes an Ajax call to the Order Service to refresh the list without refreshing the page. The code looks like this:

<h:commandLink>
    <h:graphicImage library="img" title="Check for new orders"
                    style="border:0px" name="refresh.png"/>
    <f:ajax execute="@form" render="@form" />
</h:commandLink>