Определение ограничений развертывания
При проектировании архитектуры приложения необходимо учесть корпоративныеполитики и процедуры, а также среду, в которой планируется развертывание приложения. Если целевая среда является фиксированной или негибкой, то архитектура приложения должна отражатьсуществующие в этой среде ограничения. Также должны быть учтенынефункциональные требования, такие как безопасность, надежностьи др. Можно выделить следующие основные ограничения развертывания.
Ограничения по аппаратным требованиям. Например, необходимо использовать процессоры, поддерживающие определенныетехнологии.
Ограничения по программным требованиям. Например, использование конкретной операционной системы.
Ограничения собственно по развертыванию. Возможна ситуацияс использованием отдельного сервера для установки приложения, либо покупки места для сервера у поставщиков таких услуг. Можновыделить ограничения пропускной способности канала, размеровдоступной оперативной памяти, если развертывание будет происходить на системе, где невозможно делать аппаратные изменения.
Повышенные требования безопасности. Данные требованиямогут ограничить возможные места расположения серверов, либопотребуется использование дополнительных аппаратных (программных) средств для обеспечения требуемого уровня надежности системы.
Тема 11. Архитектурные стили проектирования
План лекции
1. Типовые архитектурные стили
2. Клиент-серверная архитектура
3. Компонентная архитектура
4. Проблемно-ориентированное проектирование
5. Многослойная архитектура
6. Архитектура на основе канала сообщений
7. N-уровневая/3-уровневая архитектура
8. Объектно-ориентированная архитектура
9. Сервисно-ориентированная архитектура
Типовые архитектурные стили
Архитектурный стиль (парадигма) может рассматриваться какобобщенный шаблон для проектирования архитектуры ПО, опирающийся на некий набор принципов и обеспечивающий абстрактнуюбазу для определенного семейства систем. Каждый стиль определяетнабор правил, которые задают типы компонентов, используемых длякомпоновки системы, и типы отношений, применяемых при компоновке, а также ограничения по способам компоновки и допущенияо ее семантике.
Архитектура ПС практически никогда не ограничена лишь однимархитектурным стилем и, как правило, сочетает в себе несколькоархитектурных стилей. В таблице11.1 приводится список типовых архитектурных стилей, рассматриваемых в данной теме, и дается краткоеописание каждого из них.
Сочетание архитектурных стилей крайне полезно при построенииWeb-приложений, где можно достичь эффективного разделенияфункциональности за счет применения многослойного архитектурного стиля. Таким образом, можно отделить логику представленияот бизнес-логики и логики доступа к данным. Требования безопасности организации могут обусловливать либо 3-уровневое развертывание приложения, либо развертывание более чем с тремя уровнями. Уровень представления может развертываться в пограничной сетирасполагающейся между внутренней сетью организации и внешнейсетью. В качестве модели взаимодействия на уровне представленияможет применяться шаблон представления с отделением (разновидность многослойного стиля), такой как Model-View-Controller (MVC).
Таблица11.1. Типовые архитектурные стили
Архитектурный стиль (парадигма) | Описание |
Клиент-серверная архитектура | Система разделяется на клиентскую и серверную части, где клиент посылает запросык серверу. Во многих случаях в роли серверавыступает сервер БД, а логика приложенияпредставлена процедурами хранения |
Компонентная архитектура | Дизайн приложения разлагается на функциональные (логические) компонентыпредоставляющие тщательно проработанныеинтерфейсы связи, с возможностью их повторного использования |
Проблемно-ориентированное проектирование (дизайн на основе предметной области) | Объектно-ориентированный стиль, ориентированный на моделирование сферы деловойактивности и определяющий бизнес-объектына основании сущностей данной предметнойобласти |
Многослойная архитектура | Функциональные области приложения разделяются на многослойные группы (уровни) |
Архитектура на основеканала сообщений | Стиль, предписывающий использованиеПС, которая может принимать и отправлятьсообщения по одному или более каналамсвязи. Приложения получают возможностьвзаимодействия, не располагая конкретнымисведениями друг о друге |
N-уровневая/3 уровневая архитектура | Функциональность выделяется в отдельныесегменты, во многом аналогично многослойному стилю, но сегменты физически располагаются на разных компьютерах (уровнях) |
Объектно-ориентированная архитектура | Парадигма проектирования, основанная нараспределении ответственности приложения(системы) между отдельными, многократноиспользуемыми и самостоятельными объектами, содержащими данные и правилаповедения |
Сервисно-ориентированная архитектура(SOA) | Описывает приложения, предоставляющиеи потребляющие функциональность в видесервисов с помощью контрактов и сообщений |
Также можно выбрать архитектурный стиль SOA и реализовать связьмежду Web-сервером и сервером приложений посредством обменасообщениями.
На выбор архитектурных стилей оказывает влияние множествофакторов, например, способность организации к проектированию иреализации, возможности и опыт разработчиков, а также ограничения инфраструктуры и организации. Рассмотрим каждый архитектурный стиль более подробно.