Re^4: start over with SOAP in Perl?

...except when it isn't, such as when document/literal encoded - reasonable description here.

You're splitting hairs. :) A function call is simply something to the effect of a receiver getting some information and responding to it. A document/literal encoded message in SOAP is a receiver getting some information, processing it as it sees fit, and responding to it. The differences are semantics. They act the exact same in the general scheme of life, love, and the persuit of beer.

Many of the use cases were fantasy - something vendors where / are hoping to sell in the SOA orgy.

examples? Im curious.

So what's the addressing scheme for? And how did we get to HTTP over SOAP?. Also document / literal style services aren't about calling remote APIs - what you describe is only a subset of SOAP - Encoded / RPC over HTTP.

The endpoint url? It's not required. An engine will ask you for an endpoint, some place to deliver a message. I can route soap over smtp/e-mail and process it as an asynchronous queue. Document passing IS a form of rpc in that the receiving side looks at the message and decides what to do w/ it. the only difference between formal rpc and document passing, is in the nomenclature. In the end, you are sending a message, a message as a document or a message in a more common "function call like document" that warrants a response.

So why HTTP? Why not? Most people were doing RPC (REST and so forth) over various protocols. HTTP is most popular. Again, SOAP is a format protocol for messages, documents and what not. It's not reliant on networking or anything of that nature.

I know where you're coming from but in the end that's the illusion of SOAP - it feels good when everything "just works" like this. But the moment it doesn't, you got a huge stack of code to debug + verbose wire formats (can you do XSD by hand?). And with networks involved, there are a lot of things that can go wrong. And have mercy the moment you need to scale to anything but low volume Intranet / Extranet interfaces...

All generalizations are wrong. Sadly, I've done debugging on soap interfaces when something has gone wrong, either a bug in a toolkit, or something jsut didn't feel right. Once you know how, it's easy. Learn soap, learn soap toolkits, and basic soap debugging, and it becomes portable. Sorry, this "illusion" and "bullshit" (from earlier) is subjective.

It's got error handling, a trace of the "raw" HTTP conversation and it gives you an instant data structure to examine. It's relatively easy to extend this to support conditional GETs and you're already on your way to preserving bandwidth / scaling.

That's nice you can dump the content of an XML feed, but now you need to execute an XML parser over it and examine the XML content. Also, you have to format the url. In a soap-esq ay, I would do something like

$pm->set_target("http://perlmonks.org")
$pm->get_node(333)
$pm->get_node(334)
$pm->get_node(335)
[download]

We can argue the ins and outs of this ad infinitum but from my perspective, simple always wins.

Not arguing who's right, who loses and all that BS. This is computer engineering and software design. Only thing that wins in the end is what works. If you can use REST, great. Awesome. I know many people who use it successfully. I personally prefer SOAP simply because I don't have to worry about XML parsing, recreating an object model and the likes.

An annecdotal example: I had to work with salesforce.com, a CRM system once. I needed to pull a user's information, and sync it to a local user's records depending on the situation. I got their quickstart document, explaining the calls and the wsdl. Took the WSDL, generated the code and was up to the debugging point within minutes. The debugging points were things like calling their APIs in a certain order, which ones I should use for efficiency, and various other things like trying to divide by zero due to my own stupidity.

Another annecodal example: verisign uses rest. I grabbed their document and started writing code agaist their target url. I reconstructed an object model, by hand, that worked around the data being sent and retrieved. I implemented the communications by hand, parsed the responses by hand and sent out the request, by hand. I was up rather quickly after debugging all the code I wrote.

In the end, I ran into little troubles with either. w/ the SOAP implementatoin, I had LESS code to write and was faster to get working because of the standard. Now, I'm not trying to convince you to use SOAP over REST. Use whatever you wish, it's ok. But please, don't spread misinformation if it can be helped :)

Comment on Re^4: start over with SOAP in Perl? Download Code

Replies are listed 'Best First'.

Re^5: start over with SOAP in Perl?
by harryf (Beadle) on Sep 04, 2006 at 11:16 UTC

OK - calmer / wiser today ;)

"Many of the use cases were fantasy - something vendors where / are hoping to sell in the SOA orgy." examples? Im curious.

Correct to call me - that's gut feeling. What I'm getting at there is I feel many of these evolved as a result of people working on SOAP / WS-* forseeing problems / use cases which no one was already facing / doing in the real world i.e. there was no experience to be applied, lessons learnt in defining the specs. That's in contrast to REST / HTTP.

"So what's the addressing scheme for? And how did we get to HTTP over SOAP?. Also document / literal style services aren't about calling remote APIs - what you describe is only a subset of SOAP - Encoded / RPC over HTTP." The endpoint url? It's not required. An engine will ask you for an endpoint, some place to deliver a message. I can route soap over smtp/e-mail and process it as an asynchronous queue. Document passing IS a form of rpc in that the receiving side looks at the message and decides what to do w/ it. the only difference between formal rpc and document passing, is in the nomenclature. In the end, you are sending a message, a message as a document or a message in a more common "function call like document" that warrants a response.

Was attempting to justify my view that SOAP is protocol in the sense HTTP is a protocol and that SOAP re-invents a bunch of things that already exist. I also see the origins of SOAP (and XML-RPC) as having been fundamentally driven as a mechanism to exploit firewalls - that only port 80 is open, but that's me.

All generalizations are wrong.

Very much agreed - but that defeats the point of ranting ;)

Once you know how, it's easy. Learn soap, learn soap toolkits, and basic soap debugging, and it becomes portable. Sorry, this "illusion" and "bullshit" (from earlier) is subjective.

Agreed again but the learning curve is a problem. I've long since taking SOAP seriously as something I need to follow closely but last time I did, reached the point of being able to hand-code WSDL (pretty much required if you're publishing web services in dynamic languages) and regard myself as generally able, if required.

My (few) first-hand experiences, doing company-to-company interfaces, suggest to me the average developer response to SOAP and web services is a preference to dealing purely in terms of APIs and a lack of interest in understanding what happens behind them (this thread could be a case in point as well). That translates into problem solving of the "it works / it doesn't work" kind - if there's, say, a failing HTTP proxy server between the two endpoints, locating the problem becomes very hard.

More to the point, if responsiblity for SOAP interfaces becomes the job of sysadmins, what are the chances of their being able to isolate problems when the interface "stops working"? For a point-to-point SOAP interface, the answer might be "perhaps" although I'd expect weekend calls to the developers, but if you've got async SOAP messages passing over a number of intemediate systems, identifying why a message failed to reach it's final destination is likely to be a mammoth effort (guessing - no anecdotes). By contrast, figuring out where an email got lost is do-able.

[reply]


Don't ask to ask, just ask
	PerlMonks