Thank you for the kind welcome. I've been here before fielding questions about Spring. This time we'll be talking OSGi, Pax, and Spring-DM.
Let me offer a quick prelude to this week's discussions...
I got into Spring early on because dependency injection and AOP helped me untangle the objects in my application. I never thought of myself as an organized kind of person, but letting DI and AOP decouple my object made me really appreciate distinct separation of my application objects.
The problem is that while my application objects were decoupled from each other, I was still jumbling up the modules of my applications. I liked Maven's support for build-time modularity, but it still left me wanting to better separate the more coarse grained application elements.
When I first heard of OSGi, I dismissed it as some complex, heavyweight thing that didn't interest me. But then when Spring-DM came about, I couldn't help but take a look. If the Spring guys were embracing OSGi, then maybe there's something to it. If the guys who's tagline is "Eliminating Enterprise Java Complexity" are interested in OSGi, then maybe it's not as complex as I had thought.
I dug into it and discovered that OSGi isn't complex and it isn't heavyweight. And I discovered that what rough edges OSGi does have are nicely smoothed out by things like Spring-DM and the Pax selection of tools. I found OSGi to be a pleasure to work with and a great way to achieve true modularity in my applications.
So, I set out to write about my experience. That's what Modular Java is all about--an OSGi experience. It's not a comprehensive volume on OSGi, nor is it a detailed reference. It's a practical walk though the same kind of experience that I had with OSGi with you, the reader, as my pair programming partner. In just over 250 pages, we develop a complete, modular web application using OSGi, Spring-DM, and a variety of other tools that I pull in as necessary.
Now we're here on JavaRanch this week talking about OSGi. I'm here to answer your questions as best as I can. Like Java itself, OSGi is a broad and ever-growing topic, so I'm sure that there'll be some questions that stump me. But feel free to ask anyway. Let's have some OSGi fun this week.
OSGi stands for "Open Service Gateway Initiative" also known as the "Dynamic module System for java"
It defines an architecture for modular application development.
Joined: Sep 19, 2003
binayakumar patel wrote:Welcome Craig Walls
Can we use the combine frame work of OSGI and Spring as desktop application or
we can use this only for web base and enterprise application.
Spring is about decoupling application objects and OSGi is about decoupling application modules. It doesn't matter much what kind of application is being developed. In Modular Java, I build a web application...but that's just because that's the class of application I build most frequently, so it seemed natural to me.
But I see absolutely no reason why you can't build a desktop application with OSGi. After all, one of OSGi's most famous applications is a desktop application: The Eclipse IDE.
Rahul Juneja wrote:Let me start by asking what exactly is OSGI as i haven't worked on it yet and i have an understanding of Spring Core and Dependency inject in general.
In short, OSGi is a specification for a modularization framework for Java. While other efforts in the JCP are underway to bring modularity to the Java platform, OSGi has been providing Java modularity for over 10 years!
Note that OSGi itself is a specification, not an implementation. There are several implementations of the OSGi specification with the big players being Equinox (Eclipse), Felix (Apache), and Knopflerfish.
Going a bit deeper, modularity is defined by two dimensions: coupling (an external measure of how intimate application elements are with other elements) and cohesion (an internal measure of how focused an application element is. Application elements that are highly coupled and low in the cohesion category aren't very modular and consequently are difficult to maintain, test, and understand. On the other hand, elements that are loosely-coupled with other elements and highly cohesive are typically easy to maintain, test, and understand.
Although it's possible to develop highly-cohesive/loosely-coupled modules in Java without OSGi, there's very little about the language or the platform that enforces it. Consequently, despite our best efforts, we developers often miss the mark on modularity. OSGi not only enforces modularity, but strongly encourages it. As a result, OSGi-based applications exhibit all of the traits of good modularity (maintenance, testability, etc).
The two fundamental ways that OSGi offers modularity are classpath management and service registries. The details of these two ideas are beyond the scope of this already lengthy response to your simple question, so I'll stop here and let you ask for more details.
Joined: Jun 26, 2009
Thanks Craig Walls,
Your new book will surely give us, new direction for the development of robust and dynamic application using OSGi and Spring-DM.