In the previous chapter, we set up all the necessary software to develop and execute the applications that will be developed throughout the book. In this chapter, we will:
- Take a look at the business case used as a background to the technical features and implementation
- Create an entity project to provide isolation and reuse of business entities, defining a persistence layer
- Create a web project with a simple query page that would access the entities we just created
- Deploy and run both projects to make sure every component—database, application server, and libraries—is configured and working as expected
To explore the features delivered by the WebLogic Server and its associated technologies/products, we're going to develop a system to search and reserve movie tickets with two main business entities—the customer and the theater:
The main focus of the business is to provide a central point for movie theater customers to browse, search, and reserve tickets. In order to show up as a search result, a theater location (or chain) must close a deal with us. By doing so, they don't have to keep all the necessary structure to have an online presence, and we get our income from a monthly fee paid by each theater plus a small percentage of each ticket we sell.
Some of the data, such as the list of movies and locations are located at the central module, Store, and others, such as seat availability are held by each theater. Upon closing a partnership, we hand over a small application module that the theater's IT personnel must set up. So, when a customer queries about a specific exhibition, the theater module is accessed by the store module to get up-to-date information on available seats, and so on. When a reservation is made, the store sends the necessary information to the selected theater so that it can mark the seat as taken. Here is a high-level modular view of our solution:
The basic use case scenario goes like this:
- The customer accesses the web page to search for a movie, chooses between the available criteria to compose the query, and submits it to the store module.
- Some of the information (movie and theater data) is located at the store module and is validated upon the arrival of the request. After checking for data consistency, the local data is retrieved and a query to the appropriate theater is issued.
- The theater module receives the request, processes it by getting the necessary information from its database, and sends the response back.
- The store module receives the data and shows it to the customer. If he/she wants to proceed and reserve the ticket, another command is sent to the store module, which in turn sends the data to the theater module.
- The remote module sends the request to the theater's proprietary system and after the reservation is confirmed, a response is sent back to our store module, which saves the transaction along with a unique control number.
- A confirmation message is presented to the customer with the generated control number. This is a proof that the transaction was completed successfully. Upon arrival at the theater's booth, the customer presents the control number to the clerk, who verifies the validity of the reservation using his own system. If everything's ok, the customer pays for the tickets and the entrance is granted.
When we think about a diagram with the main entities (domain model) of this system, their definitions and relationships should look like this:
The preceding graphic is a fairly complete representation of the entities that a real-world system would need to implement the business scenario we just presented. As the goal of the book is to help the understanding and usage of the WebLogic Server 12c, we're going to simplify the business model a little bit so that we can keep the focus on what really matters.
So, here is the set of entities we are going to use throughout the book:
The mapping of these entities to relational tables is pretty straightforward, but as we have two modules, each module will use a subset of the tables as shown here:
Keep in mind that even with this simplified model, we will be able to present the intended features of the application server. Having a complex model would just demand repetitive coding effort. That said, let's discuss one last detail about the project's structure using Eclipse before we start generating actual code.