Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Stefan Tilkov on Feb 16, 2007
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".
Read the interview here.
Free $40 SOA Demystified Book Offer
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
"There's not only one way to build a distributed system. RESTful is one way, SOA is another as are distributed objects and RPC."
So, REST!=SOA? So, SOA==SOAP+WS-*?
I hope he was just kidding.
I didn't anywhere say SOA == SOAP+WS-*! SOA is an approach to building systems, WS-* is a bunch of technologies .. with which you can certainly realize SOAs but its by no means the only way.
"SOA is another [way]"
So what's the point in putting SOA as an alternative to REST?
What a hoot :)
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".
Benjamin
SOA is an alternative to ROA.
Well I certainly wasn't expecting a lot of love from RESTafarians after this interview :). Stefan himself had to keep his hands in his pockets to control himself I think!
Yep, REST solved everything and those of us who are not RESTafarins are just too dumb to know a good thing when they see it.
So... you can't do SOA using REST?
If that's true I am curious about your definition of SOA.
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.
SOA as a business concept can be implemented using WS-* or REST - both (and many others) are valid strategies.
Others view SOA and ROA as alternatives, with WS-* being an implementation of SOA, and RESTful HTTP an implementation of ROA. That view is valid as well.
I believe Sanjiva's view is the first, yours is the second.
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'.
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:
Benjamin.
"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...
Phillip,
>He didn't compared REST to WS-* or SOAP he compares it to SOA what is totally nonsense for me
You 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.
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 not
be 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 not
be 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).
Hi Phillip, nice to see you around here. :)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!"
Sanjiva: I would also really like to hear your definition of SOA. Or do you also feel that SOA is just marketing?
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.
Hi Rafael,
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.
Benjamin
Hi,
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?
Victor
Hi Rafael,
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.
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 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).
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.
Hi Philip,
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.
Benjamin.
Hello, Sajiva,
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".
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.
Well. REST is a architecture style,it is not a tecnology.
www.xfront.com/REST-Web-Services.html <- Found by Google
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.
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 about:
POST /party/124134/customership
<customerRelationship>
<keyAccountManager>my.org.com/employees/12355</keyAccountManager>
<customerStatus>GOLD</customerStatus>
<expirationDate>2008/12/31</expirationDate>
</customerRelationship>
Sorry about the beating of deceased equines.
Sanjiva wrote
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.
Have you checked out WADL (Web Application Description Language at wadl.dev.java.net/) by Marc Hadley yet? This might answer a lot of your needs.
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.
-Frank Cohen
www.pushtotest.com
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
39 comments
Watch Thread Reply