Лекция. Границы архитектурного проектирования по. План

Software Connectors

Соединители в программной архитектуре уточняются в процессе проектирования и находятся под сильным влиянием среды развертывания проекта. В наиболее абстрактной форме соединитель указывает на необходимость во время выполнения системы для одного из элементов отправить сообщение другому элементу и потенциально получить ответное сообщение. Во время уточнения архитектуры ПО, если два элемента сопоставлены с одним процессом, соединитель может быть сопоставлен с локальным вызовом метода. Если два элемента сопоставлены двум разным процессам на одном компьютере, соединитель может быть сопоставлен с локальной очередью сообщений или каналом. Если два элемента сопоставлены двум разным компьютерам, то для уточнения соединителя между ними можно использовать удаленный вызов метода или вызов веб-службы.
Программные соединители классифицируются по многим атрибутам, включая режим синхронизации, инициатор, тип реализации, активный промежуток времени, разветвление, носитель информации и среду. Основываясь на режиме синхронизации соединителя, мы можем классифицировать все соединители на две категории: блокирующие соединители и неблокирующие соединители, как показано на рисунке 2.2 (а). Блокирующий соединитель позволяет одному из его элементов инцидента отправлять запрос (вызов метода или сообщение) другому и ожидать ответа (возвращаемое значение метода или сообщение). Элемент будет заблокирован от дальнейшего выполнения, пока не получит ответ. Неблокирующий соединитель позволяет одному из его инцидентных элементов отправить запрос (вызов метода или сообщение) другому, а затем продолжить его выполнение, не ожидая ответа.
Основываясь на инициаторе соединителя, мы можем классифицировать все соединители на две категории: соединители с одним инициатором и соединители с двумя инициаторами, как показано на рисунке 2.2 (b). Инициатор – это элемент инцидента соединителя, который может сделать запрос своему партнеру. Соединитель с одним инициатором позволяет только одному из двух инцидентных элементов сделать запрос другому элементу, но не наоборот.
Соединитель с двумя инициаторами позволяет любому из двух инцидентных элементов сделать запрос другому элементу. Чтобы система поддерживала обратный вызов между двумя подсистемами, эти две подсистемы должны быть соединены соединителем с двумя инициаторами.

Информационный поток на соединителе может быть реализован с использованием различных носителей информации, как показано на рисунке 2.2 (с). Если два элемента инцидента находятся в одном процессе, скажем, как два потока, они могут использовать общую переменную для обмена информацией. Если они отображаются на разные процессы на одном и том же процессоре, то для реализации соединителя могут использоваться такие ресурсы, как каналы, файлы или локальные очереди сообщений. Вызовы методов и передача сообщений являются более распространенными и более структурированными способами передачи информации. Удаленный вызов метода и обмен сообщениями также могут обеспечивать связь между элементами, развернутыми на разных процессорах. На рисунке 2.3 показано, что система сообщений, состоящая из модуля отправителя сообщения и модуля приема сообщения, соединенных сетью, используется для реализации соединителя с одним инициатором для подсистемы 1 для отправки сообщений / запросов в подсистему 2. Формат сообщения должен быть определяется так, что отправитель и получатель могут понимать сообщения, и должен быть принят протокол для определения правильного установления связи и синхронизации между двумя сторонами. Два маленьких кружка в стрелках, соединяющих систему сообщений с двумя подсистемами, представляют два интерфейса, которые соединяют систему сообщений с ее инцидентными элементами.

На основе типа реализации соединитель может быть классифицирован как основанный на подписи или на основе протокола, как показано на рисунке 2.2 (d). Для соединителей на основе подписи имя метода указывает на операцию, а параметры содержат значения аргументов для выполнения операции. Если мы назначим один или несколько параметров метода для указания типов операций, соединитель может использоваться для реализации протоколов.

В то время как соединители на основе подписи могут использоваться только для запроса одного типа операции, соединитель на основе протокола может реализовывать несколько типов операций с одной подписью привязки. Кроме того, основанный на протоколе соединитель может поддерживать новые типы операций после исправления системных интерфейсов. Соединители между подсистемой интерпретатора и ее клиентскими подсистемами основаны на протоколе. Соединители на основе сообщений поддерживают более гибкие формы протоколов, в которых вся информация об операциях, аргументах и возвращаемых значениях кодируется в форматах сообщений и соглашениях о подтверждении связи между участвующими сторонами. Протокол HTTP между веб-серверами и веб-браузерами является знакомым примером реализации соединителя на основе протокола.
Время активности соединителя относится к тому моменту, когда по соединителю отправляется запрос операции или сообщение. Соединители могут быть классифицированы на запрограммированные соединители и управляемые событиями разъемы, как показано на рисунке 2.2 (e). Обычно вызов метода выполняется во время, заданное во время программирования: когда выполнение приходит к строке определенного метода, выполняется вызов другого метода. Но для систем реального времени, реактивных систем и любой системы с графическим пользовательским интерфейсом модель программирования на основе событий становится гораздо более гибким механизмом соединения. Один элемент будет функционировать в качестве источника события, и все элементы, которые должны быть уведомлены о событии, будут зарегистрированы как слушатели источника события. Когда событие происходит, все зарегистрированные элементы слушателя будут уведомлены о потенциальной реакции.

