Paul Fremantle is a co-founder and VP of Technology at Open Source Web services startup WSO2. He co-chairs the OASIS Technical Committee standardizing Web Services Reliable Messaging, and is a committer and release manager on the Apache Synapse project. Before co-founding WSO2, Paul was an SOA and Web Services leader in IBM's WebSphere division. Paul is a member of the Apache Software Foundation. OT (Oxygen Tank): Paul, you are the co-chair of the OASIS WS-RX Technical Committee. What is that?Paul: WS-RX is a technical committee set up to standardize the Web Services Reliable Messaging (WSRM) specification. In particular, the aim of the committee is to pull together all the companies in this space to create a single standard for adding reliability to existing SOAP messaging.OT: Do you think this is important?Paul: Well, there are lots of technologies out there that offer reliable messaging, ranging from IBM MQSeries to the ebXML Messaging Service standard. But there isn't a single interoperable standard that has been accepted by most software vendors. WSRM has the opportunity to democratize the reliable messaging market and open it up. So, yes, I think this is a very important initiative.OT: Where do you see WSRM being used?Paul: The most obvious candidate is business-to-business interactions. There are several initiatives, such as the French Government PRESTO project and the Danish Government OIOSOI project that are using WSRM to add reliability between different organizations. But I also think that there is a huge opportunity *within* organizations to add reliable messaging or replace existing expensive proprietary solutions. For example, the new communications stack inside Windows Vista, known as Windows Communications Foundation (WCF), fully supports WSRM 1.0 out of the box.OT: How does WSRM work?Paul: It's very simple. At each end of the conversation you add a WSRM agent. Usually these plug into your existing Web Services framework. These agents agree on a reliability contract (known as a Sequence between them). Once this is done, the sender adds a unique message number to each business message. The receiver sends back acknowledgements, and if messages are lost, then they will be resent. Of course, there is more to it than that, but that is the basic idea. If you want to know more you can read my introduction.OT: How does WSRM compare to existing reliable messaging systems such as JMS?Paul: The Java Messaging Service API (JMS) is widely adopted, but this doesn't offer an interoperable wire protocol. So you can't talk from one vendor's JMS implementation to another without some kind of bridging in the middle. The other key difference is that WSRM doesn't require you to change your programming model. Because SOAP is already a message based model, you can add reliability in without having to think about concepts such as queues and topics. The result is that WSRM can be very easy to implement if you already have a SOAP or XML based architecture.OT: What implementations are there of WSRM?Paul: Well there are a number of vendor implementations, but the implementation I'm most familiar with is Apache Sandesha2. This is a pure open source codebase that implements the WSRM 1.0 specification as well as the latest drafts of the 1.1 specification. Sandesha2 is used in a number of implementations, including Apache Axis2, IBM's latest Web Services fixpack, and WSO2's Web Services Application Server. We also use Sandesha2 in the Apache Synapse project. It does some really neat things, for example, allowing you to bridge between existing JMS systems and WSRM clients and services.OT: Tell me more about the WSO2 Web Services Application Server, and how it supports WSRM.Paul: WSAS is a very fast, lightweight Web Services server. It can run standalone, or be embedded into your existing J2EE servlet engine. WSAS makes it really simple to add reliability to a service. Just pull down a dropdown box and select Sandesha from the list, and your service will now support WSRM. By default, WSAS includes a lightweight database - Apache Derby - and we use this to store your messages persistently. Our architecture lets you replace this with an existing enterprise database such as Oracle or MySQL without any coding. And we have done extensive interoperability tests with Microsoft, IBM and others in order to guarantee that we work with other vendors.OT: Finally, what is the future of WSRM?Paul: The specification has gone through its first public review. We are dealing with the issues from that right now, and we aim to close the remaining issues in the near future. Once OASIS votes it through as a final standard, then I think the upsurge in interest and usage is going to be impressive.OT: Thanks very much!Paul: You're most welcome.