Chapter 11. How About a Graphical Interface?

Most applications would require more than a command-line interface for human interaction. The majority of operations, except for a few administrative tasks, would be best exposed to the user in the form of a nice graphical frontend.

In this chapter, we work towards implementing a simple servlet-based graphical interface for the bookshelf case study, in which we will expose some of the operations that we've implemented earlier.

In this chapter, you will:

  • Learn a bit about the OSGi Http Service
  • Look at the Felix Http Service and Felix Http Whiteboard implementations
  • Create our bookshelf-servlet bundle, a simple first stab at a web application-based graphical interface

Se let's start with some context around HTTP services on an OSGi framework.

The OSGi HTTP Service

In Chapter 10, Improving the Logging, we saw the Log Service, one of the service interfaces defined in the OSGi compendium specification. In this chapter, we'll see another one, namely, the Http Service.

The Http Service provides a means for bundles to expose servlets or resources to be accessed through Http and to provide content in HTML, XML, and so on. The bundles register their content and servlets in a dynamic manner, providing context information as part of the registration.

The HttpService implementation will take care of initializing the registered servlets, interfacing with the outside world, delegating requests to the corresponding servlet, and providing the resulting content back to the requesting party.

This separation of concern offers a great flexibility in the implementation of web-based applications. The bundle providing the servlet only worries about its requirements in terms of dependencies and content it provides and delegates the rest of the initialization work to the Http Service, while having access to the other services on the framework like any other bundle does.

For example, if a servlet is registered with the HttpService implementation with the alias /myServlet, then, by default, it will receive requests from users accessing the URL http://localhost:8080/myServlet. The customization of the base URL is part of the configuration of Http Service implementation.

Component structure

The following is a simplified view of the component structure related with the Http Service. Many details have been omitted for clarity.

Component structure

On the left, we have the functionality and objects provided by a bundle that uses the HttpService; this is the servlet code. On the right is an HttpService implementation; it's the service provider side of things. The middle is the interface specifications, which consist of the OSGi compendium HttpService interface (and others, not shown here) and the Java Servlet API specification (2.1+).

The right side is the bundle providing the Http Service implementation. It keeps track of registered servlets mapped to their contextual information.

Registration of servlets

The registration of a servlet with the HttpService is pretty straightforward. It consists of providing the Http Service implementation with:

  • An instance of the servlet (that implements HttpServlet)
  • The alias (base context name) of the servlet
  • An optional HttpContext implementation

The Http context implementation is optional and will be set to the default implementation provided by the Http Service implementation:

Hashtable initParams = new Hashtable();
initParams.put("paramName", "paramValue");
getHttpService().registerServlet(
"/alias", new MyServlet(), initParams, null);

This will make the Http Service aware of the instance of MyServlet and will delegate the processing of requests that it receives for http://localhost:8080/alias to MyServlet.

Note

The servlet alias must be unique in the context of the Http Service!

The initialization parameters are accessible to the servlet through the ServletConfig instance given to it at init (by calling getInitParameter()), as would be in a regular web container.

Registration of servlets

Typically, the bundle would have an activator that registers the servlet(s) at bundle start, as shown in the previous code. However, in this chapter, we will look at how to use iPOJO to achieve the same result.

In a similar fashion, servlets are unregistered by calling the unregister method of the Http Service as follows:

getHttpService().unregister("/alias");
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.255.168