13 ms·

The S stands for Simple

95 points by 10ren 17y ago

uriel 17y ago
The server seems to be back online, but in case it goes down again (or changes IP or whatever), I have mirrored it here: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
sketerpot 17y ago
Did anybody else hear the SOAP Guy's lines in a voice that sounds like a cross between a used car salesman and Foghorn Leghorn? Also, I like Google's protocol buffers library. It's straightforward, fast, has really nice bindings for C++, Java, and Python, and we know it's stable because it's what Google uses for most of its internal RPC stuff. http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/
- sgk284 17y ago
  Yea, but the PB library doesn't actually handle sending requests over the network, etc... It literally just encodes data. If you like protocol buffers, check out Thrift. Thrift was designed based off of protocol buffers, but handles everything from end to end. http://incubator.apache.org/thrift/ http://incubator.apache.org/thrift/
  - houseabsolute 17y ago
    To be more specific, the protocol buffer library provides an interface for transport, but not the transport layer itself.
- shin_lao 17y ago
  It's a good library, I've used it extensively. I only wish it would generate less warnings at compile time. :)
10ren 17y ago
Interoperability is a vitally important but hard problem. CORBA and then SOAP have been thoroughly adopted, then widely condemned. What's next?
- iamaleksey 17y ago
  REST, Thrift, AMQP + protobuffs.
  - 10ren 17y ago
    http://incubator.apache.org/thrift/ http://incubator.apache.org/thrift/ http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/ Sounds intriguing - can you elaborate on why this combination is favoured in particular? Or point to an article that discusses it? It's hard to get widespread adoption if it's not accessible... incidentally, google protocol buffers seems similar to http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One (ASN.1), which predates XML, but didn't take off.
    - iamaleksey 17y ago
      ASN.1 actually did take off, somewhat, at least in telco. And after comparing thrift to protobuffs to ASN.1 for our internal protocol I ended up chosing ASN.1, mostly because of the great ASN.1 support in the OTP (I'm using Erlang). Erlang protobuffs library, on the other hand, is somewhat lacking and is terrible at encoding/decoding huge messages with big lists. And AMQP was chosen for the transport layer because it handles persistent messages, transactions, all the routing, buffers messages, etc., etc. I'd have to implement all of these myself, had I chosen thrift. This is how I ended up with RabbitMQ and ASN.1.
      - 10ren 17y ago
        Thanks. The long-term trajectory of programming tools seem to favour developer ease over raw efficiency, as computers get faster but programmers don't (though possibly this might change as Moore's Law diverts from speed increases to multi-core). Therefore, XML became more popular than ASN.1. I think the successor to XML (and SOAP etc) will be more human-friendly than XML, rather than more efficient. That's not to say that extremely efficient techniques don't have a place (they do) or they're not cool (they are).
robbed 17y ago
I'm working on some SOAP stuff at work. I think it was a ploy to make me want to quit.
seldo 17y ago
I have to say that SOAP didn't even seem like a good idea at the time.
- blasdel 17y ago
  Dave Winer: Menace, or Monster?
psadauskas 17y ago
Its been my experience that anything with Simple or Lightweight as one of the letters in the acronym is usually anything but.
- kabdib 17y ago
  SNMP, for instance. "The Stupid, it burnnnsss!"
  - gunyoki 17y ago
    Simple doesn't mean Easy.
- dflock 17y ago
  In the same way that the old communist states often had both 'democratic' and 'republic' in their over-long official names. Hmm, LDAP. I'd hate to meet HDAP.
  - samuel 17y ago
    LDAP is "Lightweight" only when compared with X.500..
- balakk 17y ago
  S3 , SimpleDB are not all that bad.
  - blasdel 17y ago
    ...except when called via SOAP!
- gjm11 17y ago
  This is part of a general principle that things with feelgood adjectives in their names usually don't really merit them.
