Опыт реализации и использования объектных служб
Проблемы, возникшие на первой стадии использования CORBA, показали необходимость использования стандартных компонент системы (объектных служб и общих средств), которые никак не связаны с конкретной предметной областью. В качестве примера рассмотрим Службу Именования Объектов и Службу уведомления о событии.
Одной из стандартных задач при реализации распределенных систем является "поиск" местонахождения объекта в системе. В большинстве случаев тех механизмов, которые предоставляют производители программного обеспечения ORB, не хватает (Локаторы, Загрузчики и т.д.), т.к. эти механизмы ориентированны на поиск только тех объектов, которые присутствуют в системе "статически". Для поиска динамических объектов системы необходимо использовать иные механизмы. Наиболее предпочтительным с этой точки зрения выглядит Служба Именования объектов, специфицированная в рамках стандарта Общих Объектных Служб OMG. Использование этой службы значительно упрощает поиск объектов в распределенной системе. Основной идеей данной службы является "именование объекта", т.е. любой объект системы, зарегистрированный в рамках Службы, имеет уникальный идентификатор - имя объекта. В рамках Службы объекты могут быть разбиты на группы, которые, в свою очередь, могут содержать подгруппы и т.д. Можно провести аналогию между файловой структурой UNIX-систем и структурой имен объектов Службы: аналогом каталога файловой системы является Контекст Имен Службы, а аналогом файла - имя объекта, связанное с его объектной ссылкой.
Казалось бы, все достаточно просто, но и здесь возникают некоторые проблемы. Одна из них связана с тем, что структура имен объектов может образовывать замкнутый граф. В этом случае при обращении к Службе возможно зацикливание, выхода из которого не будет, т.к. в рамках стандарта не определены механизмы отслеживания коллизий подобного рода. Выходов из этой ситуации может быть несколько - от организационных, т.е. правильность построения графа имен объектов отслеживается на этапе проектирования системы, до программных, когда в реализацию Службы закладываются механизмы, позволяющие контролировать "правильность" построения графа.
Еще одна важная проблема, возникающая при работе с "динамическими" объектами системы - отказоустойчивость, при некорректном завершении работы системы. Одной из основных задач, которую приходится решать, является сохранение текущего состояния объекта, с возможностью его автоматического восстановления после перезапуска системы. Стандарты здесь не предоставляют какого либо решения, и в каждом случае все отдается на откуп конкретной реализации Служб. При использовании Службы Именования данная проблема стоит особенно остро, т.к. в большинстве случаев эта Служба является аналогом Windows Registry и хранит в себе информацию о конфигурации объектов системы.
Вообще стоит уделить особое внимание вопросу использования стандартных служб для отображения и хранения текущей конфигурации системы. Наш опыт показывает, что, как правило, "стандартность" Служб провоцирует на их использование для подобного рода задач в "чистом" виде. Это было одной из проблем, с которой мы столкнулись на второй стадии использования CORBA. Дело в том, что стандартные службы разрабатывались и стандартизировались для довольно узкого круга задач, в то время как мы пытались на них возложить те функции, которые им не свойственны. Примером тому может служить использование Службы Именования при построении подсистемы, контроля конфигурации системы. Так как основной проблемой, которую решает Служба Имен, является хранение информации о местонахождении объектов, то в какой-то момент было принято решение на ее основе построить подсистему, которая бы хранила в себе информацию о различных ресурсах системы их свойствах. В качестве компоненты, позволяющей описывать свойства ресурсов, было решено использовать Службу Объектных Свойств (Property Service). Результаты проделанной работы показали неэффективность такого подхода. При увеличении размеров системы и ее сложности в целом, происходило снижение производительности разработанной подсистемы за счет значительного межпроцессного взаимодействия внутри нее. В результате был выбран иной подход, для решения подобного рода задач. В случае если применение "стандартных" CORBA-компонент приводит к снижению производительности, то следует использовать не готовые "стандартные" службы, а библиотеки классов и алгоритмы, использовавшиеся при их реализации, и уже на этой основе создавать новые компоненты системы.
Особо хотелось рассмотреть вопрос, связанный с асинхронным взаимодействием объектов в распределенной системе. Собственно сам стандарт CORBA позволяет организовать такое взаимодействие компонент системы между собой (oneway операции). Однако данный подход значительно усложняет программную логику реализуемых компонент. И вновь на помощь приходят Объектные Службы. Специфицированная в рамках OMG Служба уведомления о событии позволяет значительно упростить реализацию асинхронного взаимодействия в системе.
При использовании данной службы, обмен информацией между компонентами основывается на обмене сообщениями, посредством некоторого специального объекта, называемого каналом событий. Причем, что очень важно, обмен сообщениями может происходить как с применением pull-, так и push-технологии. Принцип работы самого канала событий довольно прост: объекты делятся на поставщиков (Suppliers) сообщений и потребителей (Consumers) сообщений. Объект регистрируется в канале и получает уведомления о каком-либо событии через него, либо сам уведомляет канал о каком-либо событии. При регистрации объекта в канале событий указывается, какую технологию (push/pull) использовать для доставки ему сообщений, или получения от него. Таким образом, компоненты системы, не имея никакой, или минимум информации друг о друге, получают возможность взаимодействовать между собой. Также отличительной чертой Службы уведомления о событии является возможность добавления новых компонент в систему без перекомпиляции уже существующих и без останова системы в целом.
Однако и здесь возникают проблемы. В основном они связаны с тем, что в любой системе существует некоторая классификация происходящих в ней событий. В стандарте определено 2 типа Службы:
При использовании и реализации Службы Событий мы столкнулись с тем фактом, что в подавляющем большинстве случаев использование типизированного канала событий не оправдывает себя. Во-первых, возникают большие накладные расходы при проектировании и реализации типизированных объектов, которые будут обмениваться данными. Во-вторых, типизированный канал событий накладывает некоторые ограничения на интерфейсы данных объектов. В-третьих, объекты должны знать, по крайней мере, тип интерфейса другого объекта для передачи сообщений. Последнее обстоятельство также приводит к более тесной взаимозависимости компонент между собой и, как результат, к большим накладным расходам при модификации системы.
Мы пришли к выводу, что в том случае, если в системе необходимо ввести типизацию сообщений, то использовать надо более легковесный, нетипизированный вариант Службы Событий, а типизация событий будет носить организационный характер, то есть для каждого типа событий будет создаваться свой канал. Однако это решение подходит только в том случае, если в системе присутствует относительно небольшое количество типов событий, т.к. при увеличении масштабов системы количество каналов событий растет очень быстро. В результате мы пришли к тому, что целесообразней всего ввести типизацию событий внутри нетипизированного канала. Вопрос был в том, как это реализовать - хотелось сохранить стандарт. Первый вариант Службы был реализован и поддерживал стандартный интерфейс нетипизированного канала. Однако и это решение нас не удовлетворило, т.к. мы очень тесно привязались к тому продукту, на котором эта система была реализована: - для сохранения стандартного интерфейса пришлось использовать специфические механизмы конкретной реализации ORB. В конце концов, наиболее подходящим решением проблемы типизации событий было признано расширение стандартного интерфейса Службы уведомления о событии и создание на ее основе своего собственного стандарта.
В заключение этой части хотелось бы отметить, что использование "стандартных" спецификаций значительно увеличивает скорость разработки системы и в то же время упрощает процесс ее проектирования и реализации. Вместе с тем, использование Объектных Служб и Общих Средств не должно приводить к снижению производительности системы в целом и усложнению отдельно взятых подсистем. В некоторых случаях, наиболее эффективным является "расширение" стандартных спецификаций до необходимого уровня и выработка на их основе собственных внутренних стандартов.