9.1.2. Связь

Исходно CORBA имеет простую модель связи: клиент обращается к методу объ­екта и ожидает ответа. Эта модель разрабатывалась так, чтобы быть как можно проще, но при необходимости существовала возможность добавлять к ней допол­нительные методы взаимодействия. В связи с этим мы особо рассмотрим обраще­ние к средствам в CORBA, обсудив также альтернативы подобного обращения к объектам. Как мы увидим, расширения базовой модели обращения к объекту вы­зываются необходимостью поддержания асинхронного взаимодействия. Эта не­обходимость вызывается также фактом существования других моделей передачи сообщений, которые мы обсуждали в главе 2.

Модели обращения к объектам

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

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

Следовательно, синхронные обращения полезны, когда клиенту нужно дож­даться ответа. Если возвращается правильный результат, CORBA гарантирует, что метод был выполнен ровно один раз. Однако в том случае, когда ответ не требуется, для клиента лучше просто вызвать метод и как можно быстрее про­должить выполнение. Этот тип обращения соответствует асинхронному вызову RPC, который мы обсуждали в главе 2.

В CORBA такой тип асинхронных обращений именуется односторонним за­просом (one-way request). Метод может быть определен как односторонний толь­ко в том случае, если он не возвращает результата. Однако в отличие от гаранти­рованной доставки асинхронных вызовов RPC, односторонние запросы CORBA предполагают наличие только службы доставки «с максимальными усилиями» (best effort delivery). Другими словами, отправитель не получает никаких гаран­тий того, что запрос будет доставлен серверу объектов.

Кроме односторонних запросов CORBA поддерживает также механизм так называемого отложенного синхронного запроса (deferred synchronous request). Та­кой запрос, который фактически является вариантом одностороннего запроса, позволяет серверу возвращать результат клиенту асинхронно. После того как клиент посылает серверу свой запрос, он может, не дожидаясь ответа, сразу же продолжать работу. Другими словами, клиент не знает, был его запрос в дейст­вительности доставлен серверу или нет.

Эти три различных модели обращения обобщены в табл. 9.2.

Службы событий и уведомлений

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

Результатом является определение службы событий (event service). Базовая модель событий в CORBA очень проста. Каждое событие ассоциируется с еди­ничным элементом данных, обычно представленным в виде ссылки на объект или же значением, характерным для данного приложения. Событие генерирует поставщик (supplier) и получает потребитель (consumer). События доставляются по каналу событий (event channel), логически связывающего поставщика и по­требителя, как показано на рис. 9.3.

На рисунке показана так называемая модель продвижения (push model). Со­гласно этой модели при возникновении определенной ситуации поставщик гене­рирует событие и продвигает его через канал событий, по которому событие до­ставляется потребителям. Модель продвижения напоминает асинхронный режим работы, который часто ассоциируют с событиями. На практике потребители пас­сивно ожидают прихода события, полагая, что при возникновении события их работа будут так или иначе прервана.

Альтернативная модель, также поддерживаемая CORBA, — это модель извле­чения (pull model), продемонстрированная на рис. 9.4. Согласно этой модели по­требители опрашивают канал событий, проверяя, не произошло ли ожидаемое событие. Канал событий, в свою очередь, опрашивает поставщиков событий.

Хотя служба событий имеет простой и надежный способ распространения со­бытий, у него есть несколько серьезных недостатков. Для распространения собы­тий необходимо, чтобы поставщики и потребители были соединены с каналом событий. Это также означает, что если потребитель соединится с каналом после того, как событие произошло, это событие будет потеряно. Другими словами, служба сообщений CORBA не обеспечивает сохранности событий.

Очень важно, что потребители не в состоянии предпринять каких-либо мер для фильтрации событий. Любое событие, в принципе, пересылается всем потре­бителям. Если необходимо выделять различные типы событий, нужно создавать отдельные каналы событий для каждого из этих типов. Средства фильтрации имеются в расширении [325], известном под названием службы уведомлений (notification service). Помимо всего прочего эта служба содержит средства для предотвращения распространения событий, в которых не заинтересован ни один из потребителей.

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

Передача сообщений

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

Хорошо известна такая модель сохранной связи, как очереди сообщений. CORBA поддерживает эту модель в виде дополнительной службы сообщений (messaging service). Обмен сообщениями в CORBA отличается от других систем объектным подходом к взаимодействию. В частности, проектировщики службы сообщений вынуждены были соблюсти условие обязательности обращений к объектам при любом взаимодействии. В случае обмена сообщениями эти ограни­чения привели к появлению двух дополнительных видов асинхронного обраще­ния к методам.

В модели обратного вызова (callback model) клиент представляет собой объ­ект, реализующий интерфейс, в котором содержатся методы обратного вызова. Базовая коммуникационная система может вызвать эти методы для передачи результата асинхронного обращения. Важная особенность этой модели состоит в том, что асинхронные обращения к методу не влияют на исходную реализацию объекта. Другими словами, преобразовать исходное синхронное обращение в асин­хронное — задача клиента; сервер делает обычный (синхронный) вызов.

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

