Modular web apps

Question

You are very right in thinking there are synergies here, we have a modular web app where the app itself is assembled automatically from independent components (OSGi bundles) where each bundle contributes its own pages, resources, css and optionally javascript.

We don't use JSF (Spring MVC here) so I can't comment on the added complexity of that framework in an OSGi context.

Most frameworks or approaches out there still adhere to the "old" way of thinking: one WAR file representing your webapp and then many OSGi bundles and services but almost none concern themselves with the modularisation of the GUI itself.

Prerequisites for a Design

With OSGi the first question to solve is: what is your deployment scenario and who is the primary container? What I mean is that you can deploy your application on an OSGi runtime and use its infrastructure for everything. Alternatively, you can embed an OSGi runtime in a traditional app server and then you will need to re-use some infrastructure, specifically you want to use the AppServer's servlet engine.

Our design is currently based on OSGi as the container and we use the HTTPService offered by OSGi as our servlet container. We are looking into providing some sort of transparent bridge between an external servlet container and the OSGi HTTPService but that work is ongoing.

Architectural Sketch of a Spring MVC + OSGi modular webapp

So the goal is not to just serve a web application over OSGi but to also apply OSGi's component model to the web UI itself, to make it composable, re-usable, dynamic.

These are the components in the system:

• 1 central bundle that takes care of bridging Spring MVC with OSGi, specifically it uses code by Bernd Kolb to allow you to register the Spring DispatcherServlet with OSGi as a servlet.
• 1 custom URL Mapper that is injected into the DispatcherServlet and that provides the mapping of incoming HTTP requests to the correct controller.
• 1 central Sitemesh based decorator JSP that defines the global layout of the site, as well as the central CSS and Javascript libraries that we want to offer as defaults.

• Each bundle that wants to contribute pages to our web UI has to publish 1 or more Controllers as OSGi Services and make sure to register its own servlet and its own resources (CSS, JSP, images, etc) with the OSGi HTTPService. The registering is done with the HTTPService and the key methods are:

  httpService.registerResources() and httpService.registerServlet()

When a web ui contributing bundle activates and publishes its controllers, they are automatically picked up by our central web ui bundle and the aforementioned custom URL Mapper gathers these Controller services and keeps an up to date map of URLs to Controller instances.

Then when an HTTP request comes in for a certain URL, it finds the associated controller and dispatches the request there.

The Controller does its business and then returns any data that should be rendered and the name of the view (a JSP in our case). This JSP is located in the Controller's bundle and can be accessed and rendered by the central web ui bundle exactly because we went and registered the resource location with the HTTPService. Our central view resolver then merges this JSP with our central Sitemesh decorator and spits out the resulting HTML to the client.

In know this is rather high level but without providing the complete implementation it's hard to fully explain.

Our key learning point for this was to look at what Bernd Kolb did with his example JPetstore conversion to OSGi and to use that information to design our own architecture.

IMHO there is currently way too much hype and focus on getting OSGi somehow embedded in traditional Java EE based apps and very little thought being put into actually making use of OSGi idioms and its excellent component model to really allow the design of componentized web applications.

Check out SpringSource dm Server - an application server built entirely in terms of OSGi and supporting modular web applications. It is available in free, open source, and commercial versions.

You can start by deploying a standard WAR file and then gradually break your application into OSGi modules, or 'bundles' in OSGi-speak. As you might expect of SpringSource, the server has excellent support for the Spring framework and related Spring portfolio products.

Disclaimer: I work on this product.

Be aware of the Spring DM server licensing.

We've been using Restlet with OSGi to good effect with an embedded Http service (under the covers it's actually Jetty, but tomcat is available too).

Restlet has zero to minimal XML configuration needs, and any configuration we do is in the BundleActivator (registering new services).

When building up the page, we just process the relevant service implementations to generate the output, decorator style. New bundles getting plugged in will add new page decorations/widgets the next time its rendered.

REST gives us nice clean and meaningful URLs, multiple representations of the same data, and seems an extensible metaphor (few verbs, many nouns).

A bonus feature for us was the extensive support for caching, specifically the ETag.

SpringSource seems to be working on an interesting modular web framework built on top of OSGi called SpringSource Slices. More information can be found in the following blog posts:

• Modular Web Applications with SpringSource Slices
• Pluggable styling with SpringSource Slices
• Slices Menu Bar Screencast