WSO2 Data Services Provide Catalyst for SOA and Set Stage for New Cloud-Based Data Models

Transcript of BriefingsDirect podcast on data services, SOA and cloud-based data hosting models.

Listen to the podcast. Sponsor: WSO2.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, a sponsored podcast discussion about data services, how services-oriented architecture (SOA) is enabling an expansive reach for data, particularly enterprise data, how this will relate to the development of cloud infrastructures and services.

We’ll also examine what technologies and approaches organizations will need to federate and integrate these data sources and services and hosts, but without additional risk. That is to say, to free up data, give it more legs, but without losing control or increasing security risk.

We're also going to look at how open-source software relates to this, and how organizations are bridging the risk reduction and larger availability of data using open-source software.

To help us in this discussion, we are joined by distinguished a panel. First, Paul Fremantle, the chief technology officer at WSO2. Welcome, Paul.

Paul Fremantle: Hi, nice to be here.

Gardner: We are also joined by Brad Svee, the IT manager of development at Concur Technologies, a travel and expense management company in Redmond, Wash. Welcome to the show, Brad.

Brad Svee: Glad to be here.

Gardner: We are also joined by James Governor, a principal analyst and founder at RedMonk. Good to have you back, James.

James Governor: Thank you very much. Hello, everyone.

Gardner: Let's set this up by looking at the problem. I suppose the good news of looking into the past is that data has been secure and controlled. There are lots of relational databases with many, many bells and whistles applied over the years. There has also been a lot of development, middleware, and system's administration work to manage that data, keep it available, but also secure. That's the good news.

The bad news is that it's been limited in some respects by that firewall of personnel, technologies, and standards around it. I want to go to first to Paul Fremantle. Can you tell us a little bit about why the old model is not going to be sustainable in the world of services and mixed hosting environment?

Fremantle: It's a very interesting question. There are two key issues around the old model. The first is the just-in-time nature of data systems that are being bought today. Typically, customers are coming onto Websites and expecting to see the status of the world as it is right now.

They don't want to know what happened yesterday. They don't want to know what happened a week ago. They want to know exactly what happened right now. So it's very important that we move away from batch-oriented systems and file dumping and move to a real, live connected world, which is what people expect out of the Internet.

That live, connected world needs to be managed properly and it's very, very difficult to build that as a single monolithic system. So, it's really essential to move the ownership of that data to the people who really know it, create it, and own it, and that really plays to SOA. This is the model of keeping the data where it belongs and yet making it available to the rest of the world. That's the first point.

The second point is, of course, the danger inherent in getting it wrong. I have two stories, which I think will shed some interesting light on this. One is, I was working with a government organization and they were involved in a situation where every day one of the employees has to FTP a data file from a remote system and back load into their local system.

The employee went ill, and, of course, this didn't happen. They had a whole process to find out who had the password, who could do this and solve this problem. The employees had no one there to back load this data. As I was investigating, it turned out that data in the remote system, from the other organization, was actually coming from within their own organization.

There was another employee uploading the data from the main system to the remote system every day, and they had no clue about this. They didn't realize that this process had built up, where the data from organization A, was being sent to organization B, and then re-downloaded to organization A again, every single day, taking up two employee's time to do that.

Gardner: This is sort of the medieval approach to data transfer.

Fremantle: This is the medieval approach to data transfer. This was not back in 1963 that this is happening. This was actually happening in 2007.

Governor: Medieval or not, the simple fact is that there are vast amounts of exactly that kind of stuff going on out there. Another lovely story told by Martin Fowler talks about a customer -- I believe he was in the U.K. NHS, but I should be a little bit careful there. I should say it was a large organization, and they were freaking out. They said, "We've got to get off Java, because the printer driver is just no good."

He said, "What exactly are you trying to do? Let's have a chat about the situation." "We got to get off Java. We will just try and work it out." He looked at the work was that got involved. Basically, they were getting a document, printing it out, taking it across the room, and then typing it into another system on the other side of the room. He had to tell them, "Well, maybe there is another way of doing it that won't require printer drivers."

Gardner: One of the motivators, it seems, is if nothing dramatic requires you to change your patterns, then you stay with them. It's sort of inertia with people's behavior, and that includes IT. What we're seeing now is an impetus, or an acceleration and automation in services, because they have to, because there are outside organizations involved. A business process is not strictly internal, from one side of the room to the other, but could be across the globe and span many different companies. Does that sound correct, Paul?

Fremantle: Absolutely. I just want to give you a second example, which has been very well published in the U.K. where I live, but maybe it hasn't been so well known outside of U.K. The revenue and the customs in the U.K. had a significant problem recently, where they sent a CD containing 20 million records, including the birth dates, names, national insurance numbers, and bank account details of the 20 million people to another government department.

And, they lost it. They sent it again, and they lost it again. It would not be too far to say this had significant ramifications on the government and their ability to stay in government. The payoff of this was, they had policemen out searching rubbish dumps. They had to send a personal letter to each of the 20 million people. Banks had to update their security procedures.

The overall cost of this mistake, I imagine, must be in the millions of pounds. Now, the interesting question is, firstly, they didn't encrypt that data properly, but even if they had, there is a huge difference between encrypting an online system and encrypting a CD. If a hacker gets hold of the CD, he can spend as long as it takes to decrypt that system. If it takes him two years of computing power to do that, he can sit there for two years and break it.

If you have an encrypted online system and someone keeps trying to break it, the administrator sees log messages, knows that something is happening, and can deal with that. So it's not just the lack of encryption and the bulk dumping of data from one department to other, that's the problem. The model of sticking it on a CD hugely increases the dangers.

Governor: Well, people should be imprisoned for that, or at least lose the right to trade. Obviously, being government organizations, it's difficult to make that stick, but the U.K. government loves the use of phrase "fit for purpose." Quite frankly, there has been evidence that they are not fit for purpose.

Interestingly enough, one of the things about the importance of data and managing it more effectively, is thinking about data in a more rigorous way. I was going to talk on this call about "leaky abstractions." One of the problems with SOA is the notion that, "Oh, we can we can just take the system as it is and make it available as a service."

