Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

Формирование услуг в IMS с помощью контейнера сервлетов Java EE SIP

Торстен Динсинг, Горан А. П. Эрикссон, Иоаннис Фикоурас, Кристофер Гроновски, Роман Левенштейн, Пер Петтерссон, Патрик Висс

Подсистема IP-мультимедиа (IMS) предоставляет разработчикам, операторам и сервис-провайдерам возможность создавать и предлагать новые услуги с помощью стандартной маршрутизации по протоколу SIP. С целью дальнейшего улучшения и расширения возможностей IMS по созданию услуг исследовательский отдел компании Ericsson разработал инструментарий, использующий ключевые механизмы IMS, контейнеры сервлетов Java EE SIP и технологии формирования услуг.

Авторы описывают подход к формированию новых услуг посредством этого инструментария и функций, реализуемых, например, SIP-приложениями в среде сервера приложений Java EE, платформой доставки услуг (SDP) или стандартизированными IMS-инструментами.

Введение

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

Полную версию данной статьи смотрите в 3-м номере журнала за 2008 год.

Контейнер SIP-сервлетов в IMS

Контейнер SIP-сервлетов, параметры которого определены в проекте документа JSR 289, управляет находящимися в нем SIP-приложениями, а также предоставляет доступ к механизмам протокола инициации сеанса через API-интерфейс на языке Java.

Java Platform Enterprise Edition (Java EE) представляет собой масштабируемое межплатформенное ПО, используемое в телекоммуникационной отрасли. Сервер приложений (Application Server — AS) Java EE служит платформой, на которой развертывается контейнер SIP-сервлетов. AS поддерживает сетевые службы — с их помощью осуществляются отправка и получение SIP-запросов и ответов.

Сервер приложений в IMS связан с блоком управления сеансами связи (CSCF) посредством интерфейса управления IMS-сервером (ISC). Инициирующие SIP-запросы, полученные сервером от CSCF, передаются контейнеру. Контейнер определяет нужное SIP-приложение путем опроса объекта, именуемого маршрутизатором приложений (Application Router — AR). Затем контейнер направляет запрос выбранному SIP-приложению. Если SIP-приложение не терминирует запрос, контейнер снова запрашивает у маршрутизатора информацию о том, какое SIP-приложение должно быть вызвано следующим (рис. 1).

Помещая маршрут в заголовок SIP-сообщения (аналогично тому, как CSCF назначает маршрут к серверу приложений IMS), маршрутизатор приложений может также отдать контейнеру команду направить запрос SIP-приложению, размещенному на другом сервере.

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

Механизм формирования SIP-услуг

Специалисты компании Ericsson спроектировали и реализовали механизм формирования услуг, использующий интерфейс AR для предоставления контейнеру решений по SIP-маршрутизации во время рабочего цикла — данный процесс именуется динамической SIP-маршрутизацией. В предложенном подходе используются данные: состояния, поддерживаемого формирующим механизмом; SIP-сигнализации; формальных описаний SIP-услуг, предоставляемых SIP-объектами; внешних объектов, опрошенных во время рабочего цикла посредством SIP или других технологий — например, веб-служб; виртуальной машины Java (Java Virtual Machine — JVM) —в частности, такие, как время и текущая загрузка.

Механизм формирования услуг от Ericsson может рассматриваться как программируемая машина состояний, которая объединяет составные части SIP-служб (например, SIP-приложения в контейнере) для создания новых многофункциональных композитных услуг.

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

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

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

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

Ключевая формирующая логика применима к самым разным технологиям и протоколам. Формирующий механизм, таким образом, не ограничивается SIP-услугами. Например, для опроса внешних объектов с целью принятия решений о маршрутизации (на рис. 2, например, это установление связи с SIP-приложением 2) или исполнения бизнес-процессов SDP — в частно-сти, тарификации или сбора пользовательской статистики может использоваться вызов веб-службы.

Более того, SIP-приложения, предоставляющие SIP-услуги, можно также развертывать на различных серверах приложений. В этом случае формирующий механизм использует AR-интерфейс для принудительного задействования SIP-маршрута, указывающего на другой сервер приложений (см. рис. 2). Если для формирующего механизма необходимо, чтобы SIP-запрос был возвращен текущему серверу приложений после завершения обработки другим сервером, в SIP-сообщение также помещается указывающий на него маршрут. При необходимости другой сервер приложений можно оставить на SIP-пути посредством стандартных SIP-методов.

Среда формирования услуг

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

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

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

Динамическое формирование SIP-услуг

