Practicing while learning is the best way to get started with any technology. When you work hands-on and apply what you've learned as you go, you pay more attention to the details. These details may later make the difference between a smooth working project and one that requires long nights of debugging.
This book is based on a simple bookshelf service case study that we will construct step-by-step. The goal, of course, is for you to follow along and learn as you advance in the chapters.
The bookshelf application will touch on the important features of OSGi, completing the basics you've covered in the previous chapters, mainly in the context of the Felix framework as well as using components and services from other providers.
In this chapter, we will spend some time designing our project, setting its scope of work, and describing its components layout. By the end of this chapter, you will know what topics are covered in this book. You can also come back to this chapter to get a global view of the project plan.
We will:
- Describe the bookshelf case study and set the scope of work
- Go through a tiered layout of its bundles
- Define some of the conventions for the case study bundles
The case study we will construct here is a three-tiered web-based bookshelf application. Each tier consists of a functional area of the application.
The first tier is the data inventory tier, which is responsible for storing the books as well as providing management functionality.
The second tier, the main bookshelf service, holds the business logic around the bookshelf functionality.
The third tier is the user interaction tier. It provides user access to the application through a command-line interface at first, then through a simple servlet, and later through a JSP web application.
This split between the user interface, business logic, and inventory is good practice. It adds flexibility to the design by allowing the upgrade or replacement of each of the layer implementations without impacting the others and thus reducing regression testing.
Let's look at each of those layers in more detail.
For our case study, we will need a data inventory layer for storing, searching, and retrieving books.
The Book interface defines the read-only book bean and it provides the user access to the bean attributes. This interface is used when the Book entry does not require any updates. The MutableBook interface exposes the attribute-setting methods for the book bean. It is used when the caller needs to update the bean attributes.
This separation between Book and MutableBook is especially useful when developing a multi-threaded, multi-session implementation of the data inventory repository. It allows us to keep track of changes by monitoring the beans as they change and notify components of those changes when needed. The Book and MutableBook interfaces will be defined in Chapter 5, The Book Inventory Bundle, as part of the implementation of the data inventory tier.
We will define a BookInventory interface that abstracts over the repository implementation specifics.
In addition to the CRUD functionality, the book inventory interface also offers a factory method for creating new book entries. This factory method gives the caller a mutable book.
CRUD is short for Create-Retrieve-Update-Delete. It is the typical functionality-set expected from an inventory service:
- Create: Add a new book to the inventory. This operation typically checks the repository for an item with the same identifier (unique reference) and throws an exception if there's an attempt to add an item that already exists
- Retrieve: Load a book based on its unique reference, also get a list of references of items that match a set of filter criteria
- Update: Modify an existing book properties, based on its unique reference
- Delete: Remove an existing book from the inventory based on its unique reference
We'll separate the inventory API definition from its implementation, packaging each of them in its own bundle. In Chapter 5, we will write a mock implementation of the inventory that will use memory for volatile storage. It is recommended that you write another implementation for those interfaces— one that's based on permanent storage, when you're more comfortable with the process.
The separation between the API and implementation will allow you to swap an implementation with another one when it is ready. We will focus on the mock implementation in Chapter 5 and leave it to you to implement other potential flavors of it (in the previous dashed boxes).
The middle tier, or the business logic tier, of this application is the bookshelf service API and implementation. The bookshelf service implementation uses the inventory functionality exposed by the data tier, delegating book storage functionality. It also overlays application business logic by enriching the operation operation-set.
For example, one of the business logic functionalities, integrated into the bookshelf service, is user authentication. This is defined as an interface that the BookshelfService extends.
Some classes have been hidden for clarity in the preceding diagram.
During the course of our progression through the chapters, we will make changes to the implementation of the bookshelf inventory as well as to that of the bookshelf service. For the sake of making the point on API-implementation loose coupling, our case study will not separate the bookshelf service API from its implementation. This will allow you to compare the impact of changes to the bookshelf service implementation to those made to the inventory implementation.
We will look at the bookshelf service interface definition and its implementation in detail in Chapter 7,The Bookshelf: First Stab.
The upper-most layer in our application is the user interaction or presentation layer. The presentation layer integrates with the business logic layer and exposes a few flavors of interfaces accessible to the application user.
The user interaction layer in our case study will be composed of two flavors of interfaces:
The console text user interface is simpler to implement and gives early access to the application operations. The web-based graphical interface is covered later on.
The following shows the bundles that will be implemented as part of the user interaction tier and their relationship with the business logic tier.
The bookshelf-service-tui bundle will implement text user interface commands for two of the operations defined for the bookshelf service, namely, the book:search and book:add commands. The remaining commands will be left for you to implement.
The bookshelf-servlet bundle will provide a servlet graphical interface to the bookshelf service. The servlet is encoded to generate HTML and respond to user requests to the following operations:
- Listing bookshelf groups
- Listing books in a group
- Searching books by author
- Adding a book
The bookshelf-webapp bundle will provide the same functionality as the servlet bundle, implemented using Java Server Pages (JSP).