Actually, you do want to do some thinking and modeling about your data, your data structures, and how it can be accessible, and so on, because of this notion of leaky abstractions. You can push something in one place and something else is going to pop out in another by just taking a service as it is and making it online. You may not be doing the work required to use it more effectively.

I think that's the kind of thing that Paul is talking about there. What better example of the leaky abstraction is there than somebody sending a disk and not tracking where it goes? Again, the fact that there wasn't any cryptography used is really shocking, but frankly, this is business as usual.

Fremantle: In fact just to completely confirm what you are saying there, the government department that wanted this data did not want the bank account details, the national insurance numbers, or the ages. They didn't want all that data. What actually happened was the revenue and customs team were not sufficiently IT aware to be able to export just the data that was wanted, so they dumped everything onto the disk.

I think that exactly confirms what you are talking about the leaky abstraction. They just pushed out everything, because that was the simplest possible thing to do, when it wasn't exactly what's required, which is what should have been done.

Gardner: So, it does seem clear that the status quo is not sustainable. That there is inherent risk in the current system and that simply retrofitting existing data in turning it on as a service is not sufficient. Either you need to rationalize, think about the data, and generate the ability to slice it and dice it a little better, so that in the case of this disk of vast amounts of information, there was only a small portion of that that was actually required.

Let's look at this also through the lens of, "If we need to change, how do we best do best do that?" Let's look at an example of how someone who needs to view data in a different sense, in a more modern sense, how they are adjusting? Let's go to Brad at Concur. Your organization is involved with helping to improve the efficiency and productivity of travel and management inside of organizations.

Your data is going to come from a variety of areas that probably could be sensitive data in many organizations. Certainly, people are not happy about having their travel information easily available around the organization or certainly outside of it. And, of course there are government and tax implications, compliance, and implications as well. Can you give us a little bit of sense of what your data problem set is and if it's different from what we have heard on the "medieval" front? What sort of approaches you would like to take and have been taking?

Svee: First, I would like to clarify the distinct separation between our research and development team, which actually works on our product that we sell the clients, and my team, which works internally with our internal data.

I would like to draw a distinct clarification between those two. I am only able to speak to the internal data, but what we have found is exactly that that. Our data is trapped in these silos, where each department owns the data, and there is a manual paper process to request a report.

Requesting a customer report takes a long time, and what we have been able to do is try to expose that data through Web services using mashup type UI technology and data services to keep the data in the place that it belongs, without having a flat file flying between FTP servers, as you talked about, and start to show people data that they haven't seen before in an instant, consumable way.

Gardner: So, not even taking that further step of how this data might be used in an extended enterprise environment or across or departmental organization boundaries, just inside your organization, as you are trying to modernize and free up the data, you are looking at this through the lens of availability, real time, lower cost and clip, print, and touch from IT personnel. What sort of technologies and approaches have you been taking in order to try to achieve that?

Svee: For the last year or so, we have been pushing an SOA initiative and we have been evaluating the WSO2 product line, since, maybe November. We have been trying to free up our data, as well as rethink the way all our current systems are integrated. We are growing fairly rapidly and as we expand globally it is becoming more and more difficult to expose that data to the teams across the globe. So we have to jump in and rethink the complete architecture of our internal systems.

Gardner: What is it about the architecture that has a bearing on these flexibility and agility you are looking for, but that also protects your sense of reduced risk, security privacy access control?

Svee: Most of the data that we are dealing with is fairly sensitive, and therefore almost all of it has a need for at least per-user access basis, as well as, when we are transporting data, we will have to make sure that it's encrypted or at least digitally signed.

Gardner: Now, it seems to me that this data will need to be available through a browser-based portal or application to the end users, but that the data is also going to play a role with back office system, ledger, and different accounting activities, as this travel and expense content needs to be rectified across the company's books.

Svee: The browser becomes the ubiquitous consumption point for this data, and we are able to mash up the data, providing a view into several different systems. Before, that was not possible, and the additional piece of moving the file between financial systems, for example, we are able to not have to pull files, but actually use Web services to send only the data that has changed, as opposed to a complete dump of the data, which really decreases our network bandwidth usage.

Governor: There's even potentially a green argument in there. I mean, all of this batch is just kind of crazy and unnecessary. We see a lot of it. There is so much data duplicated everywhere. It seems like we, as an industry, are very good at just replicating and getting ridiculous redundancy, and not so good at synchronizing and really thinking about what data does need to be transported and working with that accordingly.

That sort of makes a lot of sense to me. It's very good to hear you are taking that approach. I think sometimes we miss-call things SOA, when in fact what you are doing is kind of "suck and play." You take this thing, suck old things out, and then work on the new thing, as opposed to actually thinking about the data structures you need to enable the data to be useful and fit you.

Gardner: Let's go to Paul. Now, here is an instance where the organization has, I think, its feet in both camps. In the old style, there is accounting, the ledgers, and data extension across application sets from a common repository, and how to batch that in such a way that the data is all on the same page, so to speak, across these applications in a time frame.

We also need to take this out through Web applications to individuals and also across applications that are Web services enabled. So, it sounds like what we have here is a situation where the data needs to do many different tricks, not just a couple of old basic tricks.

What is it that WSO2 has done recognizing this kind of need in the market and is able to satisfy this need?

Fremantle: What we have built is what we call WSO2 Data Services, which is a component of our application server. The WSO2 Data Services component allows you to take any data source that is accessible through JDBC, MySQL databases, Oracle databases, or DB2, but, in addition, we also have support for Excel, CSV files, and various other formats and very simply expose it as XML

Now this isn't just exposed to, for example, Web Services. In fact, it can also be exposed by REST interfaces. It can be exposed through XML over HTTP, can even be exposed as JSON. JavaScript Object Notation makes it very easy to build Ajax interfaces. It can also support it over JMS, and messaging system.

So the fundamental idea here is that the database can be exposed through a simple mapping file into multiple formats and multiple different protocols, without having to write new code or without having to build new systems to do that. What we're really replacing there is, for example, where you might take your database and build an object relational map and then you use multiple different programming toolkits -- one Web services toolkit, one REST toolkit, one JMS toolkit -- to then expose those objects.

