Interview: Guillaume Nodet and Adrian Trenaman on Apache ServiceMix and Role of ESBs in OSS

Transcript of a BriefingsDirect podcast with Guillaume Nodet and Adrian Trenaman of Progress Software on directions and trends in SOA and open source infrastructure.

Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion about open source, service-oriented architecture (SOA) developments, and trends.

We are going to catch up and get a refresher on some important open-source software projects in the Apache Software Foundation. We’ll be looking at the Apache ServiceMix enterprise service bus (ESB), and the toolkit, and we are going to talk with some thought leaders and community development leaders to assess the market for these products, particularly in the context of cloud computing, which is certainly getting a lot of attention these days.

We'll also look at the context around such technologies as OSGi and Java Business Integration (JBI). We want to also think about what this means for enterprise-caliber SOA, particularly leveraging open-source projects. [Access more FUSE Community podcasts.]

To help us sort out and better understand the open-source SOA landscape, we’re joined by Guillaume Nodet, software architect at Progress Software and vice president of Apache ServiceMix at Apache. Welcome to the show, Guillaume.

Guillaume Nodet: Thank you.

Gardner: We are also joined by Adrian Trenaman, distinguished consultant at Progress Software. Hey, Adrian.

Adrian Trenaman: Hey, Dana. How is it going?

Gardner: Good. Now, we are starting to see different patterns of adoption and use-case scenarios around SOA, and open-source projects. Counterpart offerings for certification and support, such as the FUSE offerings from Progress, are getting more traction in interesting ways. The role of ESBs, I think as we can safely say, it is expanding.

The role for management and policy and rules and roles is becoming much more essential, not on a case-by-case basis or tactical basis, but more from a holistic management overview of services and other aspects of IT development and deployment.

First I want to go to Guillaume. Give us a quick update on Apache ServiceMix, and how you see it being used in the market now?

Nodet: Apache ServiceMix is one of the top-level projects at the Apache Software Foundation. It was started back in 2005, and was graduated as a top-level project a year-and-a-half ago. ServiceMix is an open-source ESB and it's really a well-known ESB for several reasons, which we’ll come to later. It's really a full-featured ESB that is widely used in a whole range of companies from government to banking applications. There’s very wide use of ServiceMix.

Gardner: Tell us a little bit about your background, and how you became involved. How long have you been working on ServiceMix, and what led you up to getting involved?

Nodet: Back in 2004, I was working at a small company based in France, and we were looking for an ESB for internal purposes. I began to do some research on the open-source ESBs available at that time. I was involved in the Mule Project and I became a committer in my spare time, and had been one of the main committers for six months.

In the summer of 2005, my company was firing people for economical reasons, and I decided to take a break and leave the company. So I sent an email to James Strachan, who was just starting ServiceMix, and that's how I became involved. I was hired by LogicBlaze at the time, which has been acquired by IONA and now Progress.

Gardner: Tell us a little bit more about the context of the ServiceMix ESB in some of the other Apache Software Foundation projects, just so our listeners understand that this isn't necessarily standalone. It can be used, of course, standalone, but it fits into a bigger picture, when it comes to SOA infrastructure. Maybe you could just explain that landscape as it stands now.

The bigger picture

Nodet: ServiceMix is an ESB and reuses lots of other Apache projects. The main ones which ServiceMix reuse is Apache ActiveMQ which is a message broker so it is for the JMS backbone infrastructure. We also heavily use Apache CXF, which is a SOAP stack that integrates nicely in ServiceMix. One of the other projects that we use is Apache Camel, which is a sub-project of Apache ActiveMQ, is a message router, which is really efficient and it uses DSL to be able to configure routers very easily. So these are the three main projects that we use.

Of course, for ServiceMix 4.0, we are also using the Apache Felix OSGi Framework, and lots of other projects that we use throughout ServiceMix. There are really big ties between ServiceMix and the other projects. Another project that we can leverage in ServiceMix is Apache ODE, which is the business process execution language (BPEL) Engine.

Gardner: Now, it's not always easy to determine the number of implementations, particularly in production, for open-source projects and code. It's a bit easier when you have a commercial vendor. You can track their sales or revenues and you have a sense of what the market is doing.

Do you have any insight into what's been going on, in a larger trend around these SOA open-source projects in terms of implementation volumes? Are we still in test, are people in pilot, or are we seeing a bit more. And, what trends are there around actual production implementation? I'll throw that to either one, Adrian or Guillaume.

