My attention to the discussion concerning SOAP was attracted by a personal talk at the SAP Weblogger Meeting in Walldorf on Juli, 15th. There, DJ Adams stated his sense of understanding about SOAP, which he formerly expressed in his article Real Web Services with REST and ICF and supported thru his weblog Forget SOAP – build real web services with the ICF.
After reading/scanning these resources published by DJ, I hope to have understood him correctly. Fulfilling this precondition let me clarify things and tell you my opinion on SOAP vs. HTTP/REST. Please note that I have not read Fielding’s dissertation completely.
Definition of “Web Service”
There seems to be a different understanding between DJ and me what a Web Service is. This is OK as definitions are not laws. Here’s the significant part of a definition from Webopedia, which satisfies me:
“Unlike traditional client/server models, such as a Web server/Web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface across a network. The applications interface, not the users. Developers can then add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to users.”
Architectural overview and comparison
We go on by visualizing the two paradigms in question. After that follows the comparison of both concepts.
Architecture of HTTP-based Web Services
My picture of a Web Service architecture based on HTTP as DJ described it in his article and blog is the following, if I understood correctly:
The yellow area surrounding the three URL’s indicates that all three URL’s should belong to the same internet domain. The box reading “Parameters” should have been attached to the “URL” box as parameters are encoded within it. But to outline the fact that parameters are attached to services the current positioning seemed more approriate to me.
Architecture of SOAP-based Web Services
Here the schema of a SOAP-based architecture for Web Services:
In contrast to the HTTP approach there is only one central URL. It is representing the server address serving SOAP requests. The WSDL displayed above is the Web Service Description Language, containing services available (i.e. methods), parameters applicable to that services and metadata. The WSDL file is sent to the central URL
As the next picture shows one can match several elements of these two concepts.
So there really is not that big a difference between them! It has to be remarked that metadata is not part of the HTTP-concept. Now consider the following.
As DJ writes in the paragraph “SOAP and Firewalls”, a firewall admin should determine the accessability of several Web Services. He writes “With HTTP, the firewall administrator’s job is easier. What’s the verb? POST? Ok. What’s the noun? /some/path/to/a/data/element. Ok, not allowed. Job done.”
Well, I talked to a collegue (technical oriented) and a network administrator doing firewall stuff as well. For us three it does not make any sense to authenticate the access to a bunch of Web Services with help of the firewall. Perhaps I am missing the point, but how should the firewall admin know, what happens when someone calls a specific Web Service? Example: Let there be a Web Service called giveMeDJsMailAddress. Who can tell me what this particular service does? NO ONE CAN! The only person being in the position to do so quite probably is the developer implementing the functionality behind that Web Service. Who says that giveMeDJsMailAddress is not doing something the firewall admin does not know and if he did would not allow it. But just given the name of a Web Service (or the verb and noun, like DJ wrote) is not enough to really know what’s going on. And as there is no metadata available for DJ’s HTTP approach, things get even worse.
BTW I am of the opinion that a firewall admin should let his hands from doing authentication on functional level. He/she should only decide which ports to release and which URL’s to block in general (e.g. forbid employees to access eBay from within the company during work).
DJ: Have I mixed something up here? I cannot imagine you meant it the way I observed it.
And to use a metapher as an argument: Wouldn’t you wonder about a company securing a shop floor by using a fire door as authentication mechanism? Fire door and fire wall are not that different!
DJ’s HTTP-based suggestion for Web Service handling does not include metadata at all. This is at least my impression from the readings I did and from a personal discussion with him. In my eyes, metadata is essential to Web Services. Metadata is gaining a very high importance in the future. Just look at the Semantic Web, UDDI or annotations in Java. Without metadata there is no information. Metadata is the vehicle to add semantics to data to convert it into information.
When calling a Web Service there are often parameters attached to it. It seems to me, that in DJ’s concept, they are delivered thru the URL also used for calling the Web Service itself. Several things come to my mind when thinking about it:
There are more elegant ways to attach parameters to a function call than thru plain text within a long URL. And separation of concerns is a paradigm that angles off. Perhaps this is too theoretical, but the separation of data and specifications should be not bad at all.
While the previous paragraph is not that important in general, the authentication issue for itself should be enough thinking over HTTP-based Web Services. I hopefully managed to clarify the differences and similarities of both concepts, SOAP and HTTP, while not explaining all details.
IMHO, DJ’s statements have its eligilibity and it is good to have someone thinking about aspects being seen for granted by many people. Thank you for that, DJ! The REST principle is something we should keep in mind whenever possible. But as the situation displays to me after reading DJ’s article and weblog, I cannot identify the advantage of his HTTP concept over SOAP on a broad basis. P.S.: Please allow me to answer earliest on the 24th as I am on vacation until then 🙂 Because of this constraint and because of wanting to post this blog immediately I also could not synchronize it with the editorial staff.