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

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.

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?!

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!

We need WS-Addressing because we don't want people who design non-working architectures to use an alternative specification. No one would trust HTTPS to do business transactions like banking or business-to-business purchasing, so we need WS-Security. You can't implement services like amazon using REST because the web is a "Resource-Oriented" rather than "Service-Oriented" architecture. We need to exchange WSDL documents before I can "GET" the share price of MSFT from your web service, because otherwise your service might return data in a format I don't understand.

It's the same old bandwagon. Start with the assumption that all interactions must be possible. Design a protocol suite that permits these interactions, then wonder why all of the practical architectures are infeasible with your technology. REST starts with the architectural constraints and ends at a practical, evolvable, scalable wide-participation architecture like that of the web. It's interaction patterns aren't described in WSDL, they are described in rfc2616. There is the GET interaction pattern. There is a PUT, a POST, so on and so-forth. If you want to design new interaction patterns you are free to make your case. It won't take another 100+ specifications to extract all of the useful parts of the WS-* stack and apply them back to the web. I suspect the only valuable piece there is to extract is the equivalent of "POST at most once".

This article, like many recent web services articles (including the recent shenanigans comparing the performance of Axis2 with other stacks) avoids the single most important issue that (in my experience) most development teams care about, and which they base their choice of stack on. Namely, how easy is it to develop, deploy and maintain a web service? In this respect, the original Axis was shockingly bad. Unfortunatly, Axis2 makes no significant improvements in this area. XFire is a huge improvement on both of these, beating the pants off the usual Apache bloat, and I expect the forthcoming Spring WS to do so as well.

This interview was not about ease of development. I can talk at length about the programming model decisions we've made in Axis2 and why I think many (not all!) of those are right. XFire addresses a different set of needs and if you want to see where they're heading you should check out Apache CXF, which is what Dan considers XFire 2.0.

FWIW I absolutely agree ease of development is critical. We in Axis2 land are not done trying to make development easy or easier.

In any case, let's not divert this conversation into yet another Axis2 vs. XFire food fight; surely we can argue about REST vs. WS-* without needing to bring that in too! :)

+1 for the most part. The only point where I'd differ is that its any architecture or design patern can be implemented with any combination of technologies. Its all a matter of finding the right tool for a particular job- there's no such thing as a single tool that works for all scenarios.

Thus, I'd *never* say that WS-* was the solution to all distributed systems problems; just like I'd never agree REST is the solution to all distributed systems problems. Good engineers and architects must know all of these approaches and mix and match them appropriately to solve the given problems. Fanaticism about any given technology is so stupid.

<quote>I believe Sanjiva's view is the first, yours is the second.</quote>

Just the opposite. Sanjiva puts something like 'you can use SOA *or* REST' in the sentence:

"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!)."

So he states that they're mutually exclusive, what's simply not true. SOA, as your second paragraph says, can be implemented in REST, SOAP and other architectures/technologies/strategies/whatever. He didn't compared REST to WS-* or SOAP, he compares it to SOA what is totally nonsense for me, and that's why I'm asking him about his definition of SOA and why it is 'another way'.

Re: An implementation in search of an architecture
by
Benjamin Carlyle

The web was service-oriented long before anyone from the WS camp coined the term. Rather than offer your service in terms of a one-off custom WDSL specification you offer it in terms of standard interactions with a collection of resources. It is service-oriented that works in a large-scale participation network.

The long and the short of it is that REST defines a limited number of interactions that all system components should support if they are both meaningful and permitted. Because the number of interaction patterns and the kinds of data exchanged are both limited it is possible to plug system components together without prior planning. This is simply a dream in the WS-* world, where extra code being written in addition to generated code is usually a prerequisite.

The kind of service-orientation that corba and WS-* offer relies on special code to be written on both sides for each new IDL or WSDL developed. REST interactions rely on special code to be written whenever the current HTTP rfc is superceded or features of a new content type are required. WS-SOA works in systems where there are a small number of server-side implementations, particularly in special-purpose systems that are not designed to interact with a wider network.

