Платформа предоставления услуг - Service delivery platform

А платформа предоставления услуг (SDP) - это набор компонентов, который обеспечивает архитектуру доставки услуг (например, создание услуг, управление сеансами и протоколы) для типа услуги, предоставляемой потребителю, будь то клиент или другая система. Хотя он обычно используется в контексте телекоммуникации, он может применяться к любой системе, которая предоставляет услугу (например, телефон VOIP, телевидение по Интернет-протоколу, Интернет-сервис или SaaS ). Хотя TM Forum (TMF) работает над определением спецификаций в этой области, в отрасли нет стандартного определения SDP, и разные игроки определяют его компоненты, широту и глубину немного по-разному.

SDP часто требуют интеграции ИТ-возможностей и создания сервисов, пересекающих границы технологий и сетей. Доступные сегодня SDP обычно оптимизированы для предоставления услуги в определенной технологической или сетевой области (например, в телекоммуникациях это включает: Интернет, IMS, IPTV, Мобильное ТВ и др.). Обычно они предоставляют среды для управления службами, создания, оркестрации и выполнения. Опять же, в телекоммуникациях это может включать абстракции для управления медиа, присутствия / местоположения, интеграции и других низкоуровневых коммуникационных возможностей. SDP применимы как к потребительским, так и к бизнес-приложениям.

Только в контексте телекоммуникаций бизнес-цель внедрения SDP - обеспечить быстрое развитие и развертывание новых конвергентных мультимедийных услуг, начиная с базовых. Горшки телефонные услуги для комплексной аудио / видеоконференцсвязи для многопользовательские видеоигры (MPG). В контексте SaaS аналогичные бизнес-цели достигаются, но в контексте, специфичном для конкретной бизнес-области.

Появление Магазины приложений, для создания, размещения и доставки приложений для таких устройств, как Apple iPhone и Google Android смартфонов, сосредоточился на SDP как на средстве для поставщиков коммуникационных услуг (CSP), чтобы получать доход от данных.^[1] Используя SDP для предоставления своих сетевых ресурсов как внутреннему, так и внешнему сообществу разработчиков, включая разработчиков Web 2.0, CSP могут управлять жизненными циклами тысяч приложений и их разработчиков.^[2]^[3]

Телекоммуникационные компании, в том числе Telcordia Technologies, Nokia Siemens Networks, Nortel, Avaya, Ericsson и Alcatel-Lucent предоставляли интерфейсы и инфраструктуру для интеграции коммуникаций с начала до середины 1990-х годов. Экономичный успех IP-технологий VoIP системы в качестве замены проприетарных частная телефонная станция (АТС) Системы и настольные телефоны вызвали смещение внимания отрасли с проприетарных систем на открытые стандартные технологии.

Это изменение в открытой среде привлекло такие телекоммуникационные компании, которые специализируются на программном обеспечении. Teligent Telecom^[4] и разрешенные системные интеграторы, такие как Привязать к, Accenture, IBM, TCS, HP, Alcatel-Lucent, Tech Mahindra, Infosys, Wipro, и CGI предлагать интеграционные услуги. Кроме того, новые консорциумы компаний, производящих программные продукты для телекоммуникаций, предлагают предварительно интегрированные программные продукты для создания SDP на основе таких элементов, как услуги с добавленной стоимостью, конвергентный биллинг и управление отношениями между контентом и партнерами.

Поскольку SDP могут пересекать технологические границы, становится возможным широкий спектр смешанных приложений, например:

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

История

Конец 1990-х стал периодом беспрецедентных изменений в корпоративные приложения как хватка клиент-серверные архитектуры постепенно расслабился и позволил появиться многоуровневым архитектурам. Это означало появление сервер приложений, гибкий компромисс между абсолютом тупой терминал и клиентский ПК с тяжелой логикой. Хотя участников в кольце серверов приложений было много и они разнообразны, у них были общие преимущества: абстракция от поставщика базы данных, открытый стандарт (в основном объектно-ориентированный ) модели программирования, характеристики высокой доступности и масштабируемости, а также среды представления, среди прочего. Эти преобразования были инициированы бизнес-силами, в том числе неистовой приливной волной, которая была Интернет-бум, но ничего из этого не было бы возможно без распространения стандартов, таких как TCP / IP протокол, Ява язык программирования, а Java EE архитектура сервера веб-приложений. Именно на этом фоне трансформации началась эра быстрых изменений в телекоммуникациях.

