Una plataforma de entrega de servicios ( SDP ) es un conjunto de componentes que proporciona una arquitectura de entrega de servicios (como creación de servicios, control de sesiones y protocolos) para un tipo de servicio entregado al consumidor, ya sea un cliente u otro sistema. Aunque se usa comúnmente en el contexto de las telecomunicaciones , se puede aplicar a cualquier sistema que proporcione un servicio (por ejemplo, teléfono VOIP , televisión por protocolo de Internet , servicio de Internet o SaaS ). [1] Aunque el TM Forum (TMF) está trabajando en la definición de especificaciones en esta área, no existe una definición estándar de SDP en la industria y diferentes actores definen sus componentes, amplitud y profundidad de formas ligeramente diferentes.
Los SDP suelen requerir la integración de capacidades de TI y la creación de servicios que cruzan los límites de la tecnología y la red. Los SDP disponibles en la actualidad tienden a estar optimizados para la entrega de un servicio en un dominio tecnológico o de red determinado (por ejemplo, en telecomunicaciones, esto incluye: web, IMS , IPTV, TV móvil, etc.). Por lo general, proporcionan entornos para el control, la creación, la orquestación y la ejecución de servicios. Nuevamente en telecomunicaciones, esto puede incluir abstracciones para el control de medios, presencia/ubicación, integración y otras capacidades de comunicación de bajo nivel. Los SDP son aplicables tanto a aplicaciones de consumo como comerciales.
En el contexto de las telecomunicaciones únicamente, el objetivo comercial de implementar el SDP es permitir el rápido desarrollo y despliegue de nuevos servicios multimedia convergentes, desde servicios telefónicos POTS básicos hasta conferencias de audio y video complejas para videojuegos multijugador (MPG). En el contexto de SaaS, se logran objetivos comerciales similares, pero en un contexto específico para el dominio comercial en particular.
La aparición de las tiendas de aplicaciones , para crear, alojar y entregar aplicaciones para dispositivos como el iPhone de Apple y los teléfonos inteligentes Android de Google , ha puesto el foco en las SDP como un medio para que los proveedores de servicios de comunicación (CSP) generen ingresos a partir de los datos. [2] Al utilizar las SDP para exponer sus activos de red a las comunidades de desarrollo internas y externas, incluidos los desarrolladores web 2.0, los CSP pueden gestionar los ciclos de vida de miles de aplicaciones y sus desarrolladores. [3] [4]
Las empresas de telecomunicaciones, entre las que se incluyen Telcordia Technologies , Nokia Siemens Networks , Nortel , Avaya , Ericsson y Alcatel-Lucent, han proporcionado interfaces e infraestructura de integración de comunicaciones desde principios y mediados de los años 1990. El éxito en materia de ahorro de costes de los sistemas VoIP basados en IP como sustitutos de los sistemas de centralitas privadas (PBX) y los teléfonos de escritorio ha impulsado un cambio en el enfoque de la industria desde los sistemas propietarios a las tecnologías abiertas y estándar.
Este cambio hacia entornos abiertos ha atraído a empresas de telecomunicaciones centradas en el software como Teligent Telecom [5] y ha permitido que integradores de sistemas como Tieto , Accenture , IBM , TCS , HP , Alcatel-Lucent , Tech Mahindra , Infosys , Wipro y CGI ofrezcan servicios de integración. Además, nuevos consorcios de empresas de productos de software de telecomunicaciones ofrecen productos de software preintegrados para crear SDP basados en elementos como servicios de valor añadido, facturación convergente y gestión de relaciones con socios y contenido.
Dado que los SDP son capaces de cruzar los límites tecnológicos, se hace posible una amplia gama de aplicaciones combinadas, por ejemplo:
Se espera que el mercado de plataformas de prestación de servicios crezca a una CAGR del 10 % durante el período de pronóstico 2019-2024. [6]
A finales de los años 90 se vivió un período de cambios sin precedentes en las aplicaciones empresariales , ya que el dominio de las arquitecturas cliente-servidor se fue relajando gradualmente y se permitió la entrada de arquitecturas de n niveles. Esto representó el advenimiento del servidor de aplicaciones , un compromiso flexible entre los absolutos de la terminal tonta y la PC cliente con mucha lógica. Aunque los participantes en el círculo de servidores de aplicaciones fueron muchos y variados, compartían ventajas comunes: abstracción de proveedores de bases de datos, modelos de programación de estándares abiertos (principalmente orientados a objetos ), características de alta disponibilidad y escalabilidad y marcos de presentación, entre otros. Estas transformaciones fueron desencadenadas por fuerzas empresariales, incluida la ola desenfrenada que fue el auge de Internet , pero nada de esto habría sido posible sin la proliferación de estándares como el protocolo TCP/IP , el lenguaje de programación Java y la arquitectura de servidor de aplicaciones web Java EE . Es en este contexto de transformación que se puso en marcha la era de cambio rápido de las telecomunicaciones.
Hasta los primeros años de 2000, los mercados de las tecnologías de telecomunicaciones comerciales y empresariales todavía estaban saturados de hardware y software propietarios. Los estándares abiertos comenzaron a popularizarse con la introducción de las tecnologías IP y con la rápida expansión de la voz sobre IP (VoIP) para la transmisión de datos de voz a través de redes de paquetes y el protocolo de inicio de sesión (SIP) para el control estandarizado de los medios, especialmente en lo que respecta a las comunicaciones de voz empresariales.
En este nuevo entorno basado en estándares, la convergencia de los mundos de voz y datos ha dejado de ser un término para los desastrosos intentos de integración de las telecomunicaciones y la TI para convertirse en una verdadera vía para la producción de nuevos y mejores servicios para consumidores y empresas. En los últimos años se han introducido o proliferado varias bibliotecas de programación SIP (reSIProcate, Aricent , MjSip y su puerto derivado de HSC) y productos basados en el relativamente nuevo estándar SIP, y el estándar IP Multimedia Subsystem definido por el 3GPP ha ganado un gran número de seguidores. La Plataforma de Entrega de Servicios, cuyo poder proviene en gran parte de la calidad y la aceptación de estos estándares de apoyo, está ganando rápidamente aceptación como un patrón arquitectónico de amplia aplicación.
En la industria actual, se utilizan múltiples definiciones de Plataforma de Entrega de Servicios (SDP) sin que se haya establecido un consenso sobre un significado común. Debido a esto y a la necesidad de que los proveedores de servicios comprendan cómo gestionar mejor las SDP, el TM Forum (TMF) ha comenzado a estandarizar el concepto de Marco de Entrega de Servicios (SDF) y la gestión de SDF. La definición de SDF proporciona la terminología y los conceptos necesarios para hacer referencia a los diversos componentes involucrados, como aplicaciones y facilitadores, exposición de red y servicio, y orquestación.
Lo que se necesita para ofrecer una combinación de servicios personalizados de múltiples SDP a los usuarios finales es un medio para interconectar esos SDP a través de habilitadores de servicios y recursos de red comunes. Sin embargo, detrás de estos aspectos de servicio se encuentra un concepto fundamental: los atributos del usuario y los servicios que recibe requieren un repositorio común y un modelo de datos común , como los que proporciona un directorio LDAP/X.500 o una base de datos HSS. Las primeras implementaciones de SDP de esta naturaleza comenzaron a mediados o fines de la década de 1990 para los servicios convergentes de ISP. En los últimos 5 años se han implementado SDP más grandes y complejos en entornos de tipo MSO y para operadores móviles.
Los SDP se consideran comúnmente para entornos de tipo telecomunicaciones como un sistema central que interconecta la infraestructura de red y acceso del cliente con los sistemas OSS y BSS. Los SDP en este contexto suelen estar asociados con un régimen de servicio particular, como los teléfonos móviles, o con servicios convergentes.
Los SDP también se tienen en cuenta en el contexto de programas de transformación, convergencia e integración de gran envergadura que requieren un presupuesto considerable. La dificultad de estos proyectos es que pueden ser necesarias cientos de miles de decisiones de diseño e implementación, una vez que se ha acordado la arquitectura. Naturalmente, esta cuestión por sí sola dicta la necesidad de contar con habilidades de desarrollo de software e ingeniería operativa. Probablemente, la mejor forma de reducir estos problemas de diseño e integración es simular el SDP en un sistema de pequeña escala antes de que comience realmente el gran proyecto. Esto permite verificar que la arquitectura cumple con los requisitos operativos, de prestación de servicios y de negocio.
Los SDP también deben considerarse no sólo como una función central dentro de un operador sino como una serie de nodos de servicio distribuidos e interconectados (por ejemplo) por razones de redundancia y para diferentes perfiles de servicio para diferentes sectores comerciales y de mercado. Muchos operadores proporcionan productos a escala/nivel comercial, como servicios de voz, alojamiento web, VPN, correo, conferencias y mensajería a clientes gubernamentales y corporativos. La evolución de estos servicios agrupados podría ser desde sistemas de gestión fragmentados a un "entorno de servicio privado virtual" donde el operador ejecuta un SDP dedicado para cada uno de sus clientes que requieren sus servicios a demanda y bajo su control.
Los SDP también se pueden utilizar para gestionar distritos independientes con conectividad inalámbrica, como centros comerciales, aeropuertos, residencias de jubilados y centros de atención ambulatoria.
El punto de acceso principal de un desarrollador de software de telecomunicaciones, el entorno de creación de servicios (SCE, también entorno de creación de aplicaciones o entorno de desarrollo integrado ), es utilizado a menudo por el desarrollador para crear software, scripts y recursos que representan los servicios que se van a exponer. Estos pueden variar en complejidad desde complementos básicos de Eclipse hasta aplicaciones de modelado de aplicaciones de telecomunicaciones completamente abstractas y basadas en metadatos (como el producto CRM Central de Avaya, que ya no se fabrica).
El objetivo de la SCE es facilitar la creación rápida de nuevos servicios de comunicación. Dejando de lado por el momento factores como el marketing, cuanto más fácil sea para los desarrolladores crear servicios para una plataforma determinada, mayor será el número de servicios disponibles y, por lo tanto, la aceptación de la plataforma por parte del mercado de telecomunicaciones en general. Por lo tanto, un proveedor de infraestructura de telecomunicaciones puede obtener una ventaja significativa con un SDP que permita la creación rápida de servicios.
El aprovechamiento de los entornos de creación de servicios SIP y Java EE convergentes aceleró la adopción de plataformas de prestación de servicios. Los desarrolladores de aplicaciones basadas en Java, tradicionalmente centrados en aplicaciones de TI, desarrollan aplicaciones de comunicaciones en tiempo real utilizando Java EE y protocolos de conexión de red como SIP y servicios web Parlay X. Los proveedores de software están combinando estas tecnologías (por ejemplo, Oracle Jdeveloper y Oracle Communication and Mobility Server con el complemento básico de Eclipse) para llegar a una base de desarrolladores más amplia.
Los entornos de ejecución de servicios (SEE) se utilizan para ejecutar los servicios de comunicación desarrollados en SCE. Los entornos de ejecución suelen estar diseñados para imitar el hardware en el que se espera que se ejecute el servicio en particular. SEE puede incluirse en SCE como un IDE.
Un aspecto de un SDP es que debe estar centrado en el nuevo " punto de presencia ". Este es el punto de acceso del usuario a sus servicios convergentes donde sus preferencias y derechos se evalúan en tiempo real. El procesamiento de preferencias y derechos garantiza que los servicios del usuario en sus contextos de dispositivo/ubicación se presten correctamente. Como los derechos están relacionados con los regímenes de gestión de productos y servicios del operador, la arquitectura central de un SDP debe definir productos, servicios, usuarios, preferencias y procesos de derechos gestionados.
La implementación de estándares sigue siendo un factor crítico en las aplicaciones de presencia. La implementación de estándares como SIP y SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions) es cada vez más frecuente. SIMPLE Presence proporciona una interfaz estándar portátil y segura para manipular la información de presencia entre un cliente SIMPLE (observador) y un servidor de presencia (agente de presencia). Consulte JSR 164 para SIMPLE Presence. Los proveedores de servidores SIMPLE Presence incluyen Oracle e Italtel.
El uso de estándares para la exposición de interfaces entre SDP y dentro de los mismos debería minimizar la necesidad de integración en tres áreas principales: (1) hacia el sur hasta los componentes básicos de la red subyacente (2) entre aplicaciones de soporte como CRM, facturación y activación de servicios (3) aplicaciones y servicios de terceros. La implementación de la arquitectura orientada a servicios (SOA) puede utilizar interfaces estándar y servicios web.
Entre los proveedores de software se incluyen HP, Wwite, IBM, Oracle y Sun Microsystems. Los proveedores de equipos de red también proporcionan SDP como IMS, IPTV, Mobile TV, etc. y ofrecen la evolución de estos SDP.
En los últimos años se ha hablado mucho del concepto de arquitectura orientada a servicios (SOA). Los debates que antes se centraban en las tecnologías y conceptos de integración de aplicaciones empresariales (EAI) se han trasladado al ámbito de la SOA, favoreciendo ideas como la composición de servicios en lugar de la simple adaptación de mensajes y las técnicas de extracción, transformación y carga .
Las SOA se pueden utilizar como una tecnología de integración de aplicaciones dentro de un SDP, pero funcionan mejor cuando se utilizan en funciones de menor rendimiento, como las conexiones entre las aplicaciones transaccionales OSS y BSS y el SDP. Las SOA deben considerarse cuidadosamente si se pretende que cumplan con las demandas en tiempo real que imponen los servicios convergentes de tipo evento al SDP.
Un concepto análogo al SDP que se encuentra en el ámbito de SOA es el de Ecosistema de Servicios Web (también conocido como Mercado de Servicios Web) y la plataforma SaaS. Un Ecosistema de Servicios Web es un entorno hospedado en el que los participantes exponen sus servicios utilizando tecnologías Web comunes como HTTP , XML , SOAP y REST . Este entorno hospedado proporciona una serie de componentes de entrega de servicios que cubren aspectos como autenticación, gestión de identidad, medición y análisis de uso, adaptación de contenido, conversión de formato de datos, cobro y pago. Esto permite a los proveedores de servicios centrarse en su funcionalidad principal y externalizar la entrega de servicios a terceros. Los servicios implementados sobre Ecosistemas de Servicios Web pueden ser críticos para el negocio, pero por lo general no tienen los requisitos de tiempo real y alto rendimiento asociados a los servicios de telecomunicaciones para los que tradicionalmente se conciben los SDP. Por lo general, respaldan funciones comerciales comunes como cotización, gestión de pedidos, gestión de campañas de marketing o atención al cliente. SOA también se puede utilizar para estandarizar procesos operativos y reutilizarlos en todos los SDP.
Para implementar servicios convergentes en tiempo real y en tiempo real, se requieren cambios considerables en la arquitectura de TI y de red, y en los SDP operativos. Muchos SDP están diseñados como marcos abstractos con diagramas que utilizan etiquetas como "capa de abstracción de servicios", etc. En los sistemas reales, tales "capas" en realidad no existen. Además, es difícil darse cuenta a partir de diagramas abstractos cuál es el modelo de datos operativos del mundo real y cuántos servidores, bases de datos o directorios se pueden utilizar o integrar para formar SDP de servicios convergentes y funciones de autocuidado. Los operadores pueden enfrentarse a facturas de electricidad anuales multimillonarias por sus sistemas. De ello se desprende que los SDP con múltiples servidores y múltiples bases de datos no son ecológicos ni rentables si se pueden integrar las mismas funciones y consumir mucha menos energía.
Gestión de identidades e información: para especificar o diseñar un SDP, debemos determinar cuáles son las dimensiones del servicio al cliente y al dispositivo. Si el diseño del SDP debe dar cabida, por ejemplo, a 1 millón de usuarios y gestionar sus dispositivos, y cada elemento identificado requiere de 5 a 10 objetos de información, el SDP central probablemente esté tratando con 20 millones de objetos en tiempo real. Como la gestión de estos objetos dicta los procesos centrales de gestión de identidades de la plataforma, se debe prestar especial atención a la forma en que se implementan. La experiencia ha demostrado que un solo usuario en un SDP de servicios convergentes puede requerir 100 objetos de información y algunos objetos, como las preferencias, pueden contener 100 atributos. Los requisitos de capacidad para 10 millones de usuarios indicarían que la plataforma necesita admitir 1.000 millones de objetos y hasta 50.000 millones de atributos.
Identidad y derechos de grupo: Tradicionalmente, hemos tratado la gestión de identidad como un único usuario o dispositivo que inicia sesión con un nombre y una contraseña y hemos asumido que un servidor de identidad que contenga nombres y contraseñas resuelve el problema. Sin embargo, en la práctica, en el mundo de MSO, tenemos titulares de cuentas, titulares de cuentas secundarias (los hijos de la familia), invitados, regalos, contenido, dispositivos, preferencias que deben vincularse entre sí para recibir un servicio administrado. Los servicios que recibe la identidad grupal pueden autorizarse a través de nombre y contraseñas, pero solo deben habilitarse a través de derechos relacionados con el aprovisionamiento de productos. Las arquitecturas SDP deben adaptarse a la gestión de identidad grupal y las funciones de derechos de productos/servicios.
Presencia y eventos: La presencia es la gestión del estado de todos los activos en línea. Pero, ¿qué significa esto para las arquitecturas de sistemas? Tradicionalmente, hemos aplicado un paradigma "transaccional" en el que, por ejemplo, un usuario inicia sesión y crea una transacción en un conmutador de red, un servidor web o una aplicación de base de datos. Los servicios de presencia significan que estamos gestionando eventos de estado a tasas mucho, mucho más altas que nuestros sistemas transaccionales tradicionales. La pregunta es: ¿cómo se gestionan millones, si no miles de millones, de eventos en sistemas fragmentados, arquitecturas de bases de datos múltiples o, de hecho, marcos de trabajo? Las arquitecturas SDP también deberían tener un sistema de gestión de eventos coherente y altamente integrado como función principal.
Identidades convergentes: surge un problema operativo con 3G IMS y SIP y los servicios convergentes. SIP puede aplicar direcciones IP (IPv4 o v6), URI SIP (direcciones de correo electrónico) y URI SIP TEL (números de teléfono) en sus campos de mensaje Para, Desde, Vía y Contacto. Dichos identificadores pueden apuntar a un dispositivo telefónico, una puerta de refrigerador, una granja de contenido, una sola pieza de contenido, un usuario o incluso un grupo de usuarios. Esta flexibilidad significa que se puede realizar una llamada SIP desde casi cualquier cosa a cualquier otra cosa siempre que esté autorizado para hacerlo. Como SIP puede aplicar una mezcla de estos identificadores de sistemas telefónicos e Internet en el proceso de llamada, se deduce que el SDP debe acoplar estrechamente su procesamiento SIP con el sistema DHCP y DNS , la base de datos móvil HSS, el sistema de autorización de usuarios, el sistema de eventos de presencia, la libreta de direcciones del usuario, el procesamiento de funciones de llamadas telefónicas y la gestión de productos/servicios del operador con su sistema de autorización, todo en tiempo real. De ello se deduce que dicha funcionalidad sería muy difícil de aplicar en muchas funciones interconectadas y bases de datos fragmentadas que utilicen "SOA".
Las tecnologías y los kits de herramientas del SDP deben abordar tres cuestiones fundamentales: [ cita requerida ]
Estos tres requisitos principales del sistema en realidad dictan la arquitectura de un SDP operativo en el mundo real, independientemente de las "etiquetas abstractas" que se apliquen a sus modelos lógicos, SOA, protocolos de bus de mensajes e interconexiones de servidores. Si se omiten estos requisitos fundamentales del diseño del SDP, el operador se enfrenta a muchos problemas comerciales, de gestión de servicios y operativos que debe resolver, como por ejemplo:
En algunas situaciones, los MSO tienen millones de líneas de flujos de gestión de productos y servicios codificados en sus sistemas y no pueden migrar fácilmente a las nuevas dimensiones de servicio convergente.
Una prueba rápida de un diseño de SDP es evaluar su modelo de información y ver si está basado en los entornos de usuario de los servicios convergentes, y ver cómo ese modelo es utilizado y gestionado por todos los sistemas que necesitan incluir sus funciones de presencia y gestión de eventos.
Para apoyar el desarrollo de SDP y la evolución hacia una prestación de servicios ágil y en tiempo real, se deberían considerar sistemas de próxima generación [ cita requerida ] .