Введение в SIP Modeling Toolkit для IBM Rational Software Architect

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Джим Коналлен, старший инженер-программист, IBM

22.10.2007

Инструментарий SIP Modeling Toolkit для IBM® Rational® Software Architect представляет собой набор доменных расширений для платформы Rational Software Architect. Набор содержит инструменты, позволяющие органично использовать платформу Rational Software Architect для проектирования и разработки технологий, основанных на Session Initiation Protocol (SIP). В статье также показано, как можно интегрировать платформу Rational Software Architect с элементами Domain Specific Language (DSL) в единую среду разработки. В расширения набора инструментов входят профили унифицированного языка моделирования (Unified Modeling Language - UML), базовые модели, элементы пользовательского интерфейса, преобразования и расширения преобразований.

Введение

Протокол установления сессии (SIP) представляет собой спецификацию (RFC3261) комитета Internet Engineering Task Force (IETF) по соединению одного или нескольких мультимедийных участников (пользовательских агентов) через Интернет.

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

Поделитесь мнением... Отзыв на digg.com Публикация на del.icio.us Публикация на slashdot

Пакет 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

Для моделей проектов SIP необходимо, чтобы в UML-модели имелись базовые типы и профили SIP. SIP Modeling Toolkit устанавливает новую базовую модель и профиль, которые можно применять к любой существующей UML-модели. Проще говоря, комплект инструментов включает шаблон модели, который можно использовать для создания новых файлов моделей с примененными базовой моделью и профилем. Базовая модель SIP содержит большинство SIP-типов, применяемых в моделях проектов (на основе JSR116 и расширений WebSphere Application Server), а также SIP-сообщения, готовые для использования в диаграммах потоков вызовов. Профиль SIP включает стереотипы для сервлетов и UML диаграмм коопераций, применяемых в моделировании потоков вызовов. Шаблон модели проекта SIP можно выбрать в списке шаблонов при создании новой UML-модели, как это показано на рисунке 1.

В начало

Моделирование потоков вызовов

Один из наиболее простых способов связи определенного сценария деятельности между пользовательскими агентами и SIP-сервисами заключается в использовании диаграммы потоков вызовов. Эти диаграммы, в сущности, представляют собой UML циклограммы, как это показано на рисунке 2. Агент пользователя (User Agent - UA) SIP, как правило, инициирует поток вызовов с помощью сообщения INVITE, передаваемого в SIP-сервис. Этот сервис обычно передает сообщения в другие SIP-сервисы или преобразует сообщения и вызывает другие типы оборудования (например, элементы управления вызовами на объединительной панели).

Большая часть информации обмена между участниками находится в заголовке. SIP Modeling Toolkit содержит специализированный пользовательский интерфейс для регистрации этой дополнительной информации (см. рисунок 3). Настройки пользовательского интерфейса позволяют легко копировать заголовки из других сообщений и реорганизовывать порядок заголовков. Нажатием одной кнопки можно создать или обновить содержимое заголовка на основе фактического содержимого тела сообщения.

Потоки вызовов соответствуют очень специфичным сценариям, поэтому самые простые потоки вызовов не содержат ветвей или циклов. Но поскольку моделирование потоков вызовов в Rational Software Architect основано на UML-циклограммах, можно строить сложные диаграммы потоков вызовов с циклами, ветвями и дополнительными разделами, используя все функции UML-циклограмм.

Генерация кода сервлетов или тестового кода

В текущей версии набора инструментов нет средств автоматизации преобразований таких диаграмм потоков вызовов непосредственно в модели или коде реализации. Чтобы сделать это в общем виде, потребовалось бы рассмотреть слишком много проектных решений, которые обычно определяются локально. Однако, поскольку потоки вызовов регистрируются в UML-моделях, можно создать собственные преобразования модель-модель или модель-код, использующие сведения о потоках вызовов для генерации кода сервлета или тестового кода.

Хотя в пакете нет готовых средств автоматизации, можно легко установить трассировку между реализацией SIP-сервиса и поддерживаемыми этим сервисом потоками вызовов. Например, можно определить отношения «trace» между линиями связи потоков вызовов (отдельными участниками в потоке вызовов) и реализующим сервлетом. На рисунке 4 показан сценарий Call Blocked. В качестве примера технологии используется простой поток вызовов для примера приложения Call Blocking, имеющегося в Rational Software Architect.

В сценариях Call Blocked и Call Connected регистрируются только значимые сообщения. Моделирование всех возможных подробностей не требуется: по определению в моделях требуется регистрировать только значимую и существенную информацию.

Остальная часть потока вызовов, представленная на рисунке 4, следует нормальному потоку установления соединений и поэтому не заполняется полностью.

Установление трассируемости

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

