On Tue, Sep 9, 2008 at 1:06 AM, Nick Gall <[EMAIL PROTECTED]> wrote: > Perhaps I should call such a > restriction a "qualifying constraint" (if you have it you qualify) or > "categorical constraint" (it qualifies you for being categorized a certain > way). So a system can be excluded from the REST category either by lacking a > property or by achieving a property using a different combination of base > styles than U+LCODC$SS. > This would be in contrast to "design constraint" (that which produces a > particular set of architectural properties) -- which I think is the way you > are using the term Mark. If you still don't like my usage, substitute > "restriction" for "constraint" in what I am saying.
Yes, what you called a constraint above is most definitely not a software architectural constraint. But I disagree with what you say in the first quoted paragraph above. > From this generic point of view, one of Roy's > properties is a "constraint" because a system that lacked a property that > REST is supposed to have (eg scalability) would be excluded from the set of > systems deemed to be RESTful. Most properties aren't boolean though. And one cannot simply observe, say, a known scalable system and conclude that it is stateless, despite the fact that statelessness provides scalability. The only full proof means of testing RESTfulness is to check the software architectural constraints in use, not the properties or the "restrictions". > In this sense of "qualifying constraint", Gartner's definition of SOA is > "constrained" in the sense that one can analyze a range of systems for the > five properties (modular, distributable, described, sharable, and loosely > coupled) and get rough agreement on which systems have all five properties > (substantially) and are therefore considered SOA. It is NOT content-free. That's novel, and I agree it isn't content free. Mark.
