Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
