Ericsson NRG SDK
Дмитрий Намиот
АбаваНет
В данной статье описывается Ericsson NGR (Network Resource Gateway) SDK. Как известно, архитектура OSA описывает разделение систем на несколько уровней (точнее – на 3 уровня). Так это иллюстрируется в руководстве программиста по NRG:
Самый верхний уровень – сервисный. Это есть то место, где располагается NRG. Элементы телекоммуникационной сети располагаются на уровне управления и соединения. Уровень управления поддерживает (реализует) сигнальную систему, уровень соединения отвечает за трафик. Таким образом NRG скрывает от программиста элементы конкретной реализации телекоммуникационной сети и выдает наружу четко специфицированные интерфейсы (API – программные вызовы) – Parlay/OSA.
Иными словами NRG создает (поддерживает связь) между приложениями и собственно телекоммуникационной сетью. Собственно идея и архитектура Parlay были описаны в статьях, подготовленных АбаваНет неоднократно, поэтому ограничимся здесь кратким резюме.
Parlay/OSA есть открытые интерфейсы для телекоммуникационных сетей. Этот набор интерфейсов вносит дополнительный уровень абстракции для прикладных приложений (сервисов), который упрощает программирование и позволяет писать переносимые программы, не зависящие от аппаратуры и конкретных протоколов. Эта спецификация разрабатывается группой Parlay (http://www.parlay.org) Эта группа есть совместное предприятие комитетов 3GPP и ETSI и представляет собой некоммерческую организацию, поддерживаемую основными производителями телекоммуникационного оборудования, IT компаниями и операторами.
Для NRG (это, напомним, продукт Эрикссон – одного из основных игроков на рынке Parlay) доступно также расширение Parlay/API, которое называется HOSA (High Level Open Service Access). Следуя терминологии производителя (Эрикссон) это pre-standard (то есть еще не стандартизованное) расширение спецификаций Parlay API, которое добавляет новые сервисы и функциональность. Документация на NRG SDK перечисляет следующие дополнительные возможности:
Передача сообщений с использованием сервиса Messaging
Работа с email – Message Retrieval сервис
Сервис User Status – опрос состояния мобильных телефонов
User Location сервис – услуги позиционирования
PIM Contact сервис – поддержки списков контактов
PIM Calendar сервис – соответствует названию и поддерживает календари
Расширения Multi Party Call Control из Parlay API
User Interaction сервис – проигрывание анонсов и обработка DTMF
С практической точки зрения это расширение есть набор дополнительных пакетов (в терминах языка программирования Java). В целом, следуя устоявшейся терминологии, Ericsson Network Resource Gateway (NRG) есть SCS (Service Capability Server), который имеет встроенную модель управления доступом к услугам (имеется в виду обеспечение безопасности). Поддерживает широкий набор протоколов, что иллюстрируется следующим рисунком из документации Эрикссон:
С точки зрения протоколов сети (то есть то, с помощью чего реализуется соответствие вызовов Parlay и возможностей сети) упоминаются CS1+ (расширение Capability Set 1) и CAPv2 (CAMEL Application Part версия 2).
Практически NRG Software Development Kit (то есть NRG SDK) есть набор Java пакетов для программирования сервисов (услуг) на NRG. Одно из основных назначений SDK (как и в пакетах Appium или IBM WebSphere Telecom Server) – это абстрагирование CORBA вызовов (то есть работа с CORBA будет реально скрыта внутри SDK). Плюс HOSA предлагает дополнительный набор сервисных библиотек (также, как например и Appium Framework)
Разработчик приложений может непосредственно использовать CORBA для программирования NRG (обращаясь как к Parlay API, так и к HOSA) или использовать SDK (как дополнительный уровень абстракции). Преимущества и недостатки каждого из подходов очевидны. Прямое использование CORBA обеспечивает максимальную гибкость и переносимость, но более сложно. Использование SDK позволяет сильно упростить разработку приложений. Дополнительно SDK уже содержит ряд полезных возможностей. Например, средства кластеризации, когда у оператора работают 2 NRG узла параллельно.
NRG всегда имеет некоторую точку доступа к сервисам (Framework в терминах Эрикссон) и, собственно, набор сервисов. Здесь имеются в виду сервисы NRG (то есть Messaging, Location, User Status и т.д.), а не прикладные сервисы (услуги). Для использования какой-либо функциональности NRG приложение всегда сначала запрашивает Framework. Код для этого всегда будет выглядеть одинаково, но важно подчеркнуть, что такая функциональность обязательна. Далее эта точка доступа (Framework) будет использоваться как proxy для нашего приложения. Приложение (услуга, которую мы программируем) запрашивает ресурсы для доступа в начале исполнения и, соответственно, освобождает их после завершения. Точка доступа запрашивается каждым приложением. Жизненный цикл приложения (сервиса, услуги) определяется в NRG следующим образом:
1. Запросить доступ к Framework
2. Запросить сервис от NRG
3. Выполнять собственные транзакции (осуществлять звонки, передавать сообщения и т.д.)
4. Освободить сервис
5. Завершить работу с точкой доступа
В терминах IN точка доступа выступает как gatekeeper. Соответственно, транзакции (то есть работа с сервисом NRG) выполняются пока соответствующее соглашение об оказании услуг (SLA – Service Level Agreement) является действительным или не будет явно прекращено (приложением или оператором).
SLA есть соглашение с оператором, которое позволяет прикладному приложению (сервису, услуге) пользоваться сервисами NRG.В этом соглашении как раз и описывается, какими конкретно сервисами NRG разрешено пользоваться данному приложению (может ли оно осуществлять звонки, передавать сообщения и т.д.) SLA содержит также данные, необходимые для авторизации и аутентификации. Это и иллюстрируется на следующем рисунке:
Во-первых, происходит взаимная аутентификация приложения и точки доступа. Когда Framework и приложение подтвердили собственную идентичность, приложение может запросить у точки доступа услуги некоторого из сервисов NRG. Естественно, что приложению может быть разрешено использовать только часть сервисов, существующих (зарегистрированных) в NRG. За это как раз и отвечает SLA. Получив запрос на использование сервиса, точка доступа создает менеджера этого сервиса и возвращает соответствующую ссылку приложению. С помощью этой ссылки приложение и будет дальше работать с конкретным сервисом. SLA определяется (существует) для каждого приложения. NRG определяет два типа возможных соглашений: базирующихся на функциональности или на производительности. Ограничения SLA проверяются в реальном времени. Функциональные ограничения являются базовым типом и, в соответствии с названием, описывают какие функции NRG будут доступны конкретному приложению. Например:
Типы разрешенных триггеров
Разрешенные к использованию методы API
Разрешенные методы биллинга
Допустимые для поддержки типы сообщений
Ограничения производительности определяют, какую часть мощностей NRG можно использовать данному приложению. Например:
Максимальное число транзакций в секунду
Максимальное число исходящих звонков
Максимальное число сообщений (SMS, MMS) в секунду
С практической точки зрения, все сказанное об SLA означает, что доступ конфигурируется
внешним по отношению к приложению способом. Иными словами, оператор конфигурирует NRG и
описывает там условия работы для конкретных приложений.
С точки зрения программирования, соединение с точкой доступа есть последовательность
операций (вызовов), которые должны быть выполнены прикладной программой. Эта последовательность
может быть довольно длинной. Например, с точки зрения Parlay это 13 вызовов для получения
первого сервиса и 5 для каждого дополнительного. Собственно говоря, уровень абстрагирования
в SDK, о котором говорилось выше и направлен как раз на упрощение подобного рода процедур.
Например, запрос сервиса User Status выполняется одним вызовом:
ItsHosaUSManager = (IpHosaUserStatus) itsFramework.obtainSCF("SP_HOSA_USER_STATUS");
Рассмотрение возможностей конкретных сервисов NRG может быть предметом отдельных статей.
Здесь же мы приведем прокомментированный пример конкретного приложения, чтобы дать представление о
том, как выглядит программирование для NRG. Настоящий пример представляет собой простой SMS
обработчик – отслеживаются все сообщения, поступающие на указанный номер и переправляются,
например, на некоторый email адрес.
Класс Feature описывает соединение с NRG и создает обработчик SMS, указывая какой номер должен
отслеживаться. Обработчик будет вызывать метод smsReceived() из этого класса при получении интересующего нас SMS.
public class Feature
{
//объекты для связи с NRG
private FWproxy itsFramework;
private IpHosaUIManager itsHosaUIManager;
// обработчики
private SMSProcessor itsSMSProcessor;
public void start()
{
// трассировка HOSA
HOSAMonitor.addListener(SimpleTracer.SINGLETON);
// создание точки соединения
itsFramework = new FWproxy(Configuration.INSTANCE);
// запрос сервиса User Interaction
itsHosaUIManager = (IpHosaUIManager)itsFramework.obtainSCF("SP_HOSA_USER_INTERACTION");
/**
* Создание обработчиков. Это пользовательские классы,
* которые будут проиллюстрированы ниже
*/
itsSMSProcessor = new SMSProcessor(itsHosaUIManager, this);
// задание номера для отслеживания
itsSMSProcessor.startNotifications("123456");
}
/**
* Stops interaction with the NRG and disposes of all resources
* allocated by this instance.
* Note: this method is intended to be called at most once.
*/
public void stop()
{
if (itsSMSProcessor != null)
{
itsSMSProcessor.dispose();
}
// закрытие сервиса
if (itsHosaUIManager != null)
{
itsFramework.releaseSCF(itsHosaUIManager);
}
// закрытие точки доступа
if (itsFramework != null)
{
itsFramework.endAccess();
itsFramework.dispose();
}
// отмена трассировки
HOSAMonitor.removeListener(SimpleTracer.SINGLETON);
}
/**
* Этот метод будет вызываться из SMS обработчика при получении
* сообщения
*
* @param aSender отправитель сообщения
* @param aReceiver получатель сообщения
* @param aMessageContent текст SMS
*/
protected void smsReceived(String aSender, String aReceiver, String aMessageContent)
{
/**
* здесь мы можем переслать полученное сообщение на
* некоторый адрес. Например, с помощью JavaMail
*/
. . .
}
}
Теперь собственно обработчик. Для простоты показаны только основные методы.
public class SMSProcessor
{
/**
* в этом методе определяется получение уведомлений
* от NRG при приходе SMS на определенный адрес
*/
public int startNotifications(String aDestinationAddress)
{
IpAppHosaUIManager appHosaUIManager = this;
TpAddressRange originatingAddress = null;
TpAddressRange destinationAddress = createE164Range(aDestinationAddress);
String serviceCode = null;
TpUIEventCriteria criteria = new TpUIEventCriteria(originatingAddress,
destinationAddress, serviceCode);
int assignmentId = itsHosaUIManager.createNotification(appHosaUIManager,
criteria);
return assignmentId;
}
Далее, при получении SMS будет вызываться метод этого класса, который называется reportEventNotification()
public IpAppUI reportEventNotification(TpUIIdentifier anUserInteraction,
TpUIEventNotificationInfo anEventInfo,
int anAssignmentID)
{
String sender = anEventInfo.OriginatingAddress.AddrString;
String receiver = anEventInfo.DestinationAddress.AddrString;
String messageContent = new String(anEventInfo.UIEventData);
// вызывается метод родительского класса для
// дальнейшей пересылки SMS по Email
itsParent.smsReceived(sender, receiver, messageContent);
return null;
}
}
В заключении заметим, что сам SDK, а также эмулятор NRG доступен для бесплатной загрузки в рамках программы Ericsson MobilityWorld. Реально, все что необходимо для разработки и тестирования новых услуг может быть запущено в рамках одного персонального компьютера.
Литература:
1. 3GPP Technical Specification Group Core Network: Open Service Access; Application Programming Interface: Overview, 3GPP TS 29.198-1 (version 4.3.1)
2. Parlay API http://www.parlay.org
3. Ericsson NRG SDK Programmers Guide
Интересно узнать больше? Пишите: info@abavanet.ru
Для контактов: info@abavanet.ru
© AbavaNet 2004 all rights reserved