Enterprise Integration Zone is brought to you in partnership with:

Roger has posted 6 posts at DZone. View Full User Profile

OSGi on the Server Side and the matter of the WOO

01.25.2008
| 15759 views |
  • submit to reddit

With the advent of a SOA approach to building enterprise applications, it is apparent that there is a need of a better modularity solution for Java server-side programming. Is 2008 the year for the ascendency of OSGi?

An Introduction to OSGi on the Server Side

No-Fluff-Just-Stuff founder, Jay Zimmerman, likes to refer to what he calls the WOO factor - window of opportunity - when talking about the dynamics of our software development industry.

For me, Adobe Flex is a case in point of the WOO factor that he talks about. It's a technology that was ready and in position at the right time to become a dominant RIA solution. In contrast Java was caught with nothing to show in the RIA space. It missed the WOO.

Right now, I have an engaged server-side project that will be built on OSGi. OSGi is here today, has a proven track record (Eclipse), and solves the problems of project size scalability that we need to grapple with over product life time.

Once again, just as EJB3 missed the WOO and has been eclipsed by Spring Framework, whatever standard that Sun will ultimately back via the JSR process will miss the WOO.

Why am I writing this as though I'm lamenting a sad development? I guess that's a good question. There's really nothing to be downcast about. Great software solutions on the Java platform exist outside of JSR land. Indeed, maybe the very best software used in Java circles has been the non JSR stuff.

In coming to the Java community I've never had a problem sidestepping the nonsense being peddled and instead adopted what made sense. With JEE I completely ignored session and entity beans and just used JMS MDBs and Hibernate. So in 2003/2004/2005 I built a distributed software system on principals that the SOA dudes are now all crowing about.

Building Effective Enterprise Distributed Software Systems
data-driven communication vs behavior-driven communication


More recently I've completely ignored MVC web frameworks on the server-side and instead went with RIA + SOA where MVC is completely done on the client-side. (Doing MVC on the server-side in defiance of the Fallacies of Distributed Computing was wrong headed from the get go.)

Web frameworks peaking toward obsolescence

So here we stand today poised to fish or cut bait on this matter of large scale SOA-based development on the server-side - and we badly need a modularity solution for Java.

This is the moment of the WOO and here stands OSGi.

References
Published at DZone with permission of its author, Roger Voss. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Steven Devijver replied on Sat, 2008/01/26 - 6:13am

Since when does OSGi work in servlet containers and application servers?

Christopher Brind replied on Sat, 2008/01/26 - 10:46am in response to: Steven Devijver

For quite a while actually. For a start OSGi exposes "HTTPService" which allows you to register Servlets and other resources for delivery over http. It is limited, but a start, and that's been in there for a while.

Next, IBM websphere is built on OSGi technology and has been for a while.

More recently there is an Eclipse project which allows developers to bridge OSGi in one of two ways: By embedding an OSGi framework (Equinox) in a web application, or by embedding an application server in an OSGi framework.

Check it out here:

http://www.eclipse.org/equinox/server/

Cheers,

Brindy

Christopher Brind replied on Sat, 2008/01/26 - 10:45am

Hi rv49649,

This is a very interesting post.   The company I work for is currently building a product that combines Flex and OSGi - they seem to compliment each other very well though the integration isn't totally straight forward.  As a result, we're planning to release the framework which we've developed to enable our product in April or May.  This framework will allow developers to "kick start" application development using these two great technologies! 

Regards,
Brindy

Roger Voss replied on Sat, 2008/01/26 - 4:10pm

Hello brindy,

I agree, it's one of those situations where X naturally gives rise to Y.

I describe the Adobe Flex development approach as RIA + SOA (which stands in contrast to all manner of server-side MVC web framework approaches to building web applications).

When building simple services, but for a large scale enterprise application, one will naturally begin to be concerned with modularity and coordination of large team development.

One of my dev teams has built and shipped one Flex (RIA + SOA) manner of application to customers by now, but it was a modest size application. Modularity in our SOA layer didn't become a concern for that product. However, for this new (RIA + SOA) application, modularity will be one of the very highest concerns. We must lay in the foundation for modularity from the beginning. We must have a Java modularity solution now.

Fortunately, just as you have found, the Java platform for the server-side is rich with necessary ingredients with which to assemble a good modular SOA framework stack.

Cheers,

--RogerV

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Tarun Ramakrish... replied on Sun, 2008/01/27 - 2:08am

Hi Roger,

What about things like clustering? How does one deploy an OSGi 'bundle' that would offer components that can be distributed (like EJB's)? Bridging OSGi by bundling a complete app server as an OSGi bundle (as a commented posted above) isn't a realistic solution!

I guess OSGi would need to be supported natively by JEE vendors to have a proper chance at the server side- so that all the various JEE services could be separted into OSGi bundles and applications (that can also be separated into one or more bundles) could choose to the set of service bundles they require. And that would mean some love in the JEE 6 spec, if one was desiring mass adoption..

 

Mike Francis replied on Sun, 2008/01/27 - 3:15am in response to: Tarun Ramakrishna Elankath

Lenkite

If you are interested in distributed server-side OSGi and achieving clustering, resilience and scale you should take a look at the open source Newton project (www.codecauldron.org) which provides just this.  Newton is the foundation of the Infiniflow Service Fabric (www.paremus.com) product which builds on Newton and is available under license and with full support.  Blatent plug over :-)

Mike Francis (Paremus)

Roger Voss replied on Sun, 2008/01/27 - 3:41am in response to: Tarun Ramakrishna Elankath

lenkite:

I'm not going at this by approach of delivering a complete app server as an OSGi bundle, or by providing app server containers or services as an OSGi bundle.

Instead, OSGi bundles will be used for delivering internal application modularity.

BTW, I'm not using a JEE application server. Am assembling a custom app server stack using Apache web server, multiple instancing of Tomcat, BlazeDS, Spring Framework, ActiveMQ, etc.

Traffic will be over HTTP/HTTPS, but BlazeDS supports the long polling Comet pattern. So will be able to do server-side push of events/messages to clients (this implies session affinity, though).

The current beta of BlazeDS does not support Tomcat 6 asynchronous Comet Events (a servlet programming model available when using the Tomcat NIO-based HTTP listener). However, that will very soon be remedied.

--RogerV

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Epo Jemba replied on Sun, 2008/01/27 - 6:28am

Hi sdevijver , Hi brindy

Another way for doing servlet or war deployment with OSGi is " Pax Web Extender - War", you can find it here http://wiki.ops4j.org/confluence/display/ops4j/Pax+Web+Extender+-+War, I never test it but it seems that you can deploy your war as osgi bundles. From the site :

"Pax Web Extender WAR is an extender bundle that makes possible to deploy WAR files into OSGi."

What I understand is that you have to OSGified your war (adding correct manifest etc ...)

Hope it helps.

Tarun Ramakrish... replied on Mon, 2008/01/28 - 6:20am

Hi Roger - thanks for making things clear. Looks like you will allow for work-balancing, distribution by simply going the route of using messaging..not a choice for many of us though ;-)

@mfrancis: thanks for the links. Newton looks especially interesting. I hope OSGi gains some traction on the server side.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.