Java Links

Java EE 6 Tutorial

Design and Architecture of Duke’s Forest

Duke’s Forest is a complex application consisting of three main projects and three subprojects.

Duke’s Forest uses the following Java EE 6 platform features:

Java Persistence API entities:

- Bean Validation annotations on the entities for verifying data

- XML annotations for Java API for XML Binding (JAXB) serialization

Web services:

- A JAX-WS web service for payment, with security constraints

- A JAX-RS web service that is EJB based

Enterprise beans:

- Local session beans

- All enterprise beans packaged within the WAR

Contexts and Dependency Injection (CDI):

- CDI annotations for JavaServer Faces components

- A CDI managed bean used as a shopping cart, with conversation scoping

- Qualifiers

- Events and event handlers

Servlets:

- A Servlet 3.0 file upload example

- A servlet for dynamic image presentation

JavaServer Faces technology, using Facelets for the web frontend

- Templating

- Composite components

- Resources packaged in a JAR file so they can be found in the classpath

Security:

- Java EE security constraints on the administrative interface business methods (enterprise beans)

- Security constraints for customers and administrators (web components)

The Duke’s Forest application has two main user interfaces, both packaged within the Duke’s Store WAR file:

1. The main interface, for customers and guests
2. The administrative interface used to perform back office operations, such as adding new items to the catalog

The Fig.1 shows the architecture of the three main projects that you will deploy: Duke’s Store, Duke’s Shipment, and Duke’s Payment.

It also shows how Duke’s Store makes use of the Events and Entities projects.

Fig.2 Interactions between Duke’s Forest Components

As illustrated in Fig.2, the customer interacts with the main interface of Duke’s Store, while the administrator interacts with the administration interface. Both interfaces access a Façade consisting of managed beans and stateless session beans, which in turn interact with the entities that represent database tables. The Façade also interacts with web services APIs that access the Duke’s Payment web service. The administrator also interacts with the interface of Duke’s Shipment, which can be accessed either directly through Duke’s Shipment or from the administration interface of Duke’s Store by means of a web service.

The most fundamental building blocks of the application are the Events and Entities projects, which are bundled into Duke’s Store and Duke’s Shipment along with the Duke’s Resources project. 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 eventManager;
...
public void onNewOrder(@Observes @New OrderEvent event) {
if (processPayment(convertForWS(event))) {
orderBean.setOrderStatus(event.getOrderID(),
OrderBean.Status.PENDING_PAYMENT.getStatus());
logger.info("Payment Approved");
eventManager.fire(event);
} else {
orderBean.setOrderStatus(event.getOrderID(),
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.

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 Fig.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.

The database schema contains 8 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
• ORDER_DETAIL, which has a many-to-one relationship with PRODUCT and CUSTOMER_ORDER (it is the join table between those two tables)
• CUSTOMER_ORDER, which has a one-to-many relationship with ORDER_DETAIL and a many-to-one relationship with PERSON and ORDER_STATUS
• 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 Person entities 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, along with id values for the product and the customer.
• OrderStatus, which defines a status attribute for each order.

Sphere: Related Content