We can see the history of this pattern already played out a number of times in the SCADA industry and in other system monitoring and control environments. One of the popular SCADA protocols in US electrical systems is OPC, OLE for process control. This is based on COM, but layers an IDL on top of COM that has RESTful properties. This allows it to act as a data interchange between units out in the field, servers in the data centre, and operator workstations. In order for a large number of both server and client components to interact you need a defined protocol that conforms to appropriate architectural constraints. In WS-SOA the whole protocol is not defined until you include the WSDL file on top of the specifications already in play as part of the WS-* stack. REST architectures define the full protocol in its combination of transport protocol and content type specifications.

I concede there is a scale between pure REST practice on the wider web and the needs of a small set of programs operating within a corporate environment. As you get to smaller networks and smaller numbers of server implementations the need to constrain both interact types and data types diminishes. The most important question in architecture today is probably how to deal with the various points on this scale within the same architectural envelope. I think REST forms a better basis for beginning this discussion than the nebulous WS-SOA concept, which really doesn't address issues of architecture directly.

WS-SOA advocates aren't stupid. I don't contend that. However they are facing and solving problems in ways that don't scale up to large participation architectures, and that will bite at some point. Does REST scale down better than WS-SOA scales up? I think so. My experience is that building small distributed systems RESTfully produces significant benefits and is not significantly more difficult. Probably the biggest inhibitor is that developers are often forced to think at two levels of abstraction:

Which resources am I offering and how do client interact with them, and

Which objects am I creating, and what function calls are being made on these objects.

Re: An implementation in search of an architecture
by
Kurt Christensen

"Same old bandwagon..." I couldn't agree more. I can't understand why more people haven't drawn parallels between WS-* and CORBA. Remember CORBA? Remember the sheer number of un-implementable specs produced by the OMG? Remember how ORBs from different vendors couldn't communicate with one another as soon as the IDL became non-trivial?

I wonder how many times we'll all watch this same play performed over the course of our careers...

>He didn't compared REST to WS-* or SOAP he compares it to SOA what is totally nonsense for meYou simply cannot compare REST vs SOAP. REST is an architectural style while SOAP is a protocol (and WS-* is just a set of standards). So how can you compare apples to oranges?? SOA on the other hand is an architectural style, so it makes sense to compare REST with SOA.

I have had lengthy email discussions with Roy Fielding and Anne Thomas Manes (of course with Sanjiva too) about the subject and they both are of the view that SOAP (or WS-*) vs REST is not the right comparison, rather REST vs SOA is the more meaningful comparison. Unless you understands this, you cannot make the right decesions on what architecture is more appropriate for a given situation.

Also bear in mind that there is no formal definition for SOA,ROA or Web Services. Web Services like ESB is a term coined by marketing (pls correct me if I am wrong). Nobody says Web Services == SOA, but it's widely accepted that Web Services is one way of realizing SOA.

Now the question is can you use web services to realize REST ?? When you apply the REST constraints can you still call your service a web service? This is where there is a clear division in the community. While some think it's possible others thinks it is not. It also depends on how you define Web Services.

However one thing is for sure. The resurgence of REST and the concept of RESTful Web Services is purely driven by marketing. REST was there even before the Web. Roy thought about it even before he designed HTTP. Funny it was ignored all this time :). REST is now very hot and every stack thats out there wants to say they support REST eventhough there is utter confusion about the whole thing.

Also bear in mind that there is no formal definition for SOA,ROA or Web Services. Web Services like ESB is a term coined by marketing (pls correct me if I am wrong). Nobody says Web Services == SOA, but it's widely accepted that Web Services is one way of realizing SOA.

