BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths

Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths

Bookmarks

InfoQ's Stefan Tilkov had a chance to talk to Sanjiva Weerawarana, who founded WSO2 after having spent nearly 8 years in IBM Research, where he was one of the founders of the Web services platform. During that time, he co-authored many Web services specifications including WSDL, BPEL4WS, WS-Addressing, WS-RF and WS-Eventing. He lead the creation of IBM SOAP4J, which was released just 2 days after the SOAP 1.1 specification was released and which later became Apache SOAP. He went on to architect and implement many other products, including Apache Axis, Apache WSIF, the IBM Web Services Gateway and IBM BPWS4J, a BPEL4WS implementation, and was a key driver of IBMs Web services technical strategy.

Sanjiva has been involved with Open Source software both in IBM and in Apache for several years. In addition to the Apache Web services projects, Sanjiva is the father of Apache Jakarta BSF and also contributed to Apache Xalan. He is also a co-editor of the WSDL 2.0 specification.

As one of the fathers and a firm advocate of the WS-* architectural vision, we questioned him on the WS-* platform and his views on Microsoft's role in standardization. Sanjiva also took the opportunity to address "WS-* and REST myths".

InfoQ: Sanjiva, as you have been involved in Web services standardization for so long, what's your take on the current status of the WS-* specs?

Sanjiva Weerawarana (SW): While it took a lot longer than we all thought at the beginning, I think the core of the WS-* platform is finally stable and solid. We still have a few lingering standardization steps to be completed but the set of working specs is stable and interoperable enough for production deployment.

The biggest problem I see with the WS-* specs is the lack of a single spec that lays out the key components of the platform architecture. This results in people saying "geez there are 100+ WS- * specs; how can I possibly know what's important and what's not?!". The shipping of Microsoft's WS-* platform, WCF, in Indigo will help address this somewhat as that platform has a very small and clear set of specs but it'll take time to kill off all the political plays by various companies to create competing standards.

InfoQ: It seems to me that while it may be a slight simplification, Microsoft decides what the architecture looks like, and everybody else just has to follow. If it's not in WCF, it's not going to become widely accepted. Do you agree?

