Sam responds
For those who want to understand the issue Mark has with SOAP, he objects to the string “doGoogleSearch” in this example. FWIW, I don’t see how this is any different, architecturally, than hidden controls in HTML.
It isn’t any different than hidden controls, but I wouldn’t use hidden controls either. I’d just POST the data “q=foo” to whatever URI the POST form told me too. No need to understand what “doGoogleSearch” means, because the context in which the POST operation is to be interpreted by the server, is provided entirely by the URI to which I’m POSTing.
Sometimes I see signs of smart folks figuring out how to do Web services properly, and I feel a glimmer of hope that the industry may not be wasting hundreds of millions of dollars with SOAP and WSDL. Then I see stuff like this, and I realize, nope, it’s going to hell – specifically this part;
Bergandi: With a wizard-based environment within the SOAPswitch. The SOAPswitch itself has self-discovery capabilities. It has the ability to, in the example I gave you, inquire into the metadata of what the Siebel system looks like; discover what business objects are available and what methods are available against those business objects; and then, based upon that, in a very, very simple way, generate all the SOAP that’s required for communication.
Internet-scale distributed computing just ain’t that easy, folks, sorry.
I’m a few days late, but Sam Ruby posted his excellent REST+SOAP essay last week. I was surprised to see it not get more fanfare. I commented to Sam that I was concerned about this bit;
Now add high level methods which take care of all composite
create, update, and delete operations.
Sam suggested to me off-line that he was thinking about it in terms of just passing data over a wall/membrane, to which I responded that this is exactly how POST works; that the operation that occurs is determined solely by the server. So we may be in synch, but given previous things I’ve heard him say, and his work on SOAP and WSDL, I wonder if we really are. But here’s hoping!!
An interesting discussion on xml-dist-app about implicit versus explicit use of the Web Method Specification Feature of SOAP 1.2. I guess I just have a hard time understanding why you’d want to hide the method, either by defining a default, or deriving it from the MEP in use. I mean, how else do you accomplish something without knowing what method you’re invoking?
I’m glad Sam Ruby is contributing to the SOAP/REST discussion. As a leader in the Web services space, his word goes a long way. I’m looking forward to reading his article.
As for “bad advocacy”, I don’t believe that I’m an advocate for REST, at least in the REST/SOAP discussions. I see myself as more of a soothsayer, trying to warn people that the current approach to Web services cannot do what people hope it can do; namely, work on the Internet. But my hope is that the industry understands this soon, because I’d prefer to see it put resources into more fruitful endeavours rather than spending them repeating past mistakes. But if they don’t, then they’ll just have to learn the hard way.
Curmudgeonly yours. 8-)
Spent some time thinking about how the Apache Axis project could support the SOAP 1.2 “Web Method Feature”, the major architectural difference between SOAP 0.9/1.0/1.1, and SOAP 1.2. I’m not sure that many Web services folks understand the implications of this yet, but it’s clear to me that it dispells the notion of SOAP as a layer, which is bound to mess with some software. Layers hide other layers beneath them, but what the Web Method Feature says is that a developer must be aware of which HTTP method they’re using if they’re using SOAP bound to HTTP. Let’s hope they all see it that way too. 8-)
The topic is being discussed on axis-dev now.