В качестве примера рассмотрим объект, реализующий простой интерфейс с единственным методом:

int addCin int i. in int j. out int k):

Предположим, что этот метод (который мы описали на IDL для CORBA) по­лучает два неотрицательных целых числа i и j и возвращает i+j в выходном пара­метре к. Операция должна возвращать -1 в случае неудачного завершения. Пре­образование исходного (синхронного) обращения к методу в асинхронное путем обратного вызова происходит так: сначала создается пара описаний методов (для нашей задачи мы предпочли удобство имен строгим правилам именования [331]):

void sendcb_add(in int i. in int j); // Вызывается клиентом

void replycb_add(in int retj/al. in int k); // Вызывается клиентским ORB

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

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

В качестве альтернативы обратному вызову CORBA поддерживает модель опроса (polling model). Согласно этой модели клиенту предоставляется набор операций для опроса своего брокера ORB на предмет наличия поступивших результатов. Как и в модели обратного вызова, за преобразование синхронного обращения к методу в асинхронное отвечает клиент. И снова большую часть ра­боты можно выполнять автоматически, отталкиваясь от спецификации соответ­ствующего метода в исходном интерфейсе, который реализован в объекте.

Рассмотрим вновь наш пример. Метод add превратится в следующие два опи­сания методов (и снова для удобства мы используем свои правила именования):

void sendpoll_add(in int i. in int j): // Вызывается клиентом

void replypoll_add(out int ret_val. out int k); // Тоже вызывается клиентом

Наиболее важное различие между моделью опроса и моделью обратного вы­зова состоит в том, что метод replypoll_add реализуется клиентским брокером ORB. Эта реализация может быть автоматически сгенерирована компилятором IDL. Модель опроса приведена на рис. 9.6. И вновь мы считаем нужным отме­тить, что исходная реализация объекта на стороне сервера не претерпевает ника­ких изменений.

В описанных здесь моделях мы не учли тот факт, что сообщения, пересылае­мые между клиентом и сервером, в том числе и ответы на асинхронные обраще­ния, в случае неработоспособности клиента или сервера сохраняются базовой системой. К счастью, большинство моментов, связанных с сохранностью связи, не оказывают влияния на эти модели асинхронных обращений. Все, что нам не­обходимо сделать для создания коллекции серверов сообщений, — это разрешить временное хранение сообщений (будь то обращения или ответы) до момента доставки. Этот подход, описанный в [331], аналогичен системе очередей сообще­ний IBM, которую мы уже рассматривали в пункте 2.4.4 и не будем повторяться.

Совместимость

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

Эта проблема совместимости была решена путем введения стандартизованно­го протокола обмена между различными брокерами ORB в комбинации с уни­версальным способом создания ссылок на объекты. Если вернуться к рис. 9.2, это означает, что указанная между клиентом и сервером связь обслуживается по стандартному протоколу, который в CORBA известен как обобщенный протокол обмена между ORB (General Inter-ORB Protocol, GIOP).

GIOP — это на самом деле заготовка (каркас) протокола. Предполагается, что конкретная реализация будет выполняться поверх существующего транспорт­ного протокола. Этот транспортный протокол должен быть надежным, ориен­тированным на соединение, а также поддерживать понятия потока байтов и не­которые другие. Нас не особенно удивляет, что TCP удовлетворяет всем этим требованиям, однако имеются и другие подходящие транспортные протоколы. Реализация GIOP поверх TCP называется Интернет-протоколом обмена между ORB (Internet Inter-ORB Protocol, ПОР).

Протокол GIOP (включая ПОР и другие реализации GIOP) поддерживает восемь типов сообщений, которые перечислены в табл. 9.3. Два наиболее важных типа сообщений — это Request и Reply, которые вместе образуют часть реализа­ции обращений к удаленным методам.

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

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

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

Сообщение Cancel Request может быть послано клиентом серверу в том случае, если клиент хочет отменить действие ранее посланных сообщений Request или

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

В GIOP клиент всегда устанавливает соединение с сервером сам. Серверы могут лишь принимать или отвергать запросы на установку соединения, но сами устанавливать соединения с клиентами не в силах. Однако и клиент, и сервер имеют право разорвать соединение, для этого они должны послать другой сторо­не сообщение CloseConnection.

Если при выполнении произошла ошибка, другая сторона уведомляется об этом сообщением MessageError. Это сообщение содержит заголовок сообщения GIOP, вызвавшего ошибку. Такой же подход принят в сообщениях ICMP прото­кола IP, которые используются для возвращения информации об ошибке, если что-то идет не так. В этом случае заголовок IP-пакета, вызвавшего ошибку, воз­вращается в форме данных сообщения ICMP.

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