An Open Source SOA Strategy for Enterprise Service Buses

WSO2 has entered the open source SOA (service-oriented architecture) field with a slate of veterans from Web services specifications, application server design and lightweight framework development. The company’s latest offering to the market came June 11 with the arrival of WSO2 ESB 1.0, based on Apache Synapse and targeted at both developers who want to use enterprise service buses (ESBs) quickly, as well as operations architects seeking lightweight and high-performing components.

To help better understand and evaluate WSO2’s approach, I recently moderated a sponsored podcast with guests Ron Schmelzer, senior analyst at ZapThink, and Paul Fremantle, cofounder and vice president of technology at WSO2.

Listen to the discussion (43:45 minutes).

Here are some excerpts:

Dana Gardner: I’ve been impressed with the fact that SOA is creating early on an environment in which open source products are, in a sense, defining feature sets and approaches. In the past, we saw commercial products establish niches and define infrastructure areas that then became areas that open source products might pursue.

Ron Schmelzer: One of the things that makes SOA different from CRM, ERP, or even traditional enterprise-application integration is that SOA is architecture. It’s a style, an approach, or a methodology for building loosely coupled, composable services that meet the needs of the businesses. So it doesn’t really demand a particular technology stack. As a matter of fact, people can implement SOA using a very wide variety of technologies, which they probably already own.

Paul Fremantle: One of the things you see again and again in the computer industry is that people get to a point where they layer technologies on top of each other, and then it just gets too heavyweight. The benefits of reusing that old stuff are outweighed by the disadvantages.

We were very involved in open standards and in writing and implementing the specifications, but many of those implementations were layered on top of the Java EE enterprise runtime. We found that there was a whole new middleware based on XML and self-describing messages based on simple HTTP communications that didn’t need the existing EJB/Servlet runtime — that didn’t need to have all those existing layers.

So our philosophy when founding the company was to look at stuff afresh, and to build things with the simplest, most lightweight combination possible. We tried to target users’ requirements, rather than target an existing code base and legacy solution than we might have if we were working for a large company.

We need to cover not just the Java platform but also the C, Perl and PHP — the full gamut of platforms. SOA is not just a Java story. It’s really a cross-platform, cross-technology standard approach.

What you used to see was that companies would put together a kind of magic package, which was intellectual property, plus support, plus training, plus everything. And somehow they’d value all of this at some astronomical figure.

You’d see middleware sales of multimillion dollars. What we’re saying is that the software industry can’t maintain those levels of cost. Better value, open source software is the way to go. Obviously, open source companies have to make money, both for our own livelihoods and also because the users of open source need that commercial infrastructure there to make sure this works for them in the long term.

Schmelzer: The challenge of the market is that you can’t really take any two ESB products, as you did J2EE application servers, and compare them to each other and see a very large overlap of functionality.

What you will find is that a lot of the ESB vendors are basically taking the infrastructure technology they had prior to the SOA wave and have applied Web-services technology or perhaps business process composition on top of that to run services, which is what people are looking for.

If I have a service, I need to be able to execute it reliably. I need to be able to secure it, manage it, govern it and deal with the metadata. That’s what people really need from an SOA infrastructure — all that capability. How do I reliably run, secure and manage those services so that the loose coupling that I am looking for actually can exist?

To that extent, the ESB is really a catchphrase or a catchall for a wide variety of SOA infrastructures. If we look at the capabilities of the WSO2 ESB 1.0, it’s providing a lot of that SOA infrastructure capability.

Fremantle: We took a much broader view to say that the bus is really all of your XML, HTTP and JMS — all of your communications — and it encompasses a variety of clients and servers and different endpoints. So what do you need in that space? You need a very smart and simple mediator that can fit in, without disturbing those existing systems, and add those levels of management, connectivity and virtualization that I was just talking about. That was really our plan and our approach to this space.

I don’t think that the answer here is to have multiple proprietary ESBs and then some kind of uber-ESB between them. One of the things we tried to address, both in the Apache open source [Synapse] and in our own product, was making this product something that was really invisible to the rest of the world. You can almost think of our ESB as being a smart network router. You can have multiple versions of these around the network.

One thing we’ve done is to allow the ESB to run off of a set of metadata and configurations that’s remotely managed. It could be in a registry, it could be in an SVN repository, or it could be on a Web site or a file system. Multiple brokers can fit in the network and communicate with each other, but they could also communicate with completely different systems.

It’s really about using open standards and open metadata — things like WSDLs, XML schemas, URLs — as your foundation of integration, which means that you don’t really end up with this problem of multiple ESBs that don’t communicate. You end up with a single fabric that’s completely based on standards, and you happen to have some useful management endpoints within that fabric.

Click here for more podcasts.