Платформы доставки услуг: архитектура, компоненты и применение.

Введение

Платформа доставки услуг (SDP) – это набор компонентов, обеспечивающих архитектуру доставки (такую как создание услуг, управление сеансами и протоколы) для определенного типа услуги, предоставляемой абоненту, будь то клиент или другая система. Хотя SDP чаще всего используется в контексте телекоммуникаций, она может применяться к любой системе, предоставляющей услуги (например, VoIP-телефония, телевидение по протоколу IP, интернет-сервисы или SaaS). Несмотря на то, что Форум TM Forum (TMF) работает над определением спецификаций в этой области, в отрасли нет единого стандарта для SDP, и различные игроки определяют ее компоненты, масштаб и глубину несколько по-разному. SDP часто требуют интеграции ИТ-возможностей и создания услуг, пересекающих границы технологий и сетей. Доступные сегодня SDP, как правило, оптимизированы для доставки услуги в определенной технологической или сетевой среде (например, в телекоммуникациях это включает: веб, IMS, IPTV, мобильное ТВ и т.д.). Они обычно предоставляют среду для управления, создания, оркестрации и выполнения услуг. В телекоммуникациях это может включать абстракции для управления мультимедиа, определения местоположения, интеграции и других низкоуровневых коммуникационных функций. SDP применимы как к потребительским, так и к корпоративным приложениям. В контексте исключительно телекоммуникаций, бизнес-целью внедрения SDP является обеспечение быстрой разработки и развертывания новых конвергентных мультимедийных услуг – от базовых услуг POTS до сложных аудио- и видеоконференций для многопользовательских видеоигр (MPG). В контексте SaaS достигаются аналогичные бизнес-цели, но с учетом специфики конкретной бизнес-области. Появление магазинов приложений для создания, размещения и доставки приложений для устройств, таких как смартфоны Apple iPhone и Google Android, привлекло внимание к SDP как к средству для операторов связи (CSPs) для получения дохода от данных. Предоставляя доступ к своим сетевым ресурсам внутренним и внешним сообществам разработчиков, включая разработчиков Web 2.0, CSP могут управлять жизненным циклом тысяч приложений и их разработчиков. Компании, такие как Telcordia Technologies, Nokia Siemens Networks, Nortel, Avaya, Ericsson и Alcatel Lucent, предоставляют интерфейсы и инфраструктуру для интеграции коммуникаций с начала и середины 1990-х годов. Экономия затрат, достигнутая благодаря IP-системам VoIP, заменившим проприетарные частные автоматические телефонные станции (PBX) и настольные телефоны, привела к смещению фокуса отрасли с проприетарных систем на открытые, стандартные технологии. Этот переход к открытым средам привлек телекоммуникационные компании, ориентированные на программное обеспечение, такие как Teligent Telecom, и позволил системным интеграторам, таким как Tieto, Accenture, IBM, TCS, HP, Alcatel Lucent, Tech Mahindra, Infosys, Wipro и CGI, предлагать услуги по интеграции. Кроме того, новые консорциумы компаний, разрабатывающих программное обеспечение для телекоммуникаций, предлагают предварительно интегрированные программные продукты для создания SDP на основе таких элементов, как услуги с добавленной стоимостью, конвергентный биллинг и управление взаимоотношениями с контентом и партнерами. Поскольку SDP способны преодолевать технологические границы, становится возможен широкий спектр объединенных приложений, например:

