The OSGi component standard is one of the newer aspects of Java development today, yet it has been a long time...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
coming. For ISVs, OSGi may be a potent tool that will enable more modular swapping of components. For some mainstream developers, it could be a blessing or a curse – a curse if its power is mishandled.
At this year's EclipseCon, SearchSOA.com writer Jack Vaughan spoke with Jeff McAffer, CTO, EclipseSource, to better discern the course of OSGi. McAffer leads the Eclipse Equinox OSGi, RCP and Orbit teams. He is one of the architects of the Eclipse Platform and a co-author of "Equinox and OSGi," recently published by Addison-Wesley. Our discussion starts with a look at resolver hooks, low-level software that ultimately enables better high-level program frameworks, but with which it is possible to create "unresolvable" states.
SearchSOA: I have heard experts, discussing resolver hooks, saying that there are new things in OSGi, but don’t touch them. What is your take on that?
Jeff McAffer: I’m probably one of those experts who says, ‘don’t touch them,’ but what it really means is that there are new things in the fundamental technology that are enabling additional configurability and flexibility within OSGi. But this is more at the systems level, not at the application level.
Resolver hooks were put in place to solve a particular technological problem where people wanted to create a new framework on top of OSGi. But, really, normal application programmers don’t need that level of flexibility. What they need is a higher grain where they can work at a more abstract level. Realistically, you don't want your developers programming (OSGi) at all because it is actually quite low level. It is made for system’s level programming, not application level programming. And so, those new things you are seeing, which are very cool and very powerful, are put in place to facilitate people who are making application programming frameworks, not system level stuff. So that's really what you see.
SearchSOA: Are you seeing OSGi-based systems moving into the enterprise?
McAffer: It’s quite exciting. People are looking at adopting OSGi and they’re moving towards the enterprise. We see it showing up in all of the major app servers, we see people using it in both embedded and existing app servers. The app servers themselves are OSGi enabled.
Projects like Virgo here at Eclipse, which is essentially [built on] the preexisting DM server technology from SpringSource, that’s really taking off. We’re seeing more and more people interested in it. It really spans the range of people doing banking applications, websites for banking applications, travel websites, and enterprise software like internal in-house things that are being done with the server. And so we see Equinox [Ed Note: An implementation of OSGi] showing up everywhere.
SearchSOA: You have always been involved closely with Eclipse. Can you try and help us characterize the influence of Eclipse?
McAffer: That’s true. Actually if you go back 10 years really, what we ended up doing is first we leveled the tooling playing field. At the time, people were selling Java IDEs for lots of money and that sort of stuff with fairly basic function. We basically said, ‘OK that’s all be free now so we have to step up a level,’ so we moved the bar.. And we’re seeing sort of this next trend, which is Java modularity on the server side.
When you look at the big picture, what we’ve really done is proven that modularity is a good thing and is very powerful. Eclipse would not be anywhere near where we are today without having had a modular story and OSGi wouldn’t be known nearly as well as it is with being highly modular and Eclipse adopting it and such.
And so we’ve sort of proven that modularity is good, fine-grain modularity is good and can be successful in Java. So I think those are really the game changers that we were seeing happen over the past 10 years.