three14 17y ago
If you know that you're only going to be using the Microsoft stack, and you actually do get to use the tools that cover all this up, do you still end up regretting that there's SOAP under all of it? I've just found myself working on a project like that for the first time, and saw this, and started wondering.
- steve_g 17y ago
  If both ends of the communication are on the Microsoft stack, setting up SOAP webservices is straightforward. The tools basically take care of everything. In our case, we have a customer who exposed an ASP.NET webservice that we consume (data flows in both directions). Our production apps use VB.NET to hit the webservice, but I was able to easily write a python client for testing (by handrolling the SOAP messages). My intuition is that SOAP starts becoming unpleasant if you have lots of parties involved and/or multiple platforms. We haven't hit that wall.
  - flatline 17y ago
    Well, yeah, except you used to be able to throw up an endpoint as an asmx file and it just sort of worked. Now you are guided to create a separate WCF application. So you get a book on WCF and start reading. You create a "hello, world" app but it takes three days of playing with the config file and reading half of MSDN to get it to work. Now that you know all kinds of stuff about message and service contracts, you can't do things like pull the raw HTTP headers because it's not necessarily bound to HTTP (who's using those other protocols, again?) And, you can't latch on to just any point in the request handling because it may be any sort of request. Another week with MSDN and you've finally gotten something kind of close to what you want, which involves running with aspNetCompatibility and might as well just have been an asmx endpoint, and which would have taken about half a day's work with the old toolkit. Not that I would know from personal experience.
  - panic 17y ago
    Part of me wonders whether this difficulty of interoperation is intentional on the part of Microsoft.
csytan 17y ago
Using the Q & A style to introduce a topic works really well. I hope more people start writing like this.
- mnemonik 17y ago
  If you like this you should read The Little Schemer (if you haven't yet, that is) it is written in dialogue/question-answer format. Very Socratic method. I can't recommend the rest of the series; I haven't read them yet. The Little Schemer is excellent though.
- jrnkntl 17y ago
  This method clearly made me understand (and a lot of my fellow Media studies students) the whole Actor-Network theory of Bruno Latour and writing for academic papers in general. "A prologue in form of a dialog between a Student and his (somewhat) Socratic Professor" http://www.bruno-latour.fr/articles/article/090.html http://www.bruno-latour.fr/articles/article/090.html
- StrawberryFrog 17y ago
  Like knocking down straw men? I hope not.
papaf 17y ago
I'm sure I've had this conversation in real life :-) My one experience with SOAP was trying to get a perl client library working with a Java server -- they weren't compatible with each other. In the end I used ethereal with a Java client and dumped the request which I could then replay through perl. In fact, I would go as far to say SOAP is the least fun protocol that I've ever used (including an undocumented one).
- zaphar 17y ago
  My one SOAP exerience was similar but I ended up using LWP and creating my own serializer then they upgraded from .net 1.1 to .net 2.0 and it all broke again. I hated SOAP from then on.
mgrouchy 17y ago
I can identify with this totally. This was my life like 4 months ago before I started at the startup I am working at now. Trying to write these schemas by hand IS hell, but putting blind trust in your toolbox is possibly even worse.
StrawberryFrog 17y ago
A few notes The "SOAP Guy" sounds rather like a straw man to me. I'd like to hear what a real soap guy has to say. Though I don't know if there is such a guy any more. Soap is just a transport format. Any WCF (http://en.wikipedia.org/wiki/Windows_Communication_Foundation http://en.wikipedia.org/wiki/Windows_Communication_Foundatio...) guys around? We use WFC between .Net programs, and once you connect to the right endpoint, it pretty much just works. You may have a look at the generated WSDL to see if it's sensible, but for the most part, it is "just plumbing. You don’t need to see it." We're not stupid enough to try to get WCF and SOAP to interop with other languages, though. We'd probably look at using ActiveMQ, or XML and URLs for that kind of job. Also the statement that "no one actually uses these other transports" is not true - we use TCP transport in some cases, and it's not that unusual. There are parts - large parts - of the spec (see the WS-* stuff, e.g. http://en.wikipedia.org/wiki/List_of_Web_service_specifications#Messaging_Specification http://en.wikipedia.org/wiki/List_of_Web_service_specificati...) which very few people use or care about, which would probably make full-blooded interop with other stacks very hard. It's sad that we didn't get there yet, but I'm glad that we've got what we do have. In some cases REST is better. Even MS knows this. See http://msdn.microsoft.com/en-us/data/bb931106.aspx http://msdn.microsoft.com/en-us/data/bb931106.aspx
- StrawberryFrog 17y ago
  And another thing: the article complains that 1) SOAP sucks and 2) It keeps changing. There's some merit to both those charges, but change is a legitimate response to something not being right yet. What's the alternative? Not sure why I'm getting downvotes. Its possible that I'm wrong, but it's a more substantial answer than most comments on this topic. I'd like to hear your point of view. Or are only "LOL I agree soap sucks" comments encouraged?