We take all that pain away, and say, "All you have to do is a single definition of what your data looks like in a very simple way, and then we can expose that to the rest of the world through multiple formats."

Gardner: When that data changes on the core database, those changes are then reflected across all of these different avenues, channels, and approaches it's sharing. Is that correct?

Fremantle: Absolutely, because it's being accessed on demand and then exposing them as needed through whichever format they ask for. So, it's not storing those data formats in it's own system,

Governor: One of the things that I really like about this story is that we went through a period where there was a view that everything needed to be done with the WS stack, and the only way to do SOA, the only way to data integration, was to use these large-scale Web standards. But they're not critical in all cases, and it really depends on your requirements for the security and so on. Do you really need SOAP and some of the heavier weight protocols and technology?

I think that the approaches that say, "Let's understand is this behind the firewall? What are the levels of protection that are required?" "Can we do this in a simpler fashion?" are very valuable. The point about JSON, for UI related stuff, certainly REST kind of interfaces, but at the end of the day it's a question of, do you have developers that are available out there in your shop or to hire that are going to be able to do the work that's required and some good examples that came out of the Web world?

If you look at eBay, they had a SOAP API, but nobody used it. A great number, or 80 percent plus, of the calls were using RESTful styles. Understanding the nature of your problem and having more flexibility is very, very important.

Gardner: One of the things that I really like about this is that, almost like Metcalfe's Law. The more participants there are on the network, the more valuable it is. The more people and systems and approaches to distributing data, the more valuable the data becomes. What's been nice is that we've elevated this distribution value with data, at the same time that open source and community-based development have become much more prominent.

That means that the ways in which the data is shared and transferred is not just going to be dependent upon a commercial vendor's decision about which standards to support, but we can open this up to a community where even very esoteric users can get a community involvement to write and create the means for sharing and transferring.

The data can take on many more different integration points, and standards can evolve in new and different ways. Let's discuss a little bit, first with Paul, about the role of open source, community, and opening up the value of data.

Fremantle: I am just a fanatic about open source and community. I think that open source is absolutely vital to making this work, because fundamentally what we're talking about is breaking down the barriers between different systems. As you say, every time you're pushing the proprietary software solution that isn't based on open standards, doesn't have open APIs, and doesn't have the ability to improve it and contribute back, you're putting in another barrier.

Everyone has woken up to this idea of collaboration through Web 2.0 websites, whether through Flickr or FaceParty or whatever. What the rest of the world is waking up to is what open-source developers have been discovering over the last five to ten years. Open source is Web 2.0 for developers. It's how do you collaborate, how do I put my input, my piece of the pie? It's user-generated content for developers, and that power is unbelievable. I think we're going to see that grow even more over the next few years.

Governor: I fundamentally agree with it. Open source was an application of a pattern. Open source was the first real use case for this need for a distributed way of working, and we're certainly seeing that broadened out. People are getting a much, much better understanding of some of the values and virtues of open approaches of exposing data to new sources.

Very often, you will not get the insight, but someone else will, and that sort of openness and transparency, and that's one of the key challenges -- actually just getting organizations to understand some of the value of opening up their data.

I think that is one thing to have to tools to see that. Another is that we all now are beginning to see organizations kind of get it. Certainly, "How do we syndicate our information?" is a really key question. We are seeing media companies ask themselves exactly that. "Do we have an API? How do we build an API? Where do we get an API, so that people can syndicate the information that we have?”

I suppose I'm just double-clicking on what Paul said -- that passion is something that is becoming more and much better understood. Reuters is realizing it has to have an API. The Guardian, which is a British newspaper -- and those Americans certainly of the leftward persuasion are very familiar with it -- now has a team that is also presenting at Web conferences and talking about the API. We've got to think about how to make data more available, and open source will just be the first community to really understand this

Gardner: I'd like to bounce this off of Brad at Concur. Do you feel a little bit less anxious, or more at ease, knowing that whatever data needs that you have for the future, you don't have to wait for a vendor to come up with the solution? You might be able to go and explore what's available in a community, or if it's not available, perhaps write it yourself or have it written and contribute it back to the community. It seems to me that this would be something that would make you sleep better at night -- that an open-source and community-based approach to data services deliverability gives you more options.

Svee: I personally love open source. I think that it is the movement that's going to fix software and all these proprietary systems. I think that my small team, four developers and myself, would not be able to produce the kind of quality products internally that we're essentially asked to do, without being able to stand on the shoulders of a lot of these geniuses out there who are writing amazing code.

Gardner: Do you agree that there is this sense that you can almost future-proof yourself by recognizing, as you embrace open source, that you're not going to get locked in, that you're going to have flexibility and opportunity in the future

Svee: Exactly. I find that there are a few products that we have that we've been locked into for quite some time. It's very difficult to try to move forward and evaluate anything new, when we're locked into something that's proprietary and maybe not even supported anymore. With the open-source community out there, we're finding that the answers we get on forums and from mailing lists are every year getting faster and better. More people are collaborating, and we're trying to contribute as much as we can as well.

Gardner: And, of course, over the past several years, we've seen a tremendous uptake in the use of open-source databases and sources from MySQL, Ingres, Postgres, and there are others. Let's bounce this back now to the WSO2 product set. What is it about, when you are developing your products, Paul, that open source becomes an enabler, as well as, in a sense, a channel into the market?

Fremantle: What was interesting about us developing this data services solution was the fact of what we built on top. The data service's component that we built actually took us very little time to get to its first incarnation, and obviously we are constantly improving it and adding new capabilities.

We were working on that and it didn't take time, but the very first prototype of this was just a piece of work by one of our team who went out and did this. What enabled that really was the whole framework on which it was built, the access to framework, the app server that we built, and that framework built on the work of literally hundreds of people around the world worked on it.

For example, if we talk about the JMS support, that was a contribution by a developer to that project. The JSON support was a contribution by another developer and relied on the JSON library written by someone else. The fact that we can choose the level of encryption and security from HTTPS all the way up to full digital signatures relies on the works of the Apache XML security guys who have written XML security libraries. That's an incredible, complex piece of work and it's really the pulling together of all these different components to provide a simple useful facility.

