This is Stefan Tilkov at QCon, talking to Paul Freemantle. Can you tell us a little bit about yourself?

I am VP of technical sales at WSO2 which is an open source company, working in the SOA, messaging and web services area. Our vision is basically to build a new kind of open source middleware that's really fundamentally based on lightweight XML messaging and layering on different open standards as needed. I also chair the Web Services Reliable Exchange technical committee at OASIS which is a committee standardizing reliable messaging for web services, and previously I worked at IBM where I was a senior technical staff member. I had a varied career, I used to be a management consultant and I am slowly getting more and more technical over time, rather the opposite which a lot of people do, which is getting less and less technical. And finally I am a committer and release manager on an Apache project called Apache Synapse.

What is your take on web services, there is this so called WS-death star joke that's going around, how do you see the web services standards and specifications?

I think it is interesting that one of the problems is that technical people get bored, and they get bored just usually at the point when something is old enough and boring enough to actually be useful. And I think that may be what is happening with WS-*, it is actually getting to a point where people are using a set of standards together that actually provide a base line of useful features. What I think people are interested in are obviously SOAP as a core messaging protocol, Reliable Messaging to make sure messages get there, Security to make sure they are secure, and this thing called MTOM which is basically how you transmit binary data and still maintain efficiency, security and so forth and fit that into the SOAP messaging format. And Windows Communication Foundation (WCF, Indigo) is shipping now with these things in it.

For example the Apache Axis2 project has these, the Sun JAX-RI has these, and this has become a standard set that I think a number of people are quite interested in. For example I am working on a French government initiative called Presto where they are mandating all government departments communicate with this set of standards. We are doing a very broad-ranging project in Denmark, where basically the Danish government is specifying that small business are going to use this set of standards plus a set of standard XML schemas to do things like purchase orders and invoices securely and reliably. I think these standards are getting to the point now where they work - OK, they look a little bit ugly and heavy to some people, but fundamentally, boring can be good. And in this case I think boring is good, and that the other thing we are seeing is that people are coaelescing and there's a fantastic innoQ chart with a hundred million web services standards on it, but very few of those hundreds are going to be used extensively and I think the ones I just mentioned are probably going to become the core set of web services standards.

From your point of view the standards that would be usable today would be SOAP and WSDL, WS-Reliable Messaging, WS-Security, and MTOM?

I think there are things like Secure Conversation which I see as just an extension to Security and not really a separate standard. It is a separate standard on paper specs but the way people will use it is just as a more efficient version of WS-Security. I think there are two other pieces that are very interesting: one is WS-Trust, which is the foundation of a Microsoft initiative called CardSpace and I see a huge amount of activity around that. And this isn't really in the standard web services space, it is not being used for machine to machine interactions, it is being used to enhance the security of websites, of people's personal access to websites.

It is enabling a model like Microsoft Passport that isn't controlled by a single vendor, by a single user identity store. And I think that is very interesting and that has the potential to break web services out of this very much business-led integration space into a much wider space. And I think the other key tool that makes all this work is WS-Policy which is fundamentally an extension to WSDL to capture this higher level standards and their requirements for those. I also have an interest in WS-Eventing and WS-Management. So there are other things where you see people start using web services at a higher level. For instance WS-Management is one of those, it's not really a WS-* standard, it's just a management standard that happens to be spelled in SOAP and that really is the level we should be getting to, which is where SOAP becomes boring and people start to use it.

There is that saying "if all you've got is a hammer everything looks like a nail". SOAP is bought into people by who think "I've got this hammer, it's SOAP, I am going to use it". And there are advantages and disadvantages to that. Maybe it isn't always exactly the perfect spec and the perfect model for doing everything, but that uniformity can bring a huge capability, which is the same thing we have seen with the Java virtual machine, and the .Net virtual machine. Once you have got a uniform layer the possibilities to build out that layer become very large and that's what people are aiming to do with SOAP.

How do you view Microsoft's role in the WS-* standardization process? Have they become too influential, is it a good thing that things seem to be led so much by Microsoft?

That's a difficult question to ask me because I chair a standards group, in which Microsoft are very influential and they have done good work in that. Microsoft has an advantage and a disadvantage and that is they are very focused on shipping as part of their operating system, as part of Vista with this Communication Foundation. Being so tightly embedded into everything, they have very firm product ship times and deadlines for that. And that tends to influence their position which is that right now they want to close everything down, they want to tighten the nuts, make sure everything is stable, pretty much how it is now.