Вплоть до первых нескольких лет 2000 года рынки коммерческих и деловых телекоммуникационных технологий все еще были насыщены проприетарным оборудованием и программным обеспечением. Открытые стандарты начали становиться популярными с появлением IP-технологий и быстрым распространением Передача голоса по IP (VoIP) для передачи голосовых данных по пакетным сетям и Протокол инициирования сеанса (SIP) для стандартизированного управления мультимедиа, особенно в отношении корпоративной голосовой связи.

В этой новой среде, поддерживаемой стандартами, конвергенция мира голоса и данных стала не столько прозвищем для катастрофических попыток интеграции телекоммуникаций и ИТ, сколько реальным средством создания новых и более качественных потребительских и бизнес-услуг. За последние несколько лет были введены или распространены различные библиотеки программирования SIP (reSIProcate, Aricent, MjSip и его производный порт от HSC) и продукты, основанные на относительно новом стандарте SIP, а также Подсистема IP-мультимедиа стандарт, определенный 3GPP приобрел огромное количество поклонников. Платформа предоставления услуг, сила которой во многом зависит от качества и принятия этих поддерживающих стандартов, быстро получает признание в качестве широко применяемого архитектурного шаблона.

Сегодня в промышленности используются несколько определений платформы доставки услуг (SDP) без единого мнения относительно общего значения. Из-за этого, а также из-за необходимости для поставщиков услуг понимать, как лучше управлять SDP, TM Forum (TMF) приступила к стандартизации концепции структуры предоставления услуг (SDF) и управления SDF. Определение SDF предоставляет терминологию и концепции, необходимые для ссылки на различные задействованные компоненты, такие как приложения и средства реализации, доступность сети и услуг и оркестровка.

Что необходимо для доставки сочетания персонализированных услуг от нескольких SDP до конечных пользователей, так это средство взаимодействия этих SDP через общие средства поддержки услуг и сетевые ресурсы. Однако закрепление этих аспектов услуг было фундаментальной концепцией, заключающейся в том, что атрибуты пользователя и услуги для них требуется общий репозиторий и общая модель данных, например, предоставляемые каталогом LDAP / X.500 или базой данных HSS. Ранние реализации SDP такого рода начались в середине / конце 1990-х годов для конвергентных услуг ISP. Более крупные и сложные SDP были реализованы за последние 5 лет в средах типа MSO и для мобильных операторов.

Контекст

SDP обычно рассматриваются в средах телекоммуникационного типа как базовая система, которая связывает клиентский доступ и сетевую инфраструктуру с системами OSS и BSS. SDP в этом контексте обычно связаны с определенным режимом обслуживания, таким как мобильные телефоны или конвергентные услуги.

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

SDP также следует рассматривать не только как основную функцию оператора, но и как ряд взаимосвязанных распределенных сервисных узлов (например) по причинам избыточности и для различных профилей услуг для разных секторов бизнеса и рынка. Многие операторы предоставляют правительственным и корпоративным клиентам продукты коммерческого масштаба / уровня, такие как пакетная голосовая связь, веб-хостинг, VPN, почта, конференц-связь и средства обмена сообщениями. Эволюция таких комплексных услуг может происходить от фрагментированных систем управления до «виртуальной частной среды услуг», где оператор запускает выделенный SDP для каждого из своих клиентов, которым требуются их услуги по запросу и под их контролем.

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

Элементы

Среда создания сервиса

Часто основная точка доступа разработчика телекоммуникационного программного обеспечения, среда создания услуг (SCE, также среда создания приложений или интегрированная среда развития ) используется разработчиком для создания программного обеспечения, сценариев и ресурсов, представляющих предоставляемые услуги. По сложности они могут варьироваться от базовых подключаемых модулей Eclipse до полностью абстрагированных приложений моделирования телекоммуникационных приложений на основе метаданных (таких как продукт CRM Central от Avaya).

