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

• Название: Учебное пособие издано при поддержке образовательной программы Формирование
• Анкор: Архитектура распределенных систем программного обеспечения
• Дата: 13.01.2023
• Размер: 1 Mb.
• Имя файла: mdwrbook.docx
• Тип: Учебное пособие; #885216
• страница: 26 из 36

Работа сетевой службы

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

транслироваться в описание сетевой службы (шаг 1 на Рис. 4.16). В большинстве существующих систем привязка проводится к протоколу SOAP и сетевому адресу машины, на которой работает система управления базы данных.




Полученный текст на WSDL хранится у поставщика службы. Компилятор языка WSDL создает серверный переходник (обычно в виде сервлета) и регистрирует его на маршрутизаторе SOAP. Теперь маршрутизатор знает, что при обращении к определенному ресурсу он должен вызвать зарегистрированный переходник (шаг 2 на Рис. 4.16). В свою очередь переходник будет вызывать исходный объект (в этом случае

– хранимую процедуру базы данных). Этим завершается реализация сетевой службы. Служба стала вполне работоспособной, ее можно вызывать, но клиентское приложение реестра UDDI должно выполнить последний шаг (шаг 3 на Рис. 4.16), состоящий из двух этапов. Первый этап заключается в публикации в некотором реестре технической модели, ссылающейся на автоматически полученное описание на языке WSDL. Реестр должен быть доступен тем клиентам, для которых готовится служба. Второй этап заключается в публикации полноценной записи в

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

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

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

Другой типичный сценарий работы с сетевыми службами возникает при использовании стандартизированных интерфейсов сетевых служб. Отличается он тем, что тексты на WSDL извлекаются из реестров UDDI. Для этого нужно использовать технические модели соответствующих обзорных документов реестров. По извлеченным описаниям компилятор WSDL может генерировать программы, требующиеся на серверной стороне. В мире Java это приводит к генерации сервлета, который нужно зарегистрировать в маршрутизаторе SOAP, и интерфейса на языке Java, который реализуется службой. После реализации службы объект регистрируется в маршрутизаторе SOAP, и служба становится доступной. Ее публикация в реестре UDDI проводится как и раньше, только теперь не требуется публиковать техническую модель, которая уже имеется в реестре.

7. Координация работы сетевых служб

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

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

Для описания протоколов координации служб важным является понятие "роли". Участники взаимодействия "играют" свои роли, обмениваясь сообщениями. Протокол накладывает ограничения на порядок, в котором такой обмен может происходить. В отличие от термина "разговор", который относится ко всякой последовательности операций (обменов сообщениями), могущей возникнуть между клиентом и службой в процессе обращения к службе, термин "координационный протокол" относится именно к спецификации набора правильных (допустимых) разговоров. Важно иметь стандартизованный способ описания координационных протоколов, который позволил бы разрабатывать программное обеспечение для автоматической поддержки и управлять разговорами с сетевыми службами. Существующие попытки стандартизации, в частности, стандарт языка WSCL пока не получили достаточной поддержки, поэтому для описания координационных протоколов применяются различные модели.

Среди используемых моделей выделяются две: модель диаграмм последовательности и модель диаграмм активности. На Рис. 4.17 приведено описание разговора трех сетевых служб.
1: запросПеречня


2: заказТоваров
4: подтверждениеЗаказа

5: проведениеПлатежа


7: получениеДеталейПоставки
6: заказПоставки

3: проверкаВозможностиПоставки
8: подтверждениеПоставки

9: подтверждениеПоставки

Рис.4.17.Последовательностьобменасообщениямитрехсетевыхслужбпри отработке заказа на приобретение товара.

Диаграммы последовательности (Рис. 4.18) распространены именно ввиду их простоты и интуитивной понятности, однако, чем сложнее протокол, тем сложнее становится разобраться в этих диаграммах. Например, если бы потребовалось ввести еще одного участника взаимодействия (на стадии выяснения наличия товара на складе им мог бы быть еще один склад, оптовый) или провести дополнительные переговоры с заказчиком об изменении даты поставки, возникли бы еще несколько разговоров, параллельных первому. Иногда так и поступают, прорисовывая несколько диаграмм (такая практика используется также при описании протокола TCP), но это удобно лишь при наличии небольшого количества альтернатив, иначе диаграмм становится слишком много. В последнее время все большую популярность приобретают диаграммы активности (Рис. 4.19), с их помощью удобно демонстрировать альтернативные и параллельные ветви разговоров.

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




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

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

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



Рис.4.19.Диаграммаактивностиразговора,показанногонаРис.4.17.

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

Координационные протоколы сетевых служб делятся на вертикальные и горизонтальные. Вертикальные протоколы относятся к отдельным отраслям (и называются бизнес протоколами). Обычно в них описывается, каким образом следует строить конкретные бизнес транзакции, определяются форматы соответствующих документов,

семантика содержимого этих документов. Протокол, проиллюстрированный на Рис. 4.17-4.19, тоже является вертикальным.

Многие важные детали реализации (как проводить обмен сообщениями) часто в вертикальных протоколах отсутствуют, они больше концентрируются на семантике обменов, а также на наборах правильных разговоров. Детали – это то, с чем имеют дело горизонтальныепротоколы, в которых определяется общая инфраструктура, независящая от прикладной области. Однако сетевые службы предназначены для взаимодействия не внутри, а между предприятиями, и многие ранее разработанные методы для них не пригодны. В частности, из-за длительности взаимодействия протоколы подтверждения типа 2РС использоваться не могут, так как они в момент этого подтверждения блокируют ресурсы. Следует разрабатывать новые стандарты (уже разработаны стандарты WS-Coordination, WS-Transaction).