That is one of the big distinctions between REST and SOA. REST is very well defined (I won't get into "formality" here) in Roy Fielding's thesis as an architectural style. Any architectural style is, by definition, an abstract concept, more descriptive than prescriptive in nature. But is is well defined nonetheless. SOA is defined as many things in many places, which is another way of saying that it is not defined at all. Stefan's previous post hinted at two different possible meanings for SOA, both of which are interesting and useful, and in a perfect world would have good distinct names. But I guess we'll just have to live with the ambiguity and ensuing cognitive dissonance for, well..., forever.

Now the question is can you use web services to realize REST ?? When you apply the REST constraints can you still call your service a web service? This is where there is a clear division in the community. While some think it's possible others thinks it is not. It also depends on how you define Web Services.

I don't see this division at all, much less "clearly" :)Full-stack WSDL+SOAP+XSD Web Services break constraints that are an integral part of the REST architectural style. One obvious difference is that there is no "Uniform interface" when we talk about invoking SOAP endpoints. As an aside, SOAP by itself is a fine XML vocabulary for extensible message envelopes and I don't see why it could notbe used, if *necessary*, as a media-type for a resource representation (though I guess that would be rare).

However one thing is for sure. The resurgence of REST and the concept of RESTful Web Services is purely driven by marketing. REST was there even before the Web. Roy thought about it even before he designed HTTP. Funny it was ignored all this time :). REST is now very hot and every stack thats out there wants to say they support REST eventhough there is utter confusion about the whole thing.

Utter confusion about what? And the only "stack support" needed for developing a RESTful web service is a good http library. It remains to be seen if further abstractions can be helpful (as opposed to WS-*, where they are pretty much necessary).

(ugh. I screwed-up the formatting. This is the same as the previous message, but properly formatted.)

Hello Rajith.

Also bear in mind that there is no formal definition for SOA,ROA or Web Services. Web Services like ESB is a term coined by marketing (pls correct me if I am wrong). Nobody says Web Services == SOA, but it's widely accepted that Web Services is one way of realizing SOA.

That is one of the big distinctions between REST and SOA. REST is very well defined (I won't get into "formality" here) in Roy Fielding's thesis as an architectural style. Any architectural style is, by definition, an abstract concept, more descriptive than prescriptive in nature. But is is well defined nonetheless. SOA is defined as many things in many places, which is another way of saying that it is not defined at all. Stefan's previous post hinted at two different possible meanings for SOA, both of which are interesting and useful, and in a perfect world would have good distinct names. But I guess we'll just have to live with the ambiguity and ensuing cognitive dissonance for, well..., forever.

Now the question is can you use web services to realize REST ?? When you apply the REST constraints can you still call your service a web service? This is where there is a clear division in the community. While some think it's possible others thinks it is not. It also depends on how you define Web Services.

I don't see this division at all, much less "clearly" :)Full-stack WSDL+SOAP+XSD Web Services break constraints that are an integral part of the REST architectural style. One obvious difference is that there is no "Uniform interface" when we talk about invoking SOAP endpoints. As an aside, SOAP by itself is a fine XML vocabulary for extensible message envelopes and I don't see why it could notbe used, if *necessary*, as a media-type for a resource representation (though I guess that would be rare).

However one thing is for sure. The resurgence of REST and the concept of RESTful Web Services is purely driven by marketing. REST was there even before the Web. Roy thought about it even before he designed HTTP. Funny it was ignored all this time :). REST is now very hot and every stack thats out there wants to say they support REST eventhough there is utter confusion about the whole thing.

Utter confusion about what? And the only "stack support" needed for developing a RESTful web service is a good http library. It remains to be seen if further abstractions can be helpful (as opposed to WS-*, where they are pretty much necessary).

SOA, as your second paragraph says, can be implemented in REST, SOAP and other architectures/technologies/strategies/whatever. He didn't compared REST to WS-* or SOAP, he compares it to SOA what is totally nonsense for me, and that's why I'm asking him about his definition of SOA and why it is 'another way'.

I agree that asking him to pick which (of the many) definitions of SOA he was referring to is a good idea. The paragraph quoted above is, I think, pretty illustrative of the ambiguity. Stefan suggested that there are two views of SOA. A business view, which I would loosely describe as organizing an institution's IT development efforts as separate services, probably run by distinct teams, which communicate through well-defined interfaces. It is opposed to business strategies like "everything has to pass through the Big Integration Database" or "lets build one giant Consolidated app containing everything we need", etc. (Stefan, please correct me if I am mischaracterizing your views).

