Вторая стадия: проблемы использования объектных служб и пути их решения, администрирование и отказоустойчивость

Обзор поставленных перед разработчиками задач

Построение информационной системы, удовлетворяющей следующим требованиям:

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

Описание использованных технологий и решений

К моменту выполнения проекта, появилось большое количество реализаций объектных служб, спецификаций описывающих как горизонтальные общие средства, так и общие средства, ориентированные на вертикальные рынки. Информационная система строилась из расчета смешанной архитектуры взаимодействия. В качестве средства управления последовательностью выполняемых работ использовалась технология Workflow. Вся подсистема пользовательского интерфейса реализовывалась на Java. Активно использовались в качестве строительных блоков службы, как специфицированные, так и не специфицированные OMG.

Анализ возникших проблем

Отсутствовал опыт и методика совместного использования объектных служб. Несмотря на понимание тех возможностей, которые предоставляют доступные службы, постоянно возникали вопросы о целесообразности их применения, технологиях (методиках) их совместного использования. Довольно часто работал принцип обратной связи, когда идея использования той или иной службы возникала по результатам тестирования компонентов и их взаимодействий. Не все службы удовлетворяли в том виде, в котором они были специфицированы OMG (например, Concurrency Control Service с жестко зафиксированной моделью блокировок).

При тестировании компонентов информационной системы возникли проблемы с обеспечением их отказоустойчивости. Подход, предполагающий сохранять состояния большей части CORBA-объектов в СУБД не оправдал себя, так как требовал большие ресурсы.

С другой стороны, остро встала проблема администрирования, которая не сводилась только к администрированию баз данных. Продукты класса Tivoli и UniCentre не могли быть использованы из-за их большой стоимости.

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

Пути решения описанных проблем

Анализ показал, что для успешного применения объектных служб разработчики должны:

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

По каждому из указанных пунктов был накоплен опыт, проведены исследования, сформированы конкретные методики. Так, например, службе запросов (Query Service), требуется наличие практически всех служб. И это понятно, поскольку с точки зрения предоставляемой функциональности она является одной из самых развитых, позволяя формулировать и выполнять запросы над объектами с использованием OQL (Object Query Language) ODMG, SQL или подмножества этих двух языков. При выполнении запроса служба может обратиться за услугами к Transaction Service, Relationship Service, Persistent Service, Concurrency Control Service, Property Service, часть из которых в свою очередь пользуется услугами Naming Service, Externalization Service, Life Cycle Service. Как результат возникает довольно длинная цепочка вызовов методов удаленных объектов, что может отрицательно сказаться на времени выполнения запроса. Для систем, обрабатывающих информацию в режиме реального времени и требующих гарантированного времени отклика на запрос это неприемлемо. Но как часто возникает необходимость в минимально возможном времени отклика на запрос? Для многих организаций, особенно в случае наличия унаследованных систем, на первый план выступает не скорость выполнения запроса, а возможность обеспечения единого интерфейса к неоднородным базам данных. В такой ситуации, использование Query Service вполне оправдано, поскольку позволяет на основе стандартных средств сделать подсистему доступа к базам данных открытой при интеграции ее компонентов с другими компонентами информационных систем.

Расширение функциональности служб обеспечивается посредством определения нового интерфейса, наследуемого от интерфейса, специфицированного OMG. При этом в случае, если служба разрабатывается собственными силами, то необязательна реализация всех методов, определяемых IDL-интерфейсами. Усечение функциональности, поддерживаемой службой, позволяет за короткие сроки получить упрощенное решение, которое, при необходимости, может быть доработано.

Проблема отказоустойчивости решается средствами рационального использования, как СУБД, так и CORBA-объектов, реализующих функции журнализации на базе файловой системы, и в совокупности выступающих в качестве объектной службы.

"Облегченное" решение задач администрирования получается на основе совместного использования технологии мобильных агентов, Java и CORBA.

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

Назад | Содержание | Вперед