- •1.Актуальность темы исследования
- •2. Состояние разработанности проблемы в научной литературе
- •2.1. Существующие стандарты и модели международных организаций
- •2.1.1 Рекомендации мсэ-т и модель tmn
- •2.1.2 Стандарты tm Forum и концепция ngoss
- •2.2. Реализация систем управления
- •2.2.1. Системы nms
- •2.2.2. Системы oss/bss
- •2.2.3. Программная реализация систем управления
- •3. Цель и задачи исследования
- •4. Предполагаемые результаты
- •5. Область внедрения предполагаемых результатов
- •6. Эффективность внедрения предполагаемых результатов
- •6.1. Техническая эффективность
- •6.2. Экономическая эффективность
- •7.Список сокращений и переводов
- •8.Литература
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) могут выступать работники самой компании – оператора/провайдера. В случае, когда в качестве разработчика системы управления выступает компания – разработчик программного обеспечения на выходе получается более унифицированный – «коробочный» продукт, который может обладать ( а может и не обладать – зависит от политики компании) адаптивностью и гибкостью к нуждам клиента. Во втором случае, когда разработчиком выступает вендор, решение является менее гибким, но зато гарантированно работает и оперативно поддерживается производителем.
Рассмотрев представленные решения, можно сделать следующие общие выводы.
Системы в своём большинстве строятся на основе стандартизованных интерфейсов, что призвано обеспечить взаимодействие с другими системами.
Системам управления присуща модульность, что положительно сказывается на унификации сборного решения и лояльности клиента (нет затрат на ненужный функционал).
Все системы управления не являются комплексными, покрывающими все сквозные бизнес-процессы предприятия (решение HPявляется исключением, подчёркивающее общую тенденцию).
Нет решений, базирующихся на несетевом подходе локализации проблем (нет отдельной инфраструктуры/системы управления в составе комплексной – для разрешения проблем ниже сетевого уровня модели OSI).
Данные заключения позволяют систематизировать общие тенденции систем управления, полученные в результате резюмирования общедоступных материалов.