Do It Yourself (DIY) television shows have proven popular with audiences, but the same “I can save myself money by doing it on my own,” mentality that makes for good entertainment, may not be so amusing when it comes to OSGi server runtimes.

During his lecture, Ward talked about how those who enjoy DIY projects will like OSGi because it’s all about modularity. “It’s very easy to build a server runtime from a freely available piece,” he said. “OSGi makes it simple to reuse components, but do you want to do this?”

If an application architect decides to go the DIY route, there are several options to choose from. Among the platforms are: Eclipse, Apache, Aries, JBoss, GlassFish and IBM Websphere, explained Ward.

There isn’t a cut-and-dry answer to what features should be used. Just like the many aforementioned platforms, each scenario needs to be looked at independently.

Ward advised session attendees to ask themselves, “What do you want from your runtime?,” he asked. “You need to answer this question first. Is it a development stack for playing around with?”

Ward also advised people to consider the following:

- Do you want to learn? You’ll gain the most knowledge if you build it yourself;

- What kind of time do you have? You’ll make the fastest progress using a pre-built offering;

- Is it a small/medium reduction system with a small feature set?

Even though each situation has its own circumstances, there are some general rules to follow. Ward suggested that for those creating an application that needs a lot of features, building their own runtime isn’t a wise decision. He asserted that in such a scenario, developers should save themselves time and pick a pre-built runtime that offers the necessary services.

Another situation where building a runtime can also be a poor use of resources is when an application needs to run on three or more nodes. Again, Ward said this is a scenario where it’s better to fork over some cash. The combination of deployment, management, and monitoring will be big issues.

Ward’s closing piece of advice was this, “Mostly, pick an option that’s designed for your requirements. The number of people who don’t do this is crazy!”

SpringSource’s Rod Johnson, whose Spring Framework rose to prominence as a kinder and gentler way to do Java ventured into this battle earlier this year when he admitted to OSGi’s complexity. As SpringSource’s OSGi dm Server is one of the poster children for OSGi success to this point, Johnson found he had to do some clarifying. The server is now part of the Eclipse Foundation portfolio. Here, per TheServerSide.com is Rod Johnson’s take on OSGi:

(a) OSGi is a great solution for complex applications with stringent modularity requirements;

(b) typical business applications (from which we make the bulk of our revenue) don’t have such requirements;

(c) our efforts to reduce the complexity of writing server-side OSGi applications were promising, but the road to simplification was longer and less certain than we’d hoped. Thus continuing down that road at the Eclipse Foundation, in partnership with other companies and individuals, was a natural move.

Not long ago I had a chance to speak with Peter Kriens of the OSGi Alliance, who has been working on the OSGi Enterprise Specification. He said the theme of the enterprise spec is to bring OSGi in line with Java EE specifications, specifically JTA, JPA, JMX, JNDI and the Web container.

Generally speaking, OSGi is in the early adopter phase at the enterprise level. Kriens said OSGi solves problems an enterprise might run into when applications get very large, and most enterprises probably aren’t quite to that point yet. He said there is a solid foundation for working with Java EE, but the ease of use still needs a bit of work.

While it may be a while before OSGi is ready for the enterprise, vendors have been steadily embracing it.

“All major Java EE application servers have used OSGi as their core platform,” sad Kriens, “WebSphere, WebLogic, SAP, JBoss, Jonas and so on.”

OSGi was designed to create applications out of components that were not necessarily designed to work together. The original model was a residential gateway that would run code for many different service providers. Though this model seems to exist in many application models, Kriens said, OSGi adds the unique aspect that these components can actually discover each other and collaborate. This is where modularity becomes important, he said.

“The OSGi service model significantly simplifies the design of large systems,” Kriens said. “The size of today’s applications has made it clear that the existing model of the classpath does not scale to today’s needs; there are just too many things that can go wrong without getting any warning until it is too late.”

The company’s updated SOA platform has an interesting feature called the Component Manager. Through a checkbox-styled UI, a developer or architect can start with the basic core and click to add more than 150 functionality components. For example, you can add mediation to the Web Services Application Server with a click and the Component Manager automatically acquires, installs and provisions the feature in the runtime.

I am sure users will appreciate having one less reason to deal with installers and file systems. But as this feature probably is meant for installing WSO2 components on WSO2 middleware, I can’t help but wonder if it would integrate well with the multi-vendor, best-of-breed middleware systems we see in many enterprises.

There were a host of other updates to the platform. WSO2 has added in WS-Discovery to automatically find service endpoints, as well as enhanced governance registry integration across the platform. The company’s ESB now has a graphical dashboard to monitor runtimes and provide analytics. The governance registry now works with the WSO2 Gadget Server, which provides tools for impact analysis on services and registry resources.

WSO2 is known for its lightweight, open-source approach to middleware and has built its platform on OSGi. Analysts often talk of OSGi as the next wave for enterprise application environments. While some say it is still overly complex to use, OSGi’s approach to componentization lets developers update elements in the runtime without taking systems offline.

Developer styles become an issue as one programming model starts to rule. The frameworks take away work from the developer, providing an added layer of abstraction and simplified means to address common chores. For some this is a boon – for others this is a bane.

It will be interesting to see where the OSGi component standard fits in with all this. It is meant to be modular. It is meant to adhere to the type of programming rigor we find in embedded systems design. But it has significant support for the popular Spring Web framework, too.

OSGi may represent a new development paradigm that can be approached from framework-friendly entry points (implementations), or ones that are more barebones interfaces. For Greg Wilkins, Founder and CTO of Webtide – which last year became part of Intalio – that is a good thing.

“These days, it is too easy not to program to interfaces but instead to implementations,” Wilkins said last week as part of a panel discussion at the open-source EclipseCon event .

“[Developers] got lazy and we tunneled too much to the implementation,” he said. “The OSGi module is going to be good to keep us from being lazy.”

Some people think OSGi is too hard. Some people think Web frameworks are too easy. As the old-time car advertisements used to say: “Your mileage may vary.”

Related story on OSGi
Enterprise OSGi spec rolls out at EclipseCon – SearchSOA.com

While the dm Server follows the rising trend in modular application development, Coyler said at this point OSGi is the sort of framework a company invests in to see a payback over time. Most enterprise application development, however, looks to solve problems in a more quick and agile fashion.

On TheServerSide, a popular forum in the Java community, many of those commenting on a related post shared this view. Reza Rahman said OSGi is still more applicable in embedded systems than at the enterprise level:

I agree that OSGi is still years away from becoming mainstream, so this is probably a good move on part of both SpringSource and wider acceptance of dmServer if it is really to become something developers adopt in significant numbers. Personally, I think OSGi as it stands today is more applicable in its embedded systems roots than it is in the enterprise, so an Eclipse project is a much better fit in the scheme of things.

Erik Kristiansen of IBM Websphere said an easy-to-use programming model for OSGi is closer than many realize. He said IBM is working to bring OSGi to Websphere customers and currently has an OSGi Application Open Alpha available.

Some others said OSGi is intriguing but that they have not used it because of its complexity. One of the major issues developers seem to have with OSGi are the class loader behaviors

The OSGi framework for Java is often praised for its standards-based, componentized approach to application development. IBM’s offering will offer WebSphere developers the OSGi Blueprint service specification and the ability to assemble, deploy and manage applications as a collection of versioned OSGi bundles.

The alpha will include support for the following:

• OSGi 4.2 Blueprint component model for declarative assembly, and simplified unit test
• Extensions to the Blueprint component model for declarative transactions, container-managed JPA and resource reference configuration
• Module sharing between applications
• Integrated bundle repository and support for external repositories to support application provisioning
• Integrated administration of application bundles
• Federation of lookup mechanisms between local JNDI and the OSGi service registry
• Support for deploying existing WARs as web application bundles

Gemini will, “provide a home for sub-projects that integrate existing Java enterprise technologies into module-based platforms, and/or that implement enterprise specifications on module-based platforms,” according to the proposal on Eclipse.org.

SpringSource says it will contribute two initial projects:

• Gemini Web Container – the OSGi Web Container reference implementation, which is currently housed in the SpringSource git repository.
• Gemini Blueprint Service – a spring programming model for OSGi based on Spring Dynamic Modules.

On the other hand is the question of just how OSGi features in the programming model for enterprise applications. What is the web component model? The persistence model? How does the vast landscape of existing Java EE components begin to take some advantage from OSGi?

Robinson goes on to say the OSGi Alliance Enterprise Expert Group (EEG) is looking at these questions, and just how common Java EE technologies are addressed in an OSGi environment.

[On this one, a nod to old SearchSOA friend Daniel Rubio.]