Обратный вызов метода можно считать частным случаем этого механизма, управляемого событиями. Один элемент вызывает метод другого элемента, причем один из его параметров передает ссылку на объект обратного вызова / метод (объект слушателя). Когда в последнем элементе происходит какое-либо событие, он использует сохраненную ссылку для обратного вызова и уведомления первого элемента. Управляемые событиями соединители поддерживают позднюю привязку между подсистемами.
Основанный на соединителе промежутка (span) между соединяющими элементами мы классифицируем соединители как локальные или сетевые, как показано на рисунке 2.2 (f). Этот атрибут соединителя зависит от того, расположены ли элементы инцидента в одном процессоре. Этот атрибут имеет большое влияние на технологии реализации соединителя. Сетевые коннекторы обычно реализуются с использованием шаблона проектирования прокси-сервера для поддержки парадигмы объектно-ориентированного программирования в распределенной среде. Предположим, что существует один инициатор и сетевой соединитель от подсистемы 1 к подсистеме 2, и подсистема 2 предоставляет интерфейс для вызова подсистемой 1. Пара объектов прокси и скелета будет сгенерирована из интерфейса некоторым технологически зависимым инструментом, и они будут связаны системой сообщений, как показано на рисунке 2.4. Прокси-объект предоставляет тот же интерфейс, что и подсистема 2, и он расположен в том же процессе, что и подсистема 1. Подсистема 1 создает иллюзию того, что прокси-объект - это подсистема 2, развернутая в том же процессе. Когда подсистема 1 вызывает метод прокси-объекта, тело метода отправляет операцию и аргументы своему партнеру-скелетону, который развернут в том же процессе, что и подсистема 2, по сети через систему сообщений. Затем скелет выполнит соответствующий локальный вызов метода для подсистемы 2 и отправит возвращаемое значение или любые исключения обратно прокси-объекту через систему сообщений. Затем прокси-объект отправит полученное возвращаемое значение как собственное подсистеме 1. Одним из основных преимуществ этого подхода является то, что ни одна из подсистем не должна быть подключена к сети во время их проектирования и реализации.
Основанный на соединителе разветвления (fan-out) (количество элементов, к которому может подключиться один элемент), мы классифицируем соединители как соединители 1-1 и 1- *, как показано на рисунке 2.2 (g). Разъемы 1-1 предназначены только для подключения двух элементов. Разъемы 1- * предназначены для соединения одного элемента с переменным количеством элементов одного типа. Например, веб-сервер и веб-браузеры подключены с помощью соединителя 1- *, так же как сервер и клиенты в архитектуре клиент-сервер. Атрибут разветвления (fan-out) соединителя может существенно повлиять на технологию и производительность реализации соединителя.
Основанный на соединителе среды, которая является технологией реализации или поддерживающей платформы двух падающих элементов соединителя, мы классифицируем соединители на однородные соединители и разнородные соединители, как показано на рисунке 2.2 (h). Инцидентные элементы однородного соединителя реализованы на одном языке программирования и в программной среде и работают в одной операционной системе. Инцидентные элементы гетерогенного соединителя могут быть реализованы с использованием разных языков программирования или программных сред и могут работать в разных операционных системах. CORBA, веб-сервисы и обмен сообщениями являются типичными технологиями реализации гетерогенных соединителей.
Гетерогенные соединители обычно реализуются с использованием шаблона проектирования брокера. Это означает, что система сообщений может быть реализована с модулями отправителя и получателя сообщений, реализованными на разных языках программирования или на разных платформах. Предположим, что две подсистемы на рисунке 2.4 реализованы на разных языках программирования и развернуты на разных платформах двух сетевых компьютерных систем. Это иллюстрирует шаблон проектирования брокера со следующими модификациями.
Во-первых, объект-посредник и модуль отправителя сообщения будут реализованы на одном и том же языке программирования и запущены в той же компьютерной системе, что и подсистема 1. Скелетный объект и модуль-получатель сообщения будут реализованы на одном языке программирования и будут выполняться в той же компьютерной системе, что и подсистема 2.
Во-вторых, будет определен протокол уровня приложения для представления операций и значений аргументов независимо от платформы и языка. И прокси-объект, и скелетный объект будут поддерживать маршалинг данных (преобразование данных из формы, зависящей от платформы или языка, в платформенно-независимую от языка форму) и демаршалинг (преобразование данных из формы, не зависящей от платформы и языка, в платформа и язык-зависимая форма). Когда прокси-объект получает вызов метода из подсистемы 1, он упорядочивает значения аргументов и отправляет результирующие значения и имя операции в каркасный объект на другой стороне сети, который будет демаршировать значения аргументов в форму, используемую подсистемой. 2. Получив возвращаемое значение, каркасный объект упорядочит его и отправит обратно прокси-объекту, который затем демонтирует возвращаемое значение в форму, используемую подсистемой 1, и вернет ее в качестве собственного возвращаемого значения.