На рисунке 5 реализация примера Call Blocking показана с отношениями «trace» между определеными ролями участников и классами реализации. Участники потоков вызовов могут трассировать не только «siplet» (основной SIP-сервлет, реализующий SIP-сервис) двух потоков вызовов, но и другие элементы, значимые с точки зрения архитектуры.

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

В начало

Моделирование сервлетов

Требования к инструментарию Если рассмотреть фактическую работу по реализации SIP-сервиса, можно заметить, что большая ее часть направлена на создание бизнес-логики, включая доступ к корпоративным объектам, базам данных, Web-сервисам и другим сервисам. Лишь очень малая часть этих сервисов относится собственно к SIP-технологии. Это означает, что при выборе правильной среды разработки для создания таких сервисов необходимо выбрать среду, которая, помимо SIP-технологий, способна работать со всеми остальными значимыми технологиями.

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

На рисунке 6 показана простая машина состояний, объединяющая два основных сценария примера блокировки вызовов (Call Blocking). Для разработки поведения сервиса (машины состояния, операции, кооперация и т.д.) UML предоставляет проектировщикам различные средства моделирования.

Исполняемым компонентам SIP-сервиса (реализованного в соответствии со спецификацией JSR116) для расширения класса среды SipServlet и для включения нескольких элементов в дескрипторы развертывания sip.xml и web.xml Web-проекта требуется только Java-класс. Сервлеты в данной модели создаются с нуля при помощи элемента панели инструментов для Siplet (SIP-сервлет) или для ConvergedServlet и с помощью создания в модели нового стандартного класса. Стереотипы классов перечислены в таблице 1. Панель содержит инструменты для каждого из трех основных стереотипов в профиле SIP.

Стереотипы для элементов UML-модели позволяют связывать с элементами модели дополнительную семантику. Стереотипы также позволяют определять дополнительные свойства, которые можно регистрировать в модели и использовать в автоматизированных преобразованиях.

Стереотип	Описание
Siplet	Применяется к классам, отвечающим на SIP-сообщения. Стандартный Siplet (SIP-сервлет) классов, приводящий к генерации Java-класса, расширяющего SipServlet.
HttpServlet	Применяется к классам, отвечающим на стандартные HTTP-сообщения. Стандартный HTTPServlet классов отвечает за генерацию классов сервлетов Java (то есть классов расширения HttpServlet).
ConvergedServlet	Применяется к классам, отвечающим на SIP и HTTP-сообщения. Эти сервисы расширяют класс com.ibm.wsspi.sip.converge. ConvergedServlet, предоставляемый WebSphere.

Если для создания нового Siplet или сервлета используется панель инструментов, то новый класс гарантированно расширяет соответствующий суперкласс из базовой модели SIP (см. рисунок 7). Если панель инструментов не используется, к классу можно применять стереотип, что позволяет расширить другой класс или интерфейс среды.

Реализация этого сервиса, как описано при помощи набора диаграмм потоков вызовов, начинается с модели проекта с единственным стандартным классом, расширяющим правильный класс среды. Методы этого класса принимают запросы SIP-клиентов и отвечают за обмен данными с прокси для установления сессии с одним или несколькими другими устройствами.

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

Основной мотив для использования стереотипов – это идентификация отдельных классов в качестве основных реализаций для поведения SIP-сервиса. Для "регистрации" этих классов на Web-сервере приложений требуется дополнительная метаинформация. Эта информация связывается со стереотипом и представляется разработчику в форме специальной панели (см. рисунок 9). Панель доступна в виде новой вкладки в стандартном разделе панели Properties

В случае Siplet данная информация включает шаблон или критерий фильтра, определяющий условия активации этого Siplet контейнером. Шаблон представляет собой простую древовидную структуру, выполняющую преобразование в XML-фрагмент и используемую непосредственно в дескрипторе развертывания (в соответствии с JSR116).

Остальная часть представления дает удобный способ добавления переопределений методов для большинства методов 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).

Единственными параметрами для этого преобразования являются Web-проект и модель назначения. Применение этого преобразования приводит к обновлению модели, создающей классы SIP-сервлетов, HTTP-сервлетов или объединенных сервлетов и обновляющей SIP-свойства из дескрипторов развертывания. Данное преобразование только обновляет содержимое дескрипторов развертывания. Обновление атрибутов, операций или ассоциаций классов не выполняется. Наряду с остальным содержимым Java эти операции можно выполнить при помощи преобразования Java-UML, имеющегося в Rational Software Architect.

В начало

Обзор этапов проектирования

Процесс проектирования начинается с ввода данных, полученных от аналитиков, обычно в форме диаграмм потоков вызовов, которые можно зарегистрировать в виде циклограмм. Некоторые проектировщики объединяют эти диаграммы в UML-машину состояний или UML-операцию для создания нового поведения для всех сценариев. Машина состояний или операция представляет отдельный компонент поведения, который, будучи реализованным в виде SIP-сервиса, поддерживает все потоки вызовов. Это также хороший механизм анализа для определения неопределенностей и конфликтов в ожидаемых сценариях.

