On 12/7/07, Michael Champion <mc@x...> wrote:
> SOA has no constraints on operators,  but in practice operators are late
> bound via service definitions and operands are fairly stongly typed by
> schemas/data contracts.

But what kind of constraint is that and what architectural properties
does it induce?  AFAICT it's not a constraint because whether a
service has a description or not doesn't matter a wink to the runtime
architecture of the system.  Consider that once your system was
running, you could safely delete all the service descriptions and it
would continue to run.

> ROA tightly constrains operators, but has no constraints on operands (i.e.
> "resource representations" other than MIME types I suppose).

Off the top of my head, REST requires that representations include
hyperlinks if the information it contains should be able to progress
the application state machine.

> There is beauty in both views of life. What we need in my opinion is a
> deeper and more empirical understanding of which set of architecural
> constraints and non-constraints is most associated with the various,
> somewhat conflicting values of "scalability, evolvability, visibility,
> simplicity, etc."

I agree that more work is needed here, but there's some to work from.
The REST dissertation has some good info.

But I don't believe that's holding us back.  What is IMO, is truly
appreciating the value of constraints in general.  I remember having a
hell of a time in WS-Arch, trying to convince people this was a useful
model for understanding and comparing software architectures.  We
never did agree to use it.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com