I think it's so amazing, because you really stand on the shoulders of giants. That's the only way you can put it. What I like about this is to hear Brad say that he is doing the same, we are doing the same, and all around there is a value change of people doing small contributions that, when put together, add up to something fantastic. That's just an amazing story.

Gardner: Given that there are many approaches that Brad, as a user organization, is undertaking, and they dovetail somewhat with what you are doing as a supplier, we also have other suppliers that are embracing open source increasingly and building out product sets that have originated from technology that was contributed or project format or license. How do these pieces come together, if we have a number of different open-source infrastructure projects and the products? I'm thinking about perhaps an ESB, and your data solution, and some integration middleware. What's the whole that's greater than the sum of the parts?

Governor: I certainly have some pretty strong opinions here. I think we can learn a lot from the ecosystems as well. One of the absolutely key skills in open source, as a business, is packaging. Packaging is very, very important to open source, and pulling things together and then offering support and service is a very powerful model.

It's really nothing new. If we look at personal computers, you go out and you can buy yourself chips from AMD or Intel, you can buy an OEM version of Windows or choose to do with Linux, you can buy RAM from another company, you can buy storage disks from another company, and kind of glom it all together.

But, as that industry has shown us, it really makes a lot more sense to buy it from a specialist packager. That might be Dell, HP, or others. I think that open-source software has really got some similar dynamics. So, if you want an Eclipse IDE, you are likely to be buying it from an IBM or a Genuitec or CodeGear, and a couple of those are our clients. I should disclose that.

In this space we've got the same dynamics. If you are, for example, a Web company, and you don't want to be paying these third parties to do that packaging for you, fine. But, for the great mass of enterprises, it really doesn't make that much sense to be spending all your time there with glue guns, worrying about how pieces fit together, even in Eclipse, where it is a very pluggable architecture.

It makes a great deal of sense to outsource that to a third party, because otherwise it's really a recipe for more confusion, I would argue. So yes, you can do it yourself, but that doesn't necessarily mean, you should. The PC example, yes, for a hobbyist or someone who wants to learn about the thing, absolutely, build your own, roll your own. But, for getting on with things in business, it does make sense to work with the packager that's going to offer you full service and support.

Fremantle: I've got to jump in here and say that's exactly our model. Though we don't just offer the data services, we offer, an ESB, a mashup server, and SOA registry, and we make sure all those things work together. The reality is that there are a lot of programmers out there who are hobbyists, so there are a lot of people who do like to take individual components and pieces and put them together, and we support both of those equally, but I think your analogy of the PC market and that plug and play model is absolutely like open source and specifically open-source SOA. We all focus very much on interoperability will make sure that our products work together.

Open source drives this market of components, and it's exactly the same thing that happened in the PC market. As soon as there was an open buy off that wasn't owned by a single company, the world opened up to people being able to make those components, work in peace and harmony, and compete on a level playing field. That's exactly where the open-source market is today.

Gardner: So how about that, Brad? Do you really like the idea that you can have a package approach, but you can also shake and bake it your own way?

Svee: That's exactly the sweet part in my opinion. I can shake and bake, I can code up a bunch of stuff, I can prototype stuff rapidly, and then my boss can sleep well at night, when he knows that he can also buy some support, in case whatever I cook up doesn't quite come out of the oven. I see there's a kind of new model in open source that I think is going to be successful because of that.

Gardner: Okay, now we have seen some very good success with this model: have it your way, if you will, on the infrastructure level. We are moving up into data services now. It seems to me that this also sets us up to move an abstraction higher into the realm of data portability. Just as we are seeing the need in social networks, where the end user wants to be able to take their data from one supplier of a social networking function to another, I think we are going to start to see more of that in business ecologies as well.

A business will not want to be locked into a technology, but it also doesn't want to be locked into a relationship with another supplier, another business. They want to be able to walk away from that when the time is right and take their data with it. So, maybe we'll close out our discussion with a little blue-sky discussion about this model taking a step further out into the cloud. Any thoughts about that, Paul?

Fremantle: I think that's a really interesting discussion. I was at a conference with Tim O'Reilly about two years ago and we were having exactly this discussion, which is that openness of services needs to be matched by openness of data. We are definitely seeing that in the Web marketplace through back-end systems like Amazon S3 storage, and we are beginning to see a lot of other people start to jump on this and start to build open accessible databases.

I think that's an absolutely fantastic usage for this kind of data service, which is to say, "It's my data. I don't just want to host things in an open fashion. I don't want to write code in an open fashion. I want open services and open data, so I can get it, move it, protect it myself, and relocate it."

So, I think there's a really interesting idea behind this, which is, once we get to the point where your data is no longer tied to a specific system and no longer has to be co-located with a particular MySQL database, we start to free up that processing. If you look at what Amazon did with the Elastic Cloud Service and their storage system, the storage system came first. The data services were a precursor to having an effective cloud-computing platform. So, it's really a precursor. You have to have data services, before you can start to migrate your processing and scale it up in this fashion.

Gardner: What do you think, James? Is this something that will be in great demand in the market, and there is also a green angle here?

Governor: Yeah, I think undoubtedly it will. Simon Phipps from Sun talks about the freedom to leave. We had a big example recently, Comcast buying Plaxo. They have lost a lot of the users. A lot of Plaxo users just closed up their account there. Interestingly enough, Plaxo had a nice function to do that -- very good for closing the account, not so good for exporting the data. I am not so sure the problems are primarily technical. I think there are a great deal of policy and social problems that we are going to have to deal with.

It's very interesting to me that we call people heroes that are trying to break Facebook terms of service, in some cases with the recent data portability example. We've got some really key challenges about what does data ownership mean. From my perspective, as I said earlier, I think it's very important that we have the mechanisms whereby we have access to data without necessarily allowing replication of it all over the place.

If it is your data, then yes, by all means, you should have permission to take a copy of it. What about if you're on a network and you want to take all the data and all of the surrounding metadata? Really, the discussion becomes about that metadata. Am I allowed to get anything back from Google about my behaviors and other people's behaviors?

It's really a social question, and we, as a society or a number of different societies, have got to think about this, and what we want from our data, what we want from privacy, and what we want we want from transparency. We can gain wonderful things, I mean wonderful advantages, but there is also the flip side, and I think it's very important that we keep that in mind.