And then there is the second, more technical, view of SOA as an architectural style. The problem is that, IMHO, there is ambiguity in defining this second view as well. One could say that the SOA architectural style is predicated on message exchanges by loosely coupled systems. This is somewhat compatible with the REST style. It is also too unconstrained to be of any use. We could try to refine it and say that in a SOA, systems communicate by exchanging documents consisting in header/body envelopes that can be processed and routed by intermediaries using language-independent technologies. This is less compatible with REST, but reads like just a definition of WS-*, not an abstract architectural style.

Rafael, the first definition is exactly the one I was trying to provide, so you did definitely not misunderstand me. I agree with the ambiguity issue of the second definition as well, but did not want to complicate things even further :-)

When someone points out differences between SOA and REST, they're usually (at least in this particular moment) subscribing to the *technical* view. Every single time someone who subscribes to "SOA as a business concept" view complains "but you can do SOA with REST!"

I have had lengthy email discussions with Roy Fielding and Anne Thomas Manes (of course with Sanjiva too) about the subject and they both are of the view that SOAP (or WS-*) vs REST is not the right comparison, rather REST vs SOA is the more meaningful comparison. Unless you understands this, you cannot make the right decesions on what architecture is more appropriate for a given situation.

Can you provide arguments on this conclusion?

Also bear in mind that there is no formal definition for SOA,ROA or Web Services. Web Services like ESB is a term coined by marketing (pls correct me if I am wrong). Nobody says Web Services == SOA, but it's widely accepted that Web Services is one way of realizing SOA.

And that's why I asked him about his definition.

However one thing is for sure. The resurgence of REST and the concept of RESTful Web Services is purely driven by marketing. REST was there even before the Web. Roy thought about it even before he designed HTTP. Funny it was ignored all this time :). REST is now very hot and every stack thats out there wants to say they support REST eventhough there is utter confusion about the whole thing.

I think it's the same thing as 'from-EJB-to-POJO'. POJOs were there all that time but it only got recognition as an architecture when the EJB model failed.

Actually I do think there is space for both technologies right now, my point is that stating that 'you use SOA or REST' is simply FUD.

I don't see this division at all, much less "clearly" :)Full-stack WSDL+SOAP+XSD Web Services break constraints that are an integral part of the REST architectural style. One obvious difference is that there is no "Uniform interface" when we talk about invoking SOAP endpoints. As an aside, SOAP by itself is a fine XML vocabulary for extensible message envelopes and I don't see why it could not be used, if *necessary*, as a media-type for a resource representation (though I guess that would be rare).

Even in your analysis you have described the two different schools of thought, which IMHO is an accurate reflection of the current division. In you main point you say REST constraints are broken with Web Services and then as a side point you mention, it is possible if *necessary* to use SOAP as a media type for a resource representation. I too agree. But in your second point, If I am not mistaken you don't seem to think, that SOAP as a media type doesn't necessarily mean it's Web Services. I also think the same. However there are many people who thinks that it's also Web Services. Thats why I said there is a clear distinction.

Also read Stefans comments,

When someone points out differences between SOA and REST, they're usually (at least in this particular moment) subscribing to the *technical* view. Every single time someone who subscribes to "SOA as a business concept" view complains "but you can do SOA with REST!"

This is the clear division I am talking about. While some compare SOA and REST as alternatives, some thinks it's possible to do SOA with REST, or Web Services with REST. The fact that SOA, ROA and Web Services means many things many people, some things it is possible to do REST with Web Services while others think it's not.

Utter confusion about what?

Well look at the confusion and ambiguity surrounding REST and RESTful web services. IMO a lot of people have not groked the concept of REST properly. Many think POX/HTTP is REST. And that is why people tend to compare SOAP vs REST.

And the only "stack support" needed for developing a RESTful web service is a good http library. It remains to be seen if further abstractions can be helpful (as opposed to WS-*, where they are pretty much necessary)

Spot on. Thats exactly my point. We had HTTP libraries for ages. Did anybody talk about REST? Now every SOAP stack out there is trying to say we support REST !!!!! Since when do u need a SOAP stack to do REST??? Look at Sun's new JSR 311, why aren't they improving the existing API's for HTTP and adding that support their instead of doing it inside JAX-WS? That is more marketing than anything else. REST is hot now, so is Web Services. Most people think it's possible to do both in one (the feeling I got from attending conferences last year), so marketing is trying to cater to this large segment.

