Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Реферат по философии.2.1.doc
Скачиваний:
47
Добавлен:
03.05.2015
Размер:
9.87 Mб
Скачать

2.2.3. Программная реализация систем управления

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

Самым распространённым и гибким решением на сегодняшний момент является так называемое “midleware” - промежуточный слой для обеспечения взаимодействия систем. изначальным вариантом, получившим широкое распространение, было сочетание MTMN с CORBA. Такое решение имело целый ряд недостатков, в частности узкий круг применения - только между уровнями EML и NML модели TMN и необходимость наличия индивидуального интерфейса для взаимодействия каждой EMS. Впоследствии после ряда итераций для MTMN было предложено использовать XML в качестве IDL.

Наиболее актуальной альтернативой MTOSI/XML на сегодняшний день представляется инициатива OSS/J TMForum, которая в качестве языка описания взаимодействия использует язык Java и его приложения. Основной разницей между MTOSI/XML и OSS/J является объект действия: в MTOSI/XML им является процесс, а в OSS/J - сущность. Это является следствием того, что при разработке концепций преследовались различные цели: MTMN, а в последствии MTOSI, должна была обеспечить независимость от гетерогенности сетевых эле­ментов и транспортных технологий, в то время как OSS/J разрабатывалась в качестве надстройки для взаимодействия систем OSS/BSS вне зависимости от используемого верхнеуровнего протокола (JMS, HTTP и т.д.).

В силу очевидной необходимости взаимодействия брокеров объектных запросов (ORB) систем, построенных с согласно концепции TMForum MTOSI и OSS/J, которая выделилась в отдельное направление развития, в обоих сообществах ведутся работы по формированию рекомендательных документов для обеспечения взаимодействия таких структур и API, соответственно.

Пример такого рекомендательного взаимодействия приведён ниже.

Рисунок 13. Общая эталонная структура трансляции IDL CORBA в OSS/J - объекты

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

Рассмотрев представленные решения, можно сделать следующие общие выводы.

  1. Системы в своём большинстве строятся на основе стандартизованных интерфейсов, что призвано обеспечить взаимодействие с другими системами.

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

  3. Все системы управления не являются комплексными, покрывающими все сквозные бизнес-процессы предприятия (решение HPявляется исключением, подчёркивающее общую тенденцию).

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

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