Discussions

News: The Great and Complete SOAP vs POX Debate

  1. The Great and Complete SOAP vs POX Debate (7 messages)

    In "Neward and Trenaman consider REST, or The Great and Complete SOAP vs POX Debate," TSS presents the collected episodes of Ted Neward and Adrian Trenaman’s discussion on SOAP vs. POX ("plain old XML", not "a sickness," although Your Editor supposes the definition's questionable.)
    The intrepid Neward suggests objects and XML have just as deep an impedance mismatch as objects and relational data do. REST is a good architectural style, admits Adrian, but he notes that SOAP, since it’s transport-agnostic, would work even if you wanted to send the message over other transports beyond HTTP, like JMS messages. Check it out!
  2. Interesting discussion but I think it glosses over some problems with SOAP and WSDL. It's not the ideas behind SOAP that are the problem. It's the implementation. First of all the original WSDL spec is a piece of junk. That hardly anyone can implement it properly (and my anyone, I mean big vendors with lots of resources) should be a clue that there's a problem. The 2.0 spec seems a lot cleaner but it seems that it will be a while before it pushes out the old stuff. The other thing is that in my experience when we tried to use the built in SOAP facilities, many of the people using the web services starting moaning about how they couldn't deal with that and asked us put the error status in the payload. I think we need to separate discussions about the theories behind SOAP from discussions about SOAP as it exists.
  3. Actually James, I don't have a problem with SOAP 1.2 because there really isn't that much to it. (Its what you can add to it ...) Now with WSDL, there certainly are issues because once again, they've tried to squeeze in too many things into one spec in order to satisfy a diverse community - especially the vendors. While we are at it though we might (I do) want to go after XML Schema - the third leg of this stool. You see a lot about the Structures part and how much better this or that (e.g. RELAX) is, but I have a much bigger objection to Data Types. It is just plain wrong. Its inconsistent, sloppy, etc. It looks like what it is - an attempt to satisfy 40 opinionated experts from diverse fields with one spec. I'd like to start over. Let's start with a standard for creating documents with tree (or other acyclical) graph structures so you didn't have to only use XML to get support from the other standards. All the alternatives should be the equvalent (1 to 1) of each other. Let's rewrite XML Schema with one purpose - representing data. Then let's see if WSDL cannot be simplified by breaking it up - separating concerns. I know, the horse is out of the barn and vested interests are in control. I fear this may all collapse under its own weight.
  4. Actually James, I don't have a problem with SOAP 1.2 because there really isn't that much to it. (Its what you can add to it ...) Now with WSDL, there certainly are issues because once again, they've tried to squeeze in too many things into one spec in order to satisfy a diverse community - especially the vendors.
    Actually that is the exact reason WSDL is a mess, as I understand it. When the different vendors convened to determine the standard, they had all developed code around their favorite candidates. No one wanted to give that up so we have a WSDL document that is internally redundant. My experience is that very few vendors (or none, possibly) actually implement this redundancy properly which creates asymmetrical understanding of the document. This is not a minor concern. A standard should make it easy to converse. I've used two tools from Tibco that did not understand each other's WSDLs. Now, SOAP, to me is fairly unexciting and not really a problem because it is so trivial, as you say. I will note that the perceived complexity (and utility) of SOAP is much greater than the reality of the situation. Really the value is in the WSDL. SOAP doesn't do a whole lot for you by itself. The main problem I see with SOAP is that a lot of developers and vendors strip off the SOAP message before they get to any custom handling. That kind of makes it pointless. It's not SOAP's fault but clearly it's not living up to its promise if people see it as getting in the way. When I was a b2b developer, pretty much all of our partners preferred POX and my personal experience was that they tended to be more robust (for no specific reason that I can point out.) The point I am trying to make I guess is that the backlash against SOAP is not because the ideas behind it are necessarily wrong but that things have panned out badly with the way it was done.
  5. Better title[ Go to top ]

    "Two Architecture Astronauts debate SOAP and REST and TSS editors fail at humor"
  6. Messaging is about data, not objects. Trying to make object references meaningful outside thier immediate context is fraught with peril (did we learn nothing from CORBA ?). Why is this a still a subject for debate 4 years on from Fowlers first law ? (which itself was based on half a decade of failed attempts to build "distributed object" based systems). Paul.
  7. Why is this a still a subject for debate 4 years on from Fowlers first law ? (which itself was based on half a decade of failed attempts to build "distributed object" based systems).
    "Fowler's first law" has nothing to do with "distributed object". If you adhere to it, the SOAP vs POX Debate comes down to "don't do either".
  8. Fowler's first law" has nothing to do with "distributed object". If you adhere to it, the SOAP vs POX Debate comes down to "don't do either".
    Really, because that is not what Fowler says: http://www.ddj.com/dept/architect/184414966 According this article written by Fowler, it is all about distributed objects. SOA and the concept of services originated from attempts to find the right granularity for distributed calls. The distributed object/component model failed because the granularity of objects tends to be too fine. Services began as ways to group a number of calls to objects into one call to the server. (The command bean is another approach). Some used arbitrary aggregations and some based the calls on the client’s design. Neither was satisfactory. The formula that was eventually hit upon was that each call should be an invocation of a use case. That gave you some opportunities for reuse (via top down analysis) without tying you to any specific client design. We compose ours services from objects/components, but we don't expose the objects directly. As to SOAP and POX. SOAP began as XML for distributed objects (RPC/encoded), but has morphed to support a service oriented model (document/literal, end point with multiple operations invoked according to the messages it receives). So when we are talking about SOAP versus POX we are talking services, not distributed objects. So the debate is more about when you want or need robust standard protocols every one can write to or when you only need something simple. Personally I find it easier to use SOAP all the time and leave the header empty when I don’t need the additional robustness of the WS-* standards. If you are writing portlets or AJAX you may prefer POX because you don’t want to deal with a couple of extra tags.