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

Каждая из сетей общего пользования обычно предоставляет абонентам дополнительные услуги. Разработку подобных услуг существенно осложняет то обстоятельство, что каждая из существующих сетей имеет свои собственные протоколы: телефонная сеть общего пользования (SSP, точка коммутации служб) использует протокол INAP, мобильные сети используют протокол САР, по нему же работает центр коммутации MSC (Mobile Switching Center) и узел услуг SGSN (Serving GPRS Support Node) в сетях GPRS, мобильные сети третьего поколения строятся с использованием узла S-CSCF (Serving Call Session Control Function), который работает по протоколу SIP (рис. 1). Каждый из протоколов разработчику необходимо изучить.

Рис. 1. Общая схема функционирования Parlay/OSA

Архитектура Parlay

Программная модель

Parlay API — открытый универсальный программный интерфейс, скрывающий от программистов детали телефонной аппаратуры. Домен приложения не содержит никакой «телефонной» специфики, а соединение обеспечивается посредством TCP/IP.

Телефонный домен включает в себя компонент Service Capability Server (SCS), который и предоставляет Parlay API. (Иногда с легкой руки Ericsson тот же самый компонент называют Network Resource Gateway — т.е. «шлюз доступа к ресурсам».) Этот шлюз, или сервер доступа к сервисам, обеспечивает соответствие между стандартными вызовами Parlay, видимыми для разрабатываемого приложения, и конкретными протоколами (например, телефонной сети общего пользования, сети с поддержкой передачи голоса по IP и т.д.).

Приложение выполняется на компьютере разработчика, а функциональность, которая при этом запрашивается, реально находится в «телефонной» сети, на Parlay-шлюзе. Приложение осуществляет соответствующий удаленный вызов (remote procedure call, RPC), поэтому создание Parlay-приложения сводится к программированию в архитектуре CORBA и, естественно, может быть выполнено с использованием любого языка программирования, поддерживающего протоколы CORBA.

На следующем шаге CORBA-вызовы обрамляются некоторым программным интерфейсом более высокого уровня — Application Framework, что никак не изменяет сам Parlay API, но добавляет (или, точнее, надстраивает над Parlay-шлюзом) библиотеку, призванную упростить использование Parlay. Вместе с появлением Application Framework появилась и среда приложений, в которой выполняются, например, такие стандартные функции, как поддержка сеансов, авторизация и т.п. Таким образом, в реальных системах схема архитектуры Parlay принимает вид, представленный на рис. 2.

Рис. 2. Роль сервера приложений в архитектуре Parlay

Именно сервер приложений берет на себя взаимодействие с «телефонной» частью системы. Вследствие исключительной переносимости наиболее предпочтительным оказывается язык программирования Java, а потому в качестве серверов приложений используются J2EE-серверы.

Таким образом, задача программирования с использованием Parlay API сводится к программированию для конкретного сервера приложений. Необходимо лишь помнить, что если Parlay API является стандартным, то библиотеки Application Framework, которые производители надстраивают над стандартом, как правило, являются особенностью конкретного сервера.

Parlay-шлюз

Основными частями Parlay-шлюза являются ядро и сервисные компоненты (точнее, услуги шлюза). На рис. 3 показано девять компонентов — своего рода «строительных» блоков, которые определяют функциональные возможности приложений. Каждый прямоугольник в разделе «Сервисные компоненты» представляет собой один из разделов Parlay API — набор программных вызовов, сгруппированных по назначению: управление вызовом (переадресация), управление оконечными устройствами, управление сеансами и т.д. В частности, с помощью Generic Messaging API программируется работа с SMS-сообщениями, а Charging API адресован вопросам биллинга.

В последних спецификациях Parlay добавлены еще два сервисных компонента: Policy Management и Presence and Availability Management.

Лучше понять общие принципы, лежащие в основе Parlay, можно, ознакомившись со спецификациями Open Service Access (OSA) API, которые изложены в документах 3GPP, состоящих из двух групп:

  • определение интерфейсов, параметров и моделей состояний API; для описания классов интерфейсов используется язык UML, а сами интерфейсы описаны на языке IDL;
  • установка соответствия между API и различными сетевыми протоколами (MAP, CAP, INAP, SIР и др.).

