Наш опыт разработки пользовательского интерфейса показывает, что в большинстве случаев наиболее выгодной технологией его построения является технология WWW. Это обусловлено рядом причин. Основной из них, на наш взгляд, является то, что использование WWW позволяет пользователю взаимодействовать с информационной системой с любого компьютера, где установлен броузер. Во-вторых, пользовательский интерфейс броузера знаком практически каждому, кто работает с компьютером, а это снижает затраты, на обучение персонала для работы с новой системой. В-третьих, решается вопрос о переносе системы на другие платформы, т.к. по нашим подсчетам наибольшее время при кодировании информационной системы (до 80%) занимает проектирование и разработка интерфейса с пользователем. В-четвертых, становится возможным в качестве клиентских рабочих мест использовать низкопроизводительные компьютеры, что значительно удешевляет стоимость рабочего места.
Однако при всех своих преимуществах технология WWW обладает одним существенным недостатком: ее интеграция с другими технологиями порождает массу проблем. Основная из них - это обмен данными WWW сервера с внешней системой. Можно выделить три основных решения данной проблемы:
Первое решение является наиболее распространенным, но его основным недостатком является то, что при возрастании количества запросов к серверу его загрузка значительно увеличивается, что требует дополнительных ресурсов. Также в качестве недостатка можно выделить тот факт, что обмен данными между CGI сценарием и сервером происходит через потоки стандартного ввода/вывода. Поэтому в случае, если клиент прервал свой запрос, то сценарий отработает "вхолостую", что является довольно расточительным, с точки зрения использования ресурсов сервера.
Использование апплетов Java решает многие проблемы, связанные с CGI, в частности проблему загрузки сервера, проблему безопасности и т.д. Но вместе с тем повышаются требования к ресурсам клиентского рабочего места.
При использовании API сервера происходит значительная "привязка" к тому программному продукту, чей API используется, что в основном приводит к значительным затратам при переходе на другую платформу.
Все сказанное выше можно также отнести и к проблемам интеграции WWW с CORBA-системами. Однако CORBA предоставляет дополнительные возможности для этой интеграции. Например, при использовании Java у разработчиков практически не возникает проблем, т.к. в рамках OMG существует стандарт на отображение языка описания интерфейсов в Java. При этом WWW-сервер используется как стандартный механизм, позволяющий производить удаленную загрузку классов, а WWW-броузер, как JVM. Но как уже было сказано выше, Java предъявляет значительные требования к аппаратному обеспечению клиентского рабочего места. Эта была одна из основных проблем, с которыми мы столкнулись при разработке системы, где пользователю приходилось работать со сложно структурированной информацией. Иногда отклика системы приходилось ждать несколько минут, причем от 50% до 90% из этого времени приходилось на обработку пользовательским интерфейсом информации, полученной в результате запроса. Получив такие плачевные результаты, нам пришлось пересмотреть подход к построению подсистемы пользовательского интерфейса на основе WWW. Вариант использования API сервера отпадал сам собой по причинам, описанным выше: основной принцип, которым мы руководствуемся при создании ИС - минимальная зависимость системы от программной и аппаратной платформы. Оставалось только использовать CGI. Но через некоторое время нас это тоже перестало удовлетворять, т.к. CGI сценарии CORBA получались очень тяжеловесными. В основном это происходило за счет дополнительного кода, генерируемого IDL-компилятором интерфейсов и накладных расходов, связанных с CORBA (установление связи с другими объектами).
Пришлось искать пути выхода из создавшейся ситуации. В результате был разработан модуль для WWW-сервера Apache, получивший в дальнейшем название WebORB, который позволял напрямую обращаться к CORBA-объектам не порождая нового процесса. Да, пришлось использовать API, но, во-первых, взаимодействие сервера с CORBA-объектами происходит посредством интерфейса, описанного на IDL. Поэтому при переходе на другой WWW-сервер необходимо будет только переписать WebORB, а это уже те накладные расходы, которые можно себе позволить при создании такого рода систем. Во-вторых, сам сервер Apache является самым популярным в мире и доступен практически на всех платформах, что практически сводит к нулю вероятность того, что придется переписывать WebORB для другого сервера.
Производительность, которую показал WebORB. была превосходной: скорость выполнения запроса увеличилась в несколько раз. Но… Мы снизили загрузку сервера не увеличивая при этом требовательности к клиентским местам - для отображения информации используется HTML, генерируемый CORBA-объектами. Однако мы лишились возможности использования push технологии, которое было возможным при создании пользовательского интерфейса на Java. И на этот раз решение было найдено. Суть его довольно проста: на клиентское рабочее место загружается Java-апплет, представляющий CORBA-объект, который используется для принудительного управления броузером. Простой пример: необходимо произвести экстренный останов системы из-за нарушения электропитания. Система передает Java-апплету, расположенному на клиентском рабочем месте, сообщение, которое надо отобразить. В зависимости от того, какая информация была передана, апплет либо сам отображает сообщение, либо указывает броузеру загрузить соответствующий сообщению URL.
Таким образом, интеграция технологий WWW и CORBA не представляет собой какого-либо законченного решения, которое можно "взять с полки". В каждом конкретном случае остается достаточно большое количество степеней свободы. В тоже время, решения, найденные нами в процессе работы над проектами говорят о том, что интеграция WWW и CORBA заключается в обобщении и объединении опыта и решений, накопленных в обеих технологиях.