A service delivery platform (SDP) is a set of components that provides a delivery architecture (such as service creation, session control and protocols) for a type of service delivered to consumer, whether it be a customer or other system. Although it is commonly used in the context of telecommunications, it can apply to any system that provides a service (e. g. VOIP Telephone, Internet Protocol TV, Internet Service, or SaaS). Although the TM Forum (TMF) is working on defining specifications in this area, there is no standard definition of SDP in industry and different players define its components, breadth, and depth in slightly different ways. SDPs often require integration of IT capabilities and the creation of services that cross technology and network boundaries. SDPs available today tend to be optimized for the delivery of a service in a given technological or network domain (e. g. in telecommunications this includes: web, IMS, IPTV, Mobile TV, etc.). They typically provide environments for service control, creation, and orchestration and execution. Again in telecommunications, this can include abstractions for media control, presence/location, integration, and other low level communications capabilities. SDPs are applicable to both consumer and business applications. In the context of telecommunications only, the business objective of implementing the SDP is to enable rapid development and deployment of new converged multimedia services, from basic POTS phone services to complex audio/video conferencing for multiplayer video games (MPGs). In the context of SaaS, similar business objectives are achieved but in a context specific to the particular business domain. The emergence of Application Stores, to create, host, and deliver applications for devices such as Apple's iPhone and Google Android smartphones, has focused on SDPs as a means for Communication Service Providers (CSPs) to generate revenue from data. Using the SDP to expose their network assets to both the internal and external development communities, including web 2.0 developers, CSPs can manage the lifecycles of thousands of applications and their developers. Telecommunications companies including Telcordia Technologies, Nokia Siemens Networks, Nortel, Avaya, Ericsson and Alcatel Lucent have provided communications integration interfaces and infrastructure since the early to mid 1990s. The cost saving success of IP based VoIP systems as replacements for proprietary private branch exchange (PBX) systems and desktop phones has prompted a shift in industry focus from proprietary systems to open, standard technologies. This change to open environments has drawn software focused telecommunication companies like Teligent Telecom and allowed systems integrators such as Tieto, Accenture, IBM, TCS, HP, Alcatel Lucent, Tech Mahindra, Infosys, Wipro, and CGI to offer integration services. In addition, new consortia of telecommunications software product companies offer pre integrated software products to create SDPs based on elements, such as value added services, convergent billing and content/partner relationship management. Since SDPs are capable of crossing technology boundaries, a wide range of blended applications become possible, for example:

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

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

История

В конце 1990-х годов на предприятиях произошли беспрецедентные изменения, поскольку влияние клиент-серверных архитектур постепенно ослабевало и открывало путь для многоуровневых архитектур. Это ознаменовало появление сервера приложений – гибкого компромисса между принципиальной простотой тонких терминалов и вычислительной мощью клиентских ПК. Несмотря на большое разнообразие игроков на рынке серверов приложений, они имели общие преимущества: абстрагирование от конкретного поставщика баз данных, открытые (преимущественно объектно-ориентированные) модели программирования, высокая доступность и масштабируемость, а также средства для разработки пользовательского интерфейса и другие. Эти преобразования были вызваны рыночными факторами, включая стремительный рост Интернета, но без распространения таких стандартов, как протокол TCP/IP, язык программирования Java и архитектура веб-сервера приложений Java EE, они были бы невозможны. На этом фоне трансформации и началась эра стремительных перемен в телекоммуникационной отрасли. До начала 2000-х годов рынки коммерческих и корпоративных телекоммуникационных технологий оставались насыщенными проприетарным аппаратным и программным обеспечением. Открытые стандарты стали набирать популярность с внедрением IP-технологий, а также с быстрым развитием технологии Voice over IP (VoIP) для передачи голосовых данных по пакетным сетям и протокола Session Initiation Protocol (SIP) для стандартизированного управления мультимедиа, особенно в корпоративной голосовой связи. В этой новой, основанной на стандартах среде, сближение голосовой и передаваемой данных связи перестало быть синонимом неудачных попыток интеграции телекоммуникаций и ИТ, а стало реальным путем к созданию новых и улучшенных услуг для потребителей и бизнеса. За последние несколько лет были разработаны или получили распространение различные библиотеки программирования SIP (Aricent, MjSip и ее производная версия от HSC), а также продукты, основанные на относительно новом стандарте SIP. Стандарт IP Multimedia Subsystem, разработанный 3GPP, также завоевал широкую популярность. Платформа предоставления услуг (Service Delivery Platform), эффективность которой во многом зависит от качества и принятия этих поддерживающих стандартов, быстро признается как широко применимый архитектурный шаблон. В настоящее время в отрасли используется множество определений платформы предоставления услуг (SDP), и единого мнения относительно их общего значения не существует. В связи с этим, а также с необходимостью для поставщиков услуг лучше понимать, как управлять SDP, TM Forum (TMF) приступил к стандартизации концепции Service Delivery Framework (SDF) и управлению SDF. Определение SDF предоставляет терминологию и понятия, необходимые для описания различных компонентов, таких как приложения и средства их реализации, сетевые и сервисные интерфейсы, а также оркестрация. Для предоставления объединенных персонализированных услуг от нескольких SDP конечным пользователям необходим механизм взаимодействия этих SDP посредством общих сервисных средств и сетевых ресурсов. В основе этих сервисных аспектов лежит фундаментальная концепция, согласно которой атрибуты пользователя и предоставляемые ему услуги требуют общего репозитория и общей модели данных, например, каталога LDAP/X.500 или базы данных HSS. Первые реализации SDP такого типа начались в середине/конце 1990-х годов для конвергированных услуг интернет-провайдеров. Более крупные и сложные SDP были внедрены за последние 5 лет в средах типа MSO и для операторов мобильной связи.

