Так же как язык является важнейшим средством общения, так и спецификация сообщений – одна из главных задач промежуточного программного обеспечения. Именно этим способом CORBA-объекты общаются друг с другом.
В случае, когда распределенная среда устойчива (все приложения-элементы доступны в любой момент времени), синхронных сообщений достаточно. Но устойчивость ограничивает универсальность технологии. Поэтому и здесь создатели CORBA приготовили кое-что новенькое, а именно – асинхронные сообщения, независимые от времени вызовы, сервис для задания и оценки качества передачи сообщений.
Вспомним, что первые версии поддерживали три модели клиентских запросов.
Естественно, самой простой и удобной была последняя модель – однонаправленная. Самой же интересной и многообещающей выглядела синхронная отложенная модель, использование которой, к сожалению, было ограничено динамическим случаем. Конечно, теоретически Интерфейс Динамических Вызовов можно использовать и в статическом случае, но на практике никому не хочется писать лишний код, усложнять и загромождать свои приложения. Если уж можно использовать Интерфейс Статических Вызовов, то его и используют.
Новые спецификации сообщений, включенные в CORBA 3, расширяют возможности технологии. К ним относится Асинхронный Метод Вызова (Asynchronous Method Invocaction – AMI).
Можно изловчиться и организовать некоторое подобие асинхронного вызова и в старых спецификациях. Можно использовать отдельные потоки (thread) для каждой операции «запрос-отклик». Правда, в случае активного обмена сообщениями между приложениями это приводит к усложнению программной среды. Другой выход из положения для поддержки асинхронности – применение двух однонаправленных сообщений. Например, клиент может передавать в однонаправленном вызове целевому объекту свою объектную ссылку, которую целевой объект будет использовать для обратного однонаправленного вызова. Все эти хитрости в новых спецификациях становятся ненужными. В них определены два новых модели.
Две эти модели являются СORBA-отражениями хорошо знакомых моделей push и pull. Заинтересованная сторона, в данном случае, клиент, либо постоянно интересуется, как поживает его запрос (pull- polling), либо передает инициативу целевому объекту, который должен уведомить клиента в случае готовности ответа (push-callback). Обе модели не порождают новых потоков на клиенте, что немаловажно. В данном случае изменения касаются клиентской стороны модели.
В CORBA 3 определяются еще два полезных средства.Эта разновидность асинхронных вызовов поддерживает алгоритм «запомнил и послал».
Подобные вызовы необходимы в тех случаях, когда клиент посылает асинхронный запрос к объекту, который неактивен или отсоединен в данный момент. Для поддержки метода определен специальный протокол Interoperable Routing Protocol (IRP), основанный на General Inter-ORB Protocol (GIOP). С помощью этого протокола брокеры объектных запросов интегрируются с Ориентированным на сообщения Промежуточным программным обеспечением (Message Oriented Middleware —MOM).
На уровне Портируемого Объектного Адаптера можно задать политику по уровню качества, которая будет выполняться для всех объектов данного адаптера.
Итак, асинхронные методы вызовов были белым пятном в CORBA 2. В этом смысле «старая» CORBA отставала от МОМ. Эта область, в частности, не позволяла CORBA стать уникальной всеобщей объектной идеологией Распределенных Программных Приложений, превосходящей все доселе известные технологии. Теперь этот досадный недостаток устранен.