[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<snip/>
> I think that I want to emphasize Mark Baker's point about constraints,
> with a quote from the dissertation:
>
> "There are two common perspectives on the process of architectural
> design, whether it be for buildings or for software. The
> first is that a
> designer starts with nothing--a blank slate, whiteboard, or drawing
> board--and builds-up an architecture from familiar components until it
> satisfies the needs of the intended system. The second is that a
> designer starts with the system needs as a whole, without constraints,
> and then incrementally identifies and applies constraints to
> elements of
> the system in order to differentiate the design space and allow the
> forces that influence system behavior to flow naturally, in
> harmony with
> the system. Where the first emphasizes creativity and
> unbounded vision,
> the second emphasizes restraint and understanding of the
> system context.
> REST has been developed using the latter process."
I find this to be an interesting quote. It seems to me that in the field of
enterprise application development, there has been a clear trend toward this
second approach. J2EE strikes me as a good example of this. J2EE defines an
architectural framework that compels the implementor to implement *managed*
components, with the framework defining how that component interacts with
key infrastructural services (for naming, transaction management, lifecycle
management of components, etc.). Before J2EE, many OO frameworks adopted
similar approaches. The intent seems to be to take certain infrastructural
aspects of applications that can be generalized, and incorporate them into
frameworks that implement proven, best-practices approaches, releaving the
business developer of having to think of these aspects (and potentially
stumbling over them) and to focus more on business logic. These also seem
intended to permit the deployment and use of shared, generalized services
that can apply consistent policies across the enterprise (and beyond?).
J2EE is API-centric, though; not protocol-centric. For web development, the
APIs generally suck and have never achieved a similar level of
sophistication. The most they tend to offer is cookie-based session and some
template technology, then you're on your own from there. (There have been
some interesting attempts to offer richer frameworks, such as Cocoon. I'm
not familiar enough with these alternatives to judge how much the facilitate
the "resource modelling" part of the app, though.) The thought of an
API-centric framework explicitly architected for modelling an application as
REST resources strikes me as something that could really raise the level of
web development.
I wish I had more free time to work on such a thing.
|
