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