So, it's going to be a wild ride. It's exciting, and I think that it is important that we get the tools in place, so that once we get the policies well understood, we can actually begin to do things more effectively. So, again, it's very exciting, but there are a lot of threats and lot of risks that we do need to take account of. Those risks are expanded, as I say, by what I sometime call "information bulimia." This notion that we just keep eating and swallowing more and more information and more data and we need more information, and if you do that, what you end up doing is puking it all up.

Gardner: Let's close here with that real-world perspective, Brad, aside from the visual image of puking, does this interest you in terms of the idea of third-party neutral cloud-based data and does that have any bearing on your real-world issues?

Svee: Well, I can give you an example what we were able to do with data services. Within a matter of weeks, not even months, we are able to use the data services in the application server from WSO2 to essentially give a complete client picture to the business by reaching into the ERP system, pointing out invoices and products, and then reaching into the CRM system to pull out open issues, as well as, sales manager, probably about 50 data points about each customer from the CRM, and then expose those services through a simple JSON-based UI with a smart type-ahead for the customer name. Quickly, we are able to show a picture of our clients that hadn't previously been available -- and within a matter of weeks actually.

Gardner: That data could have come from any number of different sources if, to James' point, you had the proper permissioning?

Svee: Yeah, and since we are IT and we own the systems, we are able to determine who is who, and we were able to use a Web service, another data service into our HR system, to pull out roles to see whether or not you could access that information.

Gardner: That's highly valuable from a productivity and planning perspective. If you are a business strategist, that's precisely the kind of information you want?

Svee: Exactly, and they were amazed that they've had been able to live their lives without it for so long.

Gardner: Paul, do you think much of this common view business, when it comes to data services?

Fremantle: Actually, we are working on another project with a health-care provider, which is providing a single patient view. So, it's exactly the same kind of scenario with significant security and encryption and data challenges to make sure that you don't provide the wrong information to the wrong person. Obviously, all the same issues need to be solved, and being able to pull together everything that is known about a patient from multiple different system into a single view once again has huge value to the organization.

Gardner: Well, this has to be our swan song on this particular podcast. We are out of time. I want to thank our guests for helping us get into a nice far-reaching discussion about data services, what the problem set has been, what the opportunity is, and how at least one organization, Concur, is making some good use of these technologies. We have been joined by Paul Fremantle, chief technology officer at WSO2. Thank you, Paul.

Fremantle: Thank you, it has been great fun.

Gardner: I also strongly appreciate your input Brad Svee, IT manager of development at the Redmond, Wash.- based Concur. Thank you, Brad.

Svee: Well, thank you.

Gardner: And always, thank you, James Governor from RedMonk for joining. We appreciate your input.

Governor: Thank you much. It has been an interesting discussion.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect Podcast. Thanks and come back next time.

Listen to the podcast. Sponsor: WSO2.

Transcript of BriefingsDirect podcast on data services, SOA and cloud-based data hosting models. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.

Transcript of BriefingsDirect Podcast on Open Source Web Services Stacks and WSO2's Latest ESB

Edited transcript of BriefingsDirect[TM/SM] podcast with Dana Gardner, recorded June 5, 2007.

Listen to the podcast here. Sponsor: WSO2.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to a sponsored BriefingsDirect podcast. Today, a discussion about an energized entrant into the open-source Web services stack and Services Oriented Architecture (SOA) infrastructure field.

We’ll be talking to WSO2. They’ve been putting together a talented team with backing from Intel Capital to create a robust, lightweight and purely services- and standards-based stack and infrastructure offerings.

With us today to discuss their approach and philosophy to open-source and Web services support -- as well as a new product from WSO2 in the enterprise service bus (ESB) market -- is Paul Fremantle, vice president of technology at WSO2. Welcome to the show, Paul.

Paul Fremantle: Hi, Dana, nice to meet you.

Gardner: Glad you could be with us. Also joining us, a senior analyst from ZapThink, Ron Schmelzer. Welcome to the show, Ron.

Ron Schmelzer: Thank you for having me, Dana.

Gardner: Ron, you cover the field of SOA very closely. You’ve seen how both the commercial and open-source approaches have been churning over the past months and years. I wonder if we could just start the discussion with a level-set about open source and SOA.

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.

Do you agree with that? Do you think that there is something new and different going on with open source and SOA?

Schmelzer: Well, there’s certainly a role for commercial software vendors, which are obviously having a huge impact on the space. It’s very hard to ignore what IBM, BEA, Microsoft, Oracle, Sun, SAP, and all those guys are doing in the space, as well as legions of smaller vendors and niche-focused vendors who are commercial.

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. There are a lot of case studies on SOA for legacy and mainframe implementations.

So there is a significant role for open source to play in this market, given that one of the major roles that open source plays in general in IT is as an equalizing or commoditizing force for various technologies that have already made their way, and where people already understand the technology's capabilities or requirements. Open source has, to a certain extent, made that technology a lot more accessible.

Of course, the other part of open source is that it has rapidly accelerated the pace of software development through much more iterative, short-development cycles, [and] some large vendors simply can't keep up with that pace. So there is a certain role for that.

Gardner: SOA, by definition, is inclusive and supports heterogeneity, and those also are foundational notions for open source.

Let’s go to Paul Fremantle. First, give us a little bit of background for those listeners who aren't familiar with WSO2. Give us a quick rundown on the company. You’ve come from a background of standards development and a long heritage at IBM Research and product support. Tell us the story of WSO2.

Fremantle: Certainly. WSO2 was founded in August 2005. The three founders were myself, Sanjiva Weerawarana, and Davanum Srinivas. We’d all worked very much on the Web services stack.

Sanjiva was one of the leads on all the standards on Web services at IBM, and his name is on many of the documents.

I was one of the product development leads at IBM where I integrated the first SOAP support into the WebSphere platform. I built a key component of some of the WebSphere features known as the Web Services Invocation Framework, which was used heavily in the BPEL orchestrator and other parts of the stack, and which had a lot of influence on the SCA and JBI specifications. Also, I led the team that built IBM’s Web Services Gateway, and was one of the key members of the ESB development team there. So we had a very strong background.

