Учебные пособия / Усков М.В., Гольдштейн А.Б., Кисляков С.В. Программирование систем управления ИКС (черновик)

Рисунок 23. Карта кабельной канализации с фрагментами кабеля в OSS Аргус

Рисунок 24. Пример отображения зоны радиопокрытия антенны DECT в OSS Аргус.

41

Рисунок 25. Фрагмент программного кода на встроенном языке MapInfo MapBasic

4.ИНТЕГРАЦИЯ КОМПОНЕНТОВ OSS МЕЖДУ СОБОЙ

ИСО СМЕЖНЫМИ СИСТЕМАМИ АВТОМАТИЗА-

ЦИИ

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

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

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

Ниже представлены основные факторы, влияющие на интеграцию

[42]:

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

42

Распределенность. Организации становятся все более крупными, а решаемые задачи все более комплексными, появляется логическая, организационная и географическая рассредоточенность.

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

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

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

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

Интерактивность. Потребитель информации постоянно повышает свои ожидания о скорости реакции системы, быстродействии и оперативности доставки информации. Большинство процессов стремятся к выполнению в реальном времени.

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

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

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

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

Межсистемная интеграция. Задачи стыковки не ограничены рамками организации, все чаще нужно интегрироваться с партнерами, клиентами, поставщиками, подрядчиками и даже с государственными структурами.

43

4.1. Изоляция между приложениями, связность между понятиями среды

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

Рисунок 26. В исключительных случаях модули OSS не взаимодействуют между собой.

В тех случаях, когда при взаимодействии продуктов затронуты очень общие (наиболее широко используемые) предметные понятия, удобно использовать интеграцию через общий разделяемый домен (shared domain). Чаще всего подобная интеграция ограничивается работой с общими данными в хранилище, без прямой передачи управления от одного компонента к другому.

44

Рисунок 27. В случае взаимодействия по наиболее общим сущностям, такие общие понятия/службы выносится в shared domain (и

становятся частью общей среды)

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

ипередавать управление друг другу в рамках общего бизнес-процесса, используется OSS/J-подобный способ интеграции, посредством стандартизи-

рованных интерфейсов (API, Application Programming Interface).

45

Рисунок 28. Взаимодействие интегрируемых модулей OSS через открытые API

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

46

Рисунок 29. Организация взаимосвязи компонентов через подключение встраиваемого фрейма в пользовательском web-

интерфейсе

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

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

[43].

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

47

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

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

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

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

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

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

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

48

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

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

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

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

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

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

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

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

PostgreSQL [46].

49

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]. Предполагает наличие централизованного менеджера-брокера, владеющего информацией о местонахождении взаимодействующих единиц.

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

Microsoft.

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

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

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

50