What is the best technique for adding a web interface to an OSGi application?

So, I have a bunch of OSGi bundles (.jars) which perform a bunch of "business logic". All is good and up until now I've been interfacing with the bundles using the gogo command line shell.

I would like to add a web interface.

My initial thoughts are to bundle the interface into the same OSGi container/instance. I thought I would make a lightweight embedded Jetty bundle which in turn loads a .war. The servlets can then in theory talk directly with other OSGi services.

In the real world there will be several instances of the application that talk to each other. I'm not sure if it's best to have 1 web interface that connects to each one or 1 web interface locally for each business application.

There are no limitations or preferences for technology, only that it be open source.

My que开发者_如何学Pythonstion is;

• Does this suck?
• Is there a better way to do this?
• Should I separate the .war and the business logic into two separate processes?

Take a look at Virgo Web Server, formerly Spring DM Server. It's got a full-blown servlet container baked right in, is a full OSGi container, and also has Spring DM built in if you want to go that route. I don't think there's any reason to split the web and business stuff into separate processes. Whether to have a single webapp or one per business bundle seems like more of a design question: "Is it a single UI that combines many underlying concerns, or are these all separate concerns?"

The simplest way is to register your servlets with the OSGi HttpService, provided for example by the Apache Felix HTTP Service bundle. I think the Felix variant of that embeds Jetty, but you don't have to care, at the OSGi level you just see the standard HttpService.

Coupled with a server-side library that generates JSON (I am using the Apache Sling commons.json bundle), and a client-side library like jQuery, you have a powerful yet simple toolkit where your servlets can act as front-ends for your OSGi services.

It sounds like your web interface is a management interface not an end user interface?

If that's the case then have a look at the Felix webconsole, you can easily extend it by writing a plugin

Also the console itself is skinnable, so if it's just an internal application then this will probably be the simplest to implement. There's a number of plugins for managing/viewing

I wouldn't embed Jetty, as Betrand states there's the HTTP Service implementation, but also PAX Web which will allow to deploy wars directly.

RE:"Should I separate the .war and the business logic into two separate processes?" I wouldn't distribute the app for the sake of it unless (High availability or load balancing necessitate), but you should definitely split the app into a skinny war (UI stuff only) and separate service bundles.

Whether the web app should manage all instances or one per instance depends on a lot of other things;

• Are you likely to have different versions deployed at the same time? (If so then web app per instance will cause less headaches)
• Is it client facing? (separate instances may be easier to secure)
• Do you need aggregate information? (single web app)

Not sure how you're planning to get the apps to communicate, but Apache CXF can implement the Remote Services spec over webservices and Eclipse Communication Framework provides many more transport protocols.