Современный программный комплекс. Технология CORBA.

Требования

Современный программный комплекс для построения интегрированной системы безопасности среднего или крупного предприятия должен удовлетворять ряду требований.

Масштабируемость
Программный комплекс должен обладать хорошей масштабируемостью,  то есть способностью работать как на малых, так и на очень больших объектах. В зависимости от размера объекта используют различные варианты развертывания программных комплексов. На малых объектах это может быть автономная система, работающая на одном компьютере, на средних – система с централизованным подключением оборудования и возможностью управления с нескольких рабочих мест, на крупных – распределенная система с распределенным подключением оборудования и возможностью управления с любого компьютера локальной сети или из любой точки мира.
Данное свойство особенно удобно, если существует необходимость связать крупный центральный офис с удаленными небольшими филиалами организации. Установка одного и того же ПК в филиалах разного масштаба упрощает интеграцию и снижает стоимость сопровождения систем.

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

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

Расширяемость
Комплекс должен обеспечивать возможность подключение новых модулей. Новые модули могут реализовывать дополнительную логику обработки информации или управления, обеспечивать подключение к системе нового оборудования, отображение системы для операторов в нестандартном виде, стыковку и динамический обмен данными с другим программным обеспечением и др.
Очень важно, чтобы комплекс позволял подключать новые модули в ‘горячем’ режиме, чтобы для обслуживания системы или добавления к ней новых модулей не приходилось отключать систему безопасности.

Переносимость
Желательно, чтобы ПК мог функционировать на разных аппаратно-программных платформах. Это позволит устанавливать комплекс на имеющемся оборудовании и может позволить упростить интеграцию комплекса с имеющимися информационными системами предприятия.

Открытость
Как это ни странно звучит, в некоторых случаях важно, чтобы комплекс управления системой безопасности обладал открытостью. Под этим подразумевается возможность доработки ПК силами организации-инсталлятора или непосредственно конечного заказчика. Это позволяет дорабатывать комплекс непосредственно под требования заказчика. В качестве возможных направлений доработки можно предложить поддержку нового оборудования, заказную логику поведения программного комплекса в определенных ситуациях (например, отслеживание перемещения людей в помещениях, отслеживание допустимого времени пребывания автомобилей на парковке и др.), интеграция с информационными системами предприятия (например, синхронизация баз данных системы управления взаимоотношения с клиентами и базой данных пропусков системы управления доступом) и др.
Необходимым условием для обеспечения открытости комплекса является использование наиболее распространенных и развивающихся современных технологий построения ПО.
В данной статье делается попытка предложить набор технологий и архитектурных решений, позволяющих реализовать перечисленные выше требования.

Технологии

Технологии модульного построения комплексов
Решение поставленных задач и удовлетворение постоянно возникающих новых требований к ПО возможно только в случае модульной организации программного комплекса. На сегодняшний день существует несколько конкурирующих технологий модульного построения ПО. Из наиболее распространенных на сегодняшний день можно привести Microsoft COM+ / .NET,  J2EE (Java 2 Enterprise Edition) и CORBA. Все они позволяют создавать надежные, гибкие, расширяемые программные комплексы, однако у каждой из них есть своя специфика.

Microsoft COM+ / .NET
Несмотря на развитость сервисов платформы COM+ и, даже в большей степени, ее преемника – .NET, это семейство платформ Microsoft для создания распределенных объектных приложений доступно только на платформе Windows. Отсутствие процесса стандартизации как такового, тесная интеграция с операционной системой и, как следствие, закрытость этой платформы и отсутствие альтернативных реализаций, ограничивают применимость семейства платформ COM+ / .NET для создания прикладной инфраструктуры предприятия. С точки зрения ПК управления системой безопасности, данные технологии вполне можно применять, если, конечно, ставится задача построения комплекса исключительно для платформы Microsoft Windows. В этом случае упрощается задача поиска квалифицированных разработчиков, так как интерес к технологиям компании Microsoft традиционно высок. В качестве дополнительного плюса можно рассматривать, что данные технологии часто считаются бесплатными для пользователей, так как их стоимость скрыта в стоимости операционных систем компании Microsoft.