Проектирование сервиса начинается с создания в UML-модели стандартного класса «Siplet». Этот класс непосредственно сопоставляется основному классу реализации SipServlet. Проектировщик задает доменную SIP информацию в пользовательских панелях Properties, затем добавляет к проекту дополнительные классы, подключения к Web-сервисам, базам данных, корпоративным компонентам и т.д. Как указано ранее, большая часть работы по проектированию и реализации SIP-сервиса в фактической среде приходится на создание бизнес-логики взаимодействия с другими классами и технологиями.

Ресурсы

• Оригинал статьи: Introduction to the SIP Modeling Toolkit for IBM Rational Software Architect (EN);
  
  
• SIP Modeling Toolkit for Rational Software Architect (EN) (сайт developerWorks, июль 2007 г.) добавляет расширения протокола установления сессии (SIP) к базовой платформе моделирования и разработки, предоставляемой IBM Rational Software Architect;
  
  
• В статье The Value of Modeling (EN) (Ценность моделирования) (сайт developerWorks, октябрь 2004 г.) обсуждаются преимущества моделирования в контексте разработки программного обеспечения;
  
  
• Статья SIP: Creating next-generation telecom applications (EN) (SIP: создание телекоммуникационных приложений следующего поколения) (сайт developerWorks, сентябрь 2003 г.) содержит примеры практических приложений;
  
  
• В статье Using Session Initiation Protocol with IBM Lotus Sametime (EN) (Использование протокола установления сессии с IBM Lotus Sametime) (сайт developerWorks, май 2006 г.) показано, как IBM Lotus Sametime использует SIP для передачи мгновенных сообщений и осведомленности о присутствии между двумя сообществами Lotus;
  
  
• "Session Initiation Protocol in WebSphere Application Server" (EN) (Протокол установления сессии в WebSphere Application Server) (сайт developerWorks, июнь 2006 г.) описаны функции SIP в IBM WebSphere Application Server Versions 6.1 и более высокой версии.
  
  
• В статье Develop Contact Center telecom applications (EN) (Разработка телекоммуникационных приложений контактных центров) (сайт developerWorks, август 2004 г.) показано, как при помощи SIP-сервлетов создавать базовые телекоммуникационные приложения;
  
  
• Посетите раздел сайта developerWorks, связанный с Rational, где вы найдете дополнительные технические ресурсы и лучшие методы работы с продуктами платформы Rational Software Delivery. В частности просмотрите раздел Rational Software Architect;
  
  
• Подпишитесь на информационный бюллетень раздела Rational сайта developerWorks(EN). Следите за разделом Rational сайта developerWorks. Еженедельно вы будет получать информацию о последних технических ресурсах и лучших методах работы с Rational Software Delivery Platform; (EN)
  
  

• Более подробная информация о IBM Rational Unified Service Creation Environment;(EN)
  
  
• Изучите IBM Rational Software Architect V7.0 в интерактивном режиме, пройдя трехчасовой "тест-драйв" без установки или настройки пакета в собственной системе. Этот улучшенный инструмент разработки на основе моделей и статического анализа идеально подходит для разработчиков и проектировщиков программного обеспечения, занимающихся созданием приложений для сервис-ориентированной архитектуры (SOA), Java™ Platform, Enterprise Edition (J2EE) и портальных приложений;(EN)
  
  
• Приобретайте IBM Rational Software Architect;(EN)
  
  
• Загрузите оценочные версии программных продуктов IBM и овладейте инструментами разработки приложений и связующим ПО для DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)

• Примите участие в обсуждении материала на форуме.
  
  
• Форум Rational Software Architect, Data Architect, Software Modeler, Application Developer и Web Developer: Задайте вопросы о Rational Software Architect;(EN)
  
  
• Посетите блоги developerWorks и присоединяйтесь к сообществу developerWorks; (EN)
  
  

Об авторе

		Джим Коналлен (Jim Conallen) работает инженером по программному обеспечению в группе стратегии разработки на основе моделей IBM Software Group, где активно использует архитектуру на основе моделей (MDA) от Object Management Group (OMG) в разработке средств моделирования IBM Rational. Джим часто выступает на конференциях и является автором множества статей. Он специализируется в разработке Web-приложений, в частности, Web Application Extension (WAE) для UML, расширения UML, позволяющего разработчикам моделировать Web-центричные архитектуры с использованием UML и соответствующими уровнями абстрагирования и детализации. Эта работа служит базой для функций Web-моделирования пакетов IBM Rational Rose и IBM Rational XDE.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало