User talk:Zha Ewry/Scoping
Revision as of 02:01, 14 October 2007 by Morgaine Dinova (talk | contribs)
- I've been trying to find some way in which this page could be extended, or gently modified, in order to make it reflect the banner goal of the AWG -- "Making the grid a scalable place" --- but I can't find a way. The problem is that, as presented, the page distorts that expressed goal into something completely different.
- A split has been made into normative and informative work products, as if the first were primary. And yet, the first is merely a means to an end, a mechanism that we want to use in the solution of the scaling problem, and as such is entirely derivative, not primary. If we knew of a better mechanism for reaching that goal, we would use it. At this time we believe that REST services are the best tool in our toolbox for this, but they're not the actual goal itself. They're a solution preference.
- It's the final section, "Out of scope", that I least understand. It seems to suggest that actually designing the REST services for scalability is out of scope ... yet that's the primary task of AWG! You cannot avoid considering the structure of the resources which are encapsulated as REST services, because those are the bottlenecks to scalability. Merely attaching a massively scalable HTTP-based access mechanism onto the front of a non-scalable resource doesn't give you a scalable REST service. It gives you a massively congested resource and a largely wasted scalable access mechanism. I've explained this at length in Brainstorming#Illusion of scalability (abstracting resources into clouds).
- Perhaps I can explain this better from a different angle. Sure, when implementing a REST service then the functional viewpoint does not require you to consider the implementation of the resource in question. But the functional viewpoint is only one of the viewpoints of interest to AWG: the other, and a very very big one, is the scalability viewpoint, and that requires examining the resource flow bottlenecks, decoupling them, and then recombining (or restructuring) them in such a way that the front-end REST mechanism can harness the now scalable resource. Both viewpoints are equally valid, and important, when designing a scalable REST service, but the former can be done while treating the resource as a black box, and the latter can't. (See IEEE-1471 for more.) --Morgaine Dinova 21:09, 10 October 2007 (PDT)
- This issue is now bypassed through the use of Viewpoint Advocacy Tasks (name still in flux). What you called normative concerns simply become the viewpoints of your particular VAT, which I expect you'll call something like REST Service Interfaces. Since everyone agrees that we're using REST, it doesn't need to be elevated to some special rank ... it becomes "core" simply because it's part of everyone's architectural worldview. --Morgaine Dinova 00:18, 12 October 2007 (PDT)
- I've added justifications for any work products being claimed as normative. My single entry is justified on the basis of being the primary stated goal of AWG. Everything else is pretty much a detail from that perspective, and could be discarded. This is why I believe that the whole idea of normative work products is ill-founded. System architecture (particular a huge one like this) is far more complicated than a simple division into normative and informational allows. --Morgaine Dinova 02:01, 14 October 2007 (PDT)