<Jan Algermissen> That is because SOA is not an architectural style but a domain model Design approach. It it was an architectural style, one would be able to enumerate its software architectural constraints. </Jan Algermissen>
IEEE defines architecture as the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. Using this definition, SOA is an architectural style that is guided by a set of design principles. As to what those design principles are, you will get different variations from different folks, but I've always found the 8 given by Erl in his book to be a good starting point. - Formal Contract - Discoverbility - Statelessness - Reusability - Composability - Autonomous - Loose Coupling - Abstraction As to what degree one emphasizes or de-emphasizes each depends on the perspective that one brings to the table. Regards, - Anil :- :- Anil John :- http://www.aniltj.com/blog :- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
