OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] RE: A Two Day Workshop for Software Architects

[ 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 

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?


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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS