Re: I hate SOAP



  • I'm surprised nobody mentioned XML-RPC yet. It's been around a few years before SOAP, it's way
    simpler, and I think it's supported by more languages (correct me if
    I'm wrong). And who's using it? Mostly nobody. And how about WDDX,
    which is as simple and more general in scope. Have you even heard of
    it? No?



    Of course not. And you know why? Because you don't need it, ever. An
    application-specific XML format will always be more compact and just as
    easy to understand, once you've gone for "the big X". Honestly, "one
    protocol for all communications" is as crappy as "one language for all
    applications".



    Now, if you're forced to use SOAP (because of company policy or something), that's a different kind of WTF...



    Regards




  • Betreft: Re: I hate SOAP

    I think XML-RPC has always been considered a bit too bloated since
    people consider XML to be a bloated file format. But SOAP just became a
    hot topic because it's a simple protocol on top of the HTTP protocol
    that easily allows people do do client-server stuff without having to
    worry about firewalls and configuring ports. It all goes over the
    default HTTP port. (Port 80.)



    Now, XML-RPC still doesn't specify the ports that are used for this
    communication. It just defines what is exchanged between client and
    server but not the actual transport mechanism. Still, XML-RPC is a
    standardized protocol. SOAP is a simple layer on top of this,
    describing how the messages are sent between client and server and how
    they are wrapped into something the server can recognise.



    It's just a protocol, nothing more. It just helps other people to
    define something that can connect to your server without having to know
    many of the details. With XML-RPC they still need to know which ports
    to use, how to configure their firewalls, etc. With SOAP, all they need
    is an URL and the server itself can even provide all the definitions
    they need at the client-side.



    Sure, it has it's limits but at least it forces people to agree on a specific format.



  • @Katja Bergman said:



    Now, XML-RPC still doesn't specify the ports that are used for this
    communication. It just defines what is exchanged between client and
    server but not the actual transport mechanism.




    Actually, XML-RPC is bound to HTTP, just like SOAP. And HTTP doesn't say what port it's supposed to work over.



    @Katja Bergman said:


    It's just a protocol,




    I agree.


    @Katja Bergman said:

    Sure, it has it's limits but at least it forces people to agree on a specific format.





    Well, it's as much a "standard" as the dialect of CSS understood by
    Internet Explorer. It's useful as long as all the parties involved
    agree to use it. The problem is with the marketing people who make
    n00bs believe it's a panacea or something.



    Right?




  • Yup, marketing people believe that if the box of Product A has a golden XML sticker and the box of Product B has a similar golden XML sticker, then Product A and Product B can obviously immediatly communicate data between themselves.

    How many times have I not seen the question on a client questionaire 'Does your product use XML'.

    Yes it does. Internally. But it does use it. So what?

    Grr.. marketing people.

    Drak

     



  • Betreft: Re: Betreft: Re: I hate SOAP

    Actually, if you have two XML-based products then you can easily create a solution that would convert between the two XML formats. All you need is an XML Mapping tool. And all you have to do is tell the mapping tool how to map the data in one XML file to be used in the other application. This is a very generic solution that just doesn't exist for e.g. CSV files or other file formats.

    XML is a good format if you need to exchange data between two different applications because it's a simple standard that defines the whole file structure. My dad told me about one other, similar file format structure called EDI and this format just fails because there are strict specifications that an EDI file has to meet. If you can't put your data into one of the pre-defined EDI schema's then you run out of luck because you're not "allowed" to define your own schema's. But with XML, who cares.

    Are there any better alternatives that offer a way to transport a collection of data between applications? I don't think so.



  • I'd say the best alternative is the one that fits your application. In
    many cases, this can be XML. But it doesn't have to be SOAP. Or
    XML-RPC. Or, say RSS :-) I like following standards too, but not to the
    point of being... I don't know... inflexible? (replace with a softer
    word of your choice). Think of networked games. A game programmer would
    laugh in your face at that last remark.



    Actually... what are we arguing about?




  • Betreft: Re: Betreft: Re: Betreft: Re: I hate SOAP

    I'm not sure... If you create a special server for all kinds of gambling games, a gamemaker could really use SOAP so anyone could create some client application that would use this gambling server for drawing cards and keeping track of the amount of cash gambled away. Of course the owner of the server would get a small percentage of every transaction made through it's system and from there it's profits.

    Too bad it be immediately attacked by dozens of hackers. And worse, any game designer that creates online games (because SOAP isn't useful for offline games) would really hate it that any hacker could easily read all traffic between client and server and possibly even modify it to cheat...

    Game designers definitely dislike people to know anything about the protocols used in their software, because it allows people to start cheating. And especially an online game would be ruined if too many people just cheat all the time...

     

    I think more of banking when I think about SOAP. An SSL connection with the bank server with an additional username and password would make things secure. And the SOAP protocol on the bank server would allow any client to develop their own client applications to get information from the bank. For example, think about a company writing a special application that automatically pays for small transactions. Think about an online site that communicates through SOAP with a bank server to validate creditcard transactions. SOAP would allow companies to just integrate the banks services into their own bookkeeping system. It's that simple.

    Then again, any huge database system that is used by tens of thousands of people every day could use SOAP to provide all those users a simple interface to retrieve the data they want, instead of giving them whatever you think they want.



  • @Katja said:

    Actually, if you have two XML-based products then you can easily create a solution that would convert between the two XML formats. All you need is an XML Mapping tool. And all you have to do is tell the mapping tool how to map the data in one XML file to be used in the other application. This is a very generic solution that just doesn't exist for e.g. CSV files or other file formats.

    This is true, but the point I was trying to make (and failed to) is that even is A and B both speak XML, if their data is incompatible at a base level, they can speak to eachother as much as they want, and it would be like a Greek and a Chinese person trying to make conversation, each not understanding twhat the other is saying. I should have made that clearer in my first post, I apologise.

    Drak

    ps. It's also not too hard to make a CSV conversion utility, as long as you know what will be in the input and what needs to be in the output. Only, there are more readymade tools for XML out there than for CSV.



  • @Katja said:

    Game designers definitely dislike people to know
    anything about the protocols used in their software, because it allows
    people to start cheating. And especially an online game would be ruined
    if too many people just cheat all the time...





    Actually, the problem is with the kind of games that need to pass lots of data back and forth thirty times per second, such as your typical shooter. XML is plain useless in such a context.



    Now, if the game relies on the client program to prevent cheating, that's a WTF, isn't it? :-)




  • @felix said:


    Actually, the problem is with the kind of games that need to pass lots of data back and forth thirty times per second, such as your typical shooter. XML is plain useless in such a context.

    Now, if the game relies on the client program to prevent cheating, that's a WTF, isn't it? :-)

    Ah, but she was talking about gambling games. Those do not require updates as often.Obviously both client and server must prevent cheating, with the server having the last word.

    Drak



  • Betreft: Re: Betreft: Re: Betreft: Re: I hate SOAP

    The problem with a CVS conversion tool compared with an XML convertion
    tool is in general the various interpretations of the CVS format. Some
    people don't use comma's but semi-colons or perhaps even tab
    characters. Then of course there's the use of single quotes, double
    quotes and in some cases no quotes at all. And of course supporting
    different record types in a single CVS file does make it look pretty
    complicated.

    Just assume you need to export a list of today's orders from one
    application and import it in another. You'll have customers with
    master-detail links to the articles they have ordered. So one customer
    could have ordered a dozen or so articles. Doing this in CVS means that
    whatever convertion tool is going to convert it, it needs to know how
    to see the difference between an customer or an article or else you
    have a cheese sandwich that ordered an 'Alex Papadimoulis' or something silly like that. :-)



    With XML you have at least these master-detail layers in your exported data.



    Of course, the whole import/export thing also depends on the mapping
    tool that you use to transform the export file from application A to an
    import format for application B. In general, those convertions aren't
    too difficult either. Often just a matter of changing field names,
    maybe concatenating fields or providing default values for missing
    fields. This process is called mapping and is one of the things my dad
    earns his cash with. [:)] He creates custom mapping tools for specific
    customers who are using those file formats like CVS and EDI, and quite
    a few other custom formats too. But for XML there's some very easy
    mapping tool where you just create a mapping algorithm by drawing lines
    between the fields of both import and output format, and in-between you
    can also define some special actions that need to be done in the
    convertion. Once you've set this up correctly, the system can even
    create C++ sourcecode so you can compile the mapper to an executable
    for your favorite platform and use it. Haven't seen such a tool yet for
    CVS files.

    Which is a good thing, though. My dad earns quite well with these
    custom mapping tools he writes. For him, they're often very simple to
    create yet he can charge quite a bit for writing those tools for his
    customers. [;)] And they'll happily pay him too.



    So, now I think about it... Yeah, darned XML! Everyone, go back to
    using CVS or EDI or whatever other format you like! My dad needs a new
    car again. [:D]

    								</span>

Log in to reply