Re: The Revenge of the Geeks
Date: Sun, 27 Jan 2013 12:47:07 -0600
Message-ID: <ke3spm$ela$1_at_news.albasani.net>
On 1/27/2013 5:46 AM, Arved Sandstrom wrote:
> 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.
>
IMHO, better is probably not using RPC, if possible, but either way.
> 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.
>
well, maybe.
it is easier for a language which has built-in lists (in the Lisp sense), but these are an uncommon concept in mainstream languages, and if built by library features aren't quite as nice.
for example, in C, I can compose messages like: t=dylist4s("message", dyint(1), dyint(2), dyint(3)); btSendMessage(tgt, t);
and, in the reciever:
t=btRecieveMessage(src);
if(t && dyFormIs(t, "message"))
{ ... }
which *could* always be a bit worse.
in my own language, it is like this:
t=#{#message, 1, 2, 3};
btSendMessage(tgt, t);
...
t=btRecieveMessage(src);
if(t && t[0]==#message) { ... }
for Java, maybe it could be something like:
t=Cons.list(message, 1, 2, 3); //lots of overloads
tgt.sendMessage(t);
...
t=src.recieveMessage();
if((t!=null) && t.formIs("message"))
{ ... }
probably with special Cons and MailBox classes.
> 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.
>
well, this is where the whole "mandatory interop or orders from above" comes in. in such a case, people say what to do, and the programmer is expected to do so.
but, I more meant for cases where a person has free say in the matter.
and, also, a person still may choose an existing option, even if bad, because it is the least effort, or because it is still locally the best solution.
like, rolling ones' own is not required, nor necessarily always the best option, but can't necessarily be summarily excluded simply for sake of "standards", as doing so may ultimately just make things worse overall.
historically there have been cases where standards organizations have made some fairly bad standards, and most everyone else ended up ignoring them (and they largely became forgotten). Received on Sun Jan 27 2013 - 19:47:07 CET