Расширяемость. Возможность добавлять или удалять приложения с шины без влияния на существующие приложения.

Невысокая сложность. Приложения упрощаются, потому что каждому из них необходимо знать лишь, как обмениваться данными с шиной.

Гибкость. Приведение набора приложений, составляющих сложный процесс, или схем связи между приложениями в соответствие изменяющимся бизнес-требованиям или требованиям пользователя просто путем внесения изменений в конфигурацию или параметры, управляющие маршрутизацией.

Слабое связывание. Кроме предоставляемого приложением интерфейса для связи с шиной сообщений, нет никаких других зависимостей с самим приложением, что обеспечивает возможность изменения, обновления и замены его другим приложением, предоставляющим такой же интерфейс.

Масштабируемость. Возможность подключения к шине множества экземпляров одного приложения для обеспечения одновременной обработки множества запросов.

Простота приложения. Несмотря на то, что реализация шины сообщений усложняет инфраструктуру, каждому приложению приходится поддерживать лишь одно подключение к шине сообщений, а не множество подключений к другим приложениям.

Рассмотрите возможность применения архитектуры основанной на шине сообщений, если имеете существующие приложения, выполняющие задачи путем взаимодействия друг с другом, либо если хотите объединить множество шагов в одну операцию. Такой архитектурный стиль также подойдет при реализации решений, требующих взаимодействия с внешними приложениями или приложениями, размещенными в разных средах.

N-уровневая / 3-уровневая архитектура

N-уровневая и 3-уровневая архитектура являются стилями развертывания, описывающими разделение функциональности на сегменты, во многом аналогично многослойной архитектуре, но в данном случае эти сегменты могут физически размещаться на разных компьютерах, их называют уровнями. Данные архитектурные стили были созданы на базе компонентно-ориентированного подхода и, как правило, для связи используют методы платформы, а не сообщения.

Характеристиками N-уровневой архитектуры приложения являются функциональная декомпозиция приложения, сервисные компоненты и их распределенное развертывание, что обеспечивает повышенную масштабируемость, доступность, управляемость и эффективность использования ресурсов. Каждый уровень абсолютно независим от всех остальных, кроме тех, с которыми он непосредственно соседствует. N-ному уровню требуется лишь знать, как обрабатывать запрос от n+1 уровня, как передавать этот запрос на n-1 уровень (если таковой имеется), и как обрабатывать результаты запроса. Для обеспечения лучшей масштабируемости связь между уровнями обычно асинхронная.

N-уровневая архитектура обычно имеет не менее трех отдельных логических частей, каждая из которых физически размещается на разных серверах. Каждая часть отвечает за определенную функциональность. При использовании многослойного подхода слой развертывается на уровне, если предоставляемая этим слоем функциональность используется более чем одним сервисом или приложением уровня.

Примером N-уровневого/3-уровневого архитектурного стиля может служить типовое финансовое Веб-приложение с высокими требованиями к безопасности. Бизнес-слой в этом случае должен быть развернут за межсетевым экраном, из-за чего приходится развертывать слой представления на отдельном сервере в пограничной сети. Другой пример – типовой насыщенный клиент, в котором слой представления развернут на клиентских компьютерах, а бизнес-слой и слой доступа к данным развернуты на одном или более серверных уровнях.

Основными преимуществами N-уровневого/3-уровневого архитектурного стиля являются:

Удобство поддержки. Уровни не зависят друг от друга, что позволяет выполнять обновления или изменения, не оказывая влияния на приложение в целом.

Масштабируемость. Уровни организовываются на основании развертывания слоев, поэтому масштабировать приложение довольно просто.

Гибкость. Управление и масштабирование каждого уровня может выполняться независимо, что обеспечивает повышение гибкости.

Доступность. Приложения могут использовать модульную архитектуру, которая позволяет использовать в системе легко масштабируемые компоненты, что повышает доступность.

