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

Для проверки этой статьи нужны дополнительные цитаты . Помогите улучшить эту статью , добавив ссылки на надежные источники . Материалы без источников могут быть оспорены и удалены. Найти источники:  "Service delivery platform" – новости  · газеты  · книги  · ученый  · JSTOR ( январь 2016 г. ) ( Узнайте, как и когда удалять это сообщение )

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время в отрасли используется множество определений платформы доставки услуг (SDP), и нет единого мнения относительно общего значения. По этой причине, а также из-за необходимости для поставщиков услуг понимать, как лучше управлять SDP, Форум TM (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), чтобы охватить более широкую базу разработчиков.

Этот раздел пуст. Вы можете помочь, дополнив его. ( Июль 2014 )

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

Этот раздел пуст. Вы можете помочь, дополнив его. ( Июль 2014 )

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

Внедрение стандартов остается критически важным фактором в приложениях Presence. Внедрение таких стандартов, как 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 microsystems. Поставщики сетевого оборудования также предоставляют SDP, такие как IMS, IPTV, Mobile TV и т. д. и предлагают эволюцию этих SDP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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