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

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

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

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

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

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

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

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

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

Ожидается, что рынок платформ предоставления услуг будет расти в среднем на 10% в течение прогнозируемого периода 2019-2024 годов. ^[6]

История

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

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

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

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

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

Контекст

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

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

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

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

Интеграция

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

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

Связь с SOA

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

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

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

Реализация SDP

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

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

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

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

Конвергентные идентичности: Возникают эксплуатационные проблемы с 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. Стандартизация Enterprise Service Bus в мире Java.
3GPP Стандарты
Стандарты Open Mobile Alliance, касающиеся интеграции сетевых элементов, систем поддержки операций и систем поддержки бизнеса.
Parlay Group , Стандарты Parlay X , касающиеся интеграции сетевых элементов, систем поддержки операций и систем поддержки бизнеса.
JSLEE , среда выполнения логики обслуживания Java, стандарт Java для серверов приложений, управляемых событиями, используемых в платформах доставки услуг.
Протокол инициации сеанса Стандартный протокол IP-связи
Запросы спецификации Java (JSR) для систем поддержки операций
Структура предоставления услуг

Ссылки

[1] Рой, Радхика Ранджан (3 сентября 2018 г.). Справочник по SDP для согласования мультимедийных сеансов: IP-телефония SIP и WebRTC . ЦРК Пресс. ISBN 978-1-351-02388-7 .

[2] Connected Planet Online: «Решение загадки СДП». Рич Карпински. Июнь 2008 г. Проверено 17 марта 2010 г. Архивировано 13 мая 2010 г. в Wayback Machine.

[3] TechTarget: Новости SOA. «В погоне за Apple, HP нацелена на телекоммуникации, предлагая пакеты магазинов приложений». Роб Берри. Сентябрь 2009 г. Проверено 17 марта 2010 г.

[4] 8 марта 2010 г. «К 2014 году рынок платформ доставки услуг достигнет $4,6 млрд, чему способствуют мобильная реклама и магазины приложений.

[5] Пресс-релиз Infonetics. «Операторы связи потратили 57 миллиардов долларов на аутсорсинговые услуги в 2007 году». Может. 2008. Проверено 18 марта 2010 г.

[6] «Рост, тенденции и прогноз глобального рынка платформ доставки услуг на 2019–2024 годы — ожидается, что платформа как услуга (PaaS) будет занимать наибольшую долю — ResearchAndMarkets.com» . www.businesswire.com . 01.08.2019 . Проверено 22 июня 2023 г.

[1]

[2]

[3]

[4]

[5]

[6]