When someone points out differences between SOA and REST, they're usually (at least in this particular moment) subscribing to the *technical* view. Every single time someone who subscribes to "SOA as a business concept" view complains "but you can do SOA with REST!"

I totally agree here. People who talk about SOA as an abstract architectural style, compares REST and SOA as alternatives. Folks who think SOA as a "Business Concept" mostly promoted by marketing and executives(and I have heard comments like SOA is not technology but a culture change etc at conferences) thinks and wants to do SOA with REST (and everything under the sun that can make money) wether it is possible or not. As I said it's more marketing driven than anything else.

I do not like the WS-* standards, there simply are too many for my taste. They are complicated (I hate XML Schema), they are difficult to debug, if anything in your toolset seems to behave wrong. But ...But I like having standards. And I prefer to have a standard for signing XML messages. I like to have a standard that gives "types" and "syntax" for XML messages. And so on.

With REST I can solve all these issues (and did), but without a standard I have to solve them again and again. For every new company/partner that I want to integrate, I have to negotiate again, how to handle these issues. Ok, if I am Google or Amazon _I_ do not have to negoatiate.

And picking up a discussion with Stefan Tilkov (see www.innoq.com/blog/st/2006/06/30/rest_vs_soap_o...) I am still thinking, it might be my mind set that seems to prefer "methods" like "promoteToCustomer" "and transferMoney" As far as I have understood REST by now, I would have to write the first as something like "PUT Customer" (and check which fields have changed) or "POST CustomerCollection?Customer".And for transferMoney I would have to do something like "POST Transactions?Account1&Account2&Amount". And how do I define the parameters that are allowed/necessary?

I think you are right that the REST community has so far not been great at developing standards. Most relevant standards have come out of the IETF or w3c, and the rest community can be said to have come out of those organisations more than it has really turned around and put back into them.

I think there are two sides to this. On one side you have the universality issue. If we are talking about REST in terms of the architecture of the web it takes a pretty big problem that affects a lot of people to create impetus to change anything. HTTP/1.1 is still not universally adopted after how many years of standardisation? On the other side of the issue you have more corporate-minded people who I think are only just starting to seriously join the REST camp.

I think the REST community is almost ready to start seriously organising around grass-roots solutions to problems that many of us face in implementing real REST technology. Technology that is ready for the web can still go through the IETF, but I wonder if we need a set of alternative bodies. These bodies would work on smaller problem sets within particular industries or on problems that could take decades to be solved on the wider web.

To answer your questions:I'm not entirely sure what you mean by promoteToCustomer (this highlights the issue of using non-uniform methods). I'll assume you mean something like "send to customer" or "make an issue known to the customer". The answer to this one really depends on the detail, but one could see either a POST to the customer's message queue or a PUT of "true" the information's "customer visible" url.

I would see most transferMoney requests as POSTing a transaction, eg POST "<transfer><debit account="1">100</debit><credit account="2">100</credit></transfer>" to example.com/newTransactions. As I mentioned earlier, the REST community hasn't made the inroads that it perhaps should have. I don't think we have a straightforward content type for this transaction, though there are probably a few contenders out there in limited circulation.

I should have added some documentation to "promoteToCustomer" :-) In our company that means "promoting" someone who previously has expressed an interest in one of our products/services to become a customer (this is different compared to someone completely new, w.r.t. to some backend processes). But I do not think that "this highlights the issue of non-uniform methods" as you put it. Because PUTting the person to the CustomersList would not be as explicit. There may be many processes, where finally someone becomes a customer, but only one way where "promoteToCustomer" must be called (you can think of this service as kind of "orchestration" service that calls other services).

W.r.t. to transferMoney POSTed as <transfer> just seems to move the "verb" of the operation ("transfer") into the message. Where is the advantage compared to a WS? Creating a mapping for all "operations" onto PUT/POST/GET/DELETE seems to me now like a reduction in expressiveness of the interface. How would I describe the REST "interface" to an interested party, another company that wants to use our services? Again: as bad as XML-Schema and WSDL might sometimes be, they are there, we can use them now.

