Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Анализ современных систем управления телекоммуникациями. Учебное пособие
.pdf
Рисунок 2.4 – Структура NGOSS
Концепция NGOSS провозглашает 10 ключевых принципов, в
соответствии с которыми должны строиться системы OSS/BSS следующего
поколения.
1. Преображение бизнеса оператора связи. Главная задача NGOSS
состоит в том, чтобы облегчить автоматизацию бизнес-процессов в
сочетании с повышением гибкости и «маневренности» бизнеса.
2. Снижение финансовых и временных затрат на развитие IT-
инфраструктуры благодаря использованию широкодоступных с компонентов
программного обеспечения.
3. Чёткая и понятная методика миграции путём плавного перехода от
унаследованных систем и их интеграции в новое решение.
4. Снижение стоимости разработки ПО и связанных с ней рисков
путём активного использования опыта, накопленного в отрасли, и
общепринятых стандартов. Наиболее удачные разработки адаптируются для
использования в IT-среде телекоммуникационной компании.
30
5. Обеспечение комплексных, охватывающих деятельность всего
предприятия решений для различных сегментов отрасли связи, включая
операторов фиксированных, мобильных, кабельных сетей. Концепция
NGOSS нацелена на весь рынок инфокоммуникаций, а не на какой-то один
его сегмент.
6. Обеспечение доступа к корпоративным данным в любой точке IT -
инфраструктуры компании и со стороны коммерческих партнёров.
7. Создание условий для развития бизнеса оператора связи путём
использования легко расширяемых слабосвязанных распределённых систем
управления.
8. Обеспечение возможности изменения бизнес-процессов, не
затрагивая программное обеспечение, посредством отделения управления
потоком и логикой бизнес-процесса от работы приложений. В решении
NGOSS управление бизнес-процессами осуществляется независимо от
функционирования автоматизирующих отдельные их шаги приложений.
Таким образом, удаётся обеспечить необходимую гибкость для быстрого
развёртывания новых бизнес-решений и многократного использования
компонентов в различных сценариях.
9. Использование чётко определённых согласованных интерфейсов
между приложениями с целью упрощения системной интеграции. Важной
задачей NGOSS является максимальное расширение возможностей
многократного использования компонентов бизнес-процессов. Это может
быть достигнуто за счёт спецификации согласованных интерфейсов для
каждого компонента ПО.
10. Использование общей интеграционной шины для взаимодействия
компонентов с целью упрощения системной интеграции. [5]
31
2.3 Технологии построения современных
распределённых систем
В последние годы резко возрос интерес к распределённым системам.
Под распределёнными системами понимают программные комплексы,
составные части которых функционируют на разных компьютерах в сети.
Эти части взаимодействуют друг с другом, используя ту или иную
технологию различного уровня – от непосредственного использования
TCP/IP до технологий с высоким уровнем абстракции, таких, как RMI или
CORBA.
Рост популярности распределённых систем вызван существенным
ужесточением требований, предъявляемых заказчиком к современным
программным продуктам. Важнейшими из этих требований являются
следующие –
Обеспечение масштабируемости систем, т.е. способности
эффективно обслуживать как малое, так и очень большое
количество клиентов одновременно.
Надёжность создаваемых приложений. Программный комплекс
должен быть устойчив не только к ошибкам пользователей, но и
к сбоям в системе коммуникаций. Надёжность подразумевает
использование транзакций, т.е. гарантированного перехода
системы в процессе функционирования из одного устойчивого и
достоверного состояния в другое.
Возможность непрерывной работы в течение длительного
времени (режим круглосуточной работы в течение недель и
месяцев).
Высокий уровень безопасности системы, под которой понимается
не только контроль доступности тех или иных ресурсов системы
и защищённость информации на всех этапах функционирования,
32
но и отслеживание выполняемых действий с высокой степенью
достоверности.
Высокая скорость разработки приложений и простота их
сопровождения и модификации с использованием программистов
средней квалификации.
На сегодняшний день выделяются различные технологии,
поддерживающие концепцию распределённых объектных систем.
2.3.1 RMI (Remote Method Invocation)
RMI – программный интерфейс вызова удалённых методов в языке
Java. Архитектура RMI является продуктом компании JavaSoft и реализует
распределённую модель вычислений. RMI позволяет клиентским и
серверным приложениям через сеть вызывать методы клиентов/серверов,
выполняющихся в Java Virtual Machine. Хотя RMI считается легковесной и
менее мощной, чем CORBA и DCOM тем не менее, она обладает рядом
уникальных свойств, таких как распределённое, автоматическое управление
объектами и возможность пересылать сами объекты от машине к машине.
На рисунке 2.5 показаны основные компоненты архитектуры RMI.
Рисунок 2.5 – Модель RMI
Client Stub (переходник для клиента) и Server Stub (переходник для
сервера) порождены от общего интерфейса, но различие между ними в том,
33
что client stub служит просто для подсоединения к RMI Registry, а server stub
используется для связи непосредственно с функциями сервера.
Благодаря своей легкоиспользуемой Java-модели, RMI является
самым простым и самым быстрым способом создания распределённых
систем. RMI - хороший выбор для создания RAD-компонент и небольших
приложений на языке Java. Поддержка только одного языка делает
невозможным взаимодействие с объектами, написанными на другом языке.
Тем самым, роль RMI в создании больших, масштабируемых промышленных
систем, снижается.
2.3.2 DCOM (Distributed Component Object Model)
Технология DCOM была разработана компанией Microsoft в качестве
решения для распределённых систем в 1996-м году. Сейчас DCOM является
главным конкурентом CORBA.
DCOM - программная архитектура для распределения приложений
между несколькими компьютерами в сети. Программный компонент на
одной из машин может использовать DCOM для передачи сообщения (его
называют удалённым вызовом процедуры) к компоненту на другой машине.
DCOM автоматически устанавливает соединение, передает сообщение и
возвращает ответ удалённого компонента.
DCOM - технология, обеспечивающая взаимодействие между
компонентами приложения и позволяющая развертывать распределённое
приложение на платформе Windows. DCOM связывает воедино
разнообразные технологии, применяемые в распределённых приложениях.
DCOM даёт возможность двум или нескольким компонентам легко
взаимодействовать друг с другом независимо от того, когда и на каком языке
программирования они были написаны, а также где именно они находятся и
в какой операционной системе работают.
34
Рисунок 2.6 – Архитектура DCOM
Рисунок 2.6 показывает архитектуру DCOM в общем: СОМ run-time
предлагает клиентам и компонентам объектно-ориентированные сервисы и
использует RPC (Remote Procedure Call) и провайдер безопасности для
генерации стандартных сетевых пакетов, соответствующих стандарту
протокола DCOM.
Идея вызова удалённых процедур (Remote Procedure Call — RPC)
состоит в расширении механизма передачи управления и данных внутри
программы, выполняющейся на одной машине, на передачу управления и
данных через сеть. Средства удалённого вызова процедур предназначены для
облегчения организации распределённых вычислений и создания
распределённых клиент-серверных информационных систем.
2.3.3 CORBA (Common Object Request Broker
Architecture)
CORBA – это стандарт, набор спецификаций, для промежуточного
программного обеспечения объектного типа, возникающий в результате
самого широкого обсуждения накопившихся реальных проблем, в котором
участвуют и разработчики и потребители технологий. Достоинством
опережающей разработки спецификации по сравнению с реализацией
35
является возможность для независимых разработчиков создавать
Клиент Реализация Объекта
Динамический вызов
или вызов с
помощью стаба IDL
Интерфейс
ORB
Скелетон
Ядро ORB
Объектный
Адаптер
потенциально совместимые продукты, не ограничивая свободы выбора
языков, ОС, аппаратных платформ, и не диктуя выбора конкретного
технологического решения. Под термином "CORBA" понимается сложная и
развитая концепция, которая сформулирована на уровне специального языка
описаний – IDL. Реализации же этой концепции могут сильно отличаться
друг от друга по различным критериям, наиболее важным в том или другом
случае.
CORBA определяет среду для различных реализаций ORB (Object
request broker – брокер объектных запросов), поддерживающих общие
сервисы и интерфейсы (рисунок 2.7). Это обеспечивает мобильность
клиентов и реализаций объектов по отношению к различным реализациям
ORB. ORB обеспечивает интероперабельность компонентов глобального
объектного пространства. Определения интерфейсов объектов могут быть
помещены в Репозитарий Интерфейсов (Interface Repository) двумя
способами: статически - в результате спецификации на IDL, или
динамически. Репозитарий представляет компоненты интерфейса как
объекты и обеспечивает доступ к ним в период выполнения.
языков программирования – Ada, C, C++, Cobol, Java и Smalltalk.
Рисунок 2.7 – Архитектура СORBA
В настоящий момент стандартизовано отображение языка IDL на 6
36
Существуют также отображения на Pascal (точнее, Delphi), Perl, Python и ещё
несколько языков, но они не стандартизованы.
CORBA подходит к механизмам обмена и передаче данных.
Определён протокол CORBA (General Inter-ORB Protocol, GIOP) – и его
реализация на базе протокола TCP/IP (Internet Inter-ORB Protocol, IIOP). Для
каждого языка используется свое отображение данных IDL.
Сложность CORBA заключается в её огромных возможностях.
Программисту необходимо знать большое количество интерфейсов из
различных сервисов CORBA, правильно использовать возможности
объектных адаптеров и многое другое. Поскольку CORBA использует
различные схемы отображения IDL на разные языки программирования, то
программисту в общем случае надо знать их особенности для 2-3 наиболее
широко используемых языков – в первую очередь, C++ и Java.
Глава 3 Технические решения для управления
сетями связи
3.1 Система управления сетью INC-100MS
Система управления сетью INC-100MS соответствует концепции Сети
Управления Телекоммуникациями (TMN), описанной в Рекомендациях ITUT. INC-100MS поддерживает два нижних уровня: уровень управления
сетевым элементом (EML) и уровень управления сетью (NML). EML
управляет сетевым элементом независимо. NML отвечает за управление
связью между NE.
INC-100MS, основанная на объектно-ориентированном подходе,
способна обеспечить открытый интерфейс (Q3) для соединения с системой
управления сетью более высокого уровня клиента при работе с системами
других производителей.
37
Рисунок 3.1 – Системы управления сетью INC-100MS
Архитектура INC-100MS базируется на конфигурации клиент/сервер.
Клиенты имеют доступ к серверу через интерфейс CORBA, а также сервер
NMS общается с сервером EMS посредством интерфейса CORBA. Если
необходимо, несколько клиентов могут быть подключены к одному серверу.
Сервер выполняет функцию базы данных по управлению (MIB).
Сервер EMS выполняет функцию многопротокольного интерфейса, которая
обеспечивает различные интерфейсные модули для поддержки широкого
спектра сетевых элементов. Клиент обеспечивает различные пакеты
приложений и графический интерфейс пользователя. Пакеты приложений
разделены на различные функциональные пакеты, такие как управление
авариями и управление качеством.
3.1.2 Основные функции
Программное обеспечение состоит из платформы программного
обеспечения (операционная система, система управления базой данных,
38
графический интерфейс пользователя (GUI), система коммуникаций), а также
программное обеспечение приложений.
Создание карт
Иерархические карты могут быть созданы для упрощения навигации по
управляемой сети. Обычно корневая карта показывает всю управляемую
область с символами регионов. Каждый регион имеет свою собственную
подкарту.
Создание базы данных
До или во время работы INC-100MS, оператору необходимо создать или
обновить базу данных по сетевым ресурсам. База состоит из
административного домена, офиса, сетевого элемента (NE), внешних
устройств, подсети, секции.
Доступ к информации
Оператор имеет возможность выбрать пункт, чью информацию ему
необходимо получить. Информация включает не только данные,
запрашиваемые оператором, но также и процент загруженности секции,
текущее состояние резервирования, список секций, включённых в тракт.
INC-100MS обеспечивает функции управления самой системой
управления и сетью передачи данных между INC-100MS и контролируемыми
NE.
Контроль режима работы
Оператор имеет возможность управлять режимом работы серверов с
консоли клиента. Каждый сервер в конфигурации с резервом может быть
уведён в режим off-line во время модернизации программного обеспечения
или восстановления базы данных для непрерывной работы.
Управление связями
Механизм проверки связи непрерывно наблюдает за связью с NE. При
восстановлении связи после потери связи INC-100MS автоматически
39
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]