95 points by 10ren 17y ago

uriel 17y ago

The server seems to be back online, but in case it goes down again (or changes IP or whatever), I have mirrored it here: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple

sketerpot 17y ago

Did anybody else hear the SOAP Guy's lines in a voice that sounds like a cross between a used car salesman and Foghorn Leghorn? Also, I like Google's protocol buffers library. It's straightforward, fast, has really nice bindings for C++, Java, and Python, and we know it's stable because it's what Google uses for most of its internal RPC stuff. http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/

sgk284 17y ago
Yea, but the PB library doesn't actually handle sending requests over the network, etc... It literally just encodes data. If you like protocol buffers, check out Thrift. Thrift was designed based off of protocol buffers, but handles everything from end to end. http://incubator.apache.org/thrift/ http://incubator.apache.org/thrift/
- houseabsolute 17y ago
  To be more specific, the protocol buffer library provides an interface for transport, but not the transport layer itself.
shin_lao 17y ago
It's a good library, I've used it extensively. I only wish it would generate less warnings at compile time. :)

10ren 17y ago

Interoperability is a vitally important but hard problem. CORBA and then SOAP have been thoroughly adopted, then widely condemned. What's next?

iamaleksey 17y ago
REST, Thrift, AMQP + protobuffs.
- 10ren 17y ago
  http://incubator.apache.org/thrift/ http://incubator.apache.org/thrift/ http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/ Sounds intriguing - can you elaborate on why this combination is favoured in particular? Or point to an article that discusses it? It's hard to get widespread adoption if it's not accessible... incidentally, google protocol buffers seems similar to http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One (ASN.1), which predates XML, but didn't take off.
  - iamaleksey 17y ago
    ASN.1 actually did take off, somewhat, at least in telco. And after comparing thrift to protobuffs to ASN.1 for our internal protocol I ended up chosing ASN.1, mostly because of the great ASN.1 support in the OTP (I'm using Erlang). Erlang protobuffs library, on the other hand, is somewhat lacking and is terrible at encoding/decoding huge messages with big lists. And AMQP was chosen for the transport layer because it handles persistent messages, transactions, all the routing, buffers messages, etc., etc. I'd have to implement all of these myself, had I chosen thrift. This is how I ended up with RabbitMQ and ASN.1.
    - 10ren 17y ago
      Thanks. The long-term trajectory of programming tools seem to favour developer ease over raw efficiency, as computers get faster but programmers don't (though possibly this might change as Moore's Law diverts from speed increases to multi-core). Therefore, XML became more popular than ASN.1. I think the successor to XML (and SOAP etc) will be more human-friendly than XML, rather than more efficient. That's not to say that extremely efficient techniques don't have a place (they do) or they're not cool (they are).

robbed 17y ago

I'm working on some SOAP stuff at work. I think it was a ploy to make me want to quit.

seldo 17y ago

I have to say that SOAP didn't even seem like a good idea at the time.

blasdel 17y ago
Dave Winer: Menace, or Monster?

psadauskas 17y ago

Its been my experience that anything with Simple or Lightweight as one of the letters in the acronym is usually anything but.

kabdib 17y ago
SNMP, for instance. "The Stupid, it burnnnsss!"
- gunyoki 17y ago
  Simple doesn't mean Easy.
dflock 17y ago
In the same way that the old communist states often had both 'democratic' and 'republic' in their over-long official names. Hmm, LDAP. I'd hate to meet HDAP.
- samuel 17y ago
  LDAP is "Lightweight" only when compared with X.500..
balakk 17y ago
S3 , SimpleDB are not all that bad.
- blasdel 17y ago
  ...except when called via SOAP!
gjm11 17y ago
This is part of a general principle that things with feelgood adjectives in their names usually don't really merit them.

three14 17y ago

If you know that you're only going to be using the Microsoft stack, and you actually do get to use the tools that cover all this up, do you still end up regretting that there's SOAP under all of it? I've just found myself working on a project like that for the first time, and saw this, and started wondering.

