Рис 5: CGI и CORBA
Ответ на поставленный во Введении вопрос - как объединить информационные системы, основанные на технологии WWW, с другими (в том числе и распределенными) информационными системами? - заключается в следующем: необходимо связать технологию распределенных объектов (то есть технологию CORBA) с технологией WWW. Целью настоящей работы является более детальное рассмотрение связки CORBA и WWW. О внедрении же CORBA в информационные системы выходит за рамки настоящей работы.
Было выделено два различных решения поставленной задачи. Первое решение строится на применении технологии CGI, а второе -- на применении технологии Java. В рамках проделанной работы было исследовано практическое применение этих технологий, с использованием продуктов Orbix и OrbixWeb от IONA Technologies.
В чистом виде, технология CGI состоит в следующем: для формирования HTML-страницы Web-сервер запускает некий CGI-скрипт. При этом CGI-скрипт может реализовывать довольно сложную функциональную логику и обращаться, например, к базе данных. CGI-скрипт представляет собой отдельное исполняемое приложение. Язык, на котором написан скрипт, не играет большой роли.
Решение CORBA-CGI основывается на том, что исполняемый CGI-скрипт является одновременно и одной из компонент распределенной системы. Главное отличие от технологии CGI заключается в том, что CGI- скрипт является не просто исполняемым модулем, а он является одновременно и CORBA-клиентом. В некотором смысле, скрипт служит точкой входа и выхода в распределенной системе, внутри которой могут протекать различные процессы.
Рис 5: CGI и CORBA
К преимуществам этой технологии можно отнести практически все преимущества использования CORBA. Кроме того, пользователь работает с привычными для него HTML-страницами, что особенно важно при работе с объемной текстовой информацией.
Теперь о недостатках этой технологии. Практика показывает, что во-первых -- это невысока эффективность системы. Каждый раз при перезагрузке страницы необходимо заново выполнять CGI-скрипт, заново устанавливать соединения с другими компонентами системы. Это не эффективно, что особенно сильно проявляется, когда система одновременно используется несколькими пользователями. Во-вторых, не жертвуя эффективностью, невозможно своевременно уведомлять пользователя об изменениях, произошедших в просматриваемой им информации. Они будут видны лишь при перезагрузке страницы. То есть пользователь участвует в системе исключительно в роли клиента.
Частным решением проблемы эффективности выполнения CGI-запросов (особенно в многопользовательской системе), может быть расширение функциональности используемого Web-сервера, путем добавления в него соответствующих функций. В этой области была проделана работа по встраиванию в Web-сервер Apache (платформы SunOS, WindowsNT) поддержки обращения к Orbix ORB.
Сложности также возникают при создании сложных, ветвистых пользовательских интерфейсов. Дело в том, что системе, при выполнении запросов помимо веденной в окне броузера информации, необходима дополнительная, скрытая от пользователя и характеризующая текущее состояние системы информация. Вся интерфейсная часть системы привязана к окну броузера, а выводимая на экран информация создается динамически в зависимости от параметров запроса и внутреннего состояния информационной системы на некоторый момент времени. Вследствие этого, если пользователь производит неконтролируемую навигацию вперед-назад по просматриваемым страницам, повышается риск десинхронизации просматриваемой пользователем и хранимой на сервере информации, что недопустимо. Более того, система должна следить и за тем, чтобы вольные переходы от страницы к странице имели бы логический смысл, что тоже немаловажно. Тем самым, в случаях сложных пользовательских интерфейсов необходимо наличие жесткого контроля за текущим состоянием информационной системы.
Второе решение проблемы связывания технологий CORBA и WWW -- язык Java. Дело в том, что OMG стандартизировала отображение из IDL в Java. Имеются программные продукты, реализующие связь CORBA и Java -- например, OrbixWeb, Visibroker. Java-технология основана на том, что при обнаружении тега <APPLET>, броузер через сеть загружает к себе необходимые для этого апплета Java-классы и запускает его. При этом на машине пользователя запускается Java Virtual Machine (JVM), внутри которой и выполняется загруженный апплет.
Рис 6: Java и CORBA
Java-апплет, являющийся CORBA-клиентом, устанавливает все необходимые соединения с другими (серверными) приложениями системы и именно через него к пользователю идет вся информация. Апплет играет роль пользовательского интерфейса для данной распределенной системы. Количество выполняемых апплетов ничем не ограничено -- вопрос лишь в достаточных вычислительных ресурсах системы.
Коротко о достоинствах и недостатках технологии Java-CORBA:
Достоинства
|
Недостатки
|
Такие встроенные в Java средства как многопоточность, позволяют легко реализовывать и синхронное, и асинхронное взаимодействие апплетов с другими приложениями. У технологии Java-CORBA практически нет слабых мест. Единственная проблема, которая может возникнуть -- необходимость наличия мощных вычислительных ресурсов на стороне пользователя. Это, конечно, серьезный недостаток, но он, скорее, является недостатком языка Java.
Как уже отмечалось, при использовании технологии Java-CORBA, Java-апплеты могут играть роль и клиентов, и серверов. Это позволяет создание ``живых'' страниц, то есть страниц, информация на которых меняется практически постоянно. Например, если апплет представляет собой отображение состояния некоторого устройства, то при переходе устройства из одного состояния в другое, информация в апплете практически мгновенно изменится соответствующим образом. Причем это может быть информация любого рода -- как графическая, так и текстовая. Возникает вопрос: а каким способом происходит обмен информацией между апплетов и остальной частью системы?
В CORBA существует два различных механизма передачи сообщений -- механизм Push и механизм Pull [4].
Механизм PULL представляет собой следующее: когда клиент готов обрабатывать сообщения, он опрашивает сервер на наличие у того новых сообщений. Если таковых не имеется, клиент через некоторый промежуток времени повторяет операцию. При этом, в зависимости от контекста решаемой задачи и пропускных способностей сетевых каналов, тип взаимодействия клиента и сервера может быть как асинхронным, так и синхронным.
Механизм PUSH, в некотором смысле, противоположен механизму PULL. В этом случае сервер сообщений сам, по мере поступления новых сообщений, будет информировать об этом клиентов. То есть клиенты сами являются серверами, а сервер сообщений лишь вызывает у них соответствующие методы, ``вталкивая'' им сообщение. Как и в модели PULL, взаимодействие клиента и сервера сообщений может быть и асинхронным, и синхронным.
Рис 7: Механизмы PULL и PUSH
При использовании механизма PULL, на обработку каждого запроса клиента сервер расходует свои системные ресурсы, что при наличии большого числа клиентов, регулярно опрашивающих его, заметно снижает его производительность. Многое также зависит и от того, сколь часто клиенты опрашивают сервер. При большом количестве клиентов-ожидателей и коротком времени между двумя запросами к серверу, производительность сервера снижается еще больше.
Представим себе, что связь между клиентами и сервером неважная. В этом случае, эффективность работы механизма PULL будет еще снижаться по мере ухудшения качества связи. Врем выполнения запросов будет увеличиваться, а каналы связи заняты.
В модели PUSH сервер сообщений гораздо менее загружен. Сервер освобожден от необходимости регулярно реагировать на вызовы клиентов-ожидателей. Наоборот, теперь он имеет дело с клиентами-слушателями. ``Вталкивание'' сообщений клиенту применяется особенно в тех случаях, когда сообщения, появившиеся на сервере сообщений, должны быть немедленно обработаны клиентом (клиентами). Да и при наличии некачественной связи между узлами, механизм PUSH гораздо более рентабелен, чем PULL -- он использует информационный канал лишь один раз для каждого клиента.
При реальных разработках информационной системы, имеют место оба представленных способа взаимодействия компонент. Разумная комбинация компонент информационной системы, поддерживающих PUSH / PULL модели обмена сообщениями, позволяет достичь высокого уровня гибкости и производительности создаваемой информационной системы.
Использование PUSH-технологии позволяет практически мгновенно и эффективно пересылать обновленную информацию всем заинтересованным приложениям. При использовании технологии Java-CORBA реализация PUSH-технологии очень проста. У заинтересованного в сообщении пользовательского клиента (апплета) создается специальный слушатель. Этот слушатель запускается основным апплетом в отдельном процессе с использованием механизма Threads (нитей) в Java. При запуске слушатель, реализующий специфичный для данного типа сообщений IDL-интерфейс, информирует сервер сообщений о своей заинтересованности в приеме сообщений данного типа, после чего начинает ждать. При получении сообщения класс-слушатель может уже напрямую взаимодействовать с классом-клиентом.
Итак, практика показывает, что технология Java-CORBA лучше всего подходит для создания WWW CORBA-клиентов, которые:
Технологию же CORBA-CGI выгоднее применять в случае, если:
Несмотря на то, что преимущества технологии Java-CORBA над технологией CORBA-CGI значительны и область применения шире, обе рассматриваемых технологии хорошо подходят для объединения WWW-систем и клиент/сервер-систем. Технология CORBA-CGI расширяет возможности CGI, а технология Java-CORBA возможности всего WWW --- до уровня распределенных объектных систем.
В результате проделанной работы было показано, что на сегодняшний день технологии Java и CORBA прекрасно дополняют друг друга в качестве универсального, мощного средства для решения проблемы объединения систем, основанных на технологии WWW, с подобными и другими, в особенности распределенными, информационными системами.
Однако уже совсем скоро у технологии CORBA может появиться очень опасный соперник --- продвигаемая Microsoft технология DCOM, которая уже сильно потеснила CORBA с рынка Windows-ориентированных систем. Технология же RMI, наоборот, делает шаги навстречу CORBA. Начиная, видимо, с версии JDK1.2, протокол RMI будет выполняться поверх протокола IIOP, что, конечно же, выгодно всем Java и CORBA разработчикам.
Массовое использование технологии Java-CORBA выведет Internet на совершенно новый уровень взаимодействия. Internet будет все более похож на гигантскую объектную распределенную систему. Тем самым, наконец, произойдет переход от Web, к новой, объектной сети -- ObjectWeb.
назад | содержание | далее