The third partner, Davanum Srinivas, was in the CIO's office at Computer Associates and was very involved in Computer Associates' Web services stack. The other thing that tied us all together was that we all had a strong involvement at Apache Foundation.

Gardner: You’ve developed a philosophy of approaching this from a "pure" perspective. That’s to say, you don’t have a legacy to support or preserve. You’ve looked for a clean, simple, lightweight, REST-full approach, supporting AJAX-based Web applications. How did you switch from a commercial and proprietary mentality? And what drove you to this current philosophy that you’re supporting?

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. And the point at which that happens depends on the technology.

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.

Our motivation was to do exactly what’s needed. There is a little synergy there with most open-source projects. Open-source projects tend to be small, componentized, and to try and solve specific needs. They work best when there is that lightweight aspect to them.

Gardner: Yet, at the same time, you’re being ambitious. You’re integrating widely with your stack, integrating to Microsoft .NET and the Windows Communications Foundation, formerly Indigo, with also full connectivity to the Java EE environment, even back to CICS, SAP, other Web services standards, and IBM WebSphere. It seems like you want to be neutral as well.

Fremantle: Certainly. This comes back to what Ron was just saying, which is that SOA is about working with everyone equally. It’s not about having a proprietary stack. As we talk about an ESB approach, you will see that one of our key tenets is that we’re not layering interoperability at the edges as adapters onto our stack, which is what you see a lot of people doing. We’re building interoperability into the heart of all our code. So naturally we want to have as wide an interoperability as possible.

We also think there is a critical mass here -- that we need to be ambitious. 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.

Gardner: Many of us are familiar with blogging and we know what can happen in the comments fields when we post things. I want to get this upfront right away. Many times when I blog around open source and SOA and how they relate to one another, there’s inevitably the comment about, "Well, how do you make a living at this? There are an awful lot of resources being devoted to something that is not your intellectual property."

Let’s go right to that and address your business model, and perhaps the role that systems integrators and support will play in how this is driven successfully into the market.

Fremantle: Absolutely. First, we’re a completely open-source company. We do everything under the Apache license. We don’t have any kind of "gotchas," different versions, relicensing and so forth. Our revenue stream is made out of our support to customers, selling support contracts, and providing a highly professional, enterprise-class support for both the Apache open source [Synapse ESB, for example] offerings and our own products.

Secondly, it’s made out of services and training, consultancy training, and custom development.

Finally, we also have partnerships, mostly with other technology companies who embed our technology and also with system integrators and ISVs who then use our technology to build solutions for their customers.

Having worked in a highly commercial proprietary software development shop, we know that support, services, and getting code that works is actually what really counts in the software industry.

Gardner: That’s the long-term play. You look to lose some revenues upfront on licensing, but [rely instead] on what’s going to sustain the company over time. It's that long tail, if you will, of support and maintenance.

Fremantle: Absolutely, and I see the software industry moving in this direction. 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.

Gardner: Another thing that you are taking advantage of is globalization. You have a distributed company. You’re taking advantage of development resources where they are, rather than where you’d like them to be, and you’re using Apache and open source as the governance over this development process. Tell us quickly a little bit about what that means in terms of efficiency and depth.

Fremantle: Well this is a very interesting story because we're a company that has offices in the U.S., here in Europe where I'm located, and also in Sri Lanka. These locations all actually came out of a growth of open-source developers in Sri Lanka. So in many ways I feel like I’m the outsourced guy because I’m the European offshoot for a bunch of smart developers based in Sri Lanka who are really driving the direction and the quality of this product. It’s not your traditional outsourcing operation at all, it’s very much globalization.

We found that the open-source model that Apache pioneered with open mailing lists, open-source code repositories, and free and open exchange of ideas on the mailing list, have shown us a way of operating a loosely coupled and distributed development team that actually works in practice. That means that I can participate in projects with people based in the U.S. and in Sri Lanka through that structure and process. That works just as effectively as when I used to work with my development team all located in the same office.

Gardner: We’ve mentioned how you are very ambitious in your scope. You’re looking for a full Web services stack. You’re producing an application server. You’re going to be introducing a mashup server. But today we’re going to focus on the ESB product that you’re going to be demonstrating and supporting for real in June.

Let’s go to Ron at ZapThink. Ron, the role and definition of ESB have been points of contention, and yet most folks that are pursuing the support of an SOA activities infrastructure market have some sort of an ESB approach. Why don’t you give us a level-set, if you could, on the state of the ESB market, why it’s essential for SOA development and maturity, and what you think is the proper functionality -- or perhaps your philosophy around ESBs?

Schmelzer: The place to start is that an ESB is actually not specifically necessary for an SOA. However, there are a lot of things that people require of their SOA infrastructure that a lot of vendors, who are pushing ESB products, are selling. 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, it’s providing a lot of that SOA infrastructure capability. I don’t know if we’re ever going to get to a point in this industry where there will be a standardization of the ESB term. There are just too many forces in the industry that would basically try to own that term and not really make that happen.

Gardner: Let’s switch over to Paul again. You have described your offerings as middleware for Web services. In a sense, you’re starting from the perspective of this not being in a distributed-object environment, but more in an XML and semantic environment. Tell us what your requirements were as you started approaching this ESB project?

Fremantle: Actually it’s interesting listening to Ron, because what we were aiming to do was exactly what Ron says, which is not focus on what various players call their ESB technology, but instead on the requirements that someone needs for their SOA. Those are exactly the things that Ron talked about: managing your interactions, being able to turn on and off security and reliable messaging, being able to manage the quality of service that the message has as it flows across the network, being able to bridge between some mismatches, and managing connectivity.

For example, maybe I have a lightweight AJAX interface, but I already have a SOAP backend. How can I switch between that REST-like XML or HTTP interface and the SOAP interface? How can I switch between an existing JMS network and a .NET Windows Communication Foundation, SOAP reliable messaging, secure endpoint?

Then, finally, there's some level of transformation that often needs to go on the network, and that’s typically what we would call low-level transformation -- things like version management, switching namespaces on XML messages, or switching some XML formats.

