Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Technology

Philosophical Split Hurts Web Services Adoption 25

Posted by timothy 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...'"
This discussion has been archived. No new comments can be posted.

Philosophical Split Hurts Web Services Adoption More

Philosophical Split Hurts Web Services Adoption

Comments Filter:

  • Of course it's a problem... (Score:3, Insightful)

    by mike_sucks ( 55259 ) on Tuesday July 15, 2003 @09:10PM (#6448804) Homepage
    ... 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 [conveyor.com].
    • RPC.

      Always sucked.

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

      Flawed, almost all-around.

    • Re:Of course it's a problem... (Score:2, Interesting)

      by Anonymous Coward
      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.

    • 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 [microsoft.com] 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.

  • Little summary and comment (Score:4, Insightful)

    by jsse ( 254124 ) on Tuesday July 15, 2003 @09:50PM (#6449066) Homepage Journal
    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.
    • 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 to

      • 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.

    • 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

      • ...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.

  • DOD project? (Score:2, Funny)

    by djmitche ( 536135 )

    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)

    • 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?

    • Yeah, and he opposed "disputant" to "creator". But don't forget, kids: we are not in the least afraid of ruins.

      :-)

  • Biased examples -- worthless article (Score:5, Interesting)

    by plsuh ( 129598 ) <plsuh&goodeast,com> on Wednesday July 16, 2003 @01:31AM (#6450272) Homepage
    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

  • Old news - the split has moved (Score:4, Insightful)

    by Kopretinka ( 97408 ) on Wednesday July 16, 2003 @04:29AM (#6450791) Homepage
    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 REST [conveyor.com]fulness or not of Web Services. See a related Mark Baker's blog entry [markbaker.ca] for illustration.

    • 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.
      • 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?
      • 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

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close