Build your very own OSGi applications using the flexible and powerful Felix Framework
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.
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:
We’ll separate the inventory API definition from its implementation, packaging each of them in its own bundle. 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(out of the scope of this article) and leave it to you to implement other potential flavors of it (in the previous dashed boxes).
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…