CODEWITHSUNDEEP
javaosgiwar
xconspirisist
xconspirisist

Reputation: 1461

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 question is;

Upvotes: 1

Views: 622

Answers (3)

earcam
earcam

Reputation: 6692

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.

Upvotes: 0

Bertrand Delacretaz
Bertrand Delacretaz

Reputation: 6100

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.

Upvotes: 0

Ryan Stewart
Ryan Stewart

Reputation: 128929

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?"

Upvotes: 0

Related Questions