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

Dynamic Evolvability

Expand Messages
  • Jan Algermissen
    Hi, Roy writes in his dissertation: 2.3.4.1 Evolvability Evolvability represents the degree to which a component implementation can be changed without
    Message 1 of 6 , Dec 4, 2006
    • 0 Attachment
      Hi,

      Roy writes in his dissertation:

      "2.3.4.1 Evolvability

      Evolvability represents the degree to which a component
      implementation can be changed without negatively impacting other
      components. Static evolution of components generally depends on how
      well the architectural abstraction is enforced by the implementation,
      and thus is not something unique to any particular architectural
      style. Dynamic evolution, however, can be influenced by the style if
      it includes constraints on the maintenance and location of
      application state. The same techniques used to recover from partial
      failure conditions in a distributed system [133] can be used to
      support dynamic evolution."[1]

      While trying to flesh out the argument that REST does increase
      dynamic evolvability (and that SOA (whatever it really is) does not,
      if so) I realized that I am not entirely clear what architectral
      constraint of REST increases dynamic evolvability and why it does so.

      The reference to Waldo's "Note on Disributed Computing" suggests -if
      I understand correctly- that one of the problems of dynamic evolution
      is to leave the calling component in a consistent state if the
      interface of the called component unexpectedly changes. IOW, making a
      call to a remote object should either succeed or fail with a clear
      error indication that tells the caller that the interface changed and
      how.

      Regarding REST I understand this:

      While REST's uniform interface constraint cannot prevent a remote
      component from changing its interface as part of an evolution (e.g.
      it could remove former support for PUT) the client will know exactly
      what happened since it knows the method semantics (they are uniform)
      and the error code ("405 Method Not Allowed") indicates the reason
      for the failure. IOW, dynamic evolvability is increased because the
      called component can change without brealing the client (because the
      client is required to understand and expect a 405).

      Is this understanding correct?


      Assuming it is correct, does WS-* (being a SOA implementation) pass
      the test or not?
      (Without interface uniformity, all the server can really tell the
      client upon an interface change is: "Interface changed". This IMHO
      violates the constraint that the client must be in a consistent state
      after the failed call).


      Can anyone explain to me, how the location of application state
      affects dynamic evolvability? I am honsetly missing a clue here (or
      do not see the forrest for the trees).

      Thanks.

      Jan


      [1]http://www.ics.uci.edu/~fielding/pubs/dissertation/
      net_app_arch.htm#sec_2_3_4_1
      [133] http://research.sun.com/techrep/1994/abstract-29.html
    • Roy T. Fielding
      ... I am pretty sure that I was thinking of the constraint that application state be kept on the user agent. It is dynamic evolution in the sense that an
      Message 2 of 6 , Dec 4, 2006
      • 0 Attachment
        On Dec 4, 2006, at 2:57 PM, Jan Algermissen wrote:
        > Roy writes in his dissertation:
        >
        > "2.3.4.1 Evolvability
        >
        > Evolvability represents the degree to which a component
        > implementation can be changed without negatively impacting other
        > components. Static evolution of components generally depends on how
        > well the architectural abstraction is enforced by the implementation,
        > and thus is not something unique to any particular architectural
        > style. Dynamic evolution, however, can be influenced by the style if
        > it includes constraints on the maintenance and location of
        > application state. The same techniques used to recover from partial
        > failure conditions in a distributed system [133] can be used to
        > support dynamic evolution."[1]
        >
        > While trying to flesh out the argument that REST does increase
        > dynamic evolvability (and that SOA (whatever it really is) does not,
        > if so) I realized that I am not entirely clear what architectral
        > constraint of REST increases dynamic evolvability and why it does so.

        I am "pretty sure" that I was thinking of the constraint that
        application
        state be kept on the user agent. It is dynamic evolution in the
        sense that
        an old origin server can be replaced with a new one in the middle of one
        browser's ongoing conversation with a website (aside from the current
        message streams, which are presumed to complete before the origin server
        is replaced). Likewise, servers don't need to remember clients, so
        replacing
        a piece of client software does not affect other clients or servers.
        Use of URIs also helps in that regard (as opposed to using something
        that is less portable during evolution, like UUIDs).

        It is difficult for me to remember the exact origin of what I was
        thinking
        at the time because architectural properties were the first parts of the
        dissertation written down (part of the survey paper) and I changed the
        categories around several times. Most software research calls them
        "qualities" (mostly because that is what Boehm called them in early
        studies, IIRC), though some other sources refer to them as principles,
        requirements, or a host of other disturbing things.

        My first thought today was that I must have picked that definition up
        from some conversation with my apartment-mate (Peyman Oreizy). His
        dissertation on decentralized software evolution can be found at

        http://www.ics.uci.edu/~peymano/

        but he seems to have settled on a different set of terms from the
        ones that I used. It is worth reading anyway if you are interested
        in software evolution (or adaptability).

        > The reference to Waldo's "Note on Disributed Computing" suggests -if
        > I understand correctly- that one of the problems of dynamic evolution
        > is to leave the calling component in a consistent state if the
        > interface of the called component unexpectedly changes. IOW, making a
        > call to a remote object should either succeed or fail with a clear
        > error indication that tells the caller that the interface changed and
        > how.

        Er, possible, but more likely I was just thinking of partial failure
        conditions being the result of evolution-in-situ.

        > Regarding REST I understand this:
        >
        > While REST's uniform interface constraint cannot prevent a remote
        > component from changing its interface as part of an evolution (e.g.
        > it could remove former support for PUT) the client will know exactly
        > what happened since it knows the method semantics (they are uniform)
        > and the error code ("405 Method Not Allowed") indicates the reason
        > for the failure. IOW, dynamic evolvability is increased because the
        > called component can change without brealing the client (because the
        > client is required to understand and expect a 405).
        >
        > Is this understanding correct?

        I think it is more accurate to say that a resource cannot change
        its interface as part of an evolution because all resources have
        the same interface. (405 doesn't change the interface -- it is an
        answer to the request via the same interface.) But REST does not
        require use of a single interface protocol, so in that sense the
        interface could change dynamically (e.g., HTTP Upgrade).

        > Assuming it is correct, does WS-* (being a SOA implementation) pass
        > the test or not?
        > (Without interface uniformity, all the server can really tell the
        > client upon an interface change is: "Interface changed". This IMHO
        > violates the constraint that the client must be in a consistent state
        > after the failed call).

        WS-* doesn't *do* anything, and thus doesn't qualify for any test.
        You would have to test an application architecture that happens to
        use WS-* in a specific way that is testable. HTTP doesn't
        "pass" the test in isolation either -- it only passes when a
        REST-based application makes use of HTTP in a RESTful way.

        > Can anyone explain to me, how the location of application state
        > affects dynamic evolvability? I am honsetly missing a clue here (or
        > do not see the forrest for the trees).

        Consider what happens when a stateful server is replaced in the
        middle of a conversation with a client by a new server which seems
        just like the old one but has no idea what stage the client is
        within its application.

        ....Roy
      • Dave Orchard
        Roy asks about a stateful server evolving when the new server has no idea what stage the client is at. This is a great question, but most stateful servers
        Message 3 of 6 , Dec 4, 2006
        • 0 Attachment
          Roy asks about a stateful server evolving when the new server has no idea
          what stage the client is at. This is a great question, but most stateful
          servers today do the right thing. They provide for the old version and the
          new version, with a mapping between them. Thus stateful server evolution is
          fine if the server has been built for evolution, and most of the "real"
          systems do. Heck, we do side-by-side deployment too with a ton of
          variables to control how to direct.

          Properly built stateful servers are often higher user-perceived performance
          in versioning when the server side state is migrated to a new version in
          between client requests, rather than at run-time as the client request with
          the old state comes in.

          The question can be turned around a bit, and consider what happens when a
          stateful client is replaced in the middle of a conversation with a server by
          a new client which is just like the old one but has no idea what state the
          server is within its application.

          I think the question of location of client vs server state and
          versioning/evolvability is a very complicated decision, and some of the
          factors include how much the client is "trusted", how much
          time/processing/resource usage is on the client vs the server, the data set
          between the two, etc. The Web works in many ways because the time on the
          client is long compared to on the server (sub x second response time for
          those humans), the client can go away at any time (ie not trusted to do
          garbage collection properly), and the data sets are small (typically you
          just need to handle the amount of data that the client has entered to
          reconstruct the state). The more you change those (and other) factors, the
          more you lean towards server-side state. There's trade-offs in network
          performance, user-perceived performance, and other network and application
          properties that get adjusted. There's just no way that large data sets on
          the server communicating a small data set to well behaved (from a gcol
          perspective) clients where the server does most of the computing are going
          to be made client-side stateful.

          To paraphrase somebody, you've got to do the analysis for yourself and
          figure out which architectural style makes sense given your applications
          requirements.

          Cheers,
          Dave

          ________________________________

          From: rest-discuss@yahoogroups.com
          [mailto:rest-discuss@yahoogroups.com] On Behalf Of Roy T. Fielding
          Sent: Monday, December 04, 2006 5:27 PM
          To: Jan Algermissen
          Cc: rest-discuss@yahoogroups.com
          Subject: Re: [rest-discuss] Dynamic Evolvability

          > Can anyone explain to me, how the location of application state
          > affects dynamic evolvability? I am honsetly missing a clue here
          (or
          > do not see the forrest for the trees).

          Consider what happens when a stateful server is replaced in the
          middle of a conversation with a client by a new server which seems
          just like the old one but has no idea what stage the client is
          within its application.

          ....Roy
        • Roy T. Fielding
          ... Er, sometimes they do, yes, and other times they are just a checkbox on a marketing pamphlet. I have yet to see an instance of one vendor s server be
          Message 4 of 6 , Dec 5, 2006
          • 0 Attachment
            On Dec 4, 2006, at 9:35 PM, Dave Orchard wrote:

            > Roy asks about a stateful server evolving when the new server has
            > no idea
            > what stage the client is at. This is a great question, but most
            > stateful
            > servers today do the right thing. They provide for the old version
            > and the
            > new version, with a mapping between them. Thus stateful server
            > evolution is
            > fine if the server has been built for evolution, and most of the
            > "real"
            > systems do. Heck, we do side-by-side deployment too with a ton of
            > variables to control how to direct.

            Er, sometimes they do, yes, and other times they are just a checkbox
            on a marketing pamphlet. I have yet to see an instance of one
            vendor's server be replaced with a different vendor's server and
            not have the whole house of cards collapse. That is, except on
            the Web, which handles that change without any problem whatsoever
            if the identifiers do not change.

            In any case, the kind of evolution you are talking about there is
            very restricted and well planned. The statefulness, for example, has
            to be limited to session tickets or pointers to back-end systems
            that remain available during the process, and a bunch of money has
            to be thrown at the system to make even that possible.

            The kind of evolution I was talking about includes both small-scale
            planned evolution on the server and the wild whack-a-mole style of
            evolution that happens when one company absorbs another or an entire
            service shifts from a centralized architecture to edge-based Akamai.

            The important thing is not just that stateful-client architecture
            is evolvable, but that it is evolvable for free. We can indeed
            deploy an evolvable stateful system, but only if it is planned and
            budgeted as such by the likes of Bill Gates. A poor snot-nose
            grad student doesn't have that option, so in order for the vast
            multitude of services to be evolvable the solution has to be cheap
            and on by default. That is what we hope for when we architect the
            system for independent evolvability across multiple organizations.

            > Properly built stateful servers are often higher user-perceived
            > performance
            > in versioning when the server side state is migrated to a new
            > version in
            > between client requests, rather than at run-time as the client
            > request with
            > the old state comes in.
            >
            > The question can be turned around a bit, and consider what happens
            > when a
            > stateful client is replaced in the middle of a conversation with a
            > server by
            > a new client which is just like the old one but has no idea what
            > state the
            > server is within its application.

            A better example is a user operating on the same server with two
            different
            clients (e.g., desktop and blackberry) and expecting the state on both
            to remain synchronized. That is much easier to implement with a
            stateful
            server and that may be the more appropriate architecture to choose after
            considering all of the other requirements. Yep, there are lots of
            tradeoffs.
            Likewise, real-time monitoring systems are usually better architected
            as a distributed object or event-based system, with only the management
            console projecting a simpler interface.

            > I think the question of location of client vs server state and
            > versioning/evolvability is a very complicated decision, and some of
            > the
            > factors include how much the client is "trusted", how much
            > time/processing/resource usage is on the client vs the server, the
            > data set
            > between the two, etc.

            And let's not forget the question of how much money you are willing
            to spend on server complexity to make up for the other trade-offs.

            > The Web works in many ways because the time on the
            > client is long compared to on the server (sub x second response
            > time for
            > those humans), the client can go away at any time (ie not trusted
            > to do
            > garbage collection properly), and the data sets are small
            > (typically you
            > just need to handle the amount of data that the client has entered to
            > reconstruct the state). The more you change those (and other)
            > factors, the
            > more you lean towards server-side state. There's trade-offs in
            > network
            > performance, user-perceived performance, and other network and
            > application
            > properties that get adjusted. There's just no way that large data
            > sets on
            > the server communicating a small data set to well behaved (from a gcol
            > perspective) clients where the server does most of the computing
            > are going
            > to be made client-side stateful.

            Yeah, that's why stored procedures exist, and also why one thing a
            resource can be is (effectively) a stored procedure. But it's also
            interesting to consider other architectures that have more flexibility,
            such as mobile code.

            It is core to the Web design principles that the clients cannot be
            trusted, but that certainly isn't true of every system. Most times.
            Postscript printing, for example, is an excellent case study in the
            use of mostly-safe mobile code to enable independent evolution of
            printing applications from printer hardware.

            > To paraphrase somebody, you've got to do the analysis for yourself and
            > figure out which architectural style makes sense given your
            > applications
            > requirements.

            Yep, that's the key. And there is usually more than one valid
            architecture for any given application, with both positive and
            negative trade-offs in the short term and long. In the end, though,
            simplicity usually works better.

            ....Roy
          • Jan Algermissen
            Roy, thanks a lot, that was very helpful. ... Ok. Would it then be reasonable to say that a style that constrains the interface (to be uniform) increases
            Message 5 of 6 , Dec 5, 2006
            • 0 Attachment
              Roy,

              thanks a lot, that was very helpful.

              On Dec 5, 2006, at 2:26 AM, Roy T. Fielding wrote:

              > I think it is more accurate to say that a resource cannot change
              > its interface as part of an evolution because all resources have
              > the same interface. (405 doesn't change the interface -- it is an
              > answer to the request via the same interface.)

              Ok. Would it then be reasonable to say that a style that constrains the
              interface (to be uniform) increases evolvabiliy because changes
              resulting from evolution are only visible as data element changes and
              such changes are easier to cope with than interface changes?

              That has actually been my thinking over the past years, but admitedly
              I still lack a compelling reasoning why for example an incompatible
              data element change is less complex than an incopatible inerface change.
              (Hence I though the question of the caller being in a defined state
              after
              an evolution induced faulure would be the answer).

              Or is it as simple as "the complexity with data elements is inherently
              lower, e.g. because there are never issues like method call sequences or
              because it is easier to standardize a data element type than to
              standardize
              an interface, etc")?
              Intuitively I have no problem really, but as said, it is the
              reasoning that
              I find to be incomplete (in my head).


              Jan



              > But REST does not
              > require use of a single interface protocol, so in that sense the
              > interface could change dynamically (e.g., HTTP Upgrade).
            • Jan Algermissen
              Correction: Sorry, my use of the term data element below is imprecise. I was refering to representations only, not the other data elements of REST (headers,
              Message 6 of 6 , Dec 5, 2006
              • 0 Attachment
                Correction:

                Sorry, my use of the term 'data element' below is imprecise. I was
                refering to representations only, not the other data elements of REST
                (headers, URIs,...).
                Jan

                On Dec 5, 2006, at 9:03 PM, Jan Algermissen wrote:

                > Roy,
                >
                > thanks a lot, that was very helpful.
                >
                > On Dec 5, 2006, at 2:26 AM, Roy T. Fielding wrote:
                >
                > > I think it is more accurate to say that a resource cannot change
                > > its interface as part of an evolution because all resources have
                > > the same interface. (405 doesn't change the interface -- it is an
                > > answer to the request via the same interface.)
                >
                > Ok. Would it then be reasonable to say that a style that constrains
                > the
                > interface (to be uniform) increases evolvabiliy because changes
                > resulting from evolution are only visible as data element changes and
                > such changes are easier to cope with than interface changes?
                >
                > That has actually been my thinking over the past years, but admitedly
                > I still lack a compelling reasoning why for example an incompatible
                > data element change is less complex than an incopatible inerface
                > change.
                > (Hence I though the question of the caller being in a defined state
                > after
                > an evolution induced faulure would be the answer).
                >
                > Or is it as simple as "the complexity with data elements is inherently
                > lower, e.g. because there are never issues like method call
                > sequences or
                > because it is easier to standardize a data element type than to
                > standardize
                > an interface, etc")?
                > Intuitively I have no problem really, but as said, it is the
                > reasoning that
                > I find to be incomplete (in my head).
                >
                > Jan
                >
                > > But REST does not
                > > require use of a single interface protocol, so in that sense the
                > > interface could change dynamically (e.g., HTTP Upgrade).
                >
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.