Цель SCE - способствовать быстрому созданию новых услуг связи. Если сейчас игнорировать такие факторы, как маркетинг, то чем проще разработчикам создавать сервисы для данной платформы, тем больше будет количество доступных сервисов и, следовательно, признание платформы более широким телекоммуникационным рынком. Таким образом, поставщик телекоммуникационной инфраструктуры может получить значительное преимущество с помощью SDP, который обеспечивает быстрое создание услуг.

Использование конвергентных сред создания сервисов Java EE и SIP ускорило внедрение платформ доставки сервисов. Разработчики приложений на основе Java, традиционно ориентированные на ИТ-приложения, разрабатывают приложения для связи в реальном времени с использованием Java EE и протоколов сетевого подключения, таких как SIP и Parlay X веб-сервисы. Поставщики программного обеспечения объединяют эти технологии (например, Oracle Jdeveloper и Oracle Communication and Mobility Server с базовым подключаемым модулем Eclipse), чтобы охватить более широкую базу разработчиков.

Среда исполнения

Среды выполнения служб (SEE) используются для выполнения служб связи, разработанных в SCE. Среды выполнения обычно предназначены для имитации оборудования, на котором, как ожидается, будет работать конкретная служба. SEE может быть связан с SCE как IDE

Управление СМИ

Присутствие и местонахождение

Одним из аспектов SDP является то, что она должна быть сосредоточена на новом "точка присутствия ". Это точка доступа пользователей к их конвергентным службам, где их предпочтения и права оцениваются в режиме реального времени. Обработка предпочтений и прав гарантирует, что услуги пользователя в контексте их устройства / местоположения доставляются правильно. Поскольку права связаны с продуктом и режимы управления услугами оператора, основная архитектура SDP должна определять управляемые продукты, услуги, пользователей, процессы предпочтений и прав.

Реализация стандартов остается критическим фактором в приложениях Presence. Внедрение таких стандартов, как SIP и SIMPLE (протокол инициации сеанса для обмена мгновенными сообщениями и расширение использования присутствия) становится все более распространенным. SIMPLE Presence предоставляет стандартный портативный и безопасный интерфейс для управления информацией о присутствии между SIMPLE-клиентом (наблюдателем) и сервером присутствия (агентом присутствия). См. JSR 164 для ПРОСТОГО присутствия. Поставщики серверов SIMPLE Presence включают Oracle и Italtel.

Интеграция

Использование стандартов для раскрытия интерфейсов между SDP и внутри SDP должно свести к минимуму необходимость интеграции в трех основных областях: (1) южное направление к базовым компонентам базовой сети (2) между вспомогательными приложениями, такими как CRM, биллинг и активация услуг ( 3) сторонние приложения и сервисы. Реализация Сервис-Ориентированная Архитектура (SOA) может использовать стандартные интерфейсы и веб-службы.

Поставщики программного обеспечения включают микросистемы HP, wwite, IBM, Oracle и Sun. Поставщики сетевого оборудования также предоставляют SDP, такие как IMS, IPTV, Mobile TV и т. Д., И предлагают развитие этих SDP.

Отношение к SOA

Многое было сделано за последние годы^{[когда? ]} из Сервис-Ориентированная Архитектура (SOA) концепция. Обсуждения, которые когда-то были сосредоточены на интеграция корпоративных приложений (EAI) технологии и концепции переместились в область SOA, отдав предпочтение таким идеям, как композиция услуг, а не простой адаптации сообщений и извлечь, преобразовать и загрузить техники.

SOA можно использовать в качестве технологии интеграции приложений в SDP, но лучше всего они обслуживаются при использовании в функциях с более низкой производительностью, таких как соединения между транзакциями. OSS и BSS приложения и SDP. SOA нуждаются в тщательном рассмотрении, если они должны соответствовать требованиям реального времени, предъявляемым к SDP конвергентными службами типа событий.

