4.2. Проектирование и разработка типовых интерфейсов интеграции

Опыт внедрения ИТ-решений на рынке телекоммуникаций наглядно демонстрирует, что максимальный положительный эффект достигается при построении комплексного решения, в котором тесно интегрированы различные модули OSS/BSS. Преимущества интеграции особенно наглядно демонстрируются при снижении совокупносоей стоимости владения информационной системой и уменьшении затрат на ее эксплуатацию и обслуживание. Однако интеграция систем различных производителей представляет немало трудностей и требует детальной проработки области задач, на решение которых направлен каждый из интегрируемых модулей [43].

Для того, чтобы совокупность модулей системы OSS/BSS функционировала как единое целое, необходимо обеспечить их интеграцию как на техническом, так и на сематическом уровне. Сематическая интеграция требует от приложений использования унифицированной системы символов и общей их интерпретации.

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

С технической точки зрения интеграция между модулями и приложениями OSS/BSS может быть организована двумя способами: в виде выгрузки, преобразования и загрузки данных уже в другой модуль либо в виде организации автоматизированных интерфейсов между модулями. Выгрузка/загрузка данных применяется для единовременного или периодического хранения, как правило, используются текстовые или табличные файлы либо специальные таблицы в БД.

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

51

4.3. Основные способы организации взаимодействия между информационными системами

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

Одним из первых этапов проектирования является выбор сущностей, на основе которых будет передаваться смысловая информация. Взаимодействующие информационные системы часто реализованы на основе различных моделей данных, и подобрать подходящую информационную единицу достаточно сложно. В области телекоммуникаций подобным «общим языком», как правило, может выступать набор сущностей из TMF Information Framework (модель SID).

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

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

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

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

Впериод между отправкой и проверкой наличия ответа, «инициатор» может продолжать другую работу, поэтому асинхронный режим иногда еще называют «неблокирующим».

52

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

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

Web-Service/SOAP. Протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML. Его спецификация опубликована и поддерживается web-консорциумом W3C [44];

DBLink. Позволяет получить из программного кода, выполняемого

водной БД Oracle, удаленный доступ к объектам другой БД – также Oracle, или другого типа [45]. Похожая методика используется и в СУБД

PostgreSQL [46];

CLI (Call-Level Interface) [47] или разработанная на его основе тех-

нология ODBC (Open DataBase Connectivity) [48]. Универсальный интерфейс для доступа к базам данных, при использвоании которого можно разрабатывать приложения с обращением к данным, не беспокоясь о тонкостях взаимодействия с несколькими источниками различной реализации. Развитие и поддержка ODBC к настоящему времени уже прекращены. CLI, хоть и не получил столь же широкого распространения, остается международным стандартом, описанным в ISO/IEC 9075-3:2008 [49];

RPC. Общее обозначение для класса технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве;

RMI. Вариант реализации RPC – механизм, который позволяет вызывать метод удаленного объекта (чаще всего в среде выполнения Java). Согласно ему, все операции по подготовке и передаче данных инкапсулируются в вызываемом методе клиентского объекта-заглушки (stub). Сам же вызов метода ничем не отличается от вызова метода обычного локального объекта в любой объектно-ориентированной среде программирования;

CORBA. Стандарт для обмена информацией между распределенными по сети информационными объектами [50]. Предполагает наличие централизованного менеджера-брокера, владеющего информацией о местонахождении взаимодействующих единиц;

53

COM/DCOM. Вариант реализации RPC, предназначен для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. Из минусов – реализация ориентирована на продукты корпора-

ции Microsoft;

обмен файлами через файл-сервер. Давняя методика, широко использовавшаяся в эпоху файл-серверных БД, применяется только в локальных сетях. В современных реалиях для обмена может быть удобно использовать XML-файлы, содержащие как данные, так и разметку их структуры. Сам метод обмена файлами является наименее безопасным, но бывает полезен в отладочных целях как наиболее быстро реализуемый.

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

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

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

Среди типовых проблем при интеграции выделяется задача одинакового восприятия некоторых константных значений – типов, групп, категорий и прочих классификаторов. Если ключи одинаковых значений при взаимодействии не совпадают, это полностью нарушает смысловую нагрузку сообщений и приводит к неверному поведению систем.

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

54