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

XML's "Big Idea" and how it relates to REST

Expand Messages
  • Paul Prescod
    Consider this argument about how documente-oriented web services are better than RPC interfaces (after the stuff about UDDI). If you look closely I think
    Message 1 of 7 , Jun 21 12:10 PM
    • 0 Attachment
      Consider this argument about how "documente-oriented web services" are
      better than RPC interfaces (after the stuff about UDDI). If you look
      closely I think you'll see an inadvertent argument for REST in there....

      -------- Original Message --------
      Subject: RE: [e-lang] web services taking off
      Date: Fri, 21 Jun 2002 11:37:57 -0700
      From: "Karp, Alan" <alan_karp@...>
      Reply-To: e-lang@...-os.org
      To: "'e-lang@...-os.org'" <e-lang@...-os.org>

      Paul Prescod wrote:
      >
      > In case you'll be working on UDDI version 3,

      Thankfully, no.

      > I hope you'll look at my
      > critique of UDDI here:
      >
      > * http://www.xml.com/pub/a/2002/02/06/rest.html?page=2
      >
      > That's not all I have to say about UDDI but its a start.

      The question of URI versus GUID came up in every meeting I attended.
      There were very good reasons for not using URIs, but I'd have to dredge
      up my notes from 2 years ago since I can't recall the reasons now.

      >
      > Okay, but this isn't really much more than you can do with
      > COM -- unless
      > the discovery is better. Which so far it isn't but okay maybe it could
      > be someday.
      >

      The major difference between NOM (CORBA/DCOM/RMI) and DEM (XML based web
      services) is that the former is designed to encapsulate data and the
      latter is meant to expose it. The object model gives me access to the
      methods, not the data; the document model gives me access to the data,
      not the methods.

      Kevin Smathers described the difference very nicely.

      While you can probably think of an OO design more quickly than you can
      a distributed document design, (and I do agree that any good designer
      could do so), that view completely neglects what you are trying to get
      from a loosely coupled design. Data/method encapsulation is what you
      are trying to avoid, not what you are trying to acheive.

      That is because you are trying to avoid making assumptions about how
      your
      data is going to be used, and encapsulation is the means by which you
      create those assumptions in the semantics of the methods that modify
      the
      data. Someone providing a MIDI object for example might give it a
      method
      to load data from a stream, play the data to an instrument, and write
      it
      to disk.

      Since I don't own a General MIDI keyboard, I would really like to
      translate
      instrument numbers before playing them on my keyboard. With a
      document
      format it is easy for me to use stream tools like 'sed' or 'perl' to
      manipulate the data with minimal coding. With data encapsulation I
      wouldn't be able to actually get at the data except through the
      methods
      that the original programmer provided. If the programmer didn't
      expect
      me to have to modify the Instrument set, then I can't do it.

      The rule of XML is that I can never even guess all of the uses to
      which
      my data might be put. Loosely coupled design is about showing data,
      not data hiding.

      _________________________
      Alan Karp
      Principal Scientist
      Decision Technology Department
      Hewlett-Packard Laboratories MS 1141
      1501 Page Mill Road
      Palo Alto, CA 94304
      (650) 857-3967, fax (650) 857-6278
      https://ecardfile.com/id/Alan_Karp
      http://www.hpl.hp.com/personal/Alan_Karp/

      _______________________________________________
      e-lang mailing list
      e-lang@...-os.org
      http://www.eros-os.org/mailman/listinfo/e-lang
    • Joe Hsy
      ... From: Paul Prescod [mailto:paul@prescod.net] ... I ve always thought this this type of characterization of OO is rather unfair. Encapsulation can be both
      Message 2 of 7 , Jun 21 1:16 PM
      • 0 Attachment
        -----Original Message-----
        From: Paul Prescod [mailto:paul@...]

        > Kevin Smathers described the difference very nicely.
        >
        > While you can probably think of an OO design more quickly than you can
        > a distributed document design, (and I do agree that any good designer
        > could do so), that view completely neglects what you are trying to get
        > from a loosely coupled design. Data/method encapsulation is what you
        > are trying to avoid, not what you are trying to achieve.

        I've always thought this this type of characterization of OO is rather
        unfair. Encapsulation can be both a good thing and a bad thing depending on
        what you're encapsulating and the nature of the application. REST uses
        encapsulation to good use as well. Per Roy's thesis chapter 5.2.1 (Data
        Elements):

        REST therefore gains the separation of concerns of the client-server
        style without
        the server scalability problem, allows information hiding through a
        generic interface
        to enable encapsulation and evolution of services, and provides for a
        diverse set
        of functionality through downloadable feature-engines.

        I've never viewed OO as method oriented. Objects are data as well as
        associated methods. Exposing data and methods appropriately are matters of
        design (good designs expose the right set). Exposing all the data all the
        time isn't the point and isn't always a good idea. Likewise, I still don't
        understand why just because we are dealing with a super-scale distributed
        system that we should not allowing *any* object methods to be exposed.

        I think having an internet-scale OO system would be a very good thing and
        would quite useful. I've been trying to see if REST or some of the core
        concepts of REST can be the basis of such an OO system and I still think it
        can. But, if we keep insisting REST as incompatible with OO, I guess it is
        a hopeless cause.

        //Joe

        This email message, and any attachments to it, are for the sole use of the
        intended recipients, and may contain confidential and privileged
        information. Any unauthorized review, use, disclosure or distribution of
        this email message or its attachments is prohibited. If you are not the
        intended recipient, please contact the sender by reply email and destroy all
        copies of the original message.
      • Mikael Andersson
        ... Okay i ll have a go at this one :) 1) Object-Object interactions (semantics) OO systems have interactions between object and the semantic meaning of these
        Message 3 of 7 , Jul 2, 2002
        • 0 Attachment
          Joe Hsy wrote:
          > -----Original Message-----
          > From: Paul Prescod [mailto:paul@...]
          >
          >
          >>Kevin Smathers described the difference very nicely.
          >>
          >> While you can probably think of an OO design more quickly than you can
          >> a distributed document design, (and I do agree that any good designer
          >> could do so), that view completely neglects what you are trying to get
          >> from a loosely coupled design. Data/method encapsulation is what you
          >> are trying to avoid, not what you are trying to achieve.
          >
          >
          > I've always thought this this type of characterization of OO is rather
          > unfair. Encapsulation can be both a good thing and a bad thing depending on
          > what you're encapsulating and the nature of the application. REST uses
          > encapsulation to good use as well. Per Roy's thesis chapter 5.2.1 (Data
          > Elements):
          >
          > REST therefore gains the separation of concerns of the client-server
          > style without
          > the server scalability problem, allows information hiding through a
          > generic interface
          > to enable encapsulation and evolution of services, and provides for a
          > diverse set
          > of functionality through downloadable feature-engines.
          >
          > I've never viewed OO as method oriented. Objects are data as well as
          > associated methods. Exposing data and methods appropriately are matters of
          > design (good designs expose the right set). Exposing all the data all the
          > time isn't the point and isn't always a good idea. Likewise, I still don't
          > understand why just because we are dealing with a super-scale distributed
          > system that we should not allowing *any* object methods to be exposed.
          >
          > I think having an internet-scale OO system would be a very good thing and
          > would quite useful. I've been trying to see if REST or some of the core
          > concepts of REST can be the basis of such an OO system and I still think it
          > can. But, if we keep insisting REST as incompatible with OO, I guess it is
          > a hopeless cause.

          Okay i'll have a go at this one :)

          1) Object-Object interactions (semantics)
          OO systems have interactions between object and the
          semantic meaning of these methods is hard to encode in
          a form that a machine can understand.

          2) State and side effects
          Does a call to getMethod() alter the state ?
          Do i need to persist the Object after getMethod() to preserve the state ?
          Should the Object device when to persist ? This isn't always what you want.
          How far does the side effects of this method call reach ?
          Will the call return in 0.01s or in 10days ?
          Can ignore the answer ?

          The problem doesn't lie in associating the operations with data as being
          done in OO, but rather in the fact that the information is hidden so an application
          cannot choose how to process the information itself. Whoever builds the object
          must anticipate the future uses for the system if it is to be scalable and
          extensible.

          If a Object representing an image is to be anything more than data.
          It must encode operations. And as describing behaviour of methods is
          very hard. Actually the method itself is the only _exact_ description we can get.

          If we use methods and hide data we can only have one implementation of each method
          if the system as a whole is to be reliable.And the behaviour must be exactly the
          same regardless of where you use the Object/methods. So we need exact platform
          independence for it to work. And still, in large scale distributed systems you
          can easily get almost uncontrollable interactions when different parts of the
          systems starts sending messages(method invocations) back and forth. These situations
          aren't easily avoided.

          But in a massively distributed system we must assume nodes in that system might be of
          different kinds. Not all information processing units are created equal :)

          A data structure is much easier to describe because it doesn't generate interactions
          that may be sequence dependend. init(),release() and release(),init() can have wildly
          different interaction patterns. So we can describe data in fever dimensions.
          And this make it simpler.

          Each node can implement it's own (or use some library) operations for whatever
          data types it is interested in. The errors that may arise is more easily handled
          because fewer (entirely unknown) interactions will occur. Formatting errors in
          data is often quite easy to detect. So we can validate input to a higher degree.
          We can not easily validate how a method works, mainly because of that we cannot
          se the side effects (as all side effects are hidden
          until we detect them)

          What i think one should strive for in distributed systems is to avoid side effects
          as much as possible.
          This make the system much more robust against timing differences. It is even so that
          the ordering of events is irrelevant if we have _no_ side-effects.

          OO is almost _purely_ side-effects, you use methods to alter the state of an object.
          And you never know how far these side effects reach. You are at the mercy of whoever
          made that particular object. You never know the state of the object, it's lika
          quantum-mechanics. Unless you look, you don't know what you have. And when you've
          looked you still don't know :)

          Comments and criticism are welcome ...

          I will not attempt to describe the REST architecture, many has done it before me
          and succeded well.


          >
          > //Joe

          /Mikael Andersson
        • Paul Prescod
          I think you ve got some important ideas in there! REST (especially HTTP GET) is about give me the data and don t tell me what to do with it. OOP is designed
          Message 4 of 7 , Jul 2, 2002
          • 0 Attachment
            I think you've got some important ideas in there! REST (especially HTTP
            GET) is about "give me the data and don't tell me what to do with it."
            OOP is designed primarily to "tell you what to do with it" (to the
            extent of rules like the law of Demeter that strongly council against
            showing your hand)

            * http://www.ccs.neu.edu/home/lieber/LoD.html

            --
            Come discuss XML and REST web services at:
            Open Source Conference: July 22-26, 2002,
            conferences.oreillynet.com/os2002/
            Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
          • Robert Leftwich
            ... How is this any different from a description of REST, you still use methods (albeit standardized HTTP methods) to alter the state of a resource, with the
            Message 5 of 7 , Jul 3, 2002
            • 0 Attachment
              At 02:33 AM 3/07/2002, Mikael Andersson wrote:

              >OO is almost _purely_ side-effects, you use methods to alter the state of an object.

              How is this any different from a description of REST, you still use methods (albeit standardized HTTP methods) to alter the state of a resource, with the exception that GET allows side-effect free access? Refer to Mark Bakers 'An Abstract Model for HTTP Resource State' (http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model).

              >And you never know how far these side effects reach. You are at the mercy of whoever
              >made that particular object.

              Why is this any different for a resource?

              >You never know the state of the object, it's lika
              >quantum-mechanics. Unless you look, you don't know what you have. And when you've
              >looked you still don't know :)

              This is where REST is advantageous, however, you can still only see a 'representation' of the state of the resource, i.e. you only see what the resource provider wants you to see, so you can never truly know the state of the resource?

              Continuing on with the whole no side-effects approach, I'm having a hard time reconciling this notion, i.e. being purely functional (in the programming language sense) and being able to change the state of a resource via HTTP methods. Am I understanding what you mean when you say side-effect free and if so should we be looking more at FP rather than OOP for implementing REST-like systems?

              Robert
            • Mikael Andersson
              First i d like to state this: One can call (almost) any system OO if you look har enough. In the same way as all systems is procedureal to the core (as
              Message 6 of 7 , Jul 3, 2002
              • 0 Attachment
                First i'd like to state this:
                One can call (almost) any system 'OO' if you look har enough. In the same way as all systems
                is procedureal to the core (as machinecode is procedural in some sense)

                We must try to look at how different techniques is used. Not how they are specified.
                Distributed systems is about realy more than about theory. People make mistakes.

                Robert Leftwich wrote:
                > At 02:33 AM 3/07/2002, Mikael Andersson wrote:
                >
                >
                >>OO is almost _purely_ side-effects, you use methods to alter the state of an object.
                >
                >
                > How is this any different from a description of REST, you still use methods
                > (albeit standardized HTTP methods) to alter the state of a resource, with
                > the exception that GET allows side-effect free access? Refer to Mark Bakers
                > 'An Abstract Model for HTTP Resource State' (http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model).
                >

                GET,POST,PUT has very clear meanings (esp. as describe in that draft). Most OO systems
                contain 1000's of methods with different semantics, and it's hard for a system to know
                what they mean. And they cannot explore, for doing so may alter the state unpredictably.

                Using GET you can (or you should be able to atleast...) explore quite freely. POST
                otoh, may alter state.

                >
                >>And you never know how far these side effects reach. You are at the mercy of whoever
                >>made that particular object.
                >
                >
                > Why is this any different for a resource?
                >

                When you have the 'object' (the page/whatever). The information in it will
                not change until you request it again. If you act on a local(or remote) object
                in a fullt distributed system, it may change.

                I feel the wholeness of a resource is important. All that is guaranteed
                in an OO system is that every object is consistent to it's own rules at all times.
                And the object is the rules, so we don't know them.
                But if i call one method, and then another. The result from the first and second
                is subject to timing issues with other systems involved.

                >
                >>You never know the state of the object, it's lika
                >>quantum-mechanics. Unless you look, you don't know what you have. And when you've
                >>looked you still don't know :)
                >
                >
                > This is where REST is advantageous, however, you can still only see a 'representation'
                > of the state of the resource, i.e. you only see what the resource provider wants you
                > to see, so you can never truly know the state of the resource?
                >

                Matter is built by atoms whose state we cannot know. But on a macroscopic scale it's predictable.
                But an atom here, won't affect something somewhere entirely different (sans entanglement, but
                that's another story :) ).

                But we get some view of the state in a format we can understand. In OO the view is composite. We must
                call many methods to get a 'view'. And during that time we're at risk of timing issues.


                > Continuing on with the whole no side-effects approach, I'm having a hard time
                > reconciling this notion, i.e. being purely functional (in the programming language sense)
                > and being able to change the state of a resource via HTTP methods. Am I understanding what
                > you mean when you say side-effect free and if so should we be looking more at FP rather
                > than OOP for implementing REST-like systems?

                I don't think we can be functional. But i think there is some important ideas there. A purely
                functional system can be executed in arbitrary order and yield the same result.
                This behaviour would do wonders for any distributed system. But we should strive to reduce
                the points where side effects can happen and also to reduce the impact they may have.

                Being resilient to timing problems is very hard. And when doing something in a distributed
                environment timing can be a nightmare.

                Btw i'm not an expert of functional languages. What i know is what a friend has showed me which
                is very good at these things and what i've read from a few sources. So don't think i can give
                a very deep insight on functional programming idioms and how it possibly relates to REST
                like systems.

                I have some more things on my mind here. But i'll try to keep myself from wandering to far
                astray. As i have a tendency to do so. I easily get too philosophical :)

                >
                > Robert
                >


                /Mikael Andersson
              • Bill de hÓra
                ... Here s a working guide to various definitions of OO: Bill de hÓra .. Propylon www.propylon.com
                Message 7 of 7 , Jul 3, 2002
                • 0 Attachment
                  > -----Original Message-----
                  > From: Mikael Andersson [mailto:mikael@...]
                  > Sent: 03 July 2002 12:33
                  >
                  > First i'd like to state this:
                  > One can call (almost) any system 'OO' if you look har enough.

                  Here's a working guide to various definitions of OO:

                  <http://www.paulgraham.com/reesoo.html>

                  Bill de hÓra
                  ..
                  Propylon
                  www.propylon.com
                Your message has been successfully submitted and would be delivered to recipients shortly.