The "I hate SOAP" club.



  • I have read articles on SOAP. I am constantly bombarded with information on how awesome it is by our resident open source hippy. I have read technical articles on how awesome it is. I have been told it is "better" than COM+. Its is apparantly a drop-in replacement for various technologies from TCP to Quantum Tunneling including the internal combustion engine along the way.

    I hate SOAP.

    My first experiance with SOAP was when the resident hippy at my last workplace (every workplace has one) showed my a thin booklet on "What SOAP Meant to Me". A standard for serialization of objects and remote calls? Fine.

    Apparantly if I make all my distributed applications communicate with SOAP I will make more money. I hate SOAP.

    Let us make it clear now, SOAP is the Simple Object Access Protocol. Not the Miraculous Way of Making My Data One with Everything. That would be the MWMDOE. I should patent that.

    If I dont use SOAP then my enterprise will collapse and I wont be able to communicate with anyone. Also my house will catch on fire. I fucking hate SOAP.

    Anyway, SOAP is just a method of getting data from A, over here to B, over there. Otherwise known as a DCOM transport. In other words it doesnt do anything miraculous such as Pooling, JIT activation, Queued components, etc-fucking-cetera.

    In fact, browsing over to the MSDN the more astute may notice that a COM+ component may be exposed as a SOAP service. Why then is the world going to end if we dont use SOAP?

    Its a standard, which is fine. However I dont see the need to use a crappy XML standard when passing around objects in my internal never-to-be-seen never-should-be-seen backend. I will be sticking with my binary formatters and sticking my head in the sand.

    I will continue to have a good laugh when idiots compare SOAP with things like COM and SQL. Having a cool protocol which uses cool XML is not a distributed applications framework. That said, these statements generally come from the people who think MySQL is a real database ;)

    I shall continue to hate SOAP. I dont care for XML too much either.



  • @phx said:

    these statements generally come from the people who think MySQL is a real database

    That sort of comment usually ticks off the average poster in theDailyWTF. Personally, I don't care either way. As long as the stupid thing works and does as it's told.

    As far as XML goes, I too have a bone to pick with it.

    I'm sick and tired of all these people commenting that XML is this "savior" of the programming world. The way they talk about it, you would think it was the late 90s all over again.

    I prefer to think of XML as HTML on crack. That puts it into perspective for me.



  • I don't know what's your trouble. SOAP is an interesting protocol if
    you need multiple systems to communicate with one another. It helps
    with the development in client-server situation since one developer can
    focus on the client application while the other works on the server
    application. And they can basically use two whole different languages
    to write their code. SOAP is like the HTTP protocol that you use for
    your webbrowser. The only difference is that HTTP is used to transfer
    HTML pages that are information for people and SOAP is used to transfer
    XML which is just data for computers.

    It's just a very generic way of transferring data from one place to
    another, and in my opinion a lot nicer than those CSV or fixed-length
    text files from the past.



  • I think it just depends on the language you've used to write your SOAP
    server stuff. If you're using Java on the serverside then yes, you
    deserve to be shot for creating snail applications.



    Anyway, when you are creating server applications that need an open
    protocol for clients then you have not much choice. You need something
    that's based on an ASCII-text system to send stuff over between client
    and server. Sure, you can use a comma-separated format or define your
    own cryptic code but hey... XML is pretty easy to understand for
    everyone.

    So basically, to communicate between client and server, all you need to
    do is send some text over. The XML format is very well-suited for this.
    And once you start sending XML data between client and server then
    you're getting pretty close to the SOAP protocol already.



    The biggest advantage of SOAP is of course that you don't need to open
    some weird port in your TCP/IP communications. You just use port 80,
    which is used for HTTP communications. As a result, no need to modify
    some setting in your firewall. Whatever client/server application you
    create, it will be able to communicate through almost any connection,
    both internet and intrAnet. No need for all kinds of complex setups
    either.



  • The real advantage of SOAP (not as a protocol or a particular format)
    is that it is a standard, with a standard means of discovery and
    implementation, and no particular platform preference. Yes, it is
    verbose. Yes, it is slower than a native RPC would be. There is
    absolutely no question that there are a thousand and one ways of doing
    the same thing better-stronger-faster in a closed system. But that's
    where the alternatives fall down -- when you have to open the system
    up. All you need is one component of an application on a box you can't
    control to bring a large system down. Direct RPC (COM, COM+, DCOM) is
    system-dependant -- what if the underlying OS changes? CORBA/IIOP
    depends (to an extent, at least) on JVM versions. A text-only exchange
    on a standard carrier protocol is the only safe way to do huge,
    interorganisational, platform-agnostic applications. As long as the API
    remains stable, EVERYTHING else can change -- and your slice of the pie
    doesn't even have to be aware of the changes.



    That being sais, if this is Windows talking to itself within an
    enterprise, the gains are a bit more questionable. SOAP is not, of
    course, a panacea. What you really need is SOAP and WATER (Ways Around
    The Executive Recitative -- similar to the early "Mifwick Deflector"; a
    means to ignore the buzzword chorus while keeping the boss happy).



  • I agree that the cases for using SOAP are best for opening your
    applications/data to the outside world, and not very useful for solely
    internal needs.



    I'm beginning to get quite font of just plain old XMLHTTP.  No
    authentication layer, but simple to write / maintain, and plenty
    fast.  It can be quite powerful when combined with XSLT, depending
    on requirements...






  • Katja wrote:
    "Anyway, when you are creating server applications that need an open
    protocol for clients then you have not much choice."



    Er, yes you do. There's XML-RPC, REST, and CORBA may sometimes be an option.



  • "I shall continue to hate SOAP"



    You're French, aren't you? [:D]



    SOAP has its place, that place is not for passing data around internal
    processes. There's some arguement  for using it between seperate
    tiers, depending on the type of transaction, the tier architecture and
    the placement of the tiers. You wait till someone at your company gets
    bitten by SOA. Or Indigo.



  • Ok I have no idea what happened to my post font size. I'm going to blame the awful firefox support.



  • Something <FONT size=1>is</FONT> happening <FONT size=1>to</FONT> my <FONT size=1>font</FONT> size...<FONT size=1>help</FONT> me <FONT size=1>please!</FONT>



  • <FONT style="BACKGROUND-COLOR: #efefef">Well, I like SOAP. It keeps me clean. [:P]</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">But seriously, I've used soap in one of my company's products, and it works well. There are a few things to be careful about though. If you use SOAP with an activeX component in the browser, you should be sure not to be downloading any images at the same time, or the whole thing becomes confused (note, this may be an issue with MS's implementation of SOAP, not with SOAP an sich).</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">Drak</FONT>



  • re: You're french, aren't you?



    ROFL x 10




  • This is a good time to ask Katja a question.

    It is common knowledge that French people do not bathe. (This may apply to Belgians as well.)

    Do people in the Netherlands bathe regularly? And please define "regularly" (i.e. once a week, once a month, etc.)...



  • CPound, would you kindly make a thead dedicated to Katja so we dont have you spamming the fuck out of every thread here with your inane questions?

    French? ROFL * 10 :D

    I'm sure Alex will support Firefox when they get a little more than 5% of the browser market ;)



  • @phx said:

    CPound, would you kindly make a thead dedicated to Katja so we dont have you spamming the fuck out of every thread here with your inane questions?

    I can't take criticism very well, so here goes...

    Phx: I did not appreciate you using the phrase "spamming the fuck"...and it was also very rude for you to call my questions "inane".

    You bastard.

    Now I feel much better. [:D]



  • @KoFFiE said:

    It's also common knowledge that US citizens only have 2 braincells... *sigh*

    [:'(]



  • He does sorta have a point CPound, however rudely put..  You do tend to start up Katja discussions in several threads.



    This particular case is debateable, as it does sorta follow the topic thread...



    It depends on whether you interpret it as:

    Soap -> Bathing -> French -> Other Cultures

    or

    Soap -> Bathing -> French -> Katja

    or

    anything else that I didn't list above that comes to mind.






  • @CPound said:

    Do people in the Netherlands bathe regularly? And please define "regularly" (i.e. once a week, once a month, etc.)...

    Well, at least I do... Every morning when I get up, I take a shower, so I'd say daily.

    And once I'm done using soap in the shower, I sometimes study SOAP behind the computer. It's very interesting... You should use it too, one day... [:P]



  • Yes, SOAP is crap.



    It's not simple, it's not object-oriented, not extensible, slow, way
    too complicated for what it tries to achieve, it tries to re-invent HTTP on top of HTTP and it's hard to debug. Plus WSDL
    hardly ever works out of the box when you use 2 different
    implementations.



    It seems to me  just about the worst combination of HTTP, XML and RPC anyone could have imagined.



    In other words, it's about as crappy as the XML DOM, and like the DOM,
    the only thing for it, is that it's more or less standard and
    cross-language.




  • Betreft: Re: The "I hate SOAP" club.

    >
    It seems to me  just about the worst combination of HTTP, XML and RPC anyone could have imagined.



    Simple question. Do you have any better solution then? Basically, SOAP
    is nothing more than a simple protocol so a client application can
    exchange data with a server application through simple HTTP messages.
    The best thing of SOAP is that you basically only need an HTTP server
    to use it. It's not platform-specific, it's not processor-specific. And
    it's an open standard.



    SOAP might be slow in your opinion, but basically it's just a
    webbrowser-technique for applications, instead of a webbrowser for
    people.

    Sure, you could send the data over as simple HTML pages but then you
    often send more that you really need in the client. You'd be sending
    over markup settings, font styles and perhaps even a few images while
    all an application is interested in is pure data.

    Or send it over as a plain comma-separated text format. Or whatever
    other cryptic text format has your preference. Just makes it a lot
    harder for the client and server to communicate with one another since
    they both have to be able to read that format.



    No, the problem with SOAP is that people have these huge tables with
    10.000 records inside and they want to send over all 10.000 records to
    the client. Now, THAT will slow it down considerably. But any
    client-server technique will slow down because this kind of stupidity.
    It is okay for a simple desktop application to just select everything
    and show it to the user, but in client-server applications, this is
    plain stupid.

    Now, SOAP can be a pretty fast solution, and also reasonable easy to
    implement with the right tools. Unfortunately it's a new standard. As a
    result, some companies create tool that supposedly support SOAP but
    they don't follow the standard or it's full with bugs. Borland had this
    problem with Delphi 7, where they had problems with boolean fields,
    dates and some special WSDL formats that Delphi just couldn't
    understand. With booleans, Delphi didn't use all lowercase for the
    values 'false' and 'true'. With dates, Delphi just used the date format
    as defined by the Windows settings. And WSDL? Don't get me started
    about that in Delphi. As a result, a Delphi SOAP server can only really
    talk with a Delphi SOAP client. But when they do, they do this pretty
    fast...



  • @Katja Bergman said:

    >

    Simple question. Do you have any better solution then? Basically, SOAP
    is nothing more than a simple protocol so a client application can
    exchange data with a server application through simple HTTP messages.




    My argument is that the SOAP messages are far from simple, and that the S in SOAP is just clever marketing.



     The best thing of SOAP is that you basically only need an HTTP server to use it. It's not platform-specific, it's not processor-specific. And it's an open standard.


    I agree with you there.


    SOAP might be slow in your opinion, but basically it's just a webbrowser-technique for applications, instead of a webbrowser for people.


    Why then, do you need an XML parser just to process a request? We don't usually need them when we write dynamic pages for web-browsers - sometimes an XML formatted request might be a good idea (when you've got loads of data in the request, and it needs to be extensible), but usually that's 100% wasted CPU time.

    Look at the google API. 21 lines of XML to do a 3 word query that a browser can do with a single GET request? Why oh why oh why?

    this article is interesting:
     http://webservices.xml.com/pub/a/ws/2002/04/24/google.html



    Sure, you could send the data over as simple HTML pages but then you often send more that you really need in the client.


    depending on the kind of data returned, XML might be a good choice, however...


    Or send it over as a plain comma-separated text format. Or whatever other cryptic text format has your preference. Just makes it a lot harder for the client and server to communicate with one another since they both have to be able to read that format.


    CSV data is not as easy to parse as most people think, but XML is a lot harder - that's why we have code libraries. Anyway, if you have data that is obviously just a list of records, using CSV will dramatically reduce the amount of network traffic and time spend parsing the result.


    No, the problem with SOAP is that people have these huge tables with 10.000 records inside and they want to send over all 10.000 records to the client. Now, THAT will slow it down considerably. But any client-server technique will slow down because this kind of stupidity. It is okay for a simple desktop application to just select everything and show it to the user, but in client-server applications, this is plain stupid.


    I agree.


    Now, SOAP can be a pretty fast solution, and also reasonable easy to implement with the right tools. Unfortunately it's a new standard. As a result, some companies create tool that supposedly support SOAP but they don't follow the standard or it's full with bugs.


    SOAP isn't that new. I think one of the reasons there is still lots of imcompatible code, is because it's just too complicated. Especially, when you're using WSDL.





  • Betreft: Re: Betreft: Re: The "I hate SOAP" club.

    @joodie said:

    My argument is that the SOAP messages are far from simple, and that the S in SOAP is just clever marketing.

    Marketing by whom? SOAP is just an open standard. And even before Microsoft started messing with it, it was already supported by Java in some basic way. Java is still a popular language to use with SOAP because you can create a client-side java applet that communicates with a server-side SOAP/Java thing and thus be fully platform-independant. It's just not very fast, even if you're exchanging just data...

    @joodie said:

    Why then, do you need an XML parser just to process a request? We don't usually need them when we write dynamic pages for web-browsers - sometimes an XML formatted request might be a good idea (when you've got loads of data in the request, and it needs to be extensible), but usually that's 100% wasted CPU time.

    Actually, as XML starts to get more popular, XML parsers will just be part of whatever development library that you're using. And if you develop for Windows, you already have the MSXML type library available for your use. Which you could even invoke from your ASP webpages.

    @joodie said:

    Look at the google API. 21 lines of XML to do a 3 word query that a browser can do with a single GET request? Why oh why oh why?

    How many lines of code would you need to write "Hello, World." on your screen in Assembler? It's not the number of lines that matter. You're typically a guy, you think size matters... [:P]

    @joodie said:

    this article is interesting:
     http://webservices.xml.com/pub/a/ws/2002/04/24/google.html

    Yes, it is interesting. But what's your point? So SOAP requires a few more lines? Considering the amount of data that is sent over, it is still a pretty small packet. Besides, the people at Google are also still learning how to use this technique. SOAP itself is a reasonable new standard, although it is based upon some older techniques.

    @joodie said:
    depending on the kind of data returned, XML might be a good choice, however...

    Yea, but basically you need some kind of protocol that tells the server it should return something as XML instead of HTML or whatever. SOAP is such a protocol. By wrapping things in a SOAP envelope it becomes much clearer to the server about what to do with some request. The URL itself tells where it should be delivered and the envelope itself provides the required information that is required at that point. The server itself doesn't have to know anything about SOAP. It just needs to know how to pass it on.

    @joodie said:

    CSV data is not as easy to parse as most people think, but XML is a lot harder - that's why we have code libraries. Anyway, if you have data that is obviously just a list of records, using CSV will dramatically reduce the amount of network traffic and time spend parsing the result.

    The problem with CSV is when you have to deal with different kind of data records. Say, for example, that you're trying to send an invoice from client to server. One client who orders several things at the same time and who gets a discount calculated over the whole amount. You'd need to tell in some way who the client is, the items he ordered, the quantity of every item he ordered, the price for each item perhaps and of course the discount that he gets. And maybe a few more things too. Try to fit that in a single CVS file.

    There was a solution for this, btw. It's called EDI. But that's a file format with fixed definitions that you just can't change just like that. A real nightmare format if I can believe my dad. With XML it's just easier. You define a schema and provide this schema to the other side. There they can build their application to accept any messages that matches this schema or they use an XML mapping tool to map your schema format to their preferred schema format.

    It just makes it easier to agree on file formats...

    @joodie said:

    SOAP isn't that new. I think one of the reasons there is still lots of imcompatible code, is because it's just too complicated. Especially, when you're using WSDL.

    The SOAP standard is pretty new, although it has taken a while before it became a standard. I think SOAP became a standard in 2002 or 2003 or so. Before that, several SOAP implementations already existed but it wasn't a full standard yet.



  • @Katja said:



    How many lines of code would you need to write "Hello,
    World." on your screen in Assembler? It's not the number of lines that
    matter. You're typically a guy, you think size matters... [:P]

    I don't quite see your point here. Why do you think assembler isn't the most popular language? We need code that's easy to read and write. SOAP is neither (though I grant that it could be worse).

    Personally, I think using SOAP for the google API is just overkill. Did you notice that they still support a much easier API for RPC, but that that one is only available for paying customers?

    Besides, we're on a network here, so size does matter. You could probably gzip the body of the request and responses, though I'm not sure if that's supported by the available soap implementations.

    @Katja said:


    @joodie said:
    depending on the kind of data returned, XML might be a good choice, however...

    Yea, but basically you need some kind of protocol that tells the server it should return something as XML instead of HTML or whatever. SOAP is such a protocol. By wrapping things in a SOAP envelope it becomes much clearer to the server about what to do with some request. The URL itself tells where it should be delivered and the envelope itself provides the required information that is required at that point. The server itself doesn't have to know anything about SOAP. It just needs to know how to pass it on.


    HTTP headers should already tell you what type of data you're getting. SOAP just ignores most of the possibilities of HTTP.

    A SOAP URL and most of the HTTP headers don't determine much in SOAP, and a lot of information that should be passed via HTTP headers (if only to get possible proxies to work correctly) need to be specified in the SOAP envelope too. One URL can be coupled to a hundred different endpoints. Besides, I was talking about data returned. IMO it's much cleaner to have more or less descriptive URLs and matching headers for different requests. But then, I like REST.

    @Katja said:


    @joodie said:
    CSV data is not as easy to parse as most people think, but XML is a lot harder - that's why we have code libraries. Anyway, if you have data that is obviously just a list of records, using CSV will dramatically reduce the amount of network traffic and time spend parsing the result.

    The problem with CSV is when you have to deal with different kind of data records. Say, for example, that you're trying to send an invoice from client to server. One client who orders several things at the same time and who gets a discount calculated over the whole amount. You'd need to tell in some way who the client is, the items he ordered, the quantity of every item he ordered, the price for each item perhaps and of course the discount that he gets. And maybe a few more things too. Try to fit that in a single CVS file.



    That's why I said "if you have data that is obviously just a list of records".

    @Katja said:


    The SOAP standard is pretty new, although it has taken a while before it became a standard. I think SOAP became a standard in 2002 or 2003 or so. Before that, several SOAP implementations already existed but it wasn't a full standard yet.

    I didn't know that. That might indeed explain a few things.



  • I don't get it. What's wrong with ASN.1? Admittedly over the years
    various implementations have been exploited, but some SOAP impls
    already have and will be in the future.



    We don't need XML for something as low-level as this. XML is good as a
    self-defining data storage system, at the price of bloat akin to the
    web moving from text-based to graphics-based to multimedia-based. While
    it'll make the hardware vendors happy, what's the point, as so many
    others have said? If your binary RPC is open and reasonably extensible
    it'll stand the test of time, and if it's a standard like ASN.1, CORBA,
    or COM in windows environs. And don't ever forget - just because
    something is binary doesn't mean it can't be extensible or
    self-documenting, which all three of the above are to as much extent as
    SOAP is.



    Consider that XML's strongest point is human readability and
    editability. Using it as a machine-to-machine interface is a silly
    waste. (And encryption and compression defeat that anyway.)



    And my biggest gripe: It generally uses port 80. So do web services.
    "Hey, we don't have to play with the firewall! Let's not even tell the
    network guys what we're building!" Awesome, you just built an app that
    can no longer be managed independantly of the web server, without a
    terribly expensive new firewall. Congrats, you just built a hole in the
    network big enough to drive a truck full of hackers through. =D



  • I think this is a good read about SOAP, however. I'm not sure about
    their assertion that XML is as fast as slimmer binary - you have a
    webserver and an xml decoder in the way, instead of a C function, and
    my tests show a 2-3x slowdown - but the words about architecture and
    bottlenecks are spot-on.




  • BINNED

    @CPound said:

    (This may apply to Belgians as well.)

    I object! I just took a bath last month!


Log in to reply