Рассмотрите возможность применения N-уровневой или 3-уровневой архитектуры, если требования по обработке уровней приложения отличаются настолько сильно, что может возникнуть перекос в распределении ресурсов, или существенно разнятся требования по безопасности уровней. Например, конфиденциальные данные не должны храниться на уровне представления, но могут размещаться на бизнес-уровне или уровне данных. N-уровневая или 3-уровневая архитектура также подойдет в случае, если требуется обеспечить возможность совместного использования бизнес-логики разными приложениями и имеется достаточное количество оборудования для выделения необходимого числа серверов для каждого уровня.

Используйте только три уровня, если создаете приложение для внутренней сети организации, где все серверы будут располагаться в закрытой сети; или Интернет-приложение, требования по безопасности которого не запрещают развертывание бизнес-логики на Веб-сервере или сервере приложений. Рассмотрите возможность применения более трех уровней, если соответственно требованиям по безопасности бизнес-логика не может быть развернута в пограничной сети, или если приложение интенсивно использует ресурсы, и для разгрузки сервера необходимо перенести эту функциональность на другой сервер.

Объектно-ориентированная архитектура

Объектно-ориентированная архитектура – это парадигма проектирования, основанная на разделении ответственностей приложения или системы на самостоятельные пригодные для

повторного использования объекты, каждый из которых содержит данные и поведение, относящиеся к этому объекту. При объектно-ориентированном проектировании система рассматривается не как набор подпрограмм и процедурных команд, а как наборы взаимодействующих объектов. Объекты обособлены, независимы и слабо связаны; обмен данными между ними происходит через интерфейсы путем вызова методов и свойств других объектов и отправки/приема сообщений. Основными принципами объектноориентированного архитектурного стиля являются:

Абстракция. Позволяет преобразовать сложную операцию в обобщение, сохраняющее основные характеристики операции. Например, абстрактный интерфейс может быть широко известным описанием, поддерживающим операции доступа к данным через использование простых методов, таких как Get (Получить) и Update (Обновить). Другая форма абстракции – метаданные, используемые для обеспечения сопоставления двух форматов структурированных данных.

Композиция. Объекты могут быть образованы другими объектами и по желанию могут скрывать эти внутренние объекты от других классов или предоставлять их как простые интерфейсы.

Наследование. Объекты могут наследоваться от других объектов и использовать функциональность базового объекта или переопределять ее для реализации нового поведения. Более того, наследование упрощает обслуживание и обновление, поскольку изменения, вносимые в базовый объект, автоматически распространяются на все наследуемые от него объекты.

Инкапсуляция. Объекты предоставляют функциональность только через методы, свойства и события и скрывают внутренние детали, такие как состояние и переменные, от других объектов. Это упрощает обновление или замену объектов и позволяет выполнять эти операции без влияния на другие объекты и код, требуется лишь обеспечить совместимые интерфейсы.

Полиморфизм. Позволяет переопределять поведение базового типа, поддерживающего операции в приложении, путем реализации новых типов, которые являются взаимозаменяемыми для существующего объекта.

Отделение. Объекты могут быть отделены от потребителя путем определения абстрактного интерфейса, реализуемого объектом и понятного потребителю. Это позволяет обеспечивать альтернативные реализации, не оказывая влияния на потребителей интерфейса.

Обычно объектно-ориентированный стиль используется для описания объектной модели, поддерживающей сложные научные или финансовые операции, либо описания объектов, представляющих реальные артефакты предметной области (такие как покупатель или заказ). Последнее чаще реализуется с применением более специализированного стиля проектирования на основе предметной области, который использует преимущества принципов объектно-ориентированной архитектуры. Более подробно об этом рассказывает раздел «Проектирование на основе предметной области» ранее в этой главе.

К основным преимуществам объектно-ориентированной архитектуры относятся:

Понятность. Обеспечивается более близкое соответствие приложения реальным объектам, что делает его более понятным.

Возможность повторного использования. Обеспечивается возможность повторного использования через полиморфизм и абстракцию.

Тестируемость. Обеспечивается улучшенная тестируемость через инкапсуляцию.

Расширяемость. Инкапсуляция, полиморфизм и абстракция гарантируют, что изменения в представлении данных не повлияют на интерфейсы, предоставляемые объектами, что могло бы ограничить возможности связи и взаимодействия с другими объектами.

