Протокол установления сессии (SIP) представляет собой спецификацию (RFC3261) комитета Internet Engineering Task Force (IETF) по соединению одного или нескольких мультимедийных участников (пользовательских агентов) через Интернет.
Протокол отвечает за создание, изменение и завершение сессий, но не принимает участия в интерпретации обмена медиаданными. После того как соединение между устройствами установлено (то есть устройства обмениваются потоком медиаданных непосредственно друг с другом) SIP-сервис не используется. Но SIP-сервисы помимо соединения двух агентов выполняют и другие полезные функции. Например, при настройке или удалении соединения SIP-сервисы могут выполнять блокировку или переадресацию вызовов, а также реализовывать интерфейс с игровыми системами и системами обработки информации.
Пакет SIP Modeling Toolkit для IBM® Rational® Software Architect (см. раздел "Ресурсы") добавляет SIP-расширения к платформе UML-моделирования и разработки Rational Software Architect. Эти расширения включают доменные профили, базовые модели, преобразования и другие утилиты для моделирования и разработки на основе моделей (model-driven development - MDD) сервисов связи следующего поколения. Набор инструментов также включает расширения генерации кода для существующих преобразований UML-Java™ в среде Rational Software Architect, которые позволяют обновить SIP-элементы имеющихся реализаций сервисов.
Таким образом, данный инструментарий упрощает создание моделей уровня проекта, ориентированных на генерацию кода для SIP-сервлетов. Для этого в нем предусмотрены специализированные базовые модели, а также типовые элементы и свойства, предназначенные для сбора информации, связанной с SIP (например, информация P-Header и т.д.), в моделях сервлетов. Эти модели, элементы и свойства используются в инструментарии для генерации преобразований кода.
SIP Modeling Toolkit позволяет создавать сервисы SIP и объединенные сервисы SIP-HTTP и развертывать их на IBM® WebSphere® Application Server в виде SIP-сервлетов. Набор инструментов также можно настроить для развертывания на других платформах серверов приложений SIP. Реализация SIP-сервисов сервлетами Java™ определена в Java™ Community Process JSR 116. WebSphere Application Server версии 6.1 и выше обеспечивает встроенную поддержку для JSR 116. В данной статье описан сам инструментарий и его ключевые функции.
SIP Modeling Toolkit предназначен для использования в трех ключевых областях моделирования SIP-сервисов:
- Моделирование потоков вызовов: быстрое моделирование потоков SIP вызовов при помощи расширенных циклограмм;
- Моделирование сервлетов: проектирование SIP-сервлетов в контексте конкретных приложений с помощью инструментов и диалоговых окон;
- Преобразования и расширения преобразований: генерация кода SIP-сервлетов и элементов дескрипторов развертывания.
Данный набор инструментов не требует использования какой-либо конкретной методологии для разработки сервисов на основе SIP. Использование моделирования потоков вызовов или сервлетов является необязательным, и хотя их можно применять совместно, друг от друга они не зависят. С другой стороны, преобразования модель-код зависят от моделей сервлетов и правильного использования соответствующих расширений.
Для моделей проектов SIP необходимо, чтобы в UML-модели имелись базовые типы и профили SIP. SIP Modeling Toolkit устанавливает новую базовую модель и профиль, которые можно применять к любой существующей UML-модели. Проще говоря, комплект инструментов включает шаблон модели, который можно использовать для создания новых файлов моделей с примененными базовой моделью и профилем. Базовая модель SIP содержит большинство SIP-типов, применяемых в моделях проектов (на основе JSR116 и расширений WebSphere Application Server), а также SIP-сообщения, готовые для использования в диаграммах потоков вызовов. Профиль SIP включает стереотипы для сервлетов и UML диаграмм коопераций, применяемых в моделировании потоков вызовов. Шаблон модели проекта SIP можно выбрать в списке шаблонов при создании новой UML-модели, как это показано на рисунке 1.
Рисунок 1. Шаблон модели проекта SIP
Один из наиболее простых способов связи определенного сценария деятельности между пользовательскими агентами и SIP-сервисами заключается в использовании диаграммы потоков вызовов. Эти диаграммы, в сущности, представляют собой UML циклограммы, как это показано на рисунке 2. Агент пользователя (User Agent - UA) SIP, как правило, инициирует поток вызовов с помощью сообщения INVITE, передаваемого в SIP-сервис. Этот сервис обычно передает сообщения в другие SIP-сервисы или преобразует сообщения и вызывает другие типы оборудования (например, элементы управления вызовами на объединительной панели).
Рисунок 2. Диаграмма потоков вызовов (частичная)
Большая часть информации обмена между участниками находится в заголовке. SIP Modeling Toolkit содержит специализированный пользовательский интерфейс для регистрации этой дополнительной информации (см. рисунок 3). Настройки пользовательского интерфейса позволяют легко копировать заголовки из других сообщений и реорганизовывать порядок заголовков. Нажатием одной кнопки можно создать или обновить содержимое заголовка на основе фактического содержимого тела сообщения.
Рисунок 3. Сообщение потока вызовов
Потоки вызовов соответствуют очень специфичным сценариям, поэтому самые простые потоки вызовов не содержат ветвей или циклов. Но поскольку моделирование потоков вызовов в Rational Software Architect основано на UML-циклограммах, можно строить сложные диаграммы потоков вызовов с циклами, ветвями и дополнительными разделами, используя все функции UML-циклограмм.
Генерация кода сервлетов или тестового кода
В текущей версии набора инструментов нет средств автоматизации преобразований таких диаграмм потоков вызовов непосредственно в модели или коде реализации. Чтобы сделать это в общем виде, потребовалось бы рассмотреть слишком много проектных решений, которые обычно определяются локально. Однако, поскольку потоки вызовов регистрируются в UML-моделях, можно создать собственные преобразования модель-модель или модель-код, использующие сведения о потоках вызовов для генерации кода сервлета или тестового кода.
Хотя в пакете нет готовых средств автоматизации, можно легко установить трассировку между реализацией SIP-сервиса и поддерживаемыми этим сервисом потоками вызовов. Например, можно определить отношения «trace» между линиями связи потоков вызовов (отдельными участниками в потоке вызовов) и реализующим сервлетом. На рисунке 4 показан сценарий Call Blocked. В качестве примера технологии используется простой поток вызовов для примера приложения Call Blocking, имеющегося в Rational Software Architect.
В сценариях Call Blocked и Call Connected регистрируются только значимые сообщения. Моделирование всех возможных подробностей не требуется: по определению в моделях требуется регистрировать только значимую и существенную информацию.
Остальная часть потока вызовов, представленная на рисунке 4, следует нормальному потоку установления соединений и поэтому не заполняется полностью.
Рисунок 4. Диаграмма потока вызовов для примера блокирования вызова (заблокированного вызова)
Одно из наиболее важных применений моделирования заключается в установлении трассируемости артефактов и элементов проекта. В простейшем случае в простой модели проекта установить трассируемость можно при помощи создания отношений «trace» между реализующими сервлет классами и потоками вызовов, определяемых этими классами.
На рисунке 5 реализация примера Call Blocking показана с отношениями «trace» между определеными ролями участников и классами реализации. Участники потоков вызовов могут трассировать не только «siplet» (основной SIP-сервлет, реализующий SIP-сервис) двух потоков вызовов, но и другие элементы, значимые с точки зрения архитектуры.
Рисунок 5. Трассируемость потоков вызовов
Эти отношения трассировки важны не только в силу их потенциального использования в автоматизации и шаблонах, они также являются важными звеньями в цепи трассируемости между требованиями, реализацией и тестированием. Эти связи, определенные в модели, облегчают процесс анализа и понимания системы, исключая необходимость полагаться на соглашения по именованию и программированию. Ссылки можно просматривать и исследовать во время выполнения анализа влияния, если в системе предполагаются изменения в будущем.
При создании SIP-сервиса обычно начинают с набора требований, который может включать как общие текстовые документы, так и абстрактные примеры потоков вызовов. Эти артефакты уточняются в процессе проектирования, в частности, добавляются подробности к содержимому заголовков в потоках вызовов (можно непосредственно использовать при тестировании), в модель проекта включаются классы внешних API и локальной среды. В некоторых группах разработчиков в качестве механизма объединения потоков вызовов и повышения уровня детализации определенного сервиса могут использоваться UML машины состояний.
Требования к инструментарию
Если рассмотреть фактическую работу по реализации SIP-сервиса, можно заметить, что большая ее часть направлена на создание бизнес-логики, включая доступ к корпоративным объектам, базам данных, Web-сервисам и другим сервисам. Лишь очень малая часть этих сервисов относится собственно к SIP-технологии.
Это означает, что при выборе правильной среды разработки для создания таких сервисов необходимо выбрать среду, которая, помимо SIP-технологий, способна работать со всеми остальными значимыми технологиями.
На рисунке 6 показана простая машина состояний, объединяющая два основных сценария примера блокировки вызовов (Call Blocking). Для разработки поведения сервиса (машины состояния, операции, кооперация и т.д.) UML предоставляет проектировщикам различные средства моделирования.
Рисунок 6. Машина состояния блокировки вызовов
Исполняемым компонентам SIP-сервиса (реализованного в соответствии со спецификацией JSR116) для расширения класса среды SipServlet и для включения нескольких элементов в дескрипторы развертывания sip.xml и web.xml Web-проекта требуется только Java-класс. Сервлеты в данной модели создаются с нуля при помощи элемента панели инструментов для Siplet (SIP-сервлет) или для ConvergedServlet и с помощью создания в модели нового стандартного класса. Стереотипы классов перечислены в таблице 1. Панель содержит инструменты для каждого из трех основных стереотипов в профиле SIP.
Стереотипы для элементов UML-модели позволяют связывать с элементами модели дополнительную семантику. Стереотипы также позволяют определять дополнительные свойства, которые можно регистрировать в модели и использовать в автоматизированных преобразованиях.
Таблица 1. Стереотипы классов в SIP Modeling Toolkit
| Стереотип | Описание |
|---|---|
 Siplet |
