X
Business

Interview: Guillaume Nodet and Adrian Trenaman on Apache ServiceMix and role of OSGi in OSS clouds

As SOA and open-source projects have already collided, and as OSGi is gaining favor as the container model de jour, it makes a great deal of sense to apply these software advances to the need for higher productivity and lower total costs on the business side. Open source on-premises enterprise clouds that can interact well with open standards-oriented third-party clouds may well become the de facto boundaryless services fabric approach.
Written by Dana Gardner, Contributor

Read a full transcript of the discussion. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.

Apache Software Foundation open source projects, OSGi, service-oriented architecture (SOA) developments, and cloud computing trends are converging. The do more for less mandate of the day is accelerating interest in how these open source technologies and deployment models can work well together.

As SOA and open-source projects have already collided, and as OSGi is gaining favor as the container model de jour, it makes a great deal of sense to apply these software advances to the need for higher productivity and lower total costs on the business side. Open source on-premises enterprise clouds that can interact well with open standards-oriented third-party clouds may well become the de facto boundaryless services fabric approach. [Access other FUSE community podcasts.]

To discern how open source infrastructure trends saddle up to the private cloud hub-bub, I recently talked with some thought leaders and community development leaders to assess the possible patterns of adoption. I interviewed Guillaume Nodet, software architect at Progress Software and vice president of Apache ServiceMix at Apache, and Adrian Trenaman, distinguished consultant at Progress Software.

Here are some excerpts:

Trenaman: I think open source becomes a very natural and desirable approach in terms of the technologies that you are going to use in terms of accessing the cloud and actually implementing services on the cloud. Then, in order to get those services there in the first place, SOA is pivotal. The best practices and designs that we got from the years we have been doing SOA certainly come into play there.

Certainly, you could always see the ESBs being sort of on the periphery of the cloud, getting data in and out. That's a clear use case. There is something a little sweeter, though, about Apache ServiceMix, particularly ServiceMix 4.0, because it's absolutely geared for dynamic provisioning.

You can imagine having an instance of ServiceMix 4.0 that you know is maybe just an image that you are running on several virtual machines. The first thing it does is contact a grid controller and says, “Well, okay, what bundles do you want me to deploy?” That means we can actually have the grid controller farming out particular applications to the containers that are available.

If a container goes down, then the grid controller will restart applications or bundles on different computing resources. With OSGi at the core of ServiceMix, at the core of the ESB, that’s a step forward now in terms of dynamic provisioning and really like an autonomous competing infrastructure.

... For me, what the OSGi gives us is clearly a much better plug-in framework, into which we can drop value-added services and into which we can extend. I think the OSGi framework is great for that, as well as in terms of management, maybe moving toward grid computing. The stuff that we get from OSGi allowed us to be far more dynamic in the way we provision services.

Nodet: Another thing I just want to add about ServiceMix 4.0, complementing what Adrian just said, is that ServiceMix split into several sub-projects. One of them is ServiceMix Kernel, which is an OSGi enhanced runtime that can be used for provisioning education, and this container is able to deploy virtually any kind of abstract. So, it can support Web applications, and it can support JBI abstracts, because the JBI container is reusing it, but you can really deploy anything that you want.

So, this piece of software can really be leveraged in cloud infrastructure by virtually deploying any application that you want. It could be plain Web services without using an ESB if you don’t have such a need. So it's really pervasive.

... ServiceMix has long been a way that you can distribute your SOA artifacts. ServiceMix is an ESB and by nature, it can be distributed, so it's really easy to start several instances of ServiceMix and make them seamlessly talk together in a high availability way.

The thing that you do not really see yet is all the management and all the monitoring stuff that is needed when you deploy in such an architecture. So ServiceMix can really be used readily to fulfill the core infrastructure.

ServiceMix itself does not aim at providing all the management tools that you could find from either commercial vendors or even open-source. So, on this particular topic, ServiceMix, backed by Progress, is bringing a lot of value to our customers. Progress now has the ability to provide such software.

Trenamen: We recently finished a project in mobile health, where we used ServiceMix to take information from a government health backbone, using HL7 formatted messages, and get that information onto the PDAs of the health-care officials like doctors and nurses. So this is a really, really interesting use case in the healthcare arena, where we’ve got ServiceMix in deployment.

It’s used in a number of cases as well for financial messaging. Recently, I was working with a customer, who hoped to use ServiceMix to route messages between central securities depositories, so they were using SWIFT messages over ServiceMix. We’re getting to see a really nice uptake of new users in new areas, but we also have lots of battle-hardened deployments now in production.

... OSGi is the top of the art, in terms of deployment. It really is what we’ve all wanted for years. I’ve lost enough follicles on my head fixing class-path issues and that kind of class-path hell.

OSGi gives us a badly needed packaging system and a component-based modular deployment system for Java. It piles in some really neat features in terms of life cycle -- being able to start and shut down services, define dependencies between services and between deployment bundles, and also then to do versioning as well.

The ability to have multiple versions of the same service in the same JVM with no class-path conflicts is a massive success. What OSGi really does is clean up the air in terms of Java deployment and Java modularity. So, for me, it's an absolute no-brainer, and I have seen customers who have led the charge on this. This modular framework is not necessarily something that the industry is pushing on the consumers. The consumers are actually pulling us along.

I have worked with customers who have been using OSGi for the last year-and-a-half or two years, and they are making great strides in terms of making their application architecture clean and modular and very easy and flexible to deploy. So, I’ve seen a lot of goodness come out of OSGi and the enterprise.

Read a full transcript of the discussion. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.

Editorial standards