“Internet SOAP” vs. REST: Huh?
December 28th, 2007 | Published in distributed systems, REST, scalability, SOA | 26 Comments | Bookmark on Pinboard.in
Dilip Ranganathan pointed me to a long rant from Ganesh Prasad about using SOAP at Internet scale. I see that Stu Charlton already chimed in there with some good comments and analysis, but I think there’s still more to say.
Unless I’m missing something, Ganesh seems to be saying, “Hey, if we just stick SOAP directly onto TCP, we can scale beyond Web scale to Internet scale!” Oh, if it were only so easy. I would think that it’s fairly obvious that just because TCP scales well doesn’t mean that higher-level protocols sitting on top of it automatically scale to the same degree.
Why does the Web scale so well? Because of particular constraints deliberately imposed to induce specific architectural properties. The caching constraint contributes heavily to Web scalability, for example. Statelessness and the uniform interface also play a big role there. These constraints along with conditional GET allow messages to be significantly reduced in size or better yet, eliminated altogether. The resulting scalability impact is huge.
Ganesh talks about a lot of the things you’d have to add to the mix get a useful SOA ecosystem on top of SOAP/TCP, but nowhere does he talk about the specific architectural properties and constraints required to make it all scale. Without that, it just ain’t gonna happen. Furthermore, I don’t believe any system based either on interface specialization (i.e., the opposite of the uniform interface constraint) or on “processThis” can scale to Web scale. Interface specialization significantly increases coupling while reducing visibility and applicability, while “processThis” is so devoid of semantics that it offers nowhere to practically apply constraints like caching and statelessness that are so critical to scalability.
December 28th, 2007 at 9:18 am (#)
> Unless I’m missing something, Ganesh seems to be saying, “Hey, if we just stick SOAP directly onto TCP, we can scale beyond Web scale to Internet scale!”
Steve, that’s not what I’m saying. If there’s just one thing I want a reader to take away from my post, it’s this: “REST does not have a monopoly on architectural elegance.” The analogies with the Internet were meant to show the elegance of the messaging paradigm. I’m not talking about “scaling beyond Web scale”.
You emphasise the importance of constraints for scalability to happen.
Granularity is an important factor in scalability, too. SOAP messages can be arbitrarily chunky, enabling the specification of pithy communications at the required level of abstraction for the domain in question.
SOAP messaging assumes statelessness just like REST, so I’m not sure what your point is there.
And I’m not so sure about the uniform interface constraint either. It’s nice in theory, but in practice, the four HTTP verbs as used by RESTful applications seem to be GET, PUT, DELETE and MISC. It sort of defeats the purpose when one of the “limited” set of verbs is a catch-all, and not coincidentally, is neither safe nor idempotent. How constrained is that? I think it’s a “smell” that indicates that in the real world, we need an unconstrained set of verbs, all pretensions to the contrary notwithstanding.
Mind you, I like both REST and SOAP messaging. It’s smugness that I don’t suffer gladly. I hear positive comments about REST from most of the SOAP/WS-* practitioners I speak to, but from the REST camp, I hear only condescension. Seriously though, is there _nothing_ REST can learn from SOAP/WS-*? I find that hard to believe, and the attitude smacks of religion rather than science.
Believe me, it would greatly clear the air if a REST advocate sat down and listed out things in SOAP/WS-* that were “good” and worth adopting by REST. It would not weaken the argument for REST one bit, and it would reassure non-partisans like myself that there are reasonable people on both sides of the debate.
December 28th, 2007 at 12:01 pm (#)
I actually took the time to read Fielding’s dissertation and since then I’ve wondered about the extent to which caching contributes the scalability of the web. If anyone knows of useful papers that quantify or attempt to quantify the traffic-minimizing benefits of caching (in whatever setting, whether closer to the client or closer to the server), please post URIs.
December 28th, 2007 at 4:26 pm (#)
I would agree that there are elegant solutions in SOAP/WS-* stack. But many of them are solutions inside of the SOAP/WS-* paradigm. If we shift paradigm from “sending/receiving messages” to a “data web” then problems and (preferable) solutions are often different.
December 29th, 2007 at 11:20 am (#)
Well said Ganesh, I really like your definition of the uniform interface (GET, PUT, DELETE and MISC).
Steve, if you get some time, I would be really curious to understand your position on my two posts:
1) action interfaces are natural for any state transition of a resource
2) REST creates strong coupling
Could you also explain why the enterprise needs the kind of scalability you are talking about?
thanks,
JJ-
December 29th, 2007 at 12:54 pm (#)
Ganesh: In no way does the presence of POST among the verbs “defeat the purpose.” To say, “Well, one of the verbs is less constrained than the others, so we might as well open it all up and allow any verb at all, without constraints on any of them” is a HUGE leap that makes no sense whatsoever. Rather than a “smell” I view POST as a very pragmatic solution when it’s used as intended. Sure, you can abuse it — hello, SOAP — but tunneling is hardly a new phenomenon invented specifically for POST.
To attribute smugness to the entire REST community is a bit of an overreaction. If you read the rest-discuss Yahoo group, for example, it’s pretty much entirely composed of messages from developers discussing techniques and approaches. Nobody there seems smug to me.
As for wanting some REST person to say good things about SOAP or WS-*, why is that so important? The “RESTful Web Services” book, for example, points to WS-Security as a good thing. It obviously shows that there are REST people looking at the WS-* work and seeing what they might borrow from it. Does that satisfy you?
In my own REST-based work, I never give SOAP or WS-* a second thought. Keep in mind that I worked on WS-* standards, and products based on them, when I was chief architect/engineer for IONA, and I’ve written a number of positive articles and columns about those technologies. At the same time, I wrote a few articles about the benefits of REST as well. Today in my new line of work, I have no need for any WS-* or SOAP, because REST gives me everything I need. Does that make me smug or unreasonable? If you don’t believe there are reasonable people on both sides of the debate, then IMO you haven’t looked hard enough.
December 30th, 2007 at 12:17 pm (#)
After a bit of digging, I found a relatively early study on the benefits of caching. The PDF is available here. From the abstract:
December 30th, 2007 at 8:03 pm (#)
JJ: regarding your question about why an enterprise requires scalability, consider the following facts:
As for whether I will comment on the two blog postings you point to, I looked through the first one, and it’s pretty far off base. I can tell just from the title of the second one that’s it wrong (keep in mind that I have worked extensively on real-world production systems on both sides of this fence). So before I spend time looking at them any further, first answer a question for me: have you ever tried, with an open mind, to implement a real system using REST? If your answer is no, then no offense, but no, I will not comment further on your blog postings, as I don’t have time to waste on academic debates.
December 31st, 2007 at 6:09 pm (#)
Nicholas:
in the enterprise caching rates are very different, You don’t have customers calling your call center in parallel or several times a week. Any customer related record is going to be hit at a very low rate for having any caching benefit.
I have no problem with the results you mention for a web site with resources that are in high demand by a large number of clients. And sure enough you better have a great solution for this kind of problem.
This is actually the problem with Entity Beans, you rarely need to hit a record twice (except for metadata for instance, or list of values). So caching in the enterprise has very limited use cases, I don’t think anybody can seriously discuss that anymore.
Steve:
I am sorry that the title “turned you off” :-). I, however, think that you find the two questions embarassing, and you have no answer for them.
I work for a very large organization, so I think I can also have just a tiny bit of authority in saying what I am saying.
I also would like to emphasize that I am not saying “you don’t need scalability”, all I am saying is that in general in the enterprise you are more concerned with “reuse” than “scalability”. The scalability of enterprise application is a problem that has been solved, reuse is the problem that enterprises are facing today.
If you want to successfully address this problem:
2. The enterprise boundary isn’t as clear as it used to be.
then you need a very robust composition mechanism. REST offers a nearly perfect composition mechanism at the presentation layer which unfortunately does not translate well at all at the process and information layer.
December 31st, 2007 at 9:54 pm (#)
JJ: I am in no way embarrassed by the questions your blog asks, and they’re rather easily answered for someone willing to actually understand the answers. However, I believe you must be embarrassed to answer my very simple question. Let me repeat it: have you ever tried, with an open mind, to use REST to build a real application? It will take you mere seconds to minimally answer that question, because it’s either “yes” or “no,” but if the answer is “yes” then it would be better if you could also describe your experiences. Answering it is the very least you could do if you expect me to take considerable time from my very busy schedule to analyze your two blog postings. But again, if the answer is “no,” then I’m not going to waste my time, because if you actually wanted to learn something instead of just argue, you would have already opened your mind, learned about REST, and tried it for yourself. I have zero time for religious or academic arguments.
January 1st, 2008 at 3:34 pm (#)
sorry, Steve, I thought the answer was obvious, NO, but before I drive a recommendation for my company in one direction, I like to have enough information to make this recommendation and substantiate my decision. Some people call it, CYA, I call it integrity.
I think I have done a lot of reading and researching, and asking to have a pretty good idea where to use REST and where not to use it. None of the RESTifarians has been able to answer these questions in a satisfactory way, so I was turning to you, based on the kinds of things that you are writing, I was hoping you could give us a definite answer that I would have missed, along with the other RESTifarians.
I have no worry that these two little questions will keep coming at you, and one day you will answer them. Actually, I have done so much research on REST that I have total confidence about how you will answer them.
Happy 2008 !!
January 1st, 2008 at 9:46 pm (#)
JJ: So, you’ve never developed any application using REST, yet you already know everything about it? And not only that, you already know in advance what my answers would be if I were to waste my time responding to your blog postings? I see. But if you already know the answers, why waste my time?
Have you even thought for a minute how you would respond if the tables were turned, and some self-proclaimed expert was writing negatively about your favorite technologies, despite having freely admitted to having no relevant experience with them? I can see the flames now.
Unlike you, as I’ve already pointed out, I’ve built real-world systems using approaches from both sides of the fence. There is simply no amount of studying you can do that can fully answer the kinds of questions you’re asking. How did you gain the experience you have with your favorite technologies — did you just study them, and then you instantly had all the answers? Of course not. I’m sure gaining whatever expertise you might have took quite a bit of trial and error. Taking only a purely academic view of REST, or any other approach for that matter, will lead you in the wrong direction.
I see that Stu has already answered your questions, but you seem to reject his answers. From your postings and your responses to his efforts it’s quite easy to see that your mind is closed. It’s too bad that you refuse to learn from someone as smart as Stu. It’s also easy to see that you’re rejecting REST based mostly on fear. You owe it to your company and to yourself to stop being afraid of new approaches and open your mind. REST isn’t a silver bullet — nothing is — but it’s far too valuable to keep it out of your toolbox only because you’re afraid of it.
January 2nd, 2008 at 5:15 pm (#)
Steve,
A very Happy New Year to you!
A delayed response to your comments:
> In no way does the presence of POST among the verbs “defeat the purpose.” To say, “Well, one of the verbs is less constrained than the others, so we might as well open it all up and allow any verb at all, without constraints on any of them” is a HUGE leap that makes no sense whatsoever. Rather than a “smell” I view POST as a very pragmatic solution when it’s used as intended.
I understand, I guess I was just tweaking the REST crowd ;-). With 21 years of experience in the software industry, I know only too well the value of flexibility that is not abused.
> As for wanting some REST person to say good things about SOAP or WS-*, why is that so important?
I’m not so much interested in REST people saying good things about SOAP/WS-*. I want an honest discussion about REST’s limitations from the people who understand it best.
To explain my point of view, I’m an architect with a large bank, and part of my job is to understand, position and recommend approaches to “enterprise integration and SOA”, however you interpret it. If I report back tomorrow that we don’t need SOAP/WS-* and that REST can solve all of our problems, and it then transpires that REST does not in fact handle a couple of use cases that are important to the bank, then I end up with egg on my face.
I think I understand the elegance and power of REST. Any evangelism there is preaching to the choir. I now need to understand the limits of REST, the things it cannot do, the subtle implications of its many design choices. Unfortunately, although I have been doing a fair bit of Internet research, I seem to find more defensiveness than candid answers whenever the question of REST limitations comes up, and the counter-attack is usually based on limitations of some particular SOAP/WS-* model, such as SOAP-RPC or the heavyweight “ESB” approach. It doesn’t answer my points. That’s why I put my quest in such stark terms – is there any example of a REST person who has said nice things about SOAP/WS-*? That would be a beginning in helping me understand and position REST as a potential solution for my employer.
I view my bank as a collection of different systems from different eras and diverse technology heritage that nevertheless need to work cooperatively when presenting “services” (in the English sense of the term) to customers, staff and business partners.
I seem to be fighting on two fronts here. There is a huge marketing machine behind a particular flavour of SOAP/WS-* usage, which favours massive investment in largely proprietary “ESB” technology and tooling. I believe the actual philosophical vision behind SOAP/WS-*
(“endpointware”) is antithetical to the interests of that vendor-driven marketing machine. That’s one of the important points I made in my blog posting (http://wisdomofganesh.blogspot.com/2007/12/paying-restafarians-back-in-their-own.html).
Then there’s the entire SOAP-vs-REST debate, which seems a bit childish to me. What I’m finding is that the hard problem is in standardising domain vocabulary. If one division or system talks about “customer” while another uses the term “client” to mean the same thing, we have a gap that needs to be bridged. This has nothing to do with SOAP or REST as both approaches are domain-neutral. As another example, if one system requires customer IDs to be 8-digit numeric strings while another requires them to be 6-character alphanumeric strings, we have an even bigger problem, especially when there are existing databases to be reconciled. When one comes from that angle, XML, schema definitions and data transformations seem to loom much larger than SOAP or REST as a part of the solution. Indeed, SOAP and REST seem to be nothing more than different ways to move XML data between parts of the business. One of them defines verbs for each distinct function, and passes chunks of XML around as payload. The other defines a constrained set of standard verbs and lots of resource endpoints, and passes chunks of XML around as payload. Need there really be such a heated debate over how to move XML around?
I see hints of limitations in REST as it exists today when Sam Ruby talks about WADL, which seems to me like WSDL-for-REST, which then seems to indicate that REST lacks and needs to develop a description language. Then there’s HTTPR to improve REST reliability, but that seems more an IBM initiative than something endorsed by the REST community. Stakeholders like my bank’s business owners talk in terms of “processes”, and BPMN/WS-BPEL seem to fit right into that space, with no corresponding body of REST knowledge around “process”. What else? What else?
And what’s the REST position on XML? Is XML viewed as one of many equally valid data encodings (like JSON)? Is XML the “recommended” choice? Does REST work best when XML is used? etc.
I don’t expect that you will be able to give me an immediate answer to all of the above, but I do think we need to have a larger discussion on the issues and the perspective that I have pointed to. Hopefully, with many different minds thinking about the issue from different angles, a comprehensive picture will eventually emerge.
Regards,
Ganesh
January 2nd, 2008 at 5:33 pm (#)
Steve:
you would admit that someone who admitted that “he was wrong” for the past 20 years (RPC, CORBA, ESB…) and tell us lightly “there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage.” without any argument to substantiate his claims has little credibility in my eyes.
Why should I drive the investment of any substantial amount of resources from my company? What tells me that you will not write a post in a couple of years explaining that somehow you lost the “religion” along the way? Just give me one reason why I should trust your claims without asking questions?
The only answer that Stu gave me was: “What I agreed with you was that we need a *contract* to generate shared understanding. I did not claim that we needed specific actions to generate shared understanding. On the other hand, I do think it would be useful to define higher-level abstractions in terms of uniform operations, though I am not convinced this will enhance interoperability.”
I must admit that I do not fully understand his response. It is a bit cryptic. Maybe it is clear to you? He does seem to acknowledge some issues when REST is used in a component-component scenario and a contract beyond the uniform interface is needed, including the ability to convey more traditional application semantics.
So I was turning to you since you have “seen the light” and you have “significant experience”. I would hate to pass on big opportunities for my employer. Turning to an expert such as yourself to answer somewhat very simple architecture questions seem to be reasonable. These questions are not academic in any ways. They represent, IMHO, basic questions that any IT architect should ask himself or herself before investing large amounts of resources in this direction.
Frankly, if Stu, Stefan, Subbu, Tim, Mark B. and yourself had a straightforward answer to these two simple questions they would have been published a long time ago.
It is of course much harder to have this kind of architecture discussion than writing statements such as the kind of things you, Tim Bray or Mark B. write.
So until you, Tim and others have something substantial to say about REST that we don’t already know, please don’t waste our time, you just sound like a bunch of ESB salesmen.
JJ-
January 2nd, 2008 at 6:57 pm (#)
JJ: is there a reason that you have to be so abrasive? Your comment above is mostly insulting, and you also personally attacked me in your blog. You act as if I owe you something, which obviously I don’t.
First you tell me that I’ve stated that I was wrong about all the technologies I’ve ever worked on before. Where do you get this stuff from? I’ll thank you not to put words in my mouth, or misinterpret things I’ve said, just to try to prove your twisted and off-base points. But if you really do think I’m so wrong, then why do you keep asking for my help?
I’ve spent much of my career working on distributed object systems, especially CORBA, and I think we did a lot of good work there, all things considered. Was it all perfect? Hell no. Did we get some things wrong? Hell yes. No technology is perfect, including CORBA and including REST. (I also worked on WS-* for a few years but questioned it while doing so, and then eventually figured out it wasn’t going anywhere good.) What’s important, though, is avoiding religious attachment to technologies (something you apparently have significant trouble with) so that you can do it better the next time around. As you’re a self-proclaimed REST expert, you already know that the Web is REST-based and that it’s also a large distributed objects system. I therefore see REST as a perfectly logical step in my journey through the distributed objects space. A decade from now, I may very well be using something else besides REST because it helps me build even better solutions. Does that make me wrong about REST now? Of course not, because technologies change and you have to adapt with them. Change is the only constant we can count on. Go study the Technology Adoption Lifecycle and try to educate yourself about how technologies are actually adopted; you need to do this because you keep trying to shoehorn all of us into one single adoption bin, but we don’t all belong there.
But anyway, to cut a long story short, as I said before I can answer all your questions, but I refuse to do so because of your poor attitude and your closed mind. I have a pretty good feeling that Mark and Tim feel the same way, if they’re even paying attention to you. You can’t go around abrasively insulting people and personally attacking them in your blog, and then expect them to cooperate with you. You wonder why you should trust my apparently flawed technical opinion — remember, you declared that I’ve been wrong about everything I’ve ever worked on — but I, and a few others I’m sure, wonder why we should trust that you would like to participate in a meaningful and respectful technical discussion, since you’ve made it quite clear both in your blog postings and in your comments here and elsewhere that you have no intention of doing so. If you were to publicly apologize to me for your personal attacks both in a comment here and in your blog, then I might change my mind. But until then, good luck getting the answers you seek from me or from anyone else.
Meanwhile, contrast your comment above with the one from Ganesh above it. Ganesh’s comment is very pleasant and objective, and he’s obviously seeking to learn. I have every intention of trying to answer his questions because I think we can learn from each other. I don’t pretend to have all the answers, but encountering someone like Ganesh means we both stand a good chance to learn as we help each other out. It’s too bad for you, JJ, that you seem incapable of the same.
January 3rd, 2008 at 8:19 am (#)
Steve:
my comments are abrasive towards ANY RESTifarian for one and unique reason, you guys are propagating false arguments and don’t want to engage in objective discussions about your recommendations.
The same thing happened between 2000 and 2005 between ebXML and Web Services and it resulted in wasting lots of time and lots of work. REST vs Web Services is going down the same path, this behavior is irresponsible.
When you write “A significant advantage of the uniform interface constraint lies in the area of scalability. For a client to correctly interact with a SOA service, it must understand the specifics of both that service’s interface contract and data contract. But for a client to invoke a REST service, it must understand only that service’s specific data contract: the interface contract is uniform for all services. I can’t overstate this difference’s impact on large-scale systems.”
I have proven that this statement is incorrect in the case of a server-to-server communication while absolutely correct in a human-browser-to-server scenario. When I ask these disturbing questions to people like you, they don’t answer, so the only technique that I found effective is to use “abrasion” until I finally touch their level of comfort.
At the end of the day, I am a scientist, so the only thing that matter to me is logical argumentation. My mind is absolutely and totally open because I have nothing to defend but a logical argumentation. I have nothing to sell, my job, like Ganesh, is to make precise recommendations.
My style is only a reflection of your style in case you have not noticed. My style would have no object, if we could in effect have a logical discussion.
January 3rd, 2008 at 9:45 am (#)
JJ: Oh, so you’re a scientist? Well, I am a person. As long as you’re abrasive and discourteous to me, you will get nowhere. I am not taking the bait.
From a technical point of view, you’ve proven nothing. The only thing “disturbing” about your questions is that you feel entitled to insult and personally attack those who dare to go in directions that you disagree with. In this entire discussion, you’ve proven only two things:
End of discussion. Further comments from you posted here will not appear. If you feel the need to continue to childishly attack Tim, Mark, me or others in your blog, go right ahead, but know that the only one who looks foolish as a result is you.
January 3rd, 2008 at 6:31 pm (#)
Then there’s the entire SOAP-vs-REST debate, which seems a bit childish to me.
But there you are trying to “tweak” people. Perhaps it does seem childish now. It was pretty unpleasant a few years back if you were on the REST side. You have to appreciate the history. REST was considered a toy if not broken, entirely. I recall been told that the Web had no architecture by people I consider eminent. Those vendors you mentioned? Along with standards work, they were going to fix the web for the enterprise, nothing less. That didn’t work out as expected. Please note two things – first, I’m not disputing that WS-* has been effective inside enterprises or in specific point to point integrations; second the web/REST community did not come to the enterprise market saying it needed to be fixed. Some of that work was done in the W3C and was never to going work for or improve the Web. The W3C has a clear mission statement that was not being met, and individuals had to stand up and debate the merits. Now today, REST is going through a hype phase, advocates of the approach are lumped together pejoratively as “RESTafarians”, as if it was a cult instead of a technical architecture, whereas by counterpoint the WS-* is a bastion of rational design. That state of affairs is so wrong, it’s not even ironic. You say you want to understand the limitations of REST, but titling posts “paying restafarians back in their own coin” is hardly conducive to any kind of useful discussion, especially given the history. Is being surprised a controversial post didn’t tweak people, who have being putting up with this kind of crap for years, really the best way to get the information you want? I’ve been watching that kind of debate for years, and part of me thinks its endemic to the relative immaturity the IT/middleware industry.
“What I’m finding is that the hard problem is in standardising domain vocabulary.”
That sits above the application layer as deployed today, and you will have that problem no matter what you roll out on.
JJ assumes people have clammed up I think for the wrong reasons; I’m pretty sure people just switched off due to the tone of his posts. I know I did – calling a group of people “RESTafarian” as he does poisons the wells – more’s the disappointment when I thought we had come to some kind of civil ground. In some ways the dicussion seems pointless; it’s not as if the design aspects of REST aren’t well articulated and cannot be evaluated, and I don’t know anyone who claims it to be a universal solution, only that it’s technically better suited for some things. It has well stated constraints, and that’s the *point* – it can’t be a universal solution. Aside from rhetoric, the one place JJ and I do have a straight-up disagreement is over granularity and shared meaning of actions; I’m not convinced that BPM technology has the declarative semantics claimed for it (WSDL and UDDI had the same problems). The limitations are well discussed in the AI literature (cf McDermott, Hayes); try searching for “gensym fallacy” or “no notation without denotation” – these are old, old research problems that get rediscovered by the industry.
It does seem to me though that enterprise people are looking for new universal solutions every 5 years. Sorry if that’s harsh.
The problem you have with domain vocabularies is similar. However, I know my way around the semantic issues integrators have to deal with, and my best answer to you and JJ right now is to look at model theory, speech act theory, Pi-calculus (which JJ probably knows well due to his standards work), or John Sowa’s work, and realise that no widely available industrial technology that has what’s needed, including BPM; *but* at the very least, protocol technology like HTTP (REST) and XMPP (ARRESTED) represents a linguistic evolution in the right direction, and can support more formal interlingua such as RDF/OWL/KIF/CG in the future *because* of the way these protocols introduce layering. In the web space, you might look at RDF or OWL as they are well formalised, but my opinion is that to be deployed they require retooling and/or might be too sophisticated to roll out right now (as agent technology like FIPA and OCL was half a decade ago). And in the absence of agreed interlingua I’m convinced you will need to introduce programmatic transformations as part of an integration architecture; shared models are a bad assumption in decentralised independently evolving systems.
“I see hints of limitations in REST as it exists today when Sam Ruby talks about WADL, which seems to me like WSDL-for-REST, which then seems to indicate that REST lacks and needs to develop a description language.”
HTTP and XMPP are a kind of domain vocabulary, they just happen to be rudimentary, akin to grunting rather than speech. I am fairly sure though that technology like W3C Schema, industry vertical vocabularies based only on XML grammars with no explcit semantics, and the WSDL style of discovery, are dead ends as far as that problem goes. There’s no limitation, unless you think good layering is limiting.
“Stakeholders like my bank’s business owners talk in terms of “processes”, and BPMN/WS-BPEL seem to fit right into that space, with no corresponding body of REST knowledge around ‘process'”
I understand that. Your industry’s problem now is that SOA hype is taking that kind of business metaphor too literally and in too abstract a way to be useful, however well it plays to stakeholders. In combination with an IT doesn’t matter and/or gets nothing done and/or is a cost center prejudice, I suspect that’s building serious problems for the future. Aligning computing and data processing so tightly to domain specific business processes and services (which are *highly* transient) up and down layers isn’t an obviously good idea. It might be a better idea to treat IT as a general purpose utility, move it away from being a department, and build processes on top – in fact I’m confident that will be the next big thing after the SOA vision is suitably adjusted.
“And what’s the REST position on XML? ”
To my mind, that’s an odd question, like asking what the ESB position is on CSV. XML is a representation format. It doesn’t play into the overall architecture except in cases where processing a representation is part of the protocol act (for example, Atompub and HTTPLR both assume Atom format documents).
January 3rd, 2008 at 7:23 pm (#)
Bill,
I can understand your response. If you’ve been vilified and belittled for years and are finally vindicated, there’s bound to be some bitterness/resentment. I completely empathise. I’ve been in such situations before in my career.
Being new to the REST-SOAP debate myself, I have no baggage. What I’m seeing now is what you’ve correctly called the hype phase around REST. I believe the pendulum has swung the other way compared to a few years ago and in the current climate, it seems like the SOAP/WS-* “establishment” can do nothing right. I don’t believe that view is correct either.
If you read my post carefully, you’ll see that I’m not attacking REST at all. All I’m pointing out is that REST does not have a monopoly on architectural elegance. My language was deliberately provocative but hopefully the humour beneath came across as well. There is a model of SOAP messaging held by many (although SOAP didn’t start out that way, and many vendors even today are twisting the message (pun unintended)) which has very attractive architectural properties analogous to the Internet model, that compare well with the elegance of REST. I guess it takes a non-partisan view to even acknowledge that.
I don’t agree 100% with a couple of your other comments, though there’s some truth in them:
> [On “processes”] Your industry’s problem now is that SOA hype is taking that kind of business metaphor too literally and in too abstract a way to be useful, however well it plays to stakeholders.
I have seen BPEL-based processes being implemented and operational. It would be hard for someone to argue that this is an “abstract” view or does not work. You would be immediately challenged with actual dollar figures showing how much has been saved through process modelling and automation (or how many jobs were axed!), so I would suggest that’s a tough statement to back up.
> Aligning computing and data processing so tightly to domain specific business processes and services (which are *highly* transient) up and down layers isn’t an obviously good idea.
Ah, but business processes and services are not necessarily highly transient. It depends on how they’re modelled. The Domain-Driven Design (DDD) school of thought holds that rich, insightful modelling goes to the *core* of business logic and models its fundamental principles. Details change all the time, but if the basic model has been done right, they become little more than configuration changes to software. That also aligns well with practices like Agile methodologies, which require constant refactoring. DDD with agile development actually makes sense, because refactoring is minimised by the durable model, and the process becomes even faster.
A couple of colleagues and myself have been thinking about how these various IT trends can be fruitfully combined (SOA, DDD, agile) – we consider REST to be a legitimate part of SOA, by the way – and we’re inching our way towards a model. See http://wisdomofganesh.blogspot.com/2008/01/domain-model-its-representations-and.html
One suggestion I would make to REST advocates is this: Don’t attack SOA. Talk about REST as a way to build SOA, because that’s what it is. The fundamental principle of SOA is loose coupling, and REST is a great way to achieve that.
And by the way, I meant no offence by my use of the term RESTafarians. I thought that’s what you called yourselves! If the term is offensive, I’ll stop using it.
Regards,
Ganesh
January 3rd, 2008 at 7:45 pm (#)
Bill,
I forgot a couple or points:
> shared models are a bad assumption in decentralised independently evolving systems.
I absolutely agree, and didn’t mean to suggest that I was looking for a common vocabulary across the enterprise. We do talk in terms of “federated data models”. But it’s important to formalise vocabularies in order to distinguish them. E.g., <retailbank:customer> may mean something different from <corporatebank:customer>, and unless the taxonomy is clear, we won’t even know we have a problem when the messages start moving back and forth.
>> “And what’s the REST position on XML? ”
> To my mind, that’s an odd question, like asking what the ESB position is on CSV. XML is a representation format.
Yes, but in your experience, have you found any relative advantages of XML over other data interchange formats like JSON?
Regards,
Ganesh
January 4th, 2008 at 1:16 am (#)
Ganesh,
I think that REST understanding helps us to build better SOAP/WS*-based services (when we have to). Investment into SOAP/WS* infrastructure can help to get (buy) quickly some “centralized” features that are important in many “enterprise scenarios”: centralized business process management, centralized security management, centralized monitoring, centralized change management… and “traditional SOA tools” become more and more supportive for REST-based services.
I agree with these statements: “What I’m finding is that the hard problem is in standardising domain vocabulary. If one division or system talks about “customer” while another uses the term “client” to mean the same thing, we have a gap that needs to be bridged. This has nothing to do with SOAP or REST as both approaches are domain-neutral. As another example, if one system requires customer IDs to be 8-digit numeric strings while another requires them to be 6-character alphanumeric strings, we have an even bigger problem, especially when there are existing databases to be reconciled.”
I usually recommend introduction of “enterprise knowledge map” as an additional layer (service) in enterprise architecture
January 4th, 2008 at 10:29 am (#)
I’ll second every comment Ganesh has made, especially this one:
One suggestion I would make to REST advocates is this: Don’t attack SOA. Talk about REST as a way to build SOA, because that’s what it is. The fundamental principle of SOA is loose coupling, and REST is a great way to achieve that.
JJ-
January 4th, 2008 at 7:03 pm (#)
“I can understand your response. If you’ve been vilified and belittled for years and are finally vindicated, there’s bound to be some bitterness/resentment. I completely empathise. I’ve been in such situations before in my career.
I don’t feel “vindicated”, that’s not the point, but I am happy that WS-* has not overrun the deployed Web. So please give this line of reasoning a rest; focus instead on why you feel you need to tweak the people you want answers from:
“Being new to the REST-SOAP debate myself, I have no baggage””
“Paying restafarians back in their own coin”
Hmm.
“Yes, but in your experience, have you found any relative advantages of XML over other data interchange formats like JSON?”
Yes. The toolchain is bigger, and it deals with Unicode better (this is becoming less true over time). It’s also easier to read for non technical people, although that depends on how you design the markup, eg, CamelCase markup that is optimised for roundtripping with OO languages has poor readability, whereas Rss/Atom is decent. These days readability via browsers is a main reason why I like microformats. To its credit, JSON has identified the basic machine interchange types that can work; XSD by comparison has been a mess.
When I talk about XML I tend to exclude stuff like XSD/W3C Schema, and I don’t see its unicode/textual nature as being a problem, ie, I’m not sold on binary infosets and such and have record of arguing against them.
The downside to XML are at least twofold, First is that if what you actually needed was MIME after all, it’s a poor substitute – witness how the SOAP community went round and round on this for years, and how Atompub allows non-XML upload by design. Second, it also suffers from a gensym fallacy of sorts (this is why you need transformation) as many of the vocabularies that needed one, don’t have a formal model, and as such aren’t inerligua of the kind SOA and BPM seem to need. But this can also be a feature, and it’s worth pointing out that the semantic emptiness of XML is designed in.
“Ah, but business processes and services are not necessarily highly transient. It depends on how they’re modelled.”
Business requirements are the least stable kind that I’ve seen ;) I think the number of modeling efforts, and their length, the sheer cost of data integration, the cost of implementing m&A, the entire nature of enterprise tech, does not support you here. This is in part because people have started from the wrong foundations, and in part because people just don’t want to agree on the meaning of words and terms.
January 4th, 2008 at 7:16 pm (#)
“One suggestion I would make to REST advocates is this: Don’t attack SOA.”
I need to be careful here because I’m talking about the label “SOA” and its use in the market, and you and Ganesh are probably talking about something else, that you call “SOA”. I am concerned about the vacuity of the word “SOA”, and the height of abstraction.
So here’s the essential problem: I have no idea, specifically as to what you and Ganesh mean by SOA and more importantly, whether you mean the same thing.
You and Ganesh might be implementing successfully and calling it SOA, but the term itself has no common meaning, as such it has no value to me.
I’m a technologist that understands business, I expect some crispness and precision for technology and technical design paradigms. If SOA is purely a business process concept like Six Sigma or Kaizen, we can stop there. If it has technical import that can be assessed and measured as fit for use in designing software, that’s not coming across at all.
Loose coupling itself is better, but it doesn’t tell me much (eg what coupling dimensions? how is SCA not coupled?). That said, given the amount press and backing it gets, there must be surely something more to SOA than restating an engineering tenet.
January 4th, 2008 at 9:34 pm (#)
Bill,
Thanks for the detailed response on XML.
Another of the REST limitations that I deduced from your last comment is that “getting” REST does not confer a sense of humour, thicken a thin skin or enable one to respond graciously when people are trying to be nice.
Never mind.
A RESTful explanation for my blog post that has so offended you: Resource representations that are parsed by humans as provocative blog posts tend to generate more hyperlinks and create a more powerful hypermedia state machine that can drive the application state of more browsers compared to those that are parsed as bland. Hence human psychology when layered architecturally over the scalable web tends to favour the creation of resources which may not be to the taste of humans advocating a scalable web or such architectural layering. Make sense now?
Someone should write a thesis on this law of the web along the lines of Godel’s theorem:
“Within any formal system of logic, there will always be some propositions that cannot be proven using the rules and axioms of that system of logic.”
;-)
Regards,
Ganesh
January 5th, 2008 at 12:24 am (#)
[…] reminds you of the REST vs. SOA debate, doesn’t […]
January 5th, 2008 at 4:45 am (#)
Bill,
Apologies if that came out sounding harsher than I intended. Treat my comments as light banter. I actually have no hard feelings at all.
Regards,
Ganesh