Try searching Google for “soap rest” What’s interesting isn’t the results, it’s the sponsored link; a pointer to an opening on the Google team.
Similar searches for “soap java” and “soap” don’t show the same link.
Hmm, I wonder what prompted that? Or maybe I just don’t understand how AdWords works.
But putting the misery of these experiences aside, I’m surprised at how little I’ve had to worry about SOAP. As it became clear to me that Web Services were becoming a menace to much of the goodness wrought by XML, I worried that I would be forced to do a lot of gritting my teeth at work while I accommodated clients’ insistence on WS. This hasn’t turned out to be the case. In several cases where WS “end points” have been suggested, I’ve been surprised at how easily my suggestions of a REST-like alternative are embraced (the fact that I could usually whip up running code in hours helped a lot).
That’s what I’m seeing too, at least once you’re in the door (though for a pretty small sample space of two clients). On the other hand, looking for cool large scale distributed systems work has becoming extremely painful since Web services came onto the scene. Most projects are asking for “SOAP/WSDL/UDDI experience”, which leaves me either having to lie and say “Oh yes, I’ve got lots” (which I won’t do, of course), or else I have to put a pleasant face on WS-Insanity and brave the inevitable lack of interest, as I did in my resume;
He believes that, for the foreseeable future, the bulk of innovation in Internet scale systems will occur via additional architectural constraints applied to the Web; for example the Semantic Web, or the Two Way Web. Unfortunately, these beliefs also indicate to him that Web services have some serious architectural flaws that make their suitability as a large scale integration solution questionable. As a result, he spends considerable amounts of time working within standards setting organizations to ensure that these specifications – including SOAP 1.2 – take maximal advantage of the Web.
According to Radovan anyhow 8-)
Everyone programs in something different, so let’s just do protocol-based integration, where we will just agree on the format of the messages we are going to exchange over the wire.
I think this is the thing some ‘REST fundamentalists’ are still missing…
No, I think we get that. Or at least we get that it’s a critical part of the solution. This is why HTTP 1.1 is as well specified as it is (not that it doesn’t have issues, of course). The problem is that the format is only one part of the solution. The other part are the semantics of the messages, something that HTTP also specifies, but SOAP doesn’t … not that it should though, as it can always inherit them from the underlying protocol.
One of the nice things about being a critic of the current approach to Web services, is that the infighting amoungst the players had a chilling effect on standardization efforts, which made my job – of keeping the W3C as free from this stuff as possible – easier. Unfortunately, today, everybody seems to have come together for the worst spec of them all; WS-Addressing is now a W3C submission.
SOAP, I liked very much, just not how people were/are using it.
WSDL, I didn’t like because of the bad practice it encouraged, but I felt that it might have a role to play.
But this monstrosity actively causes harm by not using URIs as EPRs. That part of the spec has no redeeming qualities, except that it represents an attempt on behalf of the authors to Do The Right Thing regarding addressing (i.e. standardize it). Unfortunately, those authors fail to recognize that we’ve already got a perfectly good identification spec.
Update; P.S. yes, I understand than an EPR has a mandatory wsa:Address, but that doesn’t change anything, as any identifying information in the SOAP envelope is necessarily in conflict with the HTTP Request-URI. One endpoint per message, please.
The original impetus behind XML, at least as far as I was concerned back in 1996, was a way to exchange data between programs so that a program could become a service for another program. I saw this as a very simple idea. Send me a message of type A and I’ll agree to send back messages of types B, C, or D depending on your A. If the message is a simle query, send it as a URL with a query string. In the services world, this has become XML over HTTP much more than so called “web services” with their huge and complex panoply of SOAP specs and standards.
Wow! I actually had a weblog entry written, that questioned whether Adam’s transition away from a Web services company, and towards a Web company, might have had something to do with him “seeing the light” regarding REST vs. SOA. I decided not to post it because it was pure conjecture. But it seems my gut feel was partly right. However, he also adds;
Why? Because it is easy and quick.
Which is true, but not a very satisfying answer I’d say. Why is it easy and quick? Anyhow, I’m sure Adam will have lots of time to mull that question over in his work at Google. I look forward to seeing what cool stuff he comes up with there.
Sean discovers WS-MessageDelivery which triggers him to display a level of frustration that I didn’t expect to see, but that I’m happy about. We need more integration gurus to raise their hands and ask “Hello, what the $%@! are you people doing?!”, in the hope that those building this architecture may stop to take the time to think about what they’ve created and give it the principled architectural examination it requires. Sean writes;
You started at the wrong end of the pipe. SOAP always was and always will be and API-centric worldview. That is not the future. That is the past. Re-implemented badly. Sometimes I wonder. I really do.
I disagree that SOAP requires an API-centric worldview – I battled against enormous odds to ensure SOAP 1.2 didn’t – but I certainly agree that this is how Web services proponents and specs are using the SOAP specs.
On the other hand, to their credit, Web services promoters are trying to distance themselves from APIs. The problem is that they think they’ve done this with “document oriented SOAP” by removing the operation from the message. Unfortunately though, in their architecture, the operation is still in effect, it’s just hidden from the message which actually makes things worse than RPC (in case you wondered if that was possible!).
What Web services need is an architecture based purely on document exchange, not some RPC/document bastard. Luckily, one is readily available.
A great one from Jim this morning, about how REST seems to be all the buzz in various distributed computing communities. I noticed that too; it’s very cool, and a long time coming.
As for the cons, this one sentence of his seems to sum it up;
Sure REST’s message-oriented approach is sensible, but it has the downside of mixing the semantics of the SOAP message with those of the transport protocol.
What can I say? As I see it, that’s been the “Big Disconnect” since the whole Web services thing got started. Far too many people – especially those weened on CORBA, DCOM, and similarly styled architectures – just don’t appreciate the HUGELY important role played by application protocols. This is evident by the continual de-emphasis of them by treating them as transport protocols, as Jim does there, intentionally or not.
Document oriented SOAP messages should have no semantics by themselves, not even processMessage (modulo TCP – see below). The semantics should be provided by the underlying application protocol. That way, the semantics of a SOAP envelope being transferred with HTTP PUT won’t be confused with one being transferred with HTTP POST or SMTP DATA; they mean different things, and you can lookup those meanings in the HTTP and SMTP specs.
Now, if you sent it over TCP and want POST/DATA/processMessage-like semantics, you need to bind those semantics to the TCP port via an IANA registry.
Transport protocol (e.g. TCP, UDP) independence is good. Application protocol independence must die die die!
Stefan found a paper with a very interesting title, that I hadn’t heard anything about; Developing Web Services Choreography Standards – The Case of REST vs. SOAP.
I’d heard Keith Swenson’s name a few days earlier in the context of ASAP and some of the recent buzz surrounding it, but I’ve known about his work for a while. I spent some time studying both SWAP (co-authored with a buddy of mine, Greg Bolcer) and IPP during their development.
Aside; IPP actually slowed my studies into the Web (along with HTTP-NG, sigh) because I, for whatever reason, started by assuming that IPP was a good use of HTTP. Only later did I realize that the exact opposite was true (as was only recently confirmed by Roy).
On the upside, IPP’s use of POST spawned an important and interesting exchange, via Internet draft, that I studied very carefully (which lead to a draft of my own); Don’t go Postal, and The Use of POST.
Anyhow, all of this to say that I was quite surprised to see REST reasonably well represented … except for perhaps this part;
Several standards for REST style workflow interaction have been proposed, namely SWAP, Wf-XML [26, 52, 58], AWSP [49] and ASAP [38]. Instead of relying on the HTTP 1.0 commands, these standards provide higher level operations that are specifically designed for the interaction with remote processes.
Hint; if you’re trying to provide operations at a higher level than the application layer (e.g. HTTP), you’re abusing HTTP, not using it. But, the operations being tunneled are themselves reasonably generic, which is good design practice for this space, and what I think the authors were trying to point out as nearly RESTful.
It’s really encouraging to see REST mentioned in the context of workflow, since I believe it provides a superior base for scalable solutions than does SOA. I think this paper could be an important piece of work if the authors were to spend some time studying both architectural styles from a software architecture POV, as well as actually building some systems with each. As is, the analysis is pretty decent, but the conclusion – basically that it’s a crap shoot over which one is superior – needs some major work.
Savas posted a good state-of-the-conversation post upon his return, so I’ll respond to it. I still hope to respond to his earlier response to a question of mine, in what will likely end up being a mini treatise on state and state references. But that’ll have to wait.
I am now thinking that it is time to explore whether it would be possible to take the “processThis” idea to a next level. First, we really need to change the name; perhaps something like “processDocument” or “processMessage”; I like the latter better.
I could live with either, but I’d prefer “processDocument” since it’s more specific. “processMessage” could include the processing of a document (i.e. a chunk of state), or the processing of an explicit request for some action to occur. To my mind, “processDocument” suggests the former, which is what we all seem to want; state transfer.
Then, we need to demonstrate that we are not that far really from REST and, in fact, the REST approach can be seen as a subset of our model where the protocol verbs are effectively modelled as a submission of documents to the “processMessage” abstract operation.
Yes, you really aren’t very far from REST. Your architectural style seems to be state transfer based, which is awesome. I say “seems”, because Jim’s response to Matt Garland’s suggestion for how queries should be done suggested that he supported a non-state-transfer approach to querying. Which brings us to …
This last observation answers Mark’s point about the semantics of GET in this post. The semantics of GET can be captured through an appropriate SOAP message. An HTTP request-response pattern can also be described as a message exchange pattern in which the receiver of the request will send a message to the “processMessage” operation of the sender.
I think this is an absolutely critical point to the understanding of REST, or at least how it relates to the style you promote. But I think you’ve got it wrong there Savas, on two counts.
Second point first; I think the comparison between HTTP request/response and “processMessage” is incorrect; the comparison should be between HTTP POST and “processMessage”. That is, if you take away all the HTTP operations except POST, what you’ve got remaining is an application protocol with a single explicit (though it could just as well be implicit) operation which is semantically identical to a state-transfer semantic, which I understand processWhatever to be.
Second, though related, I’m certain that query semantics cannot be captured by an “appropriate SOAP message”. Consider that for any SOAP query document you can construct, I can present a SOAP service which simply adds that document to a queue (just as an example), and returns a success bit (e.g. an HTTP 204 message) with no other information. What this means then, is that a service which does respond to the query, is actually presenting a different abstraction than the one which places it in the queue. In other words, the query service isn’t using “processMessage” semantics. To query, you need a query semantic. And if you’ve got a uniform document submission semantic in processMessage, then why not a uniform query semantic? In my view, that should be the “next level” we take; it need not be full REST, of course, just an, IMO, superior style than what’s there now.
I’ll leave it at that for now, I think. The state issue needs to be addressed as I mentioned, but I think it can be decoupled from this argument.
P.S. enough of the love-in, ok guys? I’ve got a rep to maintain. 8-)