Loading ...
Sorry, an error occurred while loading the content.

The SOAP Juggernaut rolls on...

Expand Messages
  • Jeffrey Winter
    While it s encouraging to see the WebMethods feature being adopted by SOAP 1.2, I question how often a REST architecture will actually be adopted. Even the GET
    Message 1 of 8 , Jul 30, 2002
    • 0 Attachment
      While it's encouraging to see the WebMethods feature being adopted by SOAP
      1.2, I question how often a REST architecture will actually be adopted.

      Even the GET examples that are shown in the SOAP spec don't really encourage
      a REST approach.

      For example:


      http://www.w3.org/2000/xp/Group/2/06/07/edcopy-soap12-part0-with-GET-additio
      ns.html#L26854

      Shows an example HTTP GET,

      GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
      Host: travelcompany.example.org
      Accept: text/html, application/soap+xml

      The returned envelop contains a UUID reference for the named reservation
      code.

      Which is all well and good, but a subsequent POST is done to a generic
      "Reservations"
      resource, and the 'real' resource is referenced using the UUID buried in the
      posted envelope,

      POST /Reservations HTTP/1.1
      Host: travelcompany.example.org
      Content-Type: application/soap+xml; charset="utf-8"
      Content-Length: nnnn

      <!--- soap envelope elided -->

      I get the sense that most SOAP-base services will continue to simply follow
      the path of least resistance and disappear behind generic URLs.
    • Dan Brickley
      ... Hash: SHA1 ... Here s an analogy I ve been toying with when thinking about the likely shape of SOAP 1.2 deployment. POST-only SOAP services may be the HTML
      Message 2 of 8 , Jul 30, 2002
      • 0 Attachment
        -----BEGIN PGP SIGNED MESSAGE-----
        Hash: SHA1



        Jeffrey Winter wrote:
        > While it's encouraging to see the WebMethods feature being adopted by SOAP
        > 1.2, I question how often a REST architecture will actually be adopted.
        >
        > Even the GET examples that are shown in the SOAP spec don't really encourage
        > a REST approach.
        >
        > For example:
        >
        >
        > http://www.w3.org/2000/xp/Group/2/06/07/edcopy-soap12-part0-with-GET-additio
        > ns.html#L26854
        >
        > Shows an example HTTP GET,
        >
        > GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
        > Host: travelcompany.example.org
        > Accept: text/html, application/soap+xml
        >
        > The returned envelop contains a UUID reference for the named reservation
        > code.
        >
        > Which is all well and good, but a subsequent POST is done to a generic
        > "Reservations"
        > resource, and the 'real' resource is referenced using the UUID buried in the
        > posted envelope,
        >
        > POST /Reservations HTTP/1.1
        > Host: travelcompany.example.org
        > Content-Type: application/soap+xml; charset="utf-8"
        > Content-Length: nnnn
        >
        > <!--- soap envelope elided -->
        >
        > I get the sense that most SOAP-base services will continue to simply follow
        > the path of least resistance and disappear behind generic URLs.

        Here's an analogy I've been toying with when thinking about the likely
        shape of SOAP 1.2 deployment. POST-only SOAP services may be the HTML
        Frames of the next generation Web.

        Just as framed Web sites became popular for a few years after
        frames-capable browsers were deployed, we'll probably see a lot of
        POST-only SOAP services in the near future. But if the REST critique of
        POST-only services is right, we can expect to see these replaced by more
        addressable, GET-accessable SOAP services, just as we saw Frames pretty
        much vanish from mainstream use. Most Web sites don't use HTML Frames,
        because using them turns out to be a pain. The critiques we're hearing
        about POST-only SOAP have a lot in common with the various critiques of
        frames (URIs, addressability etc). Maybe we'll see a similar
        adoption/migration curve...?

        Dan

        ps. my sense that frames were quite widely adopted and then slowly
        abandoned is based on memory, anecdote etc. Does anyone know of a survey
        that puts hard figures to this claim?







        -----BEGIN PGP SIGNATURE-----
        Version: GnuPG v1.0.6 (GNU/Linux)
        Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

        iD8DBQE9RsblPhXvL3Mij+QRAhh6AJ9TmYrau7XASsOF7e11vb4pgCVDsACdFik/
        lACzD6ycTr6MkFrkUniks9c=
        =mxqH
        -----END PGP SIGNATURE-----
      • Mark Baker
        ... I d like to believe that it was this easy, but at least frames were retrievable without prior coordination. They broke a handful or architectural
        Message 3 of 8 , Jul 30, 2002
        • 0 Attachment
          On Tue, Jul 30, 2002 at 05:03:32PM +0000, Dan Brickley wrote:
          > Just as framed Web sites became popular for a few years after
          > frames-capable browsers were deployed, we'll probably see a lot of
          > POST-only SOAP services in the near future. But if the REST critique of
          > POST-only services is right, we can expect to see these replaced by more
          > addressable, GET-accessable SOAP services, just as we saw Frames pretty
          > much vanish from mainstream use. Most Web sites don't use HTML Frames,
          > because using them turns out to be a pain. The critiques we're hearing
          > about POST-only SOAP have a lot in common with the various critiques of
          > frames (URIs, addressability etc). Maybe we'll see a similar
          > adoption/migration curve...?

          I'd like to believe that it was this easy, but at least frames were
          retrievable without prior coordination. They broke a handful or
          architectural principles, but they didn't try to reinvent the entire
          architecture like the vast majority of POST based Web services do.

          > ps. my sense that frames were quite widely adopted and then slowly
          > abandoned is based on memory, anecdote etc. Does anyone know of a survey
          > that puts hard figures to this claim?

          That's my recollection too, but I don't know of any studies.

          MB
          --
          Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
          Ottawa, Ontario, CANADA. distobj@...
          http://www.markbaker.ca http://www.idokorro.com
        • Jeffrey Winter
          ... Architectural issues aside, the reason that I saw frames being dropped was a purely pragmatic one: managing state between the different frames turned out
          Message 4 of 8 , Jul 30, 2002
          • 0 Attachment
            >> ps. my sense that frames were quite widely adopted and then slowly
            >> abandoned is based on memory, anecdote etc. Does anyone know of a survey
            >> that puts hard figures to this claim?

            > That's my recollection too, but I don't know of any studies.

            Architectural issues aside, the reason that I saw frames being dropped
            was a purely pragmatic one: managing state between the different frames
            turned out to be so cumbersome that using server-side includes was
            actually easier.

            The bottom line was, building dynamic websites was easier without frames.
            Unfortunately, the exact opposite motivation seems to be at play with SOAP;
            the toolkits make it easier to ignore the issues of URI design and simply
            deal
            with a generic URI.
          • Ramin Firoozye
            The bottom line was, building dynamic websites was easier without frames. Unfortunately, the exact opposite motivation seems to be at play with SOAP; the
            Message 5 of 8 , Jul 30, 2002
            • 0 Attachment
              The bottom line was, building dynamic websites was easier without frames.
              Unfortunately, the exact opposite motivation seems to be at play with SOAP;
              the toolkits make it easier to ignore the issues of URI design and simply
              deal   with a generic URI. 
               
              There will come a point in time when there are many publicly accessible services and finding the right one becomes an issue. The UDDI behemoth is one way, but I bet Google (or something like it) will have a way of offering the same functionality through their existing interface.
               
              Having a generic URI means that many functions are going to get slammed into a single bucket. The REST naming approach has an added advantage that you can uniquely identify each function using existing URL index/search technology.
               
              -ramin
            • Paul Prescod
              ... I think that that s up to us. The SOAP juggernaut is mindless. It will roll happily towards or away from REST as long as everybody can certify their
              Message 6 of 8 , Jul 30, 2002
              • 0 Attachment
                Jeffrey Winter wrote:
                >
                > While it's encouraging to see the WebMethods feature being adopted by SOAP
                > 1.2, I question how often a REST architecture will actually be adopted.

                I think that that's up to us. The SOAP juggernaut is mindless. It will
                roll happily towards or away from REST as long as everybody can certify
                their products "SOAP Compliant." There are still many specs in the web
                services world that are not very REST-y but SOAP is the spec with the
                most cachet.

                >...
                > Which is all well and good, but a subsequent POST is done to a generic
                > "Reservations"
                > resource, and the 'real' resource is referenced using the UUID buried in the
                > posted envelope,

                I agree that's a problem but there is an example in the primer that is a
                little better. Look at "Example 13":

                POST /Reservations?name=John%20Q.%20Public HTTP/1.1
                Host: travelcompany.example.org
                Content-Type: application/soap+xml; charset="utf-8"
                Content-Length: nnnn

                <?xml version='1.0' ?>
                <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
                <env:Header>
                ...

                It still uses a UUID inside which it should not.

                It is not too late to submit suggestions to the SOAP Primer. Here are my
                comments that address the prose more than the examples:

                * http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0050.html

                You could submit some about the examples. UUIDs do not make much sense
                even from a pure-SOAP anti-REST point of view because HTTP URIs can have
                SOAP messages sent to them but UUIDs cannot. UUIDs only make sense when
                you realize that SOAP is supposed to be "transport independent" which
                means that you cannot depend upon a reliable addressing model. So you
                have to build your own. You can imagine how great that is for
                interoperability.
                --
                Come discuss XML and REST web services at:
                Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
                Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
              • Paul Prescod
                ... Which is not to say that individual SOAP advocates are mindless. The point is that the spec is outside of the control of individuals. There is no
                Message 7 of 8 , Jul 30, 2002
                • 0 Attachment
                  Paul Prescod wrote:
                  >
                  >...
                  >
                  > I think that that's up to us. The SOAP juggernaut is mindless.

                  Which is not to say that individual SOAP advocates are mindless. The
                  point is that the spec is outside of the control of individuals. There
                  is no individual strongly associated with SOAP who can answer questions
                  about right ways and wrong ways to use it. That's a void that REST
                  advocates can step into.
                  --
                  XML, Web Services Architecture, REST Architectural Style
                  Consulting, training, programming: http://www.constantrevolution.com
                  Come discuss XML and REST web services at the Extreme Markup Conference
                • S. Mike Dierken
                  ... From: Paul Prescod ... ..step into.. is definitely the right analogy... just ask what does a URI identify?
                  Message 8 of 8 , Jul 30, 2002
                  • 0 Attachment
                    ----- Original Message -----
                    From: "Paul Prescod" <paul@...>

                    > That's a void that REST advocates can step into.

                    "..step into.." is definitely the right analogy... just ask "what does a URI
                    identify?"
                  Your message has been successfully submitted and would be delivered to recipients shortly.