Re: The Revenge of the Geeks
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