• Anonymous (unregistered)

    TRWTF is flailing around with the abomination that is SOAP instead of using a RESTful interface.

  • (cs) in reply to Anonymous
    Anonymous:
    TRWTF is flailing around with the abomination that is SOAP instead of using a RESTful interface.
    Spoken by someone who's development environment doesn't have good SOAP support. SOAP's design-time support is it's advantage. REST is a simple concept that is easy to implement manually, but SOAP formalizes the service contract to the point where proper client side code can be generated. If you have a crappy development environment, the difference is academic. With a good development environment, SOAP is a wonderful thing.
  • Johnny Sutherland (unregistered)

    I have to use a web service from a third party (a relatively well know company) which only accepts the soap message in this format. One can guess how much time we spent before discovering this!

  • The Flaming Foobar (unregistered) in reply to savar
    SOAP is so unwieldy, then why are you using it?

    No one writes their own SOAP implementation. Getting JAX-WS to work is easy. Using PHP SoapClient/SoapServer is even easier. You never even see the XML.

    Now, try to define a JAX-WS service which interfaces nicely with the PHP implementation, and you'll be banging your head to the wall for a week. You'll probably end up abandoning SOAP completely, or do something like the ProcessMessage() interface above.

  • (cs) in reply to xunda
    xunda:
    The real WTF is to use SOAP and expect the resulting interfaces to be sane.

    Hmmmm, no my dear colleague.

    I gotta disagree with that one. I rather use POX or some other simpler thing over SOAP any day, BUT to imply one cannot expect sane interfaces with SOAP, that's a bit of a stretch. If one were to follow some fundamental principles (applicable to SOAP and non-SOAP services alike) - namely KISS, JRTFM among others - it is not that difficult to come up with stable, sane interfaces (provided the underlying business processes are not f* up beyond a certain level.)

    SOAP. Verbose, certainly. Workable and sane, certainly as well (as competent people have done so and still do all the time.)

    Verbosity == pain in the ass? Yes. Verbosity == inevitable wtfery? No.

    People f* up with SOAP, and they also f* up with POX and just about anything they lay their hands on to build systems with.

    SOAP is a PITA to work on, but some of the sanest implementations to complex interfaces I've seen have been with SOAP. And I cannot stress this enough (and someday I'll submit a story to tdwtf with code samples and all) that the worst piece of sh* system I've ever seen was a relatively simple set of interfaces using plain-ol-xml (POX), XML so badly malformed, it was not even parseable (yes, it is possible to crap out such a thing.)

    Developers and architects that come with this kind of crap (XML'd XML and similar misbegotten monstrosities) typically display an utter lack of fundamental skills in manners that are typically technology agnostic.

  • Anonymous (unregistered) in reply to Jaime
    Jaime:
    Anonymous:
    TRWTF is flailing around with the abomination that is SOAP instead of using a RESTful interface.
    Spoken by someone who's development environment doesn't have good SOAP support. SOAP's design-time support is it's advantage. REST is a simple concept that is easy to implement manually, but SOAP formalizes the service contract to the point where proper client side code can be generated. If you have a crappy development environment, the difference is academic. With a good development environment, SOAP is a wonderful thing.
    Yeah, SOAP's great. So great that every vendor decided to invent their own implementation. But that's obviously no problem for you, with your magical vendor-neutral development environment.
  • Andreas (unregistered)

    This ist not a WTF, but how SOAP works. I designed our interfaces the same way: There is a standardized xml-format that you can parse and that allows you to detect the content-type. After knowing the content-type you can use a specialized XML-Parser for that.

    Definitely no WTF there!

  • (cs)

    This reminds me of what I found out yesterday about Ubuntu's method of distributing source code. It consists of the original source code plus a patch. The patch does nothing but create a whole subdirectory tree called 'debian' which contains, among other things, a set of patches to the actual files.

    Sure it's more flexible this way, and I'm aware of some reasons for doing things this way, but it sure took me some time to figure out what was going on.

  • Colin (unregistered)

    I've had this same exact thing happen to me. The vendor couldn't understand that you didn't have to encode the inner XML... Let just say it was an interesting project.

  • coder12345 (unregistered)

    Our customer also does that, but the main XML contains a version number attribute so their webservice endpoint can handle many different versions of their XML.

    It is fubar but they can use the same url for all versions which they think is worth the trouble encoding/decoding.

  • abico (unregistered)
    instead of returning something useful, it returns this XML string
    FTFY
  • Luiz (unregistered)

    Why use these fancy webservices if you can just send bytes and receive bytes in ssl port using old sane tcp socket, no router will ever notice the diference.

  • David Mårtensson (unregistered) in reply to Brad Davis
    Brad Davis:
    Yeah, this isn't a WTF. One of the most common reasons for doing something like this is so you can extract the XML, create a standalone DOM from it and validate it against a schema. This is much harder to do if the piece you want to validate is actually just a node in a SOAP envelope. The point is that the encoded XML document is logically distinct from the soap envelope and even the response wrapper, so there's no good reason to make it all one big XML document.

    Exactly, We used the same nested XML before to for much the same reason.

    Also, Early Webservice implementations differed when handling arrays between .NET and Java so .NET created arrays could not be read by a Java client, or any more complex data than string, int and so, so if you needed more complex data to be sent to or from the service embedded XML was leages better than to invent some "own" solution to encode the data.

    Newer implementations is better and supports complex data types but if the service has been around for a while you do not want to force every existing customer to rebuild and they probably do not want to have multiple solutions to support.

  • super compatible (unregistered)

    Decode this!

    %25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%33%25%33%33%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%34%25%33%36%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%34%25%33%34%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%37%25%32%35%25%33%33%25%33%30%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%33%25%33%31%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%37%25%32%35%25%33%33%25%33%34%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%33%25%33%39%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%33%25%33%32%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%34%25%33%33%25%32%35%25%33%32%25%33%35%25%32%35%25%33%33%25%33%36%25%32%35%25%33%33%25%33%35

  • Jerry (unregistered) in reply to Mr. S.
    Mr. S.:
    We do this too. It does make SOAP a little easier - no schema changes for every little response change, but I'd expect more from a third party, external-facing service.
    Hint: look up xs:any ( http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-any )
    Mr. S.:
    Not to say that doing this isn't a WTF.
    Oh, I don't know. I think the real WTF is that someone accepts an implementation like that and actually puts it into production.
  • Peter (unregistered) in reply to super compatible

    This is indeed super compatible.

  • abr3 (unregistered)

    maybe they tried to redefine <xml/> to "<xml/>" in the name of encoding :o)

  • Anonymous Coder (unregistered) in reply to justsomedudette

    0000000 2123 622f 6e69 732f 2068 652d 230a 7420 0000010 6568 6e20 7865 2074 696c 656e 7220 7365 0000020 6174 7472 2073 7375 6e69 2067 6374 736c 0000030 2068 0a5c 7865 6365 6020 6877 6369 2068 0000040 6374 736c 2068 207c 6174 6c69 2d20 6031 0000050 2220 3024 2022 2422 2240 0a0a 2323 2320 0000060 0a20 2323 2320 6d20 6961 0a6e 2323 2320 0000070 0a20 200a 7720 6968 656c 7b20 675b 7465 0000080 2073 7473 6964 206e 696c 656e 205d 3d3e 0000090 3020 207d 0a7b 2020 2020 6669 7b20 655b 00000a0 666f 7320 6474 6e69 7d5d 7b20 7262 6165 00000b0 7d6b 200a 2020 6920 2066 247b 696c 656e 00000c0 3d20 203d 7d7b 207d 637b 6e6f 6974 756e 00000d0 7d65 200a 2020 7220 6765 7573 2062 612d 00000e0 6c6c 7b20 7d25 2420 696c 656e 2220 2220 00000f0 6c20 6e69 0a65 2020 2020 6573 2074 7469 0000100 6d65 2073 735b 6c70 7469 2420 696c 656e 0000110 0a5d 2020 2020 6f66 6572 6361 2068 6568 0000120 2078 6924 6574 736d 7b20 200a 2020 2020 0000130 6920 2066 5b7b 6373 6e61 2420 6568 2078 0000140 2522 2278 6420 6365 205d 3d21 3120 207d 0000150 637b 6e6f 6974 756e 7d65 200a 2020 2020 0000160 7020 7475 2073 6e2d 6e6f 7765 696c 656e 0000170 5b20 6962 616e 7972 6620 726f 616d 2074 0000180 2063 6424 6365 0a5d 2020 2020 0a7d 2020 0000190 2020 7570 7374 2220 0a22 2020 0a7d 200a 00001a0 6520 6978 2074 0a30 0a0a 000a 00001ab

    A script to decode the above comments.

    You are welcome.

  • Jym (unregistered) in reply to anon

    Indeed, here's where I would expect to find an &#34 in the wild.

  • cst1992 (unregistered) in reply to justsomedude

    I actually developed a bash script that will generate a c program that will decode this. Nicely done, man!

  • cst1992 (unregistered) in reply to justsomedudette

    "Some guy from the future"? Hmm....

  • cst1992 (unregistered) in reply to super compatible

    Level 4 compatibility - nice!

Leave a comment on “XML'd XML”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article