El objetivo del presente trabajo en colaboración con HP, es la realización de una prueba de concepto sobre contenedores de servicios convergentes, relacionando contenedores basados en Jain SLEE orientados a eventos asíncronos (Rhino, Mobicents), con contenedores J2EE modificados para soportar eventos asíncronos (BEA Systems We- bLogic® RealTime). Así mismo, se analizará la tecnología Jain SLEE, con sus ventajas y desventajas, adem ́as de describir los fundamentos de esta y sus distintos componentes. Por otra parte, se realizar ́a un estudio del proyecto open source Mobicents, el único con- tenedor de servicios libre conforme a la especificación Jain SLEE 1.0, as ́ı como de sus distintos Resource Adaptors. Como ejemplo práctico se desarrollará un Servicio para Mobicents aplicando los conocimientos mostrados. Finalmente se analizar ́an las conclusiones obtenidas y se expondrán las recomendaciones correspondientes.
Contenedor de servicios convergentes en los entornos de telecomunicaciones
1. ´
Universidad de Leon
Escuela de Ingenier´ Industrial, Inform´tica y
ıas
a
Aeron´utica
a
Proyecto Final de Carrera
Contenedor de Servicios Convergentes
en los entornos de Telecomunicaciones
Autores:
Tutores:
Jos´ Escanciano Santos
e
´
Carlos Fernandez Tessier
Javier Gallego Moral
´
Carmen Benavides Cuellar
Isa´ Garc´ Rodr´
ıas
ıa
ıguez
Le´n, 4 de junio de 2007
o
2.
3. Escuela de Ingenier´ Industrial, Inform´tica y
ıas
a
Aeron´utica
a
Universidad de Le´n
o
El presente Trabajo titulado “Contenedor de Servicios Convergentes en los entornos
de Telecomunicaciones” ha sido realizado por Jos´ Escanciano Santos, Carlos Fern´ndez
e
a
Tessier y Javier Gallego Moral, alumnos de la Escuela de Ingenier´ Industrial, Inıas
form´tica y Aeron´utica de la Universidad de Le´n, con el fin de obtener el t´
a
a
o
ıtulo de
´
Ingeniero en Informatica. La tutor´ para la realizaci´n de este trabajo ha sido
ıa
o
llevada a cabo por la profesora Carmen Benavides Cuellar y el profesor Isa´ Garc´
ıas
ıa
Rodr´
ıguez.
VºBº Tutores
Carmen Benavides Cuellar
VºBº Oficina T´cnica
e
Isa´ Garc´ Rodr´
ıas
ıa
ıguez
´
Rafael I. Rodr´
ıguez Alvarez
Autores
Jos´ Escanciano Santos
e
Carlos Fern´ndez Tessier
a
Javier Gallego Moral
4.
5. Contenedor de Servicios Convergentes en los entornos de
Telecomunicaciones
Jos´ Escanciano Santos,
e
´
Carlos Fernandez Tessier,
Javier Gallego Moral
4 de junio de 2007
6.
7. Agradecimientos
En este punto nos gustar´ agradecer a algunas personas la ayuda que nos han
ıa
prestado a la hora de llevar a cabo este proyecto. Estos son:
Pedro J. D´
ıaz, nuestro tutor de HP que nos gui´ en el desarrollo del proyecto,
o
aport´ndonos ejemplos inspiracionales, abundante informaci´n y apoyo a lo largo
a
o
de todo el a˜o.
n
Carmen Benavides Cu´llar e Isa´ Garc´ Rodr´
e
ıas
ıa
ıguez, nuestros tutores del proyecto, por su apoyo, ayuda y ´nimos para la elaboraci´n del proyecto.
a
o
Michael Maretzke , experto en JAIN SLEE involucrado en el proyecto Mobicents,
por ofrecernos su experiencia sobre la tecnolog´ JAIN SLEE.
ıa
Ivelin Ivanov (ivelin), Bartosz Baranowski(baranowb) y kulikoff por su ayuda
ofrecida a trav´s del foro Mobicents users
e
Victor Torosvi (torosvi), por la inspiraci´n que nos ha dado su ejemplo callo
controll
Y por ultimo a nuestra familia, amigos y compa˜eros por su fe y apoyo.
´
n
A todos ellos, gracias.
iii
9. Resumen
El objetivo del presente trabajo en colaboraci´n con HP, es la realizaci´n de una
o
o
prueba de concepto sobre contenedores de servicios convergentes, relacionando contenedores basados en Jain SLEE orientados a eventos as´
ıncronos (Rhino, Mobicents), con
contenedores J2EE modificados para soportar eventos as´
ıncronos (BEA Systems WebLogic® RealTime). As´ mismo, se analizar´ la tecnolog´ Jain SLEE, con sus ventajas
ı
a
ıa
y desventajas, adem´s de describir los fundamentos de esta y sus distintos componentes.
a
Por otra parte, se realizar´ un estudio del proyecto open source Mobicents, el unico cona
´
tenedor de servicios libre conforme a la especificaci´n Jain SLEE 1.0, as´ como de sus
o
ı
distintos Resource Adaptors. Como ejemplo pr´ctico se desarrollar´ un Servicio para
a
a
Mobicents aplicando los conocimientos mostrados. Finalmente se analizar´n las conclua
siones obtenidas y se expondr´n las recomendaciones correspondientes.
a
v
33. Introducci´n
o
Los operadores de red est´n centr´ndose en implementar r´pidamente una arquiteca
a
a
tura de capa de servicios flexible, din´mica y ´gil para acelerar la entrega de servicios de
a
a
ultima generaci´n. Dichos servicios ser´n independientes de la red de acceso y mezclar´n
´
o
a
a
aspectos de puro telco (IN, IMS) con aspectos del mundo de las tecnolog´ de la inıas
formaci´n (http, LDAP, etc). Adem´s, los servicios de voz cl´sica se est´n convirtiendo
o
a
a
a
en un servicio ofrecido mediante tarifa plana, y por tanto, los operadores no est´n disa
puestos a gastar demasiado en infraestructura para soportar este tipo de servicios.
Por todo ello, est´ surgiendo la necesidad de disponer de los denominados cona
tenedores de servicios convergentes. Dichos contenedores proporcionan un entorno de
ejecuci´n a los servicios, de forma que ´stos deleguen en el contenedor las tareas de
o
e
bajo nivel o tediosas (como el tratamiento de eventos, la monitorizaci´n del servicio,
o
logs, gesti´n del ciclo de vida, etc). Se podr´ decir que dichos contenedores son a los
o
ıa
servicios telco lo que los contenedores J2EE son a los servicios IT.
1
37. Cap´
ıtulo 1
El mundo IT frente al mundo de
la red
Ideas principales:
Hasta ahora las aplicaciones Telco1 estaban vetadas a unos pocos desarrolladores,
que eran los fabricantes de hardware de red. Esto implicaba que las aplicaciones estuviesen pr´cticamente empotradas en la red y que las operadoras de telecomunicaciones
a
estuviesen pr´cticamente forzadas a recurrir siempre al mismo fabricante para enriquea
cer sus servicios. Se puede decir que las operadoras de telecomunicaciones ve´ con
ıan
cierta envidia el mundo de internet, en el que los entornos de desarrollo se estaban estandarizando e iniciativas como la estandarizaci´n de los contenedores de aplicaciones
o
(J2EE) permit´ aplicaciones fiables a la vez que f´ciles de desarrollar, y que permit´
ıan
a
ıan
a los proveedores de servicios de internet poder ofrecer servicios muy innovadores (gracias a una ingente comunidad de desarrolladores con conocimiento), a un bajo coste de
desarrollo y con independencia del hardware sobre el que se ejecutaban las aplicaciones.
Java y la familia de est´ndares alrededor de este se estaba convirtiendo en un est´ndar
a
a
de desarrollo de facto, y por tanto, cualquier iniciativa alrededor de este lenguaje (las
conocidas JSR2 ), autom´ticamente pod´ ser adoptada por una gran cantidad de dea
ıa
sarrolladores.
Ante esta situaci´n, tenemos diferentes actitudes encontradas: por una parte los
o
fabricantes de equipos de red a los que no les interesa l´gicamente este modelo de deo
sarrollo “tipo internet”, puesto que les supondr´ dejar entrar en este coto vedado a
ıa
ellos a otros desarrolladores; por otra parte, los desarrolladores, que est´n altamente
a
interesados en desarrollar servicios avanzados de telecomunicaciones con un conocimiento que esencialmente ya poseen (aunque como veremos, es necesario todav´ saber de
ıa
telecomunicaciones para desarrollar este tipo de servicios), y por otra parte, los operadores de telecomunicaciones, que tienen sentimientos encontrados: por un parte,
quieren abaratar costes y tener un modelo de desarrollo de servicios abierto como en
internet, y por otra, y posiblemente debido a las influencias de los fabricantes de las
1
2
Es un t´rmino gen´rico para compa˜´ de telecomunicaciones.
e
e
nıas
Java Specification Request
5
38. CAP´
ITULO 1. EL MUNDO IT FRENTE AL MUNDO DE LA RED
6
redes que han desplegado, tienen una gran desconfianza a este tipo de entornos, bien
sea debido a su fiabilidad, a su rendimiento o a su arquitectura (alguna vez hemos o´
ıdo
la famosa frase de “la red son eventos frente a peticiones-respuesta que es internet”).
Ante estos intereses encontrados, los operadores probablemente hubiesen seguido
apostando por sus entornos de desarrollo tradicionales, si no hubiese sido por un cambio significativo en su ”l´
ınea de flotaci´n”: el modelo de negocio tradicional de los
o
operadores se est´ extinguiendo. Los ingresos por voz cada vez son menores (de hecho,
a
es posible hablar gratis utilizando internet o tarifas planas), y por tanto, cada vez es
necesario disponer de servicios de valor a˜adido (es decir, de datos) para poder sobren
vivir y no llegar a ser un mero proveedor de conectividad. Esto supone una completa
revoluci´n dentro de la industria que ha forzado a los operadores a realizar una serie
o
de actividades, tomando casi siempre la referencia del mundo de internet o mundo IT:
Buscar el abaratamiento de la infraestructura. Esto implica independencia con respecto al proveedor de red, utilizaci´n de plataformas de prop´sito general (hardo
o
ware no espec´
ıfico telco en lo que sea posible), y tendencia hacia el “todo IP”, es
decir, que toda la infraestructura del operador se soporte sobre un n´cleo basado
u
en el protocolo IP, que es el m´s extendido y por tanto el m´s barato de desplegar.
a
a
Mejorar el tiempo de puesta en servicio. Es necesario poder reaccionar ante un
nuevo servicio de la competencia. Para ello, y retomando la referencia del modelo
de internet, se hace necesaria la existencia de un contenedor gen´rico de servicios
e
y un entorno de creaci´n del servicio basado en ´l, que permita la creaci´n, deo
e
o
sarrollo, test y despliegue de servicios avanzados de forma r´pida. As´ mismo, se
a
ı
facilitan los aspectos de integraci´n horizontal y flexibilidad, aplicando de nuevo
o
los principios de internet: SOA3 y SDP4 .
Facilitar la innovaci´n en los servicios. En telecomunicaciones, siempre se habla de
o
evoluci´n, y no de revoluci´n. Las innovaciones a aportar en los nuevos servicios
o
o
pasan por integrar lo ya existente (la voz, la mensajer´ el prepago, el acceso a
ıa,
internet, etc) con lo nuevo. Para ello, se abraza el est´ndar IMS5 como referencia
a
para esta innovaci´n, a la vez que se comienza a hablar de la incorporaci´n de los
o
o
terceros a la oferta de servicios, mediante APIs est´ndar (relacionadas con Web
a
Services casi siempre). As´ mismo, los denominados servicios combinacionales son
ı
de gran importancia, puesto que facilitan la creaci´n de nuevas propuestas de
o
forma muy sencilla (por ejemplo, combinando la localizaci´n con la mensajer´
o
ıa,
ser´
ıamos capaces de obtener servicios del tipo “X m´s cercano” donde X puede
a
ser farmacia, restaurante, gasolinera, etc.
Convergencia en los servicios. Los operadores actualmente disponen de m´ltiples
u
redes de acceso a las que acceder a sus servicios. Los servicios que los har´n
a
sobrevivir tienen que ser accesibles desde todas ellas. As´ la voz tradicional, la
ı,
3
Services Oriented Architecture
Service Delivery Platforms
5
IP Multimedia Subsystem
4
39. 7
Televisi´n, la voz IP, el acceso a internet, el acceso m´vil, la mensajer´ etc deben
o
o
ıa,
ser tecnolog´ de acceso a los servicios, y no servicios en s´
ıas
ı.
De todo lo anterior, surgen una serie de requisitos sobre lo que podr´ ser el entorno
ıa
de telecomunicaciones de nueva generaci´n:
o
Est´ndar y multiprotocolo, es decir, independiente respecto a la red de acceso.
a
Independiente de la plataforma hardware en la que se ejecuta (es decir, a la
manera de java)
Sobre un contenedor que facilite el proceso de creaci´n, desarrollo, despliegue y
o
puesta en producci´n de forma r´pida y fiable
o
a
Pr´ximo a los desarrolladores de internet
o
Que facilite la apertura a los terceros
Que exporte APIs est´ndar
a
Que permita la convergencia de los servicios
De alto rendimiento y capaz de procesar los eventos de la red
Con bajo coste de pertenencia (si es posible, que sea opensource)
Visto de esta manera, parece que se trata de una serie de requerimientos imposibles
de conjugar que conforman algo parecido a la “piedra filosofal” del mundo Telco. Sin
embargo, existen iniciativas al respecto que son el objeto del presente estudio.
41. Cap´
ıtulo 2
El entorno
En el mundo de hoy d´ en el que la movilidad es de gran importancia para casi
ıa,
todas las personas, las telecomunicaciones son una de las partes m´s importantes, ya
a
que nos permiten estar en contacto con nuestros seres queridos. Las empresas Telco
est´n buscando nuevos productos que permitan a sus usuarios disponer de una maya
or movilidad o de nuevos servicios. Dentro de esta b´squeda tambi´n han empezado
u
e
a ofrecer nuevos servicios, como por ejemplo, Voz sobre IP, televisi´n a medida, etc´tera.
o
e
Disponer de tantos servicios no es f´cil, y menos a´n cuando se requieren distintos
a
u
medios para ofrecer cada uno de los servicios antes mencionados. Hay varias tecnolog´
ıas
1 , JSLEE2 ...) que permiten unificar el manejo de estos servicios mediante la
(J2EE
integraci´n de estos servicios en otras herramientas. Una de esas herramientas es el
o
contenedor de servicios convergentes Mobicents,objeto de este estudio, que asegura ser
capaz de manejar m´ltiples servicios con una efectividad muy alta y una latencia muy
u
baja.
En este entorno es donde surge la necesidad de nuevas herramientas para la creaci´n
o
de las nuevas aplicaciones.
2.1.
EDA y SLEE
En el ´mbito de las telecomunicaciones no se debe esperar a que las cosas sucedan.
a
Simplemente suceden cuando suceden, y cuando esto ocurre hay que actuar en consecuencia. Esta diferencia de visiones hace del mundo de las telecomunicaciones un
escenario especial en el que hay que prepararse de manera especial.
En este mundo es donde cobra sentido el concepto de EDA 3 . En este tipo de arquitecturas se debe procesar cada evento por separado, entendiendo como evento a la
representaci´n de una ocurrencia que requiere procesamiento por parte de la aplicaci´n
o
o
1
Java Platform, Enterprise Edition
Java Service Logic Execution Environment, tambi´n conocido como JAIN SLEE
e
3
Event Driven Architecture, Es un patr´n de arquitectura de software que promueve la producci´n,
o
o
detenci´n, consumo, y reacci´n a eventos
o
o
2
9
42. CAP´
ITULO 2. EL ENTORNO
10
y que lleva informaci´n que describe la ocurrencia, como, por ejemplo, la fuente del
o
evento. Una aplicaci´n dirigida a eventos normalmente no tendr´ un hilo de ejecuci´n
o
a
o
activo, sino que define m´todos que se ejecutar´n cuando ocurra alg´n evento.
e
a
u
Para poder recibir los eventos, una aplicaci´n de este estilo deber´ estar conectada
o
a
a un servidor de aplicaciones que es el que va a recibir los eventos provenientes de
todas las redes convergentes en primer lugar. Una vez recibidos se los reenv´ a toıa
das las aplicaciones que est´n conectadas a ese tipo de eventos. Cuando este servidor
e
de aplicaciones da cabida a un s´lo tipo de protocolo, como el SIP, se conoce con el
o
nombre de ese protocolo, como el SIP AS 4 . Cuando admite m´s de un protocolo que
a
´
funciona sobre Internet, se le conoce con el nombre de IMS AS 5 . Este ultimo es el tipo
´
de aplicaciones que nosotros usaremos.
Un SLEE 6 es servidor de aplicaciones orientadas a eventos con baja latencia. Debido a sus caracter´
ısticas, se pueden usar como servidor de aplicaciones de telecomunicaciones, ya que ´stas requieren una baja latencia.
e
Las aplicaciones que est´n orientadas a esta arquitectura no se suelen denominar
a
programas, ya que este t´rmino se suele aplicar m´s a aplicaciones con un hilo de ejee
a
cuci´n permanentemente activo. El t´rmino que se aplica es el de servicios, ya que s´lo
o
e
o
act´an cuando se producen los eventos, al igual que los servicios de emergencia en la
u
vida real, s´lo act´an cuando se les informa de una ocurrencia.
o
u
El principal ´mbito de aplicaci´n de estos servicios es el de la telefon´ puesto que
a
o
ıa,
es el que m´s auge tiene en el momento actual, aunque a un servidor de aplicaciones
a
tambi´n se pueden vincular servicios que den cabida a nuevas tecnolog´ como la Voz
e
ıas
sobre IP, las im´genes por sat´lite o incluso la seguridad de una casa.
a
e
2.2.
Objetivos
Los objetivos de este documento son muy sencillos: comprobar la capacidad real
que tiene un servidor de aplicaciones para el mundo de las telecomunicaciones, implementando un caso de uso pr´ctico.
a
En nuestro caso estamos probando el servidor de aplicaciones Mobicents, dado que
es un IMS AS de c´digo libre y, seg´n sus desarrolladores, es capaz de manejar casi tano
u
tas operaciones por segundo como las tecnolog´ disponibles actualmente, permitiendo
ıas
abaratar costes, al disponer de tan s´lo una m´quina dedicada en la que se unificar´
o
a
ıan
los diferentes eventos provenientes de las m´ltiples aplicaciones disponibles.
u
En esta evaluaci´n tambi´n intentamos medir la velocidad de desarrollo de aplicao
e
ciones o servicios para este tipo de servidores, sus ventajas sobre otro tipo de tecnolog´
ıas
4
SIP Application Server
IP Multimedia Subsystem Application Server
6
Service Logic Execution Environment,
5
43. 2.3. MODELO DE NEGOCIO
11
y la veracidad de las afirmaciones de sus desarrolladores.
2.3.
Modelo de negocio
El mundo de las telecomunicaciones es un mundo de cambio constante y riesgo, y
por tanto, retrasarse una semana o adelantarse respecto a la competencia al sacar un
producto puede suponer unas p´rdidas o unos beneficios considerables. Esta din´mica
e
a
exige que la creaci´n de nuevos servicios sea r´pida y lo m´s eficiente posible.
o
a
a
El apostar por tecnolog´ de c´digo abierto, adem´s de permitirnos tener a nuestra
ıas
o
a
disposici´n el c´digo fuente para servirnos de base para futuros desarrollos y para
o
o
efectuar posibles adaptaciones, correcciones y mejoras, nos permite ahorrarnos unos
costes de desarrollo que ser´ muy elevados. Este es el caso de Mobicents, un servidor
ıan
de aplicaciones dirigidas a eventos, el primero de c´digo libre en recibir la certificaci´n
o
o
JSLEE, y que complementa a J2EE para permitir la convergencia de todo tipo de datos
provenientes de aplicaciones inteligentes de pr´xima generaci´n. Hay otras alternativas
o
o
comerciales, como por ejemplo Opencloud y jNetX.
2.4.
Redes de pr´xima generaci´n
o
o
El concepto de redes de pr´xima generaci´n (NGN 7 ) es un concepto muy amplio
o
o
para definir las evoluciones clave en los n´cleos de las redes de telecomunicaciones y las
u
redes de acceso que se producir´n en los pr´ximos 5-10 a˜os. La idea general es que una
a
o
n
red transporte toda la informaci´n y servicios encapsul´ndolos en paquetes, al estilo de
o
a
internet. Se suelen construir con el protocolo IP.
2.5.
Un ejemplo de servidor J2EE: BEA
BEA es una familia de productos de la plataforma J2EE que incluye un servidor
de aplicaciones J2EE (BEA WebLogic® Server), un servidor de transacciones, una
plataforma de telecomunicaciones y un servidor HTTP entre otras aplicaciones.
La herramienta principal es el servidor de aplicaciones J2EE, que permite a todas
las aplicaciones escritas en este lenguaje funcionar correctamente conect´ndose a los
a
eventos. Actualmente, permite realizar funciones tan diversas y complejas como telecomunicaciones, RFID8 , computaci´n en tiempo real y virtualizaci´n.
o
o
Dicho servidor J2EE es una SOA. Incluye caracter´
ısticas de “zero downtime” (siempre activo) para fiabilidad y tiempo de servicio de tipo empresarial. Re´ne lo mejor del
u
c´digo libre y c´digo comercial para la obtenci´n de nuevas aplicaciones y servicios
o
o
o
r´pidamente. Ha demostrado una gran eficacia y seguridad.
a
7
8
Next Generation Networking
Radio Frequency IDentification
44. CAP´
ITULO 2. EL ENTORNO
12
La caracter´
ıstica de siempre activo “zero downtime” implica el mantenimiento de
las aplicaciones en funcionamiento incluso cuando se desarrollan nuevas versiones o se
cambia la configuraci´n del servidor. Tambi´n posee otras caracter´
o
e
ısticas como informaci´n de diagn´stico o herramientas gr´ficas de administraci´n.
o
o
a
o
Actualmente BEA soporta los siguientes est´ndares:
a
J2EE versiones 1.3, 1.4 y 5
JAAS9
XSLT10 y Xquery
ebXML11
BPEL12 & BPEL-J
JMX
13
SNMP14
Soporte nativo para:
ˆ SOAP15
ˆ WSDL16
ˆ UDDI17
ˆ Ws-security18
ˆ WSRP19
9
Java Authentication and Authorization Service
Extensible Stylesheet Language Transformations
11
Electronic Business using eXtensible Markup Language
12
Business Process Execution Language
13
Java Management Extensions
14
Simple Network Management Protocol
15
Simple Object Access Protocol
16
Web Services Definition Language
17
Universal Description, Discovery and Integration
18
WebServices-security
19
Web Services for Remote Portlets
10
45. Cap´
ıtulo 3
Las tecnolog´
ıas
3.1.
Requisitos
Los grandes operadores de telecomunicaciones buscan tecnolog´ con unas ciertas
ıas
caracter´
ısticas para permitir la r´pida creaci´n e implantaci´n de servicios de nueva
a
o
o
generaci´n dirigidos a grupos de usuarios espec´
o
ıficos y con un ciclo de vida potencialmente corto. Algunas de esas caracter´
ısticas son:
Comunicaciones unificadas Para poder manejar diversos protocolos como SIP1 ,
XMPP2 , e incluso alg´n protocolo de legado (que actualmente no est´ en deu
e
sarrollo, pero s´ en uso).
ı
Directorio virtual unico para registro de usuarios, informaci´n de perfiles y op´
o
ciones de configuraci´n
o
Operador virtual para ofrecer l´
ıneas telef´nicas, control de llamada y cobros
o
Entorno de juegos multijugador para facilitar la configuraci´n del juego, comunio
caciones entre jugadores, persistencia del estado de juego, entre otras caracter´
ısticas.
Escalabilidad Debido a las variaciones que se producen en el uso de estos sistemas,
´stos deben estar preparados para aumentar su potencial en relativamente poco
e
tiempo.
Estandarizaci´n Cada d´ aparecen nuevos est´ndares. Un sistema de este estilo debe
o
ıa
a
ser capaz de aceptar nuevos est´ndares.
a
Interoperabilidad Durante el proceso de estandarizaci´n hay muchos aspectos que
o
se escapan a los desarrolladores del est´ndar y que pueden aparecer durante la
a
implantaci´n. La interoperabilidad se encarga de eliminar esos problemas.
o
Tiempo de mercado El desarrollo de nuevos servicios debe ser un desarrollo muy
r´pido, debido a la voraz competencia en este campo.
a
1
2
SIP Session Initiation Protocol
Extensible Messaging and Presence Protocol
13
46. CAP´
ITULO 3. LAS TECNOLOG´
IAS
14
Latencia El tiempo transcurrido entre la recepci´n de un evento y su procesamiento
o
ha de ser lo m´s breve posible, puesto que en otro caso, no se podr´ dar las
a
ıan
telecomunicaciones en tiempo real entre dos personas.
Estos requisitos han hecho que las redes converjan hacia redes de pr´xima geno
eraci´n, y que las operadoras tengan que hacer muchos esfuerzos en investigaci´n para
o
o
mantenerse al d´ Adem´s, habr´ requisitos impl´
ıa.
a
ıa
ıcitos, como una cierta facilidad de
configuraci´n, tanto para el usuario final como para la operadora.
o
3.2.
JAVA
3.2.1.
J2EE
De cara al desarrollo de nuevas aplicaciones, Java nos ofrece una de las mayores posibilidades de elecci´n, pues al igual que existe una plataforma de desarrollo secuencial
o
(J2SE), existe una plataforma Java orientada al mundo empresarial y las aplicaciones
orientadas a eventos, para lo que nos proporciona J2EE.
J2EE est´ pensado para invocaciones mayoritariamente s´
a
ıncronas, con acceso a
datos y componentes de un tama˜o relativamente grande, que usan bases de datos en
n
gran medida, tanto para almacenar datos, como para transacciones. No presenta un
buen comportamiento para aplicaciones en tiempo real. En resumen, est´ pensado para
a
una l´gica de negocio pesada y basada en unos pocos nodos con gran capacidad de
o
c´mputo.
o
Para hacernos una idea de c´mo est´ el mundo de las aplicaciones convergentes, de
o
a
la relaci´n entre aplicaciones s´
o
ıncronas y as´
ıncronas, podemos ver la imagen 3.1.
Figura 3.1: Distribuci´n de las aplicaciones s´
o
ıncronas frente a las as´
ıncrones
47. 3.2. JAVA
3.2.2.
15
JAIN SLEE
Para el mundo de las telecomunicaciones, en que adem´s de orientaci´n a eventos se
a
o
necesita una baja latencia, Java ha desarrollado una plataforma llamada JAIN SLEE,
una plataforma de desarrollo que est´n adoptando los operadores internacionalmente
a
para ofrecer nuevos servicios y mejorar los actuales. La plataforma JAIN SLEE permite
a los operadores de red integrar estos servicios con la infraestructura de red existente,
protegiendo de este modo las inversiones realizadas a la vez que desarrollan r´pidaa
mente aplicaciones de futuro usando herramientas Java est´ndares. La especificaci´n
a
o
JAIN SLEE proporciona un est´ndar que permite a los desarrolladores Java construir
a
y desplegar aplicaciones en sistemas de tiempo real como las redes de voz y datos o la
automatizaci´n industrial.
o
JAIN SLEE se centra en proporcionar servicios fiables y escalables portables entre
los distintos usuarios de JAIN SLEE. Integra un modelo de eventos con un modelo de
programaci´n de componentes a la vez que incorpora interfaces est´ndares de control a
o
a
trav´s de JMX, adaptadores de recursos para adaptaci´n de redes, interfaces de perfiles
e
o
gen´ricas, etc. A la vez que realiza estas funciones, tambi´n permite que los desarrole
e
ladores de aplicaciones se abstraigan del protocolo utilizado.
Principalmente maneja triggers, eventos y mensajes mayoritariamente as´
ıncronos,
con objetos ligeros y con un tiempo de vida breve, provenientes de m´ltiples or´
u
ıgenes
y que necesitan una latencia baja. Suele estar distribuido en una gran red.
3.2.3.
JCC
JCC3 es una abstracci´n para efectuar el control de llamadas. Es independiente de
o
cualquier protocolo de red. Dependiendo de la implementaci´n de JCC, se soportar´n
o
a
unos protocolos de red u otros (SIP, H.323, ISUP, INAP, etc) mediante el mapeado
correspondiente.
La API4 JCC es una interfaz Java para la creaci´n, control, manipulaci´n y finalo
o
5 , de conmutaci´n de paquetes
izaci´n de sesiones de comunicaci´n en entornos PSTN
o
o
o
e inal´mbrico. Proporciona facilidades tanto para las partes implicadas en la llamada,
a
como para aplicaciones de terceros.
JCC permite la invocaci´n de aplicaciones durante el establecimiento de la sesi´n.
o
o
Adem´s, permite a los programadores el desarrollo de aplicaciones independientes de la
a
plataforma, siempre y cuando dicha plataforma soporte la API, aumentando el mercado
de sus aplicaciones. Tambi´n permite a los proveedores de servicios ofrecer r´pida y
e
a
eficientemente servicios a los usuarios finales desarrollandolos ellos mismos, mediante
outsourcing, comprandolos desarrollados por terceros o una combinaci´n de ellos.
o
3
Java Call Controll
Application Programming Interface
5
Public Switched Telephone Network, red con conmutaci´n de circuitos tradicional optimizada para
o
comunicaciones de voz en tiempo real.
4
48. CAP´
ITULO 3. LAS TECNOLOG´
IAS
16
3.3.
SIP
El protocolo de iniciaci´n de sesiones es un protocolo de se˜alizaci´n para iniciar,
o
n
o
modificar y finalizar sesiones interactivas entre dos o m´s usuarios sobre una red de
a
paquetes. Una de sus ventajas es que puede devolver m´ltiples tipos de datos mulu
timedia en una unica sesi´n. Es un protocolo basado en texto, con una arquitectura
´
o
cliente-servidor que usa mensajes de solicitud y respuesta.
Para m´s informaci´n ir al documento 10.5.2.1.
a
o
3.4.
SMPP
El protocolo de mensajes cortos peer-to-peer SMPP6 es un protocolo abierto de
la industria de las telecomunicaciones para intercambio de mensajes SMS entre entidades pares SMS como los centros de servicio de mensajes cortos. A menudo se usa
para permitir a terceras partes (p.ej.:proveedores de servicios de valor a˜adido, como
n
nuevas organizaciones) mandar mensajes, normalmente en masa. Est´ dise˜ado para
a
n
simplificar la integraci´n de las aplicaciones de datos con redes inal´mbricas m´viles.
o
a
o
El protocolo se basa en parejas de PDU7 petici´n/respuesta intercambiados medio
ante una conexi´n en la capa 4 de la arquitectura OSI (una sesi´n TCP o X.25 SVC3).
o
o
Los PDUs se codifican en binario por motivos de eficiencia.
Las versiones m´s usadas del SMPP son la v3.3, el est´ndar m´s ampliamente
a
a
a
soportado, y la v3.4, que a˜ade soporte de transmisor-receptor (conexiones simples que
n
pueden enviar y recibir mensajes). El intercambio de datos puede ser s´
ıncrono, donde
cada usuario debe esperar una respuesta por cada PDU enviada, y as´
ıncrono, donde la
transmisi´n y la recepci´n van en hilos independientes y usa buffers y temporizadores.
o
o
La ultima versi´n es la v5.0.
´
o
3.5.
SS7 y SS en general
3.5.1.
Introducci´n
o
El sistema de se˜alizaci´n 7 es un conjunto de protocolos de se˜ales en telefon´ que
n
o
n
ıa
se usan para establecer la mayor´ de las llamadas de tel´fonos en la red fija en todo el
ıa
e
mundo. Normalmente se abrevia como SS7, aunque en Norteam´rica se llama CCSS78 .
e
Fue dise˜ado para reemplazar SS5 y SS6 y R29 , todos ellos est´ndares definidos
n
a
10 anteriormente al SS7 y tuvieron alguna vez ´mbito internacional. El SS7
por ITU-T
a
ha sustituido casi totalmente a SS5 y SS6, pero a´n quedan algunos pa´
u
ıses que usan
6
Short Message Peer-to-peer Protocol
Protocol Data Units, o paquetes
8
Common Channel Signaling System 7
9
Region Two signalling
10
International Telecommunication Union Telecommunication Standardization Sector
7
49. 3.6. XMPP
17
variantes del R2
SS5 y versiones anteriores usaban una se˜alizaci´n en banda, en la que la informan
o
ci´n del establecimiento de la llamada se enviaba reproduciendo tonos especiales en las
o
l´
ıneas telef´nicas (en la jerga de la industria de las telecomunicaciones, se conoce como
o
canales portadores),pero estos ten´ varios problemas de seguridad Los protocolos acıan
tuales separan los datos de la transmisi´n de las se˜ales, para evitar problemas como
o
n
este.
En SS7 se pas´ a un sistema en que la informaci´n de se˜alizaci´n iba fuera de bano
o
n
o
da, portada en un canal de se˜alizaci´n separado. Esto evit´ problemas de seguridad,
n
o
o
ya que el usuario no ten´ conexi´n a estos canales. A SS6 y SS7 tambi´n se les llama
ıa
o
e
CCIS11 o CCS12 debido a la separaci´n entre canales de se˜alizaci´n y de datos.
o
n
o
3.5.2.
Funcionalidad
La se˜alizaci´n se refiere al intercambio de informaci´n requerida entre los compon
o
o
nentes de la llamada para proporcionar y mantener el servicio.
Como somos usuarios de la red cableada, intercambiamos se˜ales con los elementos
n
de la red todo el tiempo. Algunos ejemplos son los d´
ıgitos de se˜alizaci´n, el tono de
n
o
llamada, acceso al contestador...
SS7 es un medio por el que los elementos de la red intercambian informaci´n en
o
forma de mensajes. Tambi´n proporciona una estructura universal para la se˜alizaci´n
e
n
o
de la red de telefon´ mensajer´ interfaces y mantenimiento de la red.
ıa,
ıa,
El uso fundamental de SS7 es para encaminar una llamada telef´nica a trav´s de
o
e
la red telef´nica p´blica cableada. Para hacer esto, la llama debe realizar varios saltos
o
u
(de mi compa˜´ de tel´fonos a una compa˜´ de llamadas de larga distancia, ...). En
nıa
e
nıa
todos y cada uno de los nodos de la red, los conmutadores necesitan saber el origen y
el destino.
SS7 tambi´n tiene importancia a la hora de enlazar el tr´fico VoIP con la red
e
a
cableada, y en las redes de telefon´ m´viles como GSM13 y UMTS14 para aplicaciones
ıa o
de voz y datos.
3.6.
XMPP
El protocolo extensible de mensajer´ y presencia (XMPP, eXtensible Messaging
ıa
and Presence Protocol) es un protocolo XML para mensajer´ instant´nea (tiempo casi
ıa
a
real), presencia y servicios de petici´n y respuesta.
o
Con el protocolo XMPP se establece una plataforma para el intercambio de datos
XML que puede ser usada en aplicaciones de mensajer´ instant´nea. Este protocolo
ıa
a
11
Common Channel Interoffice Signalling System
Common Channel Signaling
13
Global System for Mobile communications
14
Universal Mobile Telecommunications System
12
50. CAP´
ITULO 3. LAS TECNOLOG´
IAS
18
hereda las caracter´
ısticas de adaptabilidad y sencillez del XML.
Para m´s informaci´n ver el documento 10.7
a
o
3.7.
MM7
El protocolo MM7 est´ especificado por 3GPP15 . Se usa para el env´ de mensajes
a
ıo
multimedia. Se basa en el concepto de Web Services y usa SOAP y HTTP para la comunicaci´n. Los mensajes multimedia se env´ al servidor o al repetidor MMS16 con
o
ıan
el m´todo POST del HTTP. El cuerpo del post contiene datos XML sobre la entrega y
e
el mensaje multimedia como un adjunto MIME-multipart.
El protocolo MM7 consiste de mensajes abstractos de petici´n y respuesta. Por
o
ejemplo, cuando un VASP17 quiere mandar un mensaje MMS, env´ una petici´n
ıa
o
MM7 submit.REQ-message al servidor o al repetidor MMS, que responde con un mensaje MM7 submit.RES-message. Cada mensaje tiene los campos obligatorios para asociar la petici´n con la respuesta indicando la especificaci´n MM7.
o
o
15
3rd Generation Partnership Project
Multimedia Messaging Service
17
Value Added Service Provider
16
53. Cap´
ıtulo 4
Introducci´n a Jain SLEE
o
4.1.
Descripci´n general
o
4.1.1.
¿Qu´ es JAIN SLEE?
e
Service Logic Execution Environment (SLEE) es un concepto conocido en la industria de las telecomunicaciones. SLEE presenta gran rendimiento, baja latencia en
el procesado de eventos. Jain SLEE es un est´ndar creado usando el Java Community
a
Process, es la versi´n java de SLEE.
o
JAIN SLEE esta dise˜ado para permitir implementaciones del est´ndar para conon
a
cer los requisitos de las aplicaciones de comunicaciones, tales como las aplicaciones
de se˜ales de red. La especificaci´n Jain SLEE esta dise˜ada entonces para que esn
o
n
tas implementaciones puedan adquirir escalabilidad y disponibilidad a trav´s de las
e
arquitecturas de clustering.
Jain SLEE es el unico est´ndar industrial dirigido para aplicaciones de comuni´
a
caciones port´tiles, i.e. una aplicaci´n puede estar escrita una vez y puede ejecutarse
a
o
en diferentes implementaciones de Jain SLEE. La portabilidad de aplicaciones se hace
posible gracias a la combinaci´n de un lenguaje de programaci´n API (espec´
o
o
ıfico para
el lenguaje de programaci´n JAVA), una t´cnica de especificaci´n no ambigua, una
o
e
o
Referencia de Implementaci´n, y un riguroso conjunto de test que un vendedor debe
o
pasar antes de que sus productos sean correctos con la especificaci´n Jain SLEE.
o
Jain SLEE es el punto de integraci´n para m´ltiples recursos de redes y protocolos.
o
u
Las aplicaciones pueden usar recursos de redes externos diferentes dentro del entorno
JAIN SLEE.
La especificaci´n JAIN SLEE permite a los desarrolladores escribir componentes
o
robustos como integrar las propiedades de transacciones ACID en el modelo de programaci´n. Los componentes pueden ser compuestos para resolver problemas m´s compleo
a
jos.
El est´ndar Jain SLEE puede descargarse desde http://jcp.org/en/jsr/detail?id=22 .
a
La especificaci´n incluye un modelo de componentes para estructurar la l´gica de
o
o
las aplicaciones de comunicaci´n tales como una colecci´n de componentes orientados a
o
o
objetos reusables, y para usar y modificar estos componentes a un nivel m´s alto y para
a
servicios m´s sofisticados. El lenguaje de programaci´n usado por los desarrolladores
a
o
en Jain SLEE es Java. La arquitectura SLEE tambi´n define el contrato entre estos
e
21
54. ´
CAP´
ITULO 4. INTRODUCCION A JAIN SLEE
22
componentes y el contenedor que los albergar´ en tiempo de ejecuci´n. SLEE soporta
a
o
el desarrollo de servidores de aplicaciones altamente disponibles y distribuidas, esto no
hace necesario una estrategia de implementaci´n particular. Lo m´s importante es que
o
a
las aplicaciones pueden escribirse una vez, y despu´s desplegarse en cualquier entorno
e
de aplicaci´n que implemente la especificaci´n SLEE.
o
o
Adem´s para el modelo de componentes, la especificaci´n SLEE tambi´n define el
a
o
e
manejo de interfaces usadas para administrar el entorno de aplicaci´n y los componentes
o
que se ejecutan dentro de este entorno.
Tambi´n se define un conjunto de funciones est´ndar (tales como funciones de tieme
a
po, de localizaci´n ´ alarma) que proveen de utilidades comunes para ser usadas en
o o
componentes de la aplicaci´n.
o
4.1.2.
¿Por qu´ aparece?
e
La pregunta que hay que responderse es porque las aplicaciones de comunicaci´n
o
est´n convergiendo en contenedores Java, y la respuesta se basa en lo siguiente:
a
Las App Telco se est´n moviendo cada vez m´s a arquitecturas basadas en coma
a
ponentes.
El deseo de usar un est´ndar unico.
a
´
Un factor muy importante es el hecho de que presente portabilidad independiente de la plataforma Hardware y Software. Sigue la filosof´ “Write once, run
ıa
anywhere”.
Los contenedores proveen de una importante estructura de servicios, tales como:
abstracci´n de alto nivel para el manejo de estados, transacciones, seguridad,
o
agrupa recursos...
Est´ centrado en la l´gica de valores a˜adidos del n´cleo de las aplicaciones.
a
o
n
u
La influencia que ejerce la gran comunidad de desarrolladores java, hace de java
un magn´
ıfico est´ndar de desarrollo.
a
La influencia que ejerce el soporte software tales como herramientas de desarrollo,
herramientas para el testeo...
4.2.
Modelo de componentes
El modelo de componentes de SLEE est´ centrado en aplicaciones de manejo de
a
eventos o aplicaciones as´
ıncronas. Este modelo elimina referencias directas entre los
productores de eventos (i.e. recursos de red) y los consumidores de eventos (i.e. componentes de aplicaciones). Un componente SLEE se llama un Service Building Block
(SBB) y se aloja en un contenedor SLEE. Un SBB cumple ciertas restricciones de idioma y programaci´n. El contenedor act´a como el entorno de ejecuci´n de los building
o
u
o
blocks y provee de la siguiente infraestructura de servicios al SBB:
Manejo de los recursos y ciclo de vida
55. 4.3. PROCESADO DE EVENTOS
23
Concurrencia
Seguridad
Persistencia
Transacciones
Un descriptor de despliegue hace posible una asociaci´n declarativa entre la ino
fraestructura de servicios y los SBBs alojados por el contenedor, en tiempo de despliegue.
Los componentes SLEE reciben peticiones en forma de eventos que representan una
ocurrencia que requiere un procesado por aplicaci´n. Estas ocurrencias albergan inforo
maci´n que las describe, tales como la fuente del evento. Un componente ejecut´ndose
o
a
dentro de SLEE puede usar eventos para se˜ales, invocaciones, o comunicarse con otras
n
aplicaciones ejecut´ndose en SLEE.
a
4.3.
Procesado de eventos
El enrutado de eventos entre recursos de datos y componentes SLEE, incluyendo
enrutado de eventos entre componentes, es la principal funci´n de SLEE. El modelo de
o
eventos de SLEE se basa en un modelo de publish/subscribe (algo parecido a JMS1 ).
Este modelo desconecta los productores de eventos de las fuentes de eventos a trav´s
e
de un mecanismo indirecto que enruta eventos desde la fuente a los consumidores, y en
SLEE es referido como el mecanismo de enrutado de eventos.
El mecanismo de enrutado de eventos describe c´mo un evento emitido por un
o
productor de eventos es enrutado y entregado a uno o mas instancias de componentes
interesados en el evento. Este enrutador recibe eventos emitidos por productores y los
entrega a las instancias de componentes que est´n interesadas en el evento.
e
Los consumidores de eventos se suscriben a los eventos deseados adjunt´ndose al Aca
tivity Context. Los productores de eventos publican los eventos en el Activity Context.
Un productor de eventos no tiene constancia de los consumidores de eventos asociados,
y un consumidor de eventos tampoco conoce directamente sus productores de eventos.
El Activity Contexts definido por SLEE mantiene la relaci´n entre los productores y
o
consumidores de eventos. El modelo de eventos de SLEE tiene los siguientes beneficios:
Promueve un mayor desacople o aislamiento del productor de eventos con respecto al consumidor. Esto facilita la modularidad y la independencia, as´ pues un
ı
error producido en el productor de evento es menos probable que se propague al
consumidor de eventos y viceversa.
Los desarrolladores de aplicaciones no necesitan saber las interfaces de las fuentes
de eventos y los manejadores de eventos no necesitan tener conocimiento sobre las
aplicaciones que consumen estos eventos. Las aplicaciones y eventos solo necesitan
conocer las interfaces que ellos definen con el Activity Context. Tal desacoplo
reduce la complejidad y costes de desarrollo.
1
Java Message Service
56. ´
CAP´
ITULO 4. INTRODUCCION A JAIN SLEE
24
Elimina referencias directas entre productores y consumidores de eventos. Las
referencias directas reducen la robustez de la aplicaci´n al introducir la posibilidad
o
de referencias inv´lidas.
a
Permite a SLEE conocer las relaciones entre los productores y consumidores de
eventos. Esto hace posible a SLEE proveer de un valor a˜adido como recolecci´n
n
o
de basura de consumidores de eventos los cuales no quieran recibir eventos nunca
m´s.
a
Permite a SLEE especificar un modelo de distribuci´n de eventos consistente
o
y unico, lo que beneficia al desarrollador al proporcionarle un unico modelo a
´
´
aprender.
Mejora la robustez ya que los productores de eventos no implementan el c´dio
go de distribuci´n de eventos que cumple con con los patrones documentados o
o
convenciones.
La aplicaci´n tiene un modelo de distribuci´n de eventos flexible, que s´lo recibe
o
o
o
tipos de eventos de los interesados. Ciertas aplicaciones en una plataforma tan
s´lo requerir´n de distribuci´n de eventos de un tipo espec´
o
a
o
ıfico de evento, mientras
que otras aplicaciones requerir´n distribuci´n de eventos de diferentes tipos.
a
o
4.4.
Integraci´n con J2EE
o
Como se ha mencionado anteriormente SLEE es un modelo de componentes como
EJB2 , Servlet o JSP3 , siendo mas similar a EJB. SLEE se construye sobre conceptos
de tecnolog´ J2EE, pero es un modelo de componentes especializado en aplicaciones
ıas
de manejo de eventos que puede a su vez ser implementado de forma independiente a
J2EE y ser usado por separado, sin requerir J2EE conjuntamente.
4.4.1.
SLEE, EJB y JMS
SLEE tiene incorporado un modelo de eventos el cual es una parte del modelo de
componentes. Mientras el modelo de componentes SLEE toma prestado mucho del modelo de componentes EJB, ´ste no acepta una herencia expl´
e
ıcita de un componente EJB.
Esto es debido a que SLEE es un entorno ligero especializado para dar alta velocidad y
baja latencia en servidores de aplicaciones de proceso de eventos, no requiriendo pues
de toda la funcionalidad de J2EE. No obstante, la Reference Implementation de SLEE
est´ construida sobre la de EJB para ilustrar el mapeado de componentes SLEE en coma
ponentes J2EE y destacar c´mo los despliegues de SLEE pueden existir en plataformas
o
de servidores de aplicaci´n J2EE.
o
JMS es la parte externa del modelo de componentes EJB, es m´s bien un servicio de
a
EJB. JMS puede ser integrado en SLEE a trav´s de un Resource Adaptor (adaptador
e
de recursos), igual que en EJB se hace a trav´s de un conector. Integraci´n SLEE y
e
o
EJB.
2
3
Enterprise Java Bean
JavaServer Pages