SW: I was one of a small group of people in IBM who, along with the team from MSFT, defined the platform that went into WCF. The core WS-* platform is indeed what's in WCF. Microsoft is the only company, other than WSO2, that has implemented the entire platform. IBM and others don't have it easy as we do because they have a lot of legacy (JEE) to carry along. (If you read this blog entry I wrote a few days ago you'll see why that path is doomed.)

So yes, WCF will provide essentially a reference implementation on the Windows platform. We provide one for Java, C and scripting languages.

InfoQ: What's your take on REST?

SW: First of all, REST has clearly given a great architectural foundation for the Web. However, one mustn't forget one key thing: The Web is necessarily human centric- only one side of the Web interactions is on auto-pilot .. the other side has a human user driving the software, which allows incredible sloppiness and flexibility.

So the question comes whether REST provides a better foundation for application to application interaction than what WS-* does.

People have of course used the Web for application to application integration for many years. But is that really REST or just using the infrastructure of the Web? Its of course the latter: The reality is that its mostly people shipping XML documents back and forth over HTTP or, in less complex cases, using HTTP GET to send data and get responses back. That's just not REST as there's no well-designed resource structure.

It is also true that people have built true REST style application to application integration systems for various specific problems. However, the reality on the street today is there there simply is no standard approach for using REST for these problems.

So I fully understand and appreciate that REST is a wonderful architectural paradigm for building scalable systems. Is it the only one? I don't think so. Is it enough to solve all application to application integration needs? I certainly don't think so either; if so we wouldn't be talking about it.

InfoQ: While it's true that there are lots of non-RESTful usages of the Web out there, I don't see how that reduces its value. Would you agree that a RESTful Web application, whether application-to- application or application-to-browser, is better than a non-RESTful one?

SW: No way; I'd never give it a carte blanche +1 like that! Better in what sense? Are you asking me to agree that having a fixed interface and moving all the interaction semantic understanding to media types is better for all scenarios? No, I don't agree. There are definitely cases where that's awesome (such as the Web), but there are other cases where that isn't so hot.

There's not only one way to build a distributed system. RESTful is one way, SOA is another as are distributed objects and RPC. Anyone who thinks that RESTful is the one true way is simply naiive (or fanatically RESTafarian!).

InfoQ: I don't believe REST is the only true way to build distributed applications, and I don't know a "RESTafarian" who does. I do believe the best way to use the Web (and HTTP) is to follow its architecture. And I explicitly asked about Web applications, not distributed applications...

I assume you'd agree that Internet Banking is a very popular Web application right? Are those RESTful? Of course not! They use cookies, the don't have a resource structure underneath and so on- all they're doing is using HTTP, HTML and CSS (and sometimes XML) effectively. What about Google maps- is that RESTful? Can you give me the URIs to each and every map block at different resolutions? What about POX- which people have been doing for years- not RESTful for the most part.

The reality is that many of the really successful Web applications aren't RESTful. Is that bad? I don't think so- they just do a great job of using what TimBL and others invented to do cool things. Does it matter that they don't follow the REST rules? Only to RESTafarians; those applications work, scale and the users love 'em - who's to say they're wrong?!

So, no, I don't carte blanche agree that RESTful applications are fundamentally better.

InfoQ: Which areas do you believe are better addressed by Web services?

SW: Web services address two key aspects: one is providing a set of standards for interacting in a manner that supports business requirements. That is, if you were ordering an engine for an airplane, would Pratt & Whitney accept an order from Boeing just over an HTTPS connection with HTTP Basic authentication? I doubt it. In those cases, you want the message to be signed by an authorized person and properly encrypted to ensure that it hasn't been tampered with. Furthermore, you absolutely want the message delivered once and exactly once- Boeing doesn't have space to have engines lying around. I could go on- but that's the problem that Web services addresses- giving a set of standard, interoperable protocols for one application to talk to another application while assuring business level qualities of service of security, reliability and others.

So, what WS-* is doing basically is taking the POX style of interaction people have been doing for years and adding some conventions for how to achieve certain business requirements in a standard way.

In theory REST can be used to realize all of these, but the reality is that those capabilities are not existing standards, which means you need to build those on a case-by-case basis, which was the situation for POX too until WS-*.

InfoQ: The WS-* specs try to build this into the platform, while the REST folks are mostly happy to do it on the application level?

SW: Right - they are because they don't try to, say, achieve message level security in an interoperable manner. Can I sign a message the same way using REST no matter which application I'm using? No, because there's no standard for that; you have to ask the other side how they'd like the signature.

REST folks say you don't need WSDL because the world is self describing. Huh? In REST, the data is "self describing" if the recipient understands the content type I send it as. But there's no content type for every piece of data; thus both parties need to agree on the types to use! Again, in the browser world this stuff is relatively easy because you have an intelligent operator on one end. In the integration world, there must be declaration and agreement on what you'll send me otherwise we just aren't going to be talking.

The REST folks should look at the HTTP binding of WSDL 2.0 — that really does give a very clean way to describe RESTful (and non-RESTful!) HTTP services. WADL gets many of its ideas from WSDL 2.0 and, other than for NIH, I can't think of many reasons why they wouldn't use and improve WSDL 2.0.

The second aspect, of course, is that Web services can be realized not only over HTTP but over other transports. Oops, I committed heresy there by saying "transport" next to HTTP! But really, WS-* works over SMTP, XMPP, JMS and all kinds of other protocols. Yes REST too can be realized over other protocols, but HTTP is the only transfer protocol that's designed to work correctly RESTfully.

InfoQ: You obviously are very much aware that HTTP is an application protocol, or transfer protocol, not a transport protocol. Many of its features are not used when a SOAP/WS-* layer is put on top of it - like caching, standardized identifiers, idempotent and safe methods. Do you agree that if I only need to support HTTP, I lose something when I use WS-*?

SW: Yes, to some extent. I absolutely accept there are key features of HTTP as a transfer protocol that are very valuable. The current crop of WS-* middleware haven't done a superb job of figuring out how to maximize using those. Again, if you look at WSDL 2.0 you'll see that we've sorted out the idempotent & safety aspects. Caching can still be supported properly too. Let me leave the identifiers topic to later since you ask specifically about WS-Addressing.

As the person who did the first ever SOAP implementation (Apache SOAP) I take full responsibility for taking several wrong decisions on how WS-* should be implemented. (If you watch the talk I gave at Google you'll see more about that.) Most of the first generation of WS-* stacks followed Apache SOAP. Then Apache Axis came along and defined a bunch of new stuff (handlers etc.) and everyone (including JAX-RPC & MSFT) followed along. Now Apache Axis2 is defining a whole new set of stuff (policy driven architecture, modules, separating context etc.) and again we're being copied by others. So what you're seeing is that people are evolving their thinking on how WS-* fits with the Web. Do we have the fit right yet? I doubt it. But we're working on improving it.

A lot of the criticism of WS-* comes from people who continue to look at SOAP as a distributed object communication mechanism. SOAP 1.1 certainly had those traits (with SOAP-RPC and SOAP Encoding) but SOAP 1.2 has lost those totally and same for WSDL- 1.1 had RPCness built in but with 2.0 its not in the least.

Same goes for WS-* implementations- people look at the old style WS-* implementations and say "argh its just RPC over XML". Take a look at WSO2 WSAS (powered by Apache Axis2) or Microsoft's WCF and see- those don't live and breathe RPC at all. In fact in Axis2 and WSAS, there's no concept of RPC built in at all. I went into more detail on this aspect in my talk at Google.

InfoQ: Do you think the REST vs. WS-* views can be consolidated?

SW: The real question is whether resource oriented architectures and service oriented architecture are one and the same. I assert that they're not: given a distributed systems problem one can develop solutions using either approach and the artifacts that result would be radically different. True REST applications are resource oriented. WS-* is used to implement service oriented architectures. So its not that one's wrong and the other is right, but rather that they're different. The great marketing coup that REST folks are trying to pull off is that WS-* is complex and REST is simple. That's just nonsense- if you really try to build the type of systems that people build with WS-* using REST, then you'd end up just as complex.

At the same time, many scenarios do not need all of WS-* for their interactions. That's where the intersection lies- new stacks like WSO2 WSAS and Apache Axis2, which are essentially driven by WSDL 2.0, offer full support for POX style services and also for HTTP GET. The resulting systems would not necessarily be RESTful but they have the same simplicity advantages that REST offers. And the best part is, the way we've designed the programming model and the infrastructure, one can write a service once and offer a POX binding, a GET binding, a SOAP/WS-* binding and even a JSON binding without writing a line of code.

To me that's the way to go forward- take the best of both worlds and mash them together rather than getting caught up in either religion!

InfoQ: I would claim that the WS-* architecture still has to achieve the features of REST/HTTP. For example, WS-Addressing seems like a very bad re-invention of URLs to me - one that still has to gain any sort of acceptance.

SW: So let's go back to see why we had to create WS-Addressing. We created Endpoint References because when you're having a business interaction with a service, the state of that interaction is more than just the URI- there's business context that might need to be propagated, such as what authentication protocol you must use to talk to the service. I may need to send a Kerberos ticket or a SAML token or use Cardspace authentication for example. In other words I need to be able to give you the URI plus some policy info telling you that extra stuff.

Now of course one can encode any information in a URI; after all its in theory an infinitely long Turing tape. However, URIs are supposed to be opaque to the client- so you can't put anything in there that the client needs to know. That means the policy info can't go in there.

Reference properties could certainly have been encoded in the URI directly. We debated that a lot but decided not to because in business contexts the reference properties (essentially cookies) can be large and have structure. Again, while its possible in theory to encode anything into a URI, having big, long, ugly URIs is not a thing people like or find particularly RESTful or even useful.

Even for the Web, are URIs enough? No of course not- what about cookies? Today, using URIs can I forward the state of an interaction I'm having with my bank account to someone else? No because some interaction state is maintained in cookies which are not part of URIs. Yes, one can indeed use URI rewriting instead of cookies but that doesn't allow the client to remember any state.

So if the information about an endpoint that I need to send you consists of some data you need to understand and some that you need to send me back so I know what you're talking about, then there's no way to avoid creating something beyond URIs.

However, wherever possible, I'm all for using URIs only. That is, if there's no metadata that needs to be sent and if any state can be kept as part of the URI itself, why not? That's then just a simple endpoint reference and it has the good property of playing well with the Web.

Getting back to the possibility of consolidation: There is a common point however, and that is what people have been doing for many years in the Web: moving XML around using HTTP. That's not RESTful at all but it uses the capabilities of the Web properly. That's definitely a good thing and if someone doesn't need all the extra security and reliability etc. offered by WS-* then such simple POX (plain-old-xml) interactions will suffice! So the thing app developers should be looking for in software is good clean support for both styles of architectures.

InfoQ: I see how one could support both WSDL/SOAP/WS-* and POX/HTTP at the same time, since they both are similarly un-RESTful. But it wouldn't really be both styles of architectures?

SW: The first question is, what is the middleware needed to implement RESTful systems? Is it nothing? I mean are servlets/php scripts/asp etc. all that's needed? Or does REST need to grow to REST-* to make a more complete platform with some common conventions/standards/protocols defined for things like message level security?

I don't claim to know the answers to these questions. What I can tell you is that we're trying to figure this out too. I agree its easy to do WS-* and POX at once and it's a lot harder to figure out whether there's one bit of middleware that's right for SOA and ROA styles. That's what makes it fun to work on this stuff!

InfoQ: Thanks a lot for your time!

Rate this Article

Adoption
Style

BT