Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RE: A Two Day Workshop for Software Architects
 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@A...] 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