The late 1990s saw a period of unprecedented change in enterprise applications as the grip of client server architectures gradually relaxed and allowed the entrance of n tiered architectures. This represented the advent of the application server, a flexible compromise between the absolutes of the dumb terminal and the logic heavy client PC. Although entrants into the application server ring were many and varied, they shared common advantages: database vendor abstraction, open standard (mostly object oriented) programming models, high availability and scalability characteristics, and presentation frameworks, among others. These transformations were triggered by business forces including the rampaging tidal wave that was the Internet boom, but none of it would have been possible without the proliferation of standards such as the TCP/IP protocol, the Java programming language, and the Java EE web application server architecture. It is against this backdrop of transformation that telecom's era of rapid change was set in motion. Up until the first few years of 2000, the markets for commercial and business telecommunication technologies were still saturated with proprietary hardware and software. Open standards started to become popular as IP technologies were introduced and with the rapid expansion of Voice over IP (VoIP) for transmission of voice data over packet networks and the Session Initiation Protocol (SIP) for standardized media control, especially regarding enterprise voice communication. In this new standards supported environment, convergence of the voice and data worlds has become less a moniker for disastrous telecom/IT integration attempts and more a true avenue for the production of new and better consumer and business services. The last few years have seen the introduction or proliferation of various SIP programming libraries (, Aricent, MjSip and its derived port by HSC) and products based on the relatively new SIP standard, and the IP Multimedia Subsystem standard defined by the 3GPP has gained a huge following. The Service Delivery Platform, whose power comes in large part from the quality and acceptance of these supporting standards, is rapidly gaining acceptance as a widely applicable architectural pattern. In industry today multiple definitions of Service Delivery Platform (SDP) are used with no established consensus as to a common meaning. Because of this, and the need for service providers to understand how to better manage SDPs, the TM Forum (TMF) has started standardizing the concept of Service Delivery Framework (SDF) and SDF management. The SDF definition provides the terminology and concepts needed to reference the various components involved, such as applications and enablers, network and service exposure, and orchestration. What is needed to deliver a blend of personalized services from multiple SDPs to end users is a means to inter work those SDPs through common service enablers and network resources. Underpinning these service aspects though has been a fundamental concept that the user's attributes and the services they receive require a common repository and a common data model, such as those provided by an LDAP/X.500 directory or HSS database. Early SDP implementations of this nature started in the mid / late 1990s for ISP converged services. Larger and more complex SDPs have been implemented over the last 5 years in MSO type environments and for mobile operators.

Контекст

Для среды телекоммуникаций платформы управления услугами (SDP) обычно рассматриваются как ключевая система, соединяющая инфраструктуру доступа и сеть клиента с системами OSS и BSS. В этом контексте SDP обычно связаны с определенным типом услуг, например, мобильной связью или конвергентными услугами. SDP также рассматриваются в рамках масштабных программ трансформации, конвергенции и интеграции, требующих значительных финансовых вложений. Сложность таких проектов заключается в том, что после утверждения архитектуры необходимо принять сотни тысяч решений по проектированию и реализации. Естественно, это само по себе обуславливает необходимость в навыках разработки программного обеспечения и эксплуатации. Вероятно, лучший способ снизить эти проблемы проектирования и интеграции – это смоделировать SDP на небольшой системе перед началом основного проекта. Это позволит проверить соответствие архитектуры требованиям к эксплуатации, предоставлению услуг и бизнес-требованиям. SDP следует рассматривать не только как ключевую функцию оператора, но и как совокупность взаимосвязанных, распределенных узлов обслуживания (например, для обеспечения резервирования и поддержки различных профилей услуг для разных сегментов бизнеса и рынка). Многие операторы предоставляют коммерческие продукты и услуги, такие как пакетные голосовые услуги, веб-хостинг, VPN, почтовые сервисы, услуги видеоконференцсвязи и обмена сообщениями для государственных и корпоративных клиентов. Эволюция таких пакетных услуг может происходить от разрозненных систем управления к "Виртуальной среде частных услуг", где оператор развертывает выделенный SDP для каждого клиента, которому требуются услуги по запросу и под его контролем. SDP также могут использоваться для управления независимыми зонами с поддержкой беспроводной связи, такими как торговые центры, аэропорты, дома престарелых, центры дневного ухода.

Обстановка создания услуг

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

Окружающая среда исполнения

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

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

Одним из аспектов СДП является то, что она должна быть ориентирована на новую "точку присутствия". Это точка доступа пользователя к его конвергентным сервисам, где его предпочтения и права оцениваются в реальном времени. Обработка предпочтений и прав обеспечивает корректную доставку сервисов пользователю с учетом контекста его устройства и местоположения. Поскольку права доступа связаны с политиками управления продуктами и сервисами оператора, базовая архитектура СДП должна определять управляемые продукты, сервисы, пользователей, а также процессы управления предпочтениями и правами доступа. Реализация стандартов остается критически важным фактором в приложениях, связанных с определением местоположения (Presence). Внедрение таких стандартов, как SIP и SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions – протокол инициирования сеанса для расширения функциональности мгновенных сообщений и определения местоположения), становится все более распространенным. SIMPLE Presence предоставляет стандартный, переносимый и безопасный интерфейс для работы с информацией о местоположении между SIMPLE-клиентом (наблюдателем) и сервером определения местоположения (агентом определения местоположения). Подробности см. в JSR 164 для SIMPLE Presence. Поставщиками серверов SIMPLE Presence являются Oracle и Italtel.

Интеграция

Использование стандартов для интерфейсов между SDP и внутри SDP должно минимизировать необходимость интеграции в трех основных областях: (1) с нижележащими компонентами сетевой инфраструктуры, (2) между приложениями поддержки, такими как CRM, биллинг и активация услуг, (3) с приложениями и сервисами сторонних разработчиков. Реализация сервисно-ориентированной архитектуры (SOA) может использовать стандартные интерфейсы и веб-сервисы. Поставщики программного обеспечения включают HP, IBM, Oracle и Sun Microsystems. Поставщики сетевого оборудования также предоставляют SDP, такие как IMS, IPTV, Mobile TV и т.д., и предлагают развитие этих SDP.

Отношение к SOA

В последние годы концепции сервисно-ориентированной архитектуры (SOA) уделяется значительное внимание. Обсуждения, которые ранее были сосредоточены на технологиях и концепциях интеграции корпоративных приложений (EAI), переместились в область SOA, отдавая предпочтение идеям, таким как композиция сервисов, а не простой адаптации сообщений и методам извлечения, преобразования и загрузки данных. SOA может использоваться как технология интеграции приложений в составе ПРР, но наиболее эффективно проявляет себя в менее требовательных к производительности функциях, таких как соединения между транзакционными приложениями OSS и BSS и ПРР. SOA требует тщательного рассмотрения, если они должны соответствовать требованиям к реальному времени, предъявляемым к ПРР конвергентными сервисами событийного типа. Концепция, аналогичная ПРР, в сфере SOA – это Web Service Ecosystem (также известная как Web Service Marketplace) и платформа SaaS. Web Service Ecosystem – это размещаемая среда, в которой участники предоставляют свои сервисы с использованием общих веб-технологий, таких как HTTP, XML, SOAP и REST. Эта размещаемая среда предоставляет ряд компонентов для предоставления сервисов, охватывающих такие аспекты, как аутентификация, управление идентификацией, измерение и анализ использования, адаптация контента, преобразование форматов данных, тарификация и оплата. Это позволяет поставщикам услуг сосредоточиться на своей основной функциональности и передать предоставление сервисов третьим сторонам. Сервисы, развернутые через Web Service Ecosystem, могут быть критически важными для бизнеса, но, как правило, не имеют требований к реальному времени и высокой производительности, характерных для телекоммуникационных сервисов, для которых традиционно разрабатываются ПРР. Обычно они поддерживают общие бизнес-функции, такие как предоставление коммерческих предложений, управление заказами, управление маркетинговыми кампаниями или обслуживание клиентов. SOA также может использоваться для стандартизации операционных процессов и их повторного использования в различных ПРР.