An Architecture style can be thought of as a family of related architectures or a pattern at the architecture level
An Architectural style is basically a set of
- Predefined components, roles, responsibilities and connectors (vocabulary)
- Constrains and guides on the use of the elements
If a style is documented it will probably have additional ingredients (like variations, examples, pros, cons etc.).
Architecture styles are used in a similar fashion to design patterns both as a common vocabulary and as design elements
To answer question 6 - yes styles can be mixed for example REST (Representational State Transfer) is a derived style mixing styles like Client-server and layered you've mentioned with constraints like use of uniform interface and stateless server.
There are many architecture styles - few notable ones (in addition to the ones you've mentioned) include pipes and filters, blackboard, hub and spoke, interpreter, MVC, Master-Slave and many many others.
Regarding question 5 - you would choose a style the same way you do any other architectural decision by weighing benefits and costs and evaluating tradeoffs - you can read a few post I've recently wrote on architecture evaluation:SAF - Architecture Evaluation (Introduction) , SAF - Architecture Evaluation - Evaluation in Code and SAF - Evaluation part II - the "Formal Methods" Also here's a link to an older post I made on Modeling - Architectural Styles
HTH,
Arnon
