[
Lists Home |
Date Index |
Thread Index
]
Let's ask why.
1. Please define scale. We toss that one in a lot and
it has been used often to defend internet designs that
later turned out to be not as robust as necessary even
if it "scaled". HTML is the shining example. It "scales"
because it only originally attempted to do one thing well:
provide a compact, predictable format for returning a
document and rendering it. Two axes. Later as more axes
were added, it began to fall apart. Thus XML and the
myriad application languages that are the XML System
Infrastructure, itself, quite complex.
2. If REST is the solution for Internet scale, why?
I suspect again, the number of axes of problems it
tries to solve are limited. If later, we find there are more
dimensions to what it is applied to, eg, web services,
will it still scale?
It's not all about technology, but in a sense, it
is about complexity. We have to be sure we constrain
the numbers and kinds of problems we try to solve.
We like aphorisms like "worse is better", "use what
works first then see what one needs next", but those
always lead to a redesign later if what is needed adds
complexity.
Even if the layers aren't right, Sessions is pointing
out that one way to solve complexity is to encapsulate,
precisely what OOP says to do. Why does OOP not scale?
Things scale unifirmly inside a boundary or orbit. If they
escape that, they become unpredictable or chaotic, if
you like. Why does OOP not scale to the boundary
of the Internet? Explosive growth in interfaces
leads to explosive growth in protocols leading
to a fatter and fatter client. Perhaps using
one client is a bad idea: parts and assemblies, it's
in the way that you use it. Why would a wristwatch
need to support multiple protocols?
I think you will find that there may be one Internet
(the network), a "Web" inside that, but that possibly
what Berners-Lee and others refuse to see is that
a "fragmented web" does not have to result in a
"fatter client" if that client does not care about
"THE web" but only "its web". What might make The
Web work at scale does so by making other components
more complex. The question is, where should a
problem be solved given the particular system goals
that uses parts of another system?
Anywhere Anytime for Anyone is the goal of The Web.
That may not be a desirable scale for all problems
on the Internet. How would one decide?
len
From: Michael Brennan [mailto:Michael_Brennan@Allegis.com]
REST is a technical architecture for internet-scale systems. OO shines
within the boundaries of a single system. It stumbles as it tries to scale
across the enterprise. It falls flat on its face when it tries to scale
across the internet. Neither J2EE nor .NET solve the problems that REST
solves, but either one can be a great complement to REST. Those who failed
with OO in the past failed to ground their approach in a sound architectural
perspective. And there will be many failures with web services for the very
same reason. It's not all about the technology.
|
