Slashdot Mirror

← Back to Stories (view on slashdot.org)

Philosophical Split Hurts Web Services Adoption

Posted by timothy on from the so-many-to-choose-from dept.

Avidwriter writes "'There is a serious split in Web services implementation philosophy that is threatening to stall the benefits of the technology to businesses and consumers,' says this Devchannel story. 'The WSDL 1.1 specification allows programmers to choose between remote procedure call (RPC) style and document-style Web services. The decision is not an arbitrary one, as it has ramifications for both message structure and more importantly the interoperability of Web services...'"

25 comments

  1. Of course it's a problem... by mike_sucks · · Score: 2, Insightful

    ... RPC-style "web" services such as SOAP and XML-RPC should not be an option. They're contrary to the architecture to the Web. If anything, they should be called RPC over HTTP or something similar, because that is all they have in common with the Web.

    If you want to do a real Web service, use REST.

    --
    -- "So, what's the deal with Auntie Gerschwitz et all?"
    1. Re:Of course it's a problem... by Jeremiah+Cornelius · · Score: 1
      RPC.

      Always sucked.

      Fits into a model of security where the 'remote' is a part of your "Trusted Computing Base."

      Flawed, almost all-around.

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    2. Re:Of course it's a problem... by Anonymous Coward · · Score: 2, Interesting

      SOAP, particularly as it matures into 1.2, is moving away from the RPC model to a most REST model. So while your point is good, don't paint SOAP with that brush.

    3. Re:Of course it's a problem... by NullStr · · Score: 1

      Precisely. HTTP is simply a convenient protocol to use, because firewalls almost certainly allow it through. Single-click generation of RPC-style "WebServices" apps looks impressive at conferences, but perhaps just saves the developer a bunch of keystrokes.

      At DevWeek London *February 2002* Don Box spoke of this RPC-vs-Document conflict, coming out (IIRC) in favour of the Document ("messaging") model.

      I'm surprised if the issue really not been largely resolved since then.

  2. Little summary and comment by jsse · · Score: 4, Insightful

    The author stated his stance in the very first paragraph:

    For example, it is incorrect to assume that a request-response programming model dictates an RPC-style message format. The Document style can also be used for request-response communication.

    And in this regard, he chose his side:

    In this case, Microsoft is right. Document/literal Web services are a better choice for data interoperability. While focusing on JAX-RPC instead of JAXM is in line with Sun's attempt to simplify Java development, it's the wrong approach for Web services.

    Then the followings are mainly pointing out the flaws in Apache Axis.

    First of all, I can see in his article what Axis does wrong. However, I don't see how Microsoft's way - Document/literal Web services - could solve the problem.

    I've mixed feeling about his arguments. First I do think the present RPC implemention in WSDL is getting out of hand(chaotic and complicated), but if we could only do document style transfer as he said the Microsoft's way, why the hell should we consider adopting WS in the first place? Isn't what SUN and Apache(and IBM, he didn't mention) does exactly what we really need for interoperative protocols?

    To put it simpler, in the pure document transfer model, the processing logics will lie in the senders and receivers. That is defeating the major merit of WS on interoperability, where the processing logics are not hard-coded into one framework.

    The author is a scientist in DOD and he really has some insight in WSDL, but if WSDL is really implemented in Microsoft's way then many wouldn't even consider adopting WS in the first place.

    1. Re:Little summary and comment by etcshadow · · Score: 2, Insightful

      Also, how seriously are we supposed to consider an article about the future of web technologies when the guy can't (sic) even figure out how to properly escape his apostrohpes.

      I mean really!

      No, joking aside, its remarkable the extent to which this is all just unmitigated editorializing without the slightest good reasoning to back it up. Not to mention that I pretty strongly disagree with the notion that "RPC is bad". If anything, I'd actually go as far as to say that I think that SOAP is far too often overkill. If XML-RPC gets the job done, then why resort to all that heavy, unmanageable garbage?

      --
      :Wq
      Not an editor command: Wq
    2. Re:Little summary and comment by LarryRiedel · · Score: 2, Informative

      I think the author may be expressing, among other things, an idea like that it may be cleaner to implement an RPC style interaction model on top of a Document style interaction model than vice versa, to define a protocol in terms of message formats than in terms of an API, to implement a blocking API on top of a non-blocking API than vice versa. Not a statement of fact so much as rejecting a choice between A or B in favor of thinking about what will be the best way to get A and B.

      Larry

    3. Re:Little summary and comment by aminorex · · Score: 1

      ...to implement a blocking API on top of a non-blocking API...

      Well, you can't use HTTP then. It's pure request-response.
      (Unless you do things that are frankly impractical.)

      If you implement RPC over REST, you're implementing
      a blocking protocol over a non-blocking protocol over
      a blocking protocol. Frankly, stupid.

      But then RPCs always were stupid. There are no "calls"
      in reality, only events.

      --
      -I like my women like I like my tea: green-
    4. Re:Little summary and comment by KILNA · · Score: 1

      If it's "it is", it's "it's" not "its". I used to confuse them as well, but I couldn't resist commenting on the comment complaining about apostrophe's.



      Yes, that last apostrophe was meant to fuck with you.

      --
      Error: PANTS NOT FOUND. Press <F1> to continue.
  3. DOD project? by djmitche · · Score: 2, Funny

    Did anyone catch the (hard-to-miss) part about the DOD project that's trying to fit terrorists into some ontology that also includes "plants" and "animals"? That's so insane, I don't know whether to laugh or cry..

    P.S. Yes, I read the article. Sorry. (slinks away in shame)

    1. Re:DOD project? by one9nine · · Score: 1
      Or how about the fact that according to the ontology , humans have revolted against our phylum oppressors and declared independence! We're no longer animals, people!

      Looks like we need a new poll to pick our new phylum name. CowboyNeilia perhaps?

    2. Re:DOD project? by Anonymous Coward · · Score: 0

      yeah and he puts Terrorists and Anarchists on the same level in has "class hierarchy".

      What a retard.

      I really don't even understand the article, what difference does it make how the data is structured?

      Right now I'm writing a daemon that does stuff and reports its status in response to XML-RPC queries, various integers, counters and so forth. Somebody tell me how this article will make my life easier or my program better or whatever.

    3. Re:DOD project? by dash2 · · Score: 1
      Yeah, and he opposed "disputant" to "creator". But don't forget, kids: we are not in the least afraid of ruins.

      :-)

    4. Re:DOD project? by aminorex · · Score: 1

      Well, um, it's a *Miltonian* ontology.

      --
      -I like my women like I like my tea: green-
    5. Re:DOD project? by dash2 · · Score: 1
      It seems the philosophical problems of the DOD go deeper than document vs. RPC-centric web services:



      4.1 heroes
      4.1.1 romantic heroes
      4.1.1.1 Osama bin Laden
      4.1.1.2 Satan

  4. Biased examples -- worthless article by plsuh · · Score: 4, Interesting

    Mr. Daconta has chosen a very contrived example to support his argument. A tree-structured taxonomy fits very nicely into a DOM-style response, but fits poorly into a Hashmap. Ergo, since his document-style request returns a DOM and his RPC-style request returns a Hashmap, the Document-style request is always superior. This is complete bullshit. Either way could be easier to implement and result in a more natural response, depending on the situation.

    A Hashmap is a lousy and unnatural way of representing a tree structure in the first place. Why would sending it over a wire in response to a SOAP call result in any less awkwardness at the other end? What if the taxonomy was represented as vectors and sub-vectors? This would allow a much more natural representation, and would result in a much clearer output in response to a SOAP call.

    What if the underlying structure was not hierarchical, but was instead a bi-directional circular linked list? Expressing this in a DOM object is possible, but it's ugly and does not flow naturally.

    Another thing to notice is how much code was written for the two examples. The RPC-style code is a mere 45 lines total. The Document-style code is shows 130 lines, but notes that many more lines were omitted. At 7 lines per omitted item from class7 to class21, that's another 105 lines, for a total of 235 lines. If you're going to put 5 times as much effort into the result, it's not surprising that you get back a much cleaner response.

    Daconta's article should be moderated as "-1 Troll" IMNSHO.

    --Paul

  5. Old news - the split has moved by Kopretinka · · Score: 3, Insightful
    WSDL 1.1 is an old specification and the split is just as old and mostly solved by general adoption of the document/literal (as opposed to RPC/encoded) approach.

    Now the pressing question seems to be the RESTfulness or not of Web Services. See a related Mark Baker's blog entry for illustration.

    --
    Yesterday was the time to do it right. Are we having a REVOLUTION yet?
    1. Re:Old news - the split has moved by aminorex · · Score: 1

      That's a cute way to avoid a debate you might lose.
      Howerver, it's a bit bald-faced:

      Even WSDL 1.1 hasn't been adopted by the overwheleming
      majority of web services, Monkey-boy's malapropisms
      notwithstanding.

      --
      -I like my women like I like my tea: green-
    2. Re:Old news - the split has moved by Kopretinka · · Score: 1

      Personally, I had the feeling that WSDL 1.1 was, in fact, adopted by the overwhelming majority of web services (HTTP/HTML services excluding). Are you aware of other interface definition language being more successful than WSDL 1.1 or are you just stating that majority of web services does without interface definition?

      --
      Yesterday was the time to do it right. Are we having a REVOLUTION yet?
    3. Re:Old news - the split has moved by aminorex · · Score: 1

      Without a WSDL interface definition, certainly.
      The lack of a WSDL definition does not make a
      thing undefined, or bereft of definition.

      --
      -I like my women like I like my tea: green-
    4. Re:Old news - the split has moved by Kopretinka · · Score: 1

      I agree, but most SOAP toolkits I know base most of their functionality off WSDL - generating client-side proxies, serialization and deserialization etc. I don't believe the majority of web services to work on the XML level.

      --
      Yesterday was the time to do it right. Are we having a REVOLUTION yet?
    5. Re:Old news - the split has moved by distobj · · Score: 1

      Whatever. I'm right, because I've written code that does what Web services people say is impossible. It's not like I'm going to wake up and realize that I didn't write that code.

      I've also spent much of the past 5 years studying very large scale systems in extreme detail. Before that, I was a CORBA wiz, so I'm well aware of pros and cons of both architectural styles.

      I choose REST because it's superior to Web services in practically every way that is important to large scale systems. Moreover, I reject Web services, because it fails to pass the single most critical litmus test for large scale systems; it's not late bound (i.e. integration complexity is necessarily worse than O(N)).

  6. Interesting reply by Anonymous Coward · · Score: 0

    Check out this reply on DevChannel:

    http://webservices.devchannel.org/comments.pl?sid= 3276&cid=139