Задача OSA API — спрятать от разработчика приложений особенности нижележащих сетей и протоколов, упростив тем самым программирование и обеспечив переносимость создаваемых программ. Так как спецификации должны учитывать множество сетевых протоколов, то неизбежно эти документы весьма громоздки, зато разработка приложений упрощается и, главное, они не меняются при изменениях на сетях.

Работа Parlay-ядра

Открытые интерфейсы Parlay являются объектно-ориентированными. Ключевую роль в концепции Parlay играет ядро. Поясним работу ядра на примере введения (или регистрации) новой услуги.

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

Процесс регистрации услуги и ее обнаружение приложением состоит из трех фаз.

  1. Регистрация. Включает три шага — запрос на аутентификацию услуги, запрос на регистрацию услуги, сообщение ссылки на услугу.
  2. Установление соглашения об обслуживании. Например, можно оговорить, что максимальное число участников группового вызова не должно превышать четырех.
  3. Установка соединения между приложением и услугой. Оно начинается с аутентификации приложения. Затем следуют запрос на доступ к услуге, обнаружение услуги, выбор услуги и фиксация соглашения об уровне обслуживания. Далее создается менеджер услуги, который будет контролировать использование услуги данным приложением, и начинается использование услуги.

Телефонный сервер Appium

Как начать разработку Parlay-приложений? Шлюзы и средства разработки имеются у компаний Ericsson (NRG SDK), Siemens, IBM (WebSphere Telecom Server). В продуктах HP используется инструментарий Incomit.

Остановимся подробнее на продуктах шведской компании Appium, известной лаборатории тестирования Parlay-шлюзов. Пожалуй, инструментарий Appium наиболее полно отвечает основной задаче Parlay — упрощению процесса разработки. Инструментарий Appium прост в использовании, удачно интегрирован с популярной интегрированной средой разработки Borland JBuilder, а также содержит обширный набор примеров, которые могут быть использованы как прототипы для собственных разработок. Среда тестирования включает телефонный сервер Appium TAS, программу имитации Parlay-шлюза Appium Lab Parlay GW, набор тестовых приложений, а также модель интеллектуальной сети Network Simulator и модель сети IP-телефонии VoIP Parlay Lab.

Appium Framework включает компоненты, соответствующие Parlay API, — управление вызовами, сообщениями, биллинг и т.д. Appium TAS представляет собой собственно сервер приложений, который исполняет пользовательские программы. Остальные компоненты (тестовая версия Parlay-шлюза, эмулятор сети, эмуляторы VoIP-клиентов и др.) относятся к среде разработки. Создатели Appium постарались собрать на одной рабочей станции все, что необходимо для разработки и тестирования приложений.

Интеграция с JBuilder на практике означает, что разработчику в среде JBuilder будет доступен модуль расширения, через который осуществляются как все операции с сервером приложений (настройка, запуск и т.п.), так и поддержка шаблонов для создания приложений. Иными словами, наряду со стандартными шаблонами, которые поддерживаются JBuilder (компоненты EJB, JSP-файлы и т.д.), появляется новый объект — телефонное приложение.

Базовая архитектура такого приложения включает минимум два компонента. Первый описывает собственно приложение и его контракты с контейнером (сервером приложений), определяя, как сервер регистрирует данное приложение и как он будет им управлять. Второй компонент отвечает за обработку активности (в простейшем случае, реализуя реакцию на звонки); Parlay API включается именно здесь. Собственно обработкой звонков в Application Framework от компании Appium занимается объект CallHandler. Разрабатываемое приложение как раз и определяет конкретную реализацию данного объекта. Технически базовый класс CallHandler, который наследуют все прикладные приложения, занимается контактами с CORBA-сервером, поиском сервисов и регистрацией обратных вызовов для получения уведомлений от сервера. Это и есть типичный пример ядра, который, скрывая технические детали, предоставляет простой интерфейс (в данном случае, JavaBean). Итак, главная задача приложения — создать и зарегистрировать конкретную реализацию CallHandler.