Those are the kind of things that we saw a real need for. We took a kind of a different vision of what an ESB was from many of the vendors. A lot of the other vendors in the marketplace had some existing technology. They either had a JMS engine, and they said, "Okay, we’re going to rebrand our JMS engine as an ESB." They had a traditional message-oriented middleware product. Or in the case of JBI, they say well, "We’ve got a JVM. So, what’s the bus? It’s a JVM."

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.

Gardner: What would the message be to developers? You’ve created a developer portal associated with your website for your company. As developers are scratching their heads and trying to determine what they want to do with SOA and how they want to produce services, what is it about your ESB that might be of interest to developers vis-à-vis some of the alternatives?

Fremantle: The first thing that’s of interest about our ESB to developers is that it’s very, very quick to get going. It’s the sort of thing that I think developers like. There is a 30MB download. You download it, you unzip it onto your hard drive, and you switch into the bin directory and start it up. You point your Web browser at it and you can start configuring and managing it straightaway.

The second thing is that it can add some instant value, even in a very simple scenario. Some things you can do very quickly. For example, you can interpose it as an HTTP proxy, so you don’t even have to recode any of your clients to start using it.

You can turn tracing on and off selectively. For example, perhaps you have a production environment and 99 percent of the time everything is working fine. But every once in a while you get an error and you need to help figure out what that problem is. You can have the system running, switch on trace, capture traces of the failure case, and then switch it off without having to bring anything down or redirect any messages, and so forth. You can instantly get some monitoring and management capabilities, without having to do much coding.

Finally, you can start to use it to do some of the things that are quite tricky. For example, one of the common cases that customers ask us for comes when they have an old Axis 1.x runtime, or a .NET 2.0 runtime. This runtime doesn’t support the latest WS-ReliableMessaging or WS-Security standards, and they need to enable that to talk to a partner. One of the things you can do very simply with the ESB is switch on those capabilities. So some of those capabilities that have a reputation for being complex are now just checkbox items with the ESB. Those are some things that I think would appeal to developers about this product.

Gardner: Do you expect that the arrival of this code under the Apache license, you’re calling it ESB 1.0, is going to be used by the developers primarily as a test-and-design environment, a learning experience that will then lead to operational use, or do you see this as an operational alternative as well, right from the get-go?

Fremantle: We really see this as an operational environment. Although this is a 1.0 product for us, the core runtime of this has been in development in Apache for about 18 months. We’ve done extensive performance tests on this engine. We're really, really pleased with the performance results.

For example, one of the things we’ve done is load it up with thousands of concurrent connections to simulate the scenario where you have a sudden spike and load that your backend can’t take care of. It doesn’t drop connections, even when you load it with thousands of concurrent TCP connections.

Similarly, we’ve done performance tests of how much overhead this adds to the path. For a standard 1K in, 1K out request-response message, you can add the ESB into that with an extra network hop now, and we add less than a third of a millisecond overhead.

We’ve done tests against one of the market-leader ESB products out there, and we’re twice as fast at doing XSLT processing. So we’ve really done a lot of heavy-duty testing on this. We think it’s up and ready for production use, despite the fact it’s just a 1.0 release.

Gardner: Ron, I suppose these days we’re seeing a lot more multiple ESBs in enterprise and hosting environments. Do you think we’re getting overcrowded now that we have another ESB? There are many other open-source ESBs: IONA/LogicBlaze CXF, MuleSource, and also Apache ServiceMix, and Apache ActiveMQ. For folks out there who are in this operational production environment, how do they start making sense of this?

Schmelzer: Well, I would say "vive la difference." It’s completely unreasonable to expect that an enterprise is ever going to be able to standardize on one technology stack for anything. We wouldn’t need SOA at all, if companies were truly homogenous. The reason why SOA has such appeal is because there’s this continued heterogeneity. Look at all the legacy mainframe technologies that exist. Part of the reason they exist is because they continue to provide value.

The fact that there are so many new technologies in the market, open source and commercial, providing value for runtime for SOA, goes to show that companies are still looking for best of breed. No two companies really have a similar environment, either a runtime execution environment or a distributed environment. Some companies are highly centralized and some companies have divisions distributed all over the world, and in parts of the world where bandwidth and processing power are still factors and budget is a factor.

In those environments we’re going to continue to see heterogeneity. A central organization might be able to invest in one kind of SOA infrastructure technology, but their branches, divisions, and departments may invest in something else. It's the power of SOA to abstract those differences so that they’re not so visible.

If there’s one thing that we can hope for from SOA it's that it really and truly enables that loose coupling, because if we’re going to continuously try to fight this battle of heterogeneity being a problem for IT, I don’t think we’ve really gotten anywhere with SOA.

Gardner: What now of loosely coupling, but across multiple ESBs? Is that going to require some way of federating among those ESBs or would it be an uber-ESB on top of them that you will use? What sort of scenarios do you expect?

Schmelzer: That’s a touchy subject. I believe the middleware-for-middleware approach is fundamentally the wrong approach. We’re seeing some companies saying, "Hey, put our ESB on top of your ESB," or "Let’s get some sort of magic integration middleware that basically integrates ESBs." That’s the old school, tightly coupled approach of managing heterogeneity.

I thought that the promise of Web services and SOA was that we could expose loosely coupled service interfaces, so that the infrastructure that runs those services doesn’t matter. The idea that you would need proprietary integration middleware to integrate other integration middleware is, in an SOA concept, a ludicrous thought. We should be able to architect our services so that the infrastructure matters less than it used to.

That being said, we do need infrastructure to run those services. Everything that WSO2 is doing is facilitating the running, execution, and, of course, management of intra-service communication, where you’re trying to manage some of that heterogeneity. A lot of stuff they were talking about in mediating protocols, and all that, is specifically to isolate services from having to worry about the runtime environment. Trying to overlay a heavy proprietary integration middleware stack on top of what is primarily another integration middleware stack is fueling the problem more than providing a solution.

Fremantle: Can I add something to that?

Gardner: Certainly.

Fremantle: I have to agree with Ron. 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 Website 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.

