Инфраструктура координационных протоколов

Программы, предназначенные для выполнения разговоров служб, называются контроллерами разговоров. Их функциональность имеет двойную направленность: они маршрутизируют разговоры и верифицируют их соответствие протоколу. Обычно контроллеры разговоров включаются в состав маршрутизаторов SOAP. Маршрутизация разговоров связана с проблемой диспетчеризации сообщений: необходимо, чтобы эти сообщения попадали нужным внутренним объектам. При получении сообщения служба определяет, к какому разговору сообщение относится, и как это сообщение надо обрабатывать, что зависит от состояния разговора. Контроллер разговоров может справляться с этим, включением в заголовки каждого пересылаемого сообщения уникального для данного разговора идентификатора. Такой идентификатор должен генерироваться каждый раз в начале нового разговора, и при получении контроллером сообщения должен в нем отыскиваться, указывая на объект (например, компонент EJB сервера приложений J2EE), которому сообщение направлено.

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

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

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

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

2. Модуль управления протоколами и сетевые службы совместно реализуют протокол. Например, в случае протокола 2PC программы доставки/получения подготовительных сообщений, подтверждений и отмен реализуются системными средствами. Принятие решения о подтверждении или отмене транзакции и программы, реализующие эти операции (например, что означает "подтвердить"), выполняются сетевыми службами, которые должны понимать настоящую логику процесса.

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

Реализация горизонтальных протоколов в слое системной поддержки, а не в самой сетевой службе, накладывает ряд дополнительных требований. Для обмена сообщениями службы должны знать порты друг друга. Эти порты могут разыскиваться в процессе привязки (например, с помощью реестров UDDI). Однако, если реализация протокола передана в системный слой, розыском портов должны заниматься модули управления протоколами. Необходимо иметь механизм передачи в систему сведений о портах.

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

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

Таким образом, широкое использование средств системной поддержки взаимодействия сетевых служб может начаться с полноценного всеобщего принятия стандартов, определяющих это взаимодействие. Одним из таких стандартов, предложенным компаниями IBM, Microsoft и BEA в августе 2002 года, является стандарт WS-Coordination, определяющий:

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

· Метод передачи контроллерам разговоров сведений о портах участников разговоров. Для этого стандарт определяет интерфейс регистрации портов.

· Метод передачи контроллерам разговоров сведений о ролях, которые они должны играть в разговоре. Для этого стандарт определяет интерфейс активации.

Важнейшее место в стандарте WS-Coordination занимают понятия "координатор" и "участник". Для описания взаимодействий между координатором и участниками стандарт WS-Coordination вводит три абстракции:

· Координационный протокол есть набор правил управления разговорами координатора с участниками (например, 2РС).

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

· Координационный контекст – это структура данных, используемая для отметки сообщений, относящихся к одному разговору (в протоколе WS-Coordination это называется "к одной координации").

Стандарт WS-Coordination определяет три формы взаимодействий между координатором и участниками:

Активация. Участник требует от координатора создать новый координационный контекст. Новые контексты создаются всякий раз, когда участник создает новый экземпляр координационного типа (разговор), например, когда сетевая служба начинает атомарную транзакцию.

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

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