Sorry, I do not get the REST vs. WS debate. For me REST just looks like another technology based on another mind set. It might feel better from a developer perspective. It might be better for one-to-one communications or for _very_ big hubs with many spokes (Amazon, Ebay, Google). But from my point of view it doesn't look that well for B2B (many-to-many) of for some big "corporate" in-house development teams. So is it perhaps just: "Choose the right tool for the right problem"?

I am currently mostly using SessionBeans/DTOs as interface for a diverse set of clients, perhaps this influences my way of thinking (and it would take a huge amount of effort to change every developer toward a REST perspective). But even for a green field project, I don't really understand the advantages of using REST. So perhaps it is my "socialization". How does yours differ?

WSDL+SOAP+XSD Web Services break constraints that are an integral partof the REST architectural style. One obvious difference is that thereis no "Uniform interface" when we talk about invoking SOAP endpoints.

WSDL+SOAP+XSD most definitely <em>allow</em> one to break the uniform interface constraint. However, that's user choice- in WSDL 2.0 in particular its perfectly possible to describe 100% RESTful services. (WSDL 1.1 allows it too but its at least a bit messy.) So if you want to use WSDL+SOAP+XSD in a RESTful manner you can.

Similarly, HTTP has extension methods- which clearly allows one to break the uniform interface constraints. (Anyone remember M-POST from SOAP 0.9?) In fact, WebDAV has its own new uniform interface extending from the 4 HTTP ones.

Does that mean HTTP is non-RESTful? It means that one can build RESTful and non-RESTful systems with HTTP. Its user choice.

Is WebDAV RESTful? Interesting question .. in its own world it works within a uniform interface and therefore it does not break the constraint. However, relative to base HTTP its not keeping to the rules right?

As an aside, SOAP by itself is a fine XML vocabulary for extensiblemessage envelopes and I don't see why it could notbe used, if *necessary*, as a media-type for a resource representation (though I guess that would be rare).

I can see where that could be useful- imagine wanting to sign the body of a POSTed XML? Where would you put the signature? You'd need some envelope structure and SOAP is as good as any at saying envelope/header/body. I believe Amazon's WS API has their own (pre-SOAP/pre-WS-Sec) form of an envelope.

If your point is that its perfectly possible to implement a service that adheres to the constrained interface and so on, then I agree with you that its possible to implement SOA with REST.

What I was trying to point out is that if you take a given distributed systems problem and try to design a soltion, then artifacts you'd be dealing with and the shape of them would be different if you tried to design it as as a bunch of interacting services vs. as a bunch of interacting resources. Its at that level that I see SOA and ROA as being two different ways to skin a cat.

Does that mean one is wrong or one is better? Of course not. Given a particular problem it may indeed be the case that SOA or ROA is a better approach for the problem but I don't see how anyone can say that either approach is better for all distributed systems problems.

Sorry, I mean "transaction" rather than "transfer" in the newTransactions example. In REST we would normally never PUT or POST a document that didn't also make sense to GET. It makes sense to GET a transaction, or have it returned as part of a transaction list. A transfer on the other hand is, as you say, a verb that it doesn't usually make sense to transfer.

Check out my (still pretty draft) REST in plain English article on restwiki. It's all about constraining interaction patterns to small set that everyone understands, allowing components with similar patterns and document types to interoperate without prior planning. REST does this in a way that allows interfaces to evolve over decades of new demands being placed on the architecture, as well as scale to huge network sizes.

Does REST help a single client interact with a single server? Not much, though the REST API of the server will likely be familiar to someone already comfortable with REST. REST is really about how the architecture performs when there are thousands of client implementations, hundreds of server implementations, and millions of architecture components controlled by just as many different agency interests over limited bandwidth fixed latency networks.

If you think you'll never participate in that kind of architecture you can stick with WS-SOA, but I would generally plan with at least one eye on the big picture. REST's benefits are not simply on or off. They improve as the size and criticality of your architecture increase. I also think the big picture architecture will do some bending over the next few years to more directly meet the needs of developers who currently depend on WS-SOA.