This comes back to what I was saying earlier. To us, your ESB is the totality of all your different networking and service-oriented systems, whether they’re .NET, Axis 2, WSO2 application servers, or ESB nodes. 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.

Gardner: Both you and Ron have mentioned that word "management," and we discussed earlier how you have a lot of ambition in terms of the scope of your development activities. Yet you’re also very interested in partnering, as I understand it, and that would include areas for management, and registry/repository. Can you give us a little bit of your philosophy about how this fabric would work, using both your approach as a fairly robust and complete stack, and also partnering with other componentry?

Fremantle: Absolutely. First, we have built internal registry and repository into the ESB, but it’s our first step in this and what we’ve built in is a pluggable interface that allows us to talk to other registries and repositories out in the network. Because we work off a lot of those standard metadata types, such as Web service policy documents, Web service description language documents, HTTPs, URLs and so forth, we can really work in a very open manner.

At the moment, the kind of interface we use to talk to our remote registry is just an HTTP interface, but there is no reason why, if we get the demand, we wouldn’t write to an UDDI interface. It's just that none of our customers have asked us for that today.

We also see the Web service management and governance space as becoming very important here. At the moment, in the Web service management space there's a bit of a problem, which is that there are two competing standards. There's been some work to merge them, but that hasn’t been completed yet.

So, what we offer in our ESB is some simple, so-called REST-based interfaces to get at management information that customers can utilize in the same SOA manner that they utilized in the other services to help manage and monitor their service interactions.

As the Web services management standards start to tighten up a bit, we certainly expect to partner with other companies who provide WS-Management consoles to allow people to manage their network through our interfaces.

We also offer a very lightweight AJAX-based GUI that comes with the product, and which allows you to monitor, manage, and control your service interactions across the network.

Because all of our code is built on these open standards and open interfaces, once again this a heterogeneous story. This is the beauty of open sources. Although as a company, WSO2 is trying to provide to our customers the most useful components that we see, those components naturally and inherently interoperate with other vendors' software, other open-source projects, and other components.

Gardner: Given this flexible use-it-in-many-ways and enter-the-market-in-many-ways approach, I wonder if we could look a little higher up from a business abstraction point of view. What will systems integrators look to as they pick best of breed, and as they pick a stack, and as they factor how to manage what’s on-site in the organizations they’re working with?

I suspect that you want to be a very good partner to these integrators, as they inject SOA activities into the way that they produce code, services, and applications -- and then also take that into the enterprises that they’re working with.

How do you see this whole systems integrator movement toward SOA shaking out, and how do you make yourselves appealing to them?

Schmelzer: SOA offers an interesting opportunity for systems integrators. They formed a large part of their business, at least in the late 1990s and early part of this decade, doing a lot of the heavy lifting of integration, actually making systems work together, facilitating the systems, implementing enterprise applications, and things like that. SOA gives these folks more of an opportunity to focus on the business than they had before and provide a higher margin of services around business process.

[SOA] allows these system integrators to focus on things like building shared services and business services that reflect the business needs, and focus on governance, policy, and enterprise architecture, which is a missing skill set for most enterprises.

Actually this gives systems integrators a good opportunity to let the opportunity of focusing on the business exceed the opportunity of focusing just on implementation and infrastructure, which is migrating overseas anyway. So there are some unique opportunities here for systems integrators with regard to SOA.

Gardner: How about that, Paul? Throwing more warm bodies at the problem probably wasn’t a good idea to begin with. Now you can’t even get the warm bodies in many cases. The goal should be to work smart not hard, I suppose. How do you take that message to the integrators?

Fremantle: We’ve had a lot of interest from system integrators. We formed some partnerships with some of them, and we’re ongoing with that process. What we found attractive to system integrators is that they now are looking much more for simple, lightweight components that work straight out of the box -- rather than large complex solutions.

Part of that is exactly what Ron’s talking about. These guys haven’t got huge amounts of time, so they need something that they can get on with and be productive with instantly. That’s the first thing.

The second thing that system integrators look for is extensibility and flexibility. One of the things system integrators want to do is to add value over the core products or components that they find. We’ve been very careful with the ESB and also in the Apache projects that we work on to create the right plug points.

It’s very simple to extend our ESB just using simple scripting language. For example, you can use JavaScript, Groovy, and Ruby -- those sorts of languages. If you use Ruby or JavaScript, there are native XML language constructs that are called REXML and E4X that you can use inside your code to do really simple, high-quality XML transformations or manipulations. That’s the first level of integration.

The second level is to jump into Java and actually write Java classes. That can be very productive and a way that you can extend the ESB with custom functions.

Then there's actually a third level of that. You can write your own plug-in to our XML configuration language. So you can effectively take your component and raise it up to be a first-class part of the ESB and its configuration model. That means now there can be a third-party set of add-ons to the ESB that start to add value.

We see those two things as being very attractive to the system integrators. First, ease of use -- get it started quickly -- and second gain the ability to extend it, to add extra value, and to build up a catalog of reusable components that makes their jobs easier.

Gardner: I would think that those same attributes would be of interest to companies that want to position themselves within an ecology or some sort of a supply chain, where they’re creating services that will be consumed among partners. Therefore, those same attributes that would be of interest to a systems integrator would be appealing to those enterprises that are seeking a role other than just creating their own applications and services, but rather to become a center of gravity for a larger business process or ecology.

Fremantle: Absolutely.

Gardner: We’re about out of time. This has been a very interesting discussion. We’ve been talking about the advent of new open-source products and code being orchestrated by WSO2. We’ve been talking with Paul Fremantle, the vice president of technology at WSO2. Thank you for your time, Paul. It was very engaging.

Fremantle: Thank you, Dana. It has been a great conversation and it has been a pleasure talking to you.

Gardner: We’ve also been joined by Ron Schmelzer, a senior analyst at ZapThink. We appreciate your insights, Ron.

Schmelzer: Glad to be here. Thank you for having me.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect podcast on WSO2, open source, SOA, and the arrival of the WSO2 ESB 1.0 product in June 2007. Thanks for joining us.

Listen to the podcast here. Sponsor: WSO2.

Transcript of Dana Gardner’s BriefingsDirect podcast on open source Web services stacks and WSO2's latest ESB. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.