steve_g 17y ago
If both ends of the communication are on the Microsoft stack, setting up SOAP webservices is straightforward. The tools basically take care of everything. In our case, we have a customer who exposed an ASP.NET webservice that we consume (data flows in both directions). Our production apps use VB.NET to hit the webservice, but I was able to easily write a python client for testing (by handrolling the SOAP messages). My intuition is that SOAP starts becoming unpleasant if you have lots of parties involved and/or multiple platforms. We haven't hit that wall.
- flatline 17y ago
  Well, yeah, except you used to be able to throw up an endpoint as an asmx file and it just sort of worked. Now you are guided to create a separate WCF application. So you get a book on WCF and start reading. You create a "hello, world" app but it takes three days of playing with the config file and reading half of MSDN to get it to work. Now that you know all kinds of stuff about message and service contracts, you can't do things like pull the raw HTTP headers because it's not necessarily bound to HTTP (who's using those other protocols, again?) And, you can't latch on to just any point in the request handling because it may be any sort of request. Another week with MSDN and you've finally gotten something kind of close to what you want, which involves running with aspNetCompatibility and might as well just have been an asmx endpoint, and which would have taken about half a day's work with the old toolkit. Not that I would know from personal experience.
- panic 17y ago
  Part of me wonders whether this difficulty of interoperation is intentional on the part of Microsoft.

csytan 17y ago

Using the Q & A style to introduce a topic works really well. I hope more people start writing like this.

mnemonik 17y ago
If you like this you should read The Little Schemer (if you haven't yet, that is) it is written in dialogue/question-answer format. Very Socratic method. I can't recommend the rest of the series; I haven't read them yet. The Little Schemer is excellent though.
jrnkntl 17y ago
This method clearly made me understand (and a lot of my fellow Media studies students) the whole Actor-Network theory of Bruno Latour and writing for academic papers in general. "A prologue in form of a dialog between a Student and his (somewhat) Socratic Professor" http://www.bruno-latour.fr/articles/article/090.html http://www.bruno-latour.fr/articles/article/090.html
StrawberryFrog 17y ago
Like knocking down straw men? I hope not.

papaf 17y ago

I'm sure I've had this conversation in real life :-) My one experience with SOAP was trying to get a perl client library working with a Java server -- they weren't compatible with each other. In the end I used ethereal with a Java client and dumped the request which I could then replay through perl. In fact, I would go as far to say SOAP is the least fun protocol that I've ever used (including an undocumented one).

zaphar 17y ago
My one SOAP exerience was similar but I ended up using LWP and creating my own serializer then they upgraded from .net 1.1 to .net 2.0 and it all broke again. I hated SOAP from then on.

mgrouchy 17y ago

I can identify with this totally. This was my life like 4 months ago before I started at the startup I am working at now. Trying to write these schemas by hand IS hell, but putting blind trust in your toolbox is possibly even worse.

StrawberryFrog 17y ago

A few notes The "SOAP Guy" sounds rather like a straw man to me. I'd like to hear what a real soap guy has to say. Though I don't know if there is such a guy any more. Soap is just a transport format. Any WCF (http://en.wikipedia.org/wiki/Windows_Communication_Foundation http://en.wikipedia.org/wiki/Windows_Communication_Foundatio...) guys around? We use WFC between .Net programs, and once you connect to the right endpoint, it pretty much just works. You may have a look at the generated WSDL to see if it's sensible, but for the most part, it is "just plumbing. You don’t need to see it." We're not stupid enough to try to get WCF and SOAP to interop with other languages, though. We'd probably look at using ActiveMQ, or XML and URLs for that kind of job. Also the statement that "no one actually uses these other transports" is not true - we use TCP transport in some cases, and it's not that unusual. There are parts - large parts - of the spec (see the WS-* stuff, e.g. http://en.wikipedia.org/wiki/List_of_Web_service_specifications#Messaging_Specification http://en.wikipedia.org/wiki/List_of_Web_service_specificati...) which very few people use or care about, which would probably make full-blooded interop with other stacks very hard. It's sad that we didn't get there yet, but I'm glad that we've got what we do have. In some cases REST is better. Even MS knows this. See http://msdn.microsoft.com/en-us/data/bb931106.aspx http://msdn.microsoft.com/en-us/data/bb931106.aspx

StrawberryFrog 17y ago
And another thing: the article complains that 1) SOAP sucks and 2) It keeps changing. There's some merit to both those charges, but change is a legitimate response to something not being right yet. What's the alternative? Not sure why I'm getting downvotes. Its possible that I'm wrong, but it's a more substantial answer than most comments on this topic. I'd like to hear your point of view. Or are only "LOL I agree soap sucks" comments encouraged?