Аналогичная концепция SDP, встречающаяся в сфере SOA, - это экосистема веб-сервисов (также известная как рынок веб-сервисов) и платформа SaaS. Экосистема веб-сервисов - это размещенная среда, в которой участники предоставляют свои сервисы с помощью общих веб-технологий, таких как HTTP, XML, МЫЛО и ОТДЫХ. Эта размещенная среда предоставляет ряд компонентов предоставления услуг, охватывающих такие аспекты, как аутентификация, управление идентификацией, измерение и аналитика использования, адаптация контента, преобразование формата данных, начисление платы и оплата. Это позволяет поставщикам услуг сосредоточиться на своих основных функциях и передать их на аутсорсинг третьим сторонам. Сервисы, развернутые в экосистемах веб-сервисов, могут быть критически важными для бизнеса, но они обычно не имеют требований к работе в реальном времени и высокой производительности, связанных с телекоммуникационными сервисами, для которых традиционно задуманы SDP. Обычно они поддерживают общие бизнес-функции, такие как составление предложений, управление заказами, управление маркетинговыми кампаниями или обслуживание клиентов. SOA также можно использовать для стандартизации операционных процессов и их повторного использования в SDP.

Реализация SDP

Существенные изменения в ИТ и сетевой архитектуре требуются при реализации реальных конвергентных услуг в реальном времени и операционных SDP. Многие SDP разработаны как абстрактные структуры с диаграммами, в которых используются ярлыки, такие как «Уровень абстракции услуг» и т. Д. В реальных системах такие «уровни» фактически не существуют. Кроме того, с помощью абстрактных диаграмм трудно понять, что такое реальная модель операционных данных и сколько серверов, баз данных или каталогов можно использовать или интегрировать для формирования конвергентных служб SDP и функций самообслуживания. Операторы могут столкнуться с многомиллионными ежегодными проблемами. долларовые счета за электроэнергию для своих систем. Отсюда следует, что SDP с несколькими серверами / базами данных не являются экологически чистыми или экономически эффективными, если те же функции могут быть интегрированы и потребляют гораздо меньше энергии.

Управление идентификацией и информацией: Чтобы определить или разработать SDP, мы должны определить, что такое измерение обслуживания клиентов и устройств. Если проект SDP должен учитывать, скажем, 1 млн пользователей, а также управлять их устройствами, и для каждого идентифицированного элемента требуется от 5 до 10 информационных объектов, то базовый SDP, вероятно, обрабатывает 20 млн объектов в реальном времени. Поскольку управление этими объектами диктует основные процессы управления идентификацией платформы, критическое внимание следует уделить способу их реализации. Опыт показал, что одному пользователю SDP конвергентных служб может потребоваться 100 объектов информации, при этом некоторые объекты, такие как предпочтения, содержат 100 атрибутов. Требования к емкости для 10 миллионов пользователей означают, что платформа должна поддерживать 1 миллиард объектов и до 50 миллиардов атрибутов.

Идентификационные данные и права группы: Традиционно мы имели дело с Identity Management как с одним пользователем или устройством, входящим в систему с именем и паролем, и предполагали, что Identity Server, хранящий имена и пароли, решает проблему. На практике, хотя в мире MSO, у нас есть владельцы учетных записей, вторичные держатели учетных записей (дети семьи), гости, подарки, контент, устройства, предпочтения, которые должны быть связаны друг с другом, чтобы получить управляемую услугу. получение может быть авторизовано с помощью имени и паролей, но должно быть разрешено только с помощью разрешений, связанных с предоставлением продукта. Архитектуры DP должны поддерживать функции управления групповой идентификацией и продуктов / услуг.

Присутствие и события: Присутствие - это управление статусом всех онлайн-активов. Но что это значит для системной архитектуры? Традиционно мы применяли «транзакционную» парадигму, когда, например, пользователь входит в систему и создает транзакцию на сетевом коммутаторе, веб-сервере или приложении базы данных. Сервисы присутствия означают, что мы управляем событиями состояния со скоростью, которая намного выше, чем у наших традиционных транзакционных систем. Вопрос в том, как миллионы, если не миллиарды событий управляются во фрагментированных системах, множественных архитектурах баз данных или, фактически, фреймворках? последовательная, высокоинтегрированная система управления событиями как основная функция.