Java 2 Enterprise Edition (J2EE)
Платформа J2EE, развиваемая в рамках открытого процесса стандартизации JCP (Java Community Process), впервые предложила цельную компонентную модель - EJB (Enterprise JavaBeans), ориентированную на создание серверной бизнес-логики. Данная технология позволяет строить комплексы, функционирующие не только на платформе Microsoft Windows. Она использует парадигму сервера приложений, которая в настоящее время признана критически важной для развертывания компонентов бизнес-логики в распределенной среде. Однако данная технология также обладает рядом ограничений. Основное – это возможность использования только языка программирования Java. При построении ПК управления системой безопасности часто возникает необходимость решения не только информационных задач, но и задач оперативного управления оборудованием, передачей и отображением аудио и видео информации и пр.  Данные задачи часто требуют тонкой оптимизации на уровне работы с оборудованием или с операционной системой, что не всегда удобно (хотя и возможно) делать в рамках данной технологии.
Что касается стоимости данной технологии для пользователей, то в ряде случаев она может быть достаточно ощутимой. Дело в том, что данная технология требует покупки лицензий на коммерческие J2EE-серверы приложений, стоимость которых может быть относительно высокой.

OMG CORBA
Технология CORBA, разрабатываемая с 1989 года консорциумом OMG (Object Management Group), является результатом работы ведущих специалистов из более чем 800 компаний и организаций. Четкий процесс стандартизации, включая аспекты взаимодействия реализаций CORBA от разных поставщиков (интероперабельность), независимость от языков программирования и операционных сред, фундаментальная поддержка ООП и многие другие уникальные характеристики, сделали CORBA ведущим стандартом в области инфраструктурного middleware. 

Основой технологии CORBA являются:

• IDL (Interface Definition Language) - язык, позволяющий описать все аспекты удаленного взаимодействия;
• cхемы отображения IDL-объявлений на конкретные языки программирования;
• ORB (Object Request Broker) - объектная магистраль, позволяющая передавать запросы от клиентов к серверам и обратно;
• Сервисы (Common Object Services) CORBA;
• GIOP - спецификация протокола (команды и форматы передаваемой информации)

Распределенная система, использующая CORBA, не ориентирована на применение конкретных операционных систем, двоичных стандартов, сетевых протоколов и языков программирования. Фактически, это единственная технология, которая обеспечивает возможность использования практически любых языков программирования и функционирование программного обеспечения практически на любых аппаратно-программных платформах.

Архитектура комплекса

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

Язык программирования

Технология CORBA позволяет вести разработку практически на любом языке программирования (C++, Java, Delphi и др.) и под любую аппаратно-программную платформу (Mi-crosoft Windows – Intel, Linux, Sun Microsystems Solaris – SPARC). Однако использование языка программирования Java позволяет получить дополнительное преимущество переносимости программного комплекса не только без его доработки, но даже и без его перекомпиляции.
Очень важным моментом является возможность использования других языков (например, C++) для некоторых модулей системы. Например, это может понадобиться для разработки модулей работы с цифровым потоковым видео или для реализации поддержки оборудования, драйвер которого поставляется только в виде COM-интерфейса.

Доступ к БД

В случае использования языка Java для разработки ПК разработчику доступна стандартная технология взаимодействия с различными серверами баз данных JDBC (Java DataBase Connectivity). Основными частями технологии JDBC являются JDBC API (набор классов и методов, к которым обращается прикладной программист) и JDBC-драйверы, которые транслируют эти вызовы в команды API конкретной СУБД. Используя данную технологию можно получить систему, независимую от используемого сервера БД и, соответственно, иметь возможность выбора сервера непосредственно для каждого заказчика в соответствии с особенностями объекта.

Хранение данных

Для хранения настроек объектов, конфигурации рабочих мест и прочей информации в БД можно применять стандартную реляционную модель, при которой данные объектов каждого типа сохраняются в отдельной таблице, содержащей набор колонок, соответствующих списку свойств этих объектов. Такой вариант хранения обеспечивает быстрые сохранение, поиск и выборку данных из БД, и удобен в информационных системах.
Системы безопасности же имеют свою специфику. С одной стороны, здесь нет острой необходимости в быстром поиске среди миллионов записей (количество обслуживаемых аппаратных объектов обычно все-таки существенно меньше).  С другой стороны, при расширении системы может возникнуть необходимость в добавлении новых типов объектов, что часто приводит к перестройке структуры БД, что, в свою очередь, затрудняет процесс установки и поддержки системы. В качестве возможной альтернативы можно рассмотреть хранение настроек объектов системы в полях типа BLOB формате XML.
XML (eXtensible Markup Language) – стандарт структурного представления данных. Представляет из себя набор правил, которые позволяют определить структуру некоторого класса документов. Документ, созданный в соответствие с этими правилами, представляет собой текстовый файл, в котором присутствуют как собственно информация, так и теги ее разметки. Имея формально описанную структуру документа, можно проверить его корректность. Наличие тегов разметки позволяет анализировать документ как человеку, так и программе. XML-документы, в первую очередь, предназначены для программного анализа их содержимого.
При таком подходе можно свободно сохранять в существующей таблице любые XML документы без перестройки структуры БД, что позволяет проводить расширение системы в ‘горячем’ режиме без ее выключения.
Однако возникает необходимость в стандартном инструменте поиска среди документов (так как стандартные средства поиска среди реляционных данных работать не будут). Для поиска удобнее всего использовать язык XPath, который предназначен для создания выражений для доступа на основании содержимого XML-документа, которые потом можно использовать в запросах к серверу БД. Некоторые серверы БД (например, Oracle Database) уже содержат встроенные средства поиска XML-документов по их содержимому. Другие же (например, Borland InterBase) обладают возможностью подключения к ним специальных модулей, реализующих данные функции.

Обмен данными с другими системами

На сегодняшний день для обмена данными с другими системами фактически все системы используют именно формат XML. При хранении конфигурации объектов в данном формате достаточно просто создать универсальную службу для обмена данными с внешними системами. Для этого достаточно экспортировать данные из БД в файлы на диск без их преобразования из реляционной формы в формат XML.
В ряде случаев может возникать необходимость преобразования данных перед их передачей другой системе. Это может быть как преобразование структуры XML документов, так и преобразование их в другой формат (например, текстовый с разделителями-табуляциями). Причем правила преобразования могут отличаться от одной внешней системы к другой. Данную задачу можно выполнить с помощью технологии XSL (eXtensible Style Language), которая представляет собой язык, позволяющий сформировать то или иное представление на базе XML-документа. Достаточно сформировать специальный документ,  описывающий процесс преобразования исходного XML-документа в результирующий документ и воспользоваться существующими библиотеками преобразования.

Обмен сообщениями

Используя для построения системы технологию CORBA для решения стандартных системных задач можно воспользоваться стандартными сервисами CORBA. Сервисы CORBA решают задачи поиска, установления отношений между объектами, сохранения их состояний, управления транзакциями и безопасностью, синхронного и асинхронного уведомления о тех или иных событиях и многое другое. Одними из самых распространенных сервисов являются Сервис Событий (Event Service) или идущий ему на смену и являющийся его развитием и обобщением Сервис Уведомлений (Notification Service). Эти сервисы позволяют универсальным образом уведомлять объекты распределенной системы о происходящих событиях. Получателями могут являться программные модули, разработанные не только производителем комплекса, что позволяет обеспечить расширение и подстройку системы под требования заказчика путем разработки новых функциональных модулей силами инсталлятора.

Обеспечение безопасности

При построении системы безопасности на базе стандартных технологий необходимо особое внимание уделить безопасности самого комплекса. Для решения этой задачи создан специальный Сервис Безопасности (Security Service). Пожалуй, это один из самых важных сервисов CORBA. Он решает очень многие проблемы: идентификации пользователя, определения прав доступа к объектам, режимов делегирования полномочий при цепочке последовательных вызовов объектов друг другом, системы аудита, защиты информации при передаче, ведении достоверной истории взаимодействия объектов и многое другое. Это очень сложный сервис, спецификация его состоит почти из 300 страниц. Самое поразительное, что при всей его сложности и многочисленности решаемых им проблем, он практически не "виден" для прикладного программиста - все действия выполняются автоматически, в том числе и распространение контекста безопасности. 

Разумеется, данная статья не покрывает всех возможных технологий и подходов к решению поставленных задач. Целью данной статьи было показать основные задачи, стоящие перед разработчиками программного обеспечения интегрированных систем технической безопасности, а также предложить возможные пути их решения. Автор надеется, что описанные в статье подходы и архитектурные решения могут быть полезны разработчикам программного обеспечения.

Автор выражает признательность московскому представительству компании Borland за оказанную при подготовке материала информационную поддержку.