Технологии, описанные в настоящей статье, представляют собой платформу приложений на базе SIP. Блок CSCF определяет сеансы, во время которых должен запускаться формирующий механизм, и связывает SIP-объекты в соответствии с первичными критериями фильтрации (iFC). Задействуя хранящиеся во внутренней памяти или полученные данные, формирующий механизм обращается к алгоритмам SIP-маршрутизации для динамической агрегации SIP-объектов (сервисных составляющих) во время маршрутизации первичного SIP-запроса (рис. 3). Таким образом, формирующий механизм дополняет собой CSCF.

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

Пример развертывания: IPTV

Рассмотрим гипотетический пример объединения IPTV-приложения на базе IMS с приложением для чата с функцией определения присутствия абонента. Находясь дома, пользователь (Шелли) иногда хочет, чтобы ее друзья знали, какой канал IPTV она смотрит. При традиционном подходе к реализации этой функции в настройках IPTV-устройства необходимо было бы преду-смотреть возможность отправлять сообщения SIP PUBLISH на сервер определения присутствия абонентов, с которого уведомление затем направлялось бы друзьям Шелли.

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

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

В свою очередь, IPTV-контроллер связывается с CSCF, руководствуясь критериями iFC. Когда Шелли уже выбрала канал, формирую-щий механизм перехватывает SIP-сообщение, содержащее информацию о нем. На основании соответствующего правила механизм «принимает решение» о необходимости включить агент определения присутствия абонента в сети (PNA) в SIP-сеанс IPTV. В случае положительного решения формирующий механизм запускает PNA, который отправляет сообщение SIP PUBLISH с указанием выбранного канала на сервер определения присутствия абонентов (рис. 4, 5).

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

Для публикации информации о присутствии абонента могут задаваться различные типы правил (например, правило, учитывающее местонахождение абонента). Более того, эти правила не являются жестко детерминированными — допускается их динамическая оценка формирующим механизмом во время настройки сеанса IPTV. Выбор правила может осуществляться на уровне отдельного абонента (разные правила для разных абонентов). Также поддерживается обновление существующих или задание новых правил без необходимости внесения изменений в формирующий шаблон. Абоненты (в рассмотренном примере — Шелли) имеют даже возможность вносить изменения в свои правила через портал, предоставляющий доступ к базе правил. Все изменения последних автоматически учитываются во время установления очередного сеанса.

Формирующий шаблон агрегирует цепочку сервисных составляющих для обработки первичного SIP-запроса, в данном случае SIP INVITE. Из профиля абонента он берет название предпочтительного правила предоставления информации о присутствии абонента. После того как название предпочтительного правила получено, выполняется проверка соответствующего правила. На рис. 5 (справа) показано правило учета местонахождения абонента, которое удовлетворяется в случае нахождения абонента дома. После успешной проверки правила, согласно формирующему шаблону, компонент PNAHandler заносится в SIP-цепочку.

Заключение

Ericsson входит в отраслевое объединение JSR 289, которое занимается стандартизацией интерфейса маршрутизатора приложений (AR) с контейнером сервлетов Java EE SIP, управляющим порядком связывания SIP-объектов с SIP-сеансом.

Специалисты компании Ericsson доказали, что расширяемый формирующий механизм обеспечивает гибкий способ реализации настраиваемых услуг. Формирующий механизм гибко связывает услуги, предоставляемые SIP-объектами. В частности, SIP-объекты, предоставляемые инструментами реализации IMS, могут объединяться в новые многофункциональные композитные услуги.

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

Фактором, определяющим успех развития данной области в будущем, является продолжение сотрудничества членов сообщества в направлении создания общей структуры, включающей в себя, в частности, интерфейсы API, расширения SIP и форматы описания SIP-услуг.

Об авторах
Динсинг Торстен, Эрикссон 
Горан А. П., Фикоурас Иоаннис, Гроновски Кристофер, 
Левенштейн Роман, 
Петтерссон Пер, Висс Патрик, 
сотрудники компании Ericsson


  
3 '2008
СОДЕРЖАНИЕ

бизнес

• Одна частная история Ethernet

• Очарование новых информационных технологий

• Текучесть кадров: система раннего предупреждения

• Корпоративный веб-хостинг

инфраструктура

• Вкладывайте деньги в автоматизацию ИТ-процессов

• Как снизить энергопотребление ЦОДа

• Станут ли сети стандарта 802.11n «добрыми соседями»?

• Аналитика для «интеллектуальных» IP-систем видеонаблюдения

• Внутритрактовые NAC-устройства

• Нехватка электроэнергии и проектирование ЦОДа

информационные системы

• Формирование услуг в IMS с помощью контейнера сервлетов Java EE SIP

• Приложения ждет реструктуризация

сети связи

• SIP-коммуникации: время наконец пришло?

кабельные системы

• Системам 100-Gigabit Ethernet быть!

• Вездесущие медиаконвертеры


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх