Re: The Revenge of the Geeks

From: Arved Sandstrom <asandstrom2_at_eastlink.ca>
Date: Sun, 27 Jan 2013 07:46:58 -0400
Message-ID: <Ss8Ns.125659$Id.2235_at_newsfe24.iad>



On 01/27/2013 12:54 AM, BGB wrote:
> On 1/26/2013 9:11 PM, Arne Vajh°j wrote:
>> On 1/26/2013 8:47 PM, Arved Sandstrom wrote:
>>> On 01/26/2013 04:47 PM, BGB wrote:
>>>> On 1/26/2013 8:12 AM, Arne Vajh°j wrote:
>>>>> On 1/26/2013 12:31 AM, BGB wrote:
>>> [ SNIP ]
>>>>
>>>>>> FWIW: I once messed briefly with XML-RPC, but never really did much
>>>>>> with
>>>>>> it since then, although long ago, parts of its design were scavenged
>>>>>> and
>>>>>> repurposed for other things (compiler ASTs).
>>>>>
>>>>> XML-RPC never really took off. Instead we got SOAP.
>>>>>
>>>>
>>>> I don't really like SOAP...
>>> [ SNIP ]
>>>
>>> I don't know anyone who does, I know I don't. Still, it's what we've
>>> got. For well-designed operations and schemas it's not that verbose, not
>>> appreciably worse than JSON. Having WSDLs and the ability to validate is
>>> useful, although over the years I've come to believe that WSDL-first is
>>> an abomination unless the project is extremely structured and
>>> disciplined.
>>>
>>> SOAP is also - still - the only game in town for various security and
>>> transactional tasks, even if aspects of WS-Security are atrocious. For
>>> true web services I'd use REST almost always, because SOAP actually
>>> isn't much to do with the Web at all. But if I need application
>>> security, encryption of portions of a message, non-repudiation,
>>> transactionality etc,and I'm really doing RPC, I'm using SOAP.
>>
>> Standards are rarely optimal.
>>
>> people are not too happy about HTTP and SMTP either.
>>
>

> well, luckily there is HTTP 2.0 in development, which "should" be a
> little better, at least as far as it will Deflate the messages...
>

> http://en.wikipedia.org/wiki/Http_2.0
> http://en.wikipedia.org/wiki/SPDY
>

> (in contrast to HTTP 1.1, it will multiplex the requests and responses
> over a single socket, and also compress the data).
>
>
>> But a standard is a standard.
>>
>> SOAP got the tools support and all the standards that
>> build on top of it.
>>
>> We can either accept it and live happy with it or invent
>> a time machine and go back to around 1998 and tell a few
>> people from IBM and MS how it should be done.
>>
>

> or just blow it off and do whatever...
>
>

> like, standards are useful so long as they are useful, but otherwise,
> unless there is some greater reason (mandatory inter-op or orders from
> above), why bother?
>

> like, unless is better for the project overall (or otherwise benefits
> the developers in some way), why not just go and do something different?
>

> granted, yes, usually standards are a good thing, but usually these are
> *good* standards. luckily at least, some of the worse offenders here
> have gained the fate they deserve.

>
>
Another note on SOAP: many (I'd say most) of the pain points encountered by a developer are not problems of SOAP itself. You can use a tool like SoapUI to hit WSDLs, and inspect the raw XML being passed back and forth - if the WSDLs and XSDs are well-crafted then the XML requests and responses are quite readable and not particularly verbose.

You'd be better off using SOAP most of the time for RPC-type work then rolling your own.

WS-Security is a different matter. That's complicated for many use cases; you don't even want to look at the typical raw XML for a request. :-) OTOH there is really no other game in town for this aspect.

What really complicates things is the tooling. For Java, you'd probably use Axis or CXF. I no longer like Axis at all, for various reasons, so I've moved to CXF. But even CXF, if you generate your client classes off a WSDL, the verbosity and complexity of the classes is offputting. You have to acquire a fair bit of experience with a language-specific WS framework in order to make generated code half-reasonable to work with. .NET, say with C# as the language, is no better - lots of little gotchas that you just have to be aware of.

So it's not all the fault of SOAP - programming language implementations for developing client and server code complicate matters quite a lot.

Usually in the enterprise world you have little or no leeway as to how systems talk to each other. You may have a few options to choose from, but rolling your own is looked upon askance.

AHS Received on Sun Jan 27 2013 - 12:46:58 CET

Original text of this message