Учите Parlay

Спецификации Parlay создавались для экономии труда программистов за счет упрощения, основанного на стандартах, продвигаемых консорциумом международных организаций, включая ETSI и 3GPP, за которыми стоят основные производители средств связи. Следовательно, инвестиции в изучение спецификаций Parlay, а также написанный на их основе код, могут быть повторно использованы. Согласно статистике Parlay Group, на конец января 2003 года было зарегистрировано 113 различных программных продуктов на основе Parlay, в том числе, 22 шлюза, 40 коммерчески эксплуатируемых услуг и 15 серверов приложений. Среди основных разработчиков такие компании, как Alcatel, Ericsson, Fujitsu, Huawei, Lucent, Marconi, Nortel, NTT, Siemens и Telenity. Почти все производители из этого списка имеют программы поддержки независимых разработчиков; примерами могут служить инициативы Appium Alliance Program или Ericsson Mobility World. Уже оснастили свои сети Parlay-шлюзами такие известные операторы, как Telecom Italia, Telenor Mobile Communications, British Telecom, Vodafone и Orange.

Дмитрий Намиот (dnamiot@inetique.ru) — технический директор, Манфред Шнепс-Шнеппе (sneps@mail.ru) — генеральный директор компании «Абаванет» (Москва).

Разработка архитектуры Parlay началась в 1998 году по инициативе компаний British Telecom, Microsoft, Nortel Networks, Siemens и Ulticom; позже к ним присоединились Cisco Systems, Ericsson, IBM, Lucent Technologies, и сейчас число участников Parlay Group превышает 60. C 2001 года стандарты на открытые интерфейсы Parlay API получили международное признание и в настоящее время разрабатываются совместными усилиями трех организаций: Parlay Group, Европейским институтом стандартизации телекоммуникаций ETSI и Консорциумом мобильных сетей третьего поколения 3GPP. Это позволяет утверждать, что архитектура Parlay становится основой построения сетей нового поколения NGN. Следуя документам ETSI и 3GPP, любой коллектив программистов уже сегодня может включиться в разработку телефонных приложений будущих сетей пакетной коммутации, особенно для мобильных операторов.

Интересным развитием данной спецификации является сервер Parlay X, абстрагирующий для программиста телефонный домен. Данный сервер будет содержать реестр UDDI с описаниями функций Parlay API. Обращение к этим функциям будет осуществляться на основе модели Web-служб по протоколу SOAP.

Виртуальный номер

На сайте www.abavanet.ru приведен текст программы, реализующей реальный пример, иллюстрирующий особенности реализации популярной услуги «виртуальный номер» (звонок на виртуальный номер переадресуется на один из реальных номеров из некоторого списка). Смысл этой услуги состоит в том, что пользователь делает видимым (публикует) для своих партнеров (клиентов) только один реальный номер. В действительности же, входящие звонки будут переадресовываться на другие номера — возможно, меняющиеся. Подобную услугу предусматривает, например, продукт Logic Line компании «МТУ-Информ». Обратим внимание на строку в коде, содержащую список обзваниваемых номеров (используются четырехзначные номера программного эмулятора):

/** список номеров, используемых при прозвоне */

private String[] addresses = {«1101», «1102», «1103»};

В модельном примере перебираются номера из некоторого фиксированного списка. Собственно, все, что нужно для трансформации этого примера в реальную услугу, — это добавить выбор списка перебираемых номеров из базы данных. Это можно сделать простым программированием с использованием JDBC, что в любом случае никак не связано с особенностями телефонной сети. А объем программного кода составляет всего 200 строк.

Другой пример — позиционирование. Недавно компания «Мегафон» запустила услугу, позволяющую определять местоположение абонента. На сайте www.abavanet.ru можно посмотреть, как выглядит реализация подобного приложения с использованием Parlay. Пользователь посылает SMS-сообщение на некоторый выделенный номер и получает либо собственные координаты, либо координаты абонента с указанным номером. Данный код написан с использованием NRG SDK от Ericsson.