In the previous chapters, we implemented the core functionality of our Bookshelf service. In a layered architecture, we've implemented the inventory as a memory-based, non-persistent temporary mock, and added the Bookshelf service on top of it. However, we don't yet have any way of interacting with our service.
In Chapter 11, How about a Graphical Interface?, we'll implement a graphical frontend for our service. In the meantime, we'll use a command-line interface (text UI), which we will put in place here.
As you learned earlier in Chapter 3, Felix Gogo, OSGi does not yet specify how users are to interact with the framework and its services through a command-line interface. Such features are left for the different bundle providers to fulfill. We've looked at the RFC 147 draft proposal and the TSL language. You have also covered a few of the commands that are provided by the Felix Gogo Shell service.
In this chapter, you will:
We will also improve our Bookshelf case study by:
book:search
and book:add
bookshelf-service
activatorWe'll also learn how to:
Felix provides a simple but extensible shell service. This service allows bundles to expose commands to the shell user. Commands that are registered by bundles are detected by the shell service and provided to the user on the text console. We will look at how this is done in a bit.
The shell service can be used by any component that wishes to interact with other services by using a simple text command mechanism.
The Apache Felix Gogo Shell waits for user input on the command line and transmits it to the Gogo Runtime Service for execution. The Gogo Runtime Service then matches the command in the transmitted line with one of the registered methods and delegates its execution to the matched method.
In Chapter 3, we've looked at the commands that are exposed by the Felix Shell Service. Here, we'll write our own commands that we'll use to manage our books and register them.