Atlhough we agree, that statement I've quoted a lot of times in this thread is very problematic, as I said in my lat post here. Someone has to read tons of papers and posts to realize what you were trying to say there, and most people simply will not do it at all before taking conclusions.

Therefore we will have people who read this interview and will get the feeling that SOA is antagonic to REST. By the time a developer suggest RESTful services to solve a business problem, his manager possibly will say something like "Not at all, we're on SOA here. Get these SOAP books and bring me solutions using SOA".

Re: An implementation in search of an architecture
by
Sanjiva Weerawarana

Hmmm .. maybe people realize that WS-* is not a distributed object system like CORBA is? At least those people who understand that WS-* is not what SOAP 1.1 and its RPC system enabled understand that WS-* is not a distributed OO!

You shouldn't also judge WS-* by the old generation of middleware that has been built for it- look at it with new stuff like Apache Axis2 / WSO2 WSAS / Microsoft WCF and you'll see that its not at all about making RPC calls over XML.

Re: An implementation in search of an architecture
by
Kurt Christensen

Yeah dude, I get it. What I also understand is that french vanilla is so close to vanilla that it's not worth quibbling about. What I understand beyond that is that the same things that effectively killed CORBA (and when I say "CORBA" I mean all of the other stuff that went with it, which overlap nicely with all the WS-* stuff) are the same things that are going to kill WS-*.

Of course, unfortunately, it won't be killed before a whole lot of snake oil salesmen have sold a whole lot of expensive middleware junk on a whole lot of golf courses to a whole lot of CIOs. And then those CIOs move on to the next sorry company, while a bunch of rank-and-file programmers are left with a bunch of angry users, trying to figure out how to get server X to understand the XML coming out of server Y.

I don't mean to sound rude, man - I know that you're trying to solve a lot of big hairy problems. It's just that these problems aren't new, and the solutions aren't quite as new and improved as some would have us believe.

Re: An implementation in search of an architecture
by
Sanjiva Weerawarana

I understand the view about snakeoil salespeople but how do you explain the wide adoption of open source WS-* stacks? We don't go around "selling" that stuff; people are coming and "buying" it (at zero cost) without us marketing it. How do you explain that- maybe all the developers who are looking and using those are misguided?

Come on. REST has its place in the world. So does WS-*. Neither is a magic solution.

I should have added some documentation to "promoteToCustomer" :-) In our company that means "promoting" someone who previously has expressed an interest in one of our products/services to become a customer (this is different compared to someone completely new, w.r.t. to some backend processes). But I do not think that "this highlights the issue of non-uniform methods" as you put it. Because PUTting the person to the CustomersList would not be as explicit. There may be many processes, where finally someone becomes a customer, but only one way where "promoteToCustomer" must be called (you can think of this service as kind of "orchestration" service that calls other services).

how do you explain the wide adoption of open source WS-* stacks? We don't go around "selling" that stuff; people are coming and "buying" it (at zero cost) without us marketing it.

With all due respect, you are definitely "marketing" the stuff -- just with slightly different means than the vendors of commercial products. And the marketing of WS-* done by the big vendors of commercial products, including your former employer, obviously benefits WSO2, too.

Which is all perfectly OK; just pointing out that adoption of Axis2 and other WSO2 products, however widespread it may be, is in itself not a sign of WS-*'s qualities (or lack of thereof).

"REST has its place in the world. So does WS-*. Neither is a magic solution."

Of course neither is a magic solution. But I think the point that you're missing Sanjiva, is that REST is an architectural *improvement* on SOA; it adds a lot of loose coupling. Some generality is sacrificed with these constraints - for example high performance stateful messaging - but not that much.

REST separates interface from implementation, while SOA does not. That's what the difference boils down to. See my earlier article here on that topic.

Hi Ben: I disagree. WADL (www.pushtotest.com/thecohenblog/wsdl-and-wadl) is getting some traction with me as a way to provide a service interface definition for REST and AJAX services. It seems to me that there is a lot more investigation and experimentation over the next couple of years before any of these message-oriented protocols and their respectives stacks will emerge as a winner.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.