Конвергентные идентичности:Возникает эксплуатационная проблема с 3G IMS и SIP и конвергентными услугами. SIP может применять IP-адреса (IPv4 или v6), SIP URI (адреса электронной почты) и SIP TEL URI (номера телефонов) в полях сообщения «Кому», «От», «Через» и «Контакт». Такие идентификаторы могут указывать на телефонное устройство, дверь холодильника, ферму контента, отдельный фрагмент контента, пользователя или даже группу пользователей. Эта гибкость означает, что вызов SIP может быть осуществлен практически из чего угодно в любую другую вещь, при условии, что он имеет на это право. Поскольку SIP может применять сочетание этих идентификаторов Интернет и телефонной системы в процессе вызова, из этого следует, что SDP должен тесно связать свою обработку SIP с системой DHCP / DNS, мобильной базой данных HSS, системой авторизации пользователей, системой событий присутствия. , адресная книга пользователя, обработка телефонных звонков и управление услугами / продуктами оператора с его системой прав - все в режиме реального времени. Отсюда следует, что такую функциональность было бы очень сложно применить ко многим взаимосвязанным функциям и фрагментированным базам данных, использующим «SOA».

Технологии и наборы инструментов SDP должны решать три фундаментальных вопроса:^{[нужна цитата ]}

Какие товары и услуги предлагаются и управляются в режиме реального времени оператором и системами самообслуживания клиентов, включая управление услугами на основе присутствия (мир Интернета, управляемого событиями), и то, как предоставляются права пользователей в реальном времени. обработанный.
Какая информационная модель конвергентных услуг используется в проекте SDP, который представляет онлайн-бизнес оператора, у которого есть абоненты, устройства, телефонные звонки, предпочтения, права, адресные книги и т.д. Во многих случаях MSO с 10 миллионами клиентов требует SDP с 500 миллионами информационных элементов - и чтобы эти элементы были доступны тысячи раз в секунду для множества различных функций SDP.
Какая архитектура управления событиями / присутствием используется в проекте SDP, который управляет скоростью онлайн-бизнес-событий. Ситуация может заключаться в том, что население города, возвращающееся домой ночью, может генерировать миллиарды статусных событий в сети. Как они будут обрабатываться SDP?

Эти три основных системных требования фактически диктуют архитектуру реального операционного SDP независимо от «абстрактных меток», применяемых к его логическим моделям, SOA, протоколам шины сообщений и межсоединениям серверов. Если эти фундаментальные требования не включены в проект SDP, оператору остается решать множество проблем в сфере бизнеса, управления услугами и эксплуатации, например:

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

В некоторых ситуациях MSO имеют миллионы строк жестко запрограммированных потоков управления продуктами и услугами в своих системах и не могут легко перейти на более новые конвергентные измерения услуг.

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

Для поддержки разработки SDP и перехода к гибкому предоставлению услуг в реальном времени системы следующего поколения должны^{[нужна цитата ]} считать.

Смотрите также

Службы каталогов играют важную роль в SDP. Видеть Справочная служба и Управление идентификацией.
Подсистема IP-мультимедиа
Сети следующего поколения
Корпоративная служебная шина Платформа интеграции, обычно используемая для Интеграция корпоративных приложений
Бизнес-интеграция с Java Стандартизация служебной шины предприятия в мире Java
3GPP Стандарты
Открытый мобильный альянс Стандарты интеграции сетевых элементов, системы поддержки операций и Системы поддержки бизнеса
Parlay Group, Parlay X Стандарты, касающиеся интеграции сетевых элементов, систем поддержки операций и систем поддержки бизнеса
JSLEE, Java Service Logic Execution Environment, стандарт Java для серверов приложений, управляемых событиями, используемых в платформах доставки услуг.
Протокол инициирования сеанса Стандартный протокол для IP-связи
Запросы спецификации Java (JSR) для систем поддержки операций
Структура предоставления услуг