And that is a big advantage because it is pressure on other vendors who might be a little more loosy goosy to get on with it and settle this and get things sorted and standardized and fixed, which is of advantage to the community. Of course it's also a disadvantage if you think things aren't quite right today and need a little bit of fixing because there's a lot of inertia to get over with. I am involved in some projects with Microsoft where fundamentally Apache Axis2 is doing all the hard work to interoperate with WCF because WCF is shipped, so if there are minor bugs in it we've got to work around them because we are an open source project and we ship every three months, we are very flexible and easy and open and so we tend to take out the slack, that's a good thing for our customers but seems a little painful at times.

You mentioned that you chair the OASIS WSRX committee (and you have written an excellent article for InfoQ which I can only point readers to). Can you elaborate a little bit on the current status there and what to use it for?

Certainly. The WS RM standard, it's a little confusing, my TC is called WSRX but the standard is called WS RM. Fundamentally a very simple approach protocol that enables you to deliver SOAP messages exactly once, and in order. Obviously it has some other capabilities but that's the primary use people want. It adds a JMS-like capability to SOAP, which allows you to basically enable reliable messaging, retries, resends and dropping duplicates, all the kind of things that you would expect from a product like MQSeries, in a completely standard open format.

And what is really interesting about RM is not that it's a hard thing to do, to reliably deliver messages is actually pretty simple. What is interesting about RM is that it is the only standard that has the backing of every single vendor in this space, ranging from Sun to Microsoft, to IBM, to TIBCO, to BEA, Sonic, Progress. I think that is very interesting because it opens up the possibility that there might really be an open, widely adopted standard for doing reliable messaging, which is something that the world hasn't really had today, there's JMS but that's just an API, underneath it all those wire protocols are completely different.

What do you think about AMQP? Have you looked at that?

I have looked at AMQP and I think it is an interesting approach, the comparison between AMQP and RM is very interesting because AMQP defines a lot of different semantic entities, it defines exchanges and queues and all sorts of stuff around messaging, it defines a whole messaging world and its own transport and protocol. RM is infinitely more lightweight, it really just defines two roles that the sender and the receiver play in acknowledging and adding message headers to messages. I think AMQP would appeal much more to someone who is used to a MQSeries model, used to a traditional messaging model that defined everything from soup to nuts.

RM is much more interesting where you are layering it on to an existing communication protocol, because it fits in much more smoothly. In England we have this concept of recorded delivery for post. In recorded delivery you take your existing letter that you are about to pop into the post box, and instead you are going into the post office, pay a little bit extra but now the same process is now reliable. It's completely composable with your existing model. The AMQP model is more like you get a courier service in, and now you have to set up an account, they have different bags and different envelopes; they have different procedures and processes, so it's not composable with the existing post office model. But FedEx is very successful so I am not knocking it, I'm just saying it's a different approach. The other thing I would like to tell you about is that with our fingers crossed we are going to submit the RM standard to the OASIS body to become standardized on Thursday, in 2 days from now. By the time you see this I am hoping it will be going through the OASIS process and people will be voting on it and so forth. I am keen to get it standardized.

Is it going to become part of WCF if that's already shipping?

I know that Microsoft have plans to move to RM 1.1 at some point, I can't comment on that. From the Apache perspective certainly we will be supporting both RM 1.0 the existing version and the standardized version in our stack which is called Apache Sandesha, and in fact we already have early support for it today. You can try out some features of RM 1.1 based on the latest draft today, and as soon as it becomes standard we expect to have a fully certified and interoperable implementation of 1.1.

One last question about the reliability issues if you don't mind. What ever happened to WS-Reliability, the other OASIS reliable messaging standard?

For those of you who don't know this was a group of companies including SUN, Hitachi, NEC, Fujitsu, who published a standard very closely based on the ebXML messaging specification. And they got it through to being an OASIS standard. The challenge firstly was that it didn't compose with WS-Addressing. Whether or not you like WS-Addressing the idea of making SOAP asynchronous and really having a well defined set of things like To: headers and ReplyTo: headers is absolutely core, and it is going to be a fundamental part of the next Basic Profile from WS-I. The ability to compose with that is pretty important. The other thing is that there's only one implementation of WS-Reliability.

When you go to being an OASIS standard you have to have 3 companies certify that they have used it. Three companies jointly collaborated to make a single implementation and that's the one they have certified. I have never believed you can really have an interoperable standard with only one implementation. Until you build two different implementations you don't find out where the real bugs are. Maybe that is a little bit mean but I think that's probably another factor in the WS-Reliability. All those companies have joined the WSRX working group and they have collaborated and commented and helped to improve the WSRM specs. My hope as chair of the TC is the WSRM specification is going to be the single widely adopted, widely used specification in this space.