Высокая связность. Размещая в объекте только функционально близкие методы и функции и используя для разных наборов функций разные объекты, можно достичь высокого уровня связности.

Рассмотрите возможность применения объектно-ориентированной архитектуры, если хотите моделировать приложение на базе реальных объектов и действий или уже имеете в своем распоряжении подходящие объекты и классы, соответствующие проектным и эксплуатационным требованиям. Объектно-ориентированный стиль также подойдет, если необходимо инкапсулировать логику и данные в компоненты, пригодные для повторного использования, или если имеется сложная бизнес-логика, которая требует абстракции и динамического поведения.

Сервисно-ориентированная архитектура

Сервисно-ориентированная архитектура (Service-oriented architecture, SOA) обеспечивает возможность предоставлять функциональность приложения в виде набора сервисов и создавать приложения, использующие программные сервисы. Сервисы слабо связаны, потому что используют основанные на стандартах интерфейсы, которые могут быть вызваны, опубликованы и обнаружены. Основная задача сервисов в SOA – предоставление схемы и взаимодействия с приложением посредством сообщений через интерфейсы, областью действия которых является приложение, а не компонент или объект. Не следует рассматривать SOA-сервис как компонентный поставщик сервисов.

SOA-архитектура может обеспечить упаковку бизнес-процессов в сервисы, поддерживающие возможность взаимодействия и использующие для передачи информации широкий диапазон протоколов и форматов данных. Клиенты и другие сервисы могут выполнять доступ к локальным сервисам, выполняющимся на том же уровне, или к удаленным сервисам по сети.

Основными принципами архитектурного стиля SOA являются:

Сервисы автономны. Обслуживание, разработка, развертывание и контроль версий каждого сервиса происходит независимо от других.

Сервисы могут быть распределены. Сервисы могут размещаться в любом месте сети, локально или удаленно, если сеть поддерживает необходимые протоколы связи.

Сервисы слабо связаны. Каждый сервис совершенно не зависит от остальных и может быть заменен или обновлен без влияния на приложения, его использующие, при условии предоставления совместимого интерфейса.

Сервисы совместно используют схему и контракт, но не класс. При обмене данными сервисы совместно используют контракты и схемы, но не внутренние классы.

Совместимость основана на политике. Политика, в данном случае, означает описание характеристик, таких как транспорт, протокол и безопасность.

Типовые сервисно-ориентированные приложения обеспечивают совместное использование информации, выполнение многоэтапных процессов (системы резервирования и онлайнмагазины), предоставление специальных отраслевых данных или сервисов между организациями и создание составных приложений, которые объединяют данные из многих источников.

Основными преимуществами SOA-архитектуры являются:

Согласование предметных областей. Повторное использование общих сервисов со стандартными интерфейсами расширяет технологические и бизнес-возможности, а также сокращает стоимость.

Абстракция. Сервисы являются автономными, доступ к ним осуществляется по формальному контракту, что обеспечивает слабое связывание и абстракцию.

Возможность обнаружения. Сервисы могут предоставлять описания, что позволяет другим приложениям и сервисам обнаруживать их и автоматически определять интерфейс.

Возможность взаимодействия. Поскольку протоколы и форматы данных основываются на отраслевых стандартах, поставщик и потребитель сервиса могут создаваться и развертываться на разных платформах.

Рационализация. Сервисы обеспечивают определенную функциональность, устраняя необходимость ее дублирования в приложениях.

Рассмотрите возможность применения SOA-подхода, если имеете доступ к сервисам, которые желаете повторно использовать; можете приобрести подходящие сервисы у компании, предоставляющей услуги хостинга; хотите создать приложения, объединяющие различные сервисы в один UI; или создаете приложения в модели ПО + сервисы (Software plus Services, S+S), ПО как сервис (Software as a Service, SaaS) или приложения для размещения в облаке. SOA-стиль подходит, если требуется поддерживать связь посредством обмена сообщениями между сегментами приложения и предоставлять функциональность независимо от платформы, если хотите использовать интегрированные сервисы, такие как аутентификация, или хотите предоставлять сервисы, видимые в каталогах, с возможностью использования клиентами, которые заранее ничего не знают об интерфейсах.