Применяется к классам, отвечающим на SIP-сообщения. Стандартный Siplet (SIP-сервлет) классов, приводящий к генерации Java-класса, расширяющего SipServlet. |
 HttpServlet |
Применяется к классам, отвечающим на стандартные HTTP-сообщения. Стандартный HTTPServlet классов отвечает за генерацию классов сервлетов Java (то есть классов расширения HttpServlet). |
 ConvergedServlet |
Применяется к классам, отвечающим на SIP и HTTP-сообщения. Эти сервисы расширяют класс com.ibm.wsspi.sip.converge. ConvergedServlet, предоставляемый WebSphere. |
Если для создания нового Siplet или сервлета используется панель инструментов, то новый класс гарантированно расширяет соответствующий суперкласс из базовой модели SIP (см. рисунок 7). Если панель инструментов не используется, к классу можно применять стереотип, что позволяет расширить другой класс или интерфейс среды.
Рисунок 7. Новые сервлеты в модели проекта
Реализация этого сервиса, как описано при помощи набора диаграмм потоков вызовов, начинается с модели проекта с единственным стандартным классом, расширяющим правильный класс среды. Методы этого класса принимают запросы SIP-клиентов и отвечают за обмен данными с прокси для установления сессии с одним или несколькими другими устройствами.
Siplet функционирует в большом проекте, который включает другие классы и API библиотек, используемые для реализации сервиса. Для всех SIP-сервисов, за исключением самых тривиальных, реализация функционирует в большом приложении и связывается с серверными процессами, базами данных, корпоративными компонентами и другими сервисами, как это показано на рисунке 8.
Рисунок 8. Структурные фрагменты модели проекта SIP-сервиса
Основной мотив для использования стереотипов - это идентификация отдельных классов в качестве основных реализаций для поведения SIP-сервиса. Для "регистрации" этих классов на Web-сервере приложений требуется дополнительная метаинформация. Эта информация связывается со стереотипом и представляется разработчику в форме специальной панели (см. рисунок 9). Панель доступна в виде новой вкладки в стандартном разделе панели Properties
В случае Siplet данная информация включает шаблон или критерий фильтра, определяющий условия активации этого Siplet контейнером. Шаблон представляет собой простую древовидную структуру, выполняющую преобразование в XML-фрагмент и используемую непосредственно в дескрипторе развертывания (в соответствии с JSR116).
Рисунок 9. Панель свойств Siplet 
Остальная часть представления дает удобный способ добавления переопределений методов для большинства методов SIP-сервлетов. Свойство Load On Startup представляет собой стандартное поле дескриптора развертывания web.xml. Оно указывает относительный критерий важности, который активируется этим сервлетом при запуске сервера. Флажки в панели позволяют задать переопределения общих методов.
Когда модель проекта будет почти готова, необходимо преобразовать проект в Java-код и дескрипторы развертывания. Пакет SIP Modeling Toolkit включает расширение преобразования для преобразований UML-Java (как для Java 1.4, так и для Java 5). Поэтому для генерации кода сервлетов SIP и HTTP используется такое же преобразование, как и для общего Java-кода. Для генерации необходимого содержимого SIP ничего другого и не требуется.
Извлечение имеющейся информации о развертывании SIP
Для существующих SIP-приложений информацию из дескрипторов развертывания sip.xml и web.xml можно преобразовать в модель проекта SIP Design Model. Для этого необходимо создать новую конфигурацию преобразования подобно созданию преобразования UML-Java. Эта новая конфигурация преобразования, предоставляемая SIP Modeling Toolkit, называется преобразованием SIP в UML (см. рисунок 10).
Рисунок 10. Создание нового обратного преобразования
Единственными параметрами для этого преобразования являются Web-проект и модель назначения. Применение этого преобразования приводит к обновлению модели, создающей классы SIP-сервлетов, HTTP-сервлетов или объединенных сервлетов и обновляющей SIP-свойства из дескрипторов развертывания. Данное преобразование только обновляет содержимое дескрипторов развертывания. Обновление атрибутов, операций или ассоциаций классов не выполняется. Наряду с остальным содержимым Java эти операции можно выполнить при помощи преобразования Java-UML, имеющегося в Rational Software Architect.
Процесс проектирования начинается с ввода данных, полученных от аналитиков, обычно в форме диаграмм потоков вызовов, которые можно зарегистрировать в виде циклограмм. Некоторые проектировщики объединяют эти диаграммы в UML-машину состояний или UML-операцию для создания нового поведения для всех сценариев. Машина состояний или операция представляет отдельный компонент поведения, который, будучи реализованным в виде SIP-сервиса, поддерживает все потоки вызовов. Это также хороший механизм анализа для определения неопределенностей и конфликтов в ожидаемых сценариях.
Проектирование сервиса начинается с создания в UML-модели стандартного класса «Siplet». Этот класс непосредственно сопоставляется основному классу реализации SipServlet. Проектировщик задает доменную SIP информацию в пользовательских панелях Properties, затем добавляет к проекту дополнительные классы, подключения к Web-сервисам, базам данных, корпоративным компонентам и т.д. Как указано ранее, большая часть работы по проектированию и реализации SIP-сервиса в фактической среде приходится на создание бизнес-логики взаимодействия с другими классами и технологиями.