You seam to have a similar situation in the eventing space with WS-Eventing and WS-Notification and WS-Events. And maybe there's another one. What's your take on eventing in general?

This is an interesting issue because what has happened is that the grid community especially the GLOBUS grid community has helped define a set of standards, the WS-ResourceFramework. And if you buy into the ResourceFramework then obviously you can see things like topics and events and notifications fitting in with that. WS-Eventing is a much simpler specification and there was a lot of work to try and unify the base part of notification, Base Notification, with Eventing. Unfortunately for some reasons that I don't know that never quite completed and I think that is a great shame, because I think these multiple standards really harm the market because people don't know where to go and what to look at.

I think there is a really interesting aspect to WS-Eventing which is that it doesn't change the business messages that flow. If you look at the traditional pub/sub system, if you go look at that you have control messages, you have system messages flowing around to say "I want to subscribe, I want to cancel my subscription" and so forth, and then you have data messages. And both of those messages have to follow the same underlying protocol. WS-Eventing doesn't really follow that model because it doesn't really talk about the data messages that flow at all. When you subscribe you just pass effectively a URL, an endpoint reference, to say where these messages go. There's a really interesting aspect to WS-Eventing which is to think of it as a dynamic wiring model for your communications protocols.

I want to get messages from that system over there, I'm going to send a subscription to it. And now it is going to send me messages. In e.g. Axis2, where we support multiple transports and protocols, those messages themselves don't have to be SOAP messages, those messages could be XML HTTP messages, XML JMS messages, anything in fact that we support as a transport. It is only the subscription that is likely to be this SOAP message. And so there is an interesting decoupling that I think changes the way we view pub/sub. And it also changes the way you look at Web services standards because you usually it's the sender of the web service message who decides what's going and receives who gets it. This inverts that because it allows the receivers to say "I want to get that message". And then it is up to the sender to obey that wiring command. It's quite an interesting change around.

As you've brought up this issue of wiring together separate or loosely coupled entities. What's your take on SCA, the Service Component Architecture?

I have not traditionally been a big fan of Service Component Architecture. There is a saying that "there is no problem in computer science you can't solve by adding another level of indirection". And what SCA is trying to do, is add another level of indirection on top of TCP and HTTP and SOAP and WSDL and all those things, whatever happens is on another layer of indirection. I think there is a danger to adding an extra layer of indirection, is that you just completely loose people - they have no idea what's going on. And they don't like that. I believe that programmers like to know that when I write this bit of code this is going to happen.

And they may not need to know all the details of everything but they will like to have a good clear idea of the consequences of writing this configuration statement, or this line of code. And I think the more levels of indirection you add, the harder it is to do that. That's not to damn the whole of SCA. I think the wiring model of SCA, the assembly model, is possibly the most interesting aspect of it and that's possibly the one that will succeed. As a programming model, as a kind of Spring on steroids I don't really like SCA. I think for example Spring and the other light weight containers are much more effective ways of doing that component based development.

As you mentioned the idea of some piece of infrastructure hiding complexity, what's your take on the ESB concept? Does WSO2 sell an ESB, and if you do, why? And if you don't, why not?

Well, we don't sell anything because we are an open source company. We do have an ESB product, but it's not what people think of an ESB, it's a much lighter weight more down to the ground component than you might expect. Once again we believe that transparency and simplicity are really what counts and the idea of an ESB being a large infrastructure component into which you chuck your messages and then you forget about where they go, is perhaps a little bit too much for a lot of developers and especially people who are much more pragmatic. Our ESB is a packaging and a productization of a project called Apache Synapse. And Synapse is a smart router for messages.

Synapse takes messages in over HTTP, SOAP and JMS, or whatever other transports you want to define (we're currently working on file and FTP transports). And it runs mediations on those messages and then it sends them out again. And those mediations are typically things like logging, routing, perhaps enabling or disabling certain things like WS-Security or Reliable Messaging, and also it can run scripts, it can run Ruby, JavaScript and other scripting languages, or it can run XSLT it can do XPath-based routing, so it's a simple mediation engine.

How does that small mediation engine compare to this larger ESB issue, what is its role in the overall infrastructure?

What elevates this router to helping you build your ESB is the fact that it can operate throughout your organization. You can have multiple brokers, multiple nodes, and they can all load their configuration from a single registry so they can act in concert, and they can act in a very policy driven manner, you can apply policies to every service message that is going through your fabric using these brokers. And I think that is an interesting idea that says: "I'm going to clear away the mystique and the hype around ESB and say what it really is.

It is the ability outside of my application logic, to apply infrastructure policies to control, manage, monitor messages as they go through my infrastructure, and that management capability to a very lightweight model. That large scale Synapse ESB deployment is something you could get to, but the really nice thing about Synapse is that you can start out by building very small deployments that do very useful simple things. For example, you can have an XML message come in over JMS and you can resend it out using SOAP over WS RM to a .Net client or system. You can enable WS-Security outside of your existing system. If you have a PocketSOAP or a Perl SOAP or a PHP SOAP system that is working but now you want to add WS-Security to it, you can place Synapse in front of it and have it offload that capability. And it is very simple; no coding required, simple XML configuration language, and it is open source.

Going from that open source model back again to the company can you elaborate a little bit on what WSO2's business model is, how you actually make money when everything you do as open source?

We are very like other open source companies; we make money out of support, maintenance, services, consulting, all the kind of things you would expect around an open source company. I think the way we see our company is not very different from a closed-source source companies. We still believe we are a software company that's making products, that's documenting those products, and selling those products to you. The only difference is that we are not selling the intellectual property rights to the code, what we are selling is our expertise around that product.

When I worked at IBM a lot of our customers bought IBM software because they trusted in IBM support. And it wasn't that the IP was so much different or so much more valuable than BEA's IP or anyone else's. In the world of J2EE it's not the intellectual property that counts, it's the company behind that intellectual property and the whole offering. And WSO2's approach is that we are experts in this field, we have a number of spec leads, we have a number of people who have really built out this platform, and so it's our expertise that really drives the profitability and the success of the company.

One of the ongoing debates here at InfoQ is the debate of REST versus web services or SOAP. Do you have a comment on that?

I think there is a temptation to view REST as a savior. We have dug ourselves into SOAP we made it too complex and we will start again with something simpler and lighter weight. And in many regards there is a lot to be said for using HTTP as the universal transport mechanism and to some extent the HTTP verbs, the PUTs, GETs and POSTs, are useful outside of just one domain. They have some wider applicability. But there is a temptation to think this is the answer, when perhaps we are just too early in the story to understand the difficulties.

And my concerns about REST is that a lot of people don't think in RESTian terms, they don't have this concept of resources and so very few people are actually making their HTTP URLs really follow the underlying resources that they are modeling, and as they get into that, what they find is that even when they do, the four core verbs of HTTP don't cover everything they want and at that point POST is a get-out clause, once you stop having a way of modeling every action, you have to start extending POST to say "I am going to POST this and that means this, and I am going to POST that and it means something different". The uniformity of REST is only there in the most simple cases where you are really just modeling resources. As we get into more complex cases that benefit may break down. There's one other interesting aspect which is the extent to which REST is really tied to HTTP.

In general it is not a good thing to tie your semantics to your transport. We have seen that for example there is a very successful protocol in the financial industry called FIX which is very widely used and very useful, but over time people have cursed the fact that they tied their transport and their protocol so tightly together. I know there are other options doing REST type semantic outside of HTTP but fundamentally the REST model is the HTTP model. And that may also turn out to be something that bites us in the future. Now HTTP is such a successful and widely adopted protocol maybe it isn't a problem. Q: What is your general view on this industry as a whole? Where is it heading? What do you see as the potential things we are going to see within the next few years? 1888 A: Abraham Lincoln said: "you can fool all people some of the time, and some of the people all of the time but you can not fool all the people all the time" and you might think I am talking about SOAP at this point but I am not.

What I am trying to say is you can't have a single system that pleases everyone, and partly because people have different requirements and partly it's just human nature. If you are doing something I want to be different so I am going to do something else. In integration we are constantly striving to come up with a single answer that pleases everyone so we have a universal integration system and I think that is never going to happen and I think that's actually more the driver behind REST versus WS-DeathStar than anything else, which is there's just different people have different approaches and I think the only thing that you can really see happening in the integration issue is a a definite move to HTTP, a definite move to XML and move to generally smaller lighter weight open source components that work together. I think that is the answer. For example to the WS-* question is to see those WS-* standards as composable units that you can use as and when you want. Just in the same way that people pull together applications out of different open source projects. That's my prediction: the confusion will continue to reign but we will slowly get to better components through open source and through lighter weight models.