Trenaman: I’m happy to chip in there. We’ve seen, quite a lot of work in terms of real-world sales. So you started in ServiceMix, obviously. We have been using ServiceMix for some time with our customers, and we have seen it used and deployed, in anger, if you will. What's interesting for me is the number of different kinds of users out there, the different markets that it gets deployed in. We have had users in airline solutions, in retail, and extensive use in government situations as well.

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.

Gardner: One of the nice things about this trend towards adoption is that you often get more contributions back into the project. Maybe it would be good now to understand who is involved with Apache, who is really contributing, and who is filling out the feature sets and defining the requirements around ServiceMix. Guillaume, do you have any thoughts about who is really behind this in terms of the authoring and requirements?

From the community

Nodet: The main thing is that everything comes from the community at large. It’s mainly users asking how they can implement a given use case. Sometimes, we don't have everything set up to fulfill the use case in the easiest way. In such a case, we try to enhance ServiceMix to cover more use cases.

In terms of contributors, we have lots of people working for different companies. Most of them are IT companies who are working and implementing SOA architecture for one of their customers and they are using ServiceMix.

We have a number of individual contractors who do some consulting around ServiceMix and they are contributing back to the software. So, it's really a diverse community. Progress is, obviously, one of the big proponents of Apache ServiceMix. As you have said, we run our business using the FUSE family of projects.

So, it's really a very diverse community and with different people from different origins, from everywhere in the world. We have Italian guys, we have, obviously, US people, and we have a big committee.

Gardner: The JBI specification has been quite central to ServiceMix. If you could, give us an update on what JBI, as its own spec, has been up to, and what that means for ServiceMix, and ultimately FUSE. Furthermore, let's get into some of the OSGi developments. It has really become hot pretty quickly in the market. So what's up with JBI and OSGi?

Nodet: The JBI specification has been out since the beginning of 2005. It defines an architecture to build some ESBs in Java. The main thing is that the key concept is normalized exchanges. This means that you can deploy components on the JBI container, and all of these components will be able to work together without any problems because they share a common knowledge of exchanges, and the messages between components are implemented. This is really a key point.

Anyone can grab a third party component from outside ServiceMix. There are a number of examples of components that exist, and you can grab such a component and deploy it in ServiceMix and it will just work.

That's really one of the main points behind the JBI specification. It’s a Java centric specification. I mean that the implementation has to be done in Java, but ServiceMix allows a lot of different clients from other technologies to jump into the bus and exchange data with other components.

So one of the things that we use for that is a STOMP protocol, which is a text-based messaging protocol. We have lots of different implementations from Ruby, Python, JavaScript and lots of different languages that you can use to talk to the ServiceMix bus.

OSGi is a specification that is really old, about 10 years, at least. It was originally designed for embedded devices. During the past two years, we have seen a lot of traction in the enterprise market to push OSGi. The main thing is that the next major version of ServiceMix, which will be ServiceMix 4.0, is based on OSGi and reuses the OSGi benefit.

The main driver behind that was mainly to get around some weaknesses of the JBI specification mainly related to the JBI packaging and class loader architecture. OSGi is really a nice specification for that and we decided to use it for the next version of ServiceMix.

Gardner: Now, we tend to see a little bit of politics oftentimes in the market around specifications, standards, who supports them, whether there is a competing approach, and where that goes. We’ve seen a bit of that in the Java Community Process over the years. I wonder, Adrian, if you might be able to set the table, if you will, around where these specifications are and what some of the commercial interests are?

For example, I know that IBM is quite strong behind OSGi, and Oracle has backed it to an extent as well. These guys, obviously, have quite a bit clout in the market. Set the table on the vendors and the specification situation now.

Sticking with JBI 1.0

Trenaman: JBI is currently at version 1.0, or 1.11 actually. There is a JBI 2.0 expert group, and I believe they are working under JSR 312. So, I think there’s work going on to advance that specification.

However, if you look at what the vendors are doing -- be it Sun, Progress, or Red Hat through JBoss -- I think the vendors are all sticking with JBI 1.0 at the moment, making customers successful with that version of the spec and in anticipation of a new version of the spec. But, I believe it’s quite quiet. Guillaume, is that correct, for 2.0?

Nodet: Yes. I am part of the 2.0 expert group for JBI and the activity has been quite low recently. One main driver behind JBI 2.0 is to refocus on what I explained is the key point of the JBI 1.0 specification, which is the concept of normalized exchanges and the normalized message router.

The goal of the JBI 2.0 Expert Group I think is to refocus on that and making JBI play much more nicely with other specifications that somewhat are seen as opponents to JBI, like SCA, and also play more nicely with OSGi because ServiceMix is not the only JBI implementation that goes towards the OSGi way. So we want also to be sure that everything aligns correctly.

Gardner: Just so listeners can understand, what is it about OSGi that is valuable or beneficial as a container in an architectural approach, when used in conjunction with the SOA architectural component?

Trenaman: 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. You mentioned politics earlier on, Dana, and the politics for me are interesting on the number of levels.

Here is my take on it. The first level is on the OSGi core platform, and what you’ve got there is a number of players who are all, in some sense I guess, competing to get the de-facto standard implementation or reference implementation. I think Eclipse Equinox emerges as the winner. They are now strongly backed by IBM.

The key players

And in the Apache Software Foundation you’ve got Felix. One of the other key players will be Knopplerfish OSGi, which is really Makewave, and they deliver Knopplerfish under a BSD-style license. So, we have some healthy competition there, but I guess in terms of feature build out Equinox seems to be the winner in that area.

That's one way of looking at it. The other thing is, if you look at your traditional app server vendors and what they are doing, IBM, Oracle, Red Hat, and Sun have all put OSGi, or are about to put OSGi, within their application servers. This is a massive movement.

I think it's interesting that OSGi is no longer a differentiator. It’s actually an important gatekeeper. You have to have it. This is a wave that the industry and that our customers are all riding, and I think they are very welcoming to it.

Politically, all of the app server vendors seem to be massively behind OSGi and supportive of it. The other area that maybe you alluded to is that in the broader Java community, there’s been a debate that's gone for some time now about JSR 277, which is the Java Community Process attempt at Java modules. The scene there is that JSR 277 overlaps massively with what OSGi intends to achieve, or rather has already achieved.

That starts getting messy all over again, because Java 7.0 will include JSR 277. So the future of Java seems to have hooked into this Java module specification, and not taking what would be the sensible choice, which would be to follow an OSGi based model, or at least to passionately embrace OSGi and weave it in a very nice way into JSR 277.

So, there is still some distance to go there on that debate over which one actually gets accepted and gets embraced by the community. I think the happiest conclusion for that is where JSR 277 really does embrace what OSGi has done, and actually, in a sense, builds support into the Java language for OSGi.

Gardner: Clearly, the momentum around OSGi has been substantial. I’ve been amazed at how far this has come so quickly.

Trenaman: Exactly.

Gardner: Now, IONA now within Progress Software, is in this not just for “peace on earth and good will toward men.” With the latest FUSE version being 4.0, you have a certification, support, and enterprise-ready service value around the ServiceMix core. Is there something about OSGi that helps Progress in delivering this to market, given the modularity and the better control and management aspects? I am thinking, if I am in certification and enterprise-ready mode for these, that OSGi actually helps me, is that correct?

It's a community issue

Trenaman: My perspective on that would be that embracing of OSGi in FUSE is a community issue. It’s the community that's driven that and that's a part of ServiceMix. So, this is something that we in Progress now are quite happy to embrace and then take into FUSE.

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.

Gardner: Great. Now, you mentioned the big “grid” word. A lot is being talked about these days in cloud computing, and there’s an interesting intersection here between open-source early adopters and the very technology savvy providers or companies and the cloud phenomenon.

We’ve seen some quite successful cloud implementations at such organizations as Google, Yahoo!, and Amazon, and we’re starting to see more with chat in the market from Microsoft and IBM that they are going to get into this as well.

These are the organizations that are looking for control, the ability to extend code and “roll their own.” That's where their value add is. What's the intersection between SOA, open-source infrastructure, and these cloud implementations? Then, we’ll talk about where these clouds might go in terms of enterprises themselves. Who wants to take the high view on the cloud and open-source SOA discussion?

Trenaman: A lot of SOA is down to simply "Good Design 101." The separation of the interface from the implementation is absolutely key, and then location independence, as well. You know, being able to access a service of some kind and actually not really care exactly where that is on the cloud, so that the whole infrastructure behind the service is transparent. You do not get to see it.

SOA brings some very nice concepts in terms of contract-first design and standard-based specification of interfaces, be they using WSDL or just plain old XML and REST -- or even XML and JMS.

I think the fact that we can now define in a well-understood way what these services are, and that allows us to get the data into and out of the cloud in a standardized way. I think that's massively important. That's one of the things that SOA brings to the cloud that becomes very important.

What open-source brings to cloud, apart from quality software against which to build massively distributed systems. What it brings is maybe a business model or a deployment model that actually suits the cloud.

I think of the traditional software licensing models for closed source where you are charging per CPU. When you look at massive cloud deployments with virtual machines on many different physical hardware boxes, those models just don't seem to work.

Gardner: A great deal of virtualization is taking place in these cloud infrastructures.

A natural approach

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.

Gardner: Let's move into this notion of a private cloud, which also requires us to understand a hybrid, or managing what takes place within a private, on-premises cloud infrastructure -- and then some of these other available services from other large consumer-facing and business-facing cloud providers.

Vendors and, in many cases, community development organizations are starting to salivate over this opportunity to provide the software, services, and support in helping enterprises create that more efficient, high availability, much more creative utilization range incumbent in a well-designed cloud infrastructure or grid or utility infrastructure.

Trenaman: Sure.

Gardner: It seems unlikely that an organization creating one of these clouds is going to go out and just buy it out of the box. It seems much more likely that, at least for the early adoption stages, this is going to be a great opportunity to be exerting your own special sauce as an internal IT organization, well versed in open-source community development projects and then delivering services back to your employees and your customers and your business partners in such a way that you can really reduce your total cost, gain agility, and gain more control.

Let's go to Guillaume. How do you see ServiceMix, in particular, playing in this movement, now that we are just starting to see the opening innings of private cloud infrastructure?

Nodet: 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.

Gardner: So, Progress has had quite a long history, several decades, in bringing enterprise development and deployment strategies, platforms, tools, a full solution. This seems to be a pretty good heritage combined with what community development can offer in starting to craft some of these solutions for private clouds and also to manage the boundaries, which I think is essential.

I can see an ESB really taking on a significantly larger role in managing the boundaries between and among different cloud implementations for integration, data portability, and transactional integration. Adrian anything to further add to that.

Dynamic provisioning

Trenaman: 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 ServiceMix, particularly ServiceMix 4, because it's absolutely geared for dynamic provisioning.

You can imagine having an instance of ServiceMix 4 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.

Nodet: Another thing I just want to add about ServiceMix 4, 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.

Gardner: We were quite early in this whole definition of what private cloud would or wouldn't be. Even the word “cloud,” of course, is quite nebulous nowadays.

I do see a huge opportunity here, given also the economic pressures that many organizations are going to be facing in the coming years. It's really essential to do more with less. As we move toward these cloud implementations, you certainly want to be able to recognize that it isn't defined. It's a work in progress, and having agility, flexibility, visibility into the code, understanding the origin for the code, and the licensing and so forth, I think is extremely important.

Trenaman: It’s massively important for anyone building the cloud, particularly a public cloud. That has got to be watched with total care.

Gardner: We’ve been talking about SOA infrastructure, getting some updates and refreshers on the ServiceMix and Apache Foundation approaches. talking to some community and thought leaders. We've learned a little bit more also about Progress Software and FUSE 4.0.

I’m very interested and excited about these cloud opportunities for developers to use as they already are. The uptake in Amazon Web Services for development activities and test-and-deploy scenarios and performance testing has been astonishing.

Microsoft is going to be right behind them with an appeal to developers to build on a Microsoft cloud. These are going to be ongoing and interesting, and so managing them is going to be critical to their success. A key differentiator from one enterprise to another it is how well they can take advantage of these, and manage the boundaries quite well.

I want to thank our participants. We have been joined by Guillaume Nodet. He is the software architect at Progress Software and vice president of Apache ServiceMix. Thank you, Guillaume, we really appreciate your input.

Nodet: No problem. I am glad that we have been able to do this.

Gardner: We have also been joined by Adrian Trenaman. He is distinguish consultant at Progress Software. Great to have you with us, Adrian.

Trenaman: It's a pleasure.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. I want to thank our sponsor for today's podcast, Progress Software. We’re coming to you through the BriefingsDirect Network. Thanks for listening and come back next time.

Listen to the podcast. Download the podcast. Find it on iTunes and Podcast.com. Learn more. Sponsor: Progress Software.

Transcript of a BriefingsDirect podcast with Guillaume Nodet and Adrian Trenaman of Progress Software on directions and trends in SOA and open source. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.