Contenedor de servicios convergentes en los entornos de telecomunicaciones
0 recomendaciones2,528 vistas
El trabajo titulado 'Contenedor de Servicios Convergentes en los Entornos de Telecomunicaciones' se centra en la realización de una prueba de concepto sobre contenedores de servicios convergentes utilizando tecnologías como JAIN SLEE y J2EE. Se analiza el proyecto Open Source Mobicents, que implementa JAIN SLEE, y se desarrolla un servicio práctico como ejemplo. Además, se incluyen recomendaciones y conclusiones sobre las tecnologías estudiadas.
![´
5.5. MODELO DE PROGRAMACION
33
Estas APIs tienen que ser suficientemente ricas para dar soporte al tipo de aplicaciones que necesitan desarrollarse en estos momentos y conseguir reducir los costes y
tiempo de desarrollo.
Estos objetivos gu´ los requisitos de los modelos de programaci´n usados para
ıan
o
el desarrollo de aplicaciones y los requisitos de los servidores de aplicaciones que las
albergan.
5.5.
Modelo de programaci´n
o
Modelo de programaci´n Simple, Orientado a objetos.
o
Da soporte para componentes de aplicaci´n 3rd party y desarrollo de aplicaciones.
o
El servidor de aplicaci´n maneja los estados de aplicaci´n.
o
o
Transaccional
Soporta unidades de trabajo independientes
Posibilita el modelado natural de sistemas as´
ıncronos
Independencia de la red
5.6.
Basado en est´ndares
a
“La adopci´n de una infraestructura de bajo coste para las telecomunio
caciones probablemente abrir´ las oportunidades de nuevos servicios (aplia
caciones), de gran coste hoy en d´ El impacto de los nuevos servicios en
ıa.
redes convergentes basadas en est´ndares ser´ mas amplio y r´pido de lo
a
a
a
que puede ser hoy en d´
ıa,...”[Gartner, Marzo de 2006].
“Las APIs est´ndar abiertas ocultan la complejidad de las redes en la
a
capa de aplicaci´n, y el uso de se˜ales est´ndares y protocolos de control
o
n
a
de llamada son la clave para proveer de flexibilidad y creatividad para los
servicios mejorados de redes de proxima generaci´n.”[Yankee Group].
o
5.7.
Independencia de la Red
Los equipamientos de legado existentes constituyen una gran inversi´n para los opo
eradores de redes. Las arquitecturas de redes transicionales probablemente se utilizar´n
a
por los operadores de redes para adoptar la nueva tecnolog´ Por tanto, ser´ posible
ıa.
a
desplegar aplicaciones en un entorno de aplicaci´n SLEE que use diversos recursos de
o
redes y protocolos de se˜al.
n
La integraci´n de un nuevo tipo de elemento de red, protocol de se˜al, o sistema
o
n
externo no requerir´ cambios en la arquitectura central del software del servidor de
a
aplicaciones. Este requisito se satisface gracias al Resource Adaptor Framework que da](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-65-320.jpg)
![CAP´
ITULO 8. CARACTER´
ISTICAS
62
8.3.
Integraci´n con otros applications servers
o
Mobicents se integra con otros applications servers como WebSphere, WebLogic y
Glassfish, ya que provee una interfaz de conexion JSLEE para cualquier cliente Java,
incluyendo servidores EE.
Figura 8.1: Application Server
8.4.
Rendimiento
A partir de la versi´n 1.0.00.CR1 mediante la herramienta open source SIPP han
o
reportado los siguientes resultados de rendimiento:
100 llamadas SIP por segundo (cps2 ) en una sola CPU de 2Ghz; Linux
370 llamadas SIP por segundo en un 4 way Netra 440; Sun/Solaris
Por lo que el rendimiento m´ximo obtenido esta entre las 1000-1200 tps3 . [19]
a
8.5.
Resource Adaptors
Mobicents actualmente tiene los siguientes Resource Adaptors 6.7 disponibles:
RA SIP 10.5, usando JAIN SIP RI and extendido con un SIP Registrar b´sico
a
y Servicios Proxy.
RA XMPP/Google Talk 10.7, Usando la libreria Smack. Funciona en modo
Cliente y Servidor de Componente.
2
3
1 SIP cps equivale a 5 tps, porque cada llamada SIP implica de 5 a 6 transacciones
transacciones por segundo](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-94-320.jpg)
![8.6. LICENCIA
63
RA Asterisk 10.1, Usando la librer´ Asterisk-Java.
ıa
RA Java Call Control (JCC), Implementando las recomendaciones en el
Ap´ndice C de JSR 22 - JSLEE 1.0 [7].
e
RA Parlay/Parlay-X 10.3, Permitiendo acceso controlado a pasarelas Parlay.
RA J2EE/JCA, Implementando las recomendaciones en el Ap´ndice F de JSR
e
22 - JSLEE 1.0 [7].
RA Diameter 10.9, Basado en la librer´ Java Diameter de Ivan Skytte Jorıa
gensen.
RA Media 10.8, Un Media RA b´sico con implementaciones basadas por defecto
a
en JMF4 .
RA SMPP 10.6, Para mensajes SMS.
RA Media Gateway 10.2, Para control avanzado de media.
RA JCC INAP5 , para integraci´n SS7 INAP6
o
RA Persistence 10.4, usa JPA7 para almacenar los datos.
RA MSCML8 (En desarrollo) Un Resource Adaptor que usa MSCML sobre SIP
para controlar la funcionalidad del servidor media.
8.5.1.
Resource Adaptors
Hay otros Resource Adaptors disponibles bajo licencias comerciales por terceros
vendedores.
8.6.
Licencia
Mobicents est´ distribuido bajo Licencia dual flexible [20], como MySQL y Asterisk.
a
La licencia de distribuci´n por defecto es GNU General Public License (GPL9 , es una
o
licencia creada por la Free Software Foundation, y est´ orientada principalmente a
a
proteger la libre distribuci´n, modificaci´n y uso de software. Su prop´sito es declarar
o
o
o
que el software cubierto por esta licencia es software libre y protegerlo de intentos de
apropiaci´n que restrinjan esas libertades a los usuarios.), la licencia m´s popular de
o
a
la Free Open Source Software (FOSS) en el mundo.
4
Java Media Framework.
Intelligent Network Application Part
6
Intelligent Network Application Part, es un protocolo de se˜ales usado por la arquitectura de redes
n
inteligentes (IN)
7
Java Persistence API[30]
8
Es un protocolo usado en conjunci´n con SIP para habilitar la entrega de servicios de conferencia
o
multimedia avanzados a trav´s de redes IP
e
9
General Public License
5](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-95-320.jpg)
![8.8. PROYECTO MOBICENTS
8.8.2.
67
Actividad
La actividad ha decrecido mucho, apenas contestan en el Foro, el desarrollo de
muchos RAs est´ estancado (Ver figura estad´
a
ısticas del proyecto), creemos que es debido
fundamentalmente por la organizaci´n del “camp mobicents” que tuvo lugar los pasados
o
28 y 29 de abril de 2007, los nuevos servicios que est´ ofreciendo Mobicents, como la
a
licencia comercial, y cursos de programaci´n JainSlee. Probablemente tambi´n est´n
o
e
e
trabajando en alg´n libro que trate sobre estos temas.
u
Figura 8.2: Estad´
ısticas del proyecto
8.8.3.
P´gina Mobicents
a
La principal fuente de informaci´n acerca de los avances y ejemplos de Mobicents, es
o
la propia p´gina del producto [11], pero dicha p´gina est´ muy mal dise˜ada, ya que se
a
a
a
n
encuentra desorganizada en algunos casos, los recursos para descargar siendo distintos
no poseen una forma de descarga igual, sino que cada uno se descarga us´ndose medios
a
alternativos sourceforge, cvs, svn, eclipse..., lo que causa un poco de descontrol. Por otro
lado, no existen gu´ adecuadas de c´mo descargar, desplegar, compilar, en resumidas
ıas
o
cuentas de como empezar a usar casos pr´cticos de mobicents.
a
8.8.4.
8.8.4.1.
Foros
Mobicents users
El foro de Mobicents users [14], tiene como objetivo las dudas que tengan los usuarios
con el proyecto Mobicents, a la hora de instalarlo, usar los resource adaptors y probar
servicios ya implementados. En ´l no siempre responden, adem´s de ser poco concretos.
e
a
Tambi´n hay que tener en cuenta que al ser Open Source la gente involucrada no gana
e
nada respondi´ndote con celeridad a tus cuestiones.
e](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-99-320.jpg)
![CAP´
ITULO 8. CARACTER´
ISTICAS
68
8.8.4.2.
Mobicents contributors
El foro Mobicents contributors [15] se discute el dise˜o de mobicents, resource adapn
tors, servicios, tareas pendientes de la hoja de ruta 11.1 etc, donde invitan a participar
activamente en ellos o proponer nuevos.
8.8.4.3.
JSLEE Resource Adaptor Types
En el foro JSLEE Resource Adaptor Types [16] se dedican a promover la estandarizaci´n de interfaces RA para mejorar la portabilidad de la aplicaci´n. Tambi´n
o
o
e
se mejoran RAs ya existentes o se proponen nuevos.
8.8.5.
Informar de Bugs, Parches y Feature Requests
Se puede usar el issue tracking system [17] para informar de Bugs y Feature Requests
de Mobicents.
Cuando se env´ un bug, es recomendable enviar un automated test case en formato
ıa
TCK o JUnit que exponga el problema.](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-100-320.jpg)
![9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK)
81
La clase BounceSBB necesita interrogar al ´rbol JNDI para la interfaz del SBB por
a
el RA. El nombre JNDI es configurado en el DD del SBB.
9.1.11.
El RA - Estructura y M´todos.
e
La clase RAFrameResourceAdaptor implementa el Resource Adaptor RAFrame y
puede ser localizado en el paquete com.maretzke.raframe.ra. La mayor´ de los m´toıa
e
dos del RA implementan la interfaz javax.slee.ResourceAdaptor y representa hooks
(enganches) invocados por el entorno JSLEE durante el ciclo de vida del RA. En la
versi´n 1.0 de JSLEE (JSR-22) [7] la integraci´n del Resource Adaptor era considero
o
ada un detalle espec´
ıfico de la implementaci´n. La versi´n 1.1 de JSLEE (JSR-240)
o
o
[8] se centr´ en la arquitectura del Resource Adaptor. El proyecto de c´digo abierto
o
o
Mobicents sigue las actividades de estandarizaci´n muy de cerca e implementa ya la
o
mayor´ de los aspectos de la versi´n 1.1 de JSLEE. Es normal encontrar diferencias o
ıa
o
anomal´ motivadas por seguir la estandarizaci´n.
ıas
o
9.1.12.
entityCreated() y entityActivated()
El m´todo entityCreated() es el primer m´todo llamado por el entorno JSLEE dese
e
pu´s de la instanciaci´n del RA.
e
o
Listado 9.10: M´todo entityCreated() de la clase RAFrameResourceAdaptor
e
/ * Implementa j a v a x . s l e e . r e s o u r c e . ResourceAdaptor R e f e r i d a a l a
E s p e c i f i c a c i ´ n JSLEE v1 . 1 , Borrador r e c i e n t e m e n t e r e v i s a d o ;
o
P´ gina 298 para m´s i n f o r m a c i ´ n . Este m´todo e s llamado por
a
a
o
e
SLEE cuando una i n s t a n c i a de un Adaptador de R e c u r s o s e s t ´
a
c a r g a d a en memoria , o cuando una e n t i d a d Adaptador de
R e c u r s o s e s c r e a d a d ur a n t e e l i n i c i o de SLEE . La
i m ple m e n t ac i ´ n SLEE c o n s t r u i r ´ e l o b j e t o Adaptador de
o
a
R e c u r s o s e i n v o c a r ´ a l m´todo e n t i t y C r e a t e d a n t e s que ninguna
a
e
o t r a o p e r a c i ´ n s e a llamada por e l o b j e t o Adaptador de R e c u r s o s
o
*/
public void e n t i t y C r e a t e d ( B o o t s t r a p C o n t e x t b o o t s t r a p C o n t e x t )
throws R e s o u r c e E x c e p t i o n {
l o g g e r . debug ( ” RAFrameResourceAdaptor . e n t i t y C r e a t e d ( )
llamado . ” ) ;
t h i s . b o o t s t r a p C o n t e x t= b o o t s t r a p C o n t e x t ;
t h i s . s l e e E n d p o i n t= b o o t s t r a p C o n t e x t . g e t S l e e E n d p o i n t ( ) ;
t h i s . eventLookup= b o o t s t r a p C o n t e x t . g e t E v e n t L o o k u p F a c i l i t y ( ) ;
s t a c k = null ;
}](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-113-320.jpg)
![9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK)
9.1.16.
89
Construyendo el RA
Pasos para desplegar el RAFrame.
1. Build el ejemplo: vamos al ejemplo RAFrame y ejecutamos ant. Introducir´ varios
a
.jar en diversas carpetas y devolver´ el mensaje:
a
BUILD SUCCESSFUL
2. Ejecutamos el servidor mobicents, inicio ejecutar: run -c all -b localhost
Figura 9.6: Consola Mobicents.
3. Abrimos un navegador y entramos en http://localhost:8080/jmx-console
4. Hacemos un filtrado poniendo en la caja de textos slee:*
5. Entramos en name=DeploymentMBean
6. Buscamos el m´todo install con un unico par´metro de tipo String, e introducimos
e
´
a
la ruta donde esta el archivo raframe-ra-type.jar por ejemplo:
file:///C:/workspace/RAFrame/stage/raframe-ra-type.jar
Nos devolver´ un DeploableUnitID con un identificador [*]. Por ejemplo:
a
DeployableUnitID [3]](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-121-320.jpg)
![´
CAP´
ITULO 9. MEJORES PRACTICAS
90
Figura 9.7: Consola Mobicents.
Si ya lo hubi´ramos echo, dar´ un error “Exception report”, con la descripci´n:
e
a
o
The server encountered an internal error () that prevented it from fulfilling this
request.
7. Pulsamos en “Back to MBean View”, y en la misma caja de texto del m´todo
e
“install”, instalamos raframe-local-ra.jar por ejemplo:
file:///C:/workspace/RAFrame/stage/raframe-local-ra.jar
Y nos dar´ otro DeploableUnitID con un identificar diferente, por ejemplo
a
DeployableUnitID [4]
8. Pulsamos en “Back to Agent View” y pinchamos sobre:
name=ResourceAdaptorMBean.
9. Vamos al m´todo createResourceAdaptorEntity que acepta tres par´metros, y
e
a
con la caja de texto, “p1”, que acepta resourceAdaptorId, no confundir con la que
acepta String. Introducimos:
ResourceAdaptorID[raframe#maretzke#1.0], sin dejar espacios, en el primer par´metro
a
y RAFrameRA en el segundo, el tercero lo dejamos vac´ Lo invocamos y nos
ıo.
mostrar´ un mensaje como que esta bien hecho.
a
Operation completed successfully without a return value.](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-122-320.jpg)
![9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK)
9.1.17.
93
Construyendo el SBB
1. Copiamos el fichero raframe-1.0.jar que se encuentra en el directorio dist del
ejemplo del RAframe en la librer´ del SBB, que se encuentra en el directorio lib,
ıa
vamos a la carpeta del SBB y ejecutamos ant.
2. Construir el ejemplo: vamos al ejemplo RAFrame y ejecutamos ant. Introducir´ vara
ios .jar en diversas carpetas y devolver´ el mensaje:
a
BUILD SUCCESSFUL
3. Con el servidor mobicents ejecut´ndose, abrimos un navegador y entramos en:
a
http://localhost:8080/jmx-console
4. Haz un filtrado poniendo en la caja de textos slee:*
5. Entra en “name=DeploymentMBean”
6. Busca el m´todo “install” con un unico par´metro de tipo String, e introduce la
e
´
a
ruta donde esta el archivo bounceSBB-service.jar, por ejemplo:
file:///C:/workspace/RASBB/dist/bounceSBB-service.jar
Nos dar´ una id, por ejemplo:
a
DeployableUnitID [5]
Figura 9.12: Consola Mobicents.
El servicio ya est´ instalado.
a](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-125-320.jpg)
![94
´
CAP´
ITULO 9. MEJORES PRACTICAS
7. El siguiente paso es activar el servicio, pulsamos en “Back to Agent View“ y entrar
en ServiceManagementMBean y vete al evento activate que acepta “javax.slee.ServiceID”
e introducimos el valor:
ServiceID[Resource Adaptor FrameworkBounceService#maretzke#1.0]
Operation completed successfully without a return value.
Figura 9.13: Consola Mobicents.
Inv´calo y el servicio estar´ desplegado y esperando por Eventos. Podemos ver el
o
a
esquema con SLEE Graph Viewer:
C:workspaceslee-graphant run](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-126-320.jpg)
![´
CAP´
ITULO 9. MEJORES PRACTICAS
98
9.2.2.
Respuesta
Usa la tabla de perfiles de direcciones y el identificador AddressProfile de la variable
initial-event-select.
Echa un ojo a la secci´n 10.13.2 para una descripci´n de AddressProfileTable y las
o
o
secciones 8.5.2 (p´gina 112) y 8.5.3. (p´gina 114) de la especificaci´n del JAIN SLEE [?]
a
a
o
para el papel de AddressProfiles en el c´lculo del nombre convergente. Tambi´n puedes
a
e
ver un ejemplo de un fragmento de un descriptor de despliegue en la p´gina 108.
a
Si sigues este enfoque, debes crear un AddressProfiles de cada servicio para cada
direcci´n que deba causar la activaci´n del servicio. No habr´ necesidad de usar una
o
o
ıa
base de datos externa en absoluto.
Tambi´n podr´ adoptar este enfoque en concordancia con el servicio principal.
e
ıas
Crea un AddressProfile para cada servicio con una direcci´n unica que ’identifica’ el
o ´
servicio. El servicio principal podr´ deisparar sus eventos personalizados con una diıa
recci´n que corresponda al servicio que se debe activar para la llamada.
o](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-130-320.jpg)
![´
CAP´
ITULO 9. MEJORES PRACTICAS
108
9.4.2.
Granularidad SBB para manejo de llamadas
¿Cu´ndo ser´ adecuado instanciar un SBB por cada llamada y cu´ndo usar el misa
a
a
mo SBB para procesar todas las llamadas provenientes de, digamos, un evento especial
o un contexto de actividad?
Si instancias un SBB ra´ por cada llamada basado en el identificador de la llamada,
ız
entonces puedes amortizar la autenticaci´n. La actividad en este caso se extiende a lo
o
largo de toda la llamada, y se identifica por el identificador de la llamada. Esto tambi´n
e
tendr´ sentido si est´s construyendo un componente stateless, como un servidor proxy
ıa
a
SIP.
Por otra parte, si instancias un SBB por tipo de eventos, como un SBB por INVITE
entonces b´sicamente est´s asociando el SBB con la transacci´n SIP y la entidad se
a
a
o
extiende solamente el periodo que ocupe la transacci´n. Esto tendr´ sentido si est´s
o
ıa
a
2.
construyendo un servicio stateful como un servicio IVR
De todas maneras, es una buena pregunta, y me gustar´ o´ otras opiniones.
ıa ır
Esto trae consigo varias cuestiones en la manera en que el SIP RA funcionar´.
a
Pienso que este comportamiento deber´ estardarizarse para conseguir la portabilidad
ıa
de los servicios. Actualmente s´lo hay una recomendaci´n en el SIP RA Type.
o
o
9.4.3.
Actualizando perfiles desde los SBB
Tengo curiosidad por saber la raz´n para no permitir a los SBB crear y actualizar
o
perfiles. Por ejemplo, si tuviera un servicio de telecomunicaciones que usara los perfiles
para mantener el estado de qu´ direcciones procesar y c´mo (bloquearlas, redirigirlas,
e
o
auto-reply, etc) estar´ bien poder actualizar estos perfiles desde, por ejemplo, una apliıa
caci´n J2EE pas´ndole eventos a un “servicio de actualizaci´n de perfiles” personalo
a
o
3 , pero a´n as´ me gustar´ o´
izado. Desde luego, podr´ usar un JMX adaptor MLET
ıa
u
ı
ıa ır
los motivos
La respuesta simple es que no ten´
ıamos los requisitos suficientemente bien definidos
para incluirlos en la versi´n 1.0. [7] De todas maneras ten´
o
ıamos un plan para ello, e
incluimos los m´todos set en la interfaz de los perfiles. Para proporcionar un poco m´s
e
a
de contexto, nuestra visi´n de los perfiles en el SLEE era que se entendieran como una
o
cache de los datos que se necesitara entregar para proporcionar el servicio. Sin embargo
no era la fuente de datos principal. Si permit´
ıamos actualizar los datos, eso significar´
ıa
que se convertir´ en una fuente de datos principal. Est´bamos preocupados de que
ıa
a
el SLEE se convirtiera en la fuente de datos principal, porque no quer´
ıamos imponer
al SLEE los requisitos (persistencia, consistencia, estabilidad, ...) asociados con una
fuente de datos principal. Pens´bamos que ese era el trabajo de una base de datos o
a
alg´n sistema OSS (con una base de datos) y el SLEE no se pens´ para ser un sustituto
u
o
de una base de datos o un sistema OSS. Con m´s tiempo, se podr´ haber a˜adido
a
ıan
n
algunos de estos temas a la versi´n 1.0. De todas maneras, la comunidad sent´ que no
o
ıa
merec´ la pena retrasar la versi´n 1.0 para a˜adir direcciones y mejoras en los perfiles.
ıa
o
n
2
3
Interactive Voice Response,
Management applet](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-140-320.jpg)
![´
9.4. OTRAS BUENAS PRACTICAS
109
Desde la versi´n 1.0 hemos resuelto muchas de las consideraciones anteriores como
o
parte del trabajo en la versi´n 1.1. La especificaci´n 1.1 [8] soportar´ actualizaciones
o
o
a
a los perfiles, lo que conlleva inconvenientes sobre c´mo validar los cambios (similar
o
a las clases Profile Management) y c´mo proporcionar mecanismos para exportar y
o
sincronizar las actualizaciones con la base de datos final.
9.4.4.
Prioridad de los eventos del SBB y entrega de los eventos
Si dos servicios (SBBs ra´
ıces) tienen distintas prioridades por defecto, por ejemplo:
SBB1 prioridad por defecto = 100
SBB2 prioridad por defecto = 50
Ambos eventos pueden recibir el evento e. ¿Cu´ndo obtiene el SBB2 el evento
a
e?¿Cu´ndo finaliza el manejador del SBB1 o un tiempo despu´s de que el SBB1 lo
a
e
haya recibido? Tal como yo lo veo, el SLEE s´lo procesa un evento a la vez.
o
El SBB2 recibe el evento despu´s de que el SBB1 haya acabado de procesarlo. Si
e
fuera “un tiempo despu´s” derivar´ en un comportamiento impredecible del servicio.
e
ıa
9.4.5.
¿Cu´l es el lugar correcto para inicializar los SBBs
a
con referencias a los RAs?
Mi evento tiene dos manejadores:
onEvent1() (inicial)
onEvent2()
El m´todo sbbCreate busca otro RA y guarda la referencia al proveedor en un campo
e
privado.
Cuando se dispara event1, se crea una nueva actividad y un nuevo SBB, y el SBB se
suscribe a esta actividad. El m´todo event1 entonces hace algo que deriva en la recepci´n
e
o
de event2 por el m´todo adecuado. Cuando se llama al m´todo de event2 intenta acceder
e
e
al proveedor, pero falla porque el campo contiene un campo vacio. Nunca se ha llamado
a sbbCreate en el objeto sbb.
Cuando se lee la especificaci´n 1.0 no queda totalmente claro pero parece que un
o
SBB puede transferir al estado activo y manejar un evento en este orden:
newInstance() -> set SbbContext -> _pooled -> sbbActivate()
-> _Ready -> onEventXY (no-inicial)
¿Es verdad esto?
Si lo es, ¿d´nde deber´ a˜adir funcionalidad que inicialice un objeto sbb, como un
o
ıa n
proveedor y activity context interface factory lookup? Esto puede producir excepciones,
as´ que supongo que hay que ponerlas en sbbCreate(). En el constructor las b´squedas
ı
u
no se pueden efectuar porque no est´ disponible el contexto y no permite que se lancen
a](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-141-320.jpg)
![´
CAP´
ITULO 9. MEJORES PRACTICAS
110
excepciones. Lo ultimo se aplica para el m´todo sbbActivate.
´
e
Deber´ tenerlo en dos lugares: sbbCreate/sbbPostCreate y sbbActivate. Si miras
ıas
en el diagrama de ciclos de vida (figura 5, p´gina 50 [7]), si hay alguna funci´n que
a
o
necesites ejecutar cuando un sbb cambia de Pooled a Ready, necesitas hacerlo en todos
los arcos que van de Pooled a Ready.
Te sugiero que pongas este c´digo de inicializaci´n en un m´todo y llames a este
o
o
e
m´todo desde sbbCreate/sbbPostCreate y sbbActivate.
e
9.4.6.
¿C´mo verificar si un contenedor SLEE conoce un EventTypeo
ID?
Estoy intentando implementar un RA que se pueda usar para comunicar un servidor
SLEE y un servidor J2EE.
El RA tiene los conceptos de evento y EventTypeID. Dado un EventTypeID (creado
con el nombre del evento, el distribuidor y la versi´n), ¿C´mo puedo comprobar si el
o
o
EventTypeID es v´lido?
a
Mira el cap´
ıtulo 13.6 [7] (Event Lookup Facility) o la p´gina 306 (BootstrapContext)
a
del borrador de la especificaci´n 1.1. [8] Este es un asunto que no se estandariz´ en la
o
o
versi´n 1.0. Mobicents tiene la posibilidad de integrar RA 1.1.
o
Usando la especificaci´n 1.0 no hay una manera est´ndar para comprobar si un
o
a
SLEE conoce un tipo de evento, necesitas preguntar al distribuidor del contenedor
JAIN SLEE c´mo se puede hacer eso. JAIN SLEE 1.1 te permitir´ hacerlo usando la
o
a
interfaz est´ndar EventLookupFacility.
a
9.4.7.
¿Cu´ndo se deben usar perfiles y cu´ndo persistencia EJB o
a
a
JDBC?
La presencia de los perfiles s´lo est´ garantizada en implementaciones SLEE certio
a
ficadas, de tal manera que los desarrolladores obtienen portabilidad de aplicaciones en
este ´rea. Adem´s existen otras implementaciones tecnol´gicas (p.ej.: JDBC4 , EJB, ...)
a
a
o
pero no son obligatorias y el TCK no la comprueba.
Si no se pueden usar los perfiles para proporcionar una soluci´n apropiada, y otra
o
tecnolog´ s´ se puede usar, entonces esperar´ que los desarrolladores usaran la otra
ıa ı
ıa
tecnolog´
ıa.
En casos espec´
ıficos, tambi´n esperar´ que los desarrolladores construyeran solue
ıa
ciones buscando al menos una combinaci´n de:
o
Conveniencia de la implementaci´n tecnol´gica.
o
o
Arquitectura de red para acceder a los datos (p.ej.: IMS est´ yendo a todos los
a
suscriptores de datos que est´n en el HSS)
a
4
Java Database Connectivity](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-142-320.jpg)
![´
9.4. OTRAS BUENAS PRACTICAS
9.4.8.
111
¿C´mo se manejan los eventos si no hay ning´ n
o
u
consumidor desplegado?
En caso de que un adaptador de recursos reciba un disparador de red (IDP en el
caso del SS7) este disparador se convierte en un evento y se reenv´ a los servicios
ıa
interesados (o los servicios lo recogen). Si no hay ning´n evento desplegado el evento
u
acaba en ninguna parte, es decir, que el elemento de red original que inici´ el disparador
o
puede estar a´n esperando por una respuesta que, desde luego, nunca llegar´. Entonces
u
a
la idea es invocar alg´n “m´todo manejador de eventos por defecto” en el RA que
u
e
inici´ el evento.
o
Conceptualmente no veo c´mo los JAIN SLEE est´ndar est´n tratando este asunto.
o
a
a
Pienso que los est´ndares actuales no consideran esto en absoluto. T´cnicamente, el
a
e
SLEE por s´ mismo no sabe c´mo interactuar con el RA, y por tanto no puede invocar
ı
o
ning´n m´todo de respuesta por defecto en ese RA.
u
e
¿Hay alguna posibilidad de desplegar un tipo de servicio manejador por defecto para
cada RA que se invoque s´lo si ning´n otro servicio ha consumido ese evento?
o
u
Estar´ bien conseguir dos cosas:
ıa
1. Obtener una indicaci´n de ese tipo de situaciones (una alarma).
o
2. Actuar en modo por defecto para cada RA desplegado.
Ninguna de esas cosas est´ especificada actualmente en los est´ndares. ¿Considerar´n
a
a
a
esto especificaciones futuras de JAIN SLEE?
La arquitectura RA en 1.1 [8] define que un RA que env´ un evento recibe inforıa
maci´n de vuelta sobre c´mo procesa ese evento el SLEE. Se invoca despu´s de que
o
o
e
el SLEE ha entregado el evento a cualquier SBB interesado e incluye una bandera de
estado indicando si alg´n SBB recibi´ el evento o no.
u
o
Esto significa que el RA proporciona la acci´n espec´
o
ıfica dependiente del protocolo
si ning´n servicio consumi´ ese evento. Por lo tanto, puede disparar una alarma y puede
u
o
ejecutar alguna acci´n apropiada (por ejemplo, mandar una se˜al continue+tc end ).
o
n
Creo que esto ya est´ cubierto en la versi´n 1.1.
a
o
9.4.9.
¿C´mo incluir JARs externos?
o
Tengo una pregunta sobre c´mo desplegar un servicio con un recurso externo de
o
l´gica de negocios.
o
Intento que el servicio provea una l´gica de negocio contenida en un archivo jar externo.
o
Esta l´gica de negocio se usar´ en uno de los componentes SBB. Cualquier modificaci´n
o
ıa
o
hecha en las clases incluidas en este archivo jar no deber´ implicar cambios en el
ıa
despliegue del servicio.
He incluido este archivo jar externo en un archivo jar de servicio desplegable. Sin
embargo, durante el despliegue en el servidor SLEE, las clases de esta l´gica de negocio
o
externa no est´n visibles. Obtengo el siguiente error:
a
Installation of deployable unit failed: javax.slee.management.
DeploymentException: Error(s) in deployable unit: Verification
error(s) in one or more components in sbb.jar: Verification](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-143-320.jpg)
![112
´
CAP´
ITULO 9. MEJORES PRACTICAS
error(s) in sbb component OurService? 1.0, Vendor: Cannot load
SBB abstract class class pl.vendor.jain.service.control._Sbb
nested exception:
java.lang.NoClassDefFoundError:
pl/vendor/service/database/DBInterface
¿C´mo puedo hacer las clases del archivo jar externo visibles al servicio? ¿Es posio
ble a˜adir estas clases sin descompilar al sbb.jar?
n
Si quieres referenciar clases de archivos jar externos en tu SBB, necesitas usar el
atributo Class-Path del manifiesto jar.En la secci´n 3 de la especificaci´n SLEE 1.0 se
o
o
menciona esto como inclusi´n de clases “por referencia”.
o
Por ejemplo, digamos que tu jar externo se llama “external.jar”. En el manifiesto
jar de tu jar de componente SBB, incluir´ el atributo
ıas
Class-Path
library/external.jar
entonces incluir´ el library/external.jar en la unidad desplegable de tu SBB (no en
ıas
el jar del componente del SBB). Como el classpath es una URL relativa, puedes poner
el jar externo en cualquier lugar dentro de tu unidad desplegable, siempre y cuando el
atributo Class-Path coincida con la localizaci´n en el jar de la unidad desplegable.
o
En SLEE 1.1 [8] hemos introducido un nuevo tipo de componente librer´ del
ıa,
que depender´n el resto de tipos de componente. Los componente librer´ eliminan
a
ıas
el uso del classpath del manifiesto, que no est´ particularmente bien definido y tiene
a
problemas cuando se usa en un entorno como el SLEE (en particular diferentes unidades
desplegables no pueden compartir una librer´ com´n).
ıa
u](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-144-320.jpg)
![CAP´
ITULO 10. RESOURCE ADAPTORS
136
10.4.
RA Persistence
10.4.1.
Java Persistence API
El API Java Persistence[30] o JPA, es un framework de Java que permite a los
desarrolladores administrar datos relacionales. Provee un modelo de persistencia POJO6 para mapeo de objetos relacionales, El API Java Persistence fue desarrollado por el
grupo experto de software EJB 3.0 como parte de JSR 220, pero su uso no est´ limitado
a
a componentes software EJB. Puede ser usado tambi´n directamente por aplicaciones
e
normales como web, e incluso fuera de la plataforma Java EE, por ejemplo, en aplicaciones Java SE.
El API Java Persistence consiste en tres ´reas:
a
El API, definido en el paquete javax.persistence
El Lenguaje de consulta Java Persistence (JPQL7 )
metadatos objeto/relacional
10.4.1.1.
Entidades
Una entidad Persitence es una clase Java ligera que normalmente representa una
tabla en una base de datos relacional. Las Instancias entidad corresponde a una fila
individual de la tabla. Las entidades normalmente tienen relaci´n con otras entidades, y
o
estas relaciones son expresadas a trav´s de metadatos objeto/relacional. Los metadatos
e
objeto/relacional pueden ser especificados directamente en el fichero de la clase entidad
usando anotaciones o en un fichero descriptor XML distribuido con la aplicaci´n.
o
10.4.1.2.
El lenguaje de consulta Java Persistence
The Java Persistence Query Language es usado para hacer consultas de las entidades
almacenadas en una base de datos relacional. Las consultas se parecen a la sintaxis de
las consultas SQL, pero operan con objetos entidad en vez de directamente con tablas
de la base de datos.
10.4.2.
Dise˜ o del Ra Persistence
n
JPA es adecuado para el RA, pues es una API O/R mapping rico y altamente
efectivo. El RA no tiene necesariamente que seguir un modelo dirigido a eventos. Ser´
ıa
recomendable una interfaz s´
ıncrona lo m´s cerca posible al uso de JPA. Hay otros
a
formas para las aplicaciones para desacoplar la l´gica de la persistencia en componentes
o
as´
ıncronos separada que usen un RA Persistence as´
ıncrono.
6
Plain Old Java Object, es una clase del lenguaje de programaci´n Java. Este nombre se les da a
o
las clases que no son de alg´n tipo especial (EJBs, Java Beans, etc) y no cumplen ning´n otro rol ni
u
u
implementan alguna interfaz especial.
7
Java Persistence Query Language](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-168-320.jpg)
![CAP´
ITULO 10. RESOURCE ADAPTORS
142
JAIN SIP v1.0
RFC 2543[32] Soportado.
J2SE 1.3 o superior.
Transacciones referenciadas por long.
El estado de la transacci´n no es
o
visible a la aplicaci´n.
o
No tiene soporte de di´logo
a
expl´
ıcito.
La configuraci´n de la pila no est´
o
a
definida.
JAIN SIP v1.1
RFC 3261[34] Soportado.
J2SE 1.4 o superior.
Interfaces de las transacciones definidas.
El estado de la transacci´n/di´logo puede
o
a
ser le´ por la aplicaci´n.
ıdo
o
La Interfaz del di´logo definida y
a
manejada por la pila.
La pila est´ configurada con propiedades
a
definidas
´
Tabla 10.4: Ultimas actualizaciones de la especificaci´n
o
10.5.2.3.1. Funcionalidad JAIN SIP JAIN SIP soporta la funcionalidad del protocolo SIP descrita en RFC 3261 [34].
JAIN SIP tiene las siguientes extensiones SIP;
- RFC12 2976 [33] permite al transportador de sesiones relacionar el control de informaci´n que es generado durante la sesi´n.
o
o
- RFC 3262 [35] proporciona informaci´n del progreso del proceso de la petici´n.
o
o
- RFC 3265 [37] la habilidad de responder notificaciones as´
ıncronas de eventos.
- RFC 3311 [38] permite al que llama o es llamado para proporcionar informaci´n de
o
la sesi´n actualizada antes de una respuesta final.
o
- RFC 3326 [39] la habilidad para saber porqu´ una petici´n SIP fue expedida.
e
o
- RFC 3428 [40] permite transferir mensajes instant´neos.
a
- RFC 3515 [41] solicita que el recipiente se refiera a un recurso dado en la petici´n.
o
Interfaz SipStack
Administra puntos de escucha y proveedores.
SipStack asociado con la direcci´n IP.
o
- Puede tener m´ltiples puntos de escucha.
u
La aplicaci´n puede tener multiples SipStacks.
o
No puede ser borrado una vez creado.
12
Request for Comments. Es un documento cuyo contenido es una propuesta oficial para un nuevo
protocolo de la red Internet, que se explica con todo detalle para que en caso de ser aceptado pueda
ser implementado sin ambig¨edades.
u](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-174-320.jpg)
![CAP´
ITULO 10. RESOURCE ADAPTORS
148
Un Request-URI que indica al usuario o servicio a quien est´ dirigido la
a
petici´n.
o
Una frase razonable que est´ destinada al usuario humano.
a
Los Mensajes podr´ contener multiples Headers del mismo tipo.
ıan
- Los Headers de un tipo dado junto a un mensaje es significativo. Por ejemplo. Headers
que son hop-by-hop deben aparecer antes que ning´n otro Header que sea endu
to-end.
El cuerpo del mensaje pondr´ la descripci´n de la sesi´n.
ıa
o
o
- JAIN SIP define este formato en un objeto que permite al cuerpo ser un String o un
objeto tipado defino por la especificaci´n JSR14 del Protocolo de Descripci´n de
o
o
la Sesi´n (SDP)15 y tambi´n un byte array.
o
e
Tipos de mensajes de peticiones
INVITE
- Permite invitar un usuario o servicio para participar en una sesi´n o para modo
ificar par´metros en una sesi´n ya existente.
a
o
BYE
- Termina la participaci´n de un cliente en una sesi´n. Confirma el establecimieno
o
to de una sesi´n.
o
CANCEL
- Termina una transacci´n.
o
OPTIONS
- Solicita informaci´n a un participante sobre sus capacidades media.
o
ACK16
- Por seguridad y aceptaci´n de la llamada (negociaci´n en tres pasos)
o
o
REGISTER
- Informa a un servidor SIP sobre la localizaci´n del User Agent.
o
INFO
14
Java Specification Request. Son documentos oficiales que describn especificaciones y tecnolog´
ıas
propuestas para ser a˜adidas a la plataforma Java.
n
15
Session Description Protocol. Es un formato para describir los pr´metros de la inicializaci´n del
a
o
streaming media. Fu´ publicado por el IETF como RFC 4566[45]
e
16
Acknowledge. Reconocimiento](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-180-320.jpg)
![10.5. RA SIP
149
- Informaci´n de control relacionada con la sesi´n generada durante una sesi´n
o
o
o
factory.
PRACK17
- Por seguridad de respuestas provisionales.
UPDATE[38]
- Actualiza una sesi´n sin impactar en el estado del di´logo.
o
a
SUBSCRIBE[37]
- Notificaci´n request de un nodo cuando ocurren ciertos eventos.
o
NOTIFY[37]
- Notificaci´n de un nodo remoto cuando ocurren ciertos eventos.
o
MESSAGE
- Para enviar mensajes instant´neos.
a
REFER[41]
- Remite a un recurso provisto en la petici´n.
o
Ejemplo real de mensaje del m´todo REGISTER:
e
Via: SIP/2.0/UDP 192.168.0.100:5060;rport;
branch=z9hG4bK646464100000000b43c52d6c00000d1200000f03
Content-Length: 0 Contact: <sip:20000@192.168.0.100:5060> Call-ID:
ED9A8038-A29D-40AB-95B1-0F5F5E905574@192.168.0.100 CSeq: 36 REGISTER
From:<sip:20000@192.168.0.101>;tag=910033437093 Max-Forwards: 70
To: <sip:20000@192.168.0.101> User-Agent:
SJphone/1.60.289a (SJ Labs) Authorization: Digest
username="20000",realm="192.168.0.101",
nonce="43c52e9d29317c0bf1f885b9aaff1522d93c7692",
uri="192.168.0.101",
response="f69463b8d3efdb87c388efa9be1a1e63"
Responses Respuestas cliente/servidor a las peticiones (C´digos de estado)
o
1xx: Tipo Informativo.
- 100 Trying (Indica intentando la llamada)
- 180 Ringing (Indica que suena el UA que se llama)
- 181 Call is being forwarded (Indica que la llamada es desviada)
- 182 Queued (LLamada encolada)
17
Provisional acknowledgement. Reconocimiento provisional](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-181-320.jpg)
![10.5. RA SIP
153
response="f69463b8d3efdb87c388efa9be1a1e63"
10.5.2.4.2. Headers Las cabeceras se utilizan para transportar informaci´n neceo
saria a las entidades SIP. Las cabeceras SIP son similares a las los campos de cabecera
de HTTP o SMTP en su sintaxis y sem´ntica.
a
JAIN SIP modela cada cabecera SIP como una interfaz espec´
ıfica de manera opuesta
a tener un sola interfaz gen´rica para manejar toda la informaci´n de la cabecera.
e
o
- Cada interfaz especifica los par´metros admisibles por la cabecera.
a
- Soporte de protocolo m´s expl´
a
ıcito - Analizando el soporte de cada cabecera.
JAIN SIP soporta todas las cabeceras definidas en RFC 3261[34] y otras cabeceras
introducidas por el soporte de los siguientes RFCs adicionales:
- RFC 3262[35] - RAckHeader y RSeqHeaders para la entrega de confianza de respuestas provisionales.
- RFC 3265[37] - AllowEventsHeader, EventHeader y SubscriptionStateHeader para
soportar el framework de notificaci´n de eventos.
o
- RFC 3326[39] - ReasonHeader para apoyarse la informaci´n en porqu´ la petici´n fue
o
e
o
emitida.
- RFC 3515[41] - ReferToHeader para soportar recipientes que remiten peticiones a
otro recurso.
- Via: Indica el transporte usado para el env´ e identifica la ruta del request, por ello
ıo
cada proxy a˜ade una l´
n
ınea a este campo.
- From: Indica la direcci´n del origen de la petici´n.
o
o
- To: Indica la direcci´n del destinatario de la petici´n.
o
o
- Call-Id: Identificador unico para cada llamada y contiene la direcci´n del host. Debe
´
o
ser igual para todos los mensajes dentro de una transacci´n.
o
- Cseq: Se inicia con un n´mero aleatorio e identifica de forma secuencial cada petici´n.
u
o
- Contact : Contiene una (o m´s) direcci´n que pueden ser usada para contactar con
a
o
el usuario.
- User Agent: Contiene el cliente agente que realiza la comunicaci´n.
o
Message Header Via: SIP/2.0/UDP
192.168.0.100:5060;rport;
branch=z9hG4bK646464100000007343c52679000020a600000e45
Content-Length: 0 Call-ID:
911D32E5-EEDF-4572-B0B2-61B294636E88@192.168.0.100 CSeq:
1 ACK From: "Prueba"<sip:20000@miasterisk.com>;](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-185-320.jpg)
![154
CAP´
ITULO 10. RESOURCE ADAPTORS
tag=8922404614682 Max-Forwards: 70 Route:
<sip:20001@192.168.0.1> To:
<sip:20001@miasterisk.com>;tag=as0a27b928
User-Agent: SJphone/1.60.289a
(SJ Labs) Contact:
<sip:20100@192.168.0.100:5060>;expires=3600
10.5.2.4.3. Addressing Una de las funciones de los servidores SIP es la localizaci´n de los usuarios y resoluci´n de nombres. Normalmente, el agente de usuario no
o
o
conoce la direcci´n IP del destinatario de la llamada, sino su e-mail.
o
Las entidades SIP identifican a un usuario con las SIP URI (Uniform Resource
Identifiers) definido en el RFC 2396[31]. Una SIP URI tiene un formato similar al del
e-mail, consta de un usuario y un dominio delimitado por una @, como muestran los
siguientes casos:
usuario@dominio, donde dominio es un nombre de dominio completo.
usuario@equipo, donde equipo es el nombre de la m´quina.
a
usuario@direcci´n ip, donde direcci´n ip es la direcci´n IP del dispositivo.
o
o
o
n´mero tel´fono@gateway, donde el gateway permite acceder al n´mero de tel´fono
u
e
u
e
a trav´s de la red telef´nica p´blica.
e
o
u
La soluci´n de identificaci´n de SIP, tambi´n puede ser basada en el DNS descrito en
o
o
e
el RFC 3263[36], donde se describen los procedimientos DNS utilizados por los clientes
para traducir una SIP URI en una direcci´n IP, puerta y protocolo de transporte
o
utilizado, o por los servidores para retornar una respuesta al cliente en caso de que la
petici´n falle.
o
10.5.2.4.4. Session Description Protocol (SDP) El protocolo SDP (Session
Description Protocol) RFC 4566[45] se utiliza para describir sesiones multicast en tiempo real, siendo util para invitaciones, anuncios, y cualquier otra forma de inicio de
´
sesiones.
La propuesta original de SDP fue dise˜ada para anunciar informaci´n necesaria
n
o
para los participantes y para aplicaciones de multicast MBONE (Multicast Backbone).
Actualmente, su uso est´ extendido para el anuncio y la negociaci´n de las capacidades
a
o
de una sesi´n multimedia en Internet.
o
Puesto que SDP es un protocolo de descripci´n, los mensajes SDP se pueden transo
portar mediante distintos protocolos con SIP, SAP, RTSP, correo electr´nico con aplio
caciones MIME o protocolos como HTTP. Como el SIP, el SDP utiliza la codificaci´n
o
del texto. Un mensaje del SDP se compone de una serie de l´
ıneas, denominados campos,
donde los nombres son abreviados por una sola letra, y est´ en un orden requerido para
a
simplificar el an´lisis. El SDP no fue dise˜ado para ser f´cilmente extensible.
a
n
a
La unica manera de ampliar o de agregar nuevas capacidades al SDP es definir un
´
nuevo atributo. Sin embargo, los atributos desconocidos pueden ser ignorados. En la
tabla siguiente podemos observar todos los campos.](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-186-320.jpg)
![CAP´
ITULO 10. RESOURCE ADAPTORS
166
para restringir el uso de in-dialog INVITEs si fuera necesario). De esta manera el c´digo
o
del sbb ser´ simplificado y el programador tendr´ que preocuparse menos de ´stos. Esa
a
e
to puede conseguirse a˜adiendo al sbb-jar.xml una definici´n de manejador de eventos
n
o
como el siguiente:
<event event-direction=’’Receive’’ initial-event=’’True’’>
<event-name>InDialogInvite</event-name>
<event-type-ref>
<event-type-name>
javax.sip.dialog.Request.INVITE
</event-type-name>
<event-type-vendor>net.java</event-type-vendor>
<event-type-version>1.2</event-type-version>
</event-type-ref>
....
</event>
Esto notificar´ al RA que nos gustar´ usar di´logos. El RA enviar´ autom´ticaa
ıa
a
a
a
mente 200 response al INVITE Request recibido, con el generado toTag para realizar
todos los prerrequisitos para crear un di´logo v´lido. Sin embargo si la aplicaci´n quiere
a
a
o
usar di´logos pero no est´ interesado en indialog re-INVITEs(por ejemplo Session
a
a
Timers del rfc 4028[44]) puede seguir el escenario mencionado arriba. Esto es hecho
solo para peticiones entrantes. Si la aplicaci´n local va a usar di´logos tiene que seguir
o
a
el escenario de arriba.
10.5.3.9.
Respuestas
Esta categor´ es la misma el Type RA JAIN SIP 1.1 y todos los eventos son
ıa
entregados en un client transaction activities. Las aplicaciones que no usen di´logos
a
relacionados s´lo para esta categor´ por eventos causados por mensajes de respuesta
o
ıa
sip (esto es aclarado m´s abajo).
a
Las aplicaciones que quieren usar el soporte del di´logo deben obtener un di´logo
a
a
antes de que sea enviado una petici´n de creaci´n de di´logo (Mirar la documentaci´n
o
o
a
o
de JAIN SIP 1.2).](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-198-320.jpg)
![CAP´
ITULO 10. RESOURCE ADAPTORS
172
10.6.1.1.
SMPP API ver 3.4
Comandos soportados:
BIND - Iniciado por el cliente
UNBIND - Iniciado por el cliente o el server
SUBMIT SM - Iniciado por el cliente(utilizado para enviar el mensaje)
DELIVER SM - Iniciado por el server (Reporte de entregas)
ENQUIRE LINK - Iniciado por el cliente.
Detalles de la conexion:
systemid = [ systemid provided to you ]
password = [ password provided to you]
systemtype = [ null or “VMA“]
IP = XXX.XXX.XXX.XXX
Port = XXXX
Formato de reporte de Entrega
id:<message_id> sub:<message_sub> dlvrd:<message_dlvrd>
submit date:<message_submit_date>
done date:<message_done_date>stat:<message_stat> err:<message_err>
Estado de los mensajes (message stat)
DLIVRD, EXPIRED, DELETED, UNDELIV, ACCEPTD, UNKNOWN, REJECTD
10.6.2.
SMPP Resource Adaptor
El Adaptador de Recursos SMPP adopta SMSC a los requerimientos del SLEE y
construye en lo alto de la implementaci´n del SMPP. El c´digo fuente para el coraz´n
o
o
o
de la implementaci´n de la pila del SMPP puede ser encontrada en sourceforge . El
o
c´digo fuente de la implementaci´n del RA en java.net.
o
o
EL RA SMPP define los siguientes conceptos del adaptador de recursos.
10.6.2.1.
10.6.2.1.1.
SMPP Resource Adaptor Type
Identificador del Resource adaptor type .
El nombre del resource adaptor type es ”SMPPResourceAdaptor”. El vendedor del
resource adaptor type es ”net.java”. La versi´n del resource adaptor type es la ”3.4”.
o](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-204-320.jpg)
![CAP´
ITULO 10. RESOURCE ADAPTORS
182
Aplicaciones de Diameter
Aplicaciones NASREQ
Aplicaciones IPv4 para moviles
Aplicaciones EAP
Aplicaciones de Control de Credito
Aplicaciones ·GPP
10.9.2.
Mobicents y Diameter
Actualmente Mobicents posee un Diameter RA para utilizarlo con JSLEE, viendo
las opciones que da este RA y comprobando que esta mucho m´s orientado al mundo
a
de la IP, descartar´ su uso en el proyecto. Cabe decir que el uso de este RA ser´
ıa
ıa
conveniente a la hora de necesitar autentificaciones fiables as´ como un buen conducto
ı
para establecer sesiones P2P.
10.9.2.1.
Descripci´n del protocolo
o
La base del protocolo de Diameter est´ definida por el RFC 3588 [?], y define los
a
requerimientos m´
ınimos para un protocolo AAA. Las aplicaciones Diameter pueden extender la base del protocolo, a˜adiendo nuevos comandos y/o atributos. Una aplicaci´n
n
o
no es un programa, sino un protocolo basado en Diameter. La seguridad de Diameter
est´ dada por IPSEC o TLS, ambos protocolos seguros.
a
10.9.2.2.
Comandos
Cada comando est´ asignado a un c´digo, que es usado por las peticiones y las
a
o
respuestas.
A continuaci´n viene una breve descripci´n de cada evento:
o
o
Abort-Session-Request: Puede ser enviado por cualquier servidor al dispositivo de
acceso que provee del servicio de sesiones, para pedir que la la sesi´n identificada
o
por Session-ID sea parada.
Abort-Session-Answer: Es enviado en respuesta a ASR. El resultado determina si
la sesi´n se ha terminado correctamente
o
Accounting-Request: Se env´ por uno nodo Diameter, act´a como un cliente, de
ıa
u
forma para intercambiar informaci´n de cuentas con otro.
o
Accounting-Answer:Se usa para aceptar un comando ACR](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-214-320.jpg)
![´
11.2. PROXIMAS MEJORAS DE MOBICENTS
187
proyectos y administrar las dependencias entre ellos. Esto es necesario ya que el
c´digo b´sico del CVS principal continua creciendo y tiene que dividirse en subo
a
proyectos. Como estan haciendo eso, la contrucci´n contin´a y ejecutar la suite
o
u
de pruebas deber´ continuar para trabajar efectivamente a lo largo de todos los
ıa
proyectos.
Nombre de la Tarea
Prioridad
Standardize SIP RA Type
Mediana
HA Testing Framework
Alta
More robust SIP RA failover
Alta
Mobicents Design Document
Mediana
SLEE-STONE Performance
test suite
Distributed Transactional
Deployment
Performance tuning and
bottleneck Identification
Concurrency Test Cases
Mediana
Mobicents Programmers Guide
Alta
Alta
Alta
No asignado
Baja
Conocimientos
necesarios
SLEE
Dificultad
SLEE, JBOSS
y J2EE
JAIN SIP, SLEE,
JBOSS y J2EE
UML,
“MagicDraw”
SLEE
Muy dif´
ıcil
SLEE JBOSS
y J2EE
Performance
tuning
Muy dif´
ıcil
SLEE
HA Cluster Management
Mediana
Eclipslee enhancements
Mediana
SLEE, JBOSS,
HA y J2EE
Eclipse y SLEE
Online Profiling
Mediana
SLEE kernel
Container Portability
Mediana
Mediana
Maven ANT
Dif´
ıcil
Normal
Mediana
Dif´
ıcil
Normal
SLEE y J2EE
One top level build system that
manages all projects
F´cil
a
Normal/
dif´
ıcil
Dif´
ıcil
Muy dif´
ıcil
Dif´
ıcil
Normal
Esfuerzo
aproximado
2 Personas,
semanas +
JSR Process
6 personas,
meses
2 personas,
meses
2 personas,
meses
3 personas,
meses
4 personas,
meses
2 personas,
meses
3 personas,
meses
4 personas,
meses
6 personas,
meses
6 personas,
meses
3 personas,
meses
3 personas,
semanas
Tabla 11.1: Detalles de las tareas
Desde el foro de de Contribuyentes de Mobicentes [15] puedes encontrar m´s infora
maci´n y formar parte del dise˜o de subproyectos.
o
n
11.2.
Pr´ximas mejoras de Mobicents
o
Career grade 1.0 GA release est´ pr´ximo.
a o
Caracter´
ısticas de disponibilidad m´s altas .
a
Mejorar los Resource Adaptors existentes y a˜adir nuevos para Media, Federated
n
Identity Management, Google Talk/Jingle, more SS7 protocols, Billing.
Administraci´n de tiempo de producci´n y herramientas de monitorizaci´n.
o
o
o
Creaci´n de servicios aumentados y otras herramientas de desarrollo.
o](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-219-320.jpg)
![217
Profile
Name
Jose
Pedro
Carlos
Javier
Profile Table Name: Controller
Blocked Addresses
Backup
(Address[ ])
SIP:sip
carlos@nist.gov
null
javier@nist.gov
pedro@nist.gov
null
null
carlos@nist.gov
null
jose@nist.gov
javier@nist.gov
null
null
Called User
(Address)
SIP:sip
jose@nist.gov
Voice
Mail
State
true
Advertising
true
true
false
true
true
true
true
Tabla 15.1: Tabla perfiles
Esta tabla de perfiles es creada usando el script zcontrollerprofile-deploy.bsh (callcontroller) o zCallControl-deploy.bsh (call-controller2) que es tambi´n usado para dee
splegar la aplicaci´n.
o
Lo ideal ser´ usar un servidor LDAP1 desde el que obtendr´ toda la informaci´n
ıa
ıas
o
recogida en los perfiles. Debido a las complicaciones, se utilizar´ MySQL
a
Vas a necesitar dos clientes SIP. Puedes instalar el msn messenger y SJphone si vas
a usar un solo ordenador . Por ejemplo:la direcci´n del cliente messenger ser´
o
a
“sip:jose@nist.gov “ y la direcci´n del cliente SJphone ser´ “sip:pedro@nist.gov “. Adem´s,
o
a
a
tendr´s que cambiar uno de los nombres del cliente para probar todas las posibilidades.
a
Despu´s de ejecutar ambos clientes vamos a ver algunos casos:
e
15.0.2.
Blocking
Si haces una llamada desde “sip:carlos@nist.gov “ o ‘sip:javier@nist.gov “
a “sip:jose@nist.gov “, recibir´s un mensaje FORBIDDEN. Estos es porque ha sido
a
creado un perfil para “jose“ en la que ambos clientes est´n bloqueados.
a
15.0.3.
Forwarding
Si haces una llamada desde “sip:pedro@nist.gov “ a “sip:carlos@nist.gov “, y “carlos“
no se encuentra disponible, esta llamada ser´ redirigida a “sip:jose@nist.gov “ debido
a
al echo de que “carlos“ como podr´s ver en la tabla de perfiles tiene la direcci´n
a
o
“sip:jose@nist.gov “ como direcci´n backup.
o
Nota: Obviamente si llamas directamente a “carlos“,y este se encuentra disponible,
la llamada ser´ procesada sin ninguna redirecci´n.
a
o
1
Lightweight Directory Access Protocol. Es un protocolo a nivel de aplicaci´n que permite el acceso
o
a un servicio de directorio ordenado y distribuido para buscar diversa informaci´n en un entorno de
o
red.](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-249-320.jpg)
![˜
CAP´
ITULO 16. DISENO
222
Figura 16.2: Slee Graph Viewer.
16.1.
Sbb design
Introducci´n te´rica seg´n lo considerado en using Shared ACI Attributes. En
o
o
u
este caso vamos a tener cuatro servicios independientes. Cada servicio(CallBlocking,
CallForwarding, VoiceMail y FreeCalls) recibir´n los el mismo evento y lo procesar´n
a
a
o no har´n nada, de acuerdo a lo que los servicios m´s altos en la cadena de entrega
a
a
hicieron. Un servicio es considerado m´s alto en la cadena cuando su prioridad de
a
entrega es m´s alta. La prioridad tiene que estar en un rango de [127, -128]. Sin
a
embargo otros servicios pueden ser insertados en una cadena de servicios entre estos
cuatro ya mencionados. Como puede ser alcanzado se ver´ m´s claro despu´s de usar
a a
e
Using Shared ACI Attributes is explained. (](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-254-320.jpg)
![16.2. CALL CONTROL SERVICES.
227
La carga de perfiles se realiza mediante el siguiente procedimiento que se encuentra
en dentro de SubscriptionProfileSbb.java:
Listado 16.7: Preparar el endpoint
public void n e w P r o f i l e ( S t r i n g p r o f i l e T a b l e N a m e , S t r i n g p r o f i l e N a m e ,
S t r i n g c a l l e e , Address [ ] block , Address backup , boolean s t a t e ,
boolean s t a t e 2 , f l o a t i n i t i a l B i l l )
throws E x c e p t i o n {
H a s h t a b l e env = new H a s h t a b l e ( ) ;
env . put ( ” j a v a . naming . f a c t o r y . i n i t i a l ” ,
” o r g . jnp . i n t e r f a c e s . NamingContextFactory ” ) ;
env . put ( ” j a v a . naming . p r o v i d e r . u r l ” ,
” jnp : / / l o c a l h o s t : 1 0 9 9 ” ) ;
env . put ( ” j a v a . naming . f a c t o r y . u r l . pkgs ” ,
” o r g . j b o s s . naming : o r g . jnp . i n t e r f a c e s ” ) ;
RMIAdaptor a da p t o r =(RMIAdaptor )
new I n i t i a l C o n t e x t ( env ) . lookup ( ”jmx/ rmi /RMIAdaptor” ) ; ;
S l e e B e a n S h e l l U t i l s l e e = new S l e e B e a n S h e l l U t i l ( ) ;
Address u s e r A d d r e s s = null ;
Address [ ] b l o c k e d A d d r e s s e s = new Address [ 2 ] ;
Address backupAddress = null ;
ObjectName p r o f i l e O b j e c t N a m e = ( ObjectName )
s l e e . c r e a t e P r o f i l e ( profileTableName , profileName ) ;
System . out . p r i n t l n ( ” *** A d d r e s s P r o f i l e ” + p r o f i l e N a m e +
” created : ” + profileObjectName ) ;
i f ( ! ( Boolean ) a d a p t o r . g e t A t t r i b u t e ( p r o f i l e O b j e c t N a m e ,
” ProfileWriteable ” )) {
Object [ ] o = new Object [ ] { } ;
a d a pt o r . i n v o k e ( p r o f i l e O b j e c t N a m e , ” e d i t P r o f i l e ” ,
o , new S t r i n g [ ] { } ) ;
System . out . p r i n t l n ( ” *** Configurando e l p e r f i l . ” ) ;
} else {
System . out . p r i n t l n ( ” ********* P r o f i l e e s e d i t a b l e . ” ) ;
}
// S e t t i n g and Committing
u s e r A d d r e s s = new Address ( AddressPlan . SIP , c a l l e e ) ;
A t t r i b u t e u s e r A t t r = new
A t t r i b u t e ( ” UserAddress ” , u s e r A d d r e s s ) ;
A t t r i b u t e b l o c k e d A t t r = new
Attribute ( ” BlockedAddresses ” , block ) ;
A t t r i b u t e backupAttr = new
A t t r i b u t e ( ” BackupAddress ” , backup ) ;
A t t r i b u t e v o i c e m a i l A t t r = new
Attribute (” VoicemailState ” , state ) ;
A t t r i b u t e a d v e r t i s i n g A t t r = new
Attribute (” AdvertisingState ” , state2 ) ;](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-260-320.jpg)
![˜
CAP´
ITULO 16. DISENO
228
A t t r i b u t e b i l l A t t r = new
Attribute (” B i l l ” , i n i t i a l B i l l ) ;
a d a pt o r .
a d a pt o r .
a d a pt o r .
a d a pt o r .
a d a pt o r .
a d a pt o r .
s e t A t t r i b u t e ( profileObjectName
s e t A t t r i b u t e ( profileObjectName
s e t A t t r i b u t e ( profileObjectName
s e t A t t r i b u t e ( profileObjectName
s e t A t t r i b u t e ( profileObjectName
s e t A t t r i b u t e ( profileObjectName
,
,
,
,
,
,
userAttr ) ;
blockedAttr ) ;
backupAttr ) ;
voicemailAttr ) ;
advertisingAttr );
billAttr );
System . out . p r i n t l n ( ” *** M o d i f i c a c i ´ n t o d a v´a
o
ı
no r e a l i z a d a . ” ) ;
a d a pt o r . i n v o k e ( p r o f i l e O b j e c t N a m e , ” c o m m i t P r o f i l e ” ,
new Object [ ] { } ,new S t r i n g [ ] { } ) ;
System . out . p r i n t l n ( ” *** M o d i f i c a c i ´ n r e a l i z a d a . ” ) ;
o
}
El evento para manejar el Registro, se define en el sbb-jar.xml, de la siguiente forma:
Listado 16.8: Preparar el endpoint
<e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True">
<event−name>R e g i s t e r</ event−name>
<event−type−r e f>
<event−type−name>j a v a x . s i p . message . Request . REGISTER
</ event−type−name>
<event−type−vendor>j a v a x . s i p</ event−type−vendor>
<event−type−version>1 . 1</ event−type−version>
</ event−type−r e f>
< i n i t i a l −event−s e l e c t o r −method−name>c a l l I D S e l e c t
</ i n i t i a l −event−s e l e c t o r −method−name>
</ e v e n t>](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-261-320.jpg)
![16.2. CALL CONTROL SERVICES.
La l´gica dentro de onRegister, es la siguiente:
o
Listado 16.9: Preparar el endpoint
public void o n R e g i s t e r ( j a v a x . s i p . RequestEvent event ,
PHandleSbbActivityContextInterface localAci ) {
Request r e q u e s t = e v e n t . g e t R e q u e s t ( ) ;
try {
l o c a l A c i . detach ( this . getSbbLocalObject ( ) ) ;
// Obtengo l a d i r e c c i ´ n URI d e l l l a m a d o r
o
FromHeader fromHeader = ( FromHeader )
r e q u e s t . getHeader ( FromHeader .NAME) ;
// From URI
URI fromURI = fromHeader . g e t A d d r e s s ( ) . getURI ( ) ;
// El p u e r t o no s e usa en e l p r o f i l e
( ( SipURI ) fromURI ) . removePort ( ) ;
// Compruebo que no e s t e r e g i s t r a d o ya
i f ( ! i s R e g i s t e r ( fromURI . t o S t r i n g ( ) ) )
{
//Comprobamos que e x i s t e e l u s u a r i o en l a b a s e de d a t o s
boolean e x i s t A=e x i s t i n g U s e r ( fromURI . t o S t r i n g ( ) ) ;
i f ( existA )
{
// Obtenemos l o s d a t o s d e l p e r f i l
S t r i n g [ ] Campos=g e t U s e r ( fromURI . t o S t r i n g ( ) ) ;
// Obtenemos l a d i r e c c i ´ n de f o r w a r d i n g
o
Address Backup ;
i f ( Campos [ 1 ] ! = ” ” )
{
Backup=new Address ( AddressPlan . SIP , Campos [ 1 ] ) ;
}
else
{
Backup=null ;
}
//Comprobamos que e s t a s u b s c r i t o a a d v e r t i s i n g
boolean adv ;
i f ( Campos[2]== ” t r u e ” )
{
adv=true ;
}
else
{
adv=f a l s e ;
}
229](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-262-320.jpg)
![˜
CAP´
ITULO 16. DISENO
230
//Comprobamos s i e s t a s u b s c r i t o a V o i c e m a i l
boolean voicem ;
i f ( Campos[3]== ” t r u e ” )
{
voicem=true ;
}
else
{
voicem=f a l s e ;
}
// Formateamos e l nombre de manera adecuada
S t r i n g [ ] nombre= Campos [ 0 ] . s u b s t r i n g ( 4 ) . s p l i t ( ”@” ) ;
// Averiguamos l a s d i r e c c i o n e s b l o q u e a d a s
S t r i n g [ ] B l o c k s=b l o c k i n g s ( Campos [ 0 ] ) ;
i f ( B l o c k s != null )
{
// Pasamos l a s d i r e c c i o n e s b l o q u e a d a s a l formato c o r r e c t o
int l e n=B l o c k s . l e n g t h ;
l o g . i n f o ( ” l o n g i t u d ”+l e n ) ;
Address [ ] b l o c k A d d r e s s=null ;
for ( int i =0; i <l e n ; i ++)
{
b l o c k A d d r e s s [ i ]=new Address ( AddressPlan . SIP ,
Blocks [ i ] ) ;
}
// Cargamos e l p e r f i l con d i r e c c i o n e s de b l o q u e o
n e w P r o f i l e ( ” C a l l C o n t r o l ” , nombre [ 0 ] , Campos [ 0 ] ,
bl oc kA ddr e s s , Backup , voicem , adv , 0 ) ;
}
else
{
// Cargamos e l p e r f i l s i n d i r e c c i o n e s de b l o q u e o
n e w P r o f i l e ( ” C a l l C o n t r o l ” , nombre [ 0 ] , Campos [ 0 ] ,
null , Backup , voicem , adv , 0 ) ;
}
}
else
{
// N o t i f i c a m o s a l l l a m a d o r que no s e e n c u e n t r a r e g i s t r a d o
ServerTransaction stRegister = ( ServerTransaction )
localAci . getActivity ( ) ;
Response r e g i s t e r R e s p o n s e = g e t M e s s a g e F a c t o r y ( ) .
c r e a t e R e s p o n s e ( Response .UNAUTHORIZED, r e q u e s t ) ;
s t R e g i s t e r . sendResponse ( r e g i s t e r R e s p o n s e ) ;
}
}
} catch . . . .](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-263-320.jpg)
![˜
CAP´
ITULO 16. DISENO
236
Listado 16.14: Preparar la conexi´n
o
public void onRingningEvent ( RequestEvent event ,
ActivityContextInterface aci ) {
....
C o n n e c t i o n D e s c r i p t o r d e s c = new C o n n e c t i o n D e s c r i p t o r ( sdp ) ;
try {
createConnection . setRemoteConnectionDescriptor ( desc ) ;
} catch ( C o n f l i c t i n g P a r a m e t e r E x c e p t i o n e ) {
// no t e n d r´a que p a s a r nunca
ı
}
EventName eventName = new EventName ( PackageName . Announcement ,
MgcpEvent . ann . withParm ( ” h t t p : / / u s e r . domain . com
/ P u b l i c i d a d . wav” ) ) ;
RequestedEvent e v e n t = new RequestedEvent ( eventName ,
new RequestedAc tion [ ]
{ RequestedAc t ion . N o t i f y I m m e d i a t e l y } ) ;
NotificationRequestParms request =
new N o t i f i c a t i o n R e q u e s t P a r m s (
new R e q u e s t I d e n t i f i e r (
I n t e g e r . t o S t r i n g (GEN++)));
r e q u e s t . s e t R e q u e s t e d E v e n t s (new RequestedEvent [ ] { e v e n t } ) ;
createConnection . setNotificationRequestParms ( request ) ;
JainMgcpProvider p r o v i d e r = ( JainMgcpProvider )
c o n t e x t . lookup ( ” s l e e / r e s o u r c e s /mgcp/ f a c t o r y p r o v i d e r ” ) ;
p r o v i d e r . send (new JainMgcpCommand [ ] { c r e a t e C o n n e c t i o n } ) ;
}
La pasarela responder´ con el mensaje CreateConnectionResponse el cual incluir´ un
a
a
nombre concreto para el endpoint adquirido por la pasarela, el identificador de la
conexi´n creada y un descriptor de session local (para esta conexi´n). Deber´
o
o
ıamos
usar este descriptor de sesi´n en el mensaje SIP SESSION PROGRESS para establecer
o
la sesi´n media.
o
Listado 16.15: Crear la conexi´n
o
public void onCreateConnectionResp ( JainMgcpResponseEvent evt ,
ActivityContextInterface aci ) {
....
CreateConnectionResponse r e s =
( CreateConnectionResponse ) evt ;
S t r i n g sdp = r e s . g e t L o c a l C o n n e c t i o n D e s c r i p t o r ( ) . t o S t r i n g ( ) ;
// h o l d e s p e c i f i c a parame tro s para f u t u r o s u s o s
Endpoint e n d p o i n t = r e s . g e t S p e c i f i c E n d p o i n t I d e n t i f i e r ( ) ;
C o n n e c t i o n I d e n t i f i e r connectionID =
res . getConnectionIdentifier ( ) ;
}](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-269-320.jpg)
![16.2. CALL CONTROL SERVICES.
237
En este momento el llamador oye la publicidad y el llamado oye el tel´fono alere
tando de una llamada. Cuando la publicidad finaliza, la pasarela enviara un mensaje
de notificaci´n (como petici´n), este evento debe ser usado para repetir la publicidad
o
o
desde el principio o enviar el ring t´
ıpico si algo falla
Listado 16.16: Volver a reproducir
public void o n N o t i f y ( JainMgcpCommandEvent evt ,
ActivityContextInterface aci ) {
....
Notify n o t i f y = ( Notify ) evt ;
eventName = n o t i f y . getObse rve dEvents ( ) [ 0 ] ;
i f ( eventName . g e t E v e n t I d e n t i f i e r ( ) . e q u a l s ( MgcpEvent . o f ) ) {
// s i f a l l a a l o i r e l a r c h i v o
// g e n e r a un mensaje R ing in
} e l s e i f ( eventName . g e t E v e n t I d e n t i f i e r ( ) .
e q u a l s ( MgcpEvent . o f ) ) {
// e n v´a N o t i f y R e q u e s t para o´ r e l a r c h i v o o t r a vez
ı
ı
EventName eventName = new EventName (
PackageName . Announcement ,
MgcpEvent . ann . withParm (
” h t t p : / / u s e r . domain . com/ p u b l i c i d a d . wav” ) ) ;
RequestedEvent e v e n t = new RequestedEvent ( eventName ,
new Reque s te dAc t ion [ ] {
Reque s te dAc t ion . N o t i f y I m m e d i a t e l y } ) ;
N o t i f i c a t i o n R e q u e s t r e q = new
N o t i f i c a t i o n R e q u e s t ( this , endpoint ,
new R e q u e s t I d e n t i f i e r (
new I n t e g e r (GEN++). t o S t r i n g ( ) ) ;
r e q . s e t R e q u e s t e d E v e n t s ( RequestedEvent [ ] { e v e n t } ) ;
p r o v i d e r . send (new JainMgcpCommandEvent [ ] { r e q } ) ;
..
}
}
Cuando el llamado responde, el SBB tiene que manejar el OK y dejar la session
media
Listado 16.17: -sbb-jar.xml
public void onOkEvent ( RequestEvent event ,
ActivityContextInterface aci ) {
....
D e l e t e C o n n e c t i o n dc = new D e l e t e C o n n e c t i o n ( this , e n d p o i n t ) ;
p r o v i d e r . send (new JainMgcpCommandEvent [ ] { dc } ) ;
}
Comentar que este c´digo no ha sido probado por la falta de tiempo para utilizar
o
el RA MGCP, ya que su versi´n funcional sali´ una semanas antes a la entrega de la
o
o
memoria.](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-270-320.jpg)
![:EL rango de default-priority est´ en [127, -128].SLEE entrega eventos a los SBB
a
de acuerdo a la prioridad.
Aunque el servicio encadenado parece bastante f´cil y nos da flexibilidad para
a
a˜adir/quitar servicios de la cadena, tambi´n nos fuerza a seguir algunas reglas. Asumn
e
iendo este escenario son como siguen:
Cada servicio es independiente.
Si un servicio es a˜adido/quitado, el c´digo fuente no es cambiado (el descriptor
n
o
xml si puede ser cambiado).
Si queremos alcanzar estos objetivos necesitamos seguir algunas reglas:
Si un servicio va a procesar un evento, tiene que fijar filteredByMe a verdadero
Si el precursor del servicio actual ha procesado el evento actual tiene que fijar
filteredByMe a verdadero
En nuestro escenario cada servicio tiene conocimiento de la acci´n realizada por su
o
precursor. El servicio actual no sabe que precursor de sus precursores lo ha echo.](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-283-320.jpg)
![Conclusiones y Recomendaciones
Actualmente los Application Servers para aplicaciones Telco son contenedores J2EE
modificados para soportar eventos as´
ıncronos, como es el caso de los AS WebLogic Server (BEA), JBoss (Red Hat), WebSphere (IBM), Oracle OC4J (Oracle) y otras compa˜´ Pero estos no fueron dise˜ados para ello. El rendimiento es muy bajo, no tiene
nıas.
n
soporte para transacciones ligeras t´
ıpicas de las Telco y es poco confiable, mientras
que SLEE, si fue dise˜ado espec´
n
ıficamente para sistemas de telecomunicaciones y es
completamente as´
ıncrono. Por lo que Slee satisface mucho m´s los requerimientos para
a
las Telco que el mejor contenedor EJB.
JAIN contiene muchas de las ventajas que los operadores y proveedores de servicios
necesitan para el desarrollo de aplicaciones Telco actuales, bajo coste, calidad de servicio
y capacidad para innovar, as´ como favorecer al desarrollo de nuevos servicios para las
ı
redes actuales y futuras.
JAIN SLEE es una especificaci´n abierta y basada en est´ndares, que define como los
o
a
servicios Telco pueden construirse, manejarse y ejecutarse. Esta extiende y envuelve el
modelo de programaci´n IN con la separaci´n de un Service Switching Point y el Service
o
o
Creation Point (SSP / SCP) y estandariza el modelo de programaci´n IN situ´ndolo
o
a
dentro del entorno Java adem´s de que la especificaci´n ha sido dise˜ada expl´
a
o
n
ıcitamente
para habilitar la implementaci´n de plataformas carrier grade requeridas en entornos
o
de se˜ales de llamadas.
n
Las operadoras actuales compiten entre ellas de forma agresiva, los clientes deben
arrebat´rselos a las otras compa˜´
a
nıas, Deutsche Telekom, France Telecom y Telecom
Italia no pasan por buenos momentos[21] , por lo que ofrecen m´s servicios de ultima
a
´
generaci´n y tarifas m´s econ´micas, que son normalmente planas, por lo que estas
o
a
o
necesitan abaratar costes para la infraestructura de los servicios. A las operadoras les
interesa que estos servicios incluyan soporte y se implementen de forma vertical, para
lograr los mayores beneficios a corto plazo y m´
ınimo riesgo. Por esto la mayor´ de las
ıa
operadores tienen planes para migrar a redes All-IP en un plazo de cinco a˜os, estos
n
nuevos servicios ser´ implementados en SIP.
ıan
Con la incertidumbre que rodea la adopci´n y crecimiento de las futuras redes, Jain
o
SLEE provee de un camino evolutivo para la creaci´n de nuevos servicios. Los opero
adores y proveedores de servicios compiten por llevarse la mayor parte de los beneficios
generados por los servicios a lo largo de las actuales redes, mientras dan poca importancia a la habilidad de migrar estos servicios a redes futuras. La caracter´
ıstica que
247](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-285-320.jpg)
![posee Jain SLEE de portabilidad e independencia de la red, hace que cualquier servicio
creado en esta arquitectura para actuales redes sea f´cilmente migrable para las futuras
a
redes.
La evoluci´n de Jain SLEE vendr´ sujeta al apoyo de los operadores y proveedores
o
a
de servicios, en la actualidad tenemos a Open Cloud a la cabeza con su contenedor Rhino, JBoss con su contenedor libre Mobicents y jNetX, como vendedores de contenedores
y soluciones basadas en Jain SLEE. Estos a su vez tienen apoyo de grandes operadoras
como Vodafone, Telef´nica, Telecom Italia, etc ´ vendedores como Motorola, Siemens,
o
o
HP, IBM, Aepona, etc. Aunque el uso de esta arquitectura no haya despegado, ya se
empiezan a usar algunos servicios creados a partir de ella. Sin embargo si finalmente
se imponen los servicios SIP, JAIN SLEE ser´ demasiado complejo, y la complejidad
ıa
esta asociado normalmente con perdida de rendimiento.
Mobicents es una plataforma VoIp de c´digo abierto completamente conforme a la
o
especificaci´n Jslee 1.0. [7] distribuido bajo Licencia dual flexible [20] y con una licencia
o
comercial 8.6.1 que desde 2.400$ permite redistribuir c´digo de Mobicents con soluciones
o
propietarias as´ como ofrecer servicios online basados en Mobicents; En el campo de
ı
las telecom NGIN, Mobicents encaja como core engine de alto rendimiento para SDP e
IMS adem´s de para una gran variedad de dominios de problemas que demandan EDA.
a
Posee un considerable n´mero de RAs ya en funcionamiento, los cuales permiten que
u
cualquier fuente de eventos pueda ser programada para encauzarlos mediante estos y
as´ poder ser manejados dentro de una aplicaci´n Jain Slee.
ı
o
Las pruebas de rendimiento efectuadas en la versi´n estable 1.0.00.CR1, han dao
do muy buenos resultados, obteniendo uno rendimiento m´ximo entorno a los 1000a
1200tps. 8.4
Sin embargo las principales ventajas del contenedor Mobicents son:
Un modelo de programaci´n as´
o
ıncrono orientado a eventos
Portabilidad con otros contenedores
- Contenedores Jain Slee, gracias a los Resource Adaptors Type.
- Contenedores J2EE, por su interfaz de conexi´n JSLEE.
o
Es independiente de la red
Es portable a cualquier arquitectura
Posee entornos amigables para la administraci´n (ver anexo E) como para el
o
desarrollo de nuevos servicios (ver anexo C)
Una comunidad activa de desarrolladores, el foro del proyecto es el tercero m´s
a
activo de Java.net
La naturaleza abierta del proyecto ha generado a gran velocidad un gran n´mero
u
de documentation, mejores pr´cticas y ejemplos.
a
248](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-286-320.jpg)
![A la hora de programar con Jain SLEE y usar Mobicents, hemos encontrado muchos problemas. Hay que recalcar que es importante tener conocimientos altos de
J2EE,JBOSS adem´s de arquitectura y servicios de red inteligente y/o IMS (SIP, Parlay,
a
etc), sin estos, hemos tenido muchas dificultades para avanzar y entender los ejemplos.
Uno de los mayores problemas que afecta al posible avance de esta arquitectura
es la falta de informaci´n sobre la metodolog´ para crear nuevas aplicaciones,y la
o
ıa
gran variedad de conocimientos que hay que poseer antes de embarcarse a programar
servicios , la unica fuente sobre Jain Slee es la propia especificaci´n y algunas p´ginas
´
o
a
Wiki.
La informaci´n que ofrece la p´gina Mobicents est´ desorganizada, las explicaciones
o
a
a
y ejemplos son escasos. La gran cantidad de desarrolladores y subproyectos independientes crea una sensaci´n de caos.
o
Otro problema es el funcionamiento del foro de Mobicents users [14], en el no siempre responden adem´s de ser poco concretos. Tambi´n hay que tener en cuenta que al
a
e
ser Open Source la gente involucrada no gana nada respondi´ndote con celeridad a tus
e
cuestiones.
A pesar de todo, invitan a cualquiera a contribuir a la plataforma, para desarrollar
las tareas pendientes de la hoja de ruta 11.1, crear nuevos subproyectos nuevos que
contribuyan a la plataforma o colaborar en el dise˜o de los existentes [15], ya sean Ras,
n
herramientas de desarrollo, servicios, etc.
Hay que se˜alar que compa˜´ de investigaci´n como Gartner han comenzado a
n
nıas
o
dar cobertura a EDA. Mobicents ha sido a˜adido en el libro de Gartner “Who is who
n
in middleware” [24]
Mobicents a´n es un proyecto relativamente joven,(la primera versi´n estable sali´ el
u
o
o
25 de Junio de 2006 [25]). El despegue de mobicents, permitir´ ahorrar una gran
ıa
cantidad de dinero a las operadoras, que actualmente pagan por servicios propietarios
muy caros, que no son compatibles con futuros cambios en las redes y son dif´
ıcilmente
exportables a otras arquitecturas o lenguajes.
Por otro lado, es una opci´n arriesgada a corto plazo, pues Mobicents necesita sobre
o
todo ser probado en entornos reales Telco y la consolidaci´n de servicios, adem´s de la
o
a
dificultad de contrataci´n de un soporte profesional una vez desplegado en producci´n.
o
o
En este contexto, entendemos que pueden ocurrir las siguientes situaciones:
Mobicents es utilizado como base por alg´n integrador de sistemas para un conu
tenedor de bajo coste, sobre el que desarrollar sus servicios Telco.
Mobicents es utilizado por alg´n operador para la creaci´n de sus propios servicios
u
o
Telco.
Mobicents es explotado e integrado en alguna plataforma ya existente J2EE (por
ejemplo BEA).
249](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-287-320.jpg)
![Las soluciones posibles de las operadoras pasan por las siguientes opciones:
seguir confiando en las evoluciones propuestas por sus suminstradores de red y
en sus integraciones cada vez m´s depuradas con el mundo J2EE,
a
Utilizar las propuestas Telco que vienen del mundo IT (como los SIP AS) para los
nuevos servicios basados en IMS, y posteriormente migrar los actuales servicios
legacy a dichas plataformas, una vez asentadas.
Utilizar los contenedores jain slee actualmente existentes. Aqu´ tendr´ dos posiı
ıan
bilidades: adoptar uno comercial, o bien evolucionar mobicents para cubrir sus
necesidades concretas. Hay que destacar que, con el apoyo actual de mobicents
por parte de la industria, OpenCloud y Jnetx les llevan una ventaja sustancial
en cuanto a funcionalidad, fiabilidad y soporte, por lo que ser´ necesario un inıa
ter´s que se traduzca en inversiones bien sea de proveedores de servicios, o de
e
operadores.
A pesar de todo, es una alternativa rentable a Open Cloud y jNETX, con la ventaja
de ser open source, lo que le da estabilidad y confiabilidad, los fallos son encontrados y
resueltos r´pidamente, y las actualizaciones llegan mucho m´s r´pido. Aunque carece
a
a a
de grandes servicios y sotisficaci´n, cuenta con un equipo desarrollador activo y en
o
aumento, es extensible, cada vez aumenta la eficiencia y se a˜aden nuevos resource
n
adaptors y servicios.
Open cloud lidera actualmente los est´ndares abiertos en el middleware de Telco
a
despu´s de que Motorola y No 8 Ventures han invertido en esta 10 millones de d´lares
e
o
[18]. Ha lanzado la primera plataforma abierta verdaderamente carrier-grade para IMS
para un mercado estimado en 5.1 billones de d´lares para el 2009 [26].
o
Mobicents, a pesar de tener muchos operadores y vendedores interesados en su
plataforma, necesita una inversi´n para su desarrollo, se ha notado mucho la desvincuo
laci´n de Open Cloud del proyecto. Ahora ha empezado a ofrecer licencias comerciales,
o
si continua ofreciendo servicios, y mejorando el contenedor, y finalmente las operadoras
apuestan por Mobicentes, triunfar´. Su principal competidor ser´ Open Cloud, que
a
ıa
no descartar´ que la comprara en un futuro, pasa asegurarse el mercado est´ndares
ıa
a
abiertos en el middleware de Telco. Incluso podr´ integrarlo Bea con sus potentes conıa
tenedores J2EE para competir con Open Cloud.
Seg´n lo descrito, mobicents se puede encontrar en una encrucijada respecto a su
u
desarrollo: o bien encuentra el apoyo necesario para su evoluci´n definitiva, o bien la diso
tancia recorrida por los fabricantes de software J2EE ser´ m´
a ınima y no ser´ necesario,
a
o bien sus hermanos comerciales (Jnetx, OpenCloud) se distancian definitivamente con
la version 1.1 de la especificaci´n. Lo veremos en los pr´ximos meses.
o
o
250](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-288-320.jpg)
![Referencias
´
[1] RAMON GARC´ y MICHAEL MARETZKE, JAIN SLEE and J2EE
IA
Technologies , 2004 JavaOne Conference
[2] DAVID FERRY y SWEEN LIM, JAIN SLEE An Event Driven Aplication
Environment , 2004 JavaOne Conference
[3] DAVID FERRY, SWEEN LIM, PHELIM O’DOHETY y DAVID
PAGE, JAIN SLEE Tutorial , 2003
[4] Open Cloud, A SLEE for all Seasons , 4 Marzo 2003
[5] Open Cloud, http://www.opencloud.com
[6] JAINSLEE.org, http://jainslee.org/
[7] JSR-22: JAIN—SLEE API Specification 1.0
, http://jcp.org/en/jsr/detail?id=22 , 17 Febrero 2004
[8] JSR-240: JAIN—SLEE API Specification 1.1
, http://jcp.org/en/jsr/detail?id=240 , 26 Febrero 2007
[9] MARETZKE MICHAEL, How To Write JSLEE Resource Adaptor , 5 Octubre
2005
[10] IVELIN IVANOV, MobicentsSMPPRA , Julio 2006
[11] Mobicents, Proyecto Mobicents
[12] Selenium Software Ltd, Selenium Software
[13] IVELIN IVANOV y VICTOR HUGO ROS,
JSLEE Service , 25 Octubre 2005
Mobicents Wake Up Call
[14] Foro Mobicents Users, http://forums.java.net/jive/forum.jspa?forumID=55
[15] Foro Mobicents Contributors
, http://forums.java.net/jive/forum.jspa?forumID=54
[16] Foro JSLEE Resource Adaptor Types
, http://forums.java.net/jive/forum.jspa?forumID=92
[17] issue tracking system, https://mobicents.dev.java.net/servlets/ProjectIssues
253](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-291-320.jpg)
![254
REFERENCIAS
[18] OpenCloud Raises $10million, http://www.opencloud.com/news-events
[19] Mobicents performance
, http://www.mobicents.org-a.googlepages.com/faq.html
[20] Mobicents license policy
, https://mobicents.dev.java.net/servlets/NewsItemView?newsItemID=3533
[21] A los grandes se les cruzan los cables
, http://www.elpais.com ,20 de Mayo 2007
[22] BEA Systems WebLogic® RealTime, http://www.bea.com
[23] BEA WebLogic® Server, http://www.bea.com
[24] Gartner starts serious coverage of event driven architectures
, http://ivelinivanov.blogspot.com ,18 de Marzo 2006
[25] Mobicents 1.0.00.CR1 Disponible
, http://forums.java.net/jive/thread.jspa?messageID=126822 ,25 de Junio 2006
[26] OpenCloud launches first true carrier-grade open platform for IMS
, http://www.opencloud.com/news-events/releases/2007/IMS products PR 20032007FINAL.html ,20 de Marzo 2007
[27] Diameter Base Protocols written in Java, jdiameter.dev.java.net ,Junio 2006
[28] Open Diameter, www.opendiameter.org ,Junio 2006
[29] Mobicents Diameter Resource Adaptor
, http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA ,19 de
Mayo 2006
[30] Java Persistence API, P´gina de Persistencia de SUN
a
[31] RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax , Agosto 1998
[32] RFC 2543, SIP: Session Initiation Protocol , Marzo 1999
[33] RFC 2976, The SIP INFO Method , Octubre 2000
[34] RFC 3261, SIP: Session Initiation Protocol , Junio 2002
[35] RFC 3262, Reliability of Provisional Responses in the Session Initiation Protocol
(SIP) , Junio 2002
[36] RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers , Junio 2002
[37] RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification , Junio
2002
[38] RFC 3311, The Session Initiation Protocol (SIP) UPDATE Method , Septiembre
2002](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-292-320.jpg)
![REFERENCIAS
255
[39] RFC 3326, The Reason Header Field for the Session Initiation Protocol (SIP) ,
Diciembre 2002
[40] RFC 3428, Session Initiation Protocol (SIP) Extension for Instant Messaging ,
Diciembre 2002
[41] RFC 3515, The Session Initiation Protocol (SIP) Refer Method , Abril 2003
[42] RFC 3588, Diameter Base Protocol 19 Mayo 2006
[43] RFC 3725, Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP) , Abril 2004
[44] RFC 4028, Session Timers in the Session Initiation Protocol (SIP) , Abril 2005
[45] RFC 4566, SDP: Session Description Protocol , Julio 2006](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-293-320.jpg)
![´
A.3. CODIGO FUENTE
267
cd $project home
ant tests-slee-tck -Dtests= ¡testpattern¿
estpattern es un fichero modelo como tests/sbb/abstractclass o tests/sbb/abstractclass/Test522Test
Este es el comando completo que ejecuta un test particular - Test522Test
La salida deber´ ser algo as´
ıa
ı:
Buildfile: build.xml
tests-slee-tck:
tests-slee-tck-internal:
[echo] slee.tck.testsuite=${slee.tck.testsuite}
[echo] Starting TCK with params: -batch ’testsuite ...
[echo] Excluding tests listed in file:
${slee.tck.testsuite}/jain-slee-tck-1_0.jtx
[java] Starting test suite...
[java] Test results: passed: 1
[java] Results written to C:workmobicentsjain-slee-1.0-tcktckwork.
[java] Report written to C:workmobicentsjain-slee-1.0-tckreports
[echo] SLEE TCK report available at
C:/work/mobicents/jain-slee-1.0-tck/reports/report.html
BUILD SUCCESSFUL
Total time: 4 seconds
Ning´n test deber´ de fallar, para hacer m´s tests, desde $project home ejecutar:
u
ıa
a
ant tests-slee-tck -Dtests=tests/sbb/abstractclass
NOTA: Los tests que est´ excluidos de test runs est´n localizados en:
a
a
$project{textunderscore}home/jain-slee-1.0-tck/testsuite/
jain-slee-tck-1{textunderscore}0.jtx
A.3.4.
Reports
Report creado por el commando:
ant tests-slee-tck -Dtests=tests/sbb/abstractclass/Test2013Test.xml
Localizado en:
C:cvsmobicentsmobicentsjain-slee-1.0-tckreportsreport.html](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-305-320.jpg)
![314
ANEXO C. ECLIPSLEE
Escoja cualquier servicio necesario del mismo modo que para los jars de los componentes. Una unidad desplegable puede contener cero o m´s servicios.
a
Presione “Finish” para crear la unidad desplegable.
Figura C.47: DU completada.
La unidad desplegable debe compilarse antes de poder instalarla en el SLEE. Esto
se puede hacer presionando dos veces en el archivo de construcci´n ant “build.xml” en
o
la ra´ del proyecto. Despu´s, presione con el bot´n derecho en “build-Test-deployableız
e
o
unit” en la columna de la derecha de la ventana del Eclipse y seleccione “1. Ant Build”.
El archivo jar resultante se ubicar´ en el directorio jars. Este directorio puede necea
sitar ser actualizado antes de que se pueda ver el archivo comprimido. Esto se puede
hacer presionando con el bot´n derecho en la carpeta y seleccionando “Refresh” del
o
men´ emergente.
u
Este archivo jar se puede instalar en el SLEE usando cualquiera de los m´todos de
e
instalaci´n de componentes SLEE, como el control de gesti´n de Rhino o una interfaz
o
o
web. Aseg´rese de que todos los adaptadores de recursos necesarios est´n instalados
u
a
antes de intentar instalar el nuevo componente.
Instalando el RA local de JAIN SIP:
[cath@hex: /rhino] cd examples/sip [cath@hex: /rhino/examples/sip] ant deploysipra
Instalando la DU de prueba:
[cath@hex: /rhino] ./manage.sh -install file:///tmp/Test-DU.jar installed: DeployableUnit[url=file:///tmp/
DU.jar]
Activando el servicio Test:
[cath@hex: /rhino] ./manage.sh -activateService ’Test Service, 1.0, Open Cloud
Ltd.’](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-352-320.jpg)
![336
ANEXO E. HANDLERS DE MOBICENTS
-deactivateService ¡Service ID¿
-getServiceState ¡Service ID¿
-setTraceLevel ¡Component ID¿¡level¿
-getTraceLevel ¡Component ID¿
-createRaEntity ¡ResourceAdaptor ID¿¡entity name¿¡props¿
-activateRaEntity ¡entity name¿
-deactivateRaEntity ¡entity name¿
-removeRaEntity ¡entity name¿
-createRaLink ¡link name¿¡entityname¿
-removeRaLink ¡link name¿
-createProfileTable ¡ProfileSpecification ID¿¡profile table name¿
-removeProfileTable ¡profile table name¿
-createProfile ¡profile tablename¿¡profile name¿
-removeProfile ¡profile table name¿¡profile name¿
El c´digo fuente se encuentra en mobicents-examples/mobicents-cli.
o
Despu´s de ejecutar el archive build.xml usando Ant obtendr´s el siguiente fichero
e
a
jar: mobicents-cli.jar.
Puedes usar el CLI en los siguientes casos:
E.1.2.1.
Un ejemplo para el tipo ID
java -jar mobicents-cli.jar -install “file:/C:/.../mobicents-examples/.../jars/...-DU.jar”
java -jar mobicents-cli.jar -uninstall “file:/C:/.../mobicents-examples/.../jars/...-DU.jar”
o para desinstalar
java -jar mobicents-cli.jar -uninstall “DeployableUnitID[#]”
java -jar mobicents-cli.jar -getDescriptor “DeployableUnitID[#]”
java -jar mobicents-cli.jar -getDeploymentId “file:/C:/.../mobicents-examples/.../jars/...DU.jar”
java -jar mobicents-cli.jar -activateService “ServiceID[Name#Vendor#Version]”
java -jar mobicents-cli.jar -deactivateService “ServiceID[Name#Vendor#Version]”
java -jar mobicents-cli.jar -getServiceState “ServiceID[Name#Vendor#Version]”
java -jar mobicents-cli.jar -setTraceLevel “¡ComponentID¿[Name#Vendor#Version]”
“¡level¿”
java -jar mobicents-cli.jar -getTraceLevel “¡ComponentID¿[Name#Vendor#Version]”](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-374-320.jpg)
![E.1. MOBICENTS CLI
E.1.2.2.
337
Resource Adaptor MBean
java -jar mobicents-cli.jar -install “file:/C:/.../sip-ra-type.jar”
java -jar mobicents-cli.jar -install “file:/C:/.../sip-local-ra.jar”
java -jar mobicents-cli.jar -createRaEntity “ResourceAdaptorID[jainsip#NIST#1.1]”
“SipRA”
java -jar mobicents-cli.jar -activateRaEntity “SipRA”
java -jar mobicents-cli.jar -createRaLink “SipRA” “SipRA”
java -jar mobicents-cli.jar -removeRaLink “SipRA”
java -jar mobicents-cli.jar -deactivateRaEntity “SipRA”
java -jar mobicents-cli.jar -removeRaEntity “SipRA”
E.1.2.3.
Creaci´n de perfiles MBean
o
java -jar mobicents-cli.jar -createProfileTable “ProfileSpecificationID[Name#Vendor#Version]”
“¡profile table name¿”
java -jar mobicents-cli.jar -removeProfileTable “¡profile table name¿”
java -jar mobicents-cli.jar -createProfile “¡profile table name¿” “¡profile name¿”
java -jar mobicents-cli.jar -removeProfile “¡profile table name¿” “¡profile name¿”
Notas:
DeployableUnitID[#] : # es el n´mero que identifica la unidad desplegable.
u
¡ComponentID¿ puede ser: ServiceID, SbbID, ResourceAdaptorID, ResourceAdaptorTypeID,ProfileSpecificationID o EventTypeID.
¡level¿ puede ser: SEVERE (valor m´s alto), WARNING, INFO, CONFIG, FINE,
a
FINER, FINEST,OFF (valor m´s bajo).
a
E.1.3.
Tareas ANT para el manejo de Mobicents
En el directorio mobicents-examples/mobicents-cli/etc encontraras un archivo example.xml. Este es un ejemplo donde puedes ver como usar comandos Slee desde
ANT. Puedes hacer funcionar el archivo desde Eclipse o desde l´
ınea de comandos.
Recuerda que si ejecutas example.xml desde l´
ınea de comandos tendr´s que escribir
a
esto: ant -f example.xml -¡target¿](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-375-320.jpg)
![348
ANEXO E. HANDLERS DE MOBICENTS
E.2.5.
Compatibilidad con navegadores
Los componentes del lado del cliente de Mobicents Management Console usan
AJAX2 y CSS23 , por lo tanto est´ recomendado usar las ultima versi´n del navega
´
o
ador.
MMC ha sido probado con Firefox 2 e Interner Explorer 6. Firefox parece funcionar
bien, mientras que IE da algunos errores CSS con los bordes de las tablas.
E.2.6.
Problemas
No hemos sido capaces de instalar una nueva Unidad Desplegable, al intentarlo
siempre da errores del tipo:
Package file: "C:mobicents_all-1-0-00-CR3resourcessiprasip-local-ra.jar "
[ERROR] serveralltmpsip-local-ra.jar(The System Cannot Find the Path Specified)
Package file: "C:/mobicents_all-1-0-00-CR3/resourcessipra/sip-local-ra.jar"
[ERROR] serveralltmp(The System Cannot Find the Path Specified)
Package file: "file:///C:/mobicents_all-1-0-00-CR3/resourcessipra/sip-local-ra.jar"
[ERROR] serveralltmpsip-local-ra.jar(The System Cannot Find the Path Specified)
En el foro Mobicents Users[14] Bartosz Baranowski mencion´ que podr´ ser un
o
ıa
problema en la inicializaci´n.
o
2
3
Asynchronous JavaScript And XML
(Cascading Style Sheets V.2](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-386-320.jpg)
![364
ANEXO F. EJEMPLOS
uso definiendo interfaces a medida de los Sbbs de la aplicaci´n.
o
Esta aplicaci´n provee un conjunto de m´tricas que est´ disponibles por MBeans, si
o
e
a
vamos a la direcci´n http://localhost:8080/jmx-console y nos desplazamos abajo hasta
o
la secci´n ’slee’, haz click en:
o
SbbUsageMBean=ServiceID[se.jayway.sip.slee.service.ThirdPCCTrigger-service
#Jayway#0.1]/
SbbID[se.jayway.sip.slee.sbb.CallControlSbb#Jayway#0.1]
Figura F.5: http://localhost:8080/jmx-console
F.2.3.
Dise˜ o
n
Esta secci´n subraya los temas de dise˜o del ejemplo en la aplicaci´n.
o
n
o
F.2.3.1.
SBB design
JSLEE define un modelo de componentes para aplicaciones as´
ıncronas basadas en
eventos, los componentes son llamados Service Building Blocks, SBBs. Hay dos componentes SBBs que produciendo la l´gica del control de llamada. Solo uno es estrictamente
o
necesario y la raz´n para dividir la funcionalidad en dos es que uno de los componentes,
o
callControllsbb, es reusable porque no tiene dependencias a ning´n evento habitual usu
ados para accionar el callflow o terminarlo y no hay dependencia de CallControlSbb a
ThirdPCCTriggerSbb.
Responsabilidades de los componentes respectivos:](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-402-320.jpg)
![F.2. EJEMPLO THIRD PARTY CALL CONTROL
371
Listado F.8: CallControlSbb
Object c o n t e n t = e v e n t . g e t R e s p o n s e ( ) . g e t C o n t e n t ( ) ;
// This i s t h e SDP from t h e c a l l e e ( f i r s t p a r t y )
t h a t w i l l be s e n t t o c a l l e r
S t r i n g c o n t e n t S t r i n g = null ;
i f ( c o n t e n t instanceof byte [ ] ) {
c o n t e n t S t r i n g = new S t r i n g ( ( byte [ ] ) c o n t e n t ) ;
} e l s e i f ( c o n t e n t instanceof S t r i n g ) {
contentString = ( String ) content ;
}
f i n a l byte [ ] s d p O f f e r = c o n t e n t S t r i n g . g e t B y t e s ( ) ;
// Get t h e a d d r e s s e s from t h e s e s s i o n s
S e s s i o n A s s o c i a t i o n sa =
( S e s s i o n A s s o c i a t i o n ) cache . get ( c a l l e e C a l l I d ) ;
S e s s i o n c a l l e e S e s s i o n = sa . g e t C a l l e e S e s s i o n ( ) ;
Address c a l l e e A d d r e s s = c a l l e e S e s s i o n . g e t S i p A d d r e s s ( ) ;
// We u s e t h e i d e n t i t y o f t h e t h i r d p a r t y c a l l c o n t r o l l e r
// a s c a l l e r a d d r e s s
Address c a l l C o n t r o l A d d r e s s =
s i p U t i l s . convertURIToAddress ( g e t C a l l C o n t r o l S i p A d d r e s s ( ) ) ;
try {
c a l l C o n t r o l A d d r e s s . setDisplayName (
( ( SipURI ) c a l l e e A d d r e s s . getURI ( ) ) . g e t U s e r ( ) ) ;
} catch ( P a r s e E x c e p t i o n e2 ) {
// TODO Auto−g e n e r a t e d c a t c h b l o c k
e2 . p r i n t S t a c k T r a c e ( ) ;
}
S e s s i o n c a l l e r S e s s i o n = sa . g e t C a l l e r S e s s i o n ( ) ;
Address c a l l e r A d d r e s s = c a l l e r S e s s i o n . g e t S i p A d d r e s s ( ) ;
Request r e q u e s t = s i p U t i l s . b u i l d I n v i t e ( c a l l C o n t r o l A d d r e s s ,
callerAddress ,
sdpOffer ,
1);
Esto muestra el trabajo de manejar la asociaci´n entre los dos di´logos de las partes
o
a
en el call setup y manejar los nombres mostrados etc. Date cuenta que usamos una direcci´n sip especial (configurable) del call controller pero usamos el nombre mostrado
o
por las partes.](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-409-320.jpg)
![Glosario
399
RTC (Red Telef´nica Conmutada)
o
Red telef´nica cl´sica
o
a
RTP(Real-time Transport Protocol)
Es un protocolo de nivel de aplicaci´n (no de nivel de transporte, como su nombre
o
podr´ hacer pensar) utilizado para la transmisi´n de informaci´n en tiempo real,
ıa
o
o
como por ejemplo audio y v´
ıdeo en una video-conferencia.
Radius
Es un protocolo AAA para aplicaciones de acceso a la red o movilidad IP. Es el
padre del protocolo actual Diameter.
Resource
Entidades externas que interact´an con otros sistemas fuera del SLEE, tales como
u
elementos de red , protocolos de pila, directorios ´ bases de datos
o
SBB (Service Building Block)
Elemento de reuso definido por Jain SLEE. Es un componente software que env´
ıa
y recibe eventos y lleva a cabo l´gica computacional basada en la recepci´n de
o
o
eventos y su estado actual.
SCF (Service Capability Features)
Abstracci´n de la funcionalidad ofrecida por la red, accesible mediante el API de
o
OSA/Parlay. Algunas veces se les llama servicios
SDP (Service Delivery Platform)
Se refiere a una incorporaci´n reciente de un estilo arquitect´nico aplicado a
o
o
los problemas de infraestructura de telecomunicaciones. Est´ dirigido a permitir
a
desarrollo y despliegue r´pido de nuevos servicios multimedia convergentes
a
SDP (Session Description Protocol)
Es un formato para describir los pr´metros de la inicializaci´n del streaming
a
o
media. Fue publicado por el IETF como RFC 4566[45]
SIP (Session Initiation Protocol)
Es un protocolo desarrollado con la intenci´n de ser el est´ndar para la iniciaci´n,
o
a
o
modificaci´n y finalizaci´n de sesiones interactivas de usuario donde intervienen
o
o
elementos multimedia. En Noviembre del a˜o 2000, SIP fue aceptado como el
n
protocolo de se˜alizaci´n de 3GPP y elemento permanente de la arquitectura
n
o
IMS.
SLEE (Service Logic Execution Environment)
Se trata de un servidor de aplicaciones. Es un contenedor para componentes
software. La especificaci´n SLEE est´ dise˜ada y optimizada para EDA.
o
a
n](https://image.slidesharecdn.com/contenedor-20de-20servicios-20convergentes-20en-20los-20entornos-20de-20telecomunicaciones-140101101402-phpapp01/85/Contenedor-de-servicios-convergentes-en-los-entornos-de-telecomunicaciones-437-320.jpg)
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
- 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
- 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
- 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
- 8. iv
- 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
- 10. vi
- 11. ´ Indice general Introducci´n y objetivos o 1 Contexto actual de las telecomunicaciones 5 1. El mundo IT frente al mundo de la red 5 2. El entorno 2.1. EDA y SLEE . . . . . . . . . 2.2. Objetivos . . . . . . . . . . . 2.3. Modelo de negocio . . . . . . 2.4. Redes de pr´xima generaci´n o o 2.5. Un ejemplo de servidor J2EE: 3. Las tecnolog´ ıas 3.1. Requisitos . . . . . . 3.2. JAVA . . . . . . . . 3.2.1. J2EE . . . . 3.2.2. JAIN SLEE . 3.2.3. JCC . . . . . 3.3. SIP . . . . . . . . . . 3.4. SMPP . . . . . . . . 3.5. SS7 y SS en general 3.5.1. Introducci´n o 3.5.2. Funcionalidad 3.6. XMPP . . . . . . . . 3.7. MM7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 10 11 11 11 . . . . . . . . . . . . 13 13 14 14 15 15 16 16 16 16 17 17 18 JAIN SLEE 21 4. Introducci´n a Jain SLEE o 4.1. Descripci´n general . . . . . . o 4.1.1. ¿Qu´ es JAIN SLEE? e 4.1.2. ¿Por qu´ aparece? . . e 4.2. Modelo de componentes . . . 4.3. Procesado de eventos . . . . . 21 21 21 22 22 23 . . . . . . . . . . . . . . . vii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 12. 4.4. Integraci´n con J2EE . . . . . . . . . . . o 4.4.1. SLEE, EJB y JMS . . . . . . . . . 4.4.1.1. Integraci´n SLEE y EJB o 4.5. Caracter´ ısticas Telco . . . . . . . . . . . . 4.6. Portabilidad entre contenedores . . . . . . 4.7. Rendimiento . . . . . . . . . . . . . . . . 4.7.1. Baja latencia . . . . . . . . . . . . 4.7.2. Alta Tasa de Transferencia . . . . 4.8. Alta disponibilidad, 99.999 % . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 24 25 27 28 29 29 29 30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 31 31 32 32 33 33 33 34 6. Modelizado de Componentes 6.1. Abstracciones y Conceptos . . . . . . . . . . . . . . . 6.2. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Comportamiento del enrutado de eventos . . 6.2.2. Subscripci´n de eventos . . . . . . . . . . . . o 6.2.3. Filtrado de eventos . . . . . . . . . . . . . . . 6.2.4. Eventos Usuales y no Usuales . . . . . . . . . 6.3. Activity y Activity Context . . . . . . . . . . . . . . 6.3.1. Activity . . . . . . . . . . . . . . . . . . . . . 6.3.2. Activity Context . . . . . . . . . . . . . . . . 6.3.3. Activity y Activity Context . . . . . . . . . . 6.3.4. Activity context y eventos . . . . . . . . . . . 6.3.5. Agregar/Separar en Activity Context . . . . 6.3.6. Ejemplo de JCC Activity Context . . . . . . 6.4. SBB y Servicios . . . . . . . . . . . . . . . . . . . . . 6.4.1. Service Building Block (SBB) . . . . . . . . . 6.4.2. Servicios . . . . . . . . . . . . . . . . . . . . . 6.4.3. Conexi´n entre SBBs y Servicios . . . . . . . o 6.4.4. Desarrollando un SBB . . . . . . . . . . . . . 6.4.5. Entidades SBB . . . . . . . . . . . . . . . . . ´ 6.4.6. Arboles de entidades SBB . . . . . . . . . . . 6.4.7. Entidades SBB padres e hijos . . . . . . . . . 6.4.7.1. Ejemplo de creaci´n de un SBB hijo o 6.4.8. Objetos SBB . . . . . . . . . . . . . . . . . . 6.4.8.1. Objetos SBB locales . . . . . . . . . 6.4.9. Entidades SBB y objetos SBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 35 35 36 36 37 37 37 37 38 38 39 39 39 40 40 40 40 41 43 43 44 44 45 45 46 5. Dise˜ o de aplicaciones JainSlee n 5.1. Abstracto . . . . . . . . . . . . . . . . 5.2. Importancia de un software confianza 5.3. Servicios de Pr´xima Generaci´n . . . o o 5.4. Desarrollo de aplicaciones . . . . . . . 5.5. Modelo de programaci´n . . . . . . . . o 5.6. Basado en est´ndares . . . . . . . . . . a 5.7. Independencia de la Red . . . . . . . . 5.8. Portabilidad . . . . . . . . . . . . . . . viii . . . . . . . . . . . . . . . .
- 13. 6.5. 6.6. 6.7. 6.8. 6.4.10. Prioridad de los SBBs . . . . . 6.4.11. Acople de los atributos SBB . . 6.4.11.1. Ejemplo Counter SBB Profiles (Perfiles) . . . . . . . . . . . . 6.5.1. Especificaci´n de Profiles . . . o Transaction y Timers . . . . . . . . . . 6.6.1. Transactions . . . . . . . . . . 6.6.2. Timers . . . . . . . . . . . . . . Resource Adaptors . . . . . . . . . . . Controles de Concurrencia en SLEE . 6.8.1. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 48 49 50 50 52 52 52 53 54 54 Mobicents 59 7. Introducci´n o 59 8. Caracter´ ısticas 8.1. Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3. Integraci´n con otros applications servers . . . . . . . o 8.4. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . 8.5. Resource Adaptors . . . . . . . . . . . . . . . . . . . . 8.5.1. Resource Adaptors . . . . . . . . . . . . . . . . 8.6. Licencia . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.1. Licencia Comercial . . . . . . . . . . . . . . . . 8.7. Patrocinadores . . . . . . . . . . . . . . . . . . . . . . 8.8. Proyecto Mobicents . . . . . . . . . . . . . . . . . . . . 8.8.1. Componentes . . . . . . . . . . . . . . . . . . . 8.8.1.1. Tecnolog´ . . . . . . . . . . . . . . . ıa 8.8.1.2. Advisory Board . . . . . . . . . . . . 8.8.2. Actividad . . . . . . . . . . . . . . . . . . . . . 8.8.3. P´gina Mobicents . . . . . . . . . . . . . . . . a 8.8.4. Foros . . . . . . . . . . . . . . . . . . . . . . . 8.8.4.1. Mobicents users . . . . . . . . . . . . 8.8.4.2. Mobicents contributors . . . . . . . . 8.8.4.3. JSLEE Resource Adaptor Types . . . 8.8.5. Informar de Bugs, Parches y Feature Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 61 61 62 62 62 63 63 64 65 65 65 65 66 67 67 67 67 68 68 68 9. Mejores pr´cticas a 9.1. RAFrame (Resource Adapter Framework) 9.1.1. El ejemplo . . . . . . . . . . . . . . 9.1.2. El protocolo . . . . . . . . . . . . . 9.1.3. El Protocol Stack . . . . . . . . . . 9.1.4. Probando el Protocol Stack . . . . 9.1.5. Descriptor de Despliegue (DD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 69 69 69 70 70 71 ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 14. 9.1.6. Eventos del RAframe . . . . . . . . . . . . . . . . . . . . . . . . 72 9.1.7. El RA Type RAFRAME . . . . . . . . . . . . . . . . . . . . . . 73 9.1.8. El Activity y Activity Context del RA . . . . . . . . . . . . . . . 75 9.1.9. EL RA Type se ofrece para los SBBs . . . . . . . . . . . . . . . . 79 9.1.10. ¿C´mo funciona? . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 o 9.1.11. El RA - Estructura y M´todos. . . . . . . . . . . . . . . . . . . . 81 e 9.1.12. entityCreated() y entityActivated() . . . . . . . . . . . . . . . . . 81 9.1.13. onEvent() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 9.1.14. getActivity() y ActivityEnded() . . . . . . . . . . . . . . . . . . . 86 9.1.15. RA Deployment Descriptor . . . . . . . . . . . . . . . . . . . . . 87 9.1.16. Construyendo el RA . . . . . . . . . . . . . . . . . . . . . . . . . 89 9.1.17. Construyendo el SBB . . . . . . . . . . . . . . . . . . . . . . . . 93 9.2. Servicios escalables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 9.2.1. Enunciado del problema . . . . . . . . . . . . . . . . . . . . . . . 97 9.2.2. Respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.3. C´mo construir un servicio SIP Registrar en SLEE . . . . . . . . . . . . 99 o 9.3.1. Descripci´n del servicio . . . . . . . . . . . . . . . . . . . . . . . 99 o 9.3.2. Implementaci´n del servicio . . . . . . . . . . . . . . . . . . . . . 99 o 9.3.2.1. Primera implementaci´n . . . . . . . . . . . . . . . . . 99 o 9.3.2.2. Eventos del servicio . . . . . . . . . . . . . . . . . . . . 99 9.3.2.3. L´gica de servicio . . . . . . . . . . . . . . . . . . . . . 102 o 9.3.2.4. Temporizador . . . . . . . . . . . . . . . . . . . . . . . 102 9.3.2.5. Comentarios . . . . . . . . . . . . . . . . . . . . . . . . 103 9.3.2.6. Objetivos a mejorar . . . . . . . . . . . . . . . . . . . . 103 9.3.3. Segunda implementaci´n . . . . . . . . . . . . . . . . . . . . . . . 103 o 9.3.3.1. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . 103 9.4. Otras buenas pr´cticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 a 9.4.1. ¿C´mo medir la duraci´n de una llamada SIP? . . . . . . . . . . 104 o o 9.4.2. Granularidad SBB para manejo de llamadas . . . . . . . . . . . . 108 9.4.3. Actualizando perfiles desde los SBB . . . . . . . . . . . . . . . . 108 9.4.4. Prioridad de los eventos del SBB y entrega de los eventos . . . . 109 9.4.5. ¿Cu´l es el lugar correcto para inicializar los SBBs a con referencias a los RAs? . . . . . . . . . . . . . . . . . . . . . . 109 9.4.6. ¿C´mo verificar si un contenedor SLEE conoce un EventTypeID? 110 o 9.4.7. ¿Cu´ndo se deben usar perfiles y cu´ndo persistencia EJB o JDBC?110 a a 9.4.8. ¿C´mo se manejan los eventos si no hay ning´n o u consumidor desplegado? . . . . . . . . . . . . . . . . . . . . . . . 111 9.4.9. ¿C´mo incluir JARs externos? . . . . . . . . . . . . . . . . . . . 111 o 10.Resource Adaptors 10.1. RA Asterisk . . . . . . . 10.1.1. Introducci´n . . o 10.1.2. Asterisk RA para 10.1.3. Eventos . . . . . 10.2. RA MGCP . . . . . . . 10.2.1. Introducci´n . . o . . . . . . . . . . . . . . Mobicents . . . . . . . . . . . . . . . . . . . . . x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 113 113 113 115 116 116
- 15. 10.2.1.1. Media gateways bridge multiple technologies 10.2.1.2. Porque pasarelas media modulares para VoIP 10.2.1.3. Pensando en el futuro . . . . . . . . . . . . . 10.2.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . 10.2.3. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.4. Configuraci´n . . . . . . . . . . . . . . . . . . . . . . . o 10.2.4.1. Configuraci´n de entrada . . . . . . . . . . . o 10.2.4.2. Normas para los nombres . . . . . . . . . . . 10.2.4.3. Conexi´n . . . . . . . . . . . . . . . . . . . . o 10.2.4.4. Llamada . . . . . . . . . . . . . . . . . . . . 10.2.4.5. eventos . . . . . . . . . . . . . . . . . . . . . 10.2.4.6. Protocolo de control . . . . . . . . . . . . . . 10.2.5. El RA . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.5.1. Identificador de tipo del RA . . . . . . . . . 10.2.5.2. Objetos Activity . . . . . . . . . . . . . . . . 10.2.5.3. Eventos del RA . . . . . . . . . . . . . . . . 10.2.5.4. Tipos de evento . . . . . . . . . . . . . . . . 10.2.5.5. Clases de eventos . . . . . . . . . . . . . . . 10.2.5.6. Activity Context Interface Factory Interface 10.2.5.7. Objeto RA . . . . . . . . . . . . . . . . . . . 10.3. RA Parlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . o 10.3.2. Consideraciones . . . . . . . . . . . . . . . . . . . . . . 10.3.3. Funcionalidades . . . . . . . . . . . . . . . . . . . . . . 10.3.4. Como instalar el RA Parlay . . . . . . . . . . . . . . . 10.3.4.1. Configuraci´n del RA . . . . . . . . . . . . . o 10.3.4.2. Contruyendo e instalando . . . . . . . . . . . 10.3.5. Ejemplo Parlay RA: Servicio CallBlocking . . . . . . 10.3.5.1. Instalando el servicio CallBlocking . . . . . 10.3.5.2. Tutorial del servicio CallBlocking de Parlay 10.4. RA Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1. Java Persistence API . . . . . . . . . . . . . . . . . . . 10.4.1.1. Entidades . . . . . . . . . . . . . . . . . . . . 10.4.1.2. El lenguaje de consulta Java Persistence . . . 10.4.2. Dise˜o del Ra Persistence . . . . . . . . . . . . . . . . n 10.4.2.1. Descripci´n de la Clase . . . . . . . . . . . . o 10.4.2.2. Eventos . . . . . . . . . . . . . . . . . . . . . 10.4.2.3. Actividades . . . . . . . . . . . . . . . . . . . 10.5. RA SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . o 10.5.2. JAIN SIP . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.2.1. Introducci´n . . . . . . . . . . . . . . . . . . o 10.5.2.2. ¿Porqu´ crear JAIN SIP? . . . . . . . . . . . e 10.5.2.3. Introducci´n a JAIN SIP . . . . . . . . . . . o 10.5.2.4. Messages y Headers . . . . . . . . . . . . . . 10.5.2.5. Transacciones y di´logos . . . . . . . . . . . a xi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 116 117 117 118 119 119 119 119 120 121 121 122 122 122 122 122 122 123 123 124 124 124 124 124 124 126 127 127 127 136 136 136 136 136 139 139 139 140 140 140 140 141 141 147 157
- 16. 10.5.2.6. Ejemplo 3PCC . . . . . . . . . . . . . . . . . . 10.5.3. Sip RA Type Memo . . . . . . . . . . . . . . . . . . . . 10.5.3.1. SIP RA Type con conjuntos de eventos duales 10.5.3.2. Activities Context e Interfaces del RA Sip . . 10.5.3.3. Tablas de Eventos . . . . . . . . . . . . . . . . 10.5.3.4. Notas . . . . . . . . . . . . . . . . . . . . . . . 10.5.3.5. Eventos y actividades . . . . . . . . . . . . . . 10.5.3.6. Eventos Out-of-dialog request . . . . . . . . . 10.5.3.7. Eventos Mid-dialog request . . . . . . . . . . . 10.5.3.8. Creaci´n autom´tica de di´logos . . . . . . . . o a a 10.5.3.9. Respuestas . . . . . . . . . . . . . . . . . . . . 10.5.3.10.Dialog state events . . . . . . . . . . . . . . . . 10.5.3.11.Timeout . . . . . . . . . . . . . . . . . . . . . 10.5.3.12.Example scenarios . . . . . . . . . . . . . . . . 10.5.4. Descarga del c´digo fuente . . . . . . . . . . . . . . . . . o 10.5.5. Despligue del RA SIP . . . . . . . . . . . . . . . . . . . 10.6. RA SMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . o 10.6.1.1. SMPP API ver 3.4 . . . . . . . . . . . . . . . . 10.6.2. SMPP Resource Adaptor . . . . . . . . . . . . . . . . . 10.6.2.1. SMPP Resource Adaptor Type . . . . . . . . . 10.6.2.2. Configuraci´n . . . . . . . . . . . . . . . . . . o 10.7. RA XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . o 10.7.2. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8. RA Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . o 10.8.2. Identificador de tipo RA . . . . . . . . . . . . . . . . . . 10.8.3. Objeto Activity . . . . . . . . . . . . . . . . . . . . . . . 10.8.4. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8.5. Objeto RA . . . . . . . . . . . . . . . . . . . . . . . . . 10.8.5.1. MediaSession . . . . . . . . . . . . . . . . . . . 10.9. Diameter RA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . o 10.9.2. Mobicents y Diameter . . . . . . . . . . . . . . . . . . . 10.9.2.1. Descripci´n del protocolo . . . . . . . . . . . . o 10.9.2.2. Comandos . . . . . . . . . . . . . . . . . . . . 10.9.2.3. Diameter State Machines . . . . . . . . . . . . 10.9.2.4. Conceptos principales del RA/RAType . . . . 10.9.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 161 161 161 162 163 164 164 165 165 166 167 167 168 170 170 171 171 172 172 172 174 176 176 177 178 178 178 178 178 179 179 181 181 182 182 182 184 184 184 11.Presente y Futuro 185 11.1. Hoja de ruta de Mobicents . . . . . . . . . . . . . . . . . . . . . . . . . . 185 11.2. Pr´ximas mejoras de Mobicents . . . . . . . . . . . . . . . . . . . . . . . 187 o xii
- 17. 12.Servicios 12.1. Servicio RingTone . . . . . . . . . . 12.1.1. Dise˜o . . . . . . . . . . . . . n 12.2. Servicio Aviso llamada entrante . . . 12.2.1. Dise˜o . . . . . . . . . . . . . n 12.3. Servicio de llamada enriquecida . . . 12.3.1. Dise˜o . . . . . . . . . . . . . n 12.4. Servicio SMS gratuito . . . . . . . . 12.4.1. Dise˜o . . . . . . . . . . . . . n 12.5. Servicio de comunicaci´n para MMO o 12.5.1. Dise˜o . . . . . . . . . . . . . n 12.6. Servicio consulta por MM7 . . . . . 12.6.1. Dise˜o . . . . . . . . . . . . . n 12.7. Servicio Video M´vil . . . . . . . . . o 12.7.1. Dise˜o m´vilTV . . . . . . . n o 12.8. Servicio Dom´tica . . . . . . . . . . o 12.8.1. Dise˜o . . . . . . . . . . . . . n 12.9. Servicios Multicast . . . . . . . . . . 12.9.1. Dise˜o . . . . . . . . . . . . . n 12.10. ervicios de localizaci´n . . . . . . . S o 12.10.1.Dise˜o . . . . . . . . . . . . . n 12.11. ervicio Aviso Disponibilidad . . . . S 12.11.1.Dise˜o . . . . . . . . . . . . . n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 189 190 190 191 192 193 194 195 196 197 198 198 199 200 201 202 203 204 205 206 207 207 Ejemplo Pr´ctico a 211 13.Introducci´n o 211 14.Prerrequisitos 213 14.1. JBoss y versiones de Java . . . . . . . . . . . . . . . . . . . . . . . . . . 213 14.1.1. Dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 15.Instalar y ejecutar 15.0.1. Usando la aplicaci´n o 15.0.2. Blocking . . . . . . . 15.0.3. Forwarding . . . . . 15.0.4. Voicemail . . . . . . 15.0.5. Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 216 217 217 218 219 16.Dise˜ o n 16.1. Sbb design . . . . . . . . . . . . . . . . . . . . . . . . . 16.2. Call Control Services. . . . . . . . . . . . . . . . . . . 16.2.1. MySQL en nuestro ejemplo . . . . . . . . . . . 16.2.1.1. Nuestra propia base de datos: Perfiles 16.2.2. Carga de perfiles . . . . . . . . . . . . . . . . . 16.2.3. CallBlockingSBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 222 223 223 223 226 232 . . . . . . . . . . . . . . . . . . . . xiii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 18. 16.2.4. 16.2.5. 16.2.6. 16.2.7. 16.2.8. Advertising . . . . . . CallForwardingSBB . VoiceMailSBB . . . . Inicio y fin de llamada Servicios en cadena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 238 239 239 244 Conclusiones y Recomendaciones 247 Referencias 253 Anexos 259 A. Instalaci´n de Mobicents o A.1. mobicents-installer . . . . . . . . . . . . . . . . . . . . . . A.2. Distribuci´n binaria . . . . . . . . . . . . . . . . . . . . . o A.3. C´digo fuente . . . . . . . . . . . . . . . . . . . . . . . . . o A.3.1. El SLEE 1.0 Technology Compatibility Kit (TCK) A.3.2. Ejecutar el contenedor . . . . . . . . . . . . . . . . A.3.3. Ejecutar TCK . . . . . . . . . . . . . . . . . . . . A.3.4. Reports . . . . . . . . . . . . . . . . . . . . . . . . A.4. Usando Eclipse Hot Code replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 259 264 265 265 266 266 267 269 B. Configuraci´n de SoftPhones o 271 B.1. XTen eyeBeam 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 B.2. X-Lite 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 B.3. SJphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 C. Eclipslee C.1. Instalaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o C.2. Creando un nuevo proyecto JAIN SLEE . . . . . . . . . . . . . . C.2.1. Creando un nuevo evento JAIN SLEE . . . . . . . . . . . C.2.2. Creando una nueva especificaci´n de perfiles JAIN SLEE o C.2.3. Creando un SBB en JAIN SLEE . . . . . . . . . . . . . . C.2.4. Creando un servicio JAIN SLEE . . . . . . . . . . . . . . C.2.5. Creando una unidad desplegable de JAIN SLEE . . . . . C.3. Haciendo disponibles componentes externos . . . . . . . . . . . . C.3.1. Instalando jars de unidades desplegables . . . . . . . . . . D. Sistemas Gestores de Archivos D.1. Bases de datos y MySQL . . . . . . . . . . D.1.1. ¿Qu´ es una base de datos? . . . . . e D.1.2. Caracter´ ısticas de una base de datos D.1.3. MySQL . . . . . . . . . . . . . . . . D.1.4. Instalaci´n . . . . . . . . . . . . . . o xiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 278 279 283 288 293 306 310 315 316 . . . . . 321 321 321 321 322 322
- 19. D.1.5. Configuraci´n de MySQL . . . . . . . . . . o D.2. Servicios de directorio y LDAP . . . . . . . . . . . D.2.1. ¿Qu´ es un servicio de directorio? . . . . . . e D.2.2. Caracter´ ısticas de un servicio de directorio D.2.3. LDAP y LDIF . . . . . . . . . . . . . . . . D.2.4. Directorio vs Bases de datos . . . . . . . . . D.2.5. Instalaci´n de LDAP . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E. Handlers de Mobicents E.1. Mobicents CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . E.1.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . o E.1.2. Invocar comandos de Slee JMX mediante CLI . . . . . . E.1.2.1. Un ejemplo para el tipo ID . . . . . . . . . . . E.1.2.2. Resource Adaptor MBean . . . . . . . . . . . . E.1.2.3. Creaci´n de perfiles MBean . . . . . . . . . . . o E.1.3. Tareas ANT para el manejo de Mobicents . . . . . . . . E.1.4. Acceso remoto . . . . . . . . . . . . . . . . . . . . . . . E.1.5. Breve tutorial de la herramienta Mobicents CLI y tareas E.1.5.1. Pasos b´sicos . . . . . . . . . . . . . . . . . . . a E.1.5.2. Arrancar y Parar Slee . . . . . . . . . . . . . . E.1.5.3. Desplegar RAs . . . . . . . . . . . . . . . . . . E.1.5.4. Replegar RAs . . . . . . . . . . . . . . . . . . E.1.5.5. Desplegar un Servicio . . . . . . . . . . . . . . E.1.5.6. Replegar un Servicio . . . . . . . . . . . . . . . E.1.5.7. Crear y Borrar perfiles . . . . . . . . . . . . . E.1.5.8. Establecer el nivel de se˜al . . . . . . . . . . . n E.1.5.9. Configurar el SBB . . . . . . . . . . . . . . . . E.2. Mobicents MMC . . . . . . . . . . . . . . . . . . . . . . . . . . E.2.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . o E.2.2. Caracter´ ısticas . . . . . . . . . . . . . . . . . . . . . . . E.2.2.1. Slee . . . . . . . . . . . . . . . . . . . . . . . . E.2.2.2. Unidades Desplegables . . . . . . . . . . . . . E.2.2.3. Componentes . . . . . . . . . . . . . . . . . . . E.2.2.4. Servicios . . . . . . . . . . . . . . . . . . . . . E.2.2.5. Resource Adaptors . . . . . . . . . . . . . . . . E.2.3. Como instalar la distribuci´n binaria de MMC . . . . . o E.2.4. Como instalar MMC desde el c´digo fuente . . . . . . . o E.2.5. Compatibilidad con navegadores . . . . . . . . . . . . . E.2.6. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . F. Ejemplos F.1. Ejemplo Wake Up Call . . . . . F.1.1. Dependencias . . . . . . F.1.2. Requerimientos . . . . . F.1.3. Build, Deploy and Run F.1.4. Dise˜o . . . . . . . . . . n . . . . . . . . . . xv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 331 331 331 332 333 333 . . . . . . . . . . . . . . . . . . . . . . . . Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 335 335 335 336 337 337 337 338 338 338 339 339 339 340 340 340 341 341 342 342 342 342 343 344 344 346 347 347 348 348 . . . . . 349 350 350 350 350 352 . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 20. F.1.4.1. wakeup-service.xml . . . . . . . . . . F.1.4.2. WakeUpSBB . . . . . . . . . . . . . . F.1.4.3. WakeUpSbbActivityContextInterface F.1.5. C´digo Fuente . . . . . . . . . . . . . . . . . . o F.1.5.1. wakeup-service.xml . . . . . . . . . . F.1.5.2. WakeUpSBB . . . . . . . . . . . . . . F.1.6. Conclusiones . . . . . . . . . . . . . . . . . . . F.2. Ejemplo Third party call control . . . . . . . . . . . . F.2.1. Prerrequisitos . . . . . . . . . . . . . . . . . . . F.2.1.1. JBoss y versiones de Java . . . . . . . F.2.1.2. Eclipse y Ant . . . . . . . . . . . . . . F.2.1.3. Mobicents y Sip RA . . . . . . . . . . F.2.1.4. Mobicents rar ipaddress issue . . . . . F.2.2. Instalar y ejecutar . . . . . . . . . . . . . . . . F.2.2.1. Servicio SLEE . . . . . . . . . . . . . F.2.2.2. Aplicaci´n Web . . . . . . . . . . . . o F.2.2.3. M´tricas . . . . . . . . . . . . . . . . e F.2.3. Dise˜o . . . . . . . . . . . . . . . . . . . . . . . n F.2.3.1. SBB design . . . . . . . . . . . . . . . F.2.3.2. Compartici´n de Estado. . . . . . . . o F.2.3.3. State machine . . . . . . . . . . . . . F.2.4. Notas . . . . . . . . . . . . . . . . . . . . . . . F.2.4.1. Caracter´ ısticas y limitaciones . . . . F.2.4.2. Interoperabilidad . . . . . . . . . . . . F.2.5. C´digo Fuente . . . . . . . . . . . . . . . . . . o F.2.5.1. Controller Servlet . . . . . . . . . . . F.2.5.2. Servicio SLEE . . . . . . . . . . . . . F.3. Mensajes smpp a trav´s de Google Talk . . . . . . . . e F.3.1. C´digo fuente . . . . . . . . . . . . . . . . . . . o F.3.2. Accediendo al RA desde SBB . . . . . . . . . . F.3.3. Handling server transactions . . . . . . . . . . F.3.4. Handling client transactions . . . . . . . . . . . F.3.5. Como instalarlo, configurarlo y arrancarlo . . . F.4. Ejemplo Google bot . . . . . . . . . . . . . . . . . . . F.4.1. C´digo fuente . . . . . . . . . . . . . . . . . . . o F.4.2. Dependencias . . . . . . . . . . . . . . . . . . . F.4.3. C´mo instalar, configurar y ejecutar . . . . . . o F.4.4. Casos de uso . . . . . . . . . . . . . . . . . . . G. Subversion G.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . o G.2. clientes . . . . . . . . . . . . . . . . . . . . . . . . . G.3. Subclipse . . . . . . . . . . . . . . . . . . . . . . . . G.3.1. Instalaci´n de Subclipse . . . . . . . . . . . . o G.3.1.1. Descarga con Eclipse por Subclipse xvi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 352 352 354 354 354 358 359 359 359 359 359 360 360 360 360 363 364 364 365 365 365 365 366 367 367 368 373 373 373 374 374 375 377 377 377 377 378 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 381 381 381 381 381
- 22. xviii
- 23. ´ Indice de figuras 3.1. Distribuci´n de las aplicaciones s´ o ıncronas frente a las as´ ıncrones . . . . . 14 4.1. Integraci´n Jain SLEE y JES. . . . . . . . . . . . . . . . . . . . . . . . . o 4.2. Jain SLEE en un entorno Telco. . . . . . . . . . . . . . . . . . . . . . . . 25 27 6.1. Eventos de Activity . . . . . . . . . . . . . . . . 6.2. Eventos de Activity Context. . . . . . . . . . . . 6.3. L´gica de los SBBs. . . . . . . . . . . . . . . . . o 6.4. M´todos que implementan la l´gica de los SBBs. e o ´ 6.5. Ejemplo de Arbol de Entidades SBB. . . . . . . . 6.6. Gr´fico relaciones SBB padres y SBB hijos. . . . a 6.7. Relaci´n Entidades SBB y Objetos SBB. . . . . . o 6.8. Especificaci´n de Profiles . . . . . . . . . . . . . o 6.9. Especificaci´n de Profiles II . . . . . . . . . . . . o 6.10. Ejemplo de Control de Concurrencia . . . . . . . . . . . . . . . . . 38 38 42 42 43 44 47 50 51 55 8.1. Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Estad´ ısticas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 67 9.1. Protocolo del ejemplo. . . . . . . . . . . . . . . . . . . . . . 9.2. El RAFSwingClient. . . . . . . . . . . . . . . . . . . . . . . 9.3. El RAFSwingClient. . . . . . . . . . . . . . . . . . . . . . . 9.4. Perspectiva de varios Descriptores de Despliegue. . . . . . . 9.5. Proceso de Eventos a trav´s de RAs y un router de eventos. e 9.6. Consola Mobicents. . . . . . . . . . . . . . . . . . . . . . . . 9.7. Consola Mobicents. . . . . . . . . . . . . . . . . . . . . . . . 9.8. Consola Mobicents. . . . . . . . . . . . . . . . . . . . . . . . 9.9. Consola Mobicents. . . . . . . . . . . . . . . . . . . . . . . . 9.10. Consola Mobicents . . . . . . . . . . . . . . . . . . . . . . . 9.11. Consola Mobicents. . . . . . . . . . . . . . . . . . . . . . . . 9.12. Consola Mobicents. . . . . . . . . . . . . . . . . . . . . . . . 9.13. Consola Mobicents. . . . . . . . . . . . . . . . . . . . . . . . 9.14. Esquema obtenido con Mobicents SLEE Graph Viewer. . . 9.15. Componentes vistos en MMC. . . . . . . . . . . . . . . . . . 9.16. Unidades Desplegadas vistas en MMC. . . . . . . . . . . . . 70 71 71 72 74 89 90 91 91 92 92 93 94 95 96 96 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1. Diagrama de Clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 xix
- 24. 10.2. Persistence . . . . . . . . . . . . . . . . . 10.3. Persistence RA SBB Interface . . . . . . . 10.4. Persitence RA Entity Manager . . . . . . 10.5. persistence.xml . . . . . . . . . . . . . . . 10.6. persistence-ra-ds.xml . . . . . . . . . . . . 10.7. Arquitectura de Objetos. . . . . . . . . . 10.8. Arquitectura de mensajeria. . . . . . . . . 10.9. Esquema de una llamada SIP. . . . . . . . 10.10. structura de una aplicaci´n gen´rica SIP. E o e 10.11. ransacciones SIP. . . . . . . . . . . . . . T 10.12. jemplo 3PCC usando JAIN SIP. . . . . . E 10.13. A SIP y Servicio Proxy . . . . . . . . . . R 10.14. mpp-ra-DU . . . . . . . . . . . . . . . . x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 137 137 138 138 143 146 152 157 158 160 170 177 12.1. Servicio Ringtone . . . . . . . . . . . 12.2. Diagrama Ring Back Tone . . . . . . 12.3. Servicio Aviso llamada entrante . . . 12.4. Diagrama de aviso llamada entrante 12.5. Servicio de llamada enriquecida . . . 12.6. Diagrama Llamada Enriquecida . . . 12.7. Servicio SMS gratis . . . . . . . . . . 12.8. Servicio SMS gratis . . . . . . . . . . 12.9. Servicio de comunicaci´n para MMO o 12.10. iagrama MMO . . . . . . . . . . . D 12.11. ervicio consulta por MM7 . . . . . S 12.12. iagrama consulta por MM7 . . . . D 12.13. ervicio Video M´vil . . . . . . . . . S o 12.14. iagrama m´vilTV . . . . . . . . . . D o 12.15. ervicio Dom´tica . . . . . . . . . . S o 12.16. iagrama domotica . . . . . . . . . . D 12.17. ervicios Multicast . . . . . . . . . . S 12.18. iagrama multicast . . . . . . . . . . D 12.19. ervicios de localizaci´n . . . . . . . S o 12.20. iagrama Servicio de Localizaci´n . D o 12.21. ervicio Aviso Disponibilidad . . . . S 12.22. iagrama Servicio de disponibilidad D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 190 191 192 193 194 195 196 196 197 198 199 200 201 201 203 204 205 205 206 207 208 16.1. Cadena de servicios. . . . . 16.2. Slee Graph Viewer. . . . . . 16.3. Diagrama Entidad Relaci´n o 16.4. Tablas . . . . . . . . . . . . 16.5. Cadena de servicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 222 224 225 244 A.1. A.2. A.3. A.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 260 261 262 Primera pantalla . . . . . . Informaci´n de instalaci´n . o o Elecci´n de la carpeta . . . o Elecci´n de los componentes o xx
- 25. A.5. A.6. A.7. A.8. Configuraci´n de la base o Listo para instalar . . . Proceso de instalaci´n . o Instalaci´n terminada . o de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 263 263 264 B.1. B.2. B.3. B.4. B.5. B.6. Configuraci´n Xten . . . o Configuraci´n X-Lite I . o Configuraci´n X-Lite II o Nuevo perfil SJPhone . Profile Options . . . . . SJPhone Configurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 273 273 274 275 275 C.1. Nuevo proyecto. . . . . . . . . C.2. Nuevo proyecto JAIN SLEE . C.3. Nombre del proyecto . . . . . C.4. Proyecto creado. . . . . . . . C.5. Nuevo paquete. . . . . . . . . C.6. Nuevo evento. . . . . . . . . . C.7. Nuevo evento JAIN SLEE. . . C.8. Nombre del evento. . . . . . . C.9. Identificaci´n del evento. . . . o C.10.Evento completado. . . . . . C.11.Construcci´n del evento. . . . o C.12.Nuevo perfil 1. . . . . . . . . C.13.Nuevo perfil 2. . . . . . . . . C.14.Nombre de archivo del perfil . C.15.Profile Identity. . . . . . . . . C.16.CMP del perfil. . . . . . . . . C.17.Perfil completo. . . . . . . . . C.18.Construcci´n del perfil. . . . o C.19.Nuevo SBB. . . . . . . . . . . C.20.Nuevo SBB. . . . . . . . . . . C.21.Nombre del archivo del SBB. C.22.Identificaci´n del SBB. . . . . o C.23.Clases del SBB. . . . . . . . . C.24.CMP del SBB. . . . . . . . . C.25.Di´logo CMP del SBB. . . . . a C.26.Uso del SBB. . . . . . . . . . C.27.Eventos del SBB . . . . . . . C.28.Di´logo de eventos del SBB . a C.29.Eventos del SBB . . . . . . . C.30.Perfil del SBB . . . . . . . . . C.31.SBB hijo. . . . . . . . . . . . C.32.Tipos de SBB RA. . . . . . . C.33.Enlaces del RAType del SBB. C.34.Entradas de entorno del SBB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 280 280 281 282 283 284 284 285 286 287 288 289 289 290 290 291 292 293 294 294 295 295 296 296 297 298 299 300 301 302 303 304 305 xxi
- 26. C.35.SBB completado. . . . . . C.36.Nuevo servicio. . . . . . . C.37.Nuevo servicio. . . . . . . C.38.Nombre del servicio. . . . C.39.Identificaci´n del servicio. o C.40.Ra´ del servicio. . . . . . ız C.41.Servicio completado. . . . C.42.Nueva unidad desplegable. C.43.Nueva unidad deplegable. C.44.Nombre de la DU . . . . . C.45.Componentes de la DU. . C.46.Servicios de la DU. . . . . C.47.DU completada. . . . . . C.48.Propiedades. . . . . . . . C.49.Propiedades. . . . . . . . C.50.Propiedades. . . . . . . . C.51.Propiedades. . . . . . . . C.52.Propiedades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 307 307 308 308 309 310 311 312 312 313 313 314 316 317 317 318 319 D.1. Pantalla de bienvenida al instalador . D.2. Selecci´n del tipo de instalaci´n . . . . o o D.3. Opciones seleccionadas . . . . . . . . . D.4. Progreso de la instalaci´n . . . . . . . o D.5. Registro de usuario . . . . . . . . . . . D.6. Fin de la instalaci´n . . . . . . . . . . o D.7. Pantalla de bienvenida del asistente de D.8. Selecci´n del tipo de configuraci´n . . o o D.9. Configuraci´n de servicio . . . . . . . o D.10.Contrase˜a . . . . . . . . . . . . . . . n D.11.Estado de la configuraci´n . . . . . . . o D.12.Fin de la instalaci´n . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . configuraci´n o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 324 324 325 326 326 327 328 328 329 330 330 E.1. E.2. E.3. E.4. E.5. E.6. Slee . . . . . . . . . . Unidades Desplegables Componentes . . . . . Servicios . . . . . . . . Par´metros . . . . . . a Resource Adaptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 343 344 345 345 346 F.1. F.2. F.3. F.4. F.5. F.6. F.7. F.8. Ejemplo wake up . . . . . . . . . . . . . SleeGraphViewer . . . . . . . . . . . . . Call Launch Form . . . . . . . . . . . . Status Feed Packpage . . . . . . . . . . http://localhost:8080/jmx-console . . . Diagrama de estado. . . . . . . . . . . . Mandando un sms a trav´s de SMPPsim e Resultado de la ejecuci´n. . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 362 363 363 364 366 376 378 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 27. G.1. Find and Install . . . . . . . . G.2. Install/Update . . . . . . . . G.3. Install . . . . . . . . . . . . . G.4. New Update Site . . . . . . . G.5. Install . . . . . . . . . . . . . G.6. Instalaci´n . . . . . . . . . . o G.7. Confirmaci´n . . . . . . . . . o G.8. Proceso de instalaci´n . . . . o G.9. Aviso . . . . . . . . . . . . . G.10.Abrir perspectiva... . . . . . . G.11.Abrir perspectiva . . . . . . . G.12.Localizaci´n del Repositorio . o G.13.Localizaci´n del Repositorio . o G.14.Usuario y Contrase˜a . . . . n G.15.Checkout . . . . . . . . . . . G.16.Checkout from SVN . . . . . G.17.Proyecto descargado de SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 382 383 384 384 385 385 386 386 387 387 388 388 389 389 390 390
- 28. xxiv
- 29. ´ Indice de tablas 4.1. Modos de interacci´n JSlee con EJB . . . . . . . . . . . . . . . . . . . . o 26 6.1. Entidades SBB y Objetos SBB . . . . . . . . . . . . . . . . . . . . . . . 46 10.1. Eventos RA Asterisk . . . . . . . . . . . . . . . . . . . . 10.2. Eventos MGCP RA . . . . . . . . . . . . . . . . . . . . 10.3. Eventos RA Persistence . . . . . . . . . . . . . . . . . . ´ 10.4. Ultimas actualizaciones de la especificaci´n . . . . . . . o 10.5. Out of dialog requests - same as JAIN SIP 1.1 RA type 10.6. In-dialog requests - new for 1.2 RA Type . . . . . . . . 10.7. Responses - same as JAIN SIP 1.1 RA Type . . . . . . . 10.8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9. Dialog State events - new for 1.2 RA Type . . . . . . . . 10.10. ew for 1.2 RA Type . . . . . . . . . . . . . . . . . . . N 10.11. ventos RA XMPP . . . . . . . . . . . . . . . . . . . . . E 10.12. omandos . . . . . . . . . . . . . . . . . . . . . . . . . . C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 122 139 142 162 162 163 163 163 163 177 183 11.1. Detalles de las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 15.1. Tabla perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 xxv
- 30. xxvi
- 31. Listados 9.1. Interfaz MessageEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2. Interfaz MessageFactory . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3. event-jar.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4. Definici´n de Actividad en resource-adaptor-type-jar.xml . . . . . . . . o 9.5. Interfaz de RAFActivity . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6. Extracto de la funci´n onEvent de la clase RAFrameResourceAdaptor o 9.7. funci´n onInitEvent de la clase BounceSBB . . . . . . . . . . . . . . . o 9.8. Interfaz RAFrameResourceAdaptorSBBInterface . . . . . . . . . . . . 9.9. M´todo onAnyEvent() de la clase BounceSBB . . . . . . . . . . . . . . e 9.10. M´todo entityCreated() de la clase RAFrameResourceAdaptor . . . . e 9.11. M´todo entityActivated() . . . . . . . . . . . . . . . . . . . . . . . . . e 9.12. onEvent() 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.13. onEvent() 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.14. onEvent() 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.15. onEvent() 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.16. onEvent() 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.17. M´todo getActivity() . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 9.18. M´todo activityEnded() . . . . . . . . . . . . . . . . . . . . . . . . . . e 9.19. resource-adaptor-jar.xml . . . . . . . . . . . . . . . . . . . . . . . . . . 9.20. Descriptor de despliegue de SIP Registrar . . . . . . . . . . . . . . . . 9.21. SIP REGISTRAR SBB . . . . . . . . . . . . . . . . . . . . . . . . . . 9.22. Interfaz de AC Register . . . . . . . . . . . . . . . . . . . . . . . . . . 9.23. DD del SBB para medir la duraci´n de una llamada SIP . . . . . . . . o 9.24. JainSipProxySbb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.25. onByeEvent(RequestEvent . . . . . . . . . . . . . . . . . . . . . . . . . 9.26. onAckEvent, getCallStartTime() y setCallStartTime . . . . . . . . . . 10.1. CallBlocking-service.xml . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2. sbb-jar.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3. Parte de c´digo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 10.4. sbb-jar.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5. sbb.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6. sbb-jar.xml parlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7. sbb.java parlay 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8. sbb.java parlay 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9. sbb.java parlay 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.10. bb.java parlay 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . s xxvii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 73 74 75 76 77 78 79 80 81 82 83 84 84 85 86 87 87 88 99 101 102 105 106 107 107 129 130 131 132 132 133 133 134 134 134
- 32. 10.11. bb.java parlay 5 . . . . . . . . . . . . . . . . . . s 10.12. ctivity Context Interface Factory . . . . . . . . A 15.1. Voicemail-sbb-jar.xml . . . . . . . . . . . . . . . 15.2. Voicemail-sbb-jar.xml . . . . . . . . . . . . . . . 16.1. Voicemail-sbb-jar.xml . . . . . . . . . . . . . . . 16.2. Creaci´n de la base de datos . . . . . . . . . . . . o 16.3. Construcci´n de las tablas . . . . . . . . . . . . . o 16.4. Inserci´n de un usuario . . . . . . . . . . . . . . o 16.5. Inserci´n de un bloqueo . . . . . . . . . . . . . . o 16.6. Inserci´n de un bloqueo . . . . . . . . . . . . . . o 16.7. Preparar el endpoint . . . . . . . . . . . . . . . . 16.8. Preparar el endpoint . . . . . . . . . . . . . . . . 16.9. Preparar el endpoint . . . . . . . . . . . . . . . . 16.10. ventos de Advertising . . . . . . . . . . . . . . . E 16.11. As adjuntos . . . . . . . . . . . . . . . . . . . . R 16.12. reparar el endpoint . . . . . . . . . . . . . . . . P 16.13. eclarar objetos . . . . . . . . . . . . . . . . . . D 16.14. reparar la conexi´n . . . . . . . . . . . . . . . . P o 16.15. rear la conexi´n . . . . . . . . . . . . . . . . . . C o 16.16. olver a reproducir . . . . . . . . . . . . . . . . . V 16.17. sbb-jar.xml . . . . . . . . . . . . . . . . . . . . . 16.18. orwarding-sbb-jar.xml . . . . . . . . . . . . . . F 16.19. ventos de Registro de llamadas . . . . . . . . . E 16.20. ampo CMP para el inicio de la llamada . . . . C 16.21. efinici´n campo CMP . . . . . . . . . . . . . . D o 16.22. vento ACK . . . . . . . . . . . . . . . . . . . . E 16.23. vento BYE . . . . . . . . . . . . . . . . . . . . . E 16.24. unci´n comprueba si tiene Advertising . . . . . F o 16.25. allForwardingSbbActivityContextInterface.java C 16.26. orwarding-sbb-jar.xml . . . . . . . . . . . . . . F 16.27. oiceMail-sbb-jar.xml . . . . . . . . . . . . . . . V 16.28. sbb-jar.xml . . . . . . . . . . . . . . . . . . . . . F.1. wakeup-service.xml . . . . . . . . . . . . . . . . . F.2. Controller Servlet . . . . . . . . . . . . . . . . . . F.3. Controller Servlet . . . . . . . . . . . . . . . . . . F.4. sbb-jar.xml . . . . . . . . . . . . . . . . . . . . . F.5. ThirdPCCTrigger-service . . . . . . . . . . . . . F.6. ThirdPCCTriggerSbb . . . . . . . . . . . . . . . F.7. ThirdPCCTriggerSbb . . . . . . . . . . . . . . . F.8. CallControlSbb . . . . . . . . . . . . . . . . . . . F.9. CallControlSbb . . . . . . . . . . . . . . . . . . . F.10.Funci´n setSbbContext . . . . . . . . . . . . . . . o F.11.Funci´n onSmsMessage . . . . . . . . . . . . . . o F.12.Funci´n onGoogleMessage . . . . . . . . . . . . . o xxviii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 174 218 219 223 225 225 226 226 226 227 228 229 233 234 235 235 236 236 237 237 239 241 241 241 242 242 243 244 245 245 246 354 367 368 368 369 370 370 371 372 374 374 375
- 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
- 34. 2
- 35. Contexto actual de las telecomunicaciones 3
- 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.
- 40. 8 CAP´ ITULO 1. EL MUNDO IT FRENTE AL MUNDO DE LA RED
- 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
- 51. JAIN SLEE 19
- 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
- 57. ´ 4.4. INTEGRACION CON J2EE 25 Figura 4.1: Integraci´n Jain SLEE y JES. o 4.4.1.1. Integraci´n SLEE y EJB o EJB -> SLEE es una interfaz de presentaci´n de eventos o EJB presenta eventos a SLEE a trav´s de la interfaz SleeConnection en el ap´ndice e e de SLEE La interfaz es implementada por un conector J2EE Este conector manda eventos a trav´s de alg´n mecanismo a un RA en SLEE e u El RA lee los eventos y los pasa al subsistema de procesado de eventos de SLEE Estos eventos son procesados como cualquier otro evento SLEE->EJB es una interfaz de presentaci´n de eventos o Desde la perspectiva de EJB un SBB es un cliente remoto Un SBB puede invocar un EJB a trav´s de su interfaz remota e El interfaz home de EJB es obtenido a trav´s del entorno JNDI4 de los SBBs e El tipo de la interfaz local se especifica en el descriptor desplegable de los SBBs 4 Java Naming and Directory Interface, es una Interfaz de Programaci´n de Aplicaciones para sero vicios de directorio.
- 58. ´ CAP´ ITULO 4. INTRODUCCION A JAIN SLEE 26 Contenedor Slee Puro Soporte para el procesado de eventos Los Vendedores de SLEE proveen Manejo del ciclo de vida Idoneidad para aplicaciones as´ ıncronas Integraci´n o J2EE/EJB SLEE mapeado sobre EJB a trav´s e de generaci´n de o c´digo o Declarativo con opci´n a un control o Programado Contenedor SLEE SLEE reespecificado como EJB + una librer´ de ıa procesado de eventos Programado Contenedor EJB Librer´ de eventos ıa Generador de C´digo o Manejado por el c´digo generado y la o librer´ de eventos ıa Contenedor EJB Librer´ de eventos ıa Alta Alta Media Media Alta Alta Manejado por el contenedor SLE Tabla 4.1: Modos de interacci´n JSlee con EJB o Manejado por el c´digo de la o aplicaci´n y la o librer´ de eventos ıa
- 59. 4.5. CARACTER´ ISTICAS TELCO 4.5. 27 Caracter´ ısticas Telco Como Jain SLEE posee alto rendimiento, es flexible y es un est´ndar abierto basado a en el procesado de eventos, por ello existe un gran n´mero de casos de uso en los entornos u de comunicaciones Figura 4.2: Jain SLEE en un entorno Telco. Jain SLEE puede usarse como plataforma de servicios en el sentido tradicional. Aun as´ es flexible en cuanto a ser capaz de dar soporte a las actuales redes (SS7) ı y las futuras (3th Generation,NGIN) Jain SLEE provee de conexiones a sistemas de soporte operacionales y de negocio (OSS/BSS). Los servicios pueden crearse para proveer de eficiencia operacional para el operador as´ como servicios autom´ticos para el consumidor ı a Jain SLEE es capaz de interoperar con J2EE por lo que se pueden crear servicios enriquecidos basados en la combinaci´n de ambos est´ndares, por ejemplo se o a pueden desplegar controles de llamada y servicios web. Considerando la integraci´n descrita anteriormente, Jain SLEE puede verse como o 5 , para telecomunicaciones. un middleware, o EAI En JainSlee podemos destacar las siguientes caracter´ ısticas Telco, que se contraponen con las caracter´ ısticas t´ ıpicamente IT: 5 Enterprise Application Integration
- 60. ´ CAP´ ITULO 4. INTRODUCCION A JAIN SLEE 28 Invocaciones: T´ ıpicamente as´ ıncronos (eventos de protocolos, eventos mapeados en invocaciones a m´todos) e Granularidad de eventos: Granularidad muy fina y con frecuencia alta Componentes: Tiempos de vida cortos y muy r´pidos (creaci´n r´pida, borrado...) a o a Fuente de datos: M´ltiples fuentes de datos (Localizaci´n, informaci´n de conu o o texto, datos provisionales, obtenidos a partir de una copia master) Transacciones: Transacciones ligeras (Para estados de demarcaci´n replicada, fio nalizaci´n r´pida y mas frecuente) o a Procesamiento: Procesamiento intensivo (El procesado es a base de invocaciones y eventos) Disponibilidad: De 3 a 59 segundos Tiempo real: Tiempo real suave Despliegue de la distribuci´n: Despliegue distribuido todo ello a trav´s de la red o e Nodos: 1 a 4 CPUs Clusters: 2 a 16 nodos 4.6. Portabilidad entre contenedores Una de las caracter´ ısticas de los contenedores de JAIN SLEE es la facilidad de portabilidad de software hecho para uno concreto con respecto a otro. Ya que el est´ndar a usado en los RAs y en los consumidores de eventos es el propio JAIN SLEE, tan s´lo o habr´ que modificar el contenedor al que estos est´n asociados. Pero entonces, cabe ıa a una duda, ¿porque crear diferentes contenedores?¿Qu´ diferencia puede haber entre e unos y otros? La clave para los vendedores que quieran hacerse un hueco en este mundo viene dada por la mejora de las siguientes caracter´ ısticas: Capas de abstracci´n para el manejo del estado de llamada o Uso optimizado de los recursos (memoria en tiempo de ejecuci´n, recolecci´n de o o basura, etc.) Alto rendimiento en la ejecuci´n de transacciones simult´neas y as´ o a ıncronas Estrategias de escalabilidad y disponibilidad a trav´s de software de clustering e Extensi´n de conformidad con la especificaci´n del est´ndar o o a
- 61. 4.7. RENDIMIENTO 4.7. Rendimiento 4.7.1. 29 Baja latencia Llamamos latencia al retraso que existe al llevar un paquete de datos de un punto a otro. El tiempo para establecer una llamada menor de 500 ms, la latencia media deber´ ıa estar entre 50 y 100 ms por transacci´n. o Esto deber´ ser alcanzable en un cluster de 2 a 4 nodos, cada uno con 2 o 4 CPUs ıa con disponibilidad y redundancia habilitadas. ¿Que es necesario para establecer una llamada en 500ms? A trav´s de 2 a 5 nodos de redes o servidores de aplicaciones. e Como m´ ınimo dos protocolos de eventos de mensajes por nodo (depende de la aplicaci´n). o 1 transacci´n por evento. o Aproximadamente entre 4 y 10 eventos por proceso dentro de los 500 ms ( excluyendo el retraso propagado, algunos procesos se solapan con la programaci´n). o De 50 a 125 ms por transacci´n(para una transacci´n simple con redundancia o o para un unico fallo de tolerancia). ´ El percentil 95 tiene como media 200 ms de tiempo de viaje. 4.7.2. Alta Tasa de Transferencia En Telco se usa el termino de BHCA6 para calcular la tasa de transferencia, en el caso de JAIN SLEE esta tasa es de 1 mill´n de BHCA. o Esto se traduce en aproximadamente 2500 transacciones por segundo con actualizaci´n de estados que son transferidos y replicados para evitar fallos de nodos unicos. o ´ ¿Qu´ requiere 1.000.000 BHCA? e De 2 a 10 protocolos de mensaje o eventos por llamadas (dependencia de aplicaci´n). o Una transacci´n por evento. o Aproximadamente 280 intentos de llamadas por segundo. Entre 560 y 2800 transacciones por segundo con actualizaci´n del estado transaco cional y replicaci´n. o 6 Busy Hour Call Attempts
- 62. ´ CAP´ ITULO 4. INTRODUCCION A JAIN SLEE 30 4.8. Alta disponibilidad, 99.999 % Con alta disponibilidad se hace referencia a la eficacia que tiene JAIN SLEE para mantenerse activo, en este caso tenemos menos de 6 minutos de inactividad planeada y no planeada por a˜o. n Tambi´n existen diferentes tipos de disponibilidad, presenta pocos fallos parciales e e implementa un manejo elegante de picos de carga sobre la capacidad m´xima del a sistema. Si SLEE falla antes de que un evento haya sido liberado a una entidad SBB particular, este lo liberar´ en esa entidad SBB utilizando otra JVM7 o cuando SLEE se reinicie. a Si una entidad SBB es invocada pero no ha terminado el procesado de un evento, la entidad SBB invocar´ otra vez con una transacci´n callback. Este mecanismo asegura a o que la entidad SBB conoce que hay un fallo en el medio del procesado de eventos. Todas las entidades SBB se desvinculan de su Activity Context una vez reciben el ActivityEndEvent. La clave para limpiar las entidades SBB es asegurarse que todos los AC’s han terminado. Un ´rbol entero SBB se limpiara despu´s de que todas las a e entidades SBB del ´rbol no sigan adjuntas a cualquier Activity Context. a 7 Java Virtual Machine
- 63. Cap´ ıtulo 5 Dise˜ o de aplicaciones JainSlee n 5.1. Abstracto Abierto, basado en est´ndares, SLEE que se integra con las redes actuales y futuras a es la clave para proveer de innovaci´n y rentabilidad en la creaci´n de servicios. o o La especificaci´n Jain SLEE define c´mo los servicios telco pueden construirse, o o manejarse y ejecutarse. Esta especificaci´n ha sido dise˜ada expl´ o n ıcitamente para dar un soporte a los vendedores de productos con el que puedan dirigir un transporte con requisitos de calidad sobre un entorno est´ndar de se˜ales de llamada. a n 5.2. Importancia de un software confianza La disponibilidad continua es la principal meta de los servicios de comunicaci´n o y s´lo se puede alcanzar si el tiempo para detectar y recuperar un fallo es bajo. La o industria de las computadoras hist´ricamente siempre ha estado preocupados por los o fallos hardware. Los fallos software son una de las mayores causas de los periodos de inactividad (40 %). El incremento de la complejidad de los sistemas software es consecuencia directa del incremento de la complejidad de los servicios proporcionados. El coste del desarrollo de software de modo que se garantice alta disponibilidad es muy alto. Las aproximaciones en el dise˜o que intentan eliminar los fallos software comprobando caso por caso incren mentan de forma considerable el coste de desarrollo a la vez que no garantizan que no ocurran fallos. Por lo tanto, adem´s de los m´todos existentes para tratar con errores hardware, exa e iste un requerimiento para las arquitecturas software que direccionen los fallos software. Jain SLEE potencia el uso de un modelo de programaci´n transaccional. Las aplicao ciones escritas utilizando este modelo poseen sem´nticas bien definidas bajo condiciones a de fallo. Tambi´n decir que el modelo de programaci´n transaccional esta integrado con e o invocaciones s´ ıncronas y as´ ıncronas. Por lo tanto podemos desarrollar aplicaciones de gran confianza, lo que da a las compa˜´ la seguridad de que su software bien hecho no fallara, y no se producir´n nıas a 31
- 64. ˜ CAP´ ITULO 5. DISENO DE APLICACIONES JAINSLEE 32 excepciones descontroladas que en el mundo de las Telco son fat´ ıdicas, ya que producen grandes periodos de inactividad. 5.3. Servicios de Pr´xima Generaci´n o o La necesidad de introducir nuevos servicios sobre redes telef´nicas m´s r´pidamente o a a ha experimentado un gran cambio durante los ultimos 10-15 a˜os. La explosi´n de Inn o ternet ha contribuido a el desarrollo de servicios de Pr´xima Generaci´n que aprovechan o o las caracter´ ısticas de redes Internet y telef´nicas. o En el desarrollo de servicios de Pr´xima Generaci´n se presentan 3 problemas: o o 1. Potabilidad de servicios: El despliegue de servicios est´ restringido por las ina terfaces propietarias, las cuales incrementan el coste de desarrollo, tiempo de comercializaci´n, y requisitos de mantenimiento. La disponibilidad de una base o de desarrollo para una plataforma en particular es peque˜a. n 2. Convergencia de Redes: Es dif´ crear aplicaciones y servicios que funcionen ıcil indistintamente sobre redes PSTN, redes basadas en paquetes (e.g. IP o ATM) y redes wireless. 3. Acceso Seguro a Redes: Es dif´ para aplicaciones externas de redes telef´nicas ıcil o el acceder a recursos de redes y y dispositivos, de una forma segura y manejable. En JainSLEE se soluciona estos problemas ya que cumple con la iniciativa JAIN, en el aspecto de la Portabilidad de servicios cumple con la m´xima de “Escribir una a vez, ejecutar en cualquier sitio”, con lo que no incrementamos el coste debido a las restricciones que hab´ y reducimos el tiempo de desarrollo. En cuanto a la convergencia ıa de redes, tiene la ventaja de estar dise˜ado para funcionar en cualquier red. Por ultimo n ´ en el acceso seguro a redes se adopta la especificaci´n Parlay para proveer de una o manera segura de acceder a las capacidades de la red. 5.4. Desarrollo de aplicaciones Para lograr satisfacer los requisitos de rendimiento y disponibilidad, el programador tiene que tener acceso a APIs que permitan que sus aplicaciones proporcionen la siguiente l´gica: o Ser simple. Funcionamiento independiente del alojamiento y fallos. Ejecuci´n independiente de unos nodos de computaci´n particulares. o o Ejecuci´n concurrente. o
- 65. ´ 5.5. MODELO DE PROGRAMACION 33 Estas APIs tienen que ser suficientemente ricas para dar soporte al tipo de aplicaciones que necesitan desarrollarse en estos momentos y conseguir reducir los costes y tiempo de desarrollo. Estos objetivos gu´ los requisitos de los modelos de programaci´n usados para ıan o el desarrollo de aplicaciones y los requisitos de los servidores de aplicaciones que las albergan. 5.5. Modelo de programaci´n o Modelo de programaci´n Simple, Orientado a objetos. o Da soporte para componentes de aplicaci´n 3rd party y desarrollo de aplicaciones. o El servidor de aplicaci´n maneja los estados de aplicaci´n. o o Transaccional Soporta unidades de trabajo independientes Posibilita el modelado natural de sistemas as´ ıncronos Independencia de la red 5.6. Basado en est´ndares a “La adopci´n de una infraestructura de bajo coste para las telecomunio caciones probablemente abrir´ las oportunidades de nuevos servicios (aplia caciones), de gran coste hoy en d´ El impacto de los nuevos servicios en ıa. redes convergentes basadas en est´ndares ser´ mas amplio y r´pido de lo a a a que puede ser hoy en d´ ıa,...”[Gartner, Marzo de 2006]. “Las APIs est´ndar abiertas ocultan la complejidad de las redes en la a capa de aplicaci´n, y el uso de se˜ales est´ndares y protocolos de control o n a de llamada son la clave para proveer de flexibilidad y creatividad para los servicios mejorados de redes de proxima generaci´n.”[Yankee Group]. o 5.7. Independencia de la Red Los equipamientos de legado existentes constituyen una gran inversi´n para los opo eradores de redes. Las arquitecturas de redes transicionales probablemente se utilizar´n a por los operadores de redes para adoptar la nueva tecnolog´ Por tanto, ser´ posible ıa. a desplegar aplicaciones en un entorno de aplicaci´n SLEE que use diversos recursos de o redes y protocolos de se˜al. n La integraci´n de un nuevo tipo de elemento de red, protocol de se˜al, o sistema o n externo no requerir´ cambios en la arquitectura central del software del servidor de a aplicaciones. Este requisito se satisface gracias al Resource Adaptor Framework que da
- 66. ˜ CAP´ ITULO 5. DISENO DE APLICACIONES JAINSLEE 34 soporte a la integraci´n de nuevos Resources. o Ejemplos de Resources incluidos: Java Call Control SIP SMPP, MM7 CAMEL (CAP), TCAP, MAP, INAP OSA/Parlay 5.8. Portabilidad Los proveedores de equipos para redes y los operadores de redes tienen un hardware y Sistemas Operativos preferidos. Las aplicaciones que se ejecutan bajo un entorno de aplicaciones Jain SLEE tienen que tener las siguientes caracter´ ısticas: Las aplicaciones tienen que ser capaces de ejecutarse bajo plataformas diferentes sin cambios. El c´digo fuente de las aplicaciones no tiene que requerir ninguna modificaci´n o o cuando se traslada entre plataformas. Las aplicaciones tienen que ser independientes de la arquitectura hardware y de APIs a nivel de sistema (Ej. POSIX1 , WIN322 , etc.) Portable Operating System Interface Unix (POSIX) 1 2 Portable Operating System Interface Unix API de Windows
- 67. Cap´ ıtulo 6 Modelizado de Componentes 6.1. Abstracciones y Conceptos Podemos centrar las principales abstracciones y conceptos de SLEE como: Evento y tipo de Evento Componente SBB, gr´fico de componente SBB, y ra´ de componente SBB a ız Entidad SBB, ´rbol de entidad SBB, y ra´ de entidad SBB a ız Borrado en cascada de un sub´rbol de entidad SBB a Clase abstracta SBB y objeto SBB Interfaz local SBB y objeto local SBB Activity, objeto Activity, y Activity Context Como SLEE reclama un ´rbol de entidad SBB y asocia entidades SBB de forma a descendente Interfaz Activity Context Interface y objeto Activity Context Interface Profile, Tabla de Profiles, y Especificaci´n de Profiles o Servicio Unidad Desplegable Interfaz de manejo 6.2. Eventos En un entorno manejado como SLEE las referencias directas no son aceptables para ser usadas dentro de un cuerpo de m´todo unico. El desarrollador debe estar preocue ´ pado de adjuntarlo a un bus de eventos, y recuperarlo del bus de eventos dentro de una transacci´n. Un evento representa una ocurrencia que debe requerir de procesado o 35
- 68. 36 CAP´ ITULO 6. MODELIZADO DE COMPONENTES por parte de la aplicaci´n. Este contiene informaci´n que describe la ocurrencia, tal o ´ o como la fuente del evento. Un evento puede originarse desde diferentes fuentes, por ejemplo un adaptador externo un protocolo de pila de comunicaciones, desde el mismo SLEE, o desde componentes dentro de SLEE. Los eventos son una abstracci´n usada o para modelar ocurrencias que no est´n relacionadas con un hilo particular de ejecuci´n. a o Por ejemplo consideremos una llamada de tel´fono entre dos personas, A y B. A e puede llamar a B en cualquier instante. La ocurrencia de A llamando a B puede ser modelada como un evento y la ocurrencia de B respondiendo el tel´fono puede ser mode elado como otro evento. SLEE usa el modelo publish/subscribe para la distribuci´n de eventos. Los SBBs o adjuntan y recuperan al Activity Context para la distribuci´n de eventos. o La arquitectura SLEE no permite a los SBBs registrarse ellos mismos de forma expl´ ıcita como listeners de un recurso, no sigue el modelo de eventos de JavaBean. En el modelo SLEE los Resource Adaptors tienen subscripciones de eventos a terceros y arbitraci´n a SLEE, lo que permite a los Resource Adaptors ser consistentes en o su modelo de eventos. 6.2.1. Comportamiento del enrutado de eventos Los eventos son as´ ıncronos, por lo tanto el hecho de lanzar un evento no significa que una llamada que ya est´ en curso sea bloqueada. Cuando un evento es lanzado a dentro de una transacci´n, se pone dentro de una cola de eventos y el m´todo de lano e zado vuelve (p.e. si un SBB lanza un evento que deber´ recibir ´l mismo, el evento es ıa e puesto en la cola para su reparto y el m´todo de lanzado vuelve inmediatamente. e Para cada tipo de evento recibido por el SBB, el desarrollador de este debe implementar un m´todo que lo maneje, la entrega de eventos se realizar´ a trav´s de la e a e invocaci´n del m´todo apropiado que maneje tal evento dentro del SBB. Si varias eno e tidades SBB est´n interesadas en el mismo evento, el SLEE define el orden de entrega a del evento mediante las prioridades. Para cada tipo de evento lanzado por el SBB, el desarrollador del SBB tiene que declarar un m´todo abstracto de lanzamiento de eventos, este m´todo abstracto se e e implementa por SLEE en tiempo de despliegue. 6.2.2. Subscripci´n de eventos o La subscripci´n de eventos es declarativa, los SBBs declaran los tipos de eventos o recibidos y el SBB ra´ declara los tipos de eventos iniciales. El SLEE habilita mecanız ismos de filtrado de eventos para reducir la acumulaci´n de eventos recibidos,los filtros o de eventos pueden existir sin SLEE o pueden ser empujados al recurso. SLEE y los RAs trabajan conjuntamente para actualizar la suscripci´n de eventos en recursos de forma o autom´tica. Una entidad SBB puede enmascarar y desenmascarar tipos de eventos de a cada Activity Context adjunto.
- 69. 6.3. ACTIVITY Y ACTIVITY CONTEXT 6.2.3. 37 Filtrado de eventos SLEE puede crear sus propios objetos filtro de eventos, el Resource no puede saber antes de tiempo los eventos en los que SLEE est´ interesado. a El SLEE ense˜ar´ al Resource la informaci´n de filtrado de evento a trav´s de su n a o e objeto proveedor. Por ejemplo, JCC desplegar´ el JccListener apropiado en el switch, ıa la direcci´n provista y la informaci´n del evento a trav´s del mecanismo de filtro de o o e eventos de JCC. La implementaci´n del proveedor JCC es capaz de modificar su base o de datos cuando el SLEE ense˜a al proveedor a crear objetos filtros de eventos desde n la informaci´n contenida en los filtros de eventos. o La especificaci´n SLEE no autoriza que la plataforma del Resource y SLEE como partan un esquema de bases de datos com´n. El observador del lanzador dentro de u la plataforma del resource y el mecanismo de subscripci´n dentro de SLEE no tienen o porqu´ estar sincronizados. Es tambi´n posible para SLEE ser estricto en la integraci´n e e o con una plataforma Resource particular y usar un mecanismo estricto de filtro asociado. 6.2.4. Eventos Usuales y no Usuales Los eventos Usuales y no Usuales deber´ ser tratados de la misma forma por el ıan enrutador de eventos. Los eventos Usuales son definidos por el desarrollador del SBB, los requisitos de tales eventos son definidos por la especificaci´n de SLEE. Estos eventos se usan para o la comunicaci´n entre componentes. o Los eventos No Usuales son definidos por SLEE y los RA, sus requisitos pueden ser mayores o menores dependiendo de la implementaci´n de SLEE y de la fuente o subyacente de los eventos. SLEE tiene flexibilidad ante el vendedor en la adaptaci´n o de los Resources existentes, con lo que los eventos No Usuales no necesitan seguir las reglas extra que define SLEE para los eventos Usuales. 6.3. Activity y Activity Context 6.3.1. Activity Definimos Activity como la abstracci´n para una cadena de eventos relacionados. o Por ejemplo,un tel´fono emitiendo eventos como conectando, desconectando, etc. ´ un e o aparato de localizaci´n m´vil emitiendo eventos de actualizaci´n de localizaci´n. o o o o Como muestra la figura los eventos son conducidos solo a las entidades SBB que est´n interesadas en ellos. a
- 70. CAP´ ITULO 6. MODELIZADO DE COMPONENTES 38 Figura 6.1: Eventos de Activity 6.3.2. Activity Context Definimos Activity Context como un objeto de dominio SLEE para encapsular la Activity definida por los Resources. Se trata pues de un canal de eventos en el cual los eventos son lanzados y distribuidos. Mantiene los estados compartidos considerando la Activity, existen relaciones de adjunci´n muchos a muchos (varios SBB pueden o adjuntar la misma Activity)y los SBBs s´lo reciben eventos de las Actividades adjuntas. o Figura 6.2: Eventos de Activity Context. 6.3.3. Activity y Activity Context Decimos que un objeto Activity es un objeto Resource, ya que representa alg´n u sistema Resource que encapsula un flujo de eventos. Un unico Activity s´lo puede ´ o procesar un evento al mismo tiempo. Por otro lado tenemos que un ActivityContext es la representaci´n SLEE de un o Resource Activity. Los SBBs reciben eventos del ActivityContext gracias a el ActivityContextInterface, que representa c´mo ven los SBBs los ActivityContext. Los SBBs o pueden leer y escribir estados en un ActivityContext. Cada ActivityContext tiene la relaci´n 1 a 1 con el objeto Activity. o
- 71. 6.3. ACTIVITY Y ACTIVITY CONTEXT 39 Cada SBB define una interfaz Java que representa su vista sobre el estado grabado en el ActivityContext, esto provee de tipos seguros y reduce fallos. 6.3.4. Activity context y eventos El Activity Context es un medio para relacionar los productores de eventos con los consumidores de eventos. Se comporta como un bus de eventos. Los eventos son lanzados y recibidos en ´l. Las entidades SBB adjuntas al bus de eventos reciben el e evento si no lo ocultan. Un consumidor tiene que estar adjunto a un Activity Context para recibir eventos lanzados dentro de ´ste. e La ventaja es que agregarse a un Activity Context hace la misma funci´n que a˜adir o n un listener. Las entidades SBB que escuchan al mismo tipo de evento normalmente se adjuntar´n a diferentes Activity Contexts y tan s´lo recibir´n los eventos lanzados a o a dentro de los Activity Contexts a los que est´n adjuntos. a 6.3.5. Agregar/Separar en Activity Context El hecho de agregar o separar Activity Context lleva consigo las siguientes caracter´ ısticas: Desvincula el consumidor y el productor de eventos. Permite al SLEE dar prioridad a la entrega de eventos. Habilita operaciones transaccionales. Reemplaza las referencias a objetos con alg´n objeto de “identidad distribuible”. u Reemplaza el concepto de Listener add/remove en el modelo de eventos de JavaBeans por sistemas distribuidos. La industria camina hacia la integraci´n de mensajes basado en publish/subscribe. o La aproximaci´n al listener es lo equivalente a una integraci´n enterprise punto o o a punto. 6.3.6. Ejemplo de JCC Activity Context Tenemos que los objetos Activity definidos por un resource JCC son JccConnection y JccCall. Suponemos que una nueva llamada llega al SLEE. Esta llamada tiene un pie de llamada en el cual est´ interesado un SBB. El objeto JccConnection pasa el evento a CONNECTION ALERTING al ActivityContext del Activity representando por el pie de llamada y el SBB recibe el evento. El SBB decide que quiere desconectar la conexi´n. Para hacerlo el SBB necesita el o objeto Activity desde el ActivityContext: public void onAlertingEvent(JccConnectionEvent event, ActivityContextInterface ac){ JccConnection connection = (JccConnection)ac.getActivity(); connection.release(); }
- 72. CAP´ ITULO 6. MODELIZADO DE COMPONENTES 40 Suponemos que se realiza una nueva llamada desde un SBB: JccProvider provider = (JccProvider) new InitialContext.lookup("location"); JccCall call = provider.createCall(args); Para recibir eventos en esta llamada, el SBB tiene que obtener un ActivityContext del nuevo Activity, a trav´s del ActivityContextInterfaceFactory del resource: e ActivityContextInteface ac = JccActivityContextInterfaceFactory.getActivityContextInterface(call); ac.attach(sbbLocalObject); 6.4. SBB y Servicios 6.4.1. Service Building Block (SBB) El elemento de reuso definido por Jain SLEE es el Service Building Block (SBB). Un SBB es un componente software que env´ y recibe eventos y lleva a cabo l´gica ıa o computacional basada en la recepci´n de eventos y su estado actual. Los SBBs son o componentes de estado y como tales pueden recordar los resultados de computaciones previas y tales resultados pueden ser aplicados en las posteriores computaciones. Un SBB puede estar compuesto de otros SBBs. De ese modo se pueden habilitar aplicaciones m´s complejas al ser construidas a partir de una colecci´n de SBBs. Los SBBs a o llevan a cabo l´gica basada en la recepci´n de eventos. Una definici´n de SBB ino o o cluye informaci´n que describe el SBB (por ejemplo el nombre, vendedor, y versi´n del o o SBB), cualquier evento que el SBB recibe, y c´digo de programa que provee al SBB de o la l´gica. El c´digo de programa para un SBB est´ compuesto por clases Java. o o a 6.4.2. Servicios Un servicio en la terminolog´ Jain SLEE es una unidad reemplazable de manejo de ıa campos. El sistema administrador de Jain SLEE controla el ciclo de vida (incluyendo el despliegue, repliegue y actualizaci´n en l´ o ınea) de un servicio. El manejo del ciclo de vida se consigue a trav´s del uso de interfaces de manejo est´ndar que provee Jain SLEE. e a Un servicio incluye informaci´n que lo describe, por ejemplo el nombre, el vendedor y o su versi´n, y m´s c´digo de programaci´n que forma parte del servicio. El c´digo del o a o o o programa puede incluir clases Java, Perfiles (Profiles) y Bloques de Construcci´n de o Servicios (SBB). 6.4.3. Conexi´n entre SBBs y Servicios o Un SBB es un componente programado de un servicio. Una instancia del Servicio puede contener una o varias instancias SBBs de diferentes tipos de SBBs. A su vez el mismo tipo de SBB puede ser incluido en varios tipos de Servicios. Un unico SBB tan solo puede procesar un evento al mismo tiempo, pero varios ´ SBBs pertenecientes al mismo Servicio pueden procesar eventos en paralelo.
- 73. 6.4. SBB Y SERVICIOS 6.4.4. 41 Desarrollando un SBB La especificaci´n SLEE define la interfaz SBB, dicha interfaz es la base definida por o la especificaci´n SLEE y est´ incluida en el archivo jar de SLEE. o a El desarrollador de SBB implementa la clase abstracta de SBB a trav´s de la ime plementaci´n del interfaz SBB. Cada SBB creado por el desarrollador debe proveer o una clase SBB abstracta que implemente la interfaz SBB base. La clase SBB abstracta contiene c´digo del desarrollador para el ciclo de vida tal como callbacks, m´todos o e manejadores de eventos, y m´todos abstractos de lanzamiento de eventos. e Las herramientas de despliegue de SLEE generan la clase concreta del SBB a trav´s e de la implementaci´n de la clase SBB abstracta. Una clase SBB concreta es generada o por SLEE cuando el SBB es desplegado dentro de un contenedor. El desarrollador SBB no implementa la clase SBB concreta. Las herramientas de despliegue implementan la clase SBB concreta a trav´s de la extensi´n de la clase SBB abstracta prove´ por el e o ıda desarrollador.
- 74. 42 CAP´ ITULO 6. MODELIZADO DE COMPONENTES Figura 6.3: L´gica de los SBBs. o Figura 6.4: M´todos que implementan la l´gica de los SBBs. e o
- 75. 6.4. SBB Y SERVICIOS 6.4.5. 43 Entidades SBB Definimos una entidad SBB como la instancia de un componente SBB. Se trata de una entidad l´gica. En la forma m´s simple hay una entidad SBB por cada instancia o a de servicio. Un SBB representa el estado de persistencia por instancia de una instancia del componente SBB. Existen algunas representaciones dirigidas del estado que tienen propiedades transaccionales. Las representaciones dirigidas podr´ estar en la memoıan ria del proceso, la memoria replicada, en un disco, en una cinta de resguardo, etc. El estado por instancia de una instancia SBB se define por los campos CMP en la clase SBB abstracta del componente SBB. Una entidad SBB ra´ es el nodo ra´ dentro del ´rbol de entidades SBB y es una ız ız a instancia de un SBB ra´ Es instanciada por SLEE para procesar sus eventos iniciales. ız. 6.4.6. ´ Arboles de entidades SBB Una entidad SBB siempre existe dentro de un ´rbol de entidades SBB. Este ´rbol se a a encuentra siempre dentro del contexto de una instancia de un servicio, que viene a ser la unidad desplegable en SLEE. Esta unidad desplegable es como SLEE conoce como instanciar componentes en tiempo de ejecuci´n para manejar llamadas de tel´fono o o e actividades. El SBB ra´ del servicio maneja el evento inicial, est´ subordinado al selector del ız a evento inicial en el descriptor del despliegue del SBB. Un ´rbol de entidades SBB, como el de a continuaci´n, muestra las relaciones entre a o padres e hijos. ´ Figura 6.5: Ejemplo de Arbol de Entidades SBB. SLEE es el padre l´gico de todas las entidades SBB ra´ o ız. Las entidades SBB ra´ son instancias de SLEE instanciadas por SBBs ra´ ız ız.
- 76. 44 CAP´ ITULO 6. MODELIZADO DE COMPONENTES El orden de entrega de los eventos va por prioridades, y en primer lugar se entrega al padre y despu´s al hijo. e Se realiza un borrado en cascada de las entidades SBB que forman un sub´rbol. a 6.4.7. Entidades SBB padres e hijos El modelo de entidades SBB es c´ ıclico. El SLEE crea las entidades SBB padres, a su vez los SBB padres crean las entidades SBB hijos, y as´ contin´an. ı u El SBB padre tiene acceso a los objetos hijos relacionados. Usa el m´todo “get” e de la relaci´n con su hijo declarado por el desarrollador en la clase abstracta del SBB o padre. La entidad SBB padre puede obtener un objeto SBB local que represente a ´l mismo. e Usa el m´todo getSBBLocalObject en su objeto SbbContext. La entidad SBB padre e puede pasar este objeto SBB local a cualquier objeto hijo que ´l cree. Normalmente e ´sto se hace definiendo un m´todo en la interfaz de los SBBs hijos locales deseando ser e e usadas por el SBB padre para pasar informaci´n a la entidad SBB hijo. o El siguiente gr´fico muestra las relaciones entre los SBB padres y los SBB hijos. a Figura 6.6: Gr´fico relaciones SBB padres y SBB hijos. a 6.4.7.1. Ejemplo de creaci´n de un SBB hijo o Una aplicaci´n CallForwarding puede estar compuesta por una aplicaci´n Call y o o otra aplicaci´n Forwarding. Esto puede ser implementado por un SBB padre (CallForo wardingSBB) con dos SBBs hijos, Ej. CallSbb y ForwardingSbb respectivamente. En el SBB padre (CallForwardingSbb) tienes que definir dos m´todos que habilie tar´n la recuperaci´n de los objetos ChildRelation: a o
- 77. 6.4. SBB Y SERVICIOS 45 public abstract class CallForwardingSbb implements Sbb { public abstract ChildRelation getCallSbb(); public abstract ChildRelation getForwardingSbb(); } SLEE implementa los m´todos de acceso a las relaciones con los hijos, de ah´ que e ı los m´todos sean abstractos en la clase SBB. e El desarrollador de la aplicaci´n SBB invoca al m´todo crear en el objeto Chilo e dRelation: public class CallChildRelation implements ChildRelation { public SbbLocalObject create() ..... { SbbLocalObject local = new CallSbbLocalObject(); return local; } } SLEE crear´ una nueva entidad SBB, el m´todo de ciclo de vida sbbCreate es a e llamado en un objeto SBB, como parte de la creaci´n de la entidad SBB. El Sbo bLocalObject de la entidad SBB es devuelto a la aplicaci´n. o 6.4.8. Objetos SBB Un objeto SBB es una instancia de una clase SBB abstracta. Este objeto tiene un ciclo de vida. Ej. No existe, est´ estancado (Pooled) o est´ listo (Ready). a a Un objeto SBB est´ “vinculado” a una entidad SBB particular durante el tiempo de a invocaci´n al m´todo. Cuando un objeto SBB esta en el estado Ready, el objeto SBB ha o e sido asignado a una entidad SBB. Este objeto funciona en nombre de la entidad SBB y puede acceder al estado persistente de la entidad SBB. Despu´s de esta invocaci´n es e o posible que la entidad SBB contin´e existiendo, pero no hay ning´n objeto SBB ligada u u a esta. Una colecci´n de objetos SBB podr´ representar una entidad. Estos objetos pueden o ıa estar en la misma o distintas JVM, pero s´lo pueden actuar sobre la misma entidad o SBB. 6.4.8.1. Objetos SBB locales La arquitectura SLEE permite el control de aplicaci´n, dependiente de la m´quina o a de estados que compone y a trav´s de componentes usa la interfaz SBB local. Hae bilita el control de aplicaci´n sobre qu´ componentes est´n adjuntos o separados del o e a Activity Context, de ah´ que estos componentes reciban eventos. Se dan reemplazamienı tos para el dinamismo del modelo del Listener add/remove en un entorno altamente disponible, concurrente y distribuido. La aplicaci´n tiene suficiente conocimiento para o hacer arbitraci´n din´mica ya que los componentes est´n coescritos o por lo menos o a a tiene suficientes caracter´ ısticas de una API para permitir el control.
- 78. 46 CAP´ ITULO 6. MODELIZADO DE COMPONENTES Entidad SBB Instancia de SBB Una entidad l´gica o Representa el estado persistente de SBB (como define los campos CMP) Mantiene relacciones con otras entidades, ej. ActivityContext adjuntos, entidades SBB padres e hijos, su entidad de servicio Objeto SBB Instancia de una clase SBB abstracta Un objeto Java Oculta estados persistentes de una entidad SBB Tiene un ciclo de vida (puede estar estancado) Puede ocultar diferentes entidades SBB a lo largo de su tiempo de vida Tabla 6.1: Entidades SBB y Objetos SBB Una interfaz SBB local es b´sicamente una versi´n local de un Proxy remoto, y no a o una referencia a un objeto SBB. Las operaciones en un SbbLocalObject son pasadas a trav´s del objeto SBB que est´ representando a la entidad SBB. Usando el modelo e a de control delegado y control coordinado, un componente recibe una evento y decide si deber´ comunicar a su coordinador que ha acabado con el evento a trav´s de la invoıa e caci´n al m´todo local. El coordinador de control es invocado en la misma transacci´n, o e o adjunta otro SBB y llama a startWithActivity en ese SBB. La transacci´n se acomete o y el intercambio de adjunto y separado es at´mico. o 6.4.9. Entidades SBB y objetos SBB Dependiendo de los requerimientos de tama˜o de un servicio particular, en un inn stante de tiempo en particular podr´ haber n objetos SBB y m entidades SBB. Si n ıa es menor que m, habr´ m-n entidades SBB que no tienen objetos SBB enlazadas a ellas. a SLEE tiene que entender la relaci´n de eventos que existe entre el consumidor y el o productor en el nivel de entidad antes que en el nivel de objeto, debido a la indirecci´n o entre los objetos SBB y las entidades SBB. Ej. La entidad SBB es distinta al objeto SBB. El estado de la entidad SBB no est´ relacionado directamente con el estado del a objeto java que se usa para una invocaci´n particular de esta entidad. o Por ejemplo una entidad SBB puede ser guardada usando una base de datos, el objeto SBB puede ser recolectado como basura, pero la entrada todav´ existe en la ıa base de datos. SLEE tiene que asegurarse que en la base de datos no haya fugas porque el programador pierde referencias. El mecanismo de referencias en Java puede ser usado para la recolecci´n de entidades SBB basura. o
- 79. 6.4. SBB Y SERVICIOS 47 Figura 6.7: Relaci´n Entidades SBB y Objetos SBB. o 6.4.10. Prioridad de los SBBs La prioridad en los SBBs se define para permitir un modo de arbitraci´n simple o entre componentes independientes. Estos son componentes que no est´n coescritos por a un desarrollador. SLEE no requiere que todas las interacciones est´n codificadas. e Por ejemplo dos componentes que no se hay escrito conjuntamente puede pasar que reciban eventos en la misma actividad. Entonces hay dos opciones: 1. Generalmente se usa el mecanismo de prioridad para tratar con esta interacci´n, o el componente con la mayor prioridad se ejecutara primero. 2. La otra opci´n es que el operador/administrador si fuera necesario puede codificar o las interacciones. Un evento es entregado en orden a cada entidad Sbb que est´ interesada en recibir a dicho evento. Una entidad Sbb padre siempre recibe el mismo evento antes que su entidad Sbb hijo. La prioridad de entrega de eventos de una entidad Sbb determina el orden en que los Sbb hermanos reciben el evento. El Sbb padre especifica una prioridad de entrega de eventos por defecto para cada relaci´n hijo. Cuando una entidad Sbb padre crea una entidad Sbb hijo, SLEE asigna o la prioridad de entrega de eventos por defecto especificada por la relaci´n hijo a la o entidad Sbb hijo. Estas prioridades pueden cambiarse en tiempo de ejecuci´n. o La entrega prioritaria de eventos de una entidad Sbb se determina de la siguiente manera: El elemento default-priority del servicio: El elemento descriptor desplegable de un Servicio especifica la prioridad de entrega de eventos de la entidad Sbb ra´ ız instanciado a trav´s de SLEE por el Servicio. e
- 80. CAP´ ITULO 6. MODELIZADO DE COMPONENTES 48 El elemento default-priority en el elemento get-child-relation-method del Sbb padre, especifica la prioridad inicial de las entidades Sbb hijo creadas en esta relaci´n hijo. Una entidad Sbb padre puede modificar la prioridad de entrega de o una entidad Sbb hijo en tiempo de ejecuci´n invocando el m´todo setSbbPrioro e ity en un objeto Sbb local que represente la entidad Sbb hijo. La prioridad de entrega de eventos de una entidad Sbb es un entero que est´ dentro a del rango -128 a 127 ambos incluidos. Siendo -128 la prioridad m´s baja y 127 la m´s a a alta. A continuaci´n mostramos una peque˜a gu´ para los desarrolladores acerca de o n ıa c´mo asignar prioridades: o 100 a 127 para prioridad de entrega de eventos m´s alta: a Entidades Sbb hijo de la misma entidad Sbb padre con la prioridad de entrega de eventos m´s alta recibir´n el evento primero. a a 31 a 99 para prioridad de entrega de eventos alta: Entidades Sbb hijo de la misma entidad Sbb padre con la prioridad de entrega de eventos alta recibir´n los eventos antes que las entidades Sbb hijo de la misma a entidad Sbb padre con prioridad de entrega de eventos est´ndar. a -30 a 30 para prioridad de entrega de eventos est´ndar: a Entidades Sbb hijo de la misma entidad Sbb padre con la prioridad de entrega de eventos est´ndar recibir´n los eventos antes que las entidades Sbb hijo de la a a misma entidad Sbb padre con prioridad de entrega de eventos baja. -99 a -31 para prioridad de entrega de eventos baja: Entidades Sbb hijo de la misma entidad Sbb padre con la prioridad de entrega de eventos baja recibir´n los eventos despu´s que las entidades Sbb hijo de la misma a e entidad Sbb padre con prioridad de entrega de eventos est´ndar. a -128 a -100 para prioridad m´s baja: a Entidades Sbb hijo de la misma entidad Sbb padre con la prioridad de entrega de eventos m´s baja recibir´n los eventos las ultimas. a a ´ Las prioridades pueden ser cambiadas en tiempo de ejecuci´n a trav´s del m´todo o e e setSbbPriority(Prioridad int), y se puede obtener a trav´s del m´todo getSbbPriorie e ty. Ambos m´todos se encuentran dentro de un objeto Sbb local que representa las e entidades. 6.4.11. Acople de los atributos SBB Cada SBB especifica los atributos que est´ dispuesto a compartir con otras entia dades SBB en el SBB Activity Context Interface. Por defecto estos atributos pueden ser compartidos entre entidades SBB del mismo componente SBB. No son accesibles por las entidades SBB de otros SBBs para evitar la compartici´n unidireccional resulo tante de dos SBBs desarrollados independientemente, y que tienen el mismo nombre de atributo siendo estos atributos sem´nticamente distintos. a
- 81. 6.4. SBB Y SERVICIOS 49 El acople de atributos en el Activity Context dirige a SLEE para hacer que los atributos declarados en entidades SBB diferentes se comporten l´gicamente como un o atributo unico. Este atributo l´gico puede ser actualizado a trav´s de cualquier m´to´ o e e do set de los atributos de los ancestros acoplados. Los cambios en el atributo l´gico o son observables a trav´s de cualquier m´todo get perteneciente a los atributos de los e e ancestros acoplados. Los atributos compartidos definidos en el SBB Activity Context Interface del SBB no son compartidos con otras entidades SBB a menos que exista un acople expl´ ıcito.Por ejemplo: - SBB1 define un atributo ’forwardCounter’ - SBB2 define un atributo ’followCounter’ Sem´nticamente ambos significan lo mismo. Pueden ser acoplados a ’counter’ y a compartidos en el SBB Activity Context. 6.4.11.1. Ejemplo Counter SBB Las clases SBB abstractas para el contador SBB: El SBB contador usa el estado CMP para salvar el valor actual del contador. Este campo CMP es de tipo entero. El SBB contador tiene cuatro m´todos en su interfaz SbbLocalObject de tipo: e void increment(), void decrement(), getValue() y void reset(). La implementaci´n de estos metodos en la clase SBB abstracta son: o public void increment(){setCounter(getCounter()+1);} public void decrement(){setCounter(getCounter()-1);} public int getValue(){return getCounter();} public void reset(){setCounter(0);} // m´todos de acceso para el field called counter e public abstract void setCounter(int val); public abstract int getCounter(); El estado de la entidad SBB es el estado del campo CMP, en este caso del campo CMP counter. Las instancias de objetos diferentes pueden actuar en la misma entidad considerando el siguiente escenario: 1. Un SBB invoca operaciones: CounterSbbLocalObject counter = getCounterSbb(); // usando un campo CMP como objeto local counter.reset(); counter.increment();
- 82. CAP´ ITULO 6. MODELIZADO DE COMPONENTES 50 2. La transacci´n se efectua. o 3. La m´quina que pasa 1 estaba funcionando continuando fallos. a 4. Otra maquina JVM invoca: CounterSbbLocalObject counter = getCounterSbb(); // obtiene un objeto de la misma entidad // counter.getValue() es todav´a 1 ı Los objetos SBB no son el mismo en 1 y 4 porque est´n en diferentes JVMs, sin a embargo el estado SBB continua verdadero a lo largo de las JVMs. 6.5. Profiles (Perfiles) Un Profile Jain SLEE contiene datos almacenados. Estos datos almacenados tienen un esquema, que es un conjunto de atributos o propiedades. Por ejemplo un n´mero de u tel´fono y una direcci´n email para un individuo puede ser considerado dos atributos e o para el Profile. Jain SLEE tambi´n define el concepto de Profile Specification. Un e Profile Specification incluye interfaces de manejo para modificar o actualizar un Profile, definiendo el esquema de un Profile y la l´gica esto puede ejecutarse para asegurarse o que el Profile es v´lido. Los SBB que funcionan dentro de Jain SLEE pueden acceder a a los profiles como parte de su l´gica de aplicaci´n. o o 6.5.1. Especificaci´n de Profiles o Figura 6.8: Especificaci´n de Profiles o La especificaci´n de Profiles define: o El esquema (atributos) de la tabla de profiles ( y profiles en tabla de profiles).
- 83. 6.5. PROFILES (PERFILES) 51 Interfaces y clases de la Especificaci´n de Profile. o Las Tablas de Profiles se crean a partir de la Especificaci´n del Profiles, y contienen o los Profiles. Figura 6.9: Especificaci´n de Profiles II o
- 84. CAP´ ITULO 6. MODELIZADO DE COMPONENTES 52 6.6. Transaction y Timers 6.6.1. Transactions Las Transactions son requeridas en primera instancia para simplificar el trabajo del desarrollador SBB. SLEE usa las transactions para hacer mas f´cil el desarrollo de a aplicaciones a trav´s de un control de concurrencia bien conocido y un modelo de fallos. e Los beneficios clave que SLEE deriva de las transacciones son: Plantillas para el control concurrente Consistencia cuando el JVM falla en medio de un c´digo SBB o Las transacciones son un modelo bien definido y eficaz. La infraestructura para implementarlas (para AC o SBB), ser´ reusada para soportar transacciones para cada a entidad. La complejidad de soportar transacciones m´s all´ de una unica entidad es la a a ´ coordinaci´n de transacciones. o Otro uso de las transacciones es la demarcaci´n: o Para replicar un estado a otros nodos (redundancia basada en memoria). Para un almacenamiento estable (redundancia basada en disco). 6.6.2. Timers Los temporizadores usan modelos de eventos nativos. Los temporizadores pueden estar retrasados cuando: El contenedor est´ sobrecargado. a El contenedor o proceso de contenedor ha fallado y se ha reiniciado. El contenedor se ha parado y reiniciado. Cuando se retrasan los timers se pueden hacer las siguientes cosas: Preservar TODO. Preservar NADA. ´ Preservar ULTIMO. Un modelo temporizador bien especificado, contiene un reloj y un calendario de resoluci´n. Existe pseudo c´digo para la construcci´n de tal modelo. o o o
- 85. 6.7. RESOURCE ADAPTORS 6.7. 53 Resource Adaptors Los Resources son entidades externas que interact´an con otros sistemas fuera de u 1 , MSC2 , etc) , protocolos de pila, directorios SLEE, tales como elementos de red (HLR o ´ bases de datos. Un Resource Adaptor adapta la interfaz particular y los requisitos de un Resource dentro de las interfaces y requisitos de Jain SLEE. Estos Resources pueden o no tener APIs Java. Los Resources con APIs java incluyen agentes de llamadas por lo que soportan la API Java Call Control, servicios Parlay/OSA, varios protocolos de pila y soporte para bases de datos con la API JDBC3 . Estas APIs definen clases Java o interfaces para representar los eventos emitidos por el Resource. Por ejemplo, la API JCC define JccCallEvent y JccConnectionEvent para representar eventos de llamada y conexi´n. Las se˜ales JccConnectionEvent tienen o n eventos como alerta de conexi´n y conectando. o La arquitectura SLEE define c´mo las aplicaciones que se ejecutan dentro de SLEE o interact´an con los Resources a trav´s de los Resource Adaptors. Los Resource Adaptors u e adaptan Resources a los requisitos de SLEE. La arquitectura SLEE define los siguientes conceptos de Resource Adaptors: Tipo Resource Adaptor: Un tipo Resource Adaptor declara las caracter´ ısticas comunes de un conjunto de Resource Adaptors. Define las interfaces Java implementadas por los Resource Adaptors del mismo tipo. Una de estas interfaces es conocida como la interfaz Resource adaptor. Tambi´n define los tipos de evene tos lanzados por los Resource Adaptor del mismo tipo. La especificaci´n SLEE o incluye recomendaciones no normativas para los Resource Adaptors JCC, SIP, y TCAP. Normalmente, un tipo Resource Adaptor se define por una organizaci´n o colaboradora con SLEE o por vendedores de Resources, como pueden ser “SLEE expert group”. Resource Adaptor: Un Resource Adaptor es una implementaci´n particular de un o tipo Resource Adaptor. Puede haber m´ltiples implementaciones del mismo tipo u RA. Un RA consiste en un conjunto de clases Java y su descriptor de despliegue. Tiene que incluir las clases Java que implementa la interfaz RA de su tipo RA. T´ ıpicamente, un RA es desarrollado por un vendedor de Resources o por un vendedor SLEE, para adaptar una implementaci´n de un Resource particular a o SLEE. Por ejemplo, el vendedor A que tiene el Resource JCC puede proveer del RA JCC (i.e. un RA del tipo RA JCC) o un vendedor SLEE B puede proveer de un RA JCC que adapte el Resource JCC de A a su SLEE. En ambos casos, el RA JCC incluir´ las clases Java de la implementaci´n JCC y las clases java que a o adaptan la implementaci´n JCC a SLEE. o Entidad Resource Adaptor: Una entidad RA es una instancia de un RA. M´ltiples u entidades RA pueden estar instanciadas por el mismo RA. Por Ejemplo, un RA 1 Home Location Register Mobile Switching Center 3 Java DataBase Connectivity 2
- 86. CAP´ ITULO 6. MODELIZADO DE COMPONENTES 54 JCC que adapte una implementaci´n JCC basada en SIP a SLEE puede aceptar o direcciones IP y n´meros de puerto como parametros. El Administrador puede u instanciar uno de estos RAs JCC para cada par direcci´n IP y n´mero de puerto. o u Una funci´n de las entidades RA es reenviar eventos originados por el Resource o que la entidad RA representa para SLEE. Jain SLEE representa recursos de redes como adaptadores de recursos (resource adaptors) y cada RA tiene un tipo. El tipo RA para JAIN SIP es “javax.sip”. Jain SLEE identifica Eventos a trav´s de los tipos de Eventos. Los eventos Jain SIP e se clasifican en RequestEvents, ResponseEvents y TimeoutEvents, cada una de estas clasificaciones contienen muchos tipos. Por ejemplo el tipo de evento para un mensaje Request de tipo ’INVITE’ es ’javax.sip.RequestEvent.Request.INVITE’. Jain SLEE representa el flujo de eventos como Activities. Los objetos Activity en JAIN SIP son ClientTransactions (inicializados localmente) y ServerTransactions (inicializados remotamente). 6.8. Controles de Concurrencia en SLEE Hay tres controles de concurrencia en SLEE: 1. Un unico evento es procesado en una Actividad en cualquier momento: ´ Un objeto SBB sirve un unico evento cada vez, por lo tanto la entrega de eventos ´ a un objeto SBB unico se hace por partes. ´ 2. Aislamiento de transacciones concurrentes, que es una transacci´n en proceso o la cual no se ha comprometido ya tiene que continuar aislada de cualquier otra transacci´n: o Hay algunos casos donde una entidad SBB puede estar invocada de forma concurrente a trav´s de m´ltiples objetos SBB que representan la misma entidad SBB e u Los objetos SBB sirviendo diferentes eventos no modifican el estado transaccional, ´stos son de s´lo lectura. e o Si el control de concurrencia optimista es escogido y los objetos SBB modifican el mismo estado transaccional, uno se necesita para abortar. 3. Los objetos SBB nunca recibir´n una invocaci´n concurrente. a o 6.8.1. Ejemplo 2 entidades SBB ambas adjuntas a dos Activity Context distintos y a uno igual: El SBB1 recibe el evento E1 sobre AC1 en TX1 y el SBB2 recibe el evento E2 sobre AC2 en TX2. El SBB1 y el SBB2 quieren modificar el estado transaccional de AC3.
- 87. 6.8. CONTROLES DE CONCURRENCIA EN SLEE 55 Figura 6.10: Ejemplo de Control de Concurrencia SLEE necesita definir la sem´ntica de control de concurrencia para las actualizaa ciones de AC3 a trav´s del SBB1 y el SBB2. TX1 y TX2 tratan de alcanzar la misma e unidad de estado de transacci´n, i.e. ambos se refieren a AC3. o El aislamiento y sem´ntica de acceso entre las transacciones concurrentes determia nar´ que pasa, i.e. pesimista u optimista. a
- 88. 56 CAP´ ITULO 6. MODELIZADO DE COMPONENTES
- 89. Mobicents 57
- 91. Cap´ ıtulo 7 Introducci´n o En el a˜o 2002, los m´viles se convirtieron en dispositivos lo suficientemente pon o tentes como para ejecutar aplicaciones que cualquier desarrollador podr´ construir. En ıa ese a˜o Ivelin Ivanov, comenz´ a pensar, teniendo como base J2EE, sobre el middlen o ware que necesitar´ los futuros dispositivos inteligentes mobiles. Era el comienzo de ıan Mobicents. Mobicents es una plataforma VoIp de c´digo abierto completamente conforme a la o especificaci´n JSLEE 1.0. Mobicents tambi´n implementa algunas de las caracter´ o e ısticas propuestas por JAIN SLEE 1.1. Mobicents aporta a las aplicaciones de telecomunicaciones un modelo de componentes y entorno de ejecuci´n robusto. Este complementa a o J2EE para habilitar convergencia de voz, video y datos en las aplicaciones inteligentes de pr´xima generaci´n. Como Televisi´n por internet, voz por ip, internet etc. o o o Mobicents es el SIP Application Server libre m´s popular para la plataforma Java; a Facilita la implementaci´n de nuevos servicios de un modo simple y r´pido; Permite el o a desarrollo de un Service Delivery Platform (SDP1 ) orientado al mercado y rentable. Al mismo tiempo que Mobicents promueve un entorno est´ndar para que surjan desarrolla adores de aplicaciones al mercado y tomar las ventajas de ( y dar visibilidad tambi´n) e los mejores programadores del web. Al mismo tiempo se crea Mobicents Foundation, una fundaci´n que se esfuerza por o acelerar el avance de Mobicents a trav´s de socios estrat´gicos que ha cambio de donar e e fondos y desarrollar recursos para el proyecto ofrecen acceso al equipo de desarrollo principal y la capacidad de influir en la hoja de ruta del proyecto 11.1. 1 Se refiere a una incorporaci´n reciente de un estilo arquitect´nico aplicado a los problemas de o o infraestructura de telecomunicaciones. Est´ dirigido a permitir desarrollo y despliegue r´pido de nuevos a a servicios multimedia convergentes, desde servicios para viejos tel´fonos POTS2 a complejas conferencias e audio/video para juegos multijugador. 59
- 92. ´ CAP´ ITULO 7. INTRODUCCION 60 En el campo de las telecom Next Generation Intelligent Networks (NGIN3 ), Mobicents encaja como core engine de alto rendimiento para SDP e IMS. Mobicents permite la composici´n de SBBs 6.4.1 como control de llamada, facturaci´n, aprovisionamieno o to del usuario, administraci´n, y presence sensitive features. La arquitectura est´ndar o a extensible acomoda naturalmente la integraci´n de puntos con aplicaciones enterprise o como Web, CRM4 o SOA5 end points. Monitoraci´n y manejo de los componentes de o Mobicents que aparecen en el box via SLEE estandard basado en interfaces JMX6 y SNMP. Esto convierte a los servidores Mobicents en un elecci´n f´cil para los telecom o a OSS7 ) de telecomunicaciones y NMS8 . Adem´s de las telecom, Mobicents es apropiado para una gran variedad de doa minios de problemas que demandan Event Driven Architecture (EDA)para un gran volumen de se˜ales con baja latencia. Por ejemplo operaciones financieras, juegos onn line,almacenamiento y recuperaci´n de datos remoto( RFID9 ) y control distribuido. o 3 Next Generation Intelligent Networks Customer relationship management, Es un t´rmino amplio que cubre conceptos usados por las orgae nizaciones para lograr sus relaciones con clientes, incluyendo almacenamiento y analisis de informaci´n o del cliente. 5 Service-oriented architecture 6 Java Management Extensions 7 Operations Support Systems, son sistemas de computadores usados por proveedores de servicios de telecomunicaciones. 8 Network Management Systems 9 Radio Frequency IDentification 4
- 93. Cap´ ıtulo 8 Caracter´ ısticas 8.1. Entorno Mobicents se ejecuta actualmente desde Jboss-3.2.8-sp1 , necesita JDK 1.4 o superior y Apache Ant para compilar y desplegar sus componentes. Ya que est´ basado en a Java, es multiplataforma. 8.2. JBoss Mobicents utiliza los siguientes componentes de JBoss: JMX Microkernel para el core service IoC y administraci´n o JNDI para el registro de servicios SLEE JTA1 para administraci´n de transacciones o TreeCache para replicaci´n de estados Altamente Disponibles o Mobicents no usa EJB o JMS como una parte de la arquitectura del n´cleo. Los u SBBs y el Router de Eventos son implementados en un principio para peso ligero y alto volumen de se˜ales como est´ se˜alado en la especificaci´n de JSLEE. n a n o 1 Java Transaction API, especifica interfaces Java est´ndar entre un administrador de transacciones y a las partes envueltas en un sistema de transacciones distribuido: el administrador de recursos, el servidor de aplicaciones y las aplicaciones transaccionales. 61
- 94. CAP´ ITULO 8. CARACTER´ ISTICAS 62 8.3. Integraci´n con otros applications servers o Mobicents se integra con otros applications servers como WebSphere, WebLogic y Glassfish, ya que provee una interfaz de conexion JSLEE para cualquier cliente Java, incluyendo servidores EE. Figura 8.1: Application Server 8.4. Rendimiento A partir de la versi´n 1.0.00.CR1 mediante la herramienta open source SIPP han o reportado los siguientes resultados de rendimiento: 100 llamadas SIP por segundo (cps2 ) en una sola CPU de 2Ghz; Linux 370 llamadas SIP por segundo en un 4 way Netra 440; Sun/Solaris Por lo que el rendimiento m´ximo obtenido esta entre las 1000-1200 tps3 . [19] a 8.5. Resource Adaptors Mobicents actualmente tiene los siguientes Resource Adaptors 6.7 disponibles: RA SIP 10.5, usando JAIN SIP RI and extendido con un SIP Registrar b´sico a y Servicios Proxy. RA XMPP/Google Talk 10.7, Usando la libreria Smack. Funciona en modo Cliente y Servidor de Componente. 2 3 1 SIP cps equivale a 5 tps, porque cada llamada SIP implica de 5 a 6 transacciones transacciones por segundo
- 95. 8.6. LICENCIA 63 RA Asterisk 10.1, Usando la librer´ Asterisk-Java. ıa RA Java Call Control (JCC), Implementando las recomendaciones en el Ap´ndice C de JSR 22 - JSLEE 1.0 [7]. e RA Parlay/Parlay-X 10.3, Permitiendo acceso controlado a pasarelas Parlay. RA J2EE/JCA, Implementando las recomendaciones en el Ap´ndice F de JSR e 22 - JSLEE 1.0 [7]. RA Diameter 10.9, Basado en la librer´ Java Diameter de Ivan Skytte Jorıa gensen. RA Media 10.8, Un Media RA b´sico con implementaciones basadas por defecto a en JMF4 . RA SMPP 10.6, Para mensajes SMS. RA Media Gateway 10.2, Para control avanzado de media. RA JCC INAP5 , para integraci´n SS7 INAP6 o RA Persistence 10.4, usa JPA7 para almacenar los datos. RA MSCML8 (En desarrollo) Un Resource Adaptor que usa MSCML sobre SIP para controlar la funcionalidad del servidor media. 8.5.1. Resource Adaptors Hay otros Resource Adaptors disponibles bajo licencias comerciales por terceros vendedores. 8.6. Licencia Mobicents est´ distribuido bajo Licencia dual flexible [20], como MySQL y Asterisk. a La licencia de distribuci´n por defecto es GNU General Public License (GPL9 , es una o licencia creada por la Free Software Foundation, y est´ orientada principalmente a a proteger la libre distribuci´n, modificaci´n y uso de software. Su prop´sito es declarar o o o que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiaci´n que restrinjan esas libertades a los usuarios.), la licencia m´s popular de o a la Free Open Source Software (FOSS) en el mundo. 4 Java Media Framework. Intelligent Network Application Part 6 Intelligent Network Application Part, es un protocolo de se˜ales usado por la arquitectura de redes n inteligentes (IN) 7 Java Persistence API[30] 8 Es un protocolo usado en conjunci´n con SIP para habilitar la entrega de servicios de conferencia o multimedia avanzados a trav´s de redes IP e 9 General Public License 5
- 96. CAP´ ITULO 8. CARACTER´ ISTICAS 64 8.6.1. Licencia Comercial Indicada para los usuarios que consideren adquirir un licencia comercial para redistribuir Mobicents con c´digo propietario u otro servicio onlince comercial basado en o Mobicents. La Licencia Comercial de Mobicents comienza en 2.400$ por un solo servidor mobicents en una m´quina con hasta 4 CPus ( hasta 16 n´cleos en total). a u Adquirir el paquete b´sico permite la licencia para redistribuir c´digo de Mobicents a o con soluciones propietarias as´ como ofrecer servicios online basados en Mobicents. La ı licencia comercial adquirida se aplica para todo el c´digo disponible del repositorio o p´blico de Mobicents por un periodo de un a˜o desde la fecha de la compra. u n El soporte profesional no est´ incluido en el precio de la licencia b´sica; es ofrecia a da como un servicio adicional. Las empresas nunca adquieren licencias sin un soporte asociado, teniendo en cuenta que suele ser el 25 % del coste de la licencia, la licencia b´sica con soporte tendr´ un precio aproximado de 3000$. a a Para adquirir la licencia comercial o pedir m´s informaci´n escribir a a o [email protected]
- 97. 8.7. PATROCINADORES 8.7. Patrocinadores Vendedores que han hecho contribuciones o planean hacerlas: ˆ University of Genova ˆ T-Mobile, ˆ Lucent Technologies ˆ Open Cloud ˆ Aepona ˆ NEC Japan ˆ Motorola ˆ Siemens ˆ JayWay Operadores: ˆ Portugal Telecom Innovacau ˆ Telecom Italia ˆ Telef´nica Espa˜a o n ˆ Vodafone R&D ˆ Volgograd GSM Russia Otros: ˆ NIST Advanced Networking Technologies Division. ˆ Universita Degli Studi Di Genova ˆ JBoss ˆ XMPP4J 8.8. Proyecto Mobicents 8.8.1. Componentes 8.8.1.1. Tecnolog´ ıa Ivelin Ivanov (Fundador) M. Ranganathan- Ranga 65
- 98. CAP´ ITULO 8. CARACTER´ ISTICAS 66 Eduardo Martins Francesco Moggia Leon Do Jean Deruelle Buddy Bright Marco Monteiro Sancho Cesar Rego Niklas Uhrberg Ivan McShane Oleg Kulikov Pavel Mitrenko 8.8.1.2. Advisory Board Paulo Chainho Nuno Silva Jim Yang
- 99. 8.8. PROYECTO MOBICENTS 8.8.2. 67 Actividad La actividad ha decrecido mucho, apenas contestan en el Foro, el desarrollo de muchos RAs est´ estancado (Ver figura estad´ a ısticas del proyecto), creemos que es debido fundamentalmente por la organizaci´n del “camp mobicents” que tuvo lugar los pasados o 28 y 29 de abril de 2007, los nuevos servicios que est´ ofreciendo Mobicents, como la a licencia comercial, y cursos de programaci´n JainSlee. Probablemente tambi´n est´n o e e trabajando en alg´n libro que trate sobre estos temas. u Figura 8.2: Estad´ ısticas del proyecto 8.8.3. P´gina Mobicents a La principal fuente de informaci´n acerca de los avances y ejemplos de Mobicents, es o la propia p´gina del producto [11], pero dicha p´gina est´ muy mal dise˜ada, ya que se a a a n encuentra desorganizada en algunos casos, los recursos para descargar siendo distintos no poseen una forma de descarga igual, sino que cada uno se descarga us´ndose medios a alternativos sourceforge, cvs, svn, eclipse..., lo que causa un poco de descontrol. Por otro lado, no existen gu´ adecuadas de c´mo descargar, desplegar, compilar, en resumidas ıas o cuentas de como empezar a usar casos pr´cticos de mobicents. a 8.8.4. 8.8.4.1. Foros Mobicents users El foro de Mobicents users [14], tiene como objetivo las dudas que tengan los usuarios con el proyecto Mobicents, a la hora de instalarlo, usar los resource adaptors y probar servicios ya implementados. En ´l no siempre responden, adem´s de ser poco concretos. e a Tambi´n hay que tener en cuenta que al ser Open Source la gente involucrada no gana e nada respondi´ndote con celeridad a tus cuestiones. e
- 100. CAP´ ITULO 8. CARACTER´ ISTICAS 68 8.8.4.2. Mobicents contributors El foro Mobicents contributors [15] se discute el dise˜o de mobicents, resource adapn tors, servicios, tareas pendientes de la hoja de ruta 11.1 etc, donde invitan a participar activamente en ellos o proponer nuevos. 8.8.4.3. JSLEE Resource Adaptor Types En el foro JSLEE Resource Adaptor Types [16] se dedican a promover la estandarizaci´n de interfaces RA para mejorar la portabilidad de la aplicaci´n. Tambi´n o o e se mejoran RAs ya existentes o se proponen nuevos. 8.8.5. Informar de Bugs, Parches y Feature Requests Se puede usar el issue tracking system [17] para informar de Bugs y Feature Requests de Mobicents. Cuando se env´ un bug, es recomendable enviar un automated test case en formato ıa TCK o JUnit que exponga el problema.
- 101. Cap´ ıtulo 9 Mejores pr´cticas a 9.1. RAFrame (Resource Adapter Framework) Este ejemplo muestra como un protocolo de pila basado en Java (RAFStack) es integrado en el entorno JSLEE. Por lo tanto, el RAFrame RA y todas las interfaces y clases necesarias se discuten en mayor detalle. Las dependencias entre el c´digo Java o y los descriptores desplegables (DD) son ilustrados en un ejemplo como un servicio simple (BounceSbb) que tambi´n esta explicado. e 9.1.1. El ejemplo La estructura del ejemplo RAFrame; Tenemos dos directorios, el RAFrame y el RASBB. El directorio RAFrame contiene todos los ficheros necesarios para el RA y el SBB todos los ficheros de servicios necesarios. Las dos carpetas contienen las carpetas src, descriptors, lib, build, dist y bin. La carpeta scr tenemos los ficheros fuentes java para el RA o el servicio; descriptors contiene todos los descriptores desplegables; lib contiene las librer´ necesarias para ıas compilar los fuentes; build contiene todas las clases java despu´s de ejecutar ant sae tisfactoriamente; dist contiene los archivos listos para desplegar y bin contiene scripts para desplegar RA o el servicio. 9.1.2. El protocolo Para el prop´sito de crear un ejemplo RA para prop´sitos principalmente autodio o dactas, un protocolo simple f´cil de entender era necesario. El protocolo RAFrame ha a nacido. Est´ basado en TCP/IP y sigue las siguientes reglas: a ID COMMAND El protocolo contiene un unico identificador (ID) y una cadena de comandos (COM´ MAND). Un mensaje de protocolo v´lido seria por ejemplo: a 100 INIT 69
- 102. ´ CAP´ ITULO 9. MEJORES PRACTICAS 70 Figura 9.1: Protocolo del ejemplo. Los mensajes de protocolo pueden contener los comandos INIT, ANY y END. Una sesi´n comienza con el comando INIT. Despu´s cualquier n´mero de comandos o e u ANY pueden ocurrir. La sesi´n termina con el comando END. Cualquier otra secuencia o de comandos es considerada inv´lida. a 9.1.3. El Protocol Stack La pila para el protocolo descrito consiste en dos clases y pueden ser localizadas en el paquete com.maretzke.raframe.stac. La clase RAFStack contiene la pila l´gica e implementa o un ServerSocket TCP/IP. Adem´s, ofrece l´gica para enviar informaci´n a otra implea o o mentaci´n RAFStack. o Una conexi´n entrante TCP/IP deja al RAFStack iniciar un nuevo RAStackThread o y delega en el trabajo de la informaci´n entrante. El RAStackThread lee la informaci´n o o entrante e informa a los objetos instanciados oyentes. Estos objetos implementan la interfaz RAFStackListener y se han registrado previamente para la notificaci´n. o La pila de implementaci´n es multihilo para bajar el tiempo ocioso (idle) necesario o para la comunicaci´n de los sockets. o 9.1.4. Probando el Protocol Stack Para ver la pila de protocolos funcionando, abrir dos ventanas de la consola de Windows, ir al directorio de RAFrame, y entrar en la carpeta bin, ejecutar en una de las ventanas el servidor: Inicio –>Ejecutar: C:workspaceRAFramebinstartRAFServer.bat y en otra el cliente swing: Inicio –>Ejecutar: C:workspaceRAFramebinstartSwingRAFClient.bat
- 103. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 71 Figura 9.2: El RAFSwingClient. Figura 9.3: El RAFSwingClient. El servidor y el cliente utilizan ambos las clases RAFStack para comunicarse. Las clases est´n localizadas en el paquete com.maretzke.raframe.test.client y empha com.maretzke.raframe.test.server. Ahora, tenemos una implementaci´n de pila que permite comunicaci´n basada en o o TCP/IP entre objetos Server y cliente. Sin embargo, la pila no asegura que el protocolo definido no sea violado. Est´ puede ser una de las tareas del RA. a 9.1.5. Descriptor de Despliegue (DD) Un Descriptor de Despliegue es un componente de aplicaciones J2EE que describe como se debe desplegar (o implantar) una aplicaci´n web. Esto dirige una herramieno ta de despliegue (o publicaci´n) para desplegar un m´dulo o aplicaci´n con opciones o o o de contenedor espec´ ıficas y describe requisitos de configuraci´n espec´ o ıficos que puede resolver un desplegador.
- 104. ´ CAP´ ITULO 9. MEJORES PRACTICAS 72 En aplicaciones J2EE, XML se usa para la sintaxis del fichero descriptor de despliegue. Debe ser llamado web.xml, y debe ser colocado en un subdirectorio llamado WEB-INF, directamente debajo de la ra´ de la aplicaci´n web. ız o JSLEE aplica los conceptos del DD para la configuraci´n, despliegue y empaquetado. o Los diferentes DDs y su significado para las diferentes entidades JSLEE son explicadas m´s tarde a pesar de un: deployable-unit.xml. Es importante para prop´sitos de empaa o quetado y referenciar todos los elementos contenidos en un archivo JSLEE listo para ser desplegado - la unidad desplegable. Figura 9.4: Perspectiva de varios Descriptores de Despliegue. 9.1.6. Eventos del RAframe Los eventos sirven para comunicar el RA con los SBBs en el contexto de JSLEE. En el caso del RAFrame RA la codificaci´n del protocolo de los mensajes en objetos o Java es muy simple; Se construye lo que seria el mensaje en java: La interfaz Java Message abstrae un mensaje de protocolo del RAFStack. El objeto Message es envuelto en un objeto MessageEvent. Eventos, listos! Los objetos que implementan esta interfaz son creados por el RA y entregados al entorno JSLEE. Listado 9.1: Interfaz MessageEvent public i n t e r f a c e MessageEvent { /* * * Accede a l o b j e t o e n v u e l t o Message que e s t ´ c o n t e n i d o en a * e l o b j e t o de im ple m e nt ac i´ n . o * @return e l c o n t e n i d o d e l o b j e t o Message . * / public Message getMessage ( ) ; /* * * El o b j e t o en e l que e l i n i c i a l m e n t e o c u r r i ´ e l Evento . o * @return El o b j e t o en e l que i n i c i a l m e n t e o c u r r i ´ e l Evento . * / o public Object g e t S o u r c e ( ) ; }
- 105. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 73 Para crear objetos reales de Message y MessageEvent el RA y los SBBs utilizan un objeto MessageFactory. Listado 9.2: Interfaz MessageFactory /* * * La c l a s e MessageEvent e n v u e l v e un o b j e t o Message y a n ade l a ˜ * h u e l l a d e l o b j e t o p e d i d o en e l . * @author Michael Maretzke */ public i n t e r f a c e MessageEvent { /* * * Accede a l o b j e t o e n v u e l t o Message que e s t ´ c o n t e n i d o en l a a * i m p le m e n t ac i´ n d e l o b j e t o . o * @return t h e c o n t a i n e d Message o b j e c t . */ public Message getMessage ( ) ; /* * * El o b j e t o donde i n i c i a l m e n t e o c u r r e e l Evento . * @return El o b j e t o donde i n i c i a l m e n t e o c u r r e e l Evento . */ public Object g e t S o u r c e ( ) ; 9.1.7. El RA Type RAFRAME La definici´n de los eventos del RA Type se hace en el DD1 event-jar.xml, que se o encuentra en /descriptors/ratype. La etiqueta event-type-name define un nombre unico ´ para los Eventos manejados por el RA Type. Este nombre es mapeado a una clase Java especificada por la etiqueta event-class-name. 1 Descriptor de Despliegue
- 106. 74 ´ CAP´ ITULO 9. MEJORES PRACTICAS Listado 9.3: event-jar.xml <? xml v e r s i o n="1.0" e n c o d i n g="ISO -8859 -1" ?> <event−j a r> <event−d e f i n i t i o n> <event−type−name> com . maretzke . r a f r a m e . message . incoming . INIT </ event−type−name> <event−type−vendor> maretzke </ event−type−vendor> <event−type−v e r s i o n> 1.0 </ event−type−v e r s i o n> <event−c l a s s −name> com . maretzke . r a f r a m e . message . MessageEvent </ event−c l a s s −name> </ event−d e f i n i t i o n> ... </ event−j a r> Figura 9.5: Proceso de Eventos a trav´s de RAs y un router de eventos. e
- 107. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 9.1.8. 75 El Activity y Activity Context del RA El DD resource-adaptor-type-jar.xml define entre otros la Actividad y el Contexto de la Actividad para el RA Type. Listado 9.4: Definici´n de Actividad en resource-adaptor-type-jar.xml o <? xml v e r s i o n="1.0" e n c o d i n g="ISO -8859 -1" ?> <r e s o u r c e −adaptor−type−j a r> <d e s c r i p t i o n /> <r e s o u r c e −adaptor−type> <d e s c r i p t i o n> Michael Maretzke RA framework r e s o u r c e a d a p t o r type − version 1.0 </ d e s c r i p t i o n> <r e s o u r c e −adaptor−type−name> r a f r a m e r a t y p e </ r e s o u r c e −adaptor−type−name> <r e s o u r c e −adaptor−type−vendor> maretzke </ r e s o u r c e −adaptor−type−vendor> <r e s o u r c e −adaptor−type−v e r s i o n> 1 . 0 </ r e s o u r c e −adaptor−type−v e r s i o n> <r e s o u r c e −adaptor−type−c l a s s e s> <a c t i v i t y −type> <a c t i v i t y −type−name> com . maretzke . r a f r a m e . r a t y p e . RAFActivity </ a c t i v i t y −type−name> </ a c t i v i t y −type> <a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −i n t e r f a c e> <a c i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −i n t e r f a c e −name> com . maretzke . r a f r a m e . R A F r a m e A c t i v i t y C o n t e x t I n t e r f a c e F a c t o r y </ a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −i n t e r f a c e −name> </ a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −i n t e r f a c e> <r e s o u r c e −adaptor−i n t e r f a c e> <r e s o u r c e −adaptor−i n t e r f a c e −name> com . maretzke . r a f r a m e . RAFrameResourceAdaptorSBBInterface </ r e s o u r c e −adaptor−i n t e r f a c e −name> </ r e s o u r c e −adaptor−i n t e r f a c e> </ r e s o u r c e −adaptor−type−c l a s s e s> . . .
- 108. ´ CAP´ ITULO 9. MEJORES PRACTICAS 76 La etiqueta activity-type-name se refiere a la interfaz Java RAFActivity. Su implementaci´n representa el estado compartido para cada Actividad entre el RA y el SBB. o Listado 9.5: Interfaz de RAFActivity public i n t e r f a c e RAFActivity { / * * Comprueba s i un comando e n t r a n t e e s v ´ l i d o de a c u e r d o a l a * e s t a d o de l a maquina e s t a b l e c i d o . * @param command La r e p r e s e n t a c i ´ n e n t e r a de l a orden o * @return v e r d a d e r o : l a orden no v i o l a e l e s t a d o de l a m´ quina ; a * f a l s o : l a orden v i o l a e l e s t a d o de l a m´ quina . * / a public boolean i s V a l i d ( int command ) ; / * * Este m´todo e s llamado para e m i t i r una s e n a l a l e s t a d o de l a e ˜ * m´ quina a b s t r a´d o por l a a c t i v i d a d de un mensaje d e l t i p o a ı * Message . INIT ha s i d o r e c i b i d o * / public void i n i t R e c e i v e d ( ) ; / * * Este m´todo e s llamado para e m i t i r una s e n a l a l e s t a d o de l a e ˜ * m´ quina a b s t r a´d o por l a a c t i v i d a d de un mensaje d e l t i p o a ı * Message . ANY ha s i d o r e c i b i d o * / public void anyReceived ( ) ; / * * Este m´todo e s llamado para e m i t i r una s e n a l a l e s t a d o de l a e ˜ * m´ quina a b s t r a´d o por l a a c t i v i d a d de un mensaje d e l t i p o a ı * Message . END ha s i d o r e c i b i d o * / public public public public public } void endReceived ( ) ; int g e t I n i t C o u n t e r ( ) ; int getAnyCounter ( ) ; int getEndCounter ( ) ; long g e t S t a r t T i m e ( ) ;
- 109. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 77 Recuerda, una Actividad es la representaci´n de un estado espec´ o ıfico para una sola secuencia de Eventos, por ejemplo el establecimiento de una llamada o la estructura de una sesi´n de juego online. Una Actividad espec´ o ıfica es identificada por un unico ´ manejador de Actividades. En nuestro ejemplo la clase RAFActivityHandle implementa el Manejador (handler). Listado 9.6: Extracto de la funci´n onEvent de la clase RAFrameResourceAdaptor o /* * * * public Implementa com . maretzke . r a f r a m e . s t a c k . RAFStackListener Este m´todo e s i n v o c a d o por e l s u b y a c e n t e RAFStack cuando e son r e c i b i d o s d a t o s e n t r a n t e s . * / void onEvent ( S t r i n g incomingData ) { MessageEvent e v e n t ; Address a d d r e s s ; int eventID ; l o g g e r . debug ( ” P e t i c i ´ n de e n t r a d a : ” + incomingData ) ; o // A n a l i z a s i n t ´ c t i c a m e n t e l o s d a t o s e n t r a n t e s a try { Message message = m e s s a g e P a r s e r . p a r s e ( incomingData ) ; e v e n t= messageFactory . c r e a t e M e s s a g e E v e n t ( this , message ) ; } catch ( I n c o r r e c t R e q u e s t F o r m a t E x c e p t i o n i r f e ) { // Desafortunadamente e l mensaje e n t r a n t e no cumple con // e l p r o t o c o l o / r e g l a s de f o r m a c i ´ n d e l mensaje . El o // mensaje e s d e s c a r t a d o . l o g g e r . debug ( ”La P e t i c i ´ n de e n t r a d a : ”+incomingData+ o ”no s i g u e l a s r e g l a s d e f i n i d a s d e l mensaje ( ID COMMAND) . Rechazando e l e v e n t o . ” ) ; return ; } // Genera e l manejador de a c t i v i d a d que i d e n t i f i c a // u nicamente l a a c t i v i d a d de c o n t e x t o a p r o p i a d a ´ RAFActivityHandle h a n d l e = new RAFActivityHandle ( e v e n t . getMessage ( ) . g e t I d ( ) ) ; // Buscar l a a c t i v i d a d RAFActivity a c t i v i t y= ( RAFActivity ) a c t i v i t i e s . g e t ( h a n d l e ) ; // La a c t i v i d a d no e x i s t e − Creemos una . i f ( a c t i v i t y == null ) { a c t i v i t y = new RAFActivityImpl ( ) ; a c t i v i t i e s . put ( handle , a c t i v i t y ) ; } . . . }
- 110. ´ CAP´ ITULO 9. MEJORES PRACTICAS 78 Por otro lado, SBBs pueden acceder a la Actividad a trav´s de ActivityContextIne terface. Listado 9.7: funci´n onInitEvent de la clase BounceSBB o /* * * El m´todo EventHandler para e v e n t o s e n t r a n t e s d e l t i p o e * ” I n i t E v e n t ” . I n i t E v e n t e s t ´ d e f i n i d o en e l D e s c r i p t o r de a * D e s p l i e g u e (DD) ”SBB−j a r . xml ” . Este m´todo e s i n v o c a d o por SLEE e * s i un e v e n t o d e l t i p o INIT e s r e c i b i d o y d i s p a r a d o por e l * Adaptador de r e c u r s o s (RA) . * / public void o n I n i t E v e n t ( MessageEvent event , A c t i v i t y C o n t e x t I n t e r f a c e ac ) { t r a c e ( L e v e l . INFO , ”BounceSBB : ” + t h i s + ” : r e c e i v e d an incoming Request . C al lI D = ” + e v e n t . getMessage ( ) . g e t I d ( ) + ” . Command = ” + e v e n t . getMessage ( ) . getCommand ( ) ) ; try { RAFActivity a c t i v i t y = ( RAFActivity ) ac . g e t A c t i v i t y ( ) ; // cambiar l a a c t i v i d a d − a q u´ s o l o con e l p r o p ´ s i t o de ı o // d e m o s tr a c i´ n , p e r o p o d r´a s e r e v a l u a d o por o t r o s o ı // SBBs . activity . initReceived ( ) ; t r a c e ( L e v e l . INFO , ”INIT Event : INIT : ” +a c t i v i t y . g e t I n i t C o u n t e r ( ) +” ANY: ” + a c t i v i t y . getAnyCounter ( ) +” END: ” + a c t i v i t y . getEndCounter ( ) +” V a l i d s t a t e : ” +a c t i v i t y . i s V a l i d ( e v e n t . getMessage ( ) . getCommandId ( ) ) ) ; } catch ( E x c e p t i o n e ) { t r a c e ( L e v e l .WARNING, ” Exception during onInitEvent : ” , e ); } }
- 111. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 9.1.9. 79 EL RA Type se ofrece para los SBBs El DD define tambi´n la interfaz entre los componentes SBB y el RA. Esta interfaz e es la unica manera que tienen los componentes SBB para interactuar con el RA. ´ Listado 9.8: Interfaz RAFrameResourceAdaptorSBBInterface package com . maretzke . r a f r a m e . r a t y p e ; import com . maretzke . r a f r a m e . message . Message ; import com . maretzke . r a f r a m e . message . MessageFactory ; public i n t e r f a c e RAFrameResourceAdaptorSBBInterface { / * * send ( ) e s una f u n c i o n a l i d a d d e l Adaptador de R e c u r s o s (RA) * e x p u e s t a a l SBB . * Debido a l a a r q u i t e c t u r a d e l SBB t e n i e n d o s o l o a c c e s o a l * RAFrameProvider en vez de a l RAFrameResourceAdaptor * d i r e c t a m e n t e , e l d e s a r r o l l a d o r d e l adaptador de r e c u r s o s * podr´ l i m i t a r l o s p r i v i l e g i o s de un SBB para i n c o v a r a * m´ todos de un Adaptador de R e c u r s o s d i r e c t a m e n t e . e * * @param message i s t h e message t o send * / public void send ( Message message ) ; / * * El MessageFactory s e n e c e s i t a d e n t r o d e l SBB para c r e a r * o b j e t o s Message , que son e n v i a d o s a t r a v ´ s d e l Adaptador e * de R e c u r s o s . * / public MessageFactory g e t M e s s a g e F a c t o r y ( ) ; / * * El RAFrameProvider da a c c e s o a c i e r t o s m´ todos d e l Adaptador e * de R e c u r s o s . El SBB p o d r´a por e j e m p l o e n v i a r o b j e t o s Message ı * a t r a v ´ s d e l Adaptador de R e c u r s o s . * / e public RAFrameResourceAdaptorSBBInterface getRAFrameProvider ( ) ; } La clase com.maretzke.raframe.ra.RAFrameProvider implementa la interfaz. Los SBBs podr´ preguntar por un objeto MessageFactory para crear objetos Message y ıan MessageEvent y podr´ acceder a un objeto RAFrameProvider para acceder al m´todo ıan e send() de la implementaci´n RA para enviar objetos Message. o
- 112. ´ CAP´ ITULO 9. MEJORES PRACTICAS 80 9.1.10. ¿C´mo funciona? o Listado 9.9: M´todo onAnyEvent() de la clase BounceSBB e / * * El m´todo EventHandler para e v e n t o s e n t r a n t e s d e l t i p o e * AnyEvent ” . AnyEvent e s t ´ d e f i n i d o en e l D e s c r i p t o r de D e s p l i e g e a * ”SBB−j a r . xml ” . Este m´todo e s i n v o c a d o por SLEE s i un e v e n t o e * d e l t i p o ANY e s r e c i b i d o y l a n z a d o por e l Adaptador de * R e c u r s o s . */ public void onAnyEvent ( MessageEvent event , A c t i v i t y C o n t e x t I n t e r f a c e ac ) { t r a c e ( L e v e l . INFO , ”BounceSBB : ” + t h i s + ” : R e c i b i d a un p e t i c i ´ n de e n t r a d a . o C al lI D = ” + e v e n t . getMessage ( ) . g e t I d ( ) + ” . Orden = ” + e v e n t . getMessage ( ) . getCommand ( ) ) ; try { RAFActivity a c t i v i t y = ( RAFActivity ) ac . g e t A c t i v i t y ( ) ; // cambia l a a c t i v i d a d − s o l o con l a i n t e n c i ´ n de o // d e m o s t r a r l o , p e r o p o d r´a s e r e v a l u a d o por o t r o s SBBs ı a c t i v i t y . anyReceived ( ) ; t r a c e ( L e v e l . INFO , ” Evento ANY: INIT : ” + activity . getInitCounter () + ”ANY: ” + a c t i v i t y . getAnyCounter ( ) + ”END: ” + a c t i v i t y . getEndCounter ( ) + ” Estado v ´ l i d o : ” a + a c t i v i t y . i s V a l i d ( e v e n t . getMessage ( ) . getCommandId ( ) ) ) ; } catch ( E x c e p t i o n e ) { t r a c e ( L e v e l .WARNING, ” Excepci´ n d u r a n t e onAnyEvent : ” , e ) ; o } // e n v´a una r e s p u e s t a a l Adaptador de R e c u r s o s / P i l a / I n v o c a d o r ı // g e n e r a un o b j e t o Message y . . . Message answer = SBB2ra . g e t M e s s a g e F a c t o r y ( ) . c r e a t e M e s s a g e ( e v e n t . getMessage ( ) . g e t I d ( ) , ”Comando d e v u e l t o por BounceSBB : ” + e v e n t . getMessage ( ) . getCommand ( ) ) ; // . . . l o e n v´a usando e l Adaptador de R e c u r s o s ı SBB2ra . send ( answer ) ; }
- 113. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 81 La clase BounceSBB necesita interrogar al ´rbol JNDI para la interfaz del SBB por a el RA. El nombre JNDI es configurado en el DD del SBB. 9.1.11. El RA - Estructura y M´todos. e La clase RAFrameResourceAdaptor implementa el Resource Adaptor RAFrame y puede ser localizado en el paquete com.maretzke.raframe.ra. La mayor´ de los m´toıa e dos del RA implementan la interfaz javax.slee.ResourceAdaptor y representa hooks (enganches) invocados por el entorno JSLEE durante el ciclo de vida del RA. En la versi´n 1.0 de JSLEE (JSR-22) [7] la integraci´n del Resource Adaptor era considero o ada un detalle espec´ ıfico de la implementaci´n. La versi´n 1.1 de JSLEE (JSR-240) o o [8] se centr´ en la arquitectura del Resource Adaptor. El proyecto de c´digo abierto o o Mobicents sigue las actividades de estandarizaci´n muy de cerca e implementa ya la o mayor´ de los aspectos de la versi´n 1.1 de JSLEE. Es normal encontrar diferencias o ıa o anomal´ motivadas por seguir la estandarizaci´n. ıas o 9.1.12. entityCreated() y entityActivated() El m´todo entityCreated() es el primer m´todo llamado por el entorno JSLEE dese e pu´s de la instanciaci´n del RA. e o Listado 9.10: M´todo entityCreated() de la clase RAFrameResourceAdaptor e / * Implementa j a v a x . s l e e . r e s o u r c e . ResourceAdaptor R e f e r i d a a l a E s p e c i f i c a c i ´ n JSLEE v1 . 1 , Borrador r e c i e n t e m e n t e r e v i s a d o ; o P´ gina 298 para m´s i n f o r m a c i ´ n . Este m´todo e s llamado por a a o e SLEE cuando una i n s t a n c i a de un Adaptador de R e c u r s o s e s t ´ a c a r g a d a en memoria , o cuando una e n t i d a d Adaptador de R e c u r s o s e s c r e a d a d ur a n t e e l i n i c i o de SLEE . La i m ple m e n t ac i ´ n SLEE c o n s t r u i r ´ e l o b j e t o Adaptador de o a R e c u r s o s e i n v o c a r ´ a l m´todo e n t i t y C r e a t e d a n t e s que ninguna a e o t r a o p e r a c i ´ n s e a llamada por e l o b j e t o Adaptador de R e c u r s o s o */ public void e n t i t y C r e a t e d ( B o o t s t r a p C o n t e x t b o o t s t r a p C o n t e x t ) throws R e s o u r c e E x c e p t i o n { l o g g e r . debug ( ” RAFrameResourceAdaptor . e n t i t y C r e a t e d ( ) llamado . ” ) ; t h i s . b o o t s t r a p C o n t e x t= b o o t s t r a p C o n t e x t ; t h i s . s l e e E n d p o i n t= b o o t s t r a p C o n t e x t . g e t S l e e E n d p o i n t ( ) ; t h i s . eventLookup= b o o t s t r a p C o n t e x t . g e t E v e n t L o o k u p F a c i l i t y ( ) ; s t a c k = null ; }
- 114. 82 ´ CAP´ ITULO 9. MEJORES PRACTICAS EL m´todo inicializa referencias importantes a los objetos JSLEE dados por el obe jeto BootstrapContext. M´s tarde JSLEE llama a entityActivated() para permitir al RA a finalizar el trabajo de inicializaci´n. o Listado 9.11: M´todo entityActivated() e / * * Implementa j a v a x . s l e e . r e s o u r c e . ResourceAdaptor * La e s p e c i f i c a c i ´ n JSLEE v1 . 1 no i n c l u y e e n t i t y A c t i v a t e d ( ) . S i n o * embargo , l a d e s c r i p c i ´ n de l a API de JSLEE v1 . 1 s i i n c l u y e e s t e o * m´todo ya . Entonces , l a documentaci´ n s i g u e e l c ´ d i g o . Este e o o * m´todo e s llamado en c o n t e x t o d e l p r o y e c t o Mobicents en e * c o n t e x t o de l a a c t i v a c i ´ n d e l RA. M´s exactamente , o a * o r g . m obi c e nts . s l e e . r e s o u r c e . R e s o u r c e A d a p t o r E n t i t y . a c t i v a t e ( ) * l l a m a a e s t e m´todo e n t i t y A c t i v a t e d ( ) . Este m´todo e n v´a a l RA e e ı * una s e n a l con l a t r a n s i c i o n de e s t a d o ”INACTIVE” a ”ACTIVE” . * / ˜ ´ public void e n t i t y A c t i v a t e d ( ) throws j a v a x . s l e e . r e s o u r c e . R e s o u r c e E x c e p t i o n { l o g g e r . debug ( ” RAFrameResourceAdaptor . e n t i t y A c t i v a t e d ( ) llamado . ” ) ; try { l o g g e r . debug ( ”Comenzando RAFStack en e l p u e r t o ” + port ) ; try { messageFactory = new MessageFactoryImpl ( ) ; raProvider = new RAFrameProviderImpl ( this , mes sageFactory ) ; m e s s a g e P a r s e r = new RAFMessageParser ( ) ; s t a c k = new RAFStack ( port , remotehost , r e m o t e p o r t ) ; // r e g i s t r a e l RS para r e c i b i r m e n s a j e s de l a p i l a // −− onEvent ( ) stack . addListener ( this ) ; stack . start ( ) ; l o g g e r . debug ( ”RAFStack l e v a n t a d o y c o r r i e n d o . ” ) ; initializeNamingContext ( ) ; } catch ( E x c e p t i o n ex ) { l o g g e r . e r r o r ( ” RAFrameResouceAdaptor . s t a r t ( ) : ¡ R e c o g i d a una e x c e p c i ´ n ! ” ) ; o ex . p r i n t S t a c k T r a c e ( ) ; throw new R e s o u r c e E x c e p t i o n ( ex . getMessage ( ) ) ; } a c t i v i t i e s = new HashMap ( ) ; } catch ( R e s o u r c e E x c e p t i o n e ) { e . printStackTrace ( ) ; throw new j a v a x . s l e e . r e s o u r c e . R e s o u r c e E x c e p t i o n ( ” RAFrameResourceAdaptor . e n t i t y A c t i v a t e d ( ) : F a l l ´ a l a hora de a c t i v a r e l RAFrame Resource Adaptor ! ” , e ) ; o } }
- 115. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 83 En el m´todo, El RA crea un objeto RAFStack, se registra a s´ mismo como ese ı cuchador y comienza la pila. Al final, un nuevo objeto HashMap es creado para guardar las actividades. 9.1.13. onEvent() El objeto embebido RAFStack del RA invoca a onEvent() y maneja sobre los caracteres recibidos como un argumento. En el m´todo onEvent() la informaci´n que recibe es analizada sint´cticamente y e o a descartada si no es v´lida. a Listado 9.12: onEvent() 1 / * * Implementa com . maretzke . r a f r a m e . s t a c k . RAFStackListener * Este m´todo e s i n v o c a d o por e l s u b y a c e n t e RAFStack cuando son e * r e c i b i d o s d a t o s e n t r a n t e s . */ public void onEvent ( S t r i n g incomingData ) { MessageEvent e v e n t ; Address a d d r e s s ; int eventID ; l o g g e r . debug ( ” P e t i c i ´ n de e n t r a d a : ” + incomingData ) ; o // A n a l i z a s i n t ´ c t i c a m e n t e l o s d a t o s e n t r a n t e s a try { Message message = m e s s a g e P a r s e r . p a r s e ( incomingData ) ; e v e n t = messageFactory . c r e a t e M e s s a g e E v e n t ( this , message ) ; } catch ( I n c o r r e c t R e q u e s t F o r m a t E x c e p t i o n i r f e ) { // Desafortunadamente e l mensaje e n t r a n t e no cumple con e l // p r o t o c o l o / r e g l a s de f o r m a c i ´ n d e l mensaje . EL mensaje e s o // d e s c a r t a d o . l o g g e r . debug ( ”La P e t i c i ´ n de e n t r a d a : ” + incomingData + o ”no s i g u e l a s r e g l a s d e f i n i d a s d e l mensaje ( ID COMMAND) . Rechazando e l e v e n t o . ” ) ; return ; }
- 116. 84 ´ CAP´ ITULO 9. MEJORES PRACTICAS Una Actividad es creada si no existe ninguna. Listado 9.13: onEvent() 2 // Genera e l manejador de a c t i v i d a d que i d e n t i f i c a u nicamente ´ // l a a c t i v i d a d de c o n t e x t o a p r o p i a d a RAFActivityHandle h a n d l e = new RAFActivityHandle ( e v e n t . getMessage ( ) . g e t I d ( ) ) ; // Buscar l a a c t i v i d a d RAFActivity a c t i v i t y = ( RAFActivity ) a c t i v i t i e s . g e t ( h a n d l e ) ; // La a c t i v i d a d no e x i s t e − Creemos una . i f ( a c t i v i t y == null ) { a c t i v i t y = new RAFActivityImpl ( ) ; a c t i v i t i e s . put ( handle , a c t i v i t y ) ; } La validez del mensaje de entrada de acuerdo a las reglas del protocolo es comprobado utilizando la Actividad del estado de la m´quina (isValid()). a Listado 9.14: onEvent() 3 i f ( ! a c t i v i t y . i s V a l i d ( e v e n t . getMessage ( ) . getCommandId ( ) ) ) { l o g g e r . debug ( ”No e s una orden v ´ l i d a . La orden no cumple a l a s r e g l a s d e f i n i d a s por e l p r o t o c o l o . ” ) ; return ; }
- 117. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 85 El identificador del Evento es visitado en el ´rbol JNDI. Si no es encontrado en el a a ´rbol JNDI, se asume como desconocido, y por lo tanto como un mensaje no v´lido. a Listado 9.15: onEvent() 4 // El m´todo f i r e E v e n t ( ) n e c e s i t a una d i r e c c i ´ n por d e f e c t o para e o // s a b e r donde d e b e r´a n s e r l a n z a d o s l o s e v e n t o s . ı a d d r e s s = new Address ( AddressPlan . IP , ” 1 2 7 . 0 . 0 . 1 ” ) ; // Cogemos e l eventID d e l ´ r b o l JNDI . a try { eventID = eventLookup . getEventID ( ”com . maretzke . r a f r a m e . message . incoming . ” + e v e n t . getMessage ( ) . getCommand ( ) . toUpperCase ( ) , ” maretzke ” , ” 1 . 0 ” ) ; } catch ( F a c i l i t y E x c e p t i o n f e ) { l o g g e r . e r r o r ( ” Caught a F a c i l i t y E x c e p t i o n : ” ) ; fe . printStackTrace ( ) ; throw new RuntimeException ( ” RAFrameResourceAdapter . onEvent ( ) : Recogida F a c i l i t y E x c e p t i o n . ” , f e ) ; } catch ( U n r e c o g n i z e d E v e n t E x c e p t i o n uee ) { l o g g e r . e r r o r ( ” Recogida un U n r e c o g n i z e d E v e n t E x c e p t i o n : ” ) ; uee . p r i n t S t a c k T r a c e ( ) ; throw new RuntimeException ( ” RAFrameResourceAdaptor . onEvent ( ) : Recogida U n r e c o g n i z e d E v e n t E x c e p t i o n . ” , uee ) ; } i f ( eventID == −1) { // S i l e n c i o s a m e n t e r e t i r a e l mensaje porque no t i e n e un t i p o de // e v e n t o r e g i s t r a d o . l o g g e r . debug ( ” RAFrameResourceAdaptor . onEvent ( ) : Event lookup −− c o u l d not f i n d e v e n t mapping −− check xml/ s l e e −e v e n t s . xml” ) ; return ; }
- 118. ´ CAP´ ITULO 9. MEJORES PRACTICAS 86 Finalmente, el mensaje es manejado a trav´s del entorno JSLEE. Esto es hecho por e el SleeEndpoint. Si es un mensaje END, el entorno JSLEE es notificado con activityEnding() de otro modo con fireEvent(). Listado 9.16: onEvent() 5 try { i f ( e v e n t . getMessage ( ) . getCommand ( ) . toLowerCase ( ) . compareTo ( ” end ” ) == 0 ) { // s i l a orden e s end , l a a c t i v i d a d c o n e c t a d a n e c e s i t a // t e r m i n a r e s t o e s e n v i a d o por s e n a l e s a SLEE mediante ˜ // a c t i v i t y E n d i n g ( ) l o g g e r . debug ( ” RAFrameResourceAdaptor . onEvent ( ) : RAFrameRA enviando s e n a l de f i n a l i z a c i ´ n ˜ o de a c t i v i d a d a SLEE . EventID : ” + eventID + ” ; CallI D : ” + e v e n t . getMessage ( ) . g e t I d ( ) + ” ; Orden : ” + e v e n t . getMessage ( ) . getCommand ( ) ) ; s l e e E n d p o i n t . a c t i v i t y E n d i n g (new RAFActivityHandle ( e v e n t . getMessage ( ) . g e t I d ( ) ) ) ; } else { // l a n z a e l e v e n t o a l e n t o r n o SLEE y s i g u e l o g g e r . debug ( ” RAFrameResourceAdaptor . onEvent ( ) : RAFrameRA l a n z a e l e v e n t o a l e n t o r n o SLEE . EventID : ” + eventID + ” ; C al lID : ” + e v e n t . getMessage ( ) . g e t I d ( ) + ” ; Orden : ” + e v e n t . getMessage ( ) . getCommand ( ) ) ; s l e e E n d p o i n t . f i r e E v e n t (new RAFActivityHandle ( e v e n t . getMessage ( ) . g e t I d ( ) ) , ( Object ) event , eventID , a d d r e s s ) ; } } catch ( I l l e g a l S t a t e E x c e p t i o n i s e ) { l o g g e r . e r r o r ( ” Recogida una I l l e g a l S t a t e E x c e p t i o n : ” ) ; i s e . printStackTrace ( ) ; } catch ( A c t i v i t y I s E n d i n g E x c e p t i o n a i e e ) { l o g g e r . e r r o r ( ” Recogida una A c t i v i t y I s E n d i n g E x c e p t i o n : ” ) ; aiee . printStackTrace ( ) ; } catch ( U n r e c o g n i z e d A c t i v i t y E x c e p t i o n uaee ) { l o g g e r . e r r o r ( ” Recogida una U n r e c o g n i z e d A c t i v i t y E x c e p t i o n : ” ) ; uaee . p r i n t S t a c k T r a c e ( ) ; } 9.1.14. getActivity() y ActivityEnded() El m´todo getActivity() devuelve el objeto Activity asociado con un manejador ese pec´ ıfico.
- 119. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 87 Listado 9.17: M´todo getActivity() e /* * * implements j a v a x . s l e e . r e s o u r c e . ResourceAdaptor * P l e a s e r e f e r t o JSLEE v1 . 1 S p e c i f i c a t i o n , E a r l y D r a f t Review Page * 301 f o r f u r t h e r i n f o r m a t i o n . The SLEE c a l l s t h i s method t o g e t * a c c e s s t o t h e u n d e r l y i n g a c t i v i t y f o r an a c t i v i t y h a n d l e . The RA * i s e x p e c t e d t o p a s s back a non−n u l l o b j e c t . * / public Object g e t A c t i v i t y ( j a v a x . s l e e . r e s o u r c e . A c t i v i t y H a n d l e activityHandle ) { l o g g e r . debug ( ” RAFrameResourceAdaptor . g e t A c t i v i t y c a l l e d . ” ) ; return a c t i v i t i e s . g e t ( a c t i v i t y H a n d l e ) ; } Cuando una Actividad espec´ ıfica termina, el RA es notificado por el entorno JSLEE mediante la invocaci´n del m´todo activityEnded(). Aqu´ el RA borra la actividad ideno e ı, tificada por su Manejador del objeto HashMap. Listado 9.18: M´todo activityEnded() e / * * Implementa j a v a x . s l e e . r e s o u r c e . ResourceAdaptor . Por f a v o r * c o n s u l t e l a e s p e c i f i c a c i ´ n JSLEE v1 . 1 , Borrador R e c i e nt e m e nt e o * r e v i s a d o ; P´ g . 301 para m´s i n f o r m a c i ´ n . El e n t o r n o SLEE l l a m a a a o * a e s t e m´todo para i n f o r m a r a l RA que e l e n t o r n o SLEE ha e * terminado de p r o c e s a r l a a c t i v i d a d para l a a c t i v i d a d * r e p r e s e n t a d a por e l manejador de a c t i v i d a d e s . El RA p o d r´a ı * p u b l i c a r c u a l q u i e r r e c u r s o r e l a c i o n a d o con e s t a a c t i v i d a d ya * que e l e n t o r n o SLEE no p r e g u n t a r por e l l a m´s . * / a public void a c t i v i t y E n d e d ( j a v a x . s l e e . r e s o u r c e . A c t i v i t y H a n d l e activityHandle ) { // q u i t a e l manejador de l a l i s t a de a c t i v i d a d e s a c t i v i t i e s . remove ( a c t i v i t y H a n d l e ) ; l o g g e r . debug ( ” RAFrameResourceAdaptor . a c t i v i t y E n d e d ( ) llamado . ” ) ; } Para resumir el ciclo de vida de los objetos Actividades: Una Actividad espec´ ıfica es creada por el m´todo del RA onEvent() cuando un Evento inicial es recibido - aqu´ e ı: el mensaje INIT. Durante el ciclo de vida de la Actividad esta es accesible mediante el m´todo del RA getActivity().Tan pronto como la Actividad termina, el entorno JSLEE e notifica al RA invocando activityEnded(). Ahora el RA borrara la Actividad de su almacenamiento. 9.1.15. RA Deployment Descriptor El DD resource-adaptor-jar.xml define un nombre para el RA y asocia al RA con el RA Type.
- 120. 88 ´ CAP´ ITULO 9. MEJORES PRACTICAS Listado 9.19: resource-adaptor-jar.xml <? xml v e r s i o n="1.0" e n c o d i n g="ISO -8859 -1" ?> <r e s o u r c e −adaptor−j a r> <r e s o u r c e −a d a pt o r i d=" raframe_1 .0 _RA"> <d e s c r i p t i o n> Michael Maretzke RA framework r e s o u r c e adaptor−v e r s i o n 1 . 0 </ d e s c r i p t i o n> <r e s o u r c e −adaptor−name> raframe </ r e s o u r c e −adaptor−name> <r e s o u r c e −adaptor−vendor> maretzke </ r e s o u r c e −adaptor−vendor> <r e s o u r c e −adaptor−v e r s i o n> 1.0 </ r e s o u r c e −adaptor−v e r s i o n> <!−− JSLEE v1 . 1 S p e c i f i c a t i o n , E a r l y D r a f t Review Page 292 ”A r e s o u r c e −adaptor−type−r e f e l e m e n t . This e l e m e n t r e f e r e n c e s a r e s o u r c e a d a p t o r type . One o r more r a type r e f e r e n c e e l e m e n t s may be p r e s e n t i n t h e deployment d e s c r i p t o r . I t c o n t a i n s t h e f o l l o w i n g elements: * A d e s c r i p t i o n e l e m e n t . This i s an o p t i o n a l i n f o r m a t i o n a l element . * A r e s o u r c e −adaptor−type−name e l e m e n t * A r e s o u r c e −ada pt ortype −vendor e l e m e n t * A r e s o u r c e −adaptor−type−v e r s i o n e l e m e n t . These e l e m e n t s u n i q u e l y i d e n t i f y a r e s o u r c e type d e c l a r e d i n a r e s o u r c e a d a p t o r −type e l e m e n t s p e c i f i e d i n a n o t h e r deployment d e s c r i p t o r . A r e s o u r c e −adaptor−type e l e m e n t d e c l a r e s a r e s o u r c e a d a p t o r type . ” −−> <r e s o u r c e −adaptor−type−r e f> <r e s o u r c e −adaptor−type−name> raframe ratype </ r e s o u r c e −adaptor−type−name> <r e s o u r c e −adaptor−type−vendor> maretzke </ r e s o u r c e −adaptor−type−vendor> <r e s o u r c e −adaptor−type−v e r s i o n> 1.0 </ r e s o u r c e −adaptor−type−v e r s i o n> </ r e s o u r c e −adaptor−type−r e f> El RA-Type para nuestro RA especifica tres Eventos: INIT, ANY y END. La etiqueta event-type-name se refiere al event-definition encontrado en el DD event-jar.xml.
- 121. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 9.1.16. 89 Construyendo el RA Pasos para desplegar el RAFrame. 1. Build el ejemplo: vamos al ejemplo RAFrame y ejecutamos ant. Introducir´ varios a .jar en diversas carpetas y devolver´ el mensaje: a BUILD SUCCESSFUL 2. Ejecutamos el servidor mobicents, inicio ejecutar: run -c all -b localhost Figura 9.6: Consola Mobicents. 3. Abrimos un navegador y entramos en http://localhost:8080/jmx-console 4. Hacemos un filtrado poniendo en la caja de textos slee:* 5. Entramos en name=DeploymentMBean 6. Buscamos el m´todo install con un unico par´metro de tipo String, e introducimos e ´ a la ruta donde esta el archivo raframe-ra-type.jar por ejemplo: file:///C:/workspace/RAFrame/stage/raframe-ra-type.jar Nos devolver´ un DeploableUnitID con un identificador [*]. Por ejemplo: a DeployableUnitID [3]
- 122. ´ CAP´ ITULO 9. MEJORES PRACTICAS 90 Figura 9.7: Consola Mobicents. Si ya lo hubi´ramos echo, dar´ un error “Exception report”, con la descripci´n: e a o The server encountered an internal error () that prevented it from fulfilling this request. 7. Pulsamos en “Back to MBean View”, y en la misma caja de texto del m´todo e “install”, instalamos raframe-local-ra.jar por ejemplo: file:///C:/workspace/RAFrame/stage/raframe-local-ra.jar Y nos dar´ otro DeploableUnitID con un identificar diferente, por ejemplo a DeployableUnitID [4] 8. Pulsamos en “Back to Agent View” y pinchamos sobre: name=ResourceAdaptorMBean. 9. Vamos al m´todo createResourceAdaptorEntity que acepta tres par´metros, y e a con la caja de texto, “p1”, que acepta resourceAdaptorId, no confundir con la que acepta String. Introducimos: ResourceAdaptorID[raframe#maretzke#1.0], sin dejar espacios, en el primer par´metro a y RAFrameRA en el segundo, el tercero lo dejamos vac´ Lo invocamos y nos ıo. mostrar´ un mensaje como que esta bien hecho. a Operation completed successfully without a return value.
- 123. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 91 Figura 9.8: Consola Mobicents. Figura 9.9: Consola Mobicents. 10. Ya lo tenemos instalado, ahora toca activarlo, pulsamos en “Back to MBean View”, y vamos al m´todo activateResourceAdaptorEntity y en la unica caja de e ´ texto ponemos RAFrameRA. Invocamos, y te nos dar´ un mensaje como que esta a bien. Operation completed successfully without a return value.
- 124. 92 ´ CAP´ ITULO 9. MEJORES PRACTICAS Figura 9.10: Consola Mobicents 11. Por ultimo pulsamos en “Back to MBean View” y buscamos el evento CreateEntityLink e introducimos en ambas cajas de texto RAFrameRA. Invocamos y ya est´. a Operation completed successfully without a return value. Figura 9.11: Consola Mobicents. Ahora tenemos desplegado el RA, y podemos ver lo que ha pasado en la consola de mobicents.
- 125. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 9.1.17. 93 Construyendo el SBB 1. Copiamos el fichero raframe-1.0.jar que se encuentra en el directorio dist del ejemplo del RAframe en la librer´ del SBB, que se encuentra en el directorio lib, ıa vamos a la carpeta del SBB y ejecutamos ant. 2. Construir el ejemplo: vamos al ejemplo RAFrame y ejecutamos ant. Introducir´ vara ios .jar en diversas carpetas y devolver´ el mensaje: a BUILD SUCCESSFUL 3. Con el servidor mobicents ejecut´ndose, abrimos un navegador y entramos en: a http://localhost:8080/jmx-console 4. Haz un filtrado poniendo en la caja de textos slee:* 5. Entra en “name=DeploymentMBean” 6. Busca el m´todo “install” con un unico par´metro de tipo String, e introduce la e ´ a ruta donde esta el archivo bounceSBB-service.jar, por ejemplo: file:///C:/workspace/RASBB/dist/bounceSBB-service.jar Nos dar´ una id, por ejemplo: a DeployableUnitID [5] Figura 9.12: Consola Mobicents. El servicio ya est´ instalado. a
- 126. 94 ´ CAP´ ITULO 9. MEJORES PRACTICAS 7. El siguiente paso es activar el servicio, pulsamos en “Back to Agent View“ y entrar en ServiceManagementMBean y vete al evento activate que acepta “javax.slee.ServiceID” e introducimos el valor: ServiceID[Resource Adaptor FrameworkBounceService#maretzke#1.0] Operation completed successfully without a return value. Figura 9.13: Consola Mobicents. Inv´calo y el servicio estar´ desplegado y esperando por Eventos. Podemos ver el o a esquema con SLEE Graph Viewer: C:workspaceslee-graphant run
- 127. 9.1. RAFRAME (RESOURCE ADAPTER FRAMEWORK) 95 Figura 9.14: Esquema obtenido con Mobicents SLEE Graph Viewer. Si tenemos instalado Mobicents Management Console, podemos ver el Servicio creado, Resource Adaptor Framework Bounce Service, el SBB RAFBounceSBB, El Resource Adaptor Type raframe ratype, el Resource Adaptor raframe y los Eventos: com.maretzke.raframe.message.incoming.INIT com.maretzke.raframe.message.incoming.ANY com.maretzke.raframe.message.incoming.END
- 128. 96 ´ CAP´ ITULO 9. MEJORES PRACTICAS Figura 9.15: Componentes vistos en MMC. Figura 9.16: Unidades Desplegadas vistas en MMC.
- 129. 9.2. SERVICIOS ESCALABLES 9.2. 97 Servicios escalables En esta secci´n veremos como implementar servicios escalables de interceptaci´n de o o llamadas. 9.2.1. Enunciado del problema ¿C´mo escribir un servicio escalable que intercepte las solicitudes de llamada JCC? o Condiciones: El servicio OBLIGATORIAMENTE tiene que ser escalable. Debe ser realmente f´cil a˜adirle nuevos servicios. a n La idea b´sica es que debo tener un servicio principal recibiendo/enviando llamadas a mediante un adaptador de recursos JCC. Este servicio comprueba contra una base de datos si el llamado o la parte receptora tiene alg´n servicio conectado. Si no hay ning´n u u servicio conectado a la llamada, la llamada simplemente se reenv´ la llamada, pero si ıa hay un servicio conectado a la llamada, el servicio principal debe disparar un evento personalizado que invoca el servicio apropiado y traslada la llamada a ese servicio. Usando este modelo minimizar´ las b´squedas en la base de datos, ya que esto es e u un cuello de botella. Si tengo 15 servicios en el SLEE y todos los servicios dialogaran directamente con el adaptador JCC, cada llamada generar´ 15 b´squedas en la base de ıa u datos. Si lo hago como he descrito anteriormente solo necesitar´ 2 b´squedas: primero ıa u la del servicio principal y segundo la del servicio que contiene la l´gica del negocio. o El modelo tambi´n hace f´cil la instalaci´n de nuevos servicios al SLEE. Todo lo e a o que se tiene que hacer es desplegar un servicio que tenga el evento personalizado como un evento inicial. Ahora los problemas con este modelo: Para facilitar el a˜adido de nuevos servicios todos los servicios tienen el evento n personalizado como evento inicial. Esto implica que el servicio principal invoca a TODOS los dem´s servicios y el a servicio en s´ mismo debe comprobar con el evento si es el servicio adecuado. Esto ı provoca una carga innecesaria en el SLEE. Ser´ genial si se pudiera configurar ıa el servicio principal para disparar diferentes eventos personalizados para cada servicio, pero simplemente no puedo imaginarme una buena manera de hacer esto mediante los perfiles. El evento inicial no deber´ ser desplegado con el servicio ıa principal, sino con el servicio que incluye la l´gica de negocio, todo para hacer un o servicio basado en m´dulos y tan desconectado como sea posible. o Me gustar´ que el servicio principal manejara todas las comunicaciones con el ıa adaptador JCC, pero no s´ c´mo enviar un evento desde un servicio al servicio e o principal. Necesito esto para reenviar la llamada.
- 130. ´ CAP´ ITULO 9. MEJORES PRACTICAS 98 9.2.2. Respuesta Usa la tabla de perfiles de direcciones y el identificador AddressProfile de la variable initial-event-select. Echa un ojo a la secci´n 10.13.2 para una descripci´n de AddressProfileTable y las o o secciones 8.5.2 (p´gina 112) y 8.5.3. (p´gina 114) de la especificaci´n del JAIN SLEE [?] a a o para el papel de AddressProfiles en el c´lculo del nombre convergente. Tambi´n puedes a e ver un ejemplo de un fragmento de un descriptor de despliegue en la p´gina 108. a Si sigues este enfoque, debes crear un AddressProfiles de cada servicio para cada direcci´n que deba causar la activaci´n del servicio. No habr´ necesidad de usar una o o ıa base de datos externa en absoluto. Tambi´n podr´ adoptar este enfoque en concordancia con el servicio principal. e ıas Crea un AddressProfile para cada servicio con una direcci´n unica que ’identifica’ el o ´ servicio. El servicio principal podr´ deisparar sus eventos personalizados con una diıa recci´n que corresponda al servicio que se debe activar para la llamada. o
- 131. ´ 9.3. COMO CONSTRUIR UN SERVICIO SIP REGISTRAR EN SLEE 99 9.3. C´mo construir un servicio SIP Registrar en SLEE o 9.3.1. Descripci´n del servicio o El agente de usuario env´ un mensaje al SLEE. SLEE registrar´ la localizaci´n del ıa a o agente de usuario y env´ la respuesta OK al usuario. El servicio tambi´n iniciar´ un ıa e a temporizador de registro. Si el usuario no env´ una nueva petici´n de registro antes de ıa o que el temporizador finalice, el servicio Registrar borrar´ dicho registro de la base de a datos de localizaciones. 9.3.2. Implementaci´n del servicio o 9.3.2.1. Primera implementaci´n o El servicio “SIP Registrar Service Sbb”,“NIST”,“1.0” tiene un Sbb ra´ “Registrar ız Sbb”, “NIST”, “1.0”. El descriptor de despliegue del servicio es el siguiente: Listado 9.20: Descriptor de despliegue de SIP Registrar <s e r v i c e −xml> <s e r v i c e> <s e r v i c e −name>SIP R e g i s t r a r S e r v i c e</ s e r v i c e −name> <s e r v i c e −vendor>NIST</ s e r v i c e −vendor> <s e r v i c e −v e r s i o n>1 . 0</ s e r v i c e −v e r s i o n> <r o o t −sbb> <sbb−name>S i p R e g i s t r a r Sbb</ sbb−name> <sbb−vendor>NIST</ sbb−vendor> <sbb−v e r s i o n>1 . 0</ sbb−v e r s i o n> </ r o o t −sbb> <d e f a u l t −p r i o r i t y>0</ d e f a u l t −p r i o r i t y> </ s e r v i c e> </ s e r v i c e −xml> 9.3.2.2. Eventos del servicio El descriptor de despliegue del SBB Registrador especifica 2 eventos: 1. M´todo de solicitud de registro JAIN SIP. Observemos las propiedades del evento e en el DD: a) Se recibe la petici´n de este evento, el SBB tiene que definir un manejador o para consumir el evento. b) Este evento es un evento inicial. c) Se instalar´ un nuevo servicio cuando quiera que un evento proveniente del a RA se dispare en un nuevo contexto de actividad. d ) El contexto de actividad tiene un mapeado 1-a-1 con una actividad dentro del RA de SIP. e) El tipo del adaptador de recursos JAIN SIP define una actividad, que tiene asociada una transacci´n SIP. o
- 132. ´ CAP´ ITULO 9. MEJORES PRACTICAS 100 f ) Una transacci´n SIP es una abstracci´n del protocolo SIP que gestiona el o o paradigma solicitud-respuesta. Una transacci´n SIP se puede comparar f´cilo a mente con una conversaci´n telef´nica. Una transacci´n SIP tiene lugar entre o o o un cliente y un servidor y contiene todos los mensajes desde la primera solicitud enviada por el cliente al servidor hasta la respuesta final no-1XX. g) Habr´ una instanciaci´n del servicio para cada solicitud REGISTER. De a o tal manera que si el servicio tiene 100 usuarios que intentan registrarse y cada usuario env´ 4 solicitudes de registro, el servicio ser´ instanciado 400 ıa a veces (lo que podr´ producir un un ataque por inundaci´n. Ver notas de ıa o seguridad). 2. JAIN SLEE TimerEvent. a) La direcci´n para este evento es de recepci´n. El evento tiene que definir un o o manejador para gestionar el evento. b) Este evento no es un evento inicial.
- 133. ´ 9.3. COMO CONSTRUIR UN SERVICIO SIP REGISTRAR EN SLEE Listado 9.21: SIP REGISTRAR SBB <sbb−j a r> <sbb i d=" sip - registrar - sbb "> <d e s c r i p t i o n>JAIN SIP R e g i s t r a r SBB</ d e s c r i p t i o n> <sbb−name>S i p R e g i s t r a r Sbb</ sbb−name> <sbb−vendor>NIST</ sbb−vendor> <sbb−v e r s i o n>1 . 0</ sbb−v e r s i o n> <sbb−c l a s s e s> <sbb−a b s t r a c t −c l a s s> <sbb−a b s t r a c t −c l a s s −name> gov . n i s t . s l e e . t e s t . s e r v i c e s . s i p . r e g i s t r a r . RegistrarSbb </ sbb−a b s t r a c t −c l a s s −name> </ sbb−a b s t r a c t −c l a s s> <sbb−a c t i v i t y −c o n t e x t −i n t e r f a c e> <sbb−a c t i v i t y −c o n t e x t −i n t e r f a c e −name> gov . n i s t . s l e e . t e s t . s e r v i c e s . s i p . r e g i s t r a r . RegistrarActivityContextInterface </ sbb−a c t i v i t y −c o n t e x t −i n t e r f a c e −name> </ sbb−a c t i v i t y −c o n t e x t −i n t e r f a c e> </ sbb−c l a s s e s> <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t=" True "> <event−name>R e g i s t e r E v e n t</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . message . Request . REGISTER</ event−type−name> <event−type−vendor>j a v a x . s i p </ event−type−vendor> <event−type−v e r s i o n>1 . 1</ event−type−v e r s i o n> </ event−type−r e f> < i n i t i a l −event−s e l e c t v a r i a b l e=" ActivityContext " /> </ e v e n t> <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t=" False "> <event−name>TimerEvent</ event−name> <event−type−r e f> <event−type−name>j a v a x . s l e e . f a c i l i t i e s . TimerEvent</ event−type−name> <event−type−vendor>j a v a x . s l e e </ event−type−vendor> <event−type−v e r s i o n>1 . 0</ event−type−v e r s i o n> </ event−type−r e f> </ e v e n t> <r e s o u r c e −adaptor−type−b i n d i n g> . . . . . </ r e s o u r c e −adaptor−type−b i n d i n g> </ sbb> </ sbb−j a r> 101
- 134. ´ CAP´ ITULO 9. MEJORES PRACTICAS 102 9.3.2.3. L´gica de servicio o La funci´n onRegisterEvent dentro del SBB registrador: o 1. Crea una entrada para la url del agente de usuario del sip dentro de la localizaci´n o servicedb. La entrada contiene la siguiente informaci´n: el punto de contacto del o agente de usuario (direcci´n IP y puerto UDP), la hora en que esta entrada expira, o CallID y el n´mero de secuencia de la petici´n SIP. u o 2. Crea un nuevo NullActivity. 3. Crea un temporizador activ´ndolo con el tiempo de expiraci´n. a o 4. Se a˜ade a ´l mismo, junto con el temporizador al ActivityContext correspondiente n e al recientemente creado NullActivity. 5. El SBB configura el n´mero de secuencia de la solicitud de registro dentro del u ActivityContext usando RegisterActivityContextInterface. 9.3.2.4. Temporizador Cuando el temporizador finaliza, se invoca al m´todo onTimerEvent. e El SBB comprueba el valor de ActivitContext usando RegisterActivityContextInterface y lo compara con el valor de la localizaci´n de la entrada. Si el valor del servicio o de localizaci´n es mayor que el valor de ActivityContext, este registro ha sido actualo izado por una nueva solicitud de registro. En este caso,el servicio no borra el valor de la entrada de registro. Si el valor es igual al valor del ActivityContext, el registro ha expirado y el servicio borra la entrada de localizaci´n para la url sip dada. o Listado 9.22: Interfaz de AC Register public i n t e r f a c e R e g i s t r a r A c t i v i t y C o n t e x t I n t e r f a c e extends ActivityContextInterface { / * * s i p A d d r e s s − User ’ s p u b l i c , w e l l −known SIP a d d r e s s * / public S t r i n g g e t S i p A d d r e s s ( ) ; public void s e t S i p A d d r e s s ( S t r i n g s i p A d d r e s s ) ; / * * s i p C o n t a c t A d d r e s s − P h y s i c a l network a d d r e s s r e g i s t e r e d f o r above s i p A d d r e s s * / public S t r i n g g e t S i p C o n t a c t A d d r e s s ( ) ; public void s e t S i p C o n t a c t A d d r e s s ( S t r i n g s i p C o n t a c t A d d r e s s ) ; / * * c a l l I d − SIP c a l l I d t h a t was used i n t h e REGISTER r e q u e s t */ public S t r i n g g e t C a l l I d ( ) ; public void s e t C a l l I d ( S t r i n g c a l l I d ) ; / * * cSeq − SIP s e q u e n c e number t h a t was used i n t h e REGISTER r e q u e s t */ public long getCSeq ( ) ; public void setCSeq ( long cSeq ) ; }
- 135. ´ 9.3. COMO CONSTRUIR UN SERVICIO SIP REGISTRAR EN SLEE 9.3.2.5. 103 Comentarios El problema de este enfoque es que cada vez que se env´ una nueva petici´n SIP ıa o se le env´ al SLEE el servicio crear´ una nueva instancia del SBB root, lo que conlleıa a var´ a la creaci´n de una nueva NullActivity y un nuevo temporizador. Si tenemos 100 a o usuarios del sistema y cada usuario env´ 4 solicitudes de registro, el servicio crear´ 400 ıa a instancias del servicio y para cada instancia del servicio crear´ 400 SBB ra´ 400 Nula ız, lActivities y 400 temporizadores. Cada SBB ra´ se eliminar´ solo despu´s de que haya ız a e finalizado el temporizador asociado. Los 400 temporizadores finalizaran, ya que cuando llega una nueva petici´n, los o temporizadores previos no se cancelan. De cara a la base de datos de localizaciones, se escribe una entrada para cada solicitud de REGISTER durante la llamada a onRegisterEvent, y se leer´ una entrada en a el m´todo onTimerEvent. Si el registro expira, tambi´n se producir´ una eliminaci´n e e a o de una entrada de la base de datos. Esto conllevar´ 400 escrituras de entradas, 400 lecturas y X eliminaciones de ena tradas. 9.3.2.6. Objetivos a mejorar Queremos reducir el n´mero de instancias del servicio y de recursos usados por u el SLEE. Queremos cancelar el temporizador cuando ya no tengan significado (por ejemplo, cuando venga una nueva petici´n para una URI determinada, el temporizador o asociado con la solicitud anterior deber´ ser cancelado). ıa Queremos evitar que un usuario inunde el SLEE en caso de no parar de enviar solicitudes REGISTER. 9.3.3. 9.3.3.1. Segunda implementaci´n o Estrategia El servicio se instanciar´ s´lo una vez para cada URL sip, lo que se puede hacer usa o ando el atributo Address de initial-event-select-variable. El servicio Register crear´ un a nuevo nullactivity cuando el SBB ra´ se crea (por ejemplo en el m´todo postCreate). ız e El SBB ra´ tendr´ un campo persistente donde el SBB puede almacenar el TimerID ız a del ultimo temporizador que se ha lanzado por el SBB ra´ Cuando viene un registro, ´ ız. el temporizador anterior se cancela, y se pone un nuevo temporizador en el null Activity Context. Si el servicio tiene 100 agentes de usuario, y cada uno manda 4 solicitudes de registro se tendr´n 100 instancias del servicio, 100 nullActivity y 100 temporizadores a en ejecuci´n. o
- 136. ´ CAP´ ITULO 9. MEJORES PRACTICAS 104 9.4. Otras buenas pr´cticas a Preguntas y respuestas. 9.4.1. ¿C´mo medir la duraci´n de una llamada SIP? o o Un ejemplo simple que usa campos CMP y nombres de convergencia para controlar la duraci´n de una llamada SIP: o Lo primero que necesitamos es guardar un valor Double con el valor de la hora actual en milisegundos. Este valor se guarda en un campo CMP para que se pueda recuperar posteriormente. Guardaremos este valor cuando tengamos un evento de petici´n ACK (despu´s o e de un evento de petici´n de INVITE) o Despu´s de esto, comprobaremos el tiempo transcurrido cuando recibamos un e evento de petici´n BYE. o Para garantizar que recibamos la hora guardada correcta en el m´todo que maneja e el evento BYE, debemos garantizar que ese evento lo recibe la misma entidad SBB que guard´ la hora inicial. o A continuaci´n vemos los descriptores de despliegue del SBB, conde se declara el o campo CMP y el nombre de convergencia:
- 137. ´ 9.4. OTRAS BUENAS PRACTICAS Listado 9.23: DD del SBB para medir la duraci´n de una llamada SIP o <sbb−j a r> <sbb i d="sip -proxy -sbb"> <d e s c r i p t i o n>JAIN SIP Proxy SBB</ d e s c r i p t i o n> <sbb−name>ProxySbb</ sbb−name> <sbb−vendor>NIST</ sbb−vendor> <sbb−v e r s i o n>1 . 0</ sbb−v e r s i o n> ... <sbb−c l a s s e s> ... <cmp− f i e l d> <d e s c r i p t i o n>Save t h e c u r r e n t time </ d e s c r i p t i o n> <cmp−f i e l d −name>s t a r t T i m e</cmp−f i e l d −name> </cmp− f i e l d> ... </ sbb−c l a s s e s> ... <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True"> <event−name>AckEvent</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . message . Request .ACK </ event−type−name> <event−type−vendor>j a v a x . s i p </ event−type−vendor> <event−type−v e r s i o n>1 . 1</ event−type−v e r s i o n> </ event−type−r e f> < i n i t i a l −event−s e l e c t o r −method−name> initialEventSelect </ i n i t i a l −event−s e l e c t o r −method−name> </ e v e n t> ... <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True"> <event−name>ByeEvent</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . message . Request .BYE </ event−type−name> <event−type−vendor>j a v a x . s i p </ event−type−vendor> <event−type−v e r s i o n>1 . 1</ event−type−v e r s i o n> </ event−type−r e f> < i n i t i a l −event−s e l e c t o r −method−name> initialEventSelect </ i n i t i a l −event−s e l e c t o r −method−name> </ e v e n t> ... </ sbb> </ sbb−j a r> 105
- 138. ´ CAP´ ITULO 9. MEJORES PRACTICAS 106 El SBB deber´ parecerse a esto (De esta manera todos los eventos BYE y ACK ıa que tengan el mismo identificador de llamada ir´n a la misma entidad del SBB): a Listado 9.24: JainSipProxySbb public abstract c l a s s JainSipProxySbb extends Sbb { /* * * Generate a custom c o n v e r g e n c e name s o t h a t Byes w i l l match t h e i r * r e s p e c t i v e ACKs, s o t h e BYE e v e n t w i l l go t o t h e same r o o t SBB e n t i t y * t h a t p r o c e s s e d t h e ACK. * CN format i s C a l l −ID * For o t h e r methods , u s e A c t i v i t y C o n t e x t . */ public I n i t i a l E v e n t S e l e c t o r initialEventSelect ( InitialEventSelector ies ) { Object e v e n t = i e s . getEvent ( ) ; i f ( e v e n t instanceof RequestEvent ) { Request r e q u e s t = ( ( RequestEvent ) e v e n t ) . getRequest ( ) ; S t r i n g method = r e q u e s t . getMethod ( ) ; i f ( method . e q u a l s ( Request .ACK) | | method . e q u a l s ( Request .BYE) ) { String c a l l I d = (( CallIdHeader ) request . getHeader ( C a l l I d H e a d e r .NAME) ) . g e t C a l l I d ( ) ; i e s . setCustomName ( c a l l I d ) ; } else { i e s . s e t A c t i v i t y C o n t e x t S e l e c t e d ( true ) ; } } return i e s ; }
- 139. ´ 9.4. OTRAS BUENAS PRACTICAS Listado 9.25: onByeEvent(RequestEvent public void onByeEvent ( RequestEvent event , A c t i v i t y C o n t e x t I n t e r f a c e ac ) { try { Request r e q u e s t = e v e n t . g e t R e q u e s t ( ) ; ServerTransaction serverTransaction = event . getServerTransaction ( ) ; p r o c e s s R e q u e s t ( s e r v e r T r a n s a c t i o n , r e q u e s t , ac ) ; double elapsedTime = System . c u r r e n t T i m e M i l l i s ()− getCallStartTime ( ) ; System . out . p r i n t l n ( ” ***** Elapsed time : ” + S t r i n g . v a l u e O f ( elapsedTime ) + ” m i l l i s e c o n d s ” ) ; System . out . p r i n t l n ( ” ***** Elapsed time : ” + S t r i n g . v a l u e O f ( ( elapsedTime /1000))+ ” s e c o n d s ” ) ; } catch ( E x c e p t i o n e ) { t r a c e ( L e v e l .WARNING, ” E x c e p t i o n d u r i n g onByeEvent ” , e ) ; } } Listado 9.26: onAckEvent, getCallStartTime() y setCallStartTime public void onAckEvent ( RequestEvent event , A c t i v i t y C o n t e x t I n t e r f a c e ac ) { try { Request r e q u e s t = e v e n t . g e t R e q u e s t ( ) ; ServerTransaction serverTransaction = event . getServerTransaction ( ) ; p r o c e s s R e q u e s t ( s e r v e r T r a n s a c t i o n , r e q u e s t , ac ) ; double tempo = System . c u r r e n t T i m e M i l l i s ( ) ; s e t C a l l S t a r t T i m e ( tempo ) ; } catch ( E x c e p t i o n e ) { t r a c e ( L e v e l .WARNING, ” E x c e p t i o n d u r i n g onAckEvent ” , e ) ; } } /* . . . */ public abstract double g e t C a l l S t a r t T i m e ( ) ; public abstract void s e t C a l l S t a r t T i m e ( double t i m e m i l l i s ) ; } 107
- 140. ´ CAP´ ITULO 9. MEJORES PRACTICAS 108 9.4.2. Granularidad SBB para manejo de llamadas ¿Cu´ndo ser´ adecuado instanciar un SBB por cada llamada y cu´ndo usar el misa a a mo SBB para procesar todas las llamadas provenientes de, digamos, un evento especial o un contexto de actividad? Si instancias un SBB ra´ por cada llamada basado en el identificador de la llamada, ız entonces puedes amortizar la autenticaci´n. La actividad en este caso se extiende a lo o largo de toda la llamada, y se identifica por el identificador de la llamada. Esto tambi´n e tendr´ sentido si est´s construyendo un componente stateless, como un servidor proxy ıa a SIP. Por otra parte, si instancias un SBB por tipo de eventos, como un SBB por INVITE entonces b´sicamente est´s asociando el SBB con la transacci´n SIP y la entidad se a a o extiende solamente el periodo que ocupe la transacci´n. Esto tendr´ sentido si est´s o ıa a 2. construyendo un servicio stateful como un servicio IVR De todas maneras, es una buena pregunta, y me gustar´ o´ otras opiniones. ıa ır Esto trae consigo varias cuestiones en la manera en que el SIP RA funcionar´. a Pienso que este comportamiento deber´ estardarizarse para conseguir la portabilidad ıa de los servicios. Actualmente s´lo hay una recomendaci´n en el SIP RA Type. o o 9.4.3. Actualizando perfiles desde los SBB Tengo curiosidad por saber la raz´n para no permitir a los SBB crear y actualizar o perfiles. Por ejemplo, si tuviera un servicio de telecomunicaciones que usara los perfiles para mantener el estado de qu´ direcciones procesar y c´mo (bloquearlas, redirigirlas, e o auto-reply, etc) estar´ bien poder actualizar estos perfiles desde, por ejemplo, una apliıa caci´n J2EE pas´ndole eventos a un “servicio de actualizaci´n de perfiles” personalo a o 3 , pero a´n as´ me gustar´ o´ izado. Desde luego, podr´ usar un JMX adaptor MLET ıa u ı ıa ır los motivos La respuesta simple es que no ten´ ıamos los requisitos suficientemente bien definidos para incluirlos en la versi´n 1.0. [7] De todas maneras ten´ o ıamos un plan para ello, e incluimos los m´todos set en la interfaz de los perfiles. Para proporcionar un poco m´s e a de contexto, nuestra visi´n de los perfiles en el SLEE era que se entendieran como una o cache de los datos que se necesitara entregar para proporcionar el servicio. Sin embargo no era la fuente de datos principal. Si permit´ ıamos actualizar los datos, eso significar´ ıa que se convertir´ en una fuente de datos principal. Est´bamos preocupados de que ıa a el SLEE se convirtiera en la fuente de datos principal, porque no quer´ ıamos imponer al SLEE los requisitos (persistencia, consistencia, estabilidad, ...) asociados con una fuente de datos principal. Pens´bamos que ese era el trabajo de una base de datos o a alg´n sistema OSS (con una base de datos) y el SLEE no se pens´ para ser un sustituto u o de una base de datos o un sistema OSS. Con m´s tiempo, se podr´ haber a˜adido a ıan n algunos de estos temas a la versi´n 1.0. De todas maneras, la comunidad sent´ que no o ıa merec´ la pena retrasar la versi´n 1.0 para a˜adir direcciones y mejoras en los perfiles. ıa o n 2 3 Interactive Voice Response, Management applet
- 141. ´ 9.4. OTRAS BUENAS PRACTICAS 109 Desde la versi´n 1.0 hemos resuelto muchas de las consideraciones anteriores como o parte del trabajo en la versi´n 1.1. La especificaci´n 1.1 [8] soportar´ actualizaciones o o a a los perfiles, lo que conlleva inconvenientes sobre c´mo validar los cambios (similar o a las clases Profile Management) y c´mo proporcionar mecanismos para exportar y o sincronizar las actualizaciones con la base de datos final. 9.4.4. Prioridad de los eventos del SBB y entrega de los eventos Si dos servicios (SBBs ra´ ıces) tienen distintas prioridades por defecto, por ejemplo: SBB1 prioridad por defecto = 100 SBB2 prioridad por defecto = 50 Ambos eventos pueden recibir el evento e. ¿Cu´ndo obtiene el SBB2 el evento a e?¿Cu´ndo finaliza el manejador del SBB1 o un tiempo despu´s de que el SBB1 lo a e haya recibido? Tal como yo lo veo, el SLEE s´lo procesa un evento a la vez. o El SBB2 recibe el evento despu´s de que el SBB1 haya acabado de procesarlo. Si e fuera “un tiempo despu´s” derivar´ en un comportamiento impredecible del servicio. e ıa 9.4.5. ¿Cu´l es el lugar correcto para inicializar los SBBs a con referencias a los RAs? Mi evento tiene dos manejadores: onEvent1() (inicial) onEvent2() El m´todo sbbCreate busca otro RA y guarda la referencia al proveedor en un campo e privado. Cuando se dispara event1, se crea una nueva actividad y un nuevo SBB, y el SBB se suscribe a esta actividad. El m´todo event1 entonces hace algo que deriva en la recepci´n e o de event2 por el m´todo adecuado. Cuando se llama al m´todo de event2 intenta acceder e e al proveedor, pero falla porque el campo contiene un campo vacio. Nunca se ha llamado a sbbCreate en el objeto sbb. Cuando se lee la especificaci´n 1.0 no queda totalmente claro pero parece que un o SBB puede transferir al estado activo y manejar un evento en este orden: newInstance() -> set SbbContext -> _pooled -> sbbActivate() -> _Ready -> onEventXY (no-inicial) ¿Es verdad esto? Si lo es, ¿d´nde deber´ a˜adir funcionalidad que inicialice un objeto sbb, como un o ıa n proveedor y activity context interface factory lookup? Esto puede producir excepciones, as´ que supongo que hay que ponerlas en sbbCreate(). En el constructor las b´squedas ı u no se pueden efectuar porque no est´ disponible el contexto y no permite que se lancen a
- 142. ´ CAP´ ITULO 9. MEJORES PRACTICAS 110 excepciones. Lo ultimo se aplica para el m´todo sbbActivate. ´ e Deber´ tenerlo en dos lugares: sbbCreate/sbbPostCreate y sbbActivate. Si miras ıas en el diagrama de ciclos de vida (figura 5, p´gina 50 [7]), si hay alguna funci´n que a o necesites ejecutar cuando un sbb cambia de Pooled a Ready, necesitas hacerlo en todos los arcos que van de Pooled a Ready. Te sugiero que pongas este c´digo de inicializaci´n en un m´todo y llames a este o o e m´todo desde sbbCreate/sbbPostCreate y sbbActivate. e 9.4.6. ¿C´mo verificar si un contenedor SLEE conoce un EventTypeo ID? Estoy intentando implementar un RA que se pueda usar para comunicar un servidor SLEE y un servidor J2EE. El RA tiene los conceptos de evento y EventTypeID. Dado un EventTypeID (creado con el nombre del evento, el distribuidor y la versi´n), ¿C´mo puedo comprobar si el o o EventTypeID es v´lido? a Mira el cap´ ıtulo 13.6 [7] (Event Lookup Facility) o la p´gina 306 (BootstrapContext) a del borrador de la especificaci´n 1.1. [8] Este es un asunto que no se estandariz´ en la o o versi´n 1.0. Mobicents tiene la posibilidad de integrar RA 1.1. o Usando la especificaci´n 1.0 no hay una manera est´ndar para comprobar si un o a SLEE conoce un tipo de evento, necesitas preguntar al distribuidor del contenedor JAIN SLEE c´mo se puede hacer eso. JAIN SLEE 1.1 te permitir´ hacerlo usando la o a interfaz est´ndar EventLookupFacility. a 9.4.7. ¿Cu´ndo se deben usar perfiles y cu´ndo persistencia EJB o a a JDBC? La presencia de los perfiles s´lo est´ garantizada en implementaciones SLEE certio a ficadas, de tal manera que los desarrolladores obtienen portabilidad de aplicaciones en este ´rea. Adem´s existen otras implementaciones tecnol´gicas (p.ej.: JDBC4 , EJB, ...) a a o pero no son obligatorias y el TCK no la comprueba. Si no se pueden usar los perfiles para proporcionar una soluci´n apropiada, y otra o tecnolog´ s´ se puede usar, entonces esperar´ que los desarrolladores usaran la otra ıa ı ıa tecnolog´ ıa. En casos espec´ ıficos, tambi´n esperar´ que los desarrolladores construyeran solue ıa ciones buscando al menos una combinaci´n de: o Conveniencia de la implementaci´n tecnol´gica. o o Arquitectura de red para acceder a los datos (p.ej.: IMS est´ yendo a todos los a suscriptores de datos que est´n en el HSS) a 4 Java Database Connectivity
- 143. ´ 9.4. OTRAS BUENAS PRACTICAS 9.4.8. 111 ¿C´mo se manejan los eventos si no hay ning´ n o u consumidor desplegado? En caso de que un adaptador de recursos reciba un disparador de red (IDP en el caso del SS7) este disparador se convierte en un evento y se reenv´ a los servicios ıa interesados (o los servicios lo recogen). Si no hay ning´n evento desplegado el evento u acaba en ninguna parte, es decir, que el elemento de red original que inici´ el disparador o puede estar a´n esperando por una respuesta que, desde luego, nunca llegar´. Entonces u a la idea es invocar alg´n “m´todo manejador de eventos por defecto” en el RA que u e inici´ el evento. o Conceptualmente no veo c´mo los JAIN SLEE est´ndar est´n tratando este asunto. o a a Pienso que los est´ndares actuales no consideran esto en absoluto. T´cnicamente, el a e SLEE por s´ mismo no sabe c´mo interactuar con el RA, y por tanto no puede invocar ı o ning´n m´todo de respuesta por defecto en ese RA. u e ¿Hay alguna posibilidad de desplegar un tipo de servicio manejador por defecto para cada RA que se invoque s´lo si ning´n otro servicio ha consumido ese evento? o u Estar´ bien conseguir dos cosas: ıa 1. Obtener una indicaci´n de ese tipo de situaciones (una alarma). o 2. Actuar en modo por defecto para cada RA desplegado. Ninguna de esas cosas est´ especificada actualmente en los est´ndares. ¿Considerar´n a a a esto especificaciones futuras de JAIN SLEE? La arquitectura RA en 1.1 [8] define que un RA que env´ un evento recibe inforıa maci´n de vuelta sobre c´mo procesa ese evento el SLEE. Se invoca despu´s de que o o e el SLEE ha entregado el evento a cualquier SBB interesado e incluye una bandera de estado indicando si alg´n SBB recibi´ el evento o no. u o Esto significa que el RA proporciona la acci´n espec´ o ıfica dependiente del protocolo si ning´n servicio consumi´ ese evento. Por lo tanto, puede disparar una alarma y puede u o ejecutar alguna acci´n apropiada (por ejemplo, mandar una se˜al continue+tc end ). o n Creo que esto ya est´ cubierto en la versi´n 1.1. a o 9.4.9. ¿C´mo incluir JARs externos? o Tengo una pregunta sobre c´mo desplegar un servicio con un recurso externo de o l´gica de negocios. o Intento que el servicio provea una l´gica de negocio contenida en un archivo jar externo. o Esta l´gica de negocio se usar´ en uno de los componentes SBB. Cualquier modificaci´n o ıa o hecha en las clases incluidas en este archivo jar no deber´ implicar cambios en el ıa despliegue del servicio. He incluido este archivo jar externo en un archivo jar de servicio desplegable. Sin embargo, durante el despliegue en el servidor SLEE, las clases de esta l´gica de negocio o externa no est´n visibles. Obtengo el siguiente error: a Installation of deployable unit failed: javax.slee.management. DeploymentException: Error(s) in deployable unit: Verification error(s) in one or more components in sbb.jar: Verification
- 144. 112 ´ CAP´ ITULO 9. MEJORES PRACTICAS error(s) in sbb component OurService? 1.0, Vendor: Cannot load SBB abstract class class pl.vendor.jain.service.control._Sbb nested exception: java.lang.NoClassDefFoundError: pl/vendor/service/database/DBInterface ¿C´mo puedo hacer las clases del archivo jar externo visibles al servicio? ¿Es posio ble a˜adir estas clases sin descompilar al sbb.jar? n Si quieres referenciar clases de archivos jar externos en tu SBB, necesitas usar el atributo Class-Path del manifiesto jar.En la secci´n 3 de la especificaci´n SLEE 1.0 se o o menciona esto como inclusi´n de clases “por referencia”. o Por ejemplo, digamos que tu jar externo se llama “external.jar”. En el manifiesto jar de tu jar de componente SBB, incluir´ el atributo ıas Class-Path library/external.jar entonces incluir´ el library/external.jar en la unidad desplegable de tu SBB (no en ıas el jar del componente del SBB). Como el classpath es una URL relativa, puedes poner el jar externo en cualquier lugar dentro de tu unidad desplegable, siempre y cuando el atributo Class-Path coincida con la localizaci´n en el jar de la unidad desplegable. o En SLEE 1.1 [8] hemos introducido un nuevo tipo de componente librer´ del ıa, que depender´n el resto de tipos de componente. Los componente librer´ eliminan a ıas el uso del classpath del manifiesto, que no est´ particularmente bien definido y tiene a problemas cuando se usa en un entorno como el SLEE (en particular diferentes unidades desplegables no pueden compartir una librer´ com´n). ıa u
- 145. Cap´ ıtulo 10 Resource Adaptors 10.1. RA Asterisk 10.1.1. Introducci´n o Asterisk es un software que proporciona un servicio de n´mero virtual sobre IP, administrando las llamadas enu trantes de 2 o m´s l´ a ıneas telef´nicas. o El servicio de n´mero virtual (PBX, Private Branch eXu change, en ingl´s), ofrecido generalmente por las empresas e de telecomunicaciones, consiste en agrupar n l´ ıneas telef´nicas en un unico n´mero que o ´ u se proporciona al p´blico y al cual se realizan las llamadas. De esta manera se muestra u 1 solo n´mero telef´nico al exterior. Cuando se recibe una llamada en dicho n´mero u o u se asigna a la primera l´ ınea real disponible, y as´ sucesivamente hasta que se tengan ı asignadas todas las l´ ıneas, momento en el cual el usuario llamante debe esperar a que se desocupe una de esas l´ ıneas. El uso de un software como Asterisk en las empresas evita la conexi´n de todos o los tel´fonos de una empresa por separado a la red de telefon´ evitando las posibles e ıa, mensualidades de las conexiones y el coste de las llamadas internas. Asterisk puede funcionar sobre varios sistemas operativos, como linux, Mac OS X, OpenBSD, .... Proporciona todas las caracter´ ısticas deseables de un servicio de n´mero u virtual, ofreciendo flexibilidad y funcionalidad e incluyendo caracter´ ısticas avanzadas. Soporta m´ltiples protocolos de voz sobre IP (VoIP) y puede interoperar con casi todos u los equipos telef´nicos basados en est´ndares usando hardware de bajo coste. o a 10.1.2. Asterisk RA para Mobicents Para activar el RA de Asterisk: Rellene las propiedades “IP address”(direcci´n IP), “login”usuario) y “password” o (contrase˜a)en el archivo asteriskra.properties. n 113
- 146. 114 CAP´ ITULO 10. RESOURCE ADAPTORS Despliegue el RA usando el ant target “asteriskradeploy” del archivo build.xml del proyecto. Muy parecido al RA de SIP, de hecho. El RA de Asterisk actualmente funciona con la interfaz de gesti´n de Asterisk, o aunque en la planificaci´n est´ el soporte para FastAGI. Despu´s del despliegue y la o a e activaci´n, usa la librer´ Asterisk-Java para crear una conexi´n capaz de gestionar una o ıa o m´quina Asterisk (especificada en el archivo asteriskra.properties). Escuchar´ cualquier a a evento o respuesta originada por Asterisk y las mandar´ al SLEE. La interfaz SBB del a RA consiste solamente de una funci´n, sendAction, que se usa para enviar a la m´quina o a Asterisk una acci´n de gesti´n en un objeto. o o Todos los tipos de acciones de gesti´n implementadas en Asterisk-Java o (en net.sf.asterisk.manager.action) est´n disponibles, lo que permite enviar a astera isk una variedad de comandos, como efectuar llamadas, redireccionarlas, terminarlas, etc. Adem´s, mediante el uso de CommandActions, que encapsulan comandos CLI, a se dispone de una mayor funcionalidad, especialmente en la configuraci´n y el estado o de asterisk; esto incluye varios m´todos para obtener informaci´n de varios aspectos e o (codecs, canales, aplicaciones, mapeados, ...) y tambi´n la habilidad de cambiar algue nas, como a˜adir y eliminar extensiones “al vuelo”. n Estos m´ltiples comandos permiten el desarrollo de un n´mero de servicios simples, u u como la redirecci´n de llamadas, por ejemplo. De todas maneras, en general, no es tan o adecuado para efectuar un control directo de llamadas como lo que estar´ disponible ıa a trav´s de una aplicaci´n de FastAGI normal, y la complejidad de los servicios que e o pueden desarrollarse usando solamente la interfaz de gesti´n es limitada. El principal o uso del RA actual de Asterisk recae en los eventos que recibe, que permiten al servidor de aplicaciones tener una idea clara de lo que Asterisk est´ haciendo por s´ s´lo, y a ı o los servicios y aplicaciones que lo usen para monitorizarlo s´lo deber´ actuar cuando o ıan fuese estrictamente necesario, necesitando poco o ning´n control para la mayor´ de los u ıa procesos de llamada. Un ejemplo de esto ser´ coleccionar datos estad´ ıa ısticos de un servidor asterisk; otro podr´ ser un servicio de cobro que usara los eventos para obtener los datos necesarios ıa (duraci´n, parte llamante, ...) y s´lo interviniera, por ejemplo, para proporcionar un o o mensaje de aviso y terminar la llamada cuando el cr´dito del llamante se acabara, si e fuera un escenario de prepago.
- 148. CAP´ ITULO 10. RESOURCE ADAPTORS 116 10.2. RA MGCP 10.2.1. Introducci´n o Con la continua globalizaci´n, las compa˜´ tienen grupos de trabajo dispersos o nıas alrededor del mundo. Para dar soporte a la productividad y comunicaci´n de los grupos o de trabajo est´n considerando soluciones basadas en redes de bajo coste que combinan a voz, wireless, datos y video. Este negocio pretende que los servicios que seleccionen e implementen tengan la alta calidad de tel´fono y otros servicios que usan ahora, y tame bi´n quieren que aumente la productividad y reduzca los costes de comunicaci´n.PAra e o acceder a los servicios de red deseado necesitan conexiones Wireless1 , Wireline2 , y Internet basada en PSTN3 con una pasarela media flexible, robusta, escalable y efectiva en coste. Estas pasarelas reducen el coste de comunicaci´n entre los grupos de trabajo o dispersos y fundamentan los servicios media. 10.2.1.1. Media gateways bridge multiple technologies Hoy todas las comunicaciones pueden llevarse a cabo a trav´s de un ordenador. e El altamente accesible broadband y el Protocolo Internet (IP) habilitan el uso de voz, datos y video. Las pasarelas Media proveen conversaci´n e inserci´n de voz Media, entre o o una red y su punto de acceso. Las pasarelas Media DSL o cable modem convierten, procesan y empaquetan datos de voz para transferirlos por el backbone de Internet hasta tel´fonos Wireline o Wireless. Las pasarelas media encajan entre el PSTN y e Wireless o redes basadas en IP. 10.2.1.2. Porque pasarelas media modulares para VoIP La demanda de mercado esta llevando a las compa˜´ a converger todos sus servinıas cios Media usando pasarelas Media con VoIP. Las compa˜´ desean esta arquitectura nıas para: Costes iniciales bajos: La inversion es baja porque el hardware usado puede utilizarse para multiples funciones. Costes de desarrollo bajo: Sistemas abiertos hardware y est´ndares software con a aplicaciones es bien definidas, da como resultado bajos costes y APIs que aceleran el desarrollo Manejo de multiples tipos media: Las compa˜´ quieren soluciones VoIP ahora, nıas pero necesitan seleccionar soluciones que manejen video en un futuro cercano. Coste de despliegue y mantenimiento bajo: los sistemas estandarizados y modulares, reducen el tiempo de entrenamiento y mantenimiento mientras mejoran el tiempo de funcionamiento. 1 Redes de comunicaciones sin cable Redes de comunicaciones con cable 3 Public Switched Telephone Network, red con conmutaci´n de circuitos tradicional optimizada para o comunicaciones de voz en tiempo real 2
- 149. 10.2. RA MGCP 117 : Habilita un tiempo de mercado r´pido: La pronta entrada en el mercado da la a oportunidad d e maximizar los ingresos. 10.2.1.3. Pensando en el futuro En el pasado las aplicaciones de red estaban separadas, habitualmente con un coste y propietario por aplicaci´n. Las pasarelas Media proporcionan de una organizaci´n o o horizontal ofreciendo la ventaja de una arquitectura com´n para todas las aplicaciones. u Hoy en d´ las pasarelas media aseguran el trabajo interno de transacciones entre diferıa entes tecnolog´ gracias a la habilitaci´n de servicios para aplicaciones basadas en ıas o media que involucran voz, datos, faxes y video. 10.2.2. Arquitectura La pasarela Media de Mobicents esta formada por tres niveles: capa de procesado media, capa de manejo y capa de control La primera capa es la capa de procesado media: Esta capa es una colecci´n de o endpoints. Cada endpoint es una fuente o un sumidero de datos y puede ser f´ ısico o virtual. Los Endpoint f´ ısicos necesitan instalaci´n de Hardware - tarjetas PSTN por o ejemplo. Cada canal digital de estas tarjetas puede configurarse como un endpoint. Para establecer comunicaci´n entre endpoints o entre endpoints y otra entidad en la o red IP a trav´s de RTP, los endpoint usan conexiones. El procesado media est´ en el e a n´cleo de la conexi´n. Esto es llevado a cabo por Procesadores de Se˜al Digital para u o n proveer de una interfaz de trafico entre Internet y las redes wireless de el PSTN, y para convertir voz Time Domain Media (TDM) en VoIP y viceversa. Este proceso depende del tiempo y el sistema tiene que reunir los paquetes en su secuencia de tiempo. Cuando los paquetes se pierden o llegan tarde, la pasarela media los descarta y los interpola. EL media comprime paquetes de voz, corrige retardos, cancela ecos, y genera tonos. El DSP puede implementarse por hardware o basado en Java Media Framework. La segunda capa es la capa de manejo: Como se menciona arriba, la capa de procesado media es una colecci´n de endpoints. Cada endpoint tiene que ser configurado, o arrancado, monitorizado y parado cuando este esta fuera de servicio. Para conseguir esto se utiliza el API Java Managed Extension. Entonces cada endpoint se implementa como MBean, por lo que cualquier herramienta JMX est´ndar puede usarse para a prop´sitos de manejo. o
- 150. CAP´ ITULO 10. RESOURCE ADAPTORS 118 Figura 10.1: Diagrama de Clases. La tercera capa es la capa de control de protocolo: Las pasarelas media se centran en la tarea de procesado media y normalmente no esta involucrada con el proceso de establecimiento de llamada. La pasarela Media es una entidad pasiva que esta controlada por agentes externos de llamada o controladores de llamada. La pasarela media de Mobicents esta dise˜ada para dar soporte a una gran variedad de protocolos de control. n 10.2.3. Endpoints Asumimos que las pasarelas medias soportan colecciones de endpoints. El tipo de endpoint determina su funcionalidad. Un endpoint tiene que implementar las caracter´ ısticas de procesado media y tiene que ser f´cilmente integrable con JBoss. Como a casi todo en JBoss, el endpoint se maneja com un MBean, y como todos los servicios de Jboss este debe implementar org.jboss.system.ServiceMBean para asegurarse un adecuado manejo del ciclo de vida. Para facilitar la configuraci´n el despliegue de o la pasarela media est´ empaquetada en un servicio MBean de JBoss cuyo descriptor es a META-INF/jboss-service.xml, el cual podemos editar f´cilmente. a Aqu´ mostramos una lista de los tipos de endpoints b´sicos: ı a Canal digital L´ ınea anal´gica o
- 151. 10.2. RA MGCP 119 Punto de acceso a servidor declarado Punto de acceso a respuesta de voz interactiva Punto de acceso a puente de conferencia Transmisi´n de paquetes o Interfaz ATM Esta lista no es final, en el futuro se definir´n mas endpoints, por ejemplo endpoints a de test para probar la calidad de la red, o end points frame-relay que se podr´n usar a para manejar canales de audio multiplexados sobre circuitos virtuales frame-relay. 10.2.4. 10.2.4.1. Configuraci´n o Configuraci´n de entrada o Cada Endpoint tiene sus datos de configuraci´n en el archivo de configuraci´n global o o de la pasarela jboss-service.xml. <server> <mbean code="org.mobicents.media.digium.BChannel" name="org.mobicents:service=ds0/s0/c1"> <attribute name="Configuration"> ... </attribute> </mbean> </sever> Donde la clase org.mobicents.media.digium.BChannel de hecho implementa el acceso para el (B-channel) para la tarjeta Digium PSTN 10.2.4.2. Normas para los nombres Como se especifica en la especificaci´n MGCP la sintaxis del nombre del endpoint o local es jer´rquica. Donde el componente menos especifico del nombre es el termino a mas a la izquierda, y el componente mas especifico es el t´rmino m´s a la derecha. El e a nombre depende del tipo del endpoint nombrado. Los t´rminos individuales del camino e de llamado deben ser separados por una unica barra. Los s´ ´ ımbolos * y $se usan como s´ ımbolos claves para la b´squeda de endpoints. Un asterisco significa ”todo el dollar u significa .alg´n” u 2 10.2.4.3. Conexi´n o Un Endpoint contiene un conjunto de Conexiones. Las Conexiones son usadas para establecer comunicaci´n entre endpoints o entre un endpoint y otra entidad en la red IP o usando RTP. Entonces, cada endpoint tiene procesadores JMF4 los cuales leen/escriben 4 Java Media Framework, librer´ Java que habilita el uso de audio, video y otros tipos de Media ıa basados en el tiempo, para ser a˜adidos en aplicaciones y applets. n
- 152. CAP´ ITULO 10. RESOURCE ADAPTORS 120 datos desde el sumidero de datos de los endpoints y JMFs RTPManager. Si la conexi´n o reside en la misma pasarela estos pueden usar procesadores de stream media de salida como entrada para procesadores de otras conexiones. Por otro lado las conexiones usan RTP para establecer comunicaci´n. o Los endpoints Virtuales no usan ning´n tipo de hardware, usan archivos o otras u conexiones como sumideros de datos, por ejemplo, un endpoint de anuncio usa archivos pre grabados para reproducirlos, y un endpoint conferencia usa streams media como salida de conexiones creadas por el propio endpoint. Las conexiones pueden ser establecidas para recibir datos, transmitir datos o ambos casos. La direcci´n del stream o media se determina por el valor del modo de conexi´n. Cada endpoint debe implemeno tar la conexi´n tomando en cuenta los endpoints espec´ o ıficos. Cada implementaci´n de o conexi´n debe ser derivada de una clase. o Conexi´n base: o public abstract class Connection { .... private String id; private int mode; private String localDescriptor; private String remoteDescriptor; private Connection remoteConnection; } Aqu´ los descriptores local y remoto son usados para especificar nodos para el stream ı RTP usando Session Description Protocol. El localDescriptor representa la conexi´n o con el mismo y el remoteDescriptor representa el nodo remoto. Los atributos remoteDescriptor y remoteConnection son mutuamente exclusivos y determinan el tipo de comunicaci´n (RTP o DataSource). Si ninguno de estos atributos existiera entonces la o conexi´n ser´ abierta. o ıa Cada endpoint tambi´n tiene que anular m´todos usados para el manejo de conexe e iones: public abstract class Endpoint extends ServiceMBeanSupport implements EndpointMBean, MgcpCommandProcessor { .... public abstract Connection createConnection(String callID, int mode) throws TooManyConnections; public abstract Connection getConnection(String connectionID) throws ConnectionNotFound; public abstract void deleteConnection(Connection connection); } 10.2.4.4. Llamada Las conexiones son creadas en cada endpoint involucrado en la llamada. Los identificadores de conexiones son unicos dentro de la llamada. La creaci´n de las conexiones ´ o se hace a trav´s de los siguientes pasos: e
- 153. 10.2. RA MGCP 121 1. El Controlador de Llamada elige el endpoint apropiado y pregunta a la pasarela c ¸rear una conexion”. La pasarela adquiere el endpoint especifico, inicializa los procesadores JMFs, crea el RTPManager y responde al comando proveyendo del descriptor local de la conexi´n especificado por el SDP. o 2. El controlador de llamada pregunta al gateway para adquirir el segundo endpoint y crear una segunda conexi´n. El controlador de llamada incluye el descriptor de o conexi´n de la primera conexi´n en la petici´n. El endpoind provee del descripo o o tor de conexi´n como remoteDescriptor y responde la petici´n proveyendo de su o o propio descriptor de conexi´n. o 3. El Controlador de Llamada modifica la conexi´n para proveer a la primera conexi´n o o del descriptor de conexi´n de la segunda o 10.2.4.5. eventos Un Controlador de llamada puede preguntar para ser notificado sobre ciertos eventos que ocurren en un endpoint o conexi´n (ej. Eventos DTMF) incluyendo el nombre del o evento en un comando.La pasarela usa el modo listener est´ndar de Java para detectar a algunos eventos. Cuando un endpoint recibe el comando que pide una notificaci´n, la nueva instancia o del listener apropiado es creado y a˜adido al endpoint o conexi´n. La clase que represenn o ta el listener b´sico implementa el procedimiento de reparto de eventos al Controlador a de llamada public abstract class BaseListener { .... public BaseListener(Call call) { ... } } Donde la informaci´n sobre el Controlador de llamada esta soportada por un objeto o Call. 10.2.4.6. Protocolo de control Normalmente cada pila de protocolo de control se implementa independientemente. Como se menciona arriba, para enlazar un protocolo de control con el media gateway, la clase base de endpoint deber´ implementar acciones para las especificaciones de los ıan protocolos. Tambi´n, la pila de protocolos deber´ estar envuelta por un objeto JMX e ıa para ser manejada y configurada por el administrador de la pasarela <server> <mbean code="org.mobicents.media.control.MgcpProvider" name="org.mobicents:service=MgcpProvider"> <attribute name="Configuration"> ...
- 154. CAP´ ITULO 10. RESOURCE ADAPTORS 122 </attribute> </mbean> </sever> 10.2.5. El RA El RA est´ adaptado para el protocolo de control MGCP a 10.2.5.1. Identificador de tipo del RA El nombre del RA type es ”JAIN MGCP”. El vendedor es ”java.mgcp”, y la versi´n o la ”1.0” 10.2.5.2. Objetos Activity Los objetos activity para el RA son org.mobicents.slee.resources.mgcp.Call, org.mobicents.slee.resources.mgcp.Connection y org.mobicents.slee.resources.mgcp.Endpoint. El objeto Call pertenece a una llamada manejada por el controlador, el objeto Connection pertenece a la conexi´n creada en el lado de la pasarela y el Endpoint o pertenece al endpoint de la pasarela que ejecuta la conexi´n. o 10.2.5.3. Eventos del RA La siguiente table muestra los eventos emitidos por el RA: Eventos Request Events jain.protocol.ip.mgcp.message.AUDIT ENDPOINT jain.protocol.ip.mgcp.message.AUDIT CONNECTION jain.protocol.ip.mgcp.message.CREATE CONNECTION jain.protocol.ip.mgcp.message.MODIFY CONNECTION jain.protocol.ip.mgcp.message.DELETE CONNECTION jain.protocol.ip.mgcp.message.NOTIFICATION REQUEST jain.protocol.ip.mgcp.message.NOTIFY RESPONSE Response Events jain.protocol.ip.mgcp.message.AUDIT ENDPOINT RESPONSE jain.protocol.ip.mgcp.message.AUDIT CONNECTION RESPONSE jain.protocol.ip.mgcp.message.CREATE CONNECTION RESPONSE jain.protocol.ip.mgcp.message.MODIFY CONNECTION RESPONSE jain.protocol.ip.mgcp.message.DELETE CONNECTION RESPONSE jain.protocol.ip.mgcp.message.NOTIFICATION REQUEST RESPONSE jain.protocol.ip.mgcp.message.NOTIFY Call Connection EndPoint X X X X X X X X X X X X X X X X X X X X X X X X X X X X Tabla 10.2: Eventos MGCP RA 10.2.5.4. Tipos de evento El tipo de evento es un mensaje cuyo nombre tiene como prefijo el package jain.protocol.ip.mgcp.message, el vendedor es jain.mgcp y la versi´n es 1.1 o 10.2.5.5. Clases de eventos JAIN MGCP define una clase de evento para todos los eventos
- 155. 10.2. RA MGCP 10.2.5.6. 123 Activity Context Interface Factory Interface El Activity Context Interface Factory Interface es : import javax.slee.ActivityContextInterface; import javax.slee.FactoryException; importjavax.slee.UnrecognizedActivityException; public interface RadiusActivityContextInterfaceFactory { public ActivityContextInterface getActivityContextInterface(Call) throws NullPointerException, UnrecognizedActivityException, FactoryException; public ActivityContextInterface getActivityContextInterface(Connection) throws NullPointerException, UnrecognizedActivityException, FactoryException; public ActivityContextInterface getActivityContextInterface(Endpoint) throws NullPointerException, UnrecognizedActivityException, FactoryException; } 10.2.5.7. Objeto RA JAIN MGCP require un objeto para crear los mensajes enviados: JainMgcpProvider
- 156. CAP´ ITULO 10. RESOURCE ADAPTORS 124 10.3. RA Parlay 10.3.1. Introducci´n o El Parlay RA permite desplegar aplicaciones Parlay/Parlay-X en contenedores SLEE tales como Mobicents. La mayor ventaja de esto es proveer de un RA para SLEE que permita conexiones de alto rendimiento en redes de telecomunicaci´n a trav´s de servicios Parlay OSA. o e Otro aspecto importante es la estandarizaci´n del modelo de programaci´n para el o o acceso y uso de servicios Parlay en entornos SLEE, gracias a la definici´n de c´mo las o o APIs del servicio Parlay pueden ser mapeadas en la definici´n de tipos del RA SLEE. o Para m´s informaci´n acerca de las APIs y documentaci´n: www.parlay.org: a o o 10.3.2. Consideraciones Para la utilizaci´n del Parlay RA es necesario tener habilitada un o Pasarela Parlay, por el contrario si no disponemos de ella necesitaremos un emulador. Es conveniente hacer todas las pruebas posibles utilizando el emulador. Lista de algunos gateways o emuladores De pago, version trial disponible Libre de Ericsson Gu´ Ericsson ıa Este ultimo puede utilizarse como ejemplo ya que es libre y existe un tema en el foro de java donde se responden a varios errores que ha dado: ForoEricsson 10.3.3. Funcionalidades Entre otras muchas caracter´ ısticas podemos encontrar control de llamadas, conferencias, interacci´n con el usuario (mensajes de texto, imagen y audio), facturaci´n, o o estado del Terminal, localizaci´n del Terminal,etc. o 10.3.4. Como instalar el RA Parlay A continuaci´n mostramos una peque˜a gu´ acerca de como instalar el Parlay RA o n ıa en Mobicents. Tan solo el paso de la configuraci´n del RA es necesario para desplegarlo, o el resto es una peque˜a introducci´n a su desarrollo y a la comprensi´n del mismo. n o o 10.3.4.1. Configuraci´n del RA o Parlay RA se configura usando un archivo java est´ndar del tipo ”.propieties”java a que se encuentra en: $PROJECT_HOME/source/ra/src/java/org/mobicents/slee/resource/
- 157. 10.3. RA PARLAY 125 parlay/ParlayResourceAdapter.properties} 10.3.4.1.1. Acceso a la pasarela . El primer paso es configurar la informaci´n de localizaci´n de la Pasarela. Parlay o o RA soporta los mecanismos de localizaci´n de Pasarela de principales vendedores de o Pasarelas Parlay. Usando el servicio Corba Naming Actualizando la propiedad org.mobicents.slee.resource.parlay.namingServiceIOR con el valor apropiado Actualizando la propiedad org.mobicents.slee.resource.parlay.ipInitialLocation con la posici´n de la pasarela ”IpInitial” en el servicio naming o Usando host and port Actualiza la localizaci´n de org.mobicents.slee.resource.parlay.ipInitialURL con la o direcci´n conocida desde la cual el servicio naming puede encontrarse o Usando IpInitial IOR Actualizando la propiedad org.mobicents.slee.resource.parlay.ipInitialIOR con el valor apropiado. El segundo paso es configurar el RA apropiadamente para la autentificaci´n con el o framework de la Pasarela Parlay. Para hacer esto tiene que especificarse un dominio ID, una secuencia de autentificaci´n y la versi´n de Parlay. Si la versi´n de Parlay es o o o la 4 tiene que especificarse tambi´n un secreto compartido. Ej: e org.mobicents.slee.resource.parlay.domainID=1234 org.mobicents.slee.resource.parlay.authenticationSequence=TWO WAY org.mobicents.slee.resource.parlay.fw.parlayVersion=P PARLAY 3 10.3.4.1.2. Probar la configuraci´n . o Para realizar pruebas es posible configurar el Parlay RA para evitar una Pasarela framework. Esto es util para algunas herramientas de pruebas y puede usarse tambi´n ´ e en situaciones de despliegues donde el framework no se encuentra disponible. Para hacer esto se necesita un segundo archivo de configuraci´n. Un ejemplo se encuentra en: o $PROJECT_HOME/source/conf/ParlayRATest.properties.
- 158. CAP´ ITULO 10. RESOURCE ADAPTORS 126 Poniendo este archive en el la carpeta del servidor app ¸onf” con la propiedad c org.mobicents.slee.resource.parlay.isByPassFwEnabled puesta en true el RA evitara toda interacci´n con el framework y tratar´ de localizar encargados de servicios a trav´s o a e de referencias a ficheros IOR5 . Nota: En este modo el RA soporta acceso solo a trav´s de una instancia simple de e cada tipo SCF 10.3.4.1.3. Configuraci´n del ORB o . Por defecto Parlay RA ha sido configurado para usar JacORB (es un c´digo abierto o de Java implementaci´n del est´ndar Object Management Group’s Corba). Se pueden o a usar tambi´n otros ORBs. La configuraci´n ORB puede ser cargada desde e o $PROJECT_HOME/source/conf/parlayra-orb.properties Debes consultar la informaci´n de tu ORB elegido. o 10.3.4.1.4. Configuraci´n del loggin o . Parlay RA usa el componente apache commons-loggin para toda la informaci´n o de log. Como todo el c´digo esta bajo el nombre org.mobicents.slee.resource.parlay el o loggin puede ser habilitado a˜adi´ndolo como ap´ndiz en tu archivo log4j.xml. n e e 10.3.4.2. Contruyendo e instalando El RA puede construirse e instalarse usando el archivo build.xml en el fuente de mobicents-parlay-ra. Los siguientes pasos detallan el proceso: 1. Carga el c´digo fuente de mobicents-parlay-ra desde el CVS o 2. Aseg´rate que el u $MOBICENTS_HOME ha sido configurado apropiadamente para tu entorno 3. Configura el RA como se ha detallado anteriormente. 4. En el nivel del directorio inicial escribe ant deploy 5. En el caso de que al desplegar el Mobicents de un error debido a que el puerto 4444 esta en uso por otra aplicaci´n, podemos cambiar este puerto por otro en el o archivo de configuraci´n o %JBOSS_HOME%serverport-bindings.xml 5 Interoperable Object Reference, en computaci´n distribuida, es una referencia a un objeto CORBA o o RMI-IIOP.
- 159. 10.3. RA PARLAY 127 Ejecutar y desplegar llevar´n a cabo los siguientes pasos: a 1. Construye y empaqueta todo c´digo y definici´n de tipos del RA o o 2. Copia el RA a la instalaci´n de Mobicents Slee o 3. Copia la ra´ del script desplegable del RA a la instalaci´n de Mobicents Slee ız o El script desplegable de la ra´ llevar´ a cabo los siguientes pasos: ız a 1. Instalar el RA 2. Activar una entidad RA 3. Crear un enlace de entidad para los servicios 10.3.5. Ejemplo Parlay RA: Servicio CallBlocking Este ejemplo se utiliza para aprender a usar el RA Parlay. En las siguientes instrucciones se detalla la instalaci´n de este servicio y provee de un simple tutorial detallando o los elementos clave. 10.3.5.1. Instalando el servicio CallBlocking El servicio CallBlocking se instalara despu´s de instalar el Parlay RA, tal y como se e ha explicado anteriormente. Desde el directorio del repositorio cvs mobicents-parlay-ra ejecuta: cd callblocking ant build-auto-deploy Que har´ lo siguiente: a 1. Construir´ y empaquetara todos los sbb y definici´n de tipos del c´digo Calla o o Blocking 2. Copia la unidad desplegables en la instalaci´n de Mobicents Slee o 3. Copiar el script desplegable beanshell en la instalaci´n de Mobicents Slee o El script desplegable beanshell hace los siguientes pasos: 1. Instala el servicio CallBlocking 2. Activa el servicio CallBlocking 10.3.5.2. Tutorial del servicio CallBlocking de Parlay El ejemplo del servicio Callblocking Parlay esta basado en el servicio de CallBlocking JCC incluido en el manual de referencia de Jain Slee
- 160. CAP´ ITULO 10. RESOURCE ADAPTORS 128 10.3.5.2.1. Visi´n General del servicio o . El servicio CallBlocking interrumpe todas los intentos de llamada originados por un conjunto de direcciones predeterminado. La direcci´n originaria se compara con o un conjunto de direcciones bloqueadas para el n´mero de destino. Si la direcci´n esta u o bloqueada entonces la llamada ser´ terminada por el servicio en otro caso la llamada a continuar´ de modo normal. a El ejemplo de CallBlocking en este tutorial usa Multi-Party Call Control Service (MPCCS) sobre un enlace Parlay para establecer la interrupci´n de llamadas y efectuar o las interacciones entre llamadas. Todas las interacciones en el enlace Parlay se llevan a cabo a trav´s del mobicents-parlay-ra. e El servicio MPCCS de Parlay permite el control de llamadas multi-party a trav´s e de un API independiente de la red, as´ que la llamada fluye y el c´digo usado en este ı o ejemplo puede ser funcionado sobre SIP o INAP 10.3.5.2.2. Visi´n General del Componente . o El servicio CallBlocking contiene los siguientes componentes claves: CallBlocking Sbb Monta la interrupci´n de llamada cuando el servicio comienza. o Maneja todas los eventos de interrupci´n de llamada en tiempo de funcionamiento o Address Profile CMP Contiene una lista de direcciones bloqueadas para unas direcciones especificas Deployment Descriptors Mecanismo standard de Slee para definir los componentes desplegables y su configuraci´n o 10.3.5.2.3. Dise˜ o de servicios . n
- 161. 10.3. RA PARLAY 129 Definici´n de servicios . o El descriptor CallBlocking-service.xml es: Listado 10.1: CallBlocking-service.xml <s e r v i c e −xml> <s e r v i c e> <s e r v i c e −name>P a r l a y C a l l B l o c k i n g</ s e r v i c e −name> <s e r v i c e −vendor>o r g . m o b i c e n t s</ s e r v i c e −vendor> <s e r v i c e −version>1 . 0</ s e r v i c e −version> <r o o t −sbb> <sbb−name>P a r l a y C a l l B l o c k i n g Sbb</ sbb−name> <sbb−vendor>o r g . m o b i c e n t s</ sbb−vendor> <sbb−version>1 . 0</ sbb−version> </ r o o t −sbb> <default−p r i o r i t y>0</ default−p r i o r i t y> <a d d r e s s −p r o f i l e −t a b l e>C a l l B l o c k i n g P r o f i l e s </ a d d r e s s −p r o f i l e −t a b l e> </ s e r v i c e> </ s e r v i c e −xml> Hay dos cosas importantes a comentar acerca de ´l: e El servicio se identifica un´ ıvocamente en el SLEE container por la tupla (servicename, service-vendor, service-version) El SBB raiz tiene que ser referenciado via el identificador un´ ıvoco compuesto por la tupla (sbb-name, sbb-vendor, sbb-version) El archivo descriptor de servicio esta metido en la Unidad Desplegable SLEE con el archivo SBB y el archivo Profile. El archivo CallBlocking-DU.jar que tiene la siguiente estructura: /CallBlocking-service.xml /META-INF/deployable-unit.xml. Este archivo simplemente lista los archivos y servicios SLEE contenidos en el DU. /jar/CallBlocking-sbb.jar. Contiene el CallBlockingSbb y su descripci´n de sero vicios. La estructura del SBB se detallar´ m´s adelante o /jar/CallBlockinga a profile.jar. Definici´n del CallBlocking Sbb o . El CallBlockingSbb esta implementado en la clase CallBlockingSbb.java y se declara a SLEE a trav´s del archivo descriptor sbb-jar.xml. Ambos archivos est´n dentro de un e a archivo CallBlocking-sbb.jar, con la siguiente estructura: /META-INF/sbb-jar.xml - SBB archivo descriptor /org/mobicents/* - clases Java
- 162. CAP´ ITULO 10. RESOURCE ADAPTORS 130 Accediendo al enlace Parlay . El Acceso al enlace Parlay se hace a trav´s del Parlay RA. Tal y como las interfaces e del Parlay RA est´n definidas en la Definici´n de tipos RA, el CallBlockingSbb debe e o declarar un vinculo con el Ra en su archivo descriptor SBB. Esto se realiza a trav´s de: e Listado 10.2: sbb-jar.xml <r e s o u r c e −adaptor−type−b i n d i n g> <r e s o u r c e −adaptor−type−r e f> <r e s o u r c e −adaptor−type−name>p a r l a y</ r e s o u r c e −adaptor−type−name> <r e s o u r c e −adaptor−type−vendor>o r g . m o b i c e n t s </ r e s o u r c e −adaptor−type−vendor> <r e s o u r c e −adaptor−type−version>4 . 2 </ r e s o u r c e −adaptor−type−version> </ r e s o u r c e −adaptor−type−r e f> <a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −name> s l e e / r e s o u r c e s /ParlayRA/ p a r l a y a c i f </ a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −name> <r e s o u r c e −adaptor−e n t i t y −b i n d i n g> <r e s o u r c e −adaptor−o b j e c t −name> s l e e / resources / parlay /4.2/ resourceAdapterSbbInterface </ r e s o u r c e −adaptor−o b j e c t −name> <r e s o u r c e −adaptor−e n t i t y −l i n k> ParlayRA </ r e s o u r c e −adaptor−e n t i t y −l i n k> </ r e s o u r c e −adaptor−e n t i t y −b i n d i n g> </ r e s o u r c e −adaptor−type−b i n d i n g> Consultar las Especificaciones de Slee para mayor informaci´n del establecimiento o de este enlace. El Sbb puede entonces acceder al RA a trav´s de su ´rbol JNDI local en Slee: e a ... try { Context c t x = ( Context ) new I n i t i a l C o n t e x t ( ) . lookup ( " java:comp /env" ) ; resourceAdapterSbbInterface = ( ParlayResourceAdapterSbbInterface ) c t x . lookup (RA JNDI NAME ) ; Configurando la interrupci´n de llamada . o El API de Parlay OSA usa una notificaci´n paterna para informar a las aplicaciones o de eventos originados en la red. Para interrumpir los intentos de llamadas una notificaci´n con el criterio apropiado debe ser creada. La notificaci´n se crear´ usando una o o a
- 163. 10.3. RA PARLAY 131 instancia de MPCCS Service Capability Features (SCF) sobre un enlace Parlay. Para acceder al SCF la aplicaci´n primero debe establecer una conexi´n a trav´s o o e del RA con el SCF. Esto se lleva a cabo usando la conexi´n Parlay RA. o Listado 10.3: Parte de c´digo o connection = resourceAdapterSbbInterface . getParlayConnection ( ) ; TpServiceIdentifier s e r v i c e I d e n t i f i e r = connection . getService ( " P_MULTI_PARTY_CALL_CONTROL " , new P r o p e r t i e s ( ) ) ; IpMultiPartyCallControlManagerConnection callControlManagerConnection = ( IpMultiPartyCallControlManagerConnection ) connection . getIpServiceConnection ( s e r v i c e I d e n t i f i e r ) ; Nota: Aqu´ no se ha definido ninguna propiedad. En un enlace normal las propiedades ı de los servicios pueden ser usadas para distinguir entre diferentes tipos de SCF. Ej. MPCCS-SIP o MPCCS-INAP. Una vez un IpMultiPartyCallControlManagerConnection ha sido establecido puede ser usado para crear una notificaci´n. o i n t assignmentID = c a l l C o n t r o l M a n a g e r C o n n e c t i o n . createNotification ( createControlCallsToNotificationRequest ( ALL E164 RANGE , ALL E164 RANGE ) ) La operaci´n createNotification(createControlCallsToNotificationRequest() es un o m´todo util dentro del Sbb que construye el evento apropiado para la interrupci´n e ´ o de la llamada. Un interruptor de llamada MPCCS consiste en un ´mbito que define a los rangos de direcciones originales y terminales, un conjunto de eventos que define las transiciones en la Llamada Parlay FSM donde las notificaciones deber´ ocurrir y un ıan modo monitor que especifica si la aplicaci´n desea interrumpir la llamada o simpleo mente recibir notificaciones del estado de la llamada. En este ejemplo una interrupci´n se ha creado entre todos los rangos de direcciones o originales o terminales E164. Y el rango de direcciones E164 se define as´ ı: p r i v a t e s t a t i c f i n a l TpAddressRange ALL E164 RANGE = new TpAddressRange ( TpAddressPlan . P ADDRESS PLAN E164 , "*" , "" , "" ) ; Un rango de direcciones SIP puede ser definido f´cilmente por ejemplo: a p r i v a t e s t a t i c f i n a l TpAddressRange ALL SIP RANGE = new TpAddressRange ( TpAddressPlan . P ADDRESS PLAN SIP , "sip:*@*" , "" , "" ) ;
- 164. CAP´ ITULO 10. RESOURCE ADAPTORS 132 El conjunto de eventos es P CALL EVENT ADDRESS COLLECTED como si fuera uno de los eventos pertenecientes a un intento de llamada original. El modo monitor es P CALL MONITOR MODE INTERRUPT como si quisi´ramos e interrumpir y tener el control de la llamada. Queremos establecer la interrupci´n de llamada tan pronto como el servicio empieza o por eso el CallBlockingSbb se adherir´ al ServiceStartedEvent el cual es un evento Slee a est´ndar. Esto es un proceso doble. Primero el descriptor desplegable Sbb tiene que ser a actualizado con la informaci´n apropiada: o Listado 10.4: sbb-jar.xml <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True"> <event−name>S e r v i c e S t a r t e d E v e n t</ event−name> <event−type−r e f> <event−type−name> javax . s l e e . s e r v i c e a c t i v i t y . ServiceStartedEvent </ event−type−name> <event−type−vendor>j a v a x . s l e e</ event−type−vendor> <event−type−version>1 . 0</ event−type−version> </ event−type−r e f> < i n i t i a l −event−s e l e c t v a r i a b l e=" ActivityContext " /> </ e v e n t> Segundo el Sbb debe proveer una implementaci´n concreta de el m´todo onSero e viceStartedEvent(ServiceStartedEvent e): Listado 10.5: sbb.java public void o n S e r v i c e S t a r t e d E v e n t ( S e r v i c e S t a r t e d E v e n t event , ActivityContextInterface aci ) { try { // . . . // o t h e r i n i t can go h e r e // . . . setupCallInterrupt ( ) ; } catch ( NamingException ne ) { t r a c e ( L e v e l .WARNING, ”ERROR: E x c e p t i o n caught p r o c e s s i n g setSbbContext ” , ne ) ; } } Manejando las Interrupciones de Llamada .
- 165. 10.3. RA PARLAY 133 El mecanismo de notificaci´n para manejar las interrupciones de llamada ya se ha o mencionado antes. El Parlay RA map´a estos informes MPCCS al ReportNotificatione Events en Slee. El CallBlockingSbb tiene que adherirse tambi´n a dichos eventos. Otra e vez esto es un proceso doble que requiere adhesi´n de informaci´n en el descriptor o o desplegable SBB, y un manejador de eventos concreto implementado en el SBB C´digo DD: o Listado 10.6: sbb-jar.xml parlay <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True"> <event−name>R e p o r t N o t i f i c a t i o n E v e n t</ event−name> <event−type−r e f> <event−type−name> o r g . m o bic e nt s . c s a p i . j r . s l e e . c c . mpccs . R e p o r t N o t i f i c a t i o n E v e n t </ event−type−name> <event−type−vendor>o r g . m o b i c e n t s</ event−type−vendor> <event−type−version>4 . 2</ event−type−version> </ event−type−r e f> < i n i t i a l −event−s e l e c t v a r i a b l e=" ActivityContext " /> </ e v e n t> C´digo Sbb: o Listado 10.7: sbb.java parlay 1 public void o n R e p o r t N o t i f i c a t i o n E v e n t ( R e p o r t N o t i f i c a t i o n E v e n t event , ActivityContextInterface aci ) { // . . . e v e n t h a n d l e r code } El ReportNotificationEvent encapsula toda la informaci´n que un SBB necesita o para interactuar con la Llamada Parlay. El dato puede finalizar as´ ı: Identificador de Servicios Identificadores a nivel de la aplicaci´n Parlay que identifica la instancia de servicio o especifico, el evento originado desde, la interrupci´n de llamada ocurrida en alguna o etapa dentro de la llamada. Estos identificadores representan una Actividad en el RA y pueden usarse para establecer conexiones para la actividad de interacci´n de servicios. o Informaci´n del evento de Llamada o Detalla la informaci´n de llamada incluyendo las direcciones origen y destino, y o el estado actual de la llamada. Estos tipos son id´nticos a los de las especificaciones e Parlay.
- 166. 134 CAP´ ITULO 10. RESOURCE ADAPTORS El servicio CallBlocking requiere la direcci´n origen, la direcci´n destino y un ideno o tificador de llamada para funcionar. Cuando recibe una notificaci´n de evento el SBB o trata de establecer una conexi´n con la llamada usando el identificador de servicio y el o identificador de llamada. Estos identificadores conjuntamente identifican un´ ıvocamente la Actividad de llamada en el RA. Listado 10.8: sbb.java parlay 2 try { // Get a c a l l c o n n e c t i o n callConnection = getIpMultiPartyCallConnection ( event . g e t S e r v i c e ( ) , event . getCallReference ( ) ) ; Si la conexi´n se establece entonces se obtiene la llamada original y la direcci´n de o o destino Listado 10.9: sbb.java parlay 3 try { // Obtener e l o r i g e n y d e s t i n o de llamada d e s d e e l e v e n t o TpAddress o r i g i n a t i n g A d d r e s s = event . g e t N o t i f i c a t i o n I n f o ( ) . CallNotificationReportScope . OriginatingAddress ; TpAddress d e s t i n a t i o n A d d r e s s = event . g e t N o t i f i c a t i o n I n f o ( ) . CallNotificationReportScope . DestinationAddress ; La direcci´n originaria se compara entonces con la lista bloqueada para la direcci´n o o destino usando el AdressProfileCMP. Se accede al profile usando el Slee ProfileFacility Listado 10.10: sbb.java parlay 4 try { // Enc ontrar e l p r o f i l e de l a d i r e c c i ´ n para l a d i r e c c i ´ n d e s t i n o o o ProfileID id = p r o f i l e F a c i l i t y . getProfileByIndexedAttribute ( ” C a l l B l o c k i n g P r o f i l e s ” , ” a d d r e s s e s ” , new Address ( AddressPlan . E164 , d e s t i n a t i o n A d d r e s s . AddrString ) ) ; CallBlockingAddressProfileCMP p r o f i l e = g e t P r o f i l e ( id ) ; Este c´digo accede al profile CallBlockingPrifiles en Slee. Buscar en la especificaci´n o o Slee para mas informaci´n acerca de c´mo establecer Profiles para SBBs. o o Dependiendo si la direcci´n se encuentra en la tabla profile la llamada puede tero minar o continuar. Terminar una llamada en MPCCS se efect´a usando el m´todo u e release(). Alternativamente la operaci´n deassingCall() renuncia al control del servicio o SBB de la llamada que impl´ ıcitamente le permite continuar en la red
- 167. 10.3. RA PARLAY 135 Listado 10.11: sbb.java parlay 5 i f ( isBlocked ) { // b l o q u e a l a llamada // F i n a l i z a l a llamada en l a r e d y en l a p a s a r e l a // P a r l a y c a l l C o n n e c t i o n . r e l e a s e ( TpReleaseCause . P USER NOT AVAILABLE ) ; } else { // d e a s s i n g c o n t i n u a i m p l i c i t a m e n t e l a llamada y l a f i n a l i z a // en l a p a s a r e l a P a r l a y callConnection . deassignCall ( ) ; }
- 168. CAP´ ITULO 10. RESOURCE ADAPTORS 136 10.4. RA Persistence 10.4.1. Java Persistence API El API Java Persistence[30] o JPA, es un framework de Java que permite a los desarrolladores administrar datos relacionales. Provee un modelo de persistencia POJO6 para mapeo de objetos relacionales, El API Java Persistence fue desarrollado por el grupo experto de software EJB 3.0 como parte de JSR 220, pero su uso no est´ limitado a a componentes software EJB. Puede ser usado tambi´n directamente por aplicaciones e normales como web, e incluso fuera de la plataforma Java EE, por ejemplo, en aplicaciones Java SE. El API Java Persistence consiste en tres ´reas: a El API, definido en el paquete javax.persistence El Lenguaje de consulta Java Persistence (JPQL7 ) metadatos objeto/relacional 10.4.1.1. Entidades Una entidad Persitence es una clase Java ligera que normalmente representa una tabla en una base de datos relacional. Las Instancias entidad corresponde a una fila individual de la tabla. Las entidades normalmente tienen relaci´n con otras entidades, y o estas relaciones son expresadas a trav´s de metadatos objeto/relacional. Los metadatos e objeto/relacional pueden ser especificados directamente en el fichero de la clase entidad usando anotaciones o en un fichero descriptor XML distribuido con la aplicaci´n. o 10.4.1.2. El lenguaje de consulta Java Persistence The Java Persistence Query Language es usado para hacer consultas de las entidades almacenadas en una base de datos relacional. Las consultas se parecen a la sintaxis de las consultas SQL, pero operan con objetos entidad en vez de directamente con tablas de la base de datos. 10.4.2. Dise˜ o del Ra Persistence n JPA es adecuado para el RA, pues es una API O/R mapping rico y altamente efectivo. El RA no tiene necesariamente que seguir un modelo dirigido a eventos. Ser´ ıa recomendable una interfaz s´ ıncrona lo m´s cerca posible al uso de JPA. Hay otros a formas para las aplicaciones para desacoplar la l´gica de la persistencia en componentes o as´ ıncronos separada que usen un RA Persistence as´ ıncrono. 6 Plain Old Java Object, es una clase del lenguaje de programaci´n Java. Este nombre se les da a o las clases que no son de alg´n tipo especial (EJBs, Java Beans, etc) y no cumplen ning´n otro rol ni u u implementan alguna interfaz especial. 7 Java Persistence Query Language
- 169. 10.4. RA PERSISTENCE 137 Figura 10.2: Persistence Figura 10.3: Persistence RA SBB Interface Figura 10.4: Persitence RA Entity Manager
- 170. 138 CAP´ ITULO 10. RESOURCE ADAPTORS Figura 10.5: persistence.xml Figura 10.6: persistence-ra-ds.xml
- 171. 10.4. RA PERSISTENCE 139 Como no hay proporcionada ninguna informaci´n sobre latencia en los m´todos o e 8 de invocaci´n, la elecci´n m´s sensata es ejecutar todos estos m´todos as´ ORM o o a e ıncronamente a la funcionalidad del n´cleo SLEE, y por lo tanto la principal ventaja del u RA, para realizar operaciones costosas fuera del n´cleo. Por eso tenemos dos clases u XExecutor en el RA. 10.4.2.1. Descripci´n de la Clase o QueryExecutor - Ejecuta consultas as´ ıncronamente a trav´s de Objetos Query e devueltos por la clase EM para un particular unidad persistencia - lanza resultados de vuelta a SLEE como eventos. PersistenceExecutor - Ejecuta as´ ıncronamente todos los m´todos EM y devuelve e los resultados como eventos lanzados a SLEE. Query interface - Interfaz que es implementada por objetos proxying requests para el objeto Query subyacente, su tarea es prepara el objeto query subyacente para ejecuciones y programar la ejecuci´n en el RA. o PersistenceRAEntityManager - Tiene la misma funci´n que un proxy Query pero o hace esto para instancias EM para una unidad particular persistencia. 10.4.2.2. Eventos Eventos Descripci´n o EntityManagerStarted EntityManagerStopped PersistentStateEvent Determina la separaci´n de los objetos. o Determina la separaci´n de los objetos. o Lanzado cuando alguna operaci´n es realizada en o entidades, como unir, actualizar, continuar y encontrar Lanzado cuando una consulta devuelve un resultado. QueryResultEvent Tabla 10.3: Eventos RA Persistence 10.4.2.3. Actividades Una actividad nula por cada EM alguna vez activado Una actividad nula por cada event type lanzado a favor de un EM - Estado, Consulta, EM Types 8 Object-relational mapping, Es una t´cnica de programaci´n para convertir datos entre tipos de e o sistemas incompatibles en bases de datos y lenguajes de programaci´n orientados a objetos. o
- 172. CAP´ ITULO 10. RESOURCE ADAPTORS 140 10.5. RA SIP 10.5.1. Introducci´n o Mobicents SIP RA es un subproyecto de Mobicents con el objetivo de crear una extensi´n SLEE de alto rendimiento para el protocolo SIP. La p´gina del proyecto es: o a https://sip-ra.dev.java.net La especificaci´n inicial del SIP RA ha sido propuesta por JSR 22 (JAIN SLEE o 1.0), donde el nombre modelo de adaptador de recursos es “JAIN SIP“. El vendedor del adaptador de recursos es “javax.sip“. La versi´n del modelo de adaptador de recursos o es la “1.1“. Mobicents provee una implementaci´n completa de esta especificaci´n. o o Actualmente hay una comunidad de trabajo activa hacia la pr´xima versi´n del SIP RA, o o que incluir´ muchas mejoras para permitir desarrollo m´s conveniente a los servicios a a SIP para un rango de aplicaciones. El nombre del modelo de adaptador de recursos es “JSIP v1.2“; El vendedor del adaptador de recursos es “net.java.slee.sip“. La versi´n o del modelo de adaptador de recursos es la “1.2“. 10.5.2. 10.5.2.1. JAIN SIP Introducci´n o 10.5.2.1.1. Session Initiation Protocol Session Initiation Protocol (SIP) es un protocolo de se˜ales para crear, modificar y destruir di´logos entre multiples endpoints: n a protocolo Request/Response (como HTTP, pero peer-peer) Sencillo y extensible Dise˜ado para movilidad (proxy/servidores redirect) n Autentificaci´n bidireccional o Capacidad de negociaci´n o SIP es utilizado para controlar las se˜ales que permiten manipular las sesiones como: n Sesiones de mensajer´ instant´nea ıa a Llamadas telef´nicas sobre internet o Servidores de juegos Localizaci´n de recursos o 10.5.2.1.2. Funcionalidad SIP SIP soporta cinco facetas para el establecimiento y la terminaci´n de comunicaciones multimedia, estas incluyen: o User location: determinaci´n del sistema final para ser usado para la comunio caci´n. o User capabilities: determinaci´n de los medios y sus par´metros para ser usado. o a
- 173. 10.5. RA SIP 141 User availability: determinaci´n de la disposici´n del llamante para activar las o o comunicaciones. Call setup: “ringing”, establecimiento de los par´metros de la llamada del llaa mante y del receptor. Call handling: Incluye la transmisi´n y terminaci´n de las llamadas. o o 10.5.2.2. ¿Porqu´ crear JAIN SIP? e SIP es una especificaci´n IETF9 que ha sido adoptada por la industria de la comuo nicaci´n en el sistema 3GPP, 3GPP2, OMA10 e ITU11 . o La especifaci´n IETF define el protocolo SIP en formato de texto. o La comunidad SIP tiene varios eventos interoperables para asegurar la credibilidad del protocolo. Como desarrollador, eres libre para implementar el protocolo en cualquier lenguaje, de ah´ definir tu propia interfaz para acceder al comportamiento del protocolo como ı est´ establecido en el est´ndar IETF. a a Mientras la especificaci´n IETF asegure la interoperabilidad entre stacks, no direco ciona interoperabilidad de aplicaciones a trav´s de stacks. e JAIN SIP satisface esta necesidad en el lenguaje de programaci´n Java. Este aseo gura verdadera interoperabilidad en la que utilizando la especificaci´n JAIN SIP tienes o interoperabilidad entre stacks y la interoperabilidad de las aplicaciones a trav´s de e stacks, frecuentemente referidas como portabilidad de aplicaci´n. o - La interoperabilidad de stack y la portabilidad de la aplicaci´n son requeridas en esta o nueva era de est´ndares de comunicaci´n. a o 10.5.2.3. Introducci´n a JAIN SIP o La interfaz estandarizada java a una pila de se˜ales SIP: n - Estandariza la interfaz a la pila. - Estandariza la interfaz de los mensajes. - Estandariza los eventos y su sem´ntica. a - Portabilidad de la aplicaci´n - verificado por el TCK. o Dise˜ado para desarrolladores que necesitan acceso total al protocolo SIP. n JAIN SIP puede ser utilizado como cliente (user agent), proxy, registrar o empotrado a un contenedor de servicios. 9 Internet Engineering Task Force. Es una organizaci´n internacional abierta de normalizaci´n, que o o tiene como objetivo el contribuir a la ingenier´ de Internet. ıa 10 Open Mobile Alliance. Es una organizaci´n de est´ndares que desarrolla est´ndares abiertos para o a a la industria de los tel´fonos m´viles e o 11 International Telecommunication Union. Es una organizaci´n internacional establecida para eso tandarizar y regular radio y telecomunicaciones internacionales.
- 174. CAP´ ITULO 10. RESOURCE ADAPTORS 142 JAIN SIP v1.0 RFC 2543[32] Soportado. J2SE 1.3 o superior. Transacciones referenciadas por long. El estado de la transacci´n no es o visible a la aplicaci´n. o No tiene soporte de di´logo a expl´ ıcito. La configuraci´n de la pila no est´ o a definida. JAIN SIP v1.1 RFC 3261[34] Soportado. J2SE 1.4 o superior. Interfaces de las transacciones definidas. El estado de la transacci´n/di´logo puede o a ser le´ por la aplicaci´n. ıdo o La Interfaz del di´logo definida y a manejada por la pila. La pila est´ configurada con propiedades a definidas ´ Tabla 10.4: Ultimas actualizaciones de la especificaci´n o 10.5.2.3.1. Funcionalidad JAIN SIP JAIN SIP soporta la funcionalidad del protocolo SIP descrita en RFC 3261 [34]. JAIN SIP tiene las siguientes extensiones SIP; - RFC12 2976 [33] permite al transportador de sesiones relacionar el control de informaci´n que es generado durante la sesi´n. o o - RFC 3262 [35] proporciona informaci´n del progreso del proceso de la petici´n. o o - RFC 3265 [37] la habilidad de responder notificaciones as´ ıncronas de eventos. - RFC 3311 [38] permite al que llama o es llamado para proporcionar informaci´n de o la sesi´n actualizada antes de una respuesta final. o - RFC 3326 [39] la habilidad para saber porqu´ una petici´n SIP fue expedida. e o - RFC 3428 [40] permite transferir mensajes instant´neos. a - RFC 3515 [41] solicita que el recipiente se refiera a un recurso dado en la petici´n. o Interfaz SipStack Administra puntos de escucha y proveedores. SipStack asociado con la direcci´n IP. o - Puede tener m´ltiples puntos de escucha. u La aplicaci´n puede tener multiples SipStacks. o No puede ser borrado una vez creado. 12 Request for Comments. Es un documento cuyo contenido es una propuesta oficial para un nuevo protocolo de la red Internet, que se explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambig¨edades. u
- 175. 10.5. RA SIP 143 Figura 10.7: Arquitectura de Objetos. Instanciado por el SipFactory e inicializado por un property set. ‘javax.sip.*’ las propiedades son reservadas y los nombres definidos por el stack configuration properties. Define la configuraci´n de la retransmisi´n. o o Define la informaci´n del router. o Retransmisiones JAIN SIP provee una funci´n conveniente que asegure que todas las retransmio siones son manejadas por la implementaci´n JAIN SIP. o - Reduce la complejidad para aplicaciones que act´en como clientes. u - Reduce la complejidad para integrar JAIN SIP como una implementaci´n b´sica o a para un Contenedor de Servlets SIP o una implementaci´n JAIN SLEE. o Configura mediante las propiedades JAVA en la interfaz SipStack. - Est´ desactivado por defecto a El manejador por defecto de las retransmisiones de mensajes en JAIN SIP es independiente de la aplicaci´n. o
- 176. CAP´ ITULO 10. RESOURCE ADAPTORS 144 - Aplicaciones proxy Stateful no necesitan saber nada de las retransmisiones ya que son manejadas por JAIN SIP. - Un aplicaci´n cliente corriente debe manejas las retransmisiones de ACKs y o Respuestas 2xx. (200 OK y 202 accepted) Propiedades de la pila IP ADDRESS - Fija la direcci´n IP del SipStack. Esta propiedad es obligatoria. o STACK NAME - Fija un nombre de usuario f´cil para identificar la implementaci´n stack subya o acente. Esta propiedad es obligatoria. OUTBOUND PROXY - Fija el proxy outbound de la pila SIP. ROUTER PATH - Fija el adecuado classpath completo a la aplicaci´n suministada Router de o objetos que determina c´mo enviar mensajes antes de que se establezca un o di´logo. a EXTENSION METHODS - Este valor de configuraci´n informa de la subyacente implementaci´n de los o o m´todos de extensi´n soportados que crean nuevos di´logos. e o a RETRANSMISSION FILTER - Una funci´n que ayuda a Clientes que habiliten la pila para manejar la retranso misi´n de peticiones ACK, respuestas 1XX y 2XX para solicitar (INVITE) o transacciones para la aplicaci´n. o Interfaz SipProvider Registra un SipListener al SipProvider. - Notifica los eventos al Listener registrado. Des-registra a SipListener del SipProvider. - Una vez des-registrado, no recibir´ m´s eventos del SipProvider. a a Cliente y Servidor tienen m´todos de creaci´n de transacciones. e o - Para enviar mensajes Request y Response statefully. M´todo de creaci´n CallIdHeader. e o
- 177. 10.5. RA SIP 145 Env´ Requests y Responses statelessly. ıa M´todos de manipulaci´n Listening Point. e o - Solo un provider por cada punto de escucha. Responsabilidades de Jain SIP Proveer m´todos para dar formato a los mensajes SIP. e Dar la habilidad a una aplicaci´n para enviar y recibir mensajes SIPo Comprobar el formato de los mensajes entrantes y habilitar a la aplicaci´n de o acceso a los campos mediante una interfaz Java estandarizada. Invocar aplicaciones handler apropiadas cuando el protocolo lo requiera. - Llegadas de mensajes y transacciones que hayan excedido el tiempo de espera. Proveer soporte a la transacci´n y manejo del estado de la transacci´n y tiempo o o de vida on behalf de una aplicaci´n del usuario. o Proveer soporte al di´logo y manejo del estado del di´logo y tiempo de vida on a a behalf de una aplicaci´n del usuario. o Interfaz del SIP Listener Un solo SipListener por cada SipStack que implica un solo Listener en la arquitectura - Todos los SipProviders asociados al SipStack tienen el mismo SipListener. El proceso de Peticiones (Request) son con estado o sin estado dependiendo de la l´gica de la aplicaci´n. o o El proceso de Respuestas (Response) tienen el estado de la respuesta (Request) m´s reciente. a El proceso de transacci´n tiene un tiempo de espera y transmite eventos de tiemo po. - Las transacciones procesan notificaciones. Responsabilidades de la aplicaci´n La aplicaci´n se registra en una impleo o mentaci´n de la interfaz SipListener para interactuar con la pila SIP. o La aplicaci´n debe registrarse con el SipProvider para todos los messaging capabilo ities con la pila. - Las peticiones de transacciones de la aplicaci´n para mensajes con estado. o - La aplicaci´n envia mensajes sin estado. o - Acceso a objetos stack. La aplicaci´n recibe mensajes de la pila como eventos mediante la interfaz del o SipListener.
- 178. CAP´ ITULO 10. RESOURCE ADAPTORS 146 Figura 10.8: Arquitectura de mensajeria. Modelo de evento La arquitectura est´ desarrollada en el entorno J2SE por lo a tanto est´ basado en eventos utilizando el modelo de eventos Listener/Provider. a - Hay una referencia directa entre el proveedor de eventos y el consumidor de eventos - El consumidor de eventos debe registrarse al proveedor de eventos. Los eventos encapsulan Requests y Responses entrantes. El modelo de evento es de un s´lo camino. Por ejemplo: la aplicaci´n no env´ o o ıa eventos, env´ mensajes. ıa El modelo de evento es as´ ıncrono usando identificadores transaccionales para mensajes correlacionados. El SipListener representa el consumidor de eventos y escucha eventos entrantes que encapsulan los mensajes que pueden ser respuestas a un di´logo iniciado o nuevos a di´logos entrantes. a El SipProvider es el proveedor de eventos que recibe mensajes de la red y los pasa a la aplicaci´n como eventos. o Paquetes Paquete General. - Define la arquitectura de las interfaces, la interfaz de la transacci´n y di´logo o a y los objetos evento de la especificaci´n. o Paquete de Address
- 179. 10.5. RA SIP 147 - El paquete de direcci´n contiene un envoltorio URI13 gen´rico y define el URI o e SIP y las interfaces URIs Tel. Paquete Message - Define las interfaces necesarias para los mensajes Request y Response. Paquete Header - El paquete Header define las interfaces de todas las cabeceras soportadas y su extensi´n. o 10.5.2.3.2. Factorias JAIN SIP define cuatro diferentes Factories para sus respectivas responsabilidades, a saber: SipFactory. - Esta interfaz define m´todos para crear nuevos objetos Stack y otros objetos e factory. AddressFactory - Esta interfaz define m´todos para crear SipURIs y TelURLs e HeaderFactory - Esta interfaz define m´todos para crear nuevos objetos Header. e MessageFactory - Esta interfaz define m´todos para crear nuevos objetos Request y Response. e 10.5.2.4. Messages y Headers 10.5.2.4.1. Messages Hay dos tipos de mensajes en SIP, que JAIN SIP define como Inferfaces: - Mensajes Request: son enviados del cliente al servidor. Estos contienen m´todos tipados espec´ e ıficos que identifican el tipo de Request. Un Request-URI que indica al usuario o servicio a quien est´ dirigido la a petici´n. o - Mensajes Response: son enviados del servidor al cliente en respuesta a un mensaje Request. Estos contienen un codigo de estado espec´ ıfico que define el tipo de Respuesta. 13 Uniform Resource Identifier, identificador uniforme de recursos. Es una cadena corta de caracteres que identifica un´ ıvocamente un recurso
- 180. CAP´ ITULO 10. RESOURCE ADAPTORS 148 Un Request-URI que indica al usuario o servicio a quien est´ dirigido la a petici´n. o Una frase razonable que est´ destinada al usuario humano. a Los Mensajes podr´ contener multiples Headers del mismo tipo. ıan - Los Headers de un tipo dado junto a un mensaje es significativo. Por ejemplo. Headers que son hop-by-hop deben aparecer antes que ning´n otro Header que sea endu to-end. El cuerpo del mensaje pondr´ la descripci´n de la sesi´n. ıa o o - JAIN SIP define este formato en un objeto que permite al cuerpo ser un String o un objeto tipado defino por la especificaci´n JSR14 del Protocolo de Descripci´n de o o la Sesi´n (SDP)15 y tambi´n un byte array. o e Tipos de mensajes de peticiones INVITE - Permite invitar un usuario o servicio para participar en una sesi´n o para modo ificar par´metros en una sesi´n ya existente. a o BYE - Termina la participaci´n de un cliente en una sesi´n. Confirma el establecimieno o to de una sesi´n. o CANCEL - Termina una transacci´n. o OPTIONS - Solicita informaci´n a un participante sobre sus capacidades media. o ACK16 - Por seguridad y aceptaci´n de la llamada (negociaci´n en tres pasos) o o REGISTER - Informa a un servidor SIP sobre la localizaci´n del User Agent. o INFO 14 Java Specification Request. Son documentos oficiales que describn especificaciones y tecnolog´ ıas propuestas para ser a˜adidas a la plataforma Java. n 15 Session Description Protocol. Es un formato para describir los pr´metros de la inicializaci´n del a o streaming media. Fu´ publicado por el IETF como RFC 4566[45] e 16 Acknowledge. Reconocimiento
- 181. 10.5. RA SIP 149 - Informaci´n de control relacionada con la sesi´n generada durante una sesi´n o o o factory. PRACK17 - Por seguridad de respuestas provisionales. UPDATE[38] - Actualiza una sesi´n sin impactar en el estado del di´logo. o a SUBSCRIBE[37] - Notificaci´n request de un nodo cuando ocurren ciertos eventos. o NOTIFY[37] - Notificaci´n de un nodo remoto cuando ocurren ciertos eventos. o MESSAGE - Para enviar mensajes instant´neos. a REFER[41] - Remite a un recurso provisto en la petici´n. o Ejemplo real de mensaje del m´todo REGISTER: e Via: SIP/2.0/UDP 192.168.0.100:5060;rport; branch=z9hG4bK646464100000000b43c52d6c00000d1200000f03 Content-Length: 0 Contact: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 36 REGISTER From:<sip:[email protected]>;tag=910033437093 Max-Forwards: 70 To: <sip:[email protected]> User-Agent: SJphone/1.60.289a (SJ Labs) Authorization: Digest username="20000",realm="192.168.0.101", nonce="43c52e9d29317c0bf1f885b9aaff1522d93c7692", uri="192.168.0.101", response="f69463b8d3efdb87c388efa9be1a1e63" Responses Respuestas cliente/servidor a las peticiones (C´digos de estado) o 1xx: Tipo Informativo. - 100 Trying (Indica intentando la llamada) - 180 Ringing (Indica que suena el UA que se llama) - 181 Call is being forwarded (Indica que la llamada es desviada) - 182 Queued (LLamada encolada) 17 Provisional acknowledgement. Reconocimiento provisional
- 182. CAP´ ITULO 10. RESOURCE ADAPTORS 150 - 183 Session progress (Indica el progreso de una sesi´n SIP) o 2xx: Tipo Afirmativo. - 200 OK - 202 Accepted 3xx: Indicaci´n de Traslado. o - 300 Multiple choices - 301 Moved permanently (Indica que el UA/Server ha sido movido permanentemente a otra direcci´n) o - 302 Moved temporarily (Movido temporalmente) - 305 Use proxy (Necesario usar proxy) - 380 Alternative service 4xx: Indicaci´n de Fallo : De autenticaci´n, no existencia del usuario. o o - 400 Bad request (Petici´n err´nea) o o - 401 Unauthorized (Petici´n sin autorizar) o - 402 Payment required (Necesario pago de la llamada) - 403 Forbidden (Petici´n no permitida , a n´meros no permitidos etc...) o u - 404 Not found (NO se encuentra el UA llamado) - 405 Method not allowed - 406 Not acceptable - 407 Proxy authentication required (Necesiario autenticar el INVITE ) - 408 Request time-out - 409 Conflict - 410 Gone - 411 Length required - 413 Request entity too - 414 Request-URI too large - 415 Unsupported media type - 420 Bad extension - 480 Temporarily not available - 481 Call leg/transaction does not exist - 482 Loop detected - 483 Too many hops - 484 Address incomplete - 485 Ambiguous - 486 Busy here
- 183. 10.5. RA SIP - 487 Request cancelled - 488 Not acceptable here 5xx: Indicaci´n de errores en el servidor. o - 500 Internal server error - 501 Not implemented - 502 Bad gateway - 503 Service unavailable - 504 Gateway time-out - 505 SIP version not supported 6xx: Fallos globales. - 600 Busy everywhere - 603 Decline - 604 Does not exist anywhere - 606 Not acceptable 151
- 184. CAP´ ITULO 10. RESOURCE ADAPTORS 152 Figura 10.9: Esquema de una llamada SIP. Ejemplo de un c´digo de respuesta. o Internet Protocol, Src Addr: 192.168.0.101 (192.168.0.101), Dst Addr: 192.168.0.100 (192.168.0.100) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 Resent Packet: False Via: SIP/2.0/UDP 192.168.0.100:5060; rport;branch=z9hG4bK646464100000000b43c52d6c00000d1200000f03 Content-Length: 0 Contact: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 36 REGISTER From: <sip:[email protected]>;tag=910033437093 Max-Forwards: 70 To: <sip:[email protected]:5060> Authorization: Digest username="20100", realm="192.168.0.101", nonce="43c52e9d29317c0bf1f885b9aaff1522d93c7692", uri="sip:192.168.0.101",
- 185. 10.5. RA SIP 153 response="f69463b8d3efdb87c388efa9be1a1e63" 10.5.2.4.2. Headers Las cabeceras se utilizan para transportar informaci´n neceo saria a las entidades SIP. Las cabeceras SIP son similares a las los campos de cabecera de HTTP o SMTP en su sintaxis y sem´ntica. a JAIN SIP modela cada cabecera SIP como una interfaz espec´ ıfica de manera opuesta a tener un sola interfaz gen´rica para manejar toda la informaci´n de la cabecera. e o - Cada interfaz especifica los par´metros admisibles por la cabecera. a - Soporte de protocolo m´s expl´ a ıcito - Analizando el soporte de cada cabecera. JAIN SIP soporta todas las cabeceras definidas en RFC 3261[34] y otras cabeceras introducidas por el soporte de los siguientes RFCs adicionales: - RFC 3262[35] - RAckHeader y RSeqHeaders para la entrega de confianza de respuestas provisionales. - RFC 3265[37] - AllowEventsHeader, EventHeader y SubscriptionStateHeader para soportar el framework de notificaci´n de eventos. o - RFC 3326[39] - ReasonHeader para apoyarse la informaci´n en porqu´ la petici´n fue o e o emitida. - RFC 3515[41] - ReferToHeader para soportar recipientes que remiten peticiones a otro recurso. - Via: Indica el transporte usado para el env´ e identifica la ruta del request, por ello ıo cada proxy a˜ade una l´ n ınea a este campo. - From: Indica la direcci´n del origen de la petici´n. o o - To: Indica la direcci´n del destinatario de la petici´n. o o - Call-Id: Identificador unico para cada llamada y contiene la direcci´n del host. Debe ´ o ser igual para todos los mensajes dentro de una transacci´n. o - Cseq: Se inicia con un n´mero aleatorio e identifica de forma secuencial cada petici´n. u o - Contact : Contiene una (o m´s) direcci´n que pueden ser usada para contactar con a o el usuario. - User Agent: Contiene el cliente agente que realiza la comunicaci´n. o Message Header Via: SIP/2.0/UDP 192.168.0.100:5060;rport; branch=z9hG4bK646464100000007343c52679000020a600000e45 Content-Length: 0 Call-ID: [email protected] CSeq: 1 ACK From: "Prueba"<sip:[email protected]>;
- 186. 154 CAP´ ITULO 10. RESOURCE ADAPTORS tag=8922404614682 Max-Forwards: 70 Route: <sip:[email protected]> To: <sip:[email protected]>;tag=as0a27b928 User-Agent: SJphone/1.60.289a (SJ Labs) Contact: <sip:[email protected]:5060>;expires=3600 10.5.2.4.3. Addressing Una de las funciones de los servidores SIP es la localizaci´n de los usuarios y resoluci´n de nombres. Normalmente, el agente de usuario no o o conoce la direcci´n IP del destinatario de la llamada, sino su e-mail. o Las entidades SIP identifican a un usuario con las SIP URI (Uniform Resource Identifiers) definido en el RFC 2396[31]. Una SIP URI tiene un formato similar al del e-mail, consta de un usuario y un dominio delimitado por una @, como muestran los siguientes casos: usuario@dominio, donde dominio es un nombre de dominio completo. usuario@equipo, donde equipo es el nombre de la m´quina. a usuario@direcci´n ip, donde direcci´n ip es la direcci´n IP del dispositivo. o o o n´mero tel´fono@gateway, donde el gateway permite acceder al n´mero de tel´fono u e u e a trav´s de la red telef´nica p´blica. e o u La soluci´n de identificaci´n de SIP, tambi´n puede ser basada en el DNS descrito en o o e el RFC 3263[36], donde se describen los procedimientos DNS utilizados por los clientes para traducir una SIP URI en una direcci´n IP, puerta y protocolo de transporte o utilizado, o por los servidores para retornar una respuesta al cliente en caso de que la petici´n falle. o 10.5.2.4.4. Session Description Protocol (SDP) El protocolo SDP (Session Description Protocol) RFC 4566[45] se utiliza para describir sesiones multicast en tiempo real, siendo util para invitaciones, anuncios, y cualquier otra forma de inicio de ´ sesiones. La propuesta original de SDP fue dise˜ada para anunciar informaci´n necesaria n o para los participantes y para aplicaciones de multicast MBONE (Multicast Backbone). Actualmente, su uso est´ extendido para el anuncio y la negociaci´n de las capacidades a o de una sesi´n multimedia en Internet. o Puesto que SDP es un protocolo de descripci´n, los mensajes SDP se pueden transo portar mediante distintos protocolos con SIP, SAP, RTSP, correo electr´nico con aplio caciones MIME o protocolos como HTTP. Como el SIP, el SDP utiliza la codificaci´n o del texto. Un mensaje del SDP se compone de una serie de l´ ıneas, denominados campos, donde los nombres son abreviados por una sola letra, y est´ en un orden requerido para a simplificar el an´lisis. El SDP no fue dise˜ado para ser f´cilmente extensible. a n a La unica manera de ampliar o de agregar nuevas capacidades al SDP es definir un ´ nuevo atributo. Sin embargo, los atributos desconocidos pueden ser ignorados. En la tabla siguiente podemos observar todos los campos.
- 187. 10.5. RA SIP 155 Tipo Descripci´n Obligatorio o V Versi´n del protocolo (obligatorio) o o Identificador (obligatorio) S Nombre de sesi´n (obligatorio) o I Informaci´n de la sesi´n (obligatorio) o o U URI de la descripci´n o e Direcci´n de correo o p N´mero de tel´fono u e p N´mero de tel´fono u e C Informaci´n de conexi´n o o b Ancho de banda Z Tiempo de correcci´n o K Clave de encriptaci´n a Atributos o T Tiempo de sesi´n(Start y stop) (obligatorio) o R Tiempo de repetici´n o m Informaci´n del protocolo de transporte(media) (obligatorio) o Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): Cisco-SIPUA 26425 12433 IN IP4 192.168.0.100 Owner Username: Cisco-SIPUA Session ID: 26425 Session Version: 12433 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.0.100 Session Name (s): SIP Call Connection Information (c): IN IP4 192.168.0.100 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.0.100 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 17338 RTP/AVP 0 8 18 101 Media Type: audio Media Port: 17338 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Format: ITU-T G.729 Media Format: 101 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15
- 188. CAP´ ITULO 10. RESOURCE ADAPTORS 156 10.5.2.4.5. JAIN SIP Extensible por Dise˜ o n borradores de internet y RFCs t´ ıpicamente definen: Las extensiones SIP descritas en - Nuevos m´todos SIP. e Nuevos m´todos de creaci´n de di´logos. e o a - Nuevas cabeceras SIP. JAIN SIP define un framework extensible para soportar nuevas cabeceras estandarizadas por SIP. - Nuevos m´todos SIP pueden ser fijados usando el campo string del m´todo de un e e request. - Una aplicaci´n informa a la pila de los m´todos de creaci´n de di´logos, especificano e o a do el nombre del m´todo a la propiedades de la configuraci´n SipStack EXTENe o SION METHOD.
- 189. 10.5. RA SIP 10.5.2.5. 157 Transacciones y di´logos a Figura 10.10: Estructura de una aplicaci´n gen´rica SIP. o e 10.5.2.5.1. Transacciones SIP Una transacci´n SIP consiste en un solo Request o y cualquier n´mero de Responses a esa petici´n. u o
- 190. 158 CAP´ ITULO 10. RESOURCE ADAPTORS Figura 10.11: Transacciones SIP. 10.5.2.5.2. Soporte a las transacciones JAIN SIP estandariza la interfaz para el modelo gen´rico transaccional definido por el protocolo SIP. e - En los modelos JAIN SIP las transacciones del Cliente y del Servidor como interfaces. La transacci´n se crea a la llegada de Request o podr´ ser creado para enviar o ıa Request salientes. - Cuando un Request es enviado fuera statefully, la aplicaci´n debe responder a una o transacci´n del Cliente. o - Cuando un nuevo Request llega, la aplicaci´n determina si manejar el Request meo diante una transacci´n del Servidor. o - Cuando un Request de un di´logo existente llega, la pila lo asocia autom´ticamente a a a una transacci´n del Servidor. o Cuando llega un Responder, la pila quiz´s lo asocie a una transacci´n del Cliente a o creada previamente con el Response. - podr´ perderse. ıa
- 191. 10.5. RA SIP 159 Los Mensajes son pasados al SipProvider para generar una nueva transacci´n. Esta o transacci´n puede ser usada para enviar el mensaje a la red. o La implementaci´n maneja la asociaci´n entre las transacciones y los di´logos. o o a 10.5.2.5.3. Soporte al di´logo a Un di´logo es una asociaci´n punto a punto entre puntos finales SIP de comunia o caci´n o - El di´logo representa un contexto en el que interpretar los mensajes SIP. a Los di´logos nunca son creados directamente por la aplicaci´n. a o - Los di´logos son establecidos por transacciones creadoras de di´logos (INVITE; a a SUBSCRIBE...) y son manejados por la pila. El borrado de los di´logos estar´ bajo el control de la aplicaci´n. a ıa o - Aunque no sea recomendado generalmente. Los di´logos son usados para mantener los datos necesarios para m´s transmia a siones de mensajes dentro del di´logo. a - Conjuntos de rutas, secuencia de n´meros, URIs de las partes en el di´logo. u a Los di´logos tienen un estado. a - Early, Confirmed, Completed y Terminated. Las transacciones podr´ pertenecer a un di´logo. ıan a - El estado del di´logo cambia como resultado de los cambios en el estado de la a transacci´n. o - Acceso a la funcinalidad del di´logo desde la interfaz de la transacci´n. a o 10.5.2.6. Ejemplo 3PCC 10.5.2.6.1. Third Party Call Control 3PCC se refiere a la habilidad general para establecer y manipular llamadas entre otras partes. El establecimiento de esas llamadas es orquestada por un tercero, llamado el controller: - Un controller es un SIP User Agent (UA) que quiere crear una sesi´n entre otros dos o agentes. 3PCC es frecuentemente usado para: - Servicios del operador, por ejemplo, el operador crear una llamada que conecta dos participantes juntos. - Conferencia.
- 192. 160 CAP´ ITULO 10. RESOURCE ADAPTORS Figura 10.12: Ejemplo 3PCC usando JAIN SIP.
- 193. 10.5. RA SIP 10.5.3. 161 Sip RA Type Memo Es una descripci´n de una extensi´n del SIP RA Type (como est´ recomendado en o o a el JAIN SLEE 1.0) que soporta di´logos SIP. El ´xito es especificar un SIP RA Type a e para simplificar notablemente la escritura de aplicaciones JSLEE usando di´logos SIP. a Este es un esfuerzo de la comunidad para ponerse de acuerdo con la extensi´n del o di´logo que puede ser m´s tarde estandarizada via JCP18 a a 10.5.3.1. SIP RA Type con conjuntos de eventos duales Esto es una descripci´n de la estrategia adoptada por Open Cloud que en peque˜as o n cantidades para definir modelos de eventos duales para peticiones SIP que pueden ocurrir cualquiera como unos Mid-dialog Requests19 y unos Out-of-dialog Requests20 . Como ejemplo hay dos modelos de eventos para peticiones SIP que corresponden a una petici´n MESSAGE, que su uso depende en si hay un dialog ACI presente o no. Hay o tambi´n modelos de eventos adicionales para respuestas sip que tienen un impacto en e el correspondiente di´logo. Por ejemplo el evento javax.sip.dialog.SetupConfirmed es a lanzado por una respuesta SIP OK si hay un dialog ACI. La raz´n para esto es que o el impacto de la expuesta sip es de mayor inter´s para la aplicaci´n que la respuesta e o actual sip. 10.5.3.2. Activities Context e Interfaces del RA Sip Hay una un nuevo AC, javax.sip.Dialog, y los antiguos activities contin´an siendo u los mismos (javax.sip.ClientTransaction, javax.sip.ServerTransaction). El SipActivityContextInterfaceFactory es extendido con el siguiente m´todo: e public ActivityContextInterface getActivityContextInterface(javax.sip.Dialog dialog) throws NullPointerException, UnrecognizedActivityException, FactoryException; 18 El Proceso de la Comunidad Java, o Java Community Process, establecido en 1998, es un proceso formalizado el cual permite a las partes interesadas involucrarse en la definici´n de futuras versiones y o caracter´ ısticas de la plataforma Java. 19 Una petici´n comienza una nueva transacci´n junto con un di´logo ya establecido, como est´ deo o a a scrito en el RFC 3261 ?? secci´n 12.2. Ejemplos son: re-INVITEs, BYE, MESSAGE. o 20 Una petici´n que se env´ fuera un di´logo existente. El ejemplo m´s com´n es un INVITE original o ıa a a u que puede dirigirse a un di´logo creado pero que es por definici´n enviado antes de que ning´n di´logo a o u a exista
- 194. CAP´ ITULO 10. RESOURCE ADAPTORS 162 10.5.3.3. Tablas de Eventos Event ID (name,vendor,version) javax.sip.message.Request.INVITE, javax.sip, 1.1 javax.sip.message.Request.ACK, javax.sip, 1.1 javax.sip.message.Request.CANCEL, javax.sip, 1.1 Class javax.sip.RequestEvent Activity Object javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.message.Request.BYE, javax.sip, 1.1 javax.sip.message.Request.REGISTER, javax.sip, 1.1 javax.sip.message.Request.OPTIONS, javax.sip, 1.1 javax.sip.message.Request.PRACK, javax.sip, 1.1 javax.sip.message.Request.INFO, javax.sip, 1.1 javax.sip.message.Request.UPDATE, javax.sip, 1.1 javax.sip.message.Request.REFER, javax.sip, 1.1 javax.sip.message.Request.SUBSCRIBE, javax.sip, 1.1 javax.sip.message.Request.NOTIFY, javax.sip, 1.1 javax.sip.message.Request.MESSAGE, javax.sip, 1.1 javax.sip.message.Request.SIP EXTENSION, javax.sip, 1.1 javax.sip.RequestEvent javax.sip.ServerTransaction, INVITE or CANCEL transaction, depending on scenario see Canceling request javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction javax.sip.RequestEvent javax.sip.ServerTransaction Tabla 10.5: Out of dialog requests - same as JAIN SIP 1.1 RA type Event ID (name,vendor,version) javax.sip.dialog.Request.INVITE, net.java, 1.2 javax.sip.dialog.Request.ACK, net.java, 1.2 javax.sip.dialog.Request.BYE, net.java, 1.2 javax.sip.dialog.Request.REGISTER, net.java, 1.2 javax.sip.dialog.Request.OPTIONS, net.java, 1.2 javax.sip.dialog.Request.PRACK, net.java, 1.2 javax.sip.dialog.Request.INFO, net.java, 1.2 javax.sip.dialog.Request.UPDATE, net.java, 1.2 javax.sip.dialog.Request.REFER, net.java, 1.2 javax.sip.dialog.Request.SUBSCRIBE, net.java, 1.2 javax.sip.dialog.Request.NOTIFY, javax.sip, 1.1 javax.sip.dialog.Request.MESSAGE, javax.sip, 1.1 javax.sip.dialog.Request.SIP EXTENSION, javax.sip, 1.1 Class javax.sip.RequestEvent Activity Object javax.sip.Dialog Notes (1) javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog, javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog javax.sip.RequestEvent javax.sip.Dialog Tabla 10.6: In-dialog requests - new for 1.2 RA Type Notes (2)
- 195. 10.5. RA SIP 163 Event ID (name,vendor,version) avax.sip.message.Response.TRYING, javax.sip, 1.1 javax.sip.message.Response.INFORMATIONAL, javax.sip, 1.1 javax.sip.message.Response.SUCCESS, javax.sip, 1.1 javax.sip.message.Response.REDIRECTION, javax.sip, 1.1 javax.sip.message.Response.CLIENT ERROR, javax.sip, 1.1 javax.sip.message.Response.SERVER ERROR, javax.sip, 1.1 javax.sip.message.Response.GLOBAL FALIURE, javax.sip, 1.1 Class javax.sip.ResponseEvent Activity Object javax.sip.ClientTransaction javax.sip.ResponseEvent Notes (3) javax.sip.ClientTransaction javax.sip.ResponseEvent javax.sip.ClientTransaction (1) javax.sip.ResponseEvent javax.sip.ClientTransaction (1) javax.sip.ResponseEvent javax.sip.ClientTransaction (1) javax.sip.ResponseEvent javax.sip.ClientTransaction (1) javax.sip.ResponseEvent javax.sip.ClientTransaction (1) Tabla 10.7: Responses - same as JAIN SIP 1.1 RA Type EVENT ID (name,vendor,version) javax.sip.Timeout.TRANSACTION, javax.sip, 1.1 javax.sip.Timeout.DIALOG, net.java, 1.2 Class javax.sip.TimeoutEvent javax.sip.DialogTerminatedEvent Activity Object javax.sip.ClientTransaction/ javax.sip.ServerTransaction javax.sip.Dialog Notes (1) (1) Tabla 10.8: Timeouts EVENT ID (name,vendor,version) javax.sip.dialog.SetupEarly, net.java, 1.2 javax.sip.dialog.SetupConfirmed, net.java, 1.2 javax.sip.dialog.SetupFailed, net.java, 1.2 javax.sip.dialog.SetupTimedOut, net.java, 1.2 javax.sip.dialog.Terminated, net.java, 1.2 Class javax.sip.ResponseEvent Activity Object javax.sip.Dialog Notes (4) javax.sip.ResponseEvent javax.sip.Dialog (4)) javax.sip.ResponseEvent javax.sip.Dialog (1/4) javax.sip.TimeoutEvent javax.sip.Dialog (1/4) javax.sip.DialogTerminatedEvent javax.sip.Dialog (1) Tabla 10.9: Dialog State events - new for 1.2 RA Type EVENT ID (name,vendor,version) javax.sip.transaction.Terminated, net.java, 1.2 javax.sip.dialog.TerminationRequest, net.java, 1.2 Class javax.sip.Transaction TerminatedEvent javax.sip.RequestEvent Activity Object javax.sip.Transaction (one of transactions) javax.sip.Dialog Notes (1) -Lanzado cuando la petici´n es recibida y o el di´logo es cerrado al a recibir el BYE Tabla 10.10: New for 1.2 RA Type 10.5.3.4. Notas 1. Este evento tambi´n termina con la actividad. e 2. Este evento es usado cuando el m´todo request no es reconocido. e 3. Este es solamente para las respuestas “100 Trying”, que pueden normalmente ser ignoradas de manera segura por el app. 4. Estos eventos ser´n lanzados en vez de los t´ a ıpicos eventos /response/timeout, si existe un actividad de di´logo. a
- 196. CAP´ ITULO 10. RESOURCE ADAPTORS 164 5. Si una petici´n BYE que termina el di´logo es recibida, el RA disparar´ un evento o a a javax.sip.dialog.TerminationRequest en vez de un evento javax.sip.dialog.Request.BYE. Un BYE no siempre termina un di´logo (Por ejemplo si las subscripciones est´n a´n a a u activas). Parecido a un evento Terminated que ser´ lanzado por un request NOTIFY a con “Subscription-State: terminated” cuando sea recibido, y no hay otros subscriptores o sesiones usando el di´logo. a 10.5.3.5. Eventos y actividades Las tablas de eventos est´ divididas en cuatro categor´ de eventos que son descritas a ıas aqu´ motivadas e ilustradas con ejemplos. Espec´ ı, ıficamente el uso de actividades de di´logo y actividades de transacci´n necesitan ser explicados ya que coexisten y est´n a o a interrelacionados. Esta secci´n describe los pasos para ser realizados por el c´digo de o o la aplicaci´n y especifica el comportamiento del RA en situaciones diferentes. o 10.5.3.6. Eventos Out-of-dialog request Entregados en un “server transaction activity”, estos eventos hacen expl´ ıcito lo que est´ en un out-of-dialog request. Las aplicaciones que no necesitan di´logos se limitan a a a esta categor´ de eventos request. Cuando un out-of-dialog requests es lanzado mediante ıa un m´todo dialog creating request la aplicaci´n puede optar por tomar ventaja del e o soporte del di´logo o solamente continuar usando la transacci´n basada en ACIs. Las a o aplicaciones que quieran tomar ventaja del soporte de di´logo har´n lo siguiente: a a Obtener el objeto javax.sip.Dialog para la petici´n que est´ hecha llamando al o a m´todo javax.sip.SipProvider.getNewDialog(Transaction tx). El SipProvider es e obtenido del JainSipResourceAdaptorSbbInterface). Obtener el activity context interface llamando a SipActivityContextInterfaceFactory.getActivityContextInterface(Dialog dialog) Ligarlo al dialog ACI. Trozo del c´digo fuente: o JainSipResourceAdaptorSbbInterface intf = ... SipActivityContextInterfaceFactory factory = ... SbbLocalObject myLocalObject = ... SipProvider provider = intf.getSipProvider(); Dialog dialog = provider.getNewDialog(requestEvent.getServerTransaction()); ActivitiyContextInterface aci = factory.getActivityContextInterface(dialog); aci.attach(myLocalObject); A partir de este punto el siguiente mid-dialog requests ser´ entregado al dialog a ACI. El RA crea un server transaction activity, para estas peticiones y si la aplicaci´n o necesita usar el correspondiente ACI, puede obtenerlo haciendo lo siguiente:
- 197. 10.5. RA SIP 165 ServerTransaction tx = RequestEvent.getServerTransaction(); SipActivityContextInterfaceFactory factory = .... ActivityContextInterface aci = factory.getActivityContextInterface(tx); Normalmente los Sbbs deber´ estar ligados al server transaction ACI corresponıan diente al out-of-dialog INVITE request iniciando un di´logo. a No es necesario crear el dialog ACI y ligarlo inmediatamente despu´s de que el e di´logo haya sido obtenido. Este paso puede ser pospuesto a un early state ya que el a objeto del di´logo se puede obtener de javax.sip.RequestEvent 10.10, a javax.sip.ResponseEvent 10.9 y javax.sip. Objetos de transacci´n respectivamente. Sin o embargo est´ recomendado en algunos casos cuando el di´logo no ha sido creado aua a tom´ticamente. Algunas implementaciones pueden depender en la ligadura al dialog a ACI. 10.5.3.7. Eventos Mid-dialog request Los eventos en esta categor´ reflejan los eventos en la secci´n previa pero difieren ıa o en que son entregados a una actividad de di´logo. De esta manera el desarrollador de la a aplicaci´n puede asumir con seguridad que la actividad subyacente es un di´logo y act´a o a u como corresponde. Un ejemplo sencillo es un Sbb que inicia un di´logo y lo liga a un diaa log ACI. Este recibir´ un re-INVITE posterior en el dialog ACI. Nota que si el Sbb tama bi´n tiene un m´todo event callback para el m´todo javax.sip.message.Request.INVITE e e e 10.5 este requerir´ una definici´n de m´todo separada. Esta es la manera m´s f´cil para a o e a a seleccionar con qu´ combinaci´n de m´todos request y ´mbito dialog/transaction el sbb e o e a conseguir´ eventos entregados. a Hay algunos m´todos que merecen alguna explicaci´n extra: e o javax.sip.dialog.Request.ACK 10.6 Es usado para reconocer un 200 OK enviado donde el INVITE fue entregado en un dialog ACI. Podr´ necesitarse usar el server transaction ACI siguiendo el ıa procedimiento descrito arriba. javax.sip.dialog.Request.BYE 10.6 Es usado en el caso de un BYE que no termina el di´logo. Esto ocurre si hay a subscriptores activos pertenecientes al di´logo. Para BYE y otras respuestas que a terminan un di´logo es usado el evento javax.sip.dialog.TerminationRequest. De a esta forma la pila sip es adaptada un poco para hacerla m´s conveniente para a aplicaciones enfocadas en los cambios del estado del di´logo. Nota que es a´n a u posible obtener el objeto javax.sip.message.Request que caus´ que el evento fuera o lanzado. 10.5.3.8. Creaci´n autom´tica de di´logos o a a El RA deber´ soportar la creaci´n autom´tica de di´logos (sin embargo esta carıa o a a acter´ ıstica deber´ ser opcional - tiene que tener algo que permita activar y desactivar ıa
- 198. CAP´ ITULO 10. RESOURCE ADAPTORS 166 para restringir el uso de in-dialog INVITEs si fuera necesario). De esta manera el c´digo o del sbb ser´ simplificado y el programador tendr´ que preocuparse menos de ´stos. Esa a e to puede conseguirse a˜adiendo al sbb-jar.xml una definici´n de manejador de eventos n o como el siguiente: <event event-direction=’’Receive’’ initial-event=’’True’’> <event-name>InDialogInvite</event-name> <event-type-ref> <event-type-name> javax.sip.dialog.Request.INVITE </event-type-name> <event-type-vendor>net.java</event-type-vendor> <event-type-version>1.2</event-type-version> </event-type-ref> .... </event> Esto notificar´ al RA que nos gustar´ usar di´logos. El RA enviar´ autom´ticaa ıa a a a mente 200 response al INVITE Request recibido, con el generado toTag para realizar todos los prerrequisitos para crear un di´logo v´lido. Sin embargo si la aplicaci´n quiere a a o usar di´logos pero no est´ interesado en indialog re-INVITEs(por ejemplo Session a a Timers del rfc 4028[44]) puede seguir el escenario mencionado arriba. Esto es hecho solo para peticiones entrantes. Si la aplicaci´n local va a usar di´logos tiene que seguir o a el escenario de arriba. 10.5.3.9. Respuestas Esta categor´ es la misma el Type RA JAIN SIP 1.1 y todos los eventos son ıa entregados en un client transaction activities. Las aplicaciones que no usen di´logos a relacionados s´lo para esta categor´ por eventos causados por mensajes de respuesta o ıa sip (esto es aclarado m´s abajo). a Las aplicaciones que quieren usar el soporte del di´logo deben obtener un di´logo a a antes de que sea enviado una petici´n de creaci´n de di´logo (Mirar la documentaci´n o o a o de JAIN SIP 1.2).
- 199. 10.5. RA SIP 167 Un trozo de c´digo: o JainSipResourceAdaptorSbbInterface intf = ... SipActivityContextInterfaceFactory factory = ... SbbLocalObject myLocalObject = ... ClientTransaction tx = .... SipProvider provider = intf.getSipProvider(); Dialog dialog = provider.getNewDialog(tx); ActivitiyContextInterface aci = factory.getActivityContextInterface(dialog); aci.attach(myLocalObject); No es obligatorio crear y ligar a un dialog ACI a esta etapa, puede ser pospuesto a una etapa posterior si se desea (pero es recomendado hacerlo tan pronto como se cree el objeto que representa el di´logo). El trozo de c´digo muestra el modo recomendado a o para la mayor´ de las aplicaciones. Si el Sbb es ligado al dialog ACI cuando la petici´n ıa o es enviada el comportamiento del RA es para entregar eventos response en un client transaction activity si el estado del di´logo no es afectado. Para respuestas que afectan a al estado del di´logo los eventos de la categor´ “Dialog state events” son usados. Mira a ıa la siguiente secci´n para ver ejemplos que contienen los dos tipos de eventos. o 10.5.3.10. Dialog state events Esta categor´ existe para ayudar a las aplicaciones que usan di´logos 10.9, todos ıa a los eventos son entregados a ACIs de di´logo. Por ejemplo, el RA mapear´ m´ltiples a a u respuestas sip a uno de los eventos en esta categor´ si estos tienen el mismo efecto ıa en el estado del di´logo. Un ejemplo concreto son las respuestas de error de 400 - 600 a 10.5.2.4.1 que son todas mapeadas al evento javax.sip.dialog.SetupFailed El estado de di´logo es afectado por responses, requests y timeouts y lo siguiente a es un resumen general de los eventos: Cuando una respuesta provisional con una etiqueta “To” es recibida el di´logo entra a al early state y el evento javax.sip.dialog.SetupEarly es lanzado. Si despu´s es recibida una respuesta final 2XX, el evento e javax.sip.dialog.SetupConfirmed es lanzado. En caso de recibir contrario se disparar´ el evento javax.sip.dialog.SetupFailed. a Si la configuraci´n del di´logo excede el tiempo de espera, un evento o a javax.sip.dialog.SetupTimedOut es lanzado, esto ocurre si no llega una respuesta final a tiempo. El evento javax.sip.dialog.Terminated es lanzado cuando el di´logo es terminado, lo a que puede ser hecho de diferentes maneras. El modo m´s com´n es un BYE request a u pero tambi´n un NOTIFY puede terminar un di´logo. e a 10.5.3.11. Timeout Las transacciones SIP exceden el tiempo de espera si no se completan dentro de un intervalo de tiempo especificado 10.8. El evento javax.sip.Timeout.TRANSACTION es
- 200. CAP´ ITULO 10. RESOURCE ADAPTORS 168 usado para avisar de esto. Este evento es entregado al correspondiente client transaction o server transaction activity. El evento javax.sip.Timeout.DIALOG es usado para informar a una aplicaci´n de o que un Di´logo ha terminado debido a que ha sobrepasado el tiempo permitido sin a entregar ning´n mensaje. Un ejemplo: Hay un di´logo entre dos UAs y uno de ellos se u a cae. El objeto de actividad del di´logo en la aplicaci´n SLEE podr´ continuar para a o ıa existir indefinidamente si no hubiera mecanismos que liberara los recursos relacionados con ´l. e 10.5.3.12. Example scenarios Aqu´ seguimos un conjunto de escenarios con eventos, mensajes sip enviados, e ı indicaciones de d´nde empiezan y acaban las actividades. o 10.5.3.12.1. INVITE con ´xito Este flujo describe el flujo de eventos para un e Sbb que inicia un di´logo y lo termina enviando un BYE. a 1. Sbb ligado a un dialog ACI y a un client transaction ACI. 2. Comenzado el client transaction y el dialog activity . 3. INVITE 4. javax.sip.message.Response.Trying en client activity. 5. javax.sip.dialog.SetupEarly en dialog activity. 6. javax.sip.dialog.SetupConfirmed en dialog activity. 7. ACK 8. Terminado el client transaction activity. 9. Continua existiendo el Dialog activity , aqu´ mid-dialog requests posteriores pueden ı ocurrir junto esta actividad. 10. Comenzado el Client transaction activity. 11. BYE 12. (que deber´ ser enviado mediante el m´todo javax.sip.Dialog.sendRequest) ıa e OK 13. Terminado el client transaction y el dialog activity. 10.5.3.12.2. Invitaci´n Cancelada (INVITE original) Este flujo es para un o Sbb recibiendo un INVITE que es cancelado m´s tarde. a 1. Comenzado el server transaction activity. 2. javax.sip.message.Request.INVITE en server transaction activity.
- 201. 10.5. RA SIP 169 3. El sbb crea un di´logo y lo conecta al dialog ACI. a 4. Comenzado el Dialog activity. 5. 180 Ringing 6. El UAC Dialog introduce un early state, ahora est´ permitido que el UAC cancele a el request. 7. 8. SIP CANCEL llega al RA que responde con un 200 OK al CANCEL y 487 “Request Terminated” al INVITE request que ha sido cancelado. javax.sip.message.Request.CANCEL en server transaction activity. 9. Terminado el server transaction y el dialog activity. (Si el Sbb intenta responder con un 200 OK despu´s de que el RA haya respondido e con un 487 “Request Terminated” el RA debe lanzar una excepci´n IllegalStateExcepo tion)
- 202. CAP´ ITULO 10. RESOURCE ADAPTORS 170 10.5.4. Descarga del c´digo fuente o Para descargar el c´digo fuente del RA sip, deber´s descargarlo del repositorio SVN o a (ver Anexo G) de la siguiente direcci´n: o https://slee-sip-ra.dev.java.net/svn/slee-sip-ra/trunk 10.5.5. Despligue del RA SIP Para los ejemplos, utilizamos el RA SIP y el servicio Proxy, ambos disponibles en el cvs, dentro de la carpeta mobicents-examples/lib/ o en el servidor mobicents1.0.00.CR3/examples/lib/ Para desplegarlos, seguiremos los siguientes pasos: 1. Inicia el servidor Mobicents: $MOBICENTS HOME$/bin/run -c all -b <127.0.0.1 o tu direcci´n ip> o 2. Aseg´rate que dentro del fichero $MOBICENTS EXAMPLES$/ejemplos/lib/build.xml u jnpHost sea igual a <127.0.0.1 o tu direcci´n ip> o 3. Despliegue del SIP RA : $MOBICENTS EXAMPLES$/lib/slee-sip-ra ant deploy 4. Despliegue del Servicio Proxy: $MOBICENTS EXAMPLES$/lib/sipservices ant deploy Figura 10.13: RA SIP y Servicio Proxy
- 203. 10.6. RA SMPP 10.6. RA SMPP 10.6.1. 171 Introducci´n o El protocolo SMPP (Short Message Peer to Peer) es un protocolo industrial standard abierto, dise˜ado para ofrecer una interfaz flexible de comunicaciones de datos n de mensajes de datos cortos entre un Message Center, como SMSC21 , Servidor GSM USSD22 u otro tipo de Message Center y un SMS application system, como un Servidor Proxy, EMail Gateway u otro Gateway de Messaging. Usando el protocolo SMPP, un sistema de aplicaci´n de SMS llamado ESME23 poo dr´ iniciar una conexi´n de aplicaci´n de capa con un SMSC sobre una conexi´n de ıa o o o red TCP/IP y despu´s podr´ enviar mensajes cortos y recibir mensajes cortos de y e ıa hacia el SMSC respectivamente. El ESME podr´ tambi´n interrogar, cancelar o reemıa e plazar mensajes cortos usando SMPP. SMPP soporta un conjunto de caracter´ ısticas de funciones de mensajes en dos direcciones como: Transmitir mensajes desde un ESME a uno o m´ltiples destinos por medio del u SMSC item Un ESME podr´ recibir mensajes por medio del SMSC de otra estaci´n m´vil ıa o o de un SME (ej. Estaciones m´viles). item o Interrogar el estado de un mensaje corto almacenado en el SMSC. item Cancelar o reemplazar un mensaje corto almacenado en el SMSC. item Enviar un mensaje corto registrado (para que un ’delivery receipt’ sea devuelto por el SMSC al que origino el mensaje). ”Programa la fecha y hora de entrega del mensaje. item Seleccionar el modo del mensaje, ej. Datagrama o almacenar y enviar. item Fijar la prioridad de entrega del mensaje corto. item Definir el tipo de codificaci´n de los datos del mensaje corto. item o Fijar el periodo de validar del mensaje corto. item Asociar un tipo de servicio a cada mensaje, ej. Notificaci´n de mail por voz. item o 21 Short Message Service Center, Es un elemento de la red de tel´fonos m´viles que se encarga de e o entregar los mensajes SMS. 22 Unstructured Supplementary Service Data, Es una capacidad de todo tel´fono GSM. Est´ generale a mente asociado con tipos de servicios de tel´fono en tiempo real o instant´neo. No hay capacidades e a almacenar y enviar que es t´ ıpica de los mensajes cortos ’normales’ (en otras palabras, no est´ presente a un SMSC en el procesamiento de la ruta). El tiempo de respuesta para servicios interactivos basados en USSD son generalmente mas r´pidos que aquellos usados por SMS a 23 External Short Message Entity, Es un t´rmino originalmente inventado por Aldisco para describir e una aplicaci´n externa que se conecta a un SMSC para activarlo en su env´ y/o recepci´n del SMS. o ıo o USSD es parecido a telnet, mientras que SMS es parecido al correo.
- 204. CAP´ ITULO 10. RESOURCE ADAPTORS 172 10.6.1.1. SMPP API ver 3.4 Comandos soportados: BIND - Iniciado por el cliente UNBIND - Iniciado por el cliente o el server SUBMIT SM - Iniciado por el cliente(utilizado para enviar el mensaje) DELIVER SM - Iniciado por el server (Reporte de entregas) ENQUIRE LINK - Iniciado por el cliente. Detalles de la conexion: systemid = [ systemid provided to you ] password = [ password provided to you] systemtype = [ null or “VMA“] IP = XXX.XXX.XXX.XXX Port = XXXX Formato de reporte de Entrega id:<message_id> sub:<message_sub> dlvrd:<message_dlvrd> submit date:<message_submit_date> done date:<message_done_date>stat:<message_stat> err:<message_err> Estado de los mensajes (message stat) DLIVRD, EXPIRED, DELETED, UNDELIV, ACCEPTD, UNKNOWN, REJECTD 10.6.2. SMPP Resource Adaptor El Adaptador de Recursos SMPP adopta SMSC a los requerimientos del SLEE y construye en lo alto de la implementaci´n del SMPP. El c´digo fuente para el coraz´n o o o de la implementaci´n de la pila del SMPP puede ser encontrada en sourceforge . El o c´digo fuente de la implementaci´n del RA en java.net. o o EL RA SMPP define los siguientes conceptos del adaptador de recursos. 10.6.2.1. 10.6.2.1.1. SMPP Resource Adaptor Type Identificador del Resource adaptor type . El nombre del resource adaptor type es ”SMPPResourceAdaptor”. El vendedor del resource adaptor type es ”net.java”. La versi´n del resource adaptor type es la ”3.4”. o
- 205. 10.6. RA SMPP 10.6.2.1.2. 173 Activity objects . Los activity objects para el RA SMPP son: 1. net.java.slee.resource.smpp.ClientTransaction 2. net.java.slee.resource.smpp.ServerTransaction 3. net.java.slee.resource.smpp.Dialog Los transaction objects Pertenecen a las transacciones que manejan las peticiones y respuestas, Dialog object pertenece a la session establecida entre la estaci´n m´vil y el ESME. o o 10.6.2.1.3. Eventos . La siguiente tabla lista los eventos emitidos por SMPP. Eventos Activity Object Transacci´n o Cliente X X net.java.slee.resource.smpp.SUBMIT SM net.java.slee.resource.smpp.SUBMIT SM RESP X X net.java.slee.resource.smpp.DATA SM net.java.slee.resource.smpp.DATA SM RESP X X net.java.slee.resource.smpp.QUERY SM net.java.slee.resource.smpp.SQUERY SM RESP X X net.java.slee.resource.smpp.CANCEL SM net.java.slee.resource.smpp.CANCEL SM RESP X X net.java.slee.resource.smpp.REPLACE SM net.java.slee.resource.smpp.REPLACE SM RESP net.java.slee.resource.smpp.MESSAGE net.java.slee.resource.smpp.DELIVERY REPORT Dialogo X net.java.slee.resource.smpp.DELIVER SM net.java.slee.resource.smpp.DELIVER SM RESP Transacci´n o Servidor X X X Events Type El event type es un mensaje nombrado con el prefijo del paquete net.java.slee.resource.smpp, el vendedor del event type es net.java y su versi´n es la 1.1 o Event classes La clase event para estos eventos son: ˆ net.java.slee.resource.smpp.RequestEvent ˆ net.java.slee.resource.smpp.ResponseEvent
- 206. CAP´ ITULO 10. RESOURCE ADAPTORS 174 Activity Context Interface Factory Interface La interfaz del Activity Context Interface Factory se muestra aqu´ ı: Listado 10.12: Activity Context Interface Factory import j a v a x . s l e e . A c t i v i t y C o n t e x t I n t e r f a c e ; import j a v a x . s l e e . F a c t o r y E x c e p t i o n ; import j a v a x . s l e e . U n r e c o g n i z e d A c t i v i t y E x c e p t i o n ; public i n t e r f a c e R a d i u s A c t i v i t y C o n t e x t I n t e r f a c e F a c t o r y { public A c t i v i t y C o n t e x t I n t e r f a c e g e t A c t i v i t y C o n t e x t I n t e r f a c e ( C l i e n t T r a n s a c t i o n tx ) throws N u l l P o i n t e r E x c e p t i o n , UnrecognizedActivityException , FactoryException ; public A c t i v i t y C o n t e x t I n t e r f a c e g e t A c t i v i t y C o n t e x t I n t e r f a c e ( S e r v e r T r a n s a c t i o n tx ) throws N u l l P o i n t e r E x c e p t i o n , UnrecognizedActivityException , FactoryException ; public A c t i v i t y C o n t e x t I n t e r f a c e getActivityContextInterface ( Dialog dialog ) throws N u l l P o i n t e r E x c e p t i o n , UnrecognizedActivityException , FactoryException ; } } 10.6.2.1.4. Resource adaptor object . El RA object es net.java.slee.resource.smpp.Provider 10.6.2.2. Configuraci´n o El RA SMPP cumple con la especificaci´n JSLEE 1.1. La configuraci´n de las o o propiedades del RA son como siguen: host: The name of the host (or IP-address string) of the SMPP server. Used to establish connection with SMSC in TCP/IP network. Default: localhost port: The port number used by SMPP server to establish connection. Default: 2775 systemId: Used as login name to authenticate connection with SMPP server. Default: 1
- 207. 10.6. RA SMPP 175 systemType: Identifies the type of system. Default:ESME. password: Used as password to authenticate connection with SMPP server. Default:1 addressTon: The default type of number (TON) that should be on received messages.Default:1 addressNpi: The default number plan indicator (NPI) that should be on received messages.Default:0 addressRange: For receivers this specifies the range of numbers for which messages are to be received. This is usually a regular expression but may be server implementation dependent. Default:0020. enquireLinkTimeout: SMPP link timeout in seconds, used to reconnect. Default: 30 El administrador de SLEE puede cancelar la configuraci´n por defecto del RA eno tity en tiempo de desarrollo (en caliente). La unica manera consiste en especificar la ´ URL que apunta al fichero de propiedades como un argumento al m´todo createRee sourceAdaptorEntity() de CLI (ver anexoE.1).
- 208. CAP´ ITULO 10. RESOURCE ADAPTORS 176 10.7. RA XMPP 10.7.1. Introducci´n o El protocolo extensible de mensajer´ y presencia ıa (XMPP, eXtensible Messaging and Presence Protocol) es un protocolo XML para mensajer´ instant´nea (tiemıa a po casi real), presencia y servicios de petici´n y respueso ta. 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 hereda las caracter´ ısticas de adaptabilidad y sencillez del XML. Aunque XMPP no est´ ligado a ninguna arquitectura de red espec´ a ıfica, hasta la fecha normalmente se ha implementado en una arquitectura cliente-servidor que se describe a continuaci´n: o Servidor: Act´a como una capa de abstracci´n para las comunicaciones XMPP. u o Sus reponsabilidades son: ˆ Gestionar las conexiones con otras entidades, los flujos XML que se mantienen con clientes autorizados, servidores y otras entidades. ˆ Enrutar adecuadamente los mensajes XML (XML Stanzas) entre las entidades con que se mantienen los flujos XML. Muchos clientes XML tambi´n almacenan datos que usan los clientes. En estos e casos los datos XML los procesa el servidor, y as´ no se env´ a otras entidades ı ıan Cliente: Muchos clientes se conectan directamente a un servidor sobre conexiones TCP y usan XMPP para obtener toda la funcionalidad del servidor y los servicios asociados. Simult´neamente se pueden conectar m´ltiples dispositivos, y cada uno a u se diferencia con la direcci´n XMPP definida en el esquema de direcciones (p.ej.: o <node@domain/home> y <node@domain/work>). Recomiendan usar el puerto 5222. Pasarela o Gateway: es un servicio de prop´sito especial del lado servidor cuya o funci´n principal es traducir mensajes XMPP en el protocolo usado por un sistema o de mensajer´ externo (que no sea XMPP), as´ como traducir los mensajes que ıa ı provienen de dicho sistema otra vez a XMPP. Algunos ejemplos son pasarelas a correo electr´nico (SMTP), IRC, SMS, y servicios de mensajer´ anteriores, como o ıa AIM, ICQ, MSN Messenger y Yahoo! Instant Messenger. La comunicaci´n entre o las pasarelas y los sistemas externos no se definen en este documento. Dado que cada servidor se identifica por una direcci´n de red y porque las comuo nicaciones servidor a servidor son una extensi´n directa de las comunicaciones clienteo servidor, en la pr´ctica, el sistema consiste en una red de servidores que se intercomunia can. Este patr´n es parecido al que usan los protocolos de mensajer´ (SMTP) que usan o ıa
- 209. 10.7. RA XMPP 177 las direcciones de red est´ndar. Las comunicaciones entre 2 servidores son opcionales. a Si est´n activadas, deben realizarse mediante flujos XML sobre una conexi´n XML. El a o puerto recomendado para conexiones entre servidores es el 5269. Figura 10.14: xmpp-ra-DU 10.7.2. Eventos Eventos Vendor org.jivesoftware.smack.packet.Message org.jivesoftware.smack.packet.Presence org.mobicents.slee.resource.xmpp.packet.PresenceProbe org.jivesoftware.smackx.packet.DiscoverInfo org.jivesoftware.smackx.packet.DiscoverItems org.jivesoftware.smack.packet.IQ org.jivesoftware.smackx.packet.IQBasedAvatar org.jivesoftware.smack.packet.Registration Version org.jivesoftware.smack org.jivesoftware.smack org.jivesoftware.smack org.jivesoftware.smack org.jivesoftware.smack org.jivesoftware.smack org.jivesoftware.smack org.jivesoftware.smack 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Tabla 10.11: Eventos RA XMPP
- 210. CAP´ ITULO 10. RESOURCE ADAPTORS 178 10.8. RA Media 10.8.1. Introducci´n o El tipo Media RA se crea para dar soporte a varias caracter´ ısticas b´sicas media, a incluyendo: 1. Dotar de un medio para adjuntar stream listeners de tipo RTP en una direcci´n o y puerto, y redirigir los datos media desde un lugar de entrada (o URL) 2. Lanzar eventos DTMF24 desde un media stream entrante. 3. Abrir media stream RTP salientes en una direcci´n y puerto o 4. Salida de media stream RTP dando la stream de entrada en java como una URL. A˜adir peticiones para salidas en colas de prioridades. Servir de streams de salida n secuenciales basados en la prioridad o mezclarlos cuando pertenecen al mismo grupo l´gico y tienen la misma prioridad. o 5. Text to Speech: Toma el texto como una cadena y lo convierte como un stream media de entrada si el modulo de traducci´n est´ disponible para el lenguaje o a dado. 6. Speech to Text: Adjunta ´ separa desde un stream entrante y lanza eventos de o texto que representan a la voz recibida. 7. Ejecuta script VoiceXML, dado una URL con el script VXML, realiza la entrada y salida de streams RTP. 10.8.2. Identificador de tipo RA El nombre del tipo RA es “media ratype”, el vendedor es “org.mobicents.media”, y la versi´n del tipo es “1.0” o 10.8.3. Objeto Activity El objeto activity para el resource Media es el objeto org.mobicents.slee.resource.media.ra.MediaSession 10.8.4. Eventos La siguiente lista de eventos son los emitidos por el resource Media. org.mobicents.slee.media.EndMediaStream: Este evento se lanza cuando se capta la finalizaci´n de un media stream o org.mobicents.slee.media.DTMF: Este evento se lanza cuando se recibe un DTMF 24 Dual-Tone Multi-Frequency,Sistema de marcaci´n por tonos en telefon´ o ıa
- 211. 10.8. RA MEDIA 179 org.mobicents.slee.media.SessionResult: Este evento se lanza para conocer si la creaci´n de un transmisor, receptor ´ transmisor-receptor se ha realizado o no o o (creaci´n as´ o ıncrona de stream) El vendedor del tipo de evento es “org.mobicents.media la version es “1.0” La clase de evento para estos eventos es org.mobicents.slee.resource.media.events.MediaEvent 2 10.8.5. Objeto RA El objeto RA es org.mobicents.slee.resource.media.ratype.MediaProvider: MediaProvider describe la interfaz entre los SBBs y el RA Media. Esta interfaz nos da la posibilidad de crear una nueva Session mediante el m´todo getNewMediaSession() el cual crea y e devuelve una Sesi´n Media con su propio ID Session. o 10.8.5.1. MediaSession Una sesi´n se considera como un intercambio de datos entre los participantes asoo ciados. Veamos algunas de las caracter´ ısticas implementadas: public void createTransmitterReceiver(String sdp, URL fileTx, URL fileRcv, boolean dtmf ) Este ,m´todo se usa para transmitir y recibir stream de audio: e ˆ sdp: Para establecer una sesi´n es necesario conocer la direcci´n remota y el o o puerto de audio. Esta informaci´n se obtiene a partir de la descripci´n del o o SDP enviado por un UA. ˆ filesTx: Ruta del archivo de audio que se quiere transmitir ˆ fileRcx: Ruta donde el audio recibido se grabar´. Si es null, se considerar´ que a a no se quiere grabar el audio recibido ˆ dtmf: Toma el valor verdadero si se quiere procesar d´ ıgitos DTMF, en otro caso toma el valor falso. Al final de la creaci´n del Transmitter-Receiver se lanzara el evento SessionReo sultEvent con el resultado (si todo ha sido correco:result = ok). public void updateLocalAddress(InetAddress localHost) Este m´todo se usa para cambiar el valor que usa por defecto, localhost por e defecto es 127.0.0.1 public String generateSdpDescription(int version, String userName, String sessionName) Este m´todo se usa para obtener la descripci´n SDP de la sesi´n creada. Esta e o o informaci´n se enviar´ al UA que inici´ la creaci´n de la sesi´n enviando su o a o o o descripci´n SDP. o public void startSession() Para comenzar una sesi´n creada. o
- 212. CAP´ ITULO 10. RESOURCE ADAPTORS 180 public void stopSession() Para parar una sesi´n creada o
- 213. 10.9. DIAMETER RA 10.9. Diameter RA 10.9.1. 181 Introducci´n o Es un protocolo de red para la autentificaci´n, autorizaci´n y control (AAA25 ) para o o aplicaciones tales como acceso de red o movilidad IP, sucediendo a su predecesor RADIUS. El protocolo DIAMETER proporciona la misma funcionalidad que RADIUS, pero con mejoras en confiabilidad, seguridad e infraestructura. Puede ser f´cilmente a extendido con nuevos tipos de casos de uso con escenarios AAA y otros escenarios IMS. El concepto b´sico es proporcionar un protocolo base que pueda ser extendido para a proporcionar servicios AAA a nuevas tecnolog´ de acceso. ıas Diameter est´ dise˜ado para trabajar en local y con roaming de AAA. a n Las extensiones son llamadas .Aplicaciones”. Cada aplicaci´n introduce nuevos tipos o 26 . (asignados por IANA27 ), l´gica de proceso etc. de mensajes, mensajes y c´digos AVP o o Tambi´n cada aplicaci´n tiene su propio c´digo que distingue sus mensajes de los mene o o sajes de otra aplicaci´n. Adem´s el c´digo de la aplicaci´n comunicar´ a otros iguales o a o o a que operaciones son soportadas por conexi´n a igual. o Diameter es m´s que un simple protocolo. Un mensaje Diameter consiste en una a cabecera y un cuerpo. Ambos consisten en AVPs ( Attribute Value Pairs : nameOfAttribute=value). AVP es crucial para el protocolo base ( y para las aplicaciones) ha sido estandarizado su documentos ( estandarizaci´n aceptada por IANA. o Ventajas sobre Radius Incrementa el tama˜o de los atributos de datos. n Un transporte mucho mas confiable Mejora en el control Eliminaci´n de paquetes perdidos o Mejores mecanismos Proxy Aumento de el control de sesi´n o Mejoras en las opciones de seguridad 25 Una pol´ ıtica de control de acceso, framework de pol´ ıtica de aplicaci´n y auditaci´n para sistemas o o de computadoras. 26 Son una representaci´n fundamental de datos, ofrecen una estructura de datos open-ended que o permite futuras extensions sin modificar el c´digo o datos existente o 27 Internet Assigned Numbers Authority, es la Agencia de Asignaci´n de N´meros de Internet. Era o u el antiguo registro central de los protocolos Internet, como puertos, n´meros de protocolo y empresa, u opciones y c´digos. Fue sustituido en 1998 por ICANN o
- 214. CAP´ ITULO 10. RESOURCE ADAPTORS 182 Aplicaciones de Diameter Aplicaciones NASREQ Aplicaciones IPv4 para moviles Aplicaciones EAP Aplicaciones de Control de Credito Aplicaciones ·GPP 10.9.2. Mobicents y Diameter Actualmente Mobicents posee un Diameter RA para utilizarlo con JSLEE, viendo las opciones que da este RA y comprobando que esta mucho m´s orientado al mundo a de la IP, descartar´ su uso en el proyecto. Cabe decir que el uso de este RA ser´ ıa ıa conveniente a la hora de necesitar autentificaciones fiables as´ como un buen conducto ı para establecer sesiones P2P. 10.9.2.1. Descripci´n del protocolo o La base del protocolo de Diameter est´ definida por el RFC 3588 [?], y define los a requerimientos m´ ınimos para un protocolo AAA. Las aplicaciones Diameter pueden extender la base del protocolo, a˜adiendo nuevos comandos y/o atributos. Una aplicaci´n n o no es un programa, sino un protocolo basado en Diameter. La seguridad de Diameter est´ dada por IPSEC o TLS, ambos protocolos seguros. a 10.9.2.2. Comandos Cada comando est´ asignado a un c´digo, que es usado por las peticiones y las a o respuestas. A continuaci´n viene una breve descripci´n de cada evento: o o Abort-Session-Request: Puede ser enviado por cualquier servidor al dispositivo de acceso que provee del servicio de sesiones, para pedir que la la sesi´n identificada o por Session-ID sea parada. Abort-Session-Answer: Es enviado en respuesta a ASR. El resultado determina si la sesi´n se ha terminado correctamente o Accounting-Request: Se env´ por uno nodo Diameter, act´a como un cliente, de ıa u forma para intercambiar informaci´n de cuentas con otro. o Accounting-Answer:Se usa para aceptar un comando ACR
- 215. 10.9. DIAMETER RA 183 Nombre del Comando Abort-Session-Request Abort-Session-Answer Accounting-Request Accounting-Answer Capabilities-Exchange-Request Capabilities-Exchange-Answer Device-Watchdog-Request Device-Watchdog-Answer Disconnect-Peer-Request Disconnect-Peer-Answer Re-Auth-Request Re-Auth-Answer Session-Termination-Request Session-Termination-Answer Abr ASR ASA ACR ACA CER CEA DWR DWA DPR DPA RAR RAA STR STA C´digo o 274 274 271 271 257 257 280 280 282 282 258 258 275 275 Tabla 10.12: Comandos Capabilities-Exchange-Request: Se env´ para intercambiar capacidades locales ıa cuando la conexi´n entre pares se esta estableciendo. Contiene c´digo de aplicao o ciones soportadas. Capabilities-Exchange-Answer: Se env´ como respuesta al mensaje CER ıa Device-Watchdog-Request: Se env´ a un par cuando no se ha intercambiado ıa trafico entre dos pares. Device-Watchdog-Answer: Se env´ como respuesta a un mensaje DWR ıa Disconnect-Peer-Request : Se env´ a un par para informar de su intenci´n de ıa o cerrar la conexi´n de transporte. o Disconnect-Peer-Answer: Se env´ como respuesta del mensaje DPR. Una vez se ıa recibe este mensaje, ´se cierra la conexi´n. o Re-Auth-Request: Se enviara por el servidor a un dispositivo de acceso que provee del servicio de sesiones, para pedir que el usuario se re identifique o re autorice. Re-Auth-Answer:Se env´ en respuesta a RAR. El c´digo de resultado AVP tiene ıa o que estar presente, e indica la disposici´n de la petici´n. Un mensaje RAA correcto o o tiene que estar seguido por una identificaci´n y/o autorizaci´n especifico. o o Session-Termination-Request: Se env´ por el dispositivo de acceso para informar ıa al Servidor Diameter que la identificaci´n y/o autorizaci´n de sesi´n se termina. o o o Session-Termination-Answer: Is sent by the Diameter Server to acknowledge the notification that the session has been terminated. Upon sending or receipt of the STA, the Diameter Server MUST release all resources for the session indicated
- 216. CAP´ ITULO 10. RESOURCE ADAPTORS 184 by the Session-Id AVP. Se env´ por el servidor de diameter para aceptar el STR. ıa Una vez se env´ o recibe el STA, el servidor diameter tiene que recopilar todos ıa los recursos de la sesi´n indicadas por el Session-Id del AVP. o 10.9.2.3. Diameter State Machines Son m´quinas de estado finito que deber´ ser observadas por un cliente o servidor a ıan ”hablando¸on otros nodos. Peer connection state machine est´ implementado por un c a pila, session state machine y accounting state machines no. Por lo tanto las dos ulti´ mas deber´ ser implementadas por un servicio (probablemente ser´n parcialmente ıan a implementados por RA/Activities en el futuro). 10.9.2.4. Conceptos principales del RA/RAType Conceptos principales: Diameter es extensible. Las extensiones son llamadas “Aplicaciones dependiendo del tipo de aplicaciones, estas pueden heredar una base de protocolos de mensajes. 2 M´s o menos orientado a el modo Peticion/Respuesta a Las aplicaciones pueden distinguirse gracias a sus IDs (cada mensaje tiene una cabecera) los agentes diameter proveen de otros nodos diameter con alguna funcionalidad. Dependiendo del tipo de agente su actividad puede ser transparente o no. Diameter es P2P por lo que los nodos tienen conocimiento de sus vecinos Vamos a ver algunas implicaciones de dise˜o: n Para estandarizar el manejo de las peticiones/respuestas asumimos que tal par de una sesi´n tendr´ un unico, valido y constante (durante la sesi´n) Session-ID. o a ´ o Las actividades tienen que conocer el destino de sus mensajes y de donde vienen o vendr´n los mensajes, y por supuesto la conexi´n por donde vendr´n. a o a Los eventos entregados a SLEE deben identificar el par el cual tiene que recibir el mensaje, a trav´s de la direcci´n y conexi´n. e o o 10.9.3. Conclusiones El Diameter RA se encuentra en un punto estancado para su implementaci´n en o Mobicents, ya que sus creadores lo han dejado atr´s para dedicarse a otros RAs. Por a lo tanto tan solo se tiene disponible una beta, y ning´n ejemplo pr´ctico que haga uso u a de ´l. e
- 217. Cap´ ıtulo 11 Presente y Futuro 11.1. Hoja de ruta de Mobicents Actualmente el c´digo b´sico est´ pasando de un estado beta a una versi´n como a a o pleta del c´digo para SLEE y el RA SIP, entrando en la fase de pruebas de la primera o versi´n. En paralelo hay varios subproyectos que est´ empezando a ampliarse y unirse o a a futuras versiones de Mobicents. La siguiente versi´n incluir´ caracter´ o a ısticas dirigidas por top “tier carriers”. Esencialmente incluir´ alta fiabilidad y caracter´ a ısticas de disponibilidad, tolerancia a fallos y soporte para administraci´n de cluster. El objetivo es producir una versi´n de Mobio o cents que soporte incluso m´s robusta disponibilidad, tolerancia a fallos y resistencia. a Varios operadores est´n actualmente ejecutando el proyecto en producci´n piloto con a o buenos resultados, pero a´n hay cosas que mejorar. u Hay bastantes tareas que tienen prioridad inmediata. Algunas de ellas est´n en proa greso, desde Mobicents invitan a unirse y hacer estas tareas. Standardize SIP RA Type Estandarizar el SIP RA types para que los SBBs del SIP puedan ser f´cilmente portables entre contenedores como Mobicents y a Rhino. HA Testing Framework Para pruebas de tolerancia a fallos necesitan un Framework de pruebas HA. El Framework de pruebas HA puede estar basado en TCK. Necesitan un RA HA que funcione parecido al RA TCK pero que trabaje a trav´s de la tolerancia a fallos en el cluster. failover. e More robust SIP RA failover Actualmente Mobicents no maneja los escenarios de fallos SIP, uno de ellos es mid-transaction. Necesitan un estado persistente en el RA sip para manejar este caso. Por ejemplo mientras un INVITE est´ siendo a procesado si uno de los nodos falla, la llamada se pierde, pero el tel´fono contine uar´ sonando sin parar, no es una buena situaci´n. Necesitamos cachear la ultima a o ´ respuesta del SBB y retransmitirlo desde el nuevo cluster l´ ıder si la petici´n es o vista otra vez con lo que el failover es transparente. 185
- 218. 186 CAP´ ITULO 11. PRESENTE Y FUTURO Mobicents Design Document Sincroniza los documentos de dise˜o con el n c´digo. ¡Necesitan secuencias y diagramas de clases ahora que el c´digo ha sido o o escrito! SLEE-STONE Performance test suiteUn resource adaptor ligero y un conjunto est´ndar de servicios SLEE can´nicos para medir el rendimiento (througha o put) de los eventos SLEE. Distributed Transactional Deployment Quieren una imagen de desarrollo unica. Ahora mismo cada nodo es desplegado invidualmente. Han cubierto el ´ caso de k nodos, con una imagen desplegada id´ntica y despu´s uno decide salir. e e Por ahora solamente despliegan invidualmente cada nodo del cluster. Esta es una soluci´n que cubre un caso donde todo est´ predesplegado y todos los servidores o a est´n levantados antes de la ca´ El caso m´s duro es qu´ hacer cuando un nodo a ıda. a e se une. Una soluci´n propuesta es poner todas las clases generadas en la cach´ y o e compartirlas entre los miembros del cluster. Performance tuning and bottleneck Identification Aunque el rendimiento es satisfactorio en la fase (1.0b1) necesitan repasar el c´digo en una base regular o e identificar m´s cuellos de botella del rendimiento. a Concurrency Test Cases El TCK en realidad no prueba la concurrencia. Este lo prueba medianamente, pero no del todo. Necesitan pruebas de concurrencia. Una idea es construir el RA SIP otra vez. Lo ideal ser´ acentuar el manejo de ıa m´ltiples actividades y timers a un servicio. u Mobicents Programmers Guide Gu´ amigables con c´digo de ejemplo. ıas o HA Cluster Management Un punto de control central para el cluster entero. Actualmente tienen m´ltiples consolas JMX. u Eclipslee enhancements Composici´n amigable de servicios slee. o Online Profiling Habilidad para proveer performance de profiling data en tiempo de ejecuci´n. Ejemplos como - la mayor´ de los RAs activos, mayor´ de CPUs o ıa ıa que consume Servicios SLEE, SBB con los mayores n´meros de eventos procesau dos, los 10 mayores eventos, gr´ficos del flujo de llamado con arcos highlighted a hot y nodos, etc. Esta tarea requiere conocimiento profundo del c´digo del kernel. o Puede encontrarse material de referencia en JDK 5 JConsole y los documentos Glassfish Managementlos. El prototipo Slee Graph Viewer puede ser un punto de comienzo. Container Portability Extraer dependencias del contenedor para que Mobicents pueda coexistir con m´ltiples contenedores J2EE. Por ejemplo, Glassfish, u WebLogic y WebSphere. Un sistema de construcci´n de niveles m´ximos que administre todos o a los proyectos Necesitan un sistema de construcci´n de niveles m´ximos impulo a sando la contrucci´n de JBoss o Maven2, que puede atraer artefactos de m´ltiples o u
- 219. ´ 11.2. PROXIMAS MEJORAS DE MOBICENTS 187 proyectos y administrar las dependencias entre ellos. Esto es necesario ya que el c´digo b´sico del CVS principal continua creciendo y tiene que dividirse en subo a proyectos. Como estan haciendo eso, la contrucci´n contin´a y ejecutar la suite o u de pruebas deber´ continuar para trabajar efectivamente a lo largo de todos los ıa proyectos. Nombre de la Tarea Prioridad Standardize SIP RA Type Mediana HA Testing Framework Alta More robust SIP RA failover Alta Mobicents Design Document Mediana SLEE-STONE Performance test suite Distributed Transactional Deployment Performance tuning and bottleneck Identification Concurrency Test Cases Mediana Mobicents Programmers Guide Alta Alta Alta No asignado Baja Conocimientos necesarios SLEE Dificultad SLEE, JBOSS y J2EE JAIN SIP, SLEE, JBOSS y J2EE UML, “MagicDraw” SLEE Muy dif´ ıcil SLEE JBOSS y J2EE Performance tuning Muy dif´ ıcil SLEE HA Cluster Management Mediana Eclipslee enhancements Mediana SLEE, JBOSS, HA y J2EE Eclipse y SLEE Online Profiling Mediana SLEE kernel Container Portability Mediana Mediana Maven ANT Dif´ ıcil Normal Mediana Dif´ ıcil Normal SLEE y J2EE One top level build system that manages all projects F´cil a Normal/ dif´ ıcil Dif´ ıcil Muy dif´ ıcil Dif´ ıcil Normal Esfuerzo aproximado 2 Personas, semanas + JSR Process 6 personas, meses 2 personas, meses 2 personas, meses 3 personas, meses 4 personas, meses 2 personas, meses 3 personas, meses 4 personas, meses 6 personas, meses 6 personas, meses 3 personas, meses 3 personas, semanas Tabla 11.1: Detalles de las tareas Desde el foro de de Contribuyentes de Mobicentes [15] puedes encontrar m´s infora maci´n y formar parte del dise˜o de subproyectos. o n 11.2. Pr´ximas mejoras de Mobicents o Career grade 1.0 GA release est´ pr´ximo. a o Caracter´ ısticas de disponibilidad m´s altas . a Mejorar los Resource Adaptors existentes y a˜adir nuevos para Media, Federated n Identity Management, Google Talk/Jingle, more SS7 protocols, Billing. Administraci´n de tiempo de producci´n y herramientas de monitorizaci´n. o o o Creaci´n de servicios aumentados y otras herramientas de desarrollo. o
- 220. 188 CAP´ ITULO 11. PRESENTE Y FUTURO
- 221. Cap´ ıtulo 12 Servicios En est´ secci´n describiremos una serie de Servicios que con Mobicents y los distintos a o Ras disponibles actualmente podemos implementar, todos los servicios son novedosos, rentables y con la posibilidad de cambiar de forma sencilla el flujo de entrega de los servicios a trav´s de un mecanismo de reglas. e 12.1. Servicio RingTone Este servicio es similar al Ya voy de telef´nica, si un usuario tiene activado este servio cio en su tel´fono le elimina la se˜al de llamada, cuando reciba llamadas, el usuario que e n le est´ llamando en los segundos de espera antes de que se establezca la comunicaci´n, a o escuchar´ una canci´n, broma etc. a o Figura 12.1: Servicio Ringtone RA SIP, Parlay, Asterisk RA MGCP 189
- 222. CAP´ ITULO 12. SERVICIOS 190 12.1.1. Dise˜ o n Realiza lo siguiente: Las llamadas llegan al proxy, este comprueba que el usuario llamado esta subscrito al servicio RingBack, y en caso afirmativo crea el SBB RingBack hijo. Servicio RingBack, establece los endpoints, uno el terminal del usuario y otro el servidor de Tonos de espera, y comienza a emitir streaming de audio en el terminal hasta que el otro usuario coja el tel´fono. e Figura 12.2: Diagrama Ring Back Tone 12.2. Servicio Aviso llamada entrante Este servicio funcionar´ con televisi´n por internet y VoIP, el usuario que se enıa o cuentre viendo la televisi´n por internet, recibir´ una aviso en la pantalla de que tiene o ıa una llamada, y tendr´ la opci´n de detener la emisi´n del programa mientras dura la ıa o o llamada.
- 223. 12.2. SERVICIO AVISO LLAMADA ENTRANTE 191 Figura 12.3: Servicio Aviso llamada entrante RA SIP, Parlay, Asterisk RA MGCP 12.2.1. Dise˜o n Realiza lo siguiente: Las llamadas llegan al proxy, este comprueba que el usuario llamado esta subscrito al servicio de televisi´n por ip, y en caso afirmativo crea el SBB Llamada entrante o hijo. El servicio Llamada entrante, lanzar´ eventos al SBB del Servicio de televisi´n a o para que muestre un mensaje en la emisi´n del programa, de que le est´n llamano a do. Si el usuario decide coger el tel´fono, el SBB Llamada entrante establecer´ la e a llamada, mientras la emisi´n quedar´ detenida (en caso de pel´ o a ıculas, series etc), en cuanto termine la llamada, la televisi´n continuara con la emisi´n. o o
- 224. CAP´ ITULO 12. SERVICIOS 192 Figura 12.4: Diagrama de aviso llamada entrante Este mismo ejemplo podr´ ampliarse a mensajes de voz, correo, noticias etc. ıa 12.3. Servicio de llamada enriquecida La llamada tiene las siguientes caracter´ ısticas: 1. Localizaci´n de la ubicaci´n del n´mero origen o o u 2. Localizaci´n del grupo de emergencia m´s cercano o a 3. Chequeo del estatus de presencia de dicho grupo 4. Se realiza una locuci´n al usuario respecto al tiempo estimado de atenci´n o o 5. Envio de un MMS con un mapa con la ubicaci´n de la direcci´n y los detalles al o o equipo m´dico e 6. Establecimiento de la llamada entre el equipo m´dico y el numero origen e
- 225. 12.3. SERVICIO DE LLAMADA ENRIQUECIDA 193 Figura 12.5: Servicio de llamada enriquecida RA Parlay RA MGCP RA MMS (a´n no disponible) u RA DIAMETER 12.3.1. Dise˜o n Realiza lo siguiente: Las llamadas llegan al proxy, este crea los SBB hijos Localizaci´n, Estado y o CallStablish, con prioridades de mayor a menor. El servicio Localizaci´n, contiene la l´gica para localizar el terminal desde donde o o se llama y localizar el grupo de emergencia m´s cercano, ambos mediante el RA a Parlay. El servicio de Estado, comprobar´ mediante una petici´n de estado del grupo de ıa o emergencia, el estado de disponibilidad o no de tal grupo. El servicio de CallStablish crear´ el hijo SBB SBB3Party ıa El servicio SBB3Party maneja la llamada: ˆ En primer lugar dar´ paso a la locuci´n respecto al tiempo estimado usando ıa o el servicio Locuci´n el cual utilizar´ MGCP para crear un vinculo entre el o ıa terminal y un servidor TTS de locuciones ˆ En segundo lugar le mandar´ un MMS al grupo m´dico con la ubicaci´n ıa e o del llamador utilizando el RA MM7 ˆ Y por ultimo establecer´ la llamada entre el llamador y el equipo medico ıa
- 226. CAP´ ITULO 12. SERVICIOS 194 Figura 12.6: Diagrama Llamada Enriquecida 12.4. Servicio SMS gratuito Este servicio consiste en el envi´ de SMS gratuitos, estos incluir´ publicidad de o ıan un tercero, que seg´n el texto enviado, introducir´ un anuncio de publicidad que tuu ıa viera relaci´n, pro ejemplo , si enviar´ un mensaje del tipo “Javi, vamos al cine a ver o a spiderman hoy?” recibir´ al principio del mensaje publicidad de un cine donde vive el ıa usuario que tiene en cartelera spiderman. El an´lisis del mensaje se realizar´ por un web service, que ser´ el encargado de a ıa ıa incluir la publicidad.
- 227. 12.4. SERVICIO SMS GRATUITO 195 Figura 12.7: Servicio SMS gratis RA PARLAY X RA SMPP RA MMS (a´n no disponible) u 12.4.1. Dise˜o n El mensaje enviado llega al SBB Gateway SMS Si el usuario est´ subscrito al servicio de SMSgratis, el SBB SMS Gratis, Introa ducir´ publicidad en el mensaje enviado. a Est´ publicidad la obtendr´ analizando el mensaje con un web service, y seg´n a a u su contenido, y el perfil del usuario, incluir´ una publicidad u otra. a Una vez a˜adida la publicidad al mensaje, el SBB Gateway SMS enviar´ el SMS n a al SMSC
- 228. CAP´ ITULO 12. SERVICIOS 196 Figura 12.8: Servicio SMS gratis 12.5. Servicio de comunicaci´n para MMO o Este servicio permitir´ comunicar a jugadores de MMO1 , teniendo opciones a˜adiıa n dos como ordenes por voz, por combinaciones de teclas o mensajes mandados por escrito. Figura 12.9: Servicio de comunicaci´n para MMO o RA SIP, Parlay, Asterisk PARLAY X RA DIAMETER 1 Massively multiplayer online game
- 229. ´ 12.5. SERVICIO DE COMUNICACION PARA MMO 12.5.1. 197 Dise˜ o n Este servicio funciona del siguiente modo: En primer lugar establece la comunicaci´n (en este caso, mediante SIP, pero o tambi´n se podr´ usar Parlay o cualquier otro RA que ofreciera esta posibilidad) e ıa se crean los SBB hijos de los servicios AAA y MMO. Tras establecer la comunicaci´n, se autentifica al usuario mediante el servicio o AAA y Diameter. Por ultimo se conecta al usuario con un Web Service para permitirle la comuni´ caci´n con usuarios de todo el mundo. o Figura 12.10: Diagrama MMO
- 230. CAP´ ITULO 12. SERVICIOS 198 12.6. Servicio consulta por MM7 Este servicio consistir´ en la consulta de informaci´n del usuario(saldo, servicios ıa o disponibles...). datos utiles ( cines, tiempo, tr´fico ...) recibir informaci´n a la que ´ a o est´ subscrito (movimientos de cuentas bancarias, subidas/bajadas bolsa ...) o recepci´n a o de publicidad. Figura 12.11: Servicio consulta por MM7 RA PARLAY X RA MMS (a´n no disponible) u 12.6.1. Dise˜ o n El usuario manda un SMS para consultar una determinada informaci´n o El SBB Informaci´n, analiza el mensaje, y hace la petici´n a un Web Service o o para informaci´n a terceros ( cine, tiempo, tr´fico ...), o para informaci´n propia o a o (servicios, saldo ...) Mediante el SBB AAA, se encarga de la autentificaci´n, autorizaci´n y control o o del usuario para acceder a la informaci´n. o Una vez identificado, le env´ la informaci´n deseada el SBB Gateway MMS. ıa o
- 231. ´ 12.7. SERVICIO VIDEO MOVIL 199 Figura 12.12: Diagrama consulta por MM7 Esto podr´ ampliarse, pidiendo la informaci´n a trav´s de Internet, Televisi´n ıa o e o interactiva etc. y recibi´ndola desde distintos dispositivos distintos al m´vil, ordenador, e o televisi´n, PDA etc. o 12.7. Servicio Video M´vil o Este servicio podr´ implementar m´vilTV, videoConferencias, reproducci´n videos ıa o o Internet (youtube), mandar videos hacia internet,etc. Para este caso podr´ ıamos utilizar MGCP, la cuesti´n es establecer los endpoints, en o los casos anteriormente descritos: m´vilTV: Un endpoint virtual que representar´ el servidor de Streaming de teleo ıa visi´n, y otro endpoint real que representar´ el m´vil. o ıa o videoConferencia: Se utilizar´ dos endpoints reales representando a los termiıan nales que intervienen en la llamada. Reproducci´n videos Internet: Al igual que con m´vilTV utilizando un endpoint o o virtual para el servidor de videos y uno real para el m´vil. o
- 232. CAP´ ITULO 12. SERVICIOS 200 Figura 12.13: Servicio Video M´vil o Otro caso ser´ el env´ de videos hacia la red, pongamos que el servidor de videos ıa ıo tiene este servicio disponible, se podr´ adaptar para que desde tu m´vil pudieras ıa o registrarte y mandar tus nuevos videos, y a su vez una vez enviado el video avisar a tus contactos via email y sms del nuevo video. RA SIP MGCP RA DIAMETER 12.7.1. Dise˜ o m´vilTV n o Realiza lo siguiente: Las llamadas llegan al proxy, si la conexi´n que se desea establecer es para ver o televisi´n entonces se crea el SBB Validaci´n. o o El servicio Validaci´n comprueba los datos del usuario y si lo valida para el servicio o Televisi´n, posteriormente crea el SBB Televisi´n. o o El servicio Televisi´n crea los endpoints, uno el terminal del usuario y otro el o servidor de Televisi´n, y comienza a emitir streaming de video en el terminal. o Tambi´n maneja la l´gica que conlleva el cambio de canal. e o
- 233. ´ 12.8. SERVICIO DOMOTICA 201 Figura 12.14: Diagrama m´vilTV o 12.8. Servicio Dom´tica o Hoy en d´ el concepto de la casa inteligente esta muy de moda el poder controlar asıa pectos de la casa como pueden ser, la calefacci´n, persianas, puertas, electrodom´sticos, o e o incluso vigilancia. Ser´ interesante poder controlar todos estos aspectos en tiempo ıa real est´s donde est´s: desde el trabajo, desde el coche en un atasco, desde las Bahamas e e de vacaciones,etc. Es posible entonces crear un RA que controle los eventos del legacy system que maneja todos los aparatos, y MGCP para el visionado de las videoc´maras. a Figura 12.15: Servicio Dom´tica o
- 234. CAP´ ITULO 12. SERVICIOS 202 RA SIP MGCP RA Dom´tica (RA propio del sistema) o RA DIAMETER 12.8.1. Dise˜ o n Realiza lo siguiente: Las llamadas entrantes las recibe el SBB de control de llamada, que mediante la creaci´n de los diferentes SBB hijos puede controlar determinados aspectos de la o llamada. El servicio AAA le permite autentificar al llamante, asegur´ndose de que reala mente es una persona autorizada para cambiar los par´metros que desea cambiar. a Ser´ el primer paso a realizar tras la realizaci´n de la conexi´n. ıa o o Mediante el servicio de locuciones, que usa el RA MGCP, se nos permite ofrecer un men´ v´ telef´nica, para proporcionar la mayor cantidad posible de par´metros u ıa o a a configurar. Los par´metros configurables son los que nos proporciona el servicio de Dom´tica, a o que tambi´n deber´ estar conectado con alguna de las unidades l´gicas que pere ıa o miten el control de los par´metros de la casa, oficina o del recinto a controlar, a para transferirle la informaci´n y que realice las acciones necesarias para efectuar o la tarea que le hemos encomendado. Por ultimo, si se desea, se puede usar el servicio AAA para efectuar la tarificaci´n ´ o de los servicios prestados.
- 235. 12.9. SERVICIOS MULTICAST 203 Figura 12.16: Diagrama domotica 12.9. Servicios Multicast Gracias al RA Asterisk es posible crear servicios Multicast para o´ radio, discursos, ır conciertos, visitas guiadas (en museos, ciudades) y todo tipo de eventos masivos. A trav´s del tel´fono m´vil podemos implementar estos servicios mediante el multicast de e e o Asterisk y el uso de captura de eventos DTMF, gracias a los cuales se podr´ impleıa mentar una navegaci´n entre las opciones que se nos puedan dar (idiomas, lugares de o visita,etc.) utilizando el keypad. RA SIP RA Asterisk RA Media(DTMF)
- 236. CAP´ ITULO 12. SERVICIOS 204 Figura 12.17: Servicios Multicast 12.9.1. Dise˜ o n La forma de actuar de este servicio ser´ la siguiente: ıa Cuando llega una nueva llamada, el SBB del servicio de control de llamada crea el SBB del servicio Multicast. A continuaci´n le pasa el control de la llamada al SBB del servicio Multicast, que o se encarga por una parte de mantener las llamadas a m´ltiples clientes mediante u el uso del RA de Asterisk, y por otra parte, de la reproducci´n simult´nea en o a todas las llamadas del mismo stream2 de m´sica, o video en su caso. u 2 flujo continuo de datos
- 237. ´ 12.10. SERVICIOS DE LOCALIZACION 205 Figura 12.18: Diagrama multicast 12.10. Servicios de localizaci´n o Se pueden implementar un servicios de localizaci´n orientados al control de ano cianos y ni˜os, el control de trabajadores m´viles, servicios de proximidad de establecn o imientos,etc. Esto lo lograr´ ıamos f´cilmente mediante la utilizaci´n de el RA Parlay y a o cualquier ra de mensajer´ para enviar la localizaci´n. ıa o Figura 12.19: Servicios de localizaci´n o
- 238. CAP´ ITULO 12. SERVICIOS 206 RA Parlay RA MMS (por hacer) RA SMPP RA Persistence(Especializado en Bases de Datos) 12.10.1. Dise˜ o n Realiza lo siguiente: Los mensajes llegan al proxy SMPP, en caso de que sean mensajes de localizaci´n o de un numero determinado se crearan los SBBs hijos SBB Localizaci´n y SBB o MMS El servicio Localizaci´n en primer lugar comprueba que terminal tiene que loo calizar y lanza un evento para localizarlo. Mediante el RA Parlay, localiza el terminal y lanza un evento para guardar estos datos en una base de datos. Se guardan los datos en una base de datos utilizando el RA Persistence. El servicio MMS manda un mensaje MMS al terminal que realiz´ la petici´n de o o localizaci´n, con un mapa y el radio de localizaci´n de el terminal a localizar. o o Figura 12.20: Diagrama Servicio de Localizaci´n o
- 239. 12.11. SERVICIO AVISO DISPONIBILIDAD 12.11. 207 Servicio Aviso Disponibilidad Ser´ posible implementar un servicio al m´s puro estilo messenger, para indicar la ıa a disponibilidad de un usuario en un momento determinado de tiempo. En este servicio se realiza una llamada normal, pero en caso de que el llamado tenga activado alg´n u estado distinto al norma (ocupado, reunion,comiendo, durmiendo,etc.) se controlar´ la ıa llamada mediante un tercero en el cual se narrar´ un mensaje indicando el estado, y ıa la opci´n de continuar la llamada en caso de emergencia, o colgar y llamar m´s tarde o a cuando el llamado cambia su estado (el mismo servicio te manda un mensaje cuando el usuario cambia de estado, tambi´n avisar´ al usuario de la llamada realizada). e ıa Figura 12.21: Servicio Aviso Disponibilidad RA SIP RA Media RA SMPP Ra Persistence(Especializado en Bases de Datos) 12.11.1. Dise˜ o n Realiza lo siguiente: Cuando el usuario que tiene contratado el servicio de Disponibilidad recibe una llamada, el SBB Proxy crea un SBB Hijo de Disponibilidad y un SBB 3PCC para controlar la llamada. El SBB de Disponibilidad crea un SBB de Estado, que consultara el estado actual del usuario (Disponible, Ocupado, Ausente ...) Seg´n el estado y el usuario que llame, se producir´ la llamada o no. u a En caso de no producirse la llamada, el SBB de disponibilidad junto con el SBB 3PCC reproducir´ un mensaje definido por el usuario o gen´rico, informando del a e estado, dando distintas opciones que podr´n activase o desactivarse. a
- 240. CAP´ ITULO 12. SERVICIOS 208 1. Dejar un mensaje de voz 2. Recibir un mensaje cuando el usuario este disponible 3. En caso de urgencia, producir la llamada de todas formas El usuario podr´ cambiar su estado bien desde su tel´fono, o desde una p´gina a e a web. Figura 12.22: Diagrama Servicio de disponibilidad El estado podr´ sincronizarse con la agenda del usuario(m´vil, google calendar etc) ıa o para no tener que cambiar continuamente de estado, o desactivar el servicio temporalmente.
- 243. Cap´ ıtulo 13 Introducci´n o En este punto deseamos realizar un ejemplo b´sico de una serie de servicios encaa denados en Mobicents. Tomamos como base el ejemplo Call Control, que posee los servicios de Bloqueo de llamada (Blocking), Desv´ de llamada (Forwarding) y Buz´n de Voz (Voice Mail). ıo o Pretendemos modificarlo para que a˜ada la siguiente funcionalidad: n 1. Servicio de carga din´mica de los perfiles a partir de una base de datos MySQL. a 2. Servicio Advertising. 3. Guardado de las llamadas realizadas en MySQL. Este ejemplo se trata tan solo de una aproximaci´n, ya que habr´ que dise˜ar un o ıa n proxy ra´ que manejara y creara los hijos seg´n entran las peticiones de llamada. ız u 211
- 245. Cap´ ıtulo 14 Prerrequisitos 14.1. JBoss y versiones de Java Esta aplicaci´n ha sido probada con Mobicents corriendo en JBoss 3.2.6 y JBoss o 3.2.7 usando Jdk 1.4 o 1.5 Tambi´n es necesario definir las siguientes variables del sistema: e JAVA_HOME = C:jdk1.5.0_15 (o j2sdk1.4.2_10) JBOSS_HOME = C:jboss-3.2.6 MOBICENTS_EXAMPLES= C:CVSmombicents-examples 14.1.1. Dependencias 1. SIP RA 1.2 2. SIP proxy/registrar - Con invite como evento no inicial 213
- 247. Cap´ ıtulo 15 Instalar y ejecutar Lo primero de todo, copiar el proyecto call-controller de la carpeta con el ejemplo incluida en el cd. Despu´s solo tendr´s que seguir estos simples pasos: e a 1. Ejecutar el servidor run -c all -b localhost. 2. Ir al directorio %MOBICENTS EXAMPLES %lib 3. En el directorio slee-sip-ra ejecutar ant deploy 4. En el directorio sipservices a) Si es la primera vez, ejecutar ant jar-with-invite-not-initial y despu´s ant e deploy b) Ejecutar ant deploy 5. En %MOBICENTS EXAMPLES %call-controller ejecutar ant deploy 1. O simplemente ve a %MOBICENTS EXAMPLEScall-controller y ejecuta ant deploy-all - esto desplegar´ todo los descrito arriba. Este es el modo recomendado, a sin embargo, es dif´ sostener con deployent despu´s de ser disparado - la consola ıcil e imprime mucha informaci´n. Hay que tener en cuenta que despliega elementos de o la carpeta lib que se encuentra un nivel mas abajo, por lo que ser´ necesario a tenerla en el mismo directorio donde se encuentre el Call-Controller Notas: Para usar esta aplicaci´n tienes que usar localhost o tu direcci´n ip ( si est´s usano o a do una red privada) para ejecutar Mobicents. Entonces tu direcci´n ip ser´ 127.0.0.1 o a u otra ip privada como 10.30.9.213. Si vas dejar de usar el call-controller, tienes que repetir el paso 1 antes de limpiar el contenedor (ant clean-container) para tener el Proxy normal de nuevo. 215
- 248. CAP´ ITULO 15. INSTALAR Y EJECUTAR 216 15.0.1. Usando la aplicaci´n o Para comprobar que la aplicaci´n funciona usamos una base de datos con los o siguientes perfiles, que se ir´n cargando a medida que se registran los SIP Phones. a Habr´ creada una tabla de perfiles llamada “Controller“ y despu´s un perfil por cada a e usuario. Puedes ver el resultado en la tabla que se muestra a continuaci´n. o
- 249. 217 Profile Name Jose Pedro Carlos Javier Profile Table Name: Controller Blocked Addresses Backup (Address[ ]) SIP:sip [email protected] null [email protected] [email protected] null null [email protected] null [email protected] [email protected] null null Called User (Address) SIP:sip [email protected] Voice Mail State true Advertising true true false true true true true Tabla 15.1: Tabla perfiles Esta tabla de perfiles es creada usando el script zcontrollerprofile-deploy.bsh (callcontroller) o zCallControl-deploy.bsh (call-controller2) que es tambi´n usado para dee splegar la aplicaci´n. o Lo ideal ser´ usar un servidor LDAP1 desde el que obtendr´ toda la informaci´n ıa ıas o recogida en los perfiles. Debido a las complicaciones, se utilizar´ MySQL a Vas a necesitar dos clientes SIP. Puedes instalar el msn messenger y SJphone si vas a usar un solo ordenador . Por ejemplo:la direcci´n del cliente messenger ser´ o a “sip:[email protected] “ y la direcci´n del cliente SJphone ser´ “sip:[email protected] “. Adem´s, o a a tendr´s que cambiar uno de los nombres del cliente para probar todas las posibilidades. a Despu´s de ejecutar ambos clientes vamos a ver algunos casos: e 15.0.2. Blocking Si haces una llamada desde “sip:[email protected] “ o ‘sip:[email protected] “ a “sip:[email protected] “, recibir´s un mensaje FORBIDDEN. Estos es porque ha sido a creado un perfil para “jose“ en la que ambos clientes est´n bloqueados. a 15.0.3. Forwarding Si haces una llamada desde “sip:[email protected] “ a “sip:[email protected] “, y “carlos“ no se encuentra disponible, esta llamada ser´ redirigida a “sip:[email protected] “ debido a al echo de que “carlos“ como podr´s ver en la tabla de perfiles tiene la direcci´n a o “sip:[email protected] “ como direcci´n backup. o Nota: Obviamente si llamas directamente a “carlos“,y este se encuentra disponible, la llamada ser´ procesada sin ninguna redirecci´n. a o 1 Lightweight Directory Access Protocol. Es un protocolo a nivel de aplicaci´n que permite el acceso o a un servicio de directorio ordenado y distribuido para buscar diversa informaci´n en un entorno de o red.
- 250. CAP´ ITULO 15. INSTALAR Y EJECUTAR 218 15.0.4. Voicemail La idea es que cuando llamas a un usuario que no est´ bloqueado, no disponible y a no tiene ninguna direcci´n backup ser´ la hora de usar el Voice Mail. Tambi´n, si no o a e puedes consultar tu Voice Mail puedes realizar una llamada a “sip:[email protected] “ Si realizas una llamada desde “sip:[email protected] “ a cualquier otro cliente que no este disponible (ej.: “sip:[email protected] “) la persona que llama (“pedro“) recibir´ una a respuesta TEMPORARILY UNAVAILABLE. Puedes ver en la tabla de perfiles que “jose“ tiene el servicio Voice Mail habilitado, entonces si “jose“ se desconecta y despu´s le llamas, se reproducir´ un mensaje de e a voz de tu cliente SIP: “Begging recording after the tone“. El fichero ¡user¿.wav con el mensaje de voz ser´ guardado en el route configurado en el Voicemail SBB deployment a descriptor (Voicemail-sbb-jar.xml): Listado 15.1: Voicemail-sbb-jar.xml <env−e n t r y> <env−entry −name>f i l e s R o u t e</ env−entry −name> <env−entry −type>j a v a . l a n g . S t r i n g</ env−entry −type> <env−entry −v a l u e> f i l e : // C: /</ env−entry −v a l u e> </ env−e n t r y> Otras entradas de entorno usadas en la aplicaci´n Voice mail son las siguientes: o
- 251. 219 Listado 15.2: Voicemail-sbb-jar.xml <env−e n t r y> <d e s c r i p t i o n> Maximum time ( m i l i s e c o n d s ) t h e Voice Mail w i l l w a i t t o r e c e i v e a DTMF d i g i t </ d e s c r i p t i o n> <env−entry −name>waitingDTMF</ env−entry −name> <env−entry −type>j a v a . l a n g . Long</ env−entry −type> <env−entry −v a l u e>5000</ env−entry −v a l u e> </ env−e n t r y> <env−e n t r y> <d e s c r i p t i o n> Maximum time ( m i l i s e c o n d s ) w h i l e t h e Voice Mail w i l l be s t o r i n g v o i c e message from t h e SIP C l i e n t </ d e s c r i p t i o n> <env−entry −name>w a i t i n g V o i c e M e s s a g e</ env−entry −name> <env−entry −type>j a v a . l a n g . Long</ env−entry −type> <env−entry −v a l u e>60000</ env−entry −v a l u e> </ env−e n t r y> Notas: Cuando est´s hablando para guardar el mensaje de voz, puedes colgar cuando a quieras. No tienes que esperar un minuto. Cuando realizas una llamada a “sip:[email protected] “ solo tienes que seguir las instrucciones de los mensajes de voz. La aplicaci´n ha sido probado usando los siguientes clientes SIP: o ˆ MSN SIP: pero el Cliente SIP no tiene un teclado num´rico. Por lo tanto, e no puedes marcar n´meros. u ˆ X.Lite v3.0 para Windows. ˆ BOL SIP Phone 15.0.5. Advertising Advertising es un sonido publicitario que los llamadores escuchan antes que el llamado responda al tel´fono, solo en caso de que el llamador tenga contratado este servicio. e El servicio de Advertising permite a los subscritos abaratar los costes de las llamadas a costa de escuchar un mensaje publicitario. Por ejemplo si “Pedro“ llama a “Javier“, y este se encuentra disponible, durante los tonos de espera de “Pedro“ se escuchar´ una cu˜a publicitaria. ıa n
- 252. 220 CAP´ ITULO 15. INSTALAR Y EJECUTAR
- 253. Cap´ ıtulo 16 Dise˜ o n En esta secci´n vamos a ver el dise˜o del skeleton y describir el servicio en un esbozo o n general para ser capaces de empezar la implementaci´n. o Tambi´n llamado Using Shared ACI Attributes: Servicios independientes. e Cada servicio est´ d´bilmente acoplado con su antecesor y descendientes. a e Figura 16.1: Cadena de servicios. 221
- 254. ˜ CAP´ ITULO 16. DISENO 222 Figura 16.2: Slee Graph Viewer. 16.1. Sbb design Introducci´n te´rica seg´n lo considerado en using Shared ACI Attributes. En o o u este caso vamos a tener cuatro servicios independientes. Cada servicio(CallBlocking, CallForwarding, VoiceMail y FreeCalls) recibir´n los el mismo evento y lo procesar´n a a o no har´n nada, de acuerdo a lo que los servicios m´s altos en la cadena de entrega a a hicieron. Un servicio es considerado m´s alto en la cadena cuando su prioridad de a entrega es m´s alta. La prioridad tiene que estar en un rango de [127, -128]. Sin a embargo otros servicios pueden ser insertados en una cadena de servicios entre estos cuatro ya mencionados. Como puede ser alcanzado se ver´ m´s claro despu´s de usar a a e Using Shared ACI Attributes is explained. (
- 255. : se necesita un poco de paciencia) Empecemos a ver algunos aspectos del c´digo fuente. Recomiendo bajarse el c´digo o o fuente completo y leer los diferentes comentarios a los largo del c´digo para entender o lo que es explicado aqu´ te´ricamente. ı o
- 256. 16.2. CALL CONTROL SERVICES. 16.2. 223 Call Control Services. Using Shared ACI Attributes En este dise˜o no hay una root SBB. Cada servicio va a estar ligado directamente n al Activity Context com´n. El nombre de convergencia para este AC ser´ computado u a desde el CallId SIP. La idea b´sica de este dise˜o es para a˜adir/quitar servicios por a n n un camino de procesamiento de eventos. Todos los servicios menos proxy - que es un hijo del servicio forwarding tiene que tener un INVITE como evento inicial. Esto es debido a que los servicios necesitan decidir que INVITE deber´ ser permitido etc. Sin embargo el proxy actual est´ conforme ıa a al patr´n “chaining“ por lo que puede ser a˜adido como un quinto servicio. Ahora es o n mitad y mitad - el proxy es un hijo, y un servicio independiente para los eventos que no sean invite. Listado 16.1: Voicemail-sbb-jar.xml <e v e n t event−d i r e c t i o n = ‘ ‘ Receive ‘ ‘ i n i t i a l −e v e n t = ‘ ‘ True ‘ ‘> <event−name>I n v i t e</ event−name> <event−type−r e f> <event−type−name> j a v a x . s i p . message . Request . INVITE </ event−type−name> <event−type−vendor> j a v a x . s i p </ event−type−vendor> <event−type−version> 1 . 1 </ event−type−version> </ event−type−r e f> < i n i t i a l −event−s e l e c t o r −method−name> callIDSelect </ i n i t i a l −event−s e l e c t o r −method−name> </ e v e n t> 16.2.1. MySQL en nuestro ejemplo A continuaci´n describiremos los pasos realizados para obtener una versi´n funcional o o de una base de datos MySQL funcionando en nuestro sistema: 16.2.1.1. Nuestra propia base de datos: Perfiles Para nuestro ejemplo hemos decidido desarrollar una base de datos para almacenar la informaci´n referente a usuarios y llamadas. Tras la fase de dise˜o nos queda el o n siguiente diagrama Entidad-Relaci´n: o En ´l podemos observar al conjunto de entidades Users, con una clave primaria, e ID, que sirve para identificar al usuario de manera un´ ıvoca. Tambi´n observamos una e clave alternativa, username, que tambi´n identificar´ al usuario de manera unica, pero e ıa ´ debido a su mayor complejidad a la hora de realizar las b´squedas, decidimos escoger u
- 257. 224 ˜ CAP´ ITULO 16. DISENO Figura 16.3: Diagrama Entidad Relaci´n o ID como la clave primaria. Dicho conjunto de entidades tiene una serie de atributos, como forwarding, en caso de que se quiera efectuar un desv´ de llamadas, y dos variıo ables booleanas (Voicemail y Advertising) para saber si en un momento determinado se tienen activadas dichas opciones. As´ mismo observamos un atributo multivalorado, ı Blocked, que nos indica si un usuario tiene bloqueadas las llamadas provenientes de otro. El conjunto de relaciones Calls, que relaciona a unos usuarios con otros, tiene varios atributos. Entre ellos el usuario que origina la llamada, Source, el que la recibe, Destiny, y la hora de inicio de la llamada, InitTime. Estos tres campos conforman la clave primaria de dicho conjunto de relaciones, ya que son el conjunto m´ ınimo que permiten identificar a una llamada. Adem´s de estos campos, tambi´n dispone de los a e atributos EndTime, para informarnos sobre la duraci´n de la llamada al compararlo o con InitTime, y un campo booleano Advertising, para indicarnos si el usuario emisor, Source, ten´ o no activado el servicio de Advertising a la hora de efectuar la llamada. ıa A la hora de reducir el esquema entidad relaci´n al esquema relacional nos salen 3 o tablas con relaciones entre ellas. En las tablas Calls y Users se almacena la informaci´n relativa a llamadas y a o usuarios respectivamente, relacionando las claves ajenas Source y Destiny de la tabla Calls con la clave primaria, id, de la tabla Users. Ambas tablas provienen de la reducci´n de los dichos conjuntos de entidades y relaciones. Sin embargo, la nueva tabla que o aparece, Blocking, con tan s´lo dos campos, Blocker y Blocked, proviene de la reduco ci´n al esquema relacional del atributo multivalorado Blocked. En dicha tabla, los dos o campos que aparecen forman una clave primaria m´ltiple. Ambos campos son claves u ajenas, provenientes de la tabla Users.
- 258. 16.2. CALL CONTROL SERVICES. 225 Figura 16.4: Tablas A continuaci´n est´ el c´digo utilizado para crear la base de datos en MySQL: o a o Listado 16.2: Creaci´n de la base de datos o c r e a t e database a d v e r t i s i n g ; use a d v e r t i s i n g ; La primera instrucci´n sirve para crear la base de datos en s´ Con la segunda, le o ı. decimos a SGBD MySQL la base de datos concreta sobre la que realizar´ las operaciones a a partir de ese momento. A continuaci´n tenemos las instrucciones para la creaci´n de las tablas. La opci´n de o o o engine=innodb le indica a MySQL que se van a realizar comprobaciones de integridad referencial al insertar, modificar y eliminar registros de la base de datos. Listado 16.3: Construcci´n de las tablas o create table users ( i d i n t primary key a u t o i n c r e m e n t , username v a r c h a r ( 5 0 ) , Forwarding v a r c h a r ( 5 0 ) , V o i c e M a i l Boolean d e f a u l t f a l s e , A d v e r t i s i n g b o o l e a n d e f a u l t f a l s e ) e n g i n e=innodb ; create table Calls ( S o u r c e i n t not n u l l , D e s t i n y i n t not n u l l , I n i t T i m e Datetime not n u l l , EndTime Datetime not n u l l , Advertising boolean d e f a u l t f a l s e , C o n s t r a i n t f o r e i g n key ( s o u r c e ) r e f e r e n c e s u s e r s ( i d ) , primary key ( s o u r c e , d e s t i n y , i n i t T i m e ) ) e n g i n e = innodb ; create table blocking ( blocker int , blocked int , primary key ( b l o c k e r , b l o c k e d ) , c o n s t r a i n t f o r e i g n key ( b l o c k e r ) r e f e r e n c e s u s e r s ( i d ) , c o n s t r a i n t f o r e i g n key ( b l o c k e d ) r e f e r e n c e s u s e r s ( i d ) ) e n g i n e = innodb ;
- 259. ˜ CAP´ ITULO 16. DISENO 226 Habiendo realizado esto, las instrucciones para insertar nuevos usuarios en la base de datos, las primeras que debemos hacer para que se cumplan las condiciones que nos permitan insertar objetos en las otras tablas, son de forma similar a la siguiente: Listado 16.4: Inserci´n de un usuario o INSERT INTO U s e r s VALUES ( n u l l , ’USERNAME ’ , ’FORWARDING ’ , false , true ) ; El primer null que va en la posici´n del id le indica a la base de datos que ha o de seguir usando la numeraci´n por defecto. El resto son solo los valores que ir´ en o ıan cualquier campo. Naturalmente habr´ que sustituir USERNAME y FORWARDING ıa por los nombres de usuario correspondientes. En el programa se implementa mediante la funci´n newUser();. o Cuando lo que deseamos insertar son bloqueos entre 2 usuarios, se deben insertar siguiendo el siguiente esquema: Listado 16.5: Inserci´n de un bloqueo o INSERT INTO b l o c k i n g v a l u e s (#BLOCKED, # BLOCKED) ; donde #BLOCKER es el identificador del usuario que va a establecer el bloqueo y #BLOCKED es el identificador del usuario bloqueado. Para establecer un bloqueo, dichos identificadores han de aparecer asociados a un usuario en la tabla correspondiente. En el servicio se puede usar la funci´n setBlocking();. o Si lo que queremos insertar es una llamada entre 2 participantes, debemos insertarla de la siguiente manera: Listado 16.6: Inserci´n de un bloqueo o INSERT INTO c a l l s v a l u e s ( 1 5 , 1 6 , "2007 -05 -16 18:21:22 " , "2007 -05 -16 18:21:22 " , t r u e ) ; El primer y el segundo campo nos indican el id del emisor y el receptor de la llamada respectivamente. El tercero y el cuarto nos indican las horas de comienzo y fin de la comunicaci´n, y el ultimo nos indica si el usuario emisor dispon´ del servicio o ´ ıa Advertising durante esta llamada. Se implementa mediante setCall();. La hora actual se puede obtener invocando a la funci´n getCurrentDateTime();. o Mediante estas instrucciones se efect´an las operaciones b´sicas necesarias para el u a funcionamiento de la carga din´mica de los perfiles a 16.2.2. Carga de perfiles La carga de los perfiles se realiza de forma din´mica. Una vez el SIP phone, trata a de registrarse, se capta el evento de registro y se comprueba en la base de datos que el usuario esta subscrito. En caso afirmativo se devuelve el perfil del usuario y se procede a registrarlo, y en caso negativo se le env´ como respuesta un mensaje de No ıa Autorizado. Este servicio es el primero que se ejecuta en CallControl, y tiene por lo tanto la prioridad m´s alta. Se trata de un servicio, que se ejecuta siempre, es decir que no tiene a ning´n ancestro que lo filtre, pero tambi´n no filtra a ning´n predecesor. u e u
- 260. 16.2. CALL CONTROL SERVICES. 227 La carga de perfiles se realiza mediante el siguiente procedimiento que se encuentra en dentro de SubscriptionProfileSbb.java: Listado 16.7: Preparar el endpoint public void n e w P r o f i l e ( S t r i n g p r o f i l e T a b l e N a m e , S t r i n g p r o f i l e N a m e , S t r i n g c a l l e e , Address [ ] block , Address backup , boolean s t a t e , boolean s t a t e 2 , f l o a t i n i t i a l B i l l ) throws E x c e p t i o n { H a s h t a b l e env = new H a s h t a b l e ( ) ; env . put ( ” j a v a . naming . f a c t o r y . i n i t i a l ” , ” o r g . jnp . i n t e r f a c e s . NamingContextFactory ” ) ; env . put ( ” j a v a . naming . p r o v i d e r . u r l ” , ” jnp : / / l o c a l h o s t : 1 0 9 9 ” ) ; env . put ( ” j a v a . naming . f a c t o r y . u r l . pkgs ” , ” o r g . j b o s s . naming : o r g . jnp . i n t e r f a c e s ” ) ; RMIAdaptor a da p t o r =(RMIAdaptor ) new I n i t i a l C o n t e x t ( env ) . lookup ( ”jmx/ rmi /RMIAdaptor” ) ; ; S l e e B e a n S h e l l U t i l s l e e = new S l e e B e a n S h e l l U t i l ( ) ; Address u s e r A d d r e s s = null ; Address [ ] b l o c k e d A d d r e s s e s = new Address [ 2 ] ; Address backupAddress = null ; ObjectName p r o f i l e O b j e c t N a m e = ( ObjectName ) s l e e . c r e a t e P r o f i l e ( profileTableName , profileName ) ; System . out . p r i n t l n ( ” *** A d d r e s s P r o f i l e ” + p r o f i l e N a m e + ” created : ” + profileObjectName ) ; i f ( ! ( Boolean ) a d a p t o r . g e t A t t r i b u t e ( p r o f i l e O b j e c t N a m e , ” ProfileWriteable ” )) { Object [ ] o = new Object [ ] { } ; a d a pt o r . i n v o k e ( p r o f i l e O b j e c t N a m e , ” e d i t P r o f i l e ” , o , new S t r i n g [ ] { } ) ; System . out . p r i n t l n ( ” *** Configurando e l p e r f i l . ” ) ; } else { System . out . p r i n t l n ( ” ********* P r o f i l e e s e d i t a b l e . ” ) ; } // S e t t i n g and Committing u s e r A d d r e s s = new Address ( AddressPlan . SIP , c a l l e e ) ; A t t r i b u t e u s e r A t t r = new A t t r i b u t e ( ” UserAddress ” , u s e r A d d r e s s ) ; A t t r i b u t e b l o c k e d A t t r = new Attribute ( ” BlockedAddresses ” , block ) ; A t t r i b u t e backupAttr = new A t t r i b u t e ( ” BackupAddress ” , backup ) ; A t t r i b u t e v o i c e m a i l A t t r = new Attribute (” VoicemailState ” , state ) ; A t t r i b u t e a d v e r t i s i n g A t t r = new Attribute (” AdvertisingState ” , state2 ) ;
- 261. ˜ CAP´ ITULO 16. DISENO 228 A t t r i b u t e b i l l A t t r = new Attribute (” B i l l ” , i n i t i a l B i l l ) ; a d a pt o r . a d a pt o r . a d a pt o r . a d a pt o r . a d a pt o r . a d a pt o r . s e t A t t r i b u t e ( profileObjectName s e t A t t r i b u t e ( profileObjectName s e t A t t r i b u t e ( profileObjectName s e t A t t r i b u t e ( profileObjectName s e t A t t r i b u t e ( profileObjectName s e t A t t r i b u t e ( profileObjectName , , , , , , userAttr ) ; blockedAttr ) ; backupAttr ) ; voicemailAttr ) ; advertisingAttr ); billAttr ); System . out . p r i n t l n ( ” *** M o d i f i c a c i ´ n t o d a v´a o ı no r e a l i z a d a . ” ) ; a d a pt o r . i n v o k e ( p r o f i l e O b j e c t N a m e , ” c o m m i t P r o f i l e ” , new Object [ ] { } ,new S t r i n g [ ] { } ) ; System . out . p r i n t l n ( ” *** M o d i f i c a c i ´ n r e a l i z a d a . ” ) ; o } El evento para manejar el Registro, se define en el sbb-jar.xml, de la siguiente forma: Listado 16.8: Preparar el endpoint <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True"> <event−name>R e g i s t e r</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . message . Request . REGISTER </ event−type−name> <event−type−vendor>j a v a x . s i p</ event−type−vendor> <event−type−version>1 . 1</ event−type−version> </ event−type−r e f> < i n i t i a l −event−s e l e c t o r −method−name>c a l l I D S e l e c t </ i n i t i a l −event−s e l e c t o r −method−name> </ e v e n t>
- 262. 16.2. CALL CONTROL SERVICES. La l´gica dentro de onRegister, es la siguiente: o Listado 16.9: Preparar el endpoint public void o n R e g i s t e r ( j a v a x . s i p . RequestEvent event , PHandleSbbActivityContextInterface localAci ) { Request r e q u e s t = e v e n t . g e t R e q u e s t ( ) ; try { l o c a l A c i . detach ( this . getSbbLocalObject ( ) ) ; // Obtengo l a d i r e c c i ´ n URI d e l l l a m a d o r o FromHeader fromHeader = ( FromHeader ) r e q u e s t . getHeader ( FromHeader .NAME) ; // From URI URI fromURI = fromHeader . g e t A d d r e s s ( ) . getURI ( ) ; // El p u e r t o no s e usa en e l p r o f i l e ( ( SipURI ) fromURI ) . removePort ( ) ; // Compruebo que no e s t e r e g i s t r a d o ya i f ( ! i s R e g i s t e r ( fromURI . t o S t r i n g ( ) ) ) { //Comprobamos que e x i s t e e l u s u a r i o en l a b a s e de d a t o s boolean e x i s t A=e x i s t i n g U s e r ( fromURI . t o S t r i n g ( ) ) ; i f ( existA ) { // Obtenemos l o s d a t o s d e l p e r f i l S t r i n g [ ] Campos=g e t U s e r ( fromURI . t o S t r i n g ( ) ) ; // Obtenemos l a d i r e c c i ´ n de f o r w a r d i n g o Address Backup ; i f ( Campos [ 1 ] ! = ” ” ) { Backup=new Address ( AddressPlan . SIP , Campos [ 1 ] ) ; } else { Backup=null ; } //Comprobamos que e s t a s u b s c r i t o a a d v e r t i s i n g boolean adv ; i f ( Campos[2]== ” t r u e ” ) { adv=true ; } else { adv=f a l s e ; } 229
- 263. ˜ CAP´ ITULO 16. DISENO 230 //Comprobamos s i e s t a s u b s c r i t o a V o i c e m a i l boolean voicem ; i f ( Campos[3]== ” t r u e ” ) { voicem=true ; } else { voicem=f a l s e ; } // Formateamos e l nombre de manera adecuada S t r i n g [ ] nombre= Campos [ 0 ] . s u b s t r i n g ( 4 ) . s p l i t ( ”@” ) ; // Averiguamos l a s d i r e c c i o n e s b l o q u e a d a s S t r i n g [ ] B l o c k s=b l o c k i n g s ( Campos [ 0 ] ) ; i f ( B l o c k s != null ) { // Pasamos l a s d i r e c c i o n e s b l o q u e a d a s a l formato c o r r e c t o int l e n=B l o c k s . l e n g t h ; l o g . i n f o ( ” l o n g i t u d ”+l e n ) ; Address [ ] b l o c k A d d r e s s=null ; for ( int i =0; i <l e n ; i ++) { b l o c k A d d r e s s [ i ]=new Address ( AddressPlan . SIP , Blocks [ i ] ) ; } // Cargamos e l p e r f i l con d i r e c c i o n e s de b l o q u e o n e w P r o f i l e ( ” C a l l C o n t r o l ” , nombre [ 0 ] , Campos [ 0 ] , bl oc kA ddr e s s , Backup , voicem , adv , 0 ) ; } else { // Cargamos e l p e r f i l s i n d i r e c c i o n e s de b l o q u e o n e w P r o f i l e ( ” C a l l C o n t r o l ” , nombre [ 0 ] , Campos [ 0 ] , null , Backup , voicem , adv , 0 ) ; } } else { // N o t i f i c a m o s a l l l a m a d o r que no s e e n c u e n t r a r e g i s t r a d o ServerTransaction stRegister = ( ServerTransaction ) localAci . getActivity ( ) ; Response r e g i s t e r R e s p o n s e = g e t M e s s a g e F a c t o r y ( ) . c r e a t e R e s p o n s e ( Response .UNAUTHORIZED, r e q u e s t ) ; s t R e g i s t e r . sendResponse ( r e g i s t e r R e s p o n s e ) ; } } } catch . . . .
- 264. 16.2. CALL CONTROL SERVICES. } Este c´digo realiza los siguientes pasos: o 1. Se capta el request del evento para averiguar el URI del llamador 2. Se comprueba que no este registrado ya 3. Se comprueba que este subscrito, es decir que este en la base de datos 4. Se recupera su perfil de la base de datos 5. Se convierte el perfil en los tipos de datos adecuados 6. Se agrega el perfil a la Tabla de Perfiles creada anteriormente. 231
- 265. ˜ CAP´ ITULO 16. DISENO 232 16.2.3. CallBlockingSBB En nuestro escenario este SBB es el primero que procesa el evento INVITE. Deber´ ıa tener la prioridad m´s alta de todos los servicios de este ejemplo. La tarea b´sica de a a este SBB es comprobar si el usuario que llama est´ o no bloqueado por el otro usuario a que recibe la llamada. Si lo est´, tiene que bloquear el procesamiento y responder al a usuario que llama de un modo apropiado. 16.2.4. Advertising En t´rminos de protocolo de se˜ales SIP el controlador debe captar el mensaje Ringe n ing y establecer una session media interviniente en la llamada, y una pasarela media que reproducir´ los archivos de sonido. Cuando el llamado responda, el controlador a de llamada deber´ dejar esta sesi´n media y establecer la llamada. Vamos a usar el a o MGCP RA para crear la sesi´n media. Todos los comandos MGCP son ejecutados por o endpoints. Esto significa que el desarrollador debe saber la configuraci´n de la pasarela o media que va a usar. Para esta aplicaci´n las caracter´ o ısticas de los endpoints declarativas son suficientes. MGCP asume que el nombre del endpoint consiste de dos partes: nombre local y nombre de dominio. El nombre local es el nombre del endpoint dentro de la pasarela media y es lo mismo que el nombre Mbean para nosotros. El nombre de dominio puede ser un nombre host o direcci´n ip, se puede incluir el puerto. Esta o parte de los nombres de endpoints se usa por el proveedor de MGCP para entregar los mensajes a la pasarela. Para aplicaciones PRBT no hay una manera concreta para que los endpoints ejecuten commandos, as´ que el nombre del endpoint para el primer mensaje CreateConı nection puede ser wildcarded. No podemos usar todos los s´ ımbolos wildcard, pero si algunos. La pasarela determinara el endpoint apropiado para ejecutar el CreateConnection y este retornara un nombre de endpoint concreto en la respuesta
- 266. 16.2. CALL CONTROL SERVICES. 233 En un primer lugar tendremos que definir los eventos a manejar en su descriptor sbb-jar.xml asociado: Listado 16.10: Eventos de Advertising <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True"> <event−name>RingningEvent</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . message . Response .INFORMATIONAL</ event−type−name> <event−type−vendor>j a v a x . s i p</ event−type−vendor> <event−type−version>1 . 1</ event−type−version> </ event−type−r e f> </ e v e n t> <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t=" False "> <event−name>CreateConnectionResp</ event−name> <event−type−r e f> <event−type−name>j a i n . p r o t o c o l . i p . mgcp . message .CREATE CONNECTION RESPONSE</ event−type−name> <event−type−vendor>n e t . j a v a</ event−type−vendor> <event−type−version>1 . 0</ event−type−version> </ event−type−r e f> </ e v e n t> <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t=" False "> <event−name>OkEvent</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . message . Response . SUCCESS</ event−type−name> <event−type−vendor>j a v a x . s i p</ event−type−vendor> <event−type−version>1 . 1</ event−type−version> </ event−type−r e f> </ e v e n t>
- 267. ˜ CAP´ ITULO 16. DISENO 234 Tambi´n tenemos que definir en este mismo descriptor, el acople con los RAs que e va a utilizar, en este caso con SIP y MGCP: Listado 16.11: RAs adjuntos <r e s o u r c e −adaptor−type−b i n d i n g> <r e s o u r c e −adaptor−type−r e f> <r e s o u r c e −adaptor−type−name>j a i n −s i p </ r e s o u r c e −adaptor−type−name> <r e s o u r c e −adaptor−type−vendor>j a v a x . s i p </ r e s o u r c e −adaptor−type−vendor> <r e s o u r c e −adaptor−type−version>1 . 1 </ r e s o u r c e −adaptor−type−version> </ r e s o u r c e −adaptor−type−r e f> <a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −name> s l e e / resources / j a i n s i p /1.1/ a c i f a c t o r y </ a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −name> <r e s o u r c e −adaptor−e n t i t y −b i n d i n g> <r e s o u r c e −adaptor−o b j e c t −name> s l e e / resources / j a i n s i p /1.1/ provider </ r e s o u r c e −adaptor−o b j e c t −name> <r e s o u r c e −adaptor−e n t i t y −l i n k>SipRA </ r e s o u r c e −adaptor−e n t i t y −l i n k> </ r e s o u r c e −adaptor−e n t i t y −b i n d i n g> </ r e s o u r c e −adaptor−type−b i n d i n g> <r e s o u r c e −adaptor−type−b i n d i n g> <r e s o u r c e −adaptor−type−r e f> <r e s o u r c e −adaptor−type−name>j a i n −mgcp </ r e s o u r c e −adaptor−type−name> <r e s o u r c e −adaptor−type−vendor>n e t . j a v a </ r e s o u r c e −adaptor−type−vendor> <r e s o u r c e −adaptor−type−version>1 . 0 </ r e s o u r c e −adaptor−type−version> </ r e s o u r c e −adaptor−type−r e f> <a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −name> s l e e / r e s o u r c e s / jainmgcp / 1 . 0 / a c i f a c t o r y </ a c t i v i t y −c o n t e x t −i n t e r f a c e −f a c t o r y −name> <r e s o u r c e −adaptor−e n t i t y −b i n d i n g> <r e s o u r c e −adaptor−o b j e c t −name> s l e e / r e s o u r c e s / jainmgcp / 1 . 0 / p r o v i d e r </ r e s o u r c e −adaptor−o b j e c t −name> <r e s o u r c e −adaptor−e n t i t y −l i n k>MGCP −CSCF </ r e s o u r c e −adaptor−e n t i t y −l i n k> </ r e s o u r c e −adaptor−e n t i t y −b i n d i n g> </ r e s o u r c e −adaptor−type−b i n d i n g>
- 268. 16.2. CALL CONTROL SERVICES. 235 A continuaci´n comenzamos a definir la l´gica del SBB: o o Listado 16.12: Preparar el endpoint public void onRingningEvent ( RequestEvent event , ActivityContextInterface aci ) { .... // P r e p a r a r mgcp para c r e a r l a c o n e x i o n E n d p o i n t I d e n t i f i e r e n d p o i n t = new E n d p o i n t I d e n t i f i e r ( ”ann/ $ ” , ” mediagateway . m o b i c e n t s . o r g ” ) ; } Hay objetos activity declarados para el MGCP RA. Estos objetos pueden usarse para crear un ActivityContextInterface. Obtener el ActivityContextInterfaceFactory y adjuntar este SBB para recibir respuestas Listado 16.13: Declarar objetos public void onRingningEvent ( RequestEvent event , ActivityContextInterface aci ) { C a l l c a l l = new C a l l ( c a l l I d H e a d e r ) ; // a c t i v i t y o b j e c t C a l l I d e n t i f i e r c a l l I d e n t i f i e r = new C a l l I d e n t i f i e r ( c a l l . getID ( ) ) ; ActivityContextInerfaceFactory a c i f = ( ActivityConextInterfaceFactory ) c o n t e x t . lookup ( ” s l e e / r e s o u r c e s /mgcp / ActivityContextInterface ” ); A c t i v i t y C o n t e x t I n t e r f a c e ac = acif . getActivityContextInterfface ( call ); ac . a t t a c h ( t h i s ) } Preparar el mensaje CreateConnection: provee del descriptor de session del llamador y llamante, presente en el mensaje Invite, y crea el evento request para la pasarela media gateway con instrucciones de reproducir un archivo de la URL especifica y notificar inmediatamente cuando esta reproducci´n haya acabado. Entonces obtiene el objeto o proveedor y manda el mensaje a la pasarela
- 269. ˜ CAP´ ITULO 16. DISENO 236 Listado 16.14: Preparar la conexi´n o public void onRingningEvent ( RequestEvent event , ActivityContextInterface aci ) { .... C o n n e c t i o n D e s c r i p t o r d e s c = new C o n n e c t i o n D e s c r i p t o r ( sdp ) ; try { createConnection . setRemoteConnectionDescriptor ( desc ) ; } catch ( C o n f l i c t i n g P a r a m e t e r E x c e p t i o n e ) { // no t e n d r´a que p a s a r nunca ı } EventName eventName = new EventName ( PackageName . Announcement , MgcpEvent . ann . withParm ( ” h t t p : / / u s e r . domain . com / P u b l i c i d a d . wav” ) ) ; RequestedEvent e v e n t = new RequestedEvent ( eventName , new RequestedAc tion [ ] { RequestedAc t ion . N o t i f y I m m e d i a t e l y } ) ; NotificationRequestParms request = new N o t i f i c a t i o n R e q u e s t P a r m s ( new R e q u e s t I d e n t i f i e r ( I n t e g e r . t o S t r i n g (GEN++))); r e q u e s t . s e t R e q u e s t e d E v e n t s (new RequestedEvent [ ] { e v e n t } ) ; createConnection . setNotificationRequestParms ( request ) ; JainMgcpProvider p r o v i d e r = ( JainMgcpProvider ) c o n t e x t . lookup ( ” s l e e / r e s o u r c e s /mgcp/ f a c t o r y p r o v i d e r ” ) ; p r o v i d e r . send (new JainMgcpCommand [ ] { c r e a t e C o n n e c t i o n } ) ; } La pasarela responder´ con el mensaje CreateConnectionResponse el cual incluir´ un a a nombre concreto para el endpoint adquirido por la pasarela, el identificador de la conexi´n creada y un descriptor de session local (para esta conexi´n). Deber´ o o ıamos usar este descriptor de sesi´n en el mensaje SIP SESSION PROGRESS para establecer o la sesi´n media. o Listado 16.15: Crear la conexi´n o public void onCreateConnectionResp ( JainMgcpResponseEvent evt , ActivityContextInterface aci ) { .... CreateConnectionResponse r e s = ( CreateConnectionResponse ) evt ; S t r i n g sdp = r e s . g e t L o c a l C o n n e c t i o n D e s c r i p t o r ( ) . t o S t r i n g ( ) ; // h o l d e s p e c i f i c a parame tro s para f u t u r o s u s o s Endpoint e n d p o i n t = r e s . g e t S p e c i f i c E n d p o i n t I d e n t i f i e r ( ) ; C o n n e c t i o n I d e n t i f i e r connectionID = res . getConnectionIdentifier ( ) ; }
- 270. 16.2. CALL CONTROL SERVICES. 237 En este momento el llamador oye la publicidad y el llamado oye el tel´fono alere tando de una llamada. Cuando la publicidad finaliza, la pasarela enviara un mensaje de notificaci´n (como petici´n), este evento debe ser usado para repetir la publicidad o o desde el principio o enviar el ring t´ ıpico si algo falla Listado 16.16: Volver a reproducir public void o n N o t i f y ( JainMgcpCommandEvent evt , ActivityContextInterface aci ) { .... Notify n o t i f y = ( Notify ) evt ; eventName = n o t i f y . getObse rve dEvents ( ) [ 0 ] ; i f ( eventName . g e t E v e n t I d e n t i f i e r ( ) . e q u a l s ( MgcpEvent . o f ) ) { // s i f a l l a a l o i r e l a r c h i v o // g e n e r a un mensaje R ing in } e l s e i f ( eventName . g e t E v e n t I d e n t i f i e r ( ) . e q u a l s ( MgcpEvent . o f ) ) { // e n v´a N o t i f y R e q u e s t para o´ r e l a r c h i v o o t r a vez ı ı EventName eventName = new EventName ( PackageName . Announcement , MgcpEvent . ann . withParm ( ” h t t p : / / u s e r . domain . com/ p u b l i c i d a d . wav” ) ) ; RequestedEvent e v e n t = new RequestedEvent ( eventName , new Reque s te dAc t ion [ ] { Reque s te dAc t ion . N o t i f y I m m e d i a t e l y } ) ; N o t i f i c a t i o n R e q u e s t r e q = new N o t i f i c a t i o n R e q u e s t ( this , endpoint , new R e q u e s t I d e n t i f i e r ( new I n t e g e r (GEN++). t o S t r i n g ( ) ) ; r e q . s e t R e q u e s t e d E v e n t s ( RequestedEvent [ ] { e v e n t } ) ; p r o v i d e r . send (new JainMgcpCommandEvent [ ] { r e q } ) ; .. } } Cuando el llamado responde, el SBB tiene que manejar el OK y dejar la session media Listado 16.17: -sbb-jar.xml public void onOkEvent ( RequestEvent event , ActivityContextInterface aci ) { .... D e l e t e C o n n e c t i o n dc = new D e l e t e C o n n e c t i o n ( this , e n d p o i n t ) ; p r o v i d e r . send (new JainMgcpCommandEvent [ ] { dc } ) ; } Comentar que este c´digo no ha sido probado por la falta de tiempo para utilizar o el RA MGCP, ya que su versi´n funcional sali´ una semanas antes a la entrega de la o o memoria.
- 271. ˜ CAP´ ITULO 16. DISENO 238 16.2.5. CallForwardingSBB En este caso el SBB est´ en el medio. Su prioridad de entrega del evento est´ entre a a el FreeCall y el VoiceMailSBB. El SBB Call Forwarding SBB tiene que comprobar si un evento ha sido procesado por su antecesor. Si no es as´ podr´ procesarlo, de otro ı, a modo tiene que marcar el evento como procesado (leer forward). La l´gica de proceso o es sencilla: Si el usuario est´ disponible, lo conecta al proxy SIP (SBB hijo) al actual ACI y a le deja hablar. Si el usuario no est´ disponible y tiene alguna direcci´n backup desv´ la a o ıa llamada del usuario que llama a la direcci´n backup. o Si el usuario no est´ disponible y no tiene ninguna direcci´n backup no hace a o nada. El SBB Call Forwarding declara sus hijos (
- 272. - mira los valores de sbb-ref y sbbalias*):
- 273. 16.2. CALL CONTROL SERVICES. 239 Listado 16.18: Forwarding-sbb-jar.xml <sbb−j a r > <sbb> <d e s c r i p t i o n /> <sbb−name>CallForwardingSbb </sbb−name> <sbb−vendor>o r g . mobicents </sbb−vendor> <sbb−v e r s i o n >0.1</sbb−v e r s i o n > ..... <sbb−r e f > <sbb−name>ProxySbb</sbb−name> <sbb−vendor>NIST</sbb−vendor> <sbb−v e r s i o n >1.0</sbb−v e r s i o n > <sbb−a l i a s >JainSipProxySbb </sbb−a l i a s > </sbb−r e f > ....... <sbb−abstract−c la ss > <sbb−abstract−c l a s s −name> o r g . m o bic e nt s . s l e e . examples . c a l l c o n t r o l . f o r w a r d i n g . CallForwardingSbb </sbb−abstract−c l a s s −name> <get−c h i l d −r e l a t i o n −method> <sbb−a l i a s −r e f >JainSipProxySbb </sbb−a l i a s −r e f > <get−c h i l d −r e l a t i o n −method−name> getJainSipProxySbb </get−c h i l d −r e l a t i o n −method−name> <default−p r i o r i t y >0</default−p r i o r i t y > </get−c h i l d −r e l a t i o n −method> ...... </sbb−c l a s s e s > .... </sbb> </sbb−j a r > 16.2.6. VoiceMailSBB Este SBB va a ser el ultimo en la cadena de procesado de nuestro escenario. ´ Request has been processed -¿do nothing. Otherwise: Voice Mail disabled: CLIENT ERROR (TEMPORARILY UNAVAILABLE - 480). Voice Mail enabled: the SBB will transmit an audio file to the user who made the call. 16.2.7. Inicio y fin de llamada Nuestro prop´sito es guardar los registros de llamada en la base de datos, los datos o a guardar son los siguientes:
- 274. ˜ CAP´ ITULO 16. DISENO 240 Source: Entero que identifica al usuario que realiza la llamada Destiny: Entero que identifica al usuario que recibi´ la llamada o initTime: Fecha y Hora de inicio de la llamada endTime: Fecha y Hora de fin de la llamada Advertising: Booleano que contiene si esa llamada se hizo utilizando advertising Con estos datos es posible calcular la factura de un individuo offline, de manera que no se altera el flujo de ejecuci´n de los servicios con c´lculos que puedan retrasarlos. o a Todo el c´digo que se mostrar´ a continuaci´n deber´ estar incluido dentro del o a o ıa ProxySBB que controla las distintas llamadas. Dentro del SBB de forwarding, en caso de que se pueda realizar la llamada, se crea un hijo dentro del ProxySBB por cada llamada realizada. Y las ocurrencias que se generen a partir de entonces derivadas de tales llamadas ser´n manejadas dentro de el ProxySBB. a El problema es que en estos momentos el c´digo fuente de el Proxy usado en Callo Control no se encuentra disponible, as´ que habr´ que crearlo de nuevo a partir de ı ıa uno base. Por problemas de tiempo en nuestro caso no lo hemos podido llevar a cabo, as´ que tan solo vamos a indicar como se realizar´ y que eventos entrar´ en juego ı ıa ıan para llevar a cabo la labor de guardar las llamadas. Como siempre en estos casos vamos a tener que definir los eventos a manejar dentro de la l´gica del SBB, en nuestro caso utilizaremos el evento ACK para captar el o inicio de la llamada, y TerminationRequest para el final, los participantes y el valor de Advertising del llamador:
- 275. 16.2. CALL CONTROL SERVICES. 241 Listado 16.19: Eventos de Registro de llamadas ... <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t=" False "> <event−name>AckEvent</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . d i a l o g . Request .ACK </ event−type−name> <event−type−vendor>n e t . j a v a</ event−type−vendor> <event−type−version>1 . 2</ event−type−version> </ event−type−r e f> </ e v e n t> <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t=" False "> <event−name>ByeEvent</ event−name> <event−type−r e f> <event−type−name>j a v a x . s i p . d i a l o g . TerminationRequest </ event−type−name> <event−type−vendor>n e t . j a v a</ event−type−vendor> <event−type−version>1 . 2</ event−type−version> </ event−type−r e f> </ e v e n t> Pretendemos realizar la inserci´n al final de la llamada, por lo que necesitamos un o campo persistente que guarde el inicio de la llamada para su posterior recuperaci´n: o Listado 16.20: Campo CMP para el inicio de la llamada <cmp− f i e l d> <cmp−f i e l d −name>t i e m p o I n i c i o</cmp−f i e l d −name> </cmp− f i e l d> Dentro de la l´gica del SBB definir´ o ıamos este campo como: Listado 16.21: Definici´n campo CMP o // ’ t i e m p o I n i c i o ’ CMP f i e l d s e t t e r public abstract void s e t t i e m p o I n i c i o ( s t r i n g v a l u e ) ; // ’ t i e m p o I n i c i o ’ CMP f i e l d g e t t e r public abstract S t r i n g g e t t i e m p o I n i c i o ( ) ; A continuaci´n se muestra como seria la l´gica del manejador del evento Ack para o o captar la hora de inicio de la llamada:
- 276. ˜ CAP´ ITULO 16. DISENO 242 Listado 16.22: Evento ACK public void onAckEvent ( j a v a x . s i p . RequestEvent event , ActivityContextInterface aci ) { mediaSession = this . getMediaSession ( ) ; try { s e t t i e m p o I n i c i o ( getCurrentDateTime ( ) ) ; } ... } Por ultimo el dise˜o del manejador del evento TerminatedRequest, en el cual tenn emos que captar el captar la hora de fin de la llamada, el llamante, el llamado, si el llamante tiene contratado advertising, recuperar el dato de hora de inicio de la llamada y realizar la inserci´n de la base de datos: o Listado 16.23: Evento BYE public void onByeEvent ( RequestEvent event , ActivityContextInterface aci ) { try { l o c a l A c i . detach ( this . getSbbLocalObject ( ) ) ; // Capto e l r e q u e s t para r e c u p e r a r e l l l a m a d o r y llamado Request r e q u e s t = e v e n t . g e t R e q u e s t ( ) ; FromHeader fromHeader = ( FromHeader ) r e q u e s t . getHeader ( FromHeader .NAME) ; ToHeader toHeader = ( ToHeader ) r e q u e s t . getHeader ( ToHeader .NAME) ; // URI d e l l l a m a d o r URI fromURI = fromHeader . g e t A d d r e s s ( ) . getURI ( ) ; // URI d e l llamado URI toURI = toHeader . g e t A d d r e s s ( ) . getURI ( ) ; // Recupero l o s I d s d e l l l a m a d o r y e l llamado int I D C a l l e r=getID ( fromURI . t o S t r i n g ( ) ) ; int I D C a l l e e=getID ( toURI . t o S t r i n g ( ) ) ; // Ahora vamos a r e c u p e r a r e l s i e l l l a m a d o r t i e n e // A d v e r t i s i n g a c t i v a d o boolean i s S u b s c r i b e r = i s A d v e r t i s i n g ( u r i . fromURI ( ) ) ; // I n s e r t a m o s en l a b a s e de d a t o s l a llamada boolean s u c c e s= s e t C a l l ( I D C a l l e r , I DC a l l e e , g e t T i e m p o I n i c i o ( ) , getCurrentDateTime ( ) , i s S u b s c r i b e r ) ; a c i . detach ( this . getSbbLocalObject ( ) ) ; } ... } Siendo el c´digo para averiguar si esta o no subscrito a Advertising: o
- 277. 16.2. CALL CONTROL SERVICES. 243 Listado 16.24: Funci´n comprueba si tiene Advertising o private boolean i s A d v e r t i s i n g ( S t r i n g s i p A d d r e s s ) { boolean s t a t e=f a l s e ; CallControlProfileCMP p r o f i l e = t h i s . lookup (new j a v a x . s l e e . Address ( AddressPlan . SIP , s i p A d d r e s s ) ) ; i f ( p r o f i l e != null ) { state = p r o f i l e . getAdvertisingState ( ) ; } return s t a t e ; } Hay que tener en cuenta que este c´digo no esta testeado, as´ que puede sufrir o ı errores inesperados, pero ser´ una aproximaci´n bastante ajustada a lo que se har´ ıa o ıa en realidad.
- 278. ˜ CAP´ ITULO 16. DISENO 244 16.2.8. Servicios en cadena El Servicio encadenado en este caso se ha conseguido de un modo sencillo. Cada servicio en cadena tiene acceso a dos banderas (menos el primero y el ultimo servicio, ´ mirar la imagen). La primera bandera indica cuando un servicio alto en a cadena ha procesado la petici´n y el segundo indica cuando el servicio actual ha procesado la o petici´n actual. o Figura 16.5: Cadena de servicios. Las banderas son compartidas a trav´s de la variable aliasing del activity context. e Cada SBB que quiere compartir su variable Activity Context ha de hacer los siguiente: Definir m´todos de acceso a su ActivityContextInterface habitual (Call Forwarde ing SBB): Listado 16.25: CallForwardingSbbActivityContextInterface.java public i n t e r f a c e C a l l F o r w a r d i n g S b b A c t i v i t y C o n t e x t I n t e r f a c e extends j a v a x . s l e e . A c t i v i t y C o n t e x t I n t e r f a c e { public boolean g e t F i l t e r e d B y A n c e s t o r ( ) ; public void s e t F i l t e r e d B y M e ( boolean v a l ) ; public boolean g e t F i l t e r e d B y M e ( ) ; }
- 279. 16.2. CALL CONTROL SERVICES. 245 Definir la variable alias de Activity Context en su sbb-jar: Listado 16.26: Forwarding-sbb-jar.xml <sbb−j a r> <sbb> ... <a c t i v i t y −c o n t e x t −a t t r i b u t e −a l i a s> <a t t r i b u t e −a l i a s −name> inviteFilteredByCallBlocking </ a t t r i b u t e −a l i a s −name> <sbb−a c t i v i t y −c o n t e x t −a t t r i b u t e −name> filteredByAncestor </ sbb−a c t i v i t y −c o n t e x t −a t t r i b u t e −name> </ a c t i v i t y −c o n t e x t −a t t r i b u t e −a l i a s> <a c t i v i t y −c o n t e x t −a t t r i b u t e −a l i a s> <a t t r i b u t e −a l i a s −name> inviteFilteredByCallForwarding </ a t t r i b u t e −a l i a s −name> <sbb−a c t i v i t y −c o n t e x t −a t t r i b u t e −name> filteredByMe </ sbb−a c t i v i t y −c o n t e x t −a t t r i b u t e −name> </ a c t i v i t y −c o n t e x t −a t t r i b u t e −a l i a s> ... </ sbb> </ sbb−j a r> En el trozo de c´digo de arriba el SBB Call Forwarding declara dos alias y m´too e dos que har´n referencia a estos alias. El sbb-activity-context-attribute-name define la a variable local para la Interfaz personalizada del Activity Context (en este caso filteredByMe). Attribute-alias-name define el nombre de la variable en el Activity Context de la actividad. El Aliasing nos permite compartir contenidos de una variable alias. En nuestro escenario la siguiente cadena es VoiceMailSbb y en su fichero sbb-jar encontraremos: Listado 16.27: VoiceMail-sbb-jar.xml <a c t i v i t y −c o n t e x t −a t t r i b u t e −a l i a s > <a t t r i b u t e −a l i a s −name> inviteFilteredByCallForwarding </ a t t r i b u t e −a l i a s −name> <sbb−a c t i v i t y −c o n t e x t −a t t r i b u t e −name> filteredByAncestor </sbb−a c t i v i t y −c o n t e x t −a t t r i b u t e −name> </ a c t i v i t y −c o n t e x t −a t t r i b u t e −a l i a s >
- 280. :Mira a los elementos del attribute-alias-name.
- 281. :Las variables context son definidas en la interfaz personalizada Activity Context con EJB como setters y getters. getXXX y —— o setXXX definir´ una variable con el a
- 282. ˜ CAP´ ITULO 16. DISENO 246 nombre XXX. Uno puede pensar que el aliasing es una manera de crear algo similar a una variable est´tica de una clase java. La diferencia es que la podemos especificar a a trav´s del fichero sbb-jar file desde desde donde esta variable es accesible. e Prioridad de entrega Ha sido fijado en el descriptor de servicios. Por cada servicio nosotros definimos una como esta: Listado 16.28: -sbb-jar.xml <s e r v i c e −xml> <s e r v i c e > ... <default−p r i o r i t y > 100 </default−p r i o r i t y > ... </ s e r v i c e > </ s e r v i c e −xml>
- 283. :EL rango de default-priority est´ en [127, -128].SLEE entrega eventos a los SBB a de acuerdo a la prioridad. Aunque el servicio encadenado parece bastante f´cil y nos da flexibilidad para a a˜adir/quitar servicios de la cadena, tambi´n nos fuerza a seguir algunas reglas. Asumn e iendo este escenario son como siguen: Cada servicio es independiente. Si un servicio es a˜adido/quitado, el c´digo fuente no es cambiado (el descriptor n o xml si puede ser cambiado). Si queremos alcanzar estos objetivos necesitamos seguir algunas reglas: Si un servicio va a procesar un evento, tiene que fijar filteredByMe a verdadero Si el precursor del servicio actual ha procesado el evento actual tiene que fijar filteredByMe a verdadero En nuestro escenario cada servicio tiene conocimiento de la acci´n realizada por su o precursor. El servicio actual no sabe que precursor de sus precursores lo ha echo.
- 284. : Por ejemplo si no hubi´ramos seguido estas reglas nuestro VoiceMailSbb tendr´ e ıa que haber tenido m´todos que le dieran acceso a la bandera del CallBlockingSbb (cae da cambio en la cadena de servicios por encima de VoiceMailSbb le forzar´ al c´digo ıa o fuente a cambiar en VoiceMailSbb) o siempre empezar´ grabando un mensaje para ıa llamadas que no han sido desviadas por el CallForwardingSbb.
- 285. Conclusiones y Recomendaciones Actualmente los Application Servers para aplicaciones Telco son contenedores J2EE modificados para soportar eventos as´ ıncronos, como es el caso de los AS WebLogic Server (BEA), JBoss (Red Hat), WebSphere (IBM), Oracle OC4J (Oracle) y otras compa˜´ Pero estos no fueron dise˜ados para ello. El rendimiento es muy bajo, no tiene nıas. n soporte para transacciones ligeras t´ ıpicas de las Telco y es poco confiable, mientras que SLEE, si fue dise˜ado espec´ n ıficamente para sistemas de telecomunicaciones y es completamente as´ ıncrono. Por lo que Slee satisface mucho m´s los requerimientos para a las Telco que el mejor contenedor EJB. JAIN contiene muchas de las ventajas que los operadores y proveedores de servicios necesitan para el desarrollo de aplicaciones Telco actuales, bajo coste, calidad de servicio y capacidad para innovar, as´ como favorecer al desarrollo de nuevos servicios para las ı redes actuales y futuras. JAIN SLEE es una especificaci´n abierta y basada en est´ndares, que define como los o a servicios Telco pueden construirse, manejarse y ejecutarse. Esta extiende y envuelve el modelo de programaci´n IN con la separaci´n de un Service Switching Point y el Service o o Creation Point (SSP / SCP) y estandariza el modelo de programaci´n IN situ´ndolo o a dentro del entorno Java adem´s de que la especificaci´n ha sido dise˜ada expl´ a o n ıcitamente para habilitar la implementaci´n de plataformas carrier grade requeridas en entornos o de se˜ales de llamadas. n Las operadoras actuales compiten entre ellas de forma agresiva, los clientes deben arrebat´rselos a las otras compa˜´ a nıas, Deutsche Telekom, France Telecom y Telecom Italia no pasan por buenos momentos[21] , por lo que ofrecen m´s servicios de ultima a ´ generaci´n y tarifas m´s econ´micas, que son normalmente planas, por lo que estas o a o necesitan abaratar costes para la infraestructura de los servicios. A las operadoras les interesa que estos servicios incluyan soporte y se implementen de forma vertical, para lograr los mayores beneficios a corto plazo y m´ ınimo riesgo. Por esto la mayor´ de las ıa operadores tienen planes para migrar a redes All-IP en un plazo de cinco a˜os, estos n nuevos servicios ser´ implementados en SIP. ıan Con la incertidumbre que rodea la adopci´n y crecimiento de las futuras redes, Jain o SLEE provee de un camino evolutivo para la creaci´n de nuevos servicios. Los opero adores y proveedores de servicios compiten por llevarse la mayor parte de los beneficios generados por los servicios a lo largo de las actuales redes, mientras dan poca importancia a la habilidad de migrar estos servicios a redes futuras. La caracter´ ıstica que 247
- 286. posee Jain SLEE de portabilidad e independencia de la red, hace que cualquier servicio creado en esta arquitectura para actuales redes sea f´cilmente migrable para las futuras a redes. La evoluci´n de Jain SLEE vendr´ sujeta al apoyo de los operadores y proveedores o a de servicios, en la actualidad tenemos a Open Cloud a la cabeza con su contenedor Rhino, JBoss con su contenedor libre Mobicents y jNetX, como vendedores de contenedores y soluciones basadas en Jain SLEE. Estos a su vez tienen apoyo de grandes operadoras como Vodafone, Telef´nica, Telecom Italia, etc ´ vendedores como Motorola, Siemens, o o HP, IBM, Aepona, etc. Aunque el uso de esta arquitectura no haya despegado, ya se empiezan a usar algunos servicios creados a partir de ella. Sin embargo si finalmente se imponen los servicios SIP, JAIN SLEE ser´ demasiado complejo, y la complejidad ıa esta asociado normalmente con perdida de rendimiento. Mobicents es una plataforma VoIp de c´digo abierto completamente conforme a la o especificaci´n Jslee 1.0. [7] distribuido bajo Licencia dual flexible [20] y con una licencia o comercial 8.6.1 que desde 2.400$ permite redistribuir c´digo de Mobicents con soluciones o propietarias as´ como ofrecer servicios online basados en Mobicents; En el campo de ı las telecom NGIN, Mobicents encaja como core engine de alto rendimiento para SDP e IMS adem´s de para una gran variedad de dominios de problemas que demandan EDA. a Posee un considerable n´mero de RAs ya en funcionamiento, los cuales permiten que u cualquier fuente de eventos pueda ser programada para encauzarlos mediante estos y as´ poder ser manejados dentro de una aplicaci´n Jain Slee. ı o Las pruebas de rendimiento efectuadas en la versi´n estable 1.0.00.CR1, han dao do muy buenos resultados, obteniendo uno rendimiento m´ximo entorno a los 1000a 1200tps. 8.4 Sin embargo las principales ventajas del contenedor Mobicents son: Un modelo de programaci´n as´ o ıncrono orientado a eventos Portabilidad con otros contenedores - Contenedores Jain Slee, gracias a los Resource Adaptors Type. - Contenedores J2EE, por su interfaz de conexi´n JSLEE. o Es independiente de la red Es portable a cualquier arquitectura Posee entornos amigables para la administraci´n (ver anexo E) como para el o desarrollo de nuevos servicios (ver anexo C) Una comunidad activa de desarrolladores, el foro del proyecto es el tercero m´s a activo de Java.net La naturaleza abierta del proyecto ha generado a gran velocidad un gran n´mero u de documentation, mejores pr´cticas y ejemplos. a 248
- 287. A la hora de programar con Jain SLEE y usar Mobicents, hemos encontrado muchos problemas. Hay que recalcar que es importante tener conocimientos altos de J2EE,JBOSS adem´s de arquitectura y servicios de red inteligente y/o IMS (SIP, Parlay, a etc), sin estos, hemos tenido muchas dificultades para avanzar y entender los ejemplos. Uno de los mayores problemas que afecta al posible avance de esta arquitectura es la falta de informaci´n sobre la metodolog´ para crear nuevas aplicaciones,y la o ıa gran variedad de conocimientos que hay que poseer antes de embarcarse a programar servicios , la unica fuente sobre Jain Slee es la propia especificaci´n y algunas p´ginas ´ o a Wiki. La informaci´n que ofrece la p´gina Mobicents est´ desorganizada, las explicaciones o a a y ejemplos son escasos. La gran cantidad de desarrolladores y subproyectos independientes crea una sensaci´n de caos. o Otro problema es el funcionamiento del foro de Mobicents users [14], en el no siempre responden adem´s de ser poco concretos. Tambi´n hay que tener en cuenta que al a e ser Open Source la gente involucrada no gana nada respondi´ndote con celeridad a tus e cuestiones. A pesar de todo, invitan a cualquiera a contribuir a la plataforma, para desarrollar las tareas pendientes de la hoja de ruta 11.1, crear nuevos subproyectos nuevos que contribuyan a la plataforma o colaborar en el dise˜o de los existentes [15], ya sean Ras, n herramientas de desarrollo, servicios, etc. Hay que se˜alar que compa˜´ de investigaci´n como Gartner han comenzado a n nıas o dar cobertura a EDA. Mobicents ha sido a˜adido en el libro de Gartner “Who is who n in middleware” [24] Mobicents a´n es un proyecto relativamente joven,(la primera versi´n estable sali´ el u o o 25 de Junio de 2006 [25]). El despegue de mobicents, permitir´ ahorrar una gran ıa cantidad de dinero a las operadoras, que actualmente pagan por servicios propietarios muy caros, que no son compatibles con futuros cambios en las redes y son dif´ ıcilmente exportables a otras arquitecturas o lenguajes. Por otro lado, es una opci´n arriesgada a corto plazo, pues Mobicents necesita sobre o todo ser probado en entornos reales Telco y la consolidaci´n de servicios, adem´s de la o a dificultad de contrataci´n de un soporte profesional una vez desplegado en producci´n. o o En este contexto, entendemos que pueden ocurrir las siguientes situaciones: Mobicents es utilizado como base por alg´n integrador de sistemas para un conu tenedor de bajo coste, sobre el que desarrollar sus servicios Telco. Mobicents es utilizado por alg´n operador para la creaci´n de sus propios servicios u o Telco. Mobicents es explotado e integrado en alguna plataforma ya existente J2EE (por ejemplo BEA). 249
- 288. Las soluciones posibles de las operadoras pasan por las siguientes opciones: seguir confiando en las evoluciones propuestas por sus suminstradores de red y en sus integraciones cada vez m´s depuradas con el mundo J2EE, a Utilizar las propuestas Telco que vienen del mundo IT (como los SIP AS) para los nuevos servicios basados en IMS, y posteriormente migrar los actuales servicios legacy a dichas plataformas, una vez asentadas. Utilizar los contenedores jain slee actualmente existentes. Aqu´ tendr´ dos posiı ıan bilidades: adoptar uno comercial, o bien evolucionar mobicents para cubrir sus necesidades concretas. Hay que destacar que, con el apoyo actual de mobicents por parte de la industria, OpenCloud y Jnetx les llevan una ventaja sustancial en cuanto a funcionalidad, fiabilidad y soporte, por lo que ser´ necesario un inıa ter´s que se traduzca en inversiones bien sea de proveedores de servicios, o de e operadores. A pesar de todo, es una alternativa rentable a Open Cloud y jNETX, con la ventaja de ser open source, lo que le da estabilidad y confiabilidad, los fallos son encontrados y resueltos r´pidamente, y las actualizaciones llegan mucho m´s r´pido. Aunque carece a a a de grandes servicios y sotisficaci´n, cuenta con un equipo desarrollador activo y en o aumento, es extensible, cada vez aumenta la eficiencia y se a˜aden nuevos resource n adaptors y servicios. Open cloud lidera actualmente los est´ndares abiertos en el middleware de Telco a despu´s de que Motorola y No 8 Ventures han invertido en esta 10 millones de d´lares e o [18]. Ha lanzado la primera plataforma abierta verdaderamente carrier-grade para IMS para un mercado estimado en 5.1 billones de d´lares para el 2009 [26]. o Mobicents, a pesar de tener muchos operadores y vendedores interesados en su plataforma, necesita una inversi´n para su desarrollo, se ha notado mucho la desvincuo laci´n de Open Cloud del proyecto. Ahora ha empezado a ofrecer licencias comerciales, o si continua ofreciendo servicios, y mejorando el contenedor, y finalmente las operadoras apuestan por Mobicentes, triunfar´. Su principal competidor ser´ Open Cloud, que a ıa no descartar´ que la comprara en un futuro, pasa asegurarse el mercado est´ndares ıa a abiertos en el middleware de Telco. Incluso podr´ integrarlo Bea con sus potentes conıa tenedores J2EE para competir con Open Cloud. Seg´n lo descrito, mobicents se puede encontrar en una encrucijada respecto a su u desarrollo: o bien encuentra el apoyo necesario para su evoluci´n definitiva, o bien la diso tancia recorrida por los fabricantes de software J2EE ser´ m´ a ınima y no ser´ necesario, a o bien sus hermanos comerciales (Jnetx, OpenCloud) se distancian definitivamente con la version 1.1 de la especificaci´n. Lo veremos en los pr´ximos meses. o o 250
- 289. Una posible evoluci´n l´gica para esta tecnolog´ ser´ la venta de servicios verticales o o ıa ıa con soporte a las operadoras, utilizando JAIN SLEE y Mobicents de forma enmascarada. Centrarse en vender la funcionalidad de un determinado servicio , sin importar la tecnolog´ subyacente. ıa Ciertamente es un riesgo invertir en Jain Slee si fracasa, pero si es tan potente como auguran, las empresas que apuesten e inviertan en Jain Slee, se llevar´n una buena a parte del futuro mercado de las Telecomunicaciones, ofreciendo servicios m´s eficientes, a rentables e innovadores, sin depender su desarrollo de terceros, infraestructuras o hardware. Es dif´ predecir el futuro, pero es probable que ocurra una lucha entre J2EE adapıcil tado a las Telco y J2EE con Jain slee, tal y como ocurri´ entre VHS y Beta. Donde las o operadoras decidir´n que tecnolog´ finalmente se impone, aunque esta no siempre sea a ıa la mejor. Sun ya ha abandonado el juego apostando por su contenedor Open Source J2EE Glassfish, quedando abanderado JAIN SLEE solamente por peque˜as compa˜´ n nıas como Open Cloud, JnetX y Mobicents. El enfoque tecnol´gico de JAIN SLEE es muy bueno para operadores con o gran confianza en IN, y el valor de asumir el riesgo de hacer negocios con compa˜´ peque˜as. Para el resto, hay otras tecnolog´ ah´ fuera. nıas n ıas ı Michael Maretzke, JAIN SLEE Expert. 251
- 290. 252
- 291. Referencias ´ [1] RAMON GARC´ y MICHAEL MARETZKE, JAIN SLEE and J2EE IA Technologies , 2004 JavaOne Conference [2] DAVID FERRY y SWEEN LIM, JAIN SLEE An Event Driven Aplication Environment , 2004 JavaOne Conference [3] DAVID FERRY, SWEEN LIM, PHELIM O’DOHETY y DAVID PAGE, JAIN SLEE Tutorial , 2003 [4] Open Cloud, A SLEE for all Seasons , 4 Marzo 2003 [5] Open Cloud, http://www.opencloud.com [6] JAINSLEE.org, http://jainslee.org/ [7] JSR-22: JAIN—SLEE API Specification 1.0 , http://jcp.org/en/jsr/detail?id=22 , 17 Febrero 2004 [8] JSR-240: JAIN—SLEE API Specification 1.1 , http://jcp.org/en/jsr/detail?id=240 , 26 Febrero 2007 [9] MARETZKE MICHAEL, How To Write JSLEE Resource Adaptor , 5 Octubre 2005 [10] IVELIN IVANOV, MobicentsSMPPRA , Julio 2006 [11] Mobicents, Proyecto Mobicents [12] Selenium Software Ltd, Selenium Software [13] IVELIN IVANOV y VICTOR HUGO ROS, JSLEE Service , 25 Octubre 2005 Mobicents Wake Up Call [14] Foro Mobicents Users, http://forums.java.net/jive/forum.jspa?forumID=55 [15] Foro Mobicents Contributors , http://forums.java.net/jive/forum.jspa?forumID=54 [16] Foro JSLEE Resource Adaptor Types , http://forums.java.net/jive/forum.jspa?forumID=92 [17] issue tracking system, https://mobicents.dev.java.net/servlets/ProjectIssues 253
- 292. 254 REFERENCIAS [18] OpenCloud Raises $10million, http://www.opencloud.com/news-events [19] Mobicents performance , http://www.mobicents.org-a.googlepages.com/faq.html [20] Mobicents license policy , https://mobicents.dev.java.net/servlets/NewsItemView?newsItemID=3533 [21] A los grandes se les cruzan los cables , http://www.elpais.com ,20 de Mayo 2007 [22] BEA Systems WebLogic® RealTime, http://www.bea.com [23] BEA WebLogic® Server, http://www.bea.com [24] Gartner starts serious coverage of event driven architectures , http://ivelinivanov.blogspot.com ,18 de Marzo 2006 [25] Mobicents 1.0.00.CR1 Disponible , http://forums.java.net/jive/thread.jspa?messageID=126822 ,25 de Junio 2006 [26] OpenCloud launches first true carrier-grade open platform for IMS , http://www.opencloud.com/news-events/releases/2007/IMS products PR 20032007FINAL.html ,20 de Marzo 2007 [27] Diameter Base Protocols written in Java, jdiameter.dev.java.net ,Junio 2006 [28] Open Diameter, www.opendiameter.org ,Junio 2006 [29] Mobicents Diameter Resource Adaptor , http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA ,19 de Mayo 2006 [30] Java Persistence API, P´gina de Persistencia de SUN a [31] RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax , Agosto 1998 [32] RFC 2543, SIP: Session Initiation Protocol , Marzo 1999 [33] RFC 2976, The SIP INFO Method , Octubre 2000 [34] RFC 3261, SIP: Session Initiation Protocol , Junio 2002 [35] RFC 3262, Reliability of Provisional Responses in the Session Initiation Protocol (SIP) , Junio 2002 [36] RFC 3263, Session Initiation Protocol (SIP): Locating SIP Servers , Junio 2002 [37] RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification , Junio 2002 [38] RFC 3311, The Session Initiation Protocol (SIP) UPDATE Method , Septiembre 2002
- 293. REFERENCIAS 255 [39] RFC 3326, The Reason Header Field for the Session Initiation Protocol (SIP) , Diciembre 2002 [40] RFC 3428, Session Initiation Protocol (SIP) Extension for Instant Messaging , Diciembre 2002 [41] RFC 3515, The Session Initiation Protocol (SIP) Refer Method , Abril 2003 [42] RFC 3588, Diameter Base Protocol 19 Mayo 2006 [43] RFC 3725, Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) , Abril 2004 [44] RFC 4028, Session Timers in the Session Initiation Protocol (SIP) , Abril 2005 [45] RFC 4566, SDP: Session Description Protocol , Julio 2006
- 294. 256 REFERENCIAS
- 295. Anexos 257
- 297. Anexo A Instalaci´n de Mobicents o A.1. mobicents-installer 1. Bajar la ultima versi´n de mobicents-installer. ´ o Mobicents Server 2. Fijar la variable del sistema MOBICENTS HOME donde vayas a instalar mobicents. 3. Instalar JDK 1.4 , pero en caso de error: Unsupported major.minor version 49.0 durante el ant make, usa JDK 1.5. 4. Fijar la variable del sistema JAVA HOME donde tengas instalado JDK 1.4 o JDK 1.5. 259
- 298. 260 ´ ANEXO A. INSTALACION DE MOBICENTS Ejecutar mobicents-installer 1.0.00.CR3.jar, nos aparecer´ la siguiente pantalla: a Figura A.1: Primera pantalla Pulsamos en siguiente, y nos mostrar´ la siguiente pantalla de informaci´n. a o Figura A.2: Informaci´n de instalaci´n o o
- 299. A.1. MOBICENTS-INSTALLER 261 Despu´s de dar a siguiente, nos preguntar´ en que carpeta queremos instalar Moe a bicents, en caso de no existir la crear´, aseg´rate que la variable del sistema MOBIa u CENTS HOME apunte a esta carpeta. Figura A.3: Elecci´n de la carpeta o
- 300. 262 ´ ANEXO A. INSTALACION DE MOBICENTS Seleccionamos en la siguiente pantalla los componentes que queremos instalar, RAs, ejemplos etc. Figura A.4: Elecci´n de los componentes o Despu´s, configuramos la base de datos que usemos. e Figura A.5: Configuraci´n de la base de datos o
- 301. A.1. MOBICENTS-INSTALLER Ya est´ listo para instalar el programa. a Figura A.6: Listo para instalar Figura A.7: Proceso de instalaci´n o 263
- 302. ´ ANEXO A. INSTALACION DE MOBICENTS 264 Si no ha ocurrido ning´n problema, mostrar´ la siguiente pantalla informando que u a la instalaci´n se ha llevado a cabo con ´xito. o e Figura A.8: Instalaci´n terminada o A.2. Distribuci´n binaria o Pasos a seguir para ejecutar Mobicents desde Mobicents Server RCx 1. Bajar la ultima versi´n de mobicents server RCx del cvs. ´ o Mobicents Server 2. Fijar la variable del sistema MOBICENTS HOME donde tengas la carpeta del servidor mobicents RCx. 3. Instalar JDK 1.4 , pero en caso de obtener el siguiente error durante el ant make: “Unsupported major.minor version 49.0” usa JDK 1.5. 4. Fijar la variable del sistema JAVA HOME donde tengas instalado JDK 1.4 o JDK 1.5. Como ejecutar el servidor Ve al directorio donde has instalado el servidor Ve a la carpeta ./bin y ejecuta ˆ Windows: run -c all -b <127.0.0.1 o tu direcci´n ip > o ˆ Linux: run.sh -c all -b <127.0.0.1 o tu direcci´n ip > o
- 303. ´ A.3. CODIGO FUENTE A.3. 265 C´digo fuente o Pasos a seguir para ejecutar Mobicents del c´digo fuente: o 1. Bajar la ultima versi´n de mobicents del cvs. ´ o cvs -d :pserver:[email protected]:/cvs login cvs -d : pserver:[email protected]:/cvs checkout mobicents 2. Fijar la variable del sistema MOBICENTS HOME donde tengas la carpeta de mobicents. 3. Descargar Jboss 3.2.6 o mayor de 3.2.x 4. Fija la variable del sistema JBOSS HOME donde tengas instalado JBoss. 5. Instalar JDK 1.4 , pero en caso de error: Unsupported major.minor version 49.0 durante el ant make, usa JDK 1.5. 6. Fijar la variable del sistema JAVA HOME donde tengas instalado JDK 1.4 o JDK 1.5. 7. Instalar Apache Ant 1.7.0 8. Fija la variable del sistema ANT HOME donde tengas instalado Ant y a˜´dela na tambi´n la carpeta bin al PATH. e 9. Entrar en el directorio de Mobicents 10. Ejecutar ant make A.3.1. El SLEE 1.0 Technology Compatibility Kit (TCK) Toda especificaci´n ha de ofrecer obligatoriamente un test de compatibilidad: el o Technology Compatibility Kit (TCK). Este test consta de un conjunto de pruebas que aseguran que una determinada implementaci´n es compatible con la especificaci´n a la que corresponden los tests. El o o JCP pone a disposici´n de los creadores de cada especificaci´n una serie de herramientas o o ( Java Compatibility Test Tools ) para la creaci´n de estos tests de compatibilidad. o Aunque en principio no era necesario que una implementaci´n como Mobicents teno ga que pasar estos tests de compatibilidad, el echo de pasarlos le ofrece muchas ventajas comerciales al conseguir la certificaci´n SLEE. o A´n as´ que una implementaci´n no pase los tests de compatibilidad, de ning´n u ı, o u modo implica que no sea compatible con la especificaci´n. Lo unico que indica este o ´ hecho es que no sea ha considerado conveniente el pasar dichas pruebas. Estos tests de compatibilidad suponen una importante garant´ para los usuarios ıa y desarrolladores de las diferentes implementaciones ya que sabiendo que Mobicents es compatible con la especificaci´n SLEE, tienen garantizado que sus desarrollos ser´n o a portables entre diferentes implementaciones que sean tambi´n compatibles con SLEE. e
- 304. ´ ANEXO A. INSTALACION DE MOBICENTS 266 Para facilitar el desarrollo, TCK est´ incluido en el m´dulo de CVS de mobicents a o con los ficheros y cr´ditos apropiados de los autores originales. e TCK est´ preconfigurado para ejecutarse junto a un servidor Mobicents activo a en localhost. A.3.2. Ejecutar el contenedor Edita el script que ejecuta JBoss para aumentar la configuraci´n de la memoria por o defecto y activar la depuraci´n. o Localiza las siguientes l´ ıneas y descom´ntalas o a˜´delas si no est´ fijado JAe na a VA OPTS: En Windows: rem Sun JVM memory allocation pool parameters. Uncomment and rem modify as appropriate. JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m rem JPDA options. Uncomment and modify as appropriate to enable rem remote debugging. JAVA_OPTS= -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket, address=8787,server=y,suspend=n %JAVA_OPTS% En Unix: JAVA_OPTS="$JAVA_OPTS -Xms128m -Xmx512m" JAVA_OPTS=" -Xdebug-Xnoagent -Xrunjdwp:transport=dt_socket,address=8787, server=y,suspend=n $JAVA_OPTS Ejecuta JBoss usando la configuraci´n all con la direcci´n IP de localhost <dio o recci´n de localhost > o Ir al directorio bin de JBoss ˆ Windows: run -c all -b <127.0.0.1 o tu direcci´n ip > o ˆ Linux: run.sh -c all -b <127.0.0.1 o tu direcci´n ip > o A.3.3. Ejecutar TCK Arrancar mobicents. %HOME_JBOSS%bin run -c all -b localhost
- 305. ´ A.3. CODIGO FUENTE 267 cd $project home ant tests-slee-tck -Dtests= ¡testpattern¿ estpattern es un fichero modelo como tests/sbb/abstractclass o tests/sbb/abstractclass/Test522Test Este es el comando completo que ejecuta un test particular - Test522Test La salida deber´ ser algo as´ ıa ı: Buildfile: build.xml tests-slee-tck: tests-slee-tck-internal: [echo] slee.tck.testsuite=${slee.tck.testsuite} [echo] Starting TCK with params: -batch ’testsuite ... [echo] Excluding tests listed in file: ${slee.tck.testsuite}/jain-slee-tck-1_0.jtx [java] Starting test suite... [java] Test results: passed: 1 [java] Results written to C:workmobicentsjain-slee-1.0-tcktckwork. [java] Report written to C:workmobicentsjain-slee-1.0-tckreports [echo] SLEE TCK report available at C:/work/mobicents/jain-slee-1.0-tck/reports/report.html BUILD SUCCESSFUL Total time: 4 seconds Ning´n test deber´ de fallar, para hacer m´s tests, desde $project home ejecutar: u ıa a ant tests-slee-tck -Dtests=tests/sbb/abstractclass NOTA: Los tests que est´ excluidos de test runs est´n localizados en: a a $project{textunderscore}home/jain-slee-1.0-tck/testsuite/ jain-slee-tck-1{textunderscore}0.jtx A.3.4. Reports Report creado por el commando: ant tests-slee-tck -Dtests=tests/sbb/abstractclass/Test2013Test.xml Localizado en: C:cvsmobicentsmobicentsjain-slee-1.0-tckreportsreport.html
- 306. ´ ANEXO A. INSTALACION DE MOBICENTS 268 JavaTest : Report JavaTest : Report TestSuite: JAIN SLEE TCK 1.0 build 46 Configuration Configuration Interview Which tests to run How to run the tests Where to put the results Results Statistics Keyword Summary Configuration Configuration Interview Which tests to run Test suite Tests C:mobicents-sourcejain-slee-1.0-tcktestsuite tests/sbb/abstractclass/Test2013Test.xml Excluded Tests 3 entries jain-slee-tck-1_0.jtx How to run the tests Environment Untitled Timeout factor 1.0 Where to put the results Work directory C:mobicents-sourcejain-slee-1.0-tcktckwork Report directory C:mobicents-sourcejain-slee-1.0-tckreports Results Tests that passed Total 1 Statistics 1
- 307. A.4. USANDO ECLIPSE HOT CODE REPLACEMENT 269 Keyword Summary keyword passed 1 1 Total 1 1 Total Memory used 1.457K, allocated 3.880K Report generated on 09-mar-2007 20:25:05 Using JavaTest 3.1.2; built on 02 Oct 2002 with Java(TM) 2 SDK, Version 1.3.1-b24 Tambi´n crea un fichero summary.txt con los resultados de los tests en el mismo e directorio. tests/sbb/abstractclass/Test2013Test.xml A.4. Passed. Test passed Usando Eclipse Hot Code replacement Eclipse soporta la caracter´ ıstica de reemplazar c´digo en un JVM que se est´ ejecuo a tando. Para que esto sea posible, las clases desplegadas en JBoss deben ser compilados por Eclipse y no por Ant. Sigue los siguiente pasos: Haz un t´ ıpico ant make Vete a Project >Clean >Mobicents ant hotcode (ejecuta el objetivo hotcode) Ejecuta JBoss Cuando quieras cambiar las clases mientras JBoss no est´ siena do ejecuta en modo debug, deber´ ejecutar el objetivo hotcode antes de que ıas empiece. empieze.
- 308. 270 ´ ANEXO A. INSTALACION DE MOBICENTS
- 309. Anexo B Configuraci´n de SoftPhones o En este anexo explicamos como configurar los SoftPhones que utilizamos para algunos ejemplos y nuestro ejemplo pr´ctico. Antes de configurar los tel´fonos, aseg´rate a e u de que el servidor Mobicents esta ejecutandose y el RA SIP y el el proxy est´n desplea gados 10.5.5. B.1. XTen eyeBeam 1.1 Si no te aparece la ventana “settings” la primera vez que inicies el tel´fono, pulsa e el bot´n derecho del rat´n sobre la interfaz gr´fica del tel´fono y elige “settings...” o o a e 1. En la ventana “Settings”, dentro del recuadro “Choose Setting Category” elige “Add a New SIP Account” 2. Introduce los siguientes datos: El nombre de usuario, por ejemplo, Mobicents en los campos “Display name”, “User name” y “Authorization user name” En el campo “Domain” introduce nist.gov Selecciona las casillas “Register with domain”, “Use as Outbound Proxy” y “Manual Override” En el campo “Host” introduce la direcci´n IP desde donde se est´ ejecutando o a Mobicents; Si el RA SIP est´ escuchando un puerto diferente al 5060, debes a especificarlo en “Manual Override”, en caso contrario deja 5060. Despu´s de esto, selecciona la casilla “Enable this SIP account” y pulsa Ok e Deja el resto de opciones con sus valores por defecto. 3. Llegado a este punto, el tel´fono deber´ registrarse con Mobicents e ıa 271
- 310. ´ ANEXO B. CONFIGURACION DE SOFTPHONES 272 Figura B.1: Configuraci´n Xten o B.2. X-Lite 3.0 Puedes bajar el X-Lite 3.0 de esta direcci´n: http://www.counterpath.com o Si no te aparece la ventana “settings” la primera vez que inicies el tel´fono, pulsa el e bot´n derecho del rat´n sobre la interfaz gr´fica del tel´fono y elige “SIP Account Seto o a e tings...” 1. En la ventana “SIP Accounts”, en el recuadro “Choose Setting Category” elige “Add...” 2. Introduce los siguientes datos: El nombre de usuario, por ejemplo, Mobicents en los campos “Display name”, “User name” y “Authorization user name” En el campo “Domain” introduce nist.gov Selecciona las casillas “Register with domain and receive incoming calls” y despu´s “Proxy” e En el campo “Address” introduce la direcci´n IP desde donde se est´ ejecuo a tando Mobicents; Si el RA SIP es escuchando un puerto diferente al 5060, debes especificarlo escribiendo “direcci´n ip:Puerto” o Despu´s de esto, selecciona la casilla “Enable this SIP account” y pulsa e Aceptar
- 311. B.2. X-LITE 3.0 273 Figura B.2: Configuraci´n X-Lite I o Deja el resto de opciones con sus valores por defecto. 3. Llegado a este punto, el tel´fono deber´ registrarse con Mobicents e ıa Figura B.3: Configuraci´n X-Lite II o
- 312. ´ ANEXO B. CONFIGURACION DE SOFTPHONES 274 B.3. SJphone Puedes bajar el SJPhone de esta direcci´n: http://www.sjlabs.com/sjp.html o 1. Pulsa el bot´n derecho del rat´n sobre la interfaz gr´fica del tel´fono y elige o o a e “Options...” 2. Haz click en “New” en la pesta˜a “Profiles” y pon un nombre al perfil, por ejemplo n Mobicents, tu pantalla se mostrar´ de as´ a ı: Figura B.4: Nuevo perfil SJPhone 3. Introduce los siguientes datos en la ventana “Profile Options” que te habr´ aparea cido: Ve a la pesta˜a “Sip Proxy” n En “Proxy Domain” introduce nist.gov En “User Domain” introduce nistg.gov Selecciona la casilla “Register with proxy”. Deja la casilla “Proxy is strict outbound” sin seleccionar. Selecciona la casilla “Use separate register” En el campo “Registar domain” introduce la IP desde donde se est´ ejecua tando Mobicents; Si el RA SIP es escuchando un puerto diferente al 5060, debes especificarlo en en el campo siguiente. Deja sin seleccionar la casilla “Unregister contact address only” Pulsa Ok
- 313. B.3. SJPHONE 275 Introduce una cuenta nueva, por ejemplo, mobicents y una contrase˜a n Selecciona el Perfil que acabas de crear y pulsa “Use...” Figura B.5: Profile Options 4. En este punto, el tel´fono deber´ registrarse con Mobicents e ıa Figura B.6: SJPhone Configurado
- 314. 276 ´ ANEXO B. CONFIGURACION DE SOFTPHONES
- 315. Anexo C Eclipslee El plug-in de JAIN SLEE para Eclipse est´ dise˜ado para facilitar la creaci´n de a n o los siguientes componentes de JAIN SLEE: Especificaciones de perfiles Eventos Bloques de construcci´n de servicios (SBBs) o Descriptores XML de servicios Unidades desplegables Con este plug-in, los desarrolladores pueden construir servicios enteros r´pida y a f´cilmente. El plugin se asegura de que los descriptores XML son correctos, as´ como a ı de la creaci´n de los esqueletos de las clases de Java para a˜adirles la l´gica de los o n o servicios. Para empezar con la creaci´n de componentes JAIN SLEE, se debe crear un proyeco to, y cualquier componente externo (como los eventos de JAIN SIP) deben ser accesibles desde ese proyecto. Las instrucciones para realizar esto est´n en las pr´ximas p´ginas. a o a 277
- 316. 278 C.1. ANEXO C. ECLIPSLEE Instalaci´n o 1. Descargar la distribuci´n binaria desde sourceforge.net, por ejemplo: mobicentso eclipslee-1.0b2.zip 2. Descomprimir el archivo 3. Copiar el directorio org.mobicents.eclipslee.servicecreation 1.0.5 a la carpeta $eclipse homeplugins 4. Copia el archivo file xerces.jar desde el directorio ..mobicents.eclipslee.servicecreation 1.0.5lib al directorio ..mobicents.eclipslee.servicecreation 1.0.5 5. Borra la carpeta que hay en $eclipse homeconfigurationorg.eclipse.update y reinicia el eclipse.
- 317. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE C.2. 279 Creando un nuevo proyecto JAIN SLEE Es necesario crear un proyecto JAIN SLEE antes de que se puedan crear componentes de JAIN SLEE. Esto se puede hacer desde el entorno de desarrollo seleccionando la opci´n “New Project” del men´ “File”, tal como se indica en la figura siguiente. o u Figura C.1: Nuevo proyecto. Esto crear´ un di´logo de “New Project” como se muestra a continuaci´n. Desde a a o este di´logo, expandir “JAIN SLEE” y seleccionar la opci´n “JAIN SLEE Project”. a o Haga click en “Next” para continuar eligiendo un nombre y una ubicaci´n para el nueo vo proyecto.
- 318. 280 ANEXO C. ECLIPSLEE Figura C.2: Nuevo proyecto JAIN SLEE D´ un nombre al proyecto y, si lo desea, especifique una ubicaci´n distinta. Para e o la mayor´ de la gente, la ubicaci´n por defecto ser´ la correcta, ya que es el espacio ıa o a de trabajo actual. La imagen siguiente muestra un proyecto con el nombre ’Test’ en la ubicaci´n por defecto. Presione “Finish” para crear este proyecto o Figura C.3: Nombre del proyecto
- 319. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 281 La siguiente imagen muestra un espacio de trabajo con proyecto JAIN SLEE reci´n e creado con la carpeta del proyecto “Test” expandida: Figura C.4: Proyecto creado. El espacio de trabajo contiene lo siguiente: Carpeta src. Todos los paquetes y componentes se deben crear en esta carpeta de c´digo. o Carpeta bin. Aqu´ es donde se ubicar´n las clases compiladas. ı a Carpeta jars. Los componentes empaquetados se colocar´n aqu´ una vez construa ı idos. Carpeta lib. Coloque aqu´ cualquier componente jar externo. ı Carpeta dtd. Contiene copia de las DTDs1 de JAIN SLEE usadas por el plugin JAIN SLEE del Eclipse en modo offline. Una librer´ del sistema JRE. Usado por Eclipse para compilar el c´digo. ıa o 1 Digital Type Definition
- 320. 282 ANEXO C. ECLIPSLEE Un archivo slee.jar. Contiene el paquete javax.slee, usado por Eclipse para compilar el c´digo y para completar el c´digo. o o Un archivo build.xml de construcci´n mediante Ant. Se usa para compilar y emo paquetar cualquier componente creado. Se recomienda no intentar modificar o borrar este archivo. Para crear un componente antes necesitas crear un paquete que lo contenga. El paquete debe crearse como descendiente del directorio src. Para hacer esto, haga click con el bot´n derecho en la carpeta src y seleccione “New Package”. D´ un nombre o e al paquete usando el di´logo emergente (se muestra debajo). a Figura C.5: Nuevo paquete. El proyecto JAIN SLEE est´ listo para a˜adir nuevos componentes. Lea las p´ginas a n a siguientes para m´s detalles: a Evento Especificaci´n de perfiles o Bloques de construcci´n de servicios (Service Building Block, SBB) o Servicio XML Unidad desplegable
- 321. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE C.2.1. 283 Creando un nuevo evento JAIN SLEE Antes de poder crear un evento de JAIN SLEE, se debe haber creado y configurado un proyecto tal como se describe en “Creando un nuevo proyecto JAIN SLEE”. Haga click con el bot´n derecho en el paquete y escoja “New Other...” como se o muestra debajo. Figura C.6: Nuevo evento.
- 322. 284 ANEXO C. ECLIPSLEE Deber´ aparecer un di´logo. Expanda la opci´n “JAIN SLEE” y escoja “JAIN ıa a o SLEE Event”. El di´logo deber´ aparecer como sigue: a ıa Figura C.7: Nuevo evento JAIN SLEE. Haga click en “Next” para obtener el siguiente di´logo: a Figura C.8: Nombre del evento. El directorio de origen y el paquete se rellenar´n autom´ticamente si selecciona a a “New Other...” al pinchar con en bot´n derecho en un paquete. De otra manera, deo ber´ completarlos presionando “Browse...” y seleccionando las localizaciones deseadas. a
- 323. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 285 D´ un nombre al evento; el nombre debe acabar en “Event.java”. Presione “next” e para ir al di´logo de identificaci´n del componente, como se ve en el dibujo inferior: a o Figura C.9: Identificaci´n del evento. o Los campos de nombre, versi´n y distribuidor son obligatorios y el SLEE los usa o para la identificaci´n del evento. El campo de la descripci´n es opcional, pero se reo o comienda completarlo para permitir una r´pida identificaci´n del evento en el futuro. a o
- 324. 286 ANEXO C. ECLIPSLEE Despu´s de completar estos campos, presione “Finish” para crear el evento. e Figura C.10: Evento completado. Dos archivos, “TestEvent.java” y “Test-event-jar.xml” se han creado en el paquete seleccionado. El primero es el c´digo fuente del evento, y el segundo es el descriptor o de despliegue del evento. Adem´s, el archivo build.xml del proyecto se ha actualizado a para la construcci´n y limpieza del evento. o
- 325. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 287 Antes de usar el evento con un SBB, debemos construirlo. Esto se puede lograr haciendo doble click en el archivo build.xml, y a continuaci´n click con el bot´n derecho o o en “build-Test-event” en el panel “Outline” a la derecha de la pantalla y escogiendo “Run 1. Ant Build”. Esto se muestra en la figura inferior. Figura C.11: Construcci´n del evento. o El jar construido se puede encontrar en el directorio “jars” del proyecto. Puede ser necesario forzar una actualizaci´n de este directorio haciendo click con el bot´n derecho o o y seleccionando “Refresh”.
- 326. 288 C.2.2. ANEXO C. ECLIPSLEE Creando una nueva especificaci´n de perfiles JAIN SLEE o Antes de poder crear una especificaci´n de perfiles JAIN SLEE se tiene que haber o creado y configurado un proyecto JAIN SLEE como se describe en Creando un nuevo proyecto JAIN SLEE. Click con el bot´n derecho en el paquete deseado y seleccione “New Other...” o como se muestra debajo. Figura C.12: Nuevo perfil 1.
- 327. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 289 Expanda “JAIN SLEE” si es necesario, y escoja “JAIN SLEE Profile Specification” como se ilustra en la figura siguiente, y a continuaci´n presione “Next”. o Figura C.13: Nuevo perfil 2. Aparecer´ el siguiente di´logo: a a Figura C.14: Nombre de archivo del perfil El directorio de origen y el paquete se rellenar´n autom´ticamente si escogi´ “New a a o Other...” al pinchar con el bot´n derecho en un paquete. De otra manera, necesio tar´ escogerlos seleccionando “Browse...” y buscando la ubicaci´n deseada. a o
- 328. 290 ANEXO C. ECLIPSLEE D´ un nombre a la especificaci´n de perfil; el nombre debe acabar en “ProfileCMP.java”. e o A continuaci´n, presione “Next” para pasar al di´logo de identificaci´n del componente, o a o mostrado abajo: Figura C.15: Profile Identity. Los campos de nombre, versi´n y distribuidor son obligatorios y el SLEE los usa o para la identificaci´n del evento. El campo de la descripci´n es opcional, pero se reo o comienda completarlo para permitir una r´pida identificaci´n del evento en el futuro. a o Tras completar estos campos, presione “Next” para modificar los campos CMP de la especificaci´n del proceso. o Figura C.16: CMP del perfil. Para a˜adir un campo CMP, pinche en “Add”. Esto a˜adir´ una fila en blanco a la n n a tabla. Para editar el nombre del campo pinche en la columna “Name” de la fila que desea modificar, introduzca el nombre y presione enter. El tipo se puede editar del mismo modo. El campo ”Visible“ controla la visibilidad para los clientes de gesti´n. El campo o “Indexed” especifica si el campo CMP es o no un atributo indexado. El valor “yes”
- 329. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 291 en el campo “Unique” indica que el valor almacenado en este campo debe ser unico ´ entre todos los perfiles de esa especificaci´n de perfiles. Por favor, lea la especificaci´n o o de JAIN SLEE para m´s detalles de estos par´metros. a a Si la especificaci´n de perfil requiere un manejo personalizado de clases abstractas, o active “Create abstract management class”. Presione “Finish” para crear la especificaci´n de perfil. o Figura C.17: Perfil completo.
- 330. 292 ANEXO C. ECLIPSLEE Para compilar y empaquetar, hay que hacer doble click en el archivo build.xml, lo que abrir´ dicho archivo. A continuaci´n click con el bot´n derecho en “build-Testa o o Profile-spec” en la ventana “Outline” a la derecha de la pantalla y escogiendo “Run 1. Ant Build” del men´ emergente como se muestra debajo. u Figura C.18: Construcci´n del perfil. o El perfil debe haberse construido para usarlo en un SBB. El perfil creado se puede encontrar en el directorio de jars en la ra´ del proyecto. Puede ser necesario actualizar ız el contenido de esta carpeta haciendo click con el bot´n derecho y seleccionando “Reo fresh”.
- 331. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE C.2.3. 293 Creando un SBB en JAIN SLEE Antes de crear un bloque de construcci´n de servicios (SBB) se tiene que haber o creado y configurado un proyecto JAIN SLEE como se describe en Creando un proyecto JAIN SLEE. Tambi´n hay que asegurarse de que cualquier componente externo e requerido est´ instalado. a Bot´n derecho en el paquete deseado y escoja “New Other...” como se muestra o debajo. Figura C.19: Nuevo SBB.
- 332. 294 ANEXO C. ECLIPSLEE Expanda “JAIN SLEE” si es necesario, y escoja “JAIN SLEE Service Building Block (SBB)” como se muestra en la siguiente figura. Haga click en “Next”. Figura C.20: Nuevo SBB. Aparecer´ el siguiente di´logo: a a Figura C.21: Nombre del archivo del SBB.
- 333. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 295 El directorio de origen y el paquete se rellenar´n autom´ticamente si escogi´ “New a a o Other...” al pinchar con el bot´n derecho en un paquete. De otra manera, necesio tar´ escogerlos seleccionando “Browse...” y buscando la ubicaci´n deseada. a o D´ un nombre al SBB; el nombre debe acabar en “Sbb.java”. Despu´s, haga click e e en “Next” para editar la identificaci´n del componente, como se muestra abajo: o Figura C.22: Identificaci´n del SBB. o Los campos de nombre, versi´n y distribuidor son obligatorios y el SLEE los usa o para la identificaci´n del SBB. El campo de la descripci´n es opcional, pero se recomieno o da completarlo para permitir una identificaci´n r´pida del SBB en el futuro. o a Despu´s de completar estos campos, presione “Next” para especificar los arhivos de e clases del SBB. Figura C.23: Clases del SBB.
- 334. 296 ANEXO C. ECLIPSLEE Este di´logo le permite especificar si este SBB requiere un SBB local y personala izado y/o un interfaz de contexto de actividad. Seleccione los interfaces requeridas y presione “Next” para editar los campos CMP del SBB. Figura C.24: CMP del SBB. Aqu´ se pueden fijar los campos CMP del SBB. A˜ada un campo CMP presionanı n do en “Add”. Un campo se puede eliminar seleccion´ndolo en la tabla y presionando a “Remove”. Para modificar un campo CMP, presionar el bot´n “Modify” que est´ en la o a tabla a continuaci´n del campo. o Figura C.25: Di´logo CMP del SBB. a D´ un nombre al campo CMP en el campo de texto “Name”. Un campo CMP puede e ser un objeto Java est´ndar, un tipo primitivo o un objeto local del SBB. Seleccione la a opci´n que representa el tipo de datos que se va a almacenar en el campo. o Un objeto Java est´ndar o un tipo primitivo requieren que se introduzca el nombre a cualificado del tipo de datos en su totalidad en el campo de texto “Type”. Por ejemplo, “java.lang.String”. Un campo CMP que almacena un objeto local del SBB s´lo debe almacenar SBB o con una identidad espec´ ıfica. El men´ desplegable SBB contendr´ todos los SBB que u a el plugin fue capaz de encontrar. Escoja el que deba ser almacenado en el campo CMP
- 335. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 297 y d´le un “Scoped Name”. Este ser´ el nombre de la variable y deber´ ser un nombre e a a de variable v´lido en Java, y deber´ empezar con una letra min´scula. a a u Si un SBB necesita almacenar un SBB de su propio tipo en un campo CMP, entonces el SBB se debe crear sin ese campo CMP, y el campo CMP a˜adido posteriormente, n despu´s de que el SBB ha sido compilado y el directorio de “jars” actualizado. Esto es e porque el plugin necesita ver una versi´n compilada de un SBB antes de a˜adirlo como o n un tipo para los campos CMP. Una vez que el campo CMP es correcto, presione “Ok” y la p´gina del asistente de a CMP se actualizar´ con los nuevos datos. a Repetir hasta que se han creado todos los campos CMP, y a continuaci´n presione o “Next” para editar los par´metros de uso del SBB: a Figura C.26: Uso del SBB. Active “Create SBB usage interface” si necesita el interfaz de uso del SBB. A continuaci´n a˜ada par´metros de uso presionando “Add” y modificando los valores de la o n a tabla. Est´n disponibles 2 tipos de par´metros: “increment” y “sample”. a a
- 336. 298 ANEXO C. ECLIPSLEE Presione “Next” para pasar al di´logo de selecci´n de evento, mostrado debajo: a o Figura C.27: Eventos del SBB El di´logo de selecci´n de evento contiene una lista de todos los eventos que el plua o gin pudo encontrar en su proyecto. Esto incluye cualquier evento que se instal´ como o componente externo. Si sus eventos personalizados no est´n listados, verifique que han a sido compilados y el directorio de jars actualizado.
- 337. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 299 Para cada evento que usted desea que su SBB sea capaz de lanzar o recibir: 1. Seleccione el evento en la tabla de eventos disponibles. 2. Presione “Select Event”; el evento se mover´ a la tabla de eventos seleccionados. a 3. Presione “Modify...” para ese evento en la tabla de eventos seleccionados. Esto crear´ el siguiente di´logo: a a Figura C.28: Di´logo de eventos del SBB a 4. Revise el “Scoped Name” y c´mbielo si lo desea. a 5. Decida la direcci´n del evento. o 6. Si la direcci´n del evento es “Receive” o “FireAndReceive” active “This is an o initial event” si debe ser un evento inicial para un servicio. 7. Si es un evento inicial, escoja uno o m´s selectores de eventos iniciales. a 8. Presione “OK”
- 338. 300 ANEXO C. ECLIPSLEE Cuando todos los eventos hayan sido configurados, el di´logo deber´ asemejarse a a ıa la siguiente figura: Figura C.29: Eventos del SBB
- 339. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 301 Presione “Next” para definir la especificaci´n de perfil del SBB. o Figura C.30: Perfil del SBB El di´logo de selecci´n de perfil contiene una lista de todos los perfiles que el plugin a o pudo encontrar en su proyecto. Esto incluye cualquier perfil instalado como componente externo. Si sus perfiles personalizados no est´n listados, verifique que han sido a compilados y la carpeta de “jars” ha sido actualizada. Para cada especificaci´n de perfil que el SBB debe referenciar: o 1. Seleccionar la especificaci´n del perfil en la tabla de perfiles disponibles. o 2. Hacer click en “Select Profile” 3. Revise el “Scoped Name” y c´mbielo si lo desea. a Si su SBB debe contener una direcci´n de especificaci´n de perfil, selecci´nelo en la o o o lista desplegable. Presione “Next” para continuar al di´logo del SBB hijo. a El di´logo de selecci´n de hijos contiene una lista de todos los SBB que el plugin a o pudo encontrar en su proyecto. Esto incluye cualquier SBB instalado como componente externo. Si sus SBBs personalizados no est´n listados, verifique que han sido compilaa dos y la carpeta de “jars” ha sido actualizada. Para cada SBB hijo que el SBB debe referenciar: 1. Seleccione el SBB en la tabla de SBBs disponibles. 2. Presione “Select SBB” 3. Revise el “Scoped Name” y c´mbielo si lo necesita. a
- 340. 302 ANEXO C. ECLIPSLEE Figura C.31: SBB hijo. 4. Escoja la prioridad por defecto del SBB hijo.
- 341. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 303 Presione “Next” para pasar al di´logo de tipos de adaptador de recursos. a Figura C.32: Tipos de SBB RA. El di´logo de selecci´n de hijos contiene una lista de todos los adaptadores de rea o cursos (Resource Adaptors, RA) que el plugin pudo encontrar en su proyecto. Esto incluye cualquier RA instalado como componente externo. Si sus tipos de adaptadores de recursos personalizados no est´n listados, verifique que han sido compilados y la a carpeta de “jars” ha sido actualizada.
- 342. 304 ANEXO C. ECLIPSLEE Para cada tipo adaptador de recursos que el SBB deba referenciar: 1. Seleccione el tipo de adaptador de recursos en la tabla de tipos de adaptadores de recurso disponibles. 2. Presione “Select RA Type” 3. Opcionalmente, especifique el nombre de la factoria de interfaces de contexto de actividad. 4. Si el RA Type tiene enlaces de entidades con otros resource adaptos, presione “Edit Bindings...”. Figura C.33: Enlaces del RAType del SBB. 5. Para cada enlace: a) Haga click en “Add” para crear un nuevo enlace. b) Especifique el nombre del objeto JNDI del enlace. c) Opcionalmente, especifique el nombre del enlace de la entidad del adaptador de recursos. 6. Presione “OK” para aplicar estos enlaces al tipo de adaptador de recursos. Presione “Next” para editar las entradas de entorno del SBB. A˜ada una entrada de entorno con el bot´n “Add”. Escriba su nombre, tipo, valn o or y, opcionalmente, la descripci´n en la tabla. Haga esto para cada entrada de entorno. o
- 343. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 305 Figura C.34: Entradas de entorno del SBB. Presione “Finish” para crear el SBB. N.B. Se puede presionar “Finish” en cualquier momento tras especificar la identificaci´n del SBB si se requiere un esqueleto de SBB. No es necesario completar previao mente todas las p´ginas del asistente. a Para compilar y empaquetar un SBB, haga doble click en el archivo build.xml. Esto abrir´ el archivo build. A continuaci´n, haga click con el bot´n derecho en “build-Testa o o sbb” en la ventana Outline en la parte derecha de la pantalla. Escoja “Run 1. Ant Build” del men´ emergente. u N.B. El SBB debe construirse para poder seleccionarlo como SBB ra´ de un servicio ız (tambi´n debe tener un evento inicial para ser un SBB ra´ El SBB construido puede e ız). encontrarse en el directorio jars en la ra´ del proyecto. Puede ser necesario forzar una ız actualizaci´n del contenido de este directorio presionando con el bot´n derecho en ´l y o o e seleccionando “Refresh”.
- 344. 306 ANEXO C. ECLIPSLEE Figura C.35: SBB completado. C.2.4. Creando un servicio JAIN SLEE Antes de poder crear un servicio JAIN SLEE, se tiene que haber creado y configurado un proyecto JAIN SLEE tal como se describe en Creando un proyecto JAIN SLEE. Adem´s, aseg´rese de que cualquier componente externo necesario est´ instalado. a u a Finalmente, el SBB ra´ de su servicio debe haber sido compilado y estar disponible ız en el directorio jars de su proyecto. Click con el bot´n derecho en el paquete deseado y escoja “New Other...” como o se muestra debajo.
- 345. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 307 Figura C.36: Nuevo servicio. Expanda “JAIN SLEE” si es necesario, y escoja Servicio XML de JAIN SLEE: Figura C.37: Nuevo servicio. El di´logo para el nombre del servicio y la ubicaci´n aparecer´ como se muestra a a o a continuaci´n: o
- 346. 308 ANEXO C. ECLIPSLEE Figura C.38: Nombre del servicio. Complete el directorio de origen y el paquete si es necesario seleccionando “Browse...”. D´ un nombre al servicio; el nombre debe terminar en “Service.xml”, despu´s, haga e e click en “Next” para especificar la identificaci´n del servicio SLEE. o Figura C.39: Identificaci´n del servicio. o Los campos de nombre, distribuidor y versi´n son obligatorios y el SLEE los usa o para identificar el servicio. El campo de la descripci´n es opcional, pero altamente reo comendado para permitir la f´cil identificaci´n del servicio en el futuro. a o Una vez que estos campos est´n completos, presione “Next” para seleccionar un a SBB ra´ ız.
- 347. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 309 Figura C.40: Ra´ del servicio. ız Todos los SBB ra´ disponibles se muestran en la tabla. Escoja aquel que deba usız arse para este servicio. N.B. Si su SBB no est´ listado, compruebe lo siguiente: a ¿El SBB tiene al menos un evento inicial? Esto es, un evento cuya direcci´n sea o “Receive” o “FireAndReceive”, marcado como “Initial-event” y con al menos un selector de evento inicial. ¿El SBB ha sido compilado y se muestra como disponible en el directorio “jars”? Si no lo est´, constr´yalo y actualice el directorio “jars”. a u Especifique la prioridad del evento por defecto, y, si est´ disponible para su SBB, a active o desactive “Specify service address profile table” en funci´n de sus necesidades. o Presione “Finish” para crear el servicio. El servicio es el unico componente que no necesita ser construido antes de ser usado. ´
- 348. 310 ANEXO C. ECLIPSLEE Figura C.41: Servicio completado. C.2.5. Creando una unidad desplegable de JAIN SLEE Antes de poder crear una unidad desplegable de JAIN SLEE, se tiene que haber creado y configurado un proyecto JAIN SLEE tal como se describe en Creando un proyecto JAIN SLEE. Tambi´n, aseg´rese de que cualquier componente externo necee u sario est´ instalado. a Una unidad desplegable se usa para instalar componentes en un JAIN SLEE. Una unidad desplegable contiene: Cero o m´s eventos a Cero o m´s especificaciones de perfil a Cero o m´s SBBs a Cero o m´s servicios a Cero o m´s adaptadores de recursos a Cero o m´s tipos de adaptadores de recursos a
- 349. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 311 Este plugin crear´ unidades desplegables que contengan eventos, especificaciones de a perfil, SBBs y servicios, pero no adaptadores de recursos ni tipos de adaptadores de recursos. Antes de poder crear una unidad desplegable (DU) de JAIN SLEE, se tiene que haber creado y configurado un proyecto JAIN SLEE tal como se describe en Creando un proyecto JAIN SLEE. Presione con el bot´n derecho en el paquete deseado y escoja “New Other...” o como se muestra debajo Figura C.42: Nueva unidad desplegable.
- 350. 312 ANEXO C. ECLIPSLEE Expanda “JAIN SLEE” si es necesario, y escoja “JAIN SLEE Deployable Unit” como se muestra en la imagen siguiente, y luego presione “Next”. Figura C.43: Nueva unidad deplegable. Aparecer´ el siguiente di´logo: a a Figura C.44: Nombre de la DU
- 351. C.2. CREANDO UN NUEVO PROYECTO JAIN SLEE 313 Seleccione el directorio de origen y el paquete si no lo est´n. D´ un nombre a la a e unidad desplegable; el nombre debe acabar en “-deployable-unit.xml”. Presione “Next” para seleccionar los jars de los componentes a incluir. Figura C.45: Componentes de la DU. Selecciona los jars de los componentes necesarios presionando en la columna “Selected” de cada fila, de tal manera que el texto bajo esa columna sea “Yes”. N.B. Normalmente no es necesario incluir el jar de los eventos de jainsip, o jars similares, ya que el adaptador de recursos que contiene esos eventos normalmente los instalar´ en el SLEE por separado para cualquier servicio que use ese adaptador de a recursos o sus eventos.. Presione “Next” para seleccionar cualquier servicio que quiera a˜adir. n Figura C.46: Servicios de la DU.
- 352. 314 ANEXO C. ECLIPSLEE Escoja cualquier servicio necesario del mismo modo que para los jars de los componentes. Una unidad desplegable puede contener cero o m´s servicios. a Presione “Finish” para crear la unidad desplegable. Figura C.47: DU completada. La unidad desplegable debe compilarse antes de poder instalarla en el SLEE. Esto se puede hacer presionando dos veces en el archivo de construcci´n ant “build.xml” en o la ra´ del proyecto. Despu´s, presione con el bot´n derecho en “build-Test-deployableız e o unit” en la columna de la derecha de la ventana del Eclipse y seleccione “1. Ant Build”. El archivo jar resultante se ubicar´ en el directorio jars. Este directorio puede necea sitar ser actualizado antes de que se pueda ver el archivo comprimido. Esto se puede hacer presionando con el bot´n derecho en la carpeta y seleccionando “Refresh” del o men´ emergente. u Este archivo jar se puede instalar en el SLEE usando cualquiera de los m´todos de e instalaci´n de componentes SLEE, como el control de gesti´n de Rhino o una interfaz o o web. Aseg´rese de que todos los adaptadores de recursos necesarios est´n instalados u a antes de intentar instalar el nuevo componente. Instalando el RA local de JAIN SIP: [cath@hex: /rhino] cd examples/sip [cath@hex: /rhino/examples/sip] ant deploysipra Instalando la DU de prueba: [cath@hex: /rhino] ./manage.sh -install file:///tmp/Test-DU.jar installed: DeployableUnit[url=file:///tmp/ DU.jar] Activando el servicio Test: [cath@hex: /rhino] ./manage.sh -activateService ’Test Service, 1.0, Open Cloud Ltd.’
- 353. C.3. HACIENDO DISPONIBLES COMPONENTES EXTERNOS C.3. 315 Haciendo disponibles componentes externos Normalmente ser´ necesario usar componentes externos en un SBB, como los adapa tadores de recursos de SIP. Este documento describe el proceso para poner estos componentes a disposici´n del plugin del Eclipse. o Los componentes externos vienen en dos tipos b´sicos de paquetes: a Unidades desplegables Archivo jar de componente La unidad desplegable es un archivo jar que se puede instalar en un JAIN SLEE. Este jar contiene al menos lo siguiente: META-INF/deployable-unit.xml El archivo jar de componente contiene uno o m´s tipos de componentes, como un a evento, un SBB o una especificaci´n de perfil. Un jar de componentes debe contener al o menos uno de los siguientes: META-INF/event-jar.xml META-INF/profile-spec-jar.xml META-INF/sbb-jar.xml META-INF/resource-adaptor-type-jar.xml
- 354. 316 C.3.1. ANEXO C. ECLIPSLEE Instalando jars de unidades desplegables Presione con el bot´n derecho en el proyecto JAIN SLEE al que desea a˜adir la o n unidad desplegable, y seleccione “Properties” del men´ emergente como se muestra u debajo. Figura C.48: Propiedades.
- 355. C.3. HACIENDO DISPONIBLES COMPONENTES EXTERNOS 317 Escoja “JAIN SLEE” de las opciones que aparecen a mano izquierda. Esto le mostrar´ el siguiente di´logo: a a Figura C.49: Propiedades. A˜ada una nueva unidad desplegable presionando “Add DU”, lo que le muestra un n di´logo de selecci´n de archivo: a o Figura C.50: Propiedades.
- 356. 318 ANEXO C. ECLIPSLEE Seleccione la unidad desplegable necesaria y haga click en “OK”: Figura C.51: Propiedades. Una vez que todas las unidades desplegables han sido seleccionadas, presione “OK” para instalarlas en el proyecto. A partir de ahora se mostrar´n como archivos jar dea pendientes del proyecto en la ventana de paquetes. Tambi´n estar´n disponibles en un e a subdirectorio de la carpeta “lib/DU” en el proyecto.
- 357. C.3. HACIENDO DISPONIBLES COMPONENTES EXTERNOS 319 Figura C.52: Propiedades. Instalando los jars de componentes Los archivos jar de componentes se pueden copiar directamente en la carpeta “lib”. N.B. Si se hace esto fuera del programa Eclipse, ser´ necesarios actualizar el direca torio “lib” posteriormente presionando con el bot´n derecho y seleccionando “Refresh” o del men´ emergente. u
- 359. Anexo D Sistemas Gestores de Archivos D.1. Bases de datos y MySQL D.1.1. ¿Qu´ es una base de datos? e Una Base de Datos (BD) es un almac´n de informaci´n orientado tanto a la ine o serci´n como a la eliminaci´n de los datos. Dicha informaci´n se guarda en ficheros y o o o para acceder a dicha informaci´n se accede a posiciones aleatorias de los mismos, en o funci´n de la ubicaci´n de los datos. Los programas que muestran dicha informaci´n se o o o denominan Sistemas Gestores de Bases de Datos (SGBD). Para acceder a dichos datos, se cre´ un lenguaje determinado, el SQL1 . o D.1.2. Caracter´ ısticas de una base de datos Dado que las bases de datos son similares a los servicios de directorio en cuanto a que su finalidad es almacenar informaci´n, comparten muchas de las caracter´ o ısticas. A continuaci´n aparece una breve descripci´n de ellos: o o Din´mico: Una base de datos es din´mica. Se actualiza en tiempo real. Puede a a consultarse en cualquier momento, sabiendo que la informaci´n va a estar actuo alizada. Flexible: En una base de datos se puede meter todo tipo de informaci´n, y amo pliarla sin mucho esfuerzo. Tambi´n tienen flexibilidad a la hora de organizar los e datos, puesto que nos permite organizarlos como queramos mediante las tablas. Seguro: Las bases de datos permiten un mayor control sobre el acceso a los datos, pudi´ndose poner restricciones a los usuarios en funci´n de quienes son o incluso e o en funci´n de las tablas que pueden ver. o Distribuci´n: Las bases de datos pueden fragmentarse para guardar la informaci´n o o por separado, pero la complicaci´n es mayor que con los servicios de directorio. o 1 Structured Query Language 321
- 360. 322 ANEXO D. SISTEMAS GESTORES DE ARCHIVOS Rendimiento: Las bases de datos deben de estar preparadas para procesar cientos, incluso miles de operaciones por segundo. Est´ndares: al poder consultarlos desde multitud de ubicaciones es imprescindible a que cumplan los est´ndares. a Relaci´n Lecturas/Escrituras: A pesar de que est´n preparadas para soportar o a las b´squedas (lecturas) especialmente las consultas, los algoritmos de escritura u tambi´n est´n optimizados, pues deben ser igualmente eficaces. Esto se debe a la e a versatilidad de las bases de datos en cuanto a su funci´n. o Debido al acceso multiple simult´neo a los mismos registros, deben implementar a mecanismos para evitar las inconsistencias, bloqueos, ... D.1.3. MySQL MySQL es un sistema gestor de bases de datos de c´digo libre de amplia difusi´n y o o f´cil integraci´n con otros servicios, bien sea en programas, mediante el uso de APIs,por a o ejemplo Connector/J para Java, o bien como servidor, ejecut´ndolo junto con PHP y a el servidor Apache para servir p´ginas web. a Recientemente han dividido su producci´n en 2 SGBDs, la versi´n Enterprise, con o o soporte, y la versi´n Community, sin soporte, pero libre. Nosotros usaremos la 2ª opci´n. o o M´s adelante explicaremos los pasos a realizar. a D.1.4. Instalaci´n o El primer paso es seleccionar la versi´n a instalar. En nuestro caso escogeremos la o ultima versi´n disponible del Community server de MySQL (la versi´n libre de dicho ´ o o servidor) en el momento en que empezamos a trabajar con ella, que era la versi´n o 5.0.37. Dado que estamos usando windows, seleccionaremos descargar los instaladores binarios para dicha plataforma, lo que simplificar´ la instalaci´n. a o Tras descargar correctamente los archivos y, opcionalmente, realizar la comprobaci´n md5 para comprobar que el archivo est´ en perfecto estado, procederemos a su o a desempaquetado y ejecuci´n del archivo Setup.exe que viene en su interior. o
- 361. D.1. BASES DE DATOS Y MYSQL 323 Lo primero que nos aparece es la pantalla de bienvenida a la aplicaci´n de instao laci´n de MySQL 5.0 (D.1). o Figura D.1: Pantalla de bienvenida al instalador Cuando presionamos en el bot´n Next nos muestra la pantalla de selecci´n del tipo o o de la instalaci´n. Aqu´ podemos seleccionar diversas opciones para instalar nuestro o ı equipo (D.2). Typical: Es el tipo de instalaci´n que viene seleccionado por defecto y el que o usaremos. Tiene preseleccionadas las opciones gen´ricas de una base de datos de e este tipo. Complete: Se instalan todas las herramientas y documentaci´n que tiene disponibles. o Es el tipo de instalaci´n que m´s espacio usa en el disco. o a Custom: Seleccionando esta opci´n nos permite hacer una instalaci´n personalo o izada. Nos permite configurar desde los componentes que deseamos instalar hasta la ubicaci´n de los archivos. o
- 362. 324 ANEXO D. SISTEMAS GESTORES DE ARCHIVOS Figura D.2: Selecci´n del tipo de instalaci´n o o En la siguiente pantalla (D.3). podemos observar las opciones seleccionadas correspondientes al tipo de instalaci´n seleccionado en la pantalla anterior. En caso de que o queramos cambiar alguno de estos par´metros deberemos ir atr´s y seleccionar otra de a a las opciones de instalaci´n, ya que en el modo seleccionado (typical) no se nos permite o escoger la ubicaci´n ni los componentes a instalar. o Figura D.3: Opciones seleccionadas
- 363. D.1. BASES DE DATOS Y MYSQL 325 Cuando presionamos Install, se instalan los componentes seleccionados, mostr´ndose a una barra de progreso de la instalaci´n (D.4). o Figura D.4: Progreso de la instalaci´n o Tras finalizar, se nos muestra una pantalla para registrarnos en MySQL.com con nuestra cuenta. En caso de que no dispongamos de ella, nos permite crear una cuenta, aunque tambi´n permite saltarse este paso con la ultima opci´n, que es la que selece ´ o cionaremos (D.5).
- 364. 326 ANEXO D. SISTEMAS GESTORES DE ARCHIVOS Figura D.5: Registro de usuario Por ultimo, y tras presionar Next en la pantalla anterior, se nos muestra el di´logo ´ a de finalizaci´n de la instalaci´n. Si dejamos marcada la opci´n Configure the MySQL o o o server now a continuaci´n se nos mostrar´ un asistente para la configuraci´n de la base o a o de datos (D.6). Figura D.6: Fin de la instalaci´n o
- 365. D.1. BASES DE DATOS Y MYSQL D.1.5. 327 Configuraci´n de MySQL o Tras la instalaci´n, el siguiente paso es la configuraci´n de la base de datos. Si o o hemos dejado marcada la opci´n Configure the MySQL server now se abrir´ inmedio a atamente el asistente, mostr´ndonos una pantalla de bienvenida (D.7). En caso de que a desmarc´ramos dicha opci´n, siempre podr´ a o ıamos abrirlo desde Inicio → Todos los programas → MySQL → MySQL Server 5.0 → MySQL Server Instance Configuration Wizard. Figura D.7: Pantalla de bienvenida del asistente de configuraci´n o An´logamente al caso de la instalaci´n, existen varias opciones para elegir: a o Detailed Configuration: Permite seleccionar el tipo de base de datos, tipo de servidor, ... Standard Configuration: Tan solo nos permite escoger la contrase˜a y el tipo de n instalaci´n. o Nosotros seleccionaremos la segunda opci´n, Standard Configuration, para facilitar o el proceso de instalaci´n (D.8). o
- 366. 328 ANEXO D. SISTEMAS GESTORES DE ARCHIVOS Figura D.8: Selecci´n del tipo de configuraci´n o o Tras este paso, se nos solicitar´ que escojamos el nombre del servicio, si lo queremos a arrancar al iniciar windows. Tambi´n nos preguntar´ si queremos a˜adir la ruta a la e a n variable PATH, para posterior ejecuci´n desde linea de comandos (D.9). o Figura D.9: Configuraci´n de servicio o En el cuarto paso del proceso de configuraci´n se nos pedir´ que introduzcamos una o a
- 367. D.1. BASES DE DATOS Y MYSQL 329 contrase˜a para el usuario root 2 , que tiene pleno acceso a toda la base de datos, sin n restricciones de ning´n tipo. Debido a esto, deberemos ser cautelosos al trabajar con u este usuario. En caso de que deseemos crear una cuenta de usuario an´nimo, tambi´n o e lo especificaremos aqu´ (D.10). ı Figura D.10: Contrase˜a n En el siguiente paso se nos muestra una lista con las tareas que el sistema efectuar´ autom´ticamente cuando presionemos Execute. (D.11) a a 2 En caso de haber una contrase˜a previa, tambi´n se nos solicitar´ dicha contrase˜a, por motivos n e a n de seguridad
- 368. 330 ANEXO D. SISTEMAS GESTORES DE ARCHIVOS Figura D.11: Estado de la configuraci´n o Por ultimo se nos mostrar´ el estado de la instalaci´n de nuestro programa. En caso ´ a o de que nos de alg´n error tambi´n se mostrar´ aqu´ En el momento en que presionemos u e a ı. Finish se nos cerrar´ el asistente de configuraci´n y podremos comenzar a usar MySQL. a o Figura D.12: Fin de la instalaci´n o
- 369. D.2. SERVICIOS DE DIRECTORIO Y LDAP D.2. Servicios de directorio y LDAP D.2.1. 331 ¿Qu´ es un servicio de directorio? e Un directorio es un almac´n de datos, al estilo de las bases de datos, pero cone tiene informaci´n m´s descriptiva y basada en atributos. La caracter´ o a ıstica principal a destacar de un servicio de directorio es que se lee mucho m´s de lo que se escribe. a Ejemplos de servicios de directorio cl´sicos pueden ser las listas de tel´fonos que proa e porcionan los operadores, o las gu´ de televisi´n semanales. ıas o Los servicios de directorio est´n preparados para proporcionar una respuesta r´pida a a a operaciones de b´squeda o consulta. Esto implica que las operaciones de inserci´n y u o actualizaci´n sean m´s costosas, computacionalmente hablando. o a D.2.2. Caracter´ ısticas de un servicio de directorio Dado que la funci´n de las bases de datos y los directorios son similares, como parten caracter´ ısticas comunes, aunque dependiendo de la naturaleza de cada uno, tendr´n otras distintas. A continuaci´n hay una breve descripci´n de las principales a o o caracter´ ısticas de un servicio de directorio. Din´mico: Un servicio de directorio es din´mico. Se actualiza en tiempo real. a a Puede consultarse en cualquier momento, sabiendo que la informaci´n va a estar o actualizada. Flexible: En un directorio se puede meter todo tipo de informaci´n, y ampliarla o sin mucho esfuerzo. Tambi´n tienen flexibilidad a la hora de organizar los datos, e puesto que nos permite organizarlos como queramos. Seguro: Los directorios electr´nicos permiten un mayor control sobre el acceso a o los datos, pudi´ndose poner restricciones a los usuarios. e Configurable: Los directorios electr´nicos permiten cambiar la configuraci´n ino o terna en cualquier momento: los datos que contiene, la informaci´n que puede ver o una persona, ... Distribuci´n: Los servicios de directorios permiten almacenar informaci´n en o o m´ltiples servidores, comunic´ndose entre ellos (si est´n configurados para elu a a lo). El proceso de replicaci´n o duplicaci´n permite la consistencia de los datos o o entre los servidores, aunque para ello deba haber inconsistencias temporales. Rendimiento: Los directorios deben de estar preparados para procesar cientos, incluso miles de operaciones por segundo. L´gicamente, para proporcionar tal o cantidad de operaciones los directorios deben implementar alg´n tipo de concuru rencia. Est´ndares: al poder consultarlos desde multitud de ubicaciones es imprescindible a que cumplan los est´ndares. a
- 370. 332 ANEXO D. SISTEMAS GESTORES DE ARCHIVOS Relaci´n Lecturas/Escrituras: La proporci´n de lecturas frente a escrituras deo o cae claramente a favor de las lecturas. En este tipo de servidores se deben servir muchas m´s peticiones de lectura que de escritura, pues es su principal caraca ter´ ıstica. D.2.3. LDAP y LDIF LDAP3 , es un protocolo de tipo cliente-servidor que proporciona los mecanismos necesarios para acceder a un servicio de directorio y recuperar la informaci´n all´ alo ı macenada. Al igual que en los sistemas de archivos un archivo se identifica por la ruta completa, comprendida por el nombre de todas las carpetas que lo albergan, en los servicios de directorio un nodo se identifica por el nombre distinguido, que es la concatenaci´n del o nombre de todos sus nodos padres. Un ejemplo: o=TUDelft, c=NL objectClass=organization o=TUDelft description=Technical University of Delft Netherlands cn=Postmaster, o=TUDelft, c=NL objectClass=organizationalRole cn=Postmaster description= TUDelft postmaster - [email protected] Este c´digo insertar´ 2 nodos en el ´rbol con la ayuda de un cliente LDAP. Uno ser´ o ıa a ıa TUDelft, como una organizaci´n. El siguiente ser´ el postmaster de dicha organizaci´n, o ıa o dependiente del anterior. Para la inserci´n de dichos nodos se guardar´ este c´digo en o ıa o un archivo y se usar´ el comando ldapadd para la inserci´n en el servicio de directorio. ıa o LDIF, LDAP Data Interchange Format, es el formato en que utiliza para la importaci´n y exportaci´n de datos a los servidores LDAP, independientemente de donde o o est´n ubicados o la implementaci´n que sigan. Sigue un formato similar al anterior, e o pero este ser´ aceptable por todos los servidores LDAP. ıa dn: cn=Barbara J Jensen, o=University of Michigan, c=US cn: Barbara J Jensen cn: Babs Jensen objectclass: person sn: Jensen dn: cn=Bjorn J Jensen, o=University of Michigan, c=US cn: Bjorn J Jensen cn: Bjorn Jensen 3 Lightwaight Directory Access Protocol
- 371. D.2. SERVICIOS DE DIRECTORIO Y LDAP 333 objectclass: person sn: Jensen dn: cn=Jennifer J Jensen, o=University of Michigan, c=US cn: Jennifer J Jensen cn: Jennifer Jensen objectclass: person sn: Jensen Esto insertar´ 3 nodos en un servicio de directorio, todos ellos al mismo nivel. ıa D.2.4. Directorio vs Bases de datos Los directorios est´n optimizados para accesos en lectura, frente a las bases de a datos convencionales, que se encuentran optimizadas para lectura y escritura. Los directorios suelen almacenar informaci´n relativamente est´tica, que cambia o a con poca frecuencia, a diferencia de las bases de datos. Los directorios no soportan transacciones (operaciones para control de una operaci´n compuesta de varios pasos. O se ejecuta completa, o no se ejecuta). o El lenguaje SQL permite el desarrollo de complicadas funciones de b´squeda y acu tualizaci´n, mientras que el LDAP es un protocolo simplificado para la aplicaci´n o o de consultas peque˜as y simples. n D.2.5. Instalaci´n de LDAP o Debido a la necesidad de programar nuestras propias aplicaciones para que accedan al servicio de directorio LDAP, y al uso de Java, decidimos usar un servidor LDAP que tuviera disponible una API para poder implementar la funcionalidad en nuestro servicio. El servidor escogido fue el servidor de c´digo libre LDAP. La instalaci´n de o o este servicio sobre Linux se puede realizar de 2 maneras: Servicio de Linux: Fue nuestra primera opci´n. Usamos un gestor de paquetes o (Synaptic) para instalar el servicio sobre un servidor que estaba ejecutando Ubuntu Linux. Instalaci´n manual de paquetes en Linux: Nuestro siguiente paso fue bajarnos los o paquetes e intentar instalarlos manualmente. En nuestro caso, fuimos incapaces de configurar completamente el servicio de directorio debido a la necesidad de OpenLDAP (SLAPD) de usar una base de datos (BerkeleyDB) de la que no fuimos capaces de obtener el instalador de ninguna fuente.
- 372. 334 ANEXO D. SISTEMAS GESTORES DE ARCHIVOS
- 373. Anexo E Handlers de Mobicents E.1. Mobicents CLI E.1.1. Introducci´n o Hay otra herramienta a parte del MMC1 , en l´ ınea de comando, utilizada para ejecutar muchos de los comandos de SLEE JMX. A parte de poder utilizarse en l´ ınea de comandos, esta herramienta esta implementada en el proyecto principal de Mobicents, y su principal tarea es proporcionar un medio para automatizar el despliegue de los ejemplos: Ras, servicios, crear/borrar perfiles,...Todo ello implementado en el build.xml del ejemplo, logrando as´ englobar ı tareas repetitivas y ahorrando mucho tiempo al desarrollador, ya que se evita el tener que ir directorio a directorio desplegando los distintos componentes que intervienen en el ejemplo, reduciendo todo ello a una l´ ınea: ant ¡target¿ E.1.2. Invocar comandos de Slee JMX mediante CLI El modo de usar el CLI es el siguiente. Usar: java -jar mobicents-cli.jar -¡command¿¡args¿ Comandos validos: -startSlee -stopSlee -install ¡url¿ -uninstall ¡Deployment ID¿ -uninstall ¡url¿ -getDescriptor ¡Deployment ID¿ -getDeploymentId ¡file url¿ -activateService ¡Service ID¿ 1 Mobicents Management Console 335
- 374. 336 ANEXO E. HANDLERS DE MOBICENTS -deactivateService ¡Service ID¿ -getServiceState ¡Service ID¿ -setTraceLevel ¡Component ID¿¡level¿ -getTraceLevel ¡Component ID¿ -createRaEntity ¡ResourceAdaptor ID¿¡entity name¿¡props¿ -activateRaEntity ¡entity name¿ -deactivateRaEntity ¡entity name¿ -removeRaEntity ¡entity name¿ -createRaLink ¡link name¿¡entityname¿ -removeRaLink ¡link name¿ -createProfileTable ¡ProfileSpecification ID¿¡profile table name¿ -removeProfileTable ¡profile table name¿ -createProfile ¡profile tablename¿¡profile name¿ -removeProfile ¡profile table name¿¡profile name¿ El c´digo fuente se encuentra en mobicents-examples/mobicents-cli. o Despu´s de ejecutar el archive build.xml usando Ant obtendr´s el siguiente fichero e a jar: mobicents-cli.jar. Puedes usar el CLI en los siguientes casos: E.1.2.1. Un ejemplo para el tipo ID java -jar mobicents-cli.jar -install “file:/C:/.../mobicents-examples/.../jars/...-DU.jar” java -jar mobicents-cli.jar -uninstall “file:/C:/.../mobicents-examples/.../jars/...-DU.jar” o para desinstalar java -jar mobicents-cli.jar -uninstall “DeployableUnitID[#]” java -jar mobicents-cli.jar -getDescriptor “DeployableUnitID[#]” java -jar mobicents-cli.jar -getDeploymentId “file:/C:/.../mobicents-examples/.../jars/...DU.jar” java -jar mobicents-cli.jar -activateService “ServiceID[Name#Vendor#Version]” java -jar mobicents-cli.jar -deactivateService “ServiceID[Name#Vendor#Version]” java -jar mobicents-cli.jar -getServiceState “ServiceID[Name#Vendor#Version]” java -jar mobicents-cli.jar -setTraceLevel “¡ComponentID¿[Name#Vendor#Version]” “¡level¿” java -jar mobicents-cli.jar -getTraceLevel “¡ComponentID¿[Name#Vendor#Version]”
- 375. E.1. MOBICENTS CLI E.1.2.2. 337 Resource Adaptor MBean java -jar mobicents-cli.jar -install “file:/C:/.../sip-ra-type.jar” java -jar mobicents-cli.jar -install “file:/C:/.../sip-local-ra.jar” java -jar mobicents-cli.jar -createRaEntity “ResourceAdaptorID[jainsip#NIST#1.1]” “SipRA” java -jar mobicents-cli.jar -activateRaEntity “SipRA” java -jar mobicents-cli.jar -createRaLink “SipRA” “SipRA” java -jar mobicents-cli.jar -removeRaLink “SipRA” java -jar mobicents-cli.jar -deactivateRaEntity “SipRA” java -jar mobicents-cli.jar -removeRaEntity “SipRA” E.1.2.3. Creaci´n de perfiles MBean o java -jar mobicents-cli.jar -createProfileTable “ProfileSpecificationID[Name#Vendor#Version]” “¡profile table name¿” java -jar mobicents-cli.jar -removeProfileTable “¡profile table name¿” java -jar mobicents-cli.jar -createProfile “¡profile table name¿” “¡profile name¿” java -jar mobicents-cli.jar -removeProfile “¡profile table name¿” “¡profile name¿” Notas: DeployableUnitID[#] : # es el n´mero que identifica la unidad desplegable. u ¡ComponentID¿ puede ser: ServiceID, SbbID, ResourceAdaptorID, ResourceAdaptorTypeID,ProfileSpecificationID o EventTypeID. ¡level¿ puede ser: SEVERE (valor m´s alto), WARNING, INFO, CONFIG, FINE, a FINER, FINEST,OFF (valor m´s bajo). a E.1.3. Tareas ANT para el manejo de Mobicents En el directorio mobicents-examples/mobicents-cli/etc encontraras un archivo example.xml. Este es un ejemplo donde puedes ver como usar comandos Slee desde ANT. Puedes hacer funcionar el archivo desde Eclipse o desde l´ ınea de comandos. Recuerda que si ejecutas example.xml desde l´ ınea de comandos tendr´s que escribir a esto: ant -f example.xml -¡target¿
- 376. 338 ANEXO E. HANDLERS DE MOBICENTS E.1.4. Acceso remoto Puedes usar mobicents-cli y tareas Ant para acceder a un SLEE remoto Por Defecto: Host = localhost JNP Port = 1099 Usando mobicents-cli.jar puedes escribir lo siguiente: {java -jar mobicents-cli.jar -host <Host_Name or IP_Address> -jnpPort <Port_Number> -<command> <args>} Para lat tareas Ant puedes ver un comentario al final del archivo example.xml. 1. Copiar el archivo unidad desplegable en el sistema de fichero del host remoto donde esta funcionando SLEE. 2. Proveer de la Url donde la el archive unidad desplegable se encuentra en el host remoto E.1.5. Breve tutorial de la herramienta Mobicents CLI y tareas Ant Mobicents CLI ha sido promocionado al proyecto principal de Mobicents. Puedes verlo en el directorio mobicents/tools/mobicents-cli. El c´digo de los archivos build.xml o y sleemanagement.xml ha sido modificado de acuerdo a ello. Desde ahora puedes usar los comandos de manejo de slee directamente desde el archivo build.xml de tu ejemplo mobicents. E.1.5.1. Pasos b´sicos a 1. Crear la variable de entorno MOBICENTS HOME si es que todav´ no la hab´ ıa ıas creado.Ejemplos: %MOBICENTS_HOME% = C:workspacemobicents $MOBICENTS = /home/workspace/mobicents 2. Importar el archivo Import slee-management.xmle ¡property environment=”system/¿ <property name="mobicents.home" value="${system.MOBICENTS_HOME}"/> <import file="${mobicents.home}/tools/mobicents-cli/sleemanagement.xml"/> 3. Cada tarea de manejo slee depende de las tareas de manejo iniciales del sleemanagement.xml
- 377. E.1. MOBICENTS CLI 339 <target name="slee-management-task" depends="management-init"> <slee-management> ... </slee-management> </target> Ahora veremos las distintas posibilidades: E.1.5.2. Arrancar y Parar Slee <target name="start-slee" depends="management-init"> <slee-management> <changesleestate state="start"/> </slee-management> </target> <target name="stop-slee" depends="management-init"> <slee-management> <changesleestate state="stop"/> </slee-management> </target> E.1.5.3. Desplegar RAs <target name="deployra" depends="management-init"> <slee-management> <install url="${file_url}<root_of_the_file_in_unix_format>/ra-type.jar"/> <install url="${file_url}<root_of_the_file_in_unix_format>/local-ra.jar"/> <createraentity resourceadaptorid="Name#Vendor#Version" entityname="<entity_name>"/> <activateraentity entityname="<entity_name>"/> <bindralinkname linkname="<link_name>" entityname="<entity_name>"/> </slee-management> </target> E.1.5.4. Replegar RAs <target name="remove-link-sipra" depends="management-init"> <slee-management> <unbindralinkname linkname="SipRA"/> <deactivateraentity entityname="SipRA"/> <removeraentity entityname="SipRA"/> <uninstall url="${file_url}<root_of_the_file_in_unix_format> /ra-type.jar"/> <uninstall url="${file_url}<root_of_the_file_in_unix_format> /local-ra.jar"/>
- 378. 340 ANEXO E. HANDLERS DE MOBICENTS </slee-management> </target> E.1.5.5. Desplegar un Servicio <target name="deploy-service" depends="management-init"> <slee-management> <install url="${file_url}<root_of_the_file_in_unix_format> /service-DU.jar"/> <activateservice serviceid="Name#Vendor#Version"/> </slee-management> </target> E.1.5.6. Replegar un Servicio <target name="undeploy-service" depends="management-init"> <slee-management> <deactivateservice serviceid="Name#Vendor#Version"/> <uninstall url="${file_url}<root_of_the_file_in_unix_format> /service-DU.jar"/> </slee-management> </target> E.1.5.7. Crear y Borrar perfiles <target name="create-profile-table" depends="management-init"> <slee-management> <createprofiletable profilespec="Name#Vendor#Version" tablename="<table_name>"/> </slee-management> </target> <target name="create-profile" depends="management-init"> <slee-management> <createprofile tablename="<table_name>" profilename="<profile_name>"/> </slee-management> </target> <target name="remove-profile" depends="management-init"> <slee-management> <removeprofile tablename="<table_name>" profilename="<profile_name>"/> </slee-management> </target> <target name="remove-profile-table" depends="management-init">
- 379. E.1. MOBICENTS CLI 341 <slee-management> <removeprofiletable tablename="<table_name>"/> </slee-management> </target> E.1.5.8. Establecer el nivel de se˜ al n <target name="set-trace-level" depends="management-init"> <slee-management> <settracelevel componentid="Name#Vendor#Version" type="<type>" level="<level>"/> </slee-management> </target> <!-Los tipos de components soportado son: event, ra, ratype, pspec, service, sbb Los tipos de nivel de se~al son: SEVERE, WARNING, INFO, n CONFIG, FINE, FINER, FINEST, OFF --> E.1.5.9. Configurar el SBB Para utilizar esta tarea puedes importer el actual slee-management.xml desde tools/mobicentscli o puedes definer la tarea por ti mismo: <taskdef name="sbbconfigurator" classname="org.mobicents.ant.sbbconfigurator.Task" classpath="${mobicents.home}/tools/ant-tasks/jars/slee-ant-tasks.jar" /> Para establecer un env-entry usa la subtarea “setenventry”. Un ejemplo: <sbbconfigurator sbbdescriptor="sbb-jar.xml"> <setenventry name="domain" newType="java.lang.String" newValue="ptinovacao.pt"/> </sbbconfigurator> Esto establecer´ el env entry con env-entry-name “domain”, en el descriptor SBB a especifico, con el nuevo tipo y valor. Si tienes que especificar mas de un SBB en un descriptor tienes que usar entonces los atributos sbbName y/o sbbVendor y/o sbbVersion para elegir el adecuado. Por ultimo, tu puedes usar el SetEnvEntrySubTask como comienzo para a˜adir n nuevas subtareas que puedas necesitar ( Ej.: polimorfismo de los SBBs- seleccionar el sbb-ref especifico de un conjunto, para convertirse en un SBB hijo)
- 380. 342 ANEXO E. HANDLERS DE MOBICENTS E.2. Mobicents MMC E.2.1. Introducci´n o Mobicents Management Console (MMC) es un subproyecto de Mobicents; Esta aplicaci´n que permite a un administrador interactuar con Slee para realizar funciones de o administraci´n. o La consola es una aplicaci´n basada en web J2EE desplegada en la ejecuci´n de la o o instancia de Apache Tomcat dentro del MicroKernel de Jboss. Un administrador puede conectarse a esta consola mediante http a trav´s de un navegador web cualquiera. e E.2.2. Caracter´ ısticas Mobicents Management Console est´ compuesto de diferentes partes: a E.2.2.1. Slee Estado actual de Slee: parado, iniciando, iniciado, parando Iniciar Slee Parar Slee Cerrar Slee Figura E.1: Slee
- 381. E.2. MOBICENTS MMC E.2.2.2. Unidades Desplegables Figura E.2: Unidades Desplegables Lista de todas las Unidades Desplegables instaladas en Slee Instalar una nueva Unidad Desplegable Buscar una Unidad Desplegable Por cada Unidad Desplegable instalada: ˆ Descripci´n o ˆ Url de donde la unidades desplegable fue instalada ˆ Fecha de la instalaci´n o ˆ Lista de los componentes instalados ˆ Desinstalar la unidad desplegable 343
- 382. 344 ANEXO E. HANDLERS DE MOBICENTS E.2.2.3. Componentes Figura E.3: Componentes Lista de todos los Componentes instalados en Slee Buscar componentes instalados Por cada Componente instalado: ˆ Tipo de componente: Servicio, SBB, Resource Adaptor Type, Resource Adaptor, EventType y Especificaci´n del Perfil. o ˆ Descripci´n o ˆ Nombre ˆ Vendedor ˆ Versi´n o E.2.2.4. E.2.2.4.1. Servicios Administraci´n de los Servicios o Lista de todos los servicios instalados en Slee Por cada Servicio instalado: ˆ Estado del servicio: inactivo, activo, parado. ˆ Activar el servicio ˆ Desactivar el servicio
- 383. E.2. MOBICENTS MMC 345 Figura E.4: Servicios E.2.2.4.2. Administraci´n de los par´metros de uso o a Lista de todos los conjuntos de par´metros definidos por un SBB dado con un a servicio Creaci´n y eliminaci´n de conjuntos de par´metros o o a Por cada conjunto de par´metros a ˆ Lista de todos los par´metros de uso y sus valores a ˆ Reiniciar los valores de los par´metros de uso a Figura E.5: Par´metros a
- 384. 346 ANEXO E. HANDLERS DE MOBICENTS E.2.2.5. Resource Adaptors Lista de todos los Resource Adaptors instalados en Slee Por cada Resource Adaptor instalado: ˆ Nombre ˆ ID ˆ Vendedor ˆ Versi´n o ˆ Fuente ˆ Unidad desplegable Lista de todos los Resource adaptor entities ˆ Nombre ˆ Estado del Resource adaptor entity: inactivo, activo, parado. ˆ Acciones desactivar o eliminar. ˆ Desactivar el servicio Crear Resource adaptor entity Figura E.6: Resource Adaptors
- 385. E.2. MOBICENTS MMC E.2.3. 347 Como instalar la distribuci´n binaria de MMC o 1. la distribuci´n binaria de Mobicents Management Console viene como un fichero o war de una unidad desplegable de la aplicaci´n web J2EE, o “management-console.war”. Este fichero puede ser descargado de est´ P´gina a a 2. Para instalar la consola, solamente pon el fichero management-console.war dentro del directorio %JBOSS HOME %serveralldeploy Jboss lo reconocer´ como una a aplicaci´n web J2EE y lo desplegara dentro de la instancia en ejecuci´n de tomcat. o o 3. Despu´s desplegarlo, se accede a la consola mediante un navegador web en la e direcci´n http://localhost:8080/management-console o E.2.4. Como instalar MMC desde el c´digo fuente o El c´digo fuente de Mobicents Management Console viene como un proyecto Eclipse o con un fichero ant build.xml que gu´ el proceso total de contrucci´n desde la compiıa o laci´n al despliegue. o 1. Descargar el proyecto MMC del repositorio SVN de https://mobicents-management.dev.java.net/svn/mobicents-management/trunk . Usa un cliente SVN, si plan´as usar Eclipse para abrir y compilar el proyecto, e Subclipse es una buena elecci´n. De otra manera, si plan´as montar construir el o e proyecto mediante linea de comandos con ant, puedes usar el cliente SVN Tortoise. 2. Descarga Google Web Toolkit SDK de http://code.google.com/webtoolkit/download.html , inst´lalo y fija la variable del a sistema %GWT HOME % que haga referencia al directorio donde lo instalaste. 3. Aseg´rate de tener el servidor Mobicents en la misma m´quina y tener correcta u a la variable del sistema %JBOSS HOME % 4. Aseg´rate de tener instalado ant. u 5. Construyendo el proyecto Para construir el proyecto con Eclipse, solamente abre el proyecto y ejecuta el build.xml Para construir el proyecto en linea de comandos, ve al directorio del proyecto y escribe ant 6. El objetivo por defecto de ant compilara el proyecto, creando un fichero war de una unidad desplegable de la aplicaci´n web J2EE, y lo desplegar´ dentro de o a Mobicents. La construcci´n puede ser echa a con Mobicents ejecutado o no. o 7. Se accede a la consola mediante un navegador web en la direcci´n o http://localhost:8080/management-console
- 386. 348 ANEXO E. HANDLERS DE MOBICENTS E.2.5. Compatibilidad con navegadores Los componentes del lado del cliente de Mobicents Management Console usan AJAX2 y CSS23 , por lo tanto est´ recomendado usar las ultima versi´n del navega ´ o ador. MMC ha sido probado con Firefox 2 e Interner Explorer 6. Firefox parece funcionar bien, mientras que IE da algunos errores CSS con los bordes de las tablas. E.2.6. Problemas No hemos sido capaces de instalar una nueva Unidad Desplegable, al intentarlo siempre da errores del tipo: Package file: "C:mobicents_all-1-0-00-CR3resourcessiprasip-local-ra.jar " [ERROR] serveralltmpsip-local-ra.jar(The System Cannot Find the Path Specified) Package file: "C:/mobicents_all-1-0-00-CR3/resourcessipra/sip-local-ra.jar" [ERROR] serveralltmp(The System Cannot Find the Path Specified) Package file: "file:///C:/mobicents_all-1-0-00-CR3/resourcessipra/sip-local-ra.jar" [ERROR] serveralltmpsip-local-ra.jar(The System Cannot Find the Path Specified) En el foro Mobicents Users[14] Bartosz Baranowski mencion´ que podr´ ser un o ıa problema en la inicializaci´n. o 2 3 Asynchronous JavaScript And XML (Cascading Style Sheets V.2
- 387. Anexo F Ejemplos Ejemplos de Servicios para Mobicents. 349
- 388. 350 ANEXO F. EJEMPLOS F.1. Ejemplo Wake Up Call F.1.1. Dependencias 1. SIP RA 1.2 2. SIP proxy/registrar F.1.2. Requerimientos El servicio Wake Up Call deber´ aceptar mensajes de UAs (Agentes usuarios; ıa clientes; tel´fonos) SIP con el formato ”(TIEMPO) (TEXTO) Esto significa un n´mero e u seguido de un espacio y alg´n texto. Cualquier otro mensaje dar como resultado un u error indefinido de la aplicaci´n. o El n´mero es tiempo que tardar´ en segundos. Lanzar´ un contador, que empezar´ a u a a a contar desde el momento en el que el mensaje es recibido por el servicio Wake Up. Despu´s del tiempo establecido termine el contador lanzar´ un mensaje autom´tico e a a que ser´ enviado al cliente con el texto enviado en el primer mensaje. a El servicio necesita para funcionar al menos un cliente SIP p´blico y disponible (ej. u SJ Phone, xTen Lite, Windows Messenger). Este aplicaci´n de ejemplo no tiene intenciones de ser un servicio real wake up o de ninguna manera. Es una mera demostraci´n del modelo de programaci´n de JAIN o o SLEE. Puede ser sin embargo como base de un servicio wake up SIP m´s pr´ctico. a a F.1.3. Build, Deploy and Run Antes de hacer nada, vamos a ver un r´pido vistazo a esta aplicaci´n desde el punto a o de vista de un usuario. Sigue los siguientes pasos 1. Baja del cvs la ultima versi´n del c´digo fuente del proyecto mobicents-examples ´ o o Alternativamente puedes bajarte el tarball m´s reciente de aqu´ 1. Ten en cuenta a ı que esta p´gina Wiki est´ m´s cercana a la ultima versi´n que la disponible como a a a ´ o tarball. 2. Aseg´rate que las variables del sistema JBOSS HOME y MOBICENTS EXAMPLES u apuntan a la ra´ del servidor JBoss server donde Mobicents est´ desplegado y el ız a directorio que contiene los ejemplos. 3. Inicia el servidor, run -c all -b 127.0.0.1 4. Ve al directorio $MOBICENT EXAMPLES/lib y edita build.xml - busca la linea con la direcci´n ip dejnpHost, comprueba que la misma con la que has ejecutado o JBoss, en este caso 127.0.0.1. 5. Ve al directorio $MOBICENT EXAMPLES/lib/slee-sip-ra 6. Ejecuta ant deploy 7. Ve a $MOBICENT EXAMPLES/lib/sipservices
- 389. F.1. EJEMPLO WAKE UP CALL 351 8. Si es la primera vez, ejecuta ant jar-with-invite-initial 9. Ejecuta ant deploy - se crear´n jars de servicios sip y se desplegar´n, en la consola a a de mobicents lanzar´ alg´n error por duplicaci´n de servicios. a u o 10. Ve al directorio del sip-wake-up. 11. Ejecuta ant deploy 12. Inicia tu cliente SIP (por ejemplo xTen ) 13. Configurarlo para que se registre con el proxy SIP ejecutado en el servidor. 14. Despu´s de agregar al contacto, [email protected], env´ un mensaje; Por ejemplo e ıale env´ ”10 Desierta maldita sea!”(sin las comillas). ıa 15. Despu´s de unos pocos segundos (dependiendo del valor num´rico) tu tel´fono e e e SIP deber´ recibir un mensaje de vuelta de [email protected] con el mensaje ıa ”Despierta maldita sea!”. Figura F.1: Ejemplo wake up
- 390. 352 ANEXO F. EJEMPLOS F.1.4. Dise˜ o n Para realizar este ejemplo, usaremos los siguientes JAIN SLEE building blocks: 1. Un servicio SLEE - wakeup-service.xml 2. Una clase Service Building Block - wakeUpSBB 3. Un Activity Context Interfaz - WakeUpSbbActivityContextInterface F.1.4.1. wakeup-service.xml Necesitamos definir un punto de entrada para nuestro nuevo servicio. Esta echo a trav´s de un fichero de definici´n del servicio que informa al contenedor SLEE que e o hemos desplegado y activado un nuevo servicio, que aceptar´ un conjunto dado de a eventos. El contenedor SLEE asegurar´ la entrega de todos los eventos a los que esta a subscrito el servicio. M´s precisamente, el servicio solo declara la ra´ SBB (WakeUpSa ız BB), que por turnos se subscribe a lo eventos SLEE. Esta es una abstracci´n adicional, o que permite a un SBB ser utilizado por multiples servicios u otros SBBS. SLEE es extremadamente potente en su ense˜anza de building blocks de gran grann ulidad y aut´nomos que pueden ser compuestos de muchas maneras para conseguir o niveles altos de abstracci´n. Este es un concepto muy importante que lleva un tiempo o acostumbrase. Especialmente para desarrolladores acostumbrados a dise˜os lineales y n monol´ ıticos vistos frecuentemente en empresas y aplicaciones web. Los componentes as´ ıncronos muy granulados ofrecen gran escalabilidad y buen control en la priorizaci´n o de servicios de telecomunicaciones. el 112 y otras llamadas de urgencias pueden ser manejadas con facilidad en un contenedor SLEE. F.1.4.2. WakeUpSBB Este ser´ la ra´ SBB del servicio. Ser´ responsable de aceptar un evento SIP MESa ız a SAGE, analizando su texto y programando un timer wakeup. Este tambi´n escuchara e eventos timer y enviara un SIP MESSAGE wake up de vuelta al UA solicitante. F.1.4.3. WakeUpSbbActivityContextInterface Si no est´s familiarizado con el concepto d Activity context, pero conoces lo que es a una HttpSession, entonces podemos simplificar las cosas op un momento diciendo que ambas ofrecen un camino a los componentes de la aplicaci´n para compartir entre ellos o estados conversacionales establecidos con los puntos finales remotos( el navegador http y el tel´fono SIP respectivamente) e Mirando algunos ejemplos y escribiendo algunos por ti mismo har´n las cosas m´s a a claras. El WakeUpSbbActivityContextInterface es u vista dentro del Activity context SLEE a trav´s de una buena interfaz escrita en Java. La interfaz tiene dos propiedades e
- 391. F.1. EJEMPLO WAKE UP CALL 353 contact y body. La propiedad contact guardar´ la direcci´n f´ a o ısica del dispositivo actual del tel´fono SIP. La propiedad body guardar´ el texto del mensaje enviado por el e a usuario. Primero pediremos al contenedor SLEE que cree una instancia concreta de un objeto object instance, que implementa la interfaz. Ligaremos despu´s este a un timer, e program´ndolo para la llamada wake up y m´s tarde recuperar los datos contextuales a a cuando el evento timer sea lanzado.
- 392. 354 ANEXO F. EJEMPLOS F.1.5. C´digo Fuente o Echemos un vistazo a algunas l´ ıneas de c´digo para comprenderlo mejor. o F.1.5.1. wakeup-service.xml Listado F.1: wakeup-service.xml <s e r v i c e −xml> <s e r v i c e> <d e s c r i p t i o n>Wake up s e r v i c e</ d e s c r i p t i o n> <s e r v i c e −name>Wake Up S e r v i c e</ s e r v i c e −name> <s e r v i c e −vendor>NIST</ s e r v i c e −vendor> <s e r v i c e −v e r s i o n>1 . 0</ s e r v i c e −v e r s i o n> <r o o t −sbb> <d e s c r i p t i o n> This Sbb send a wake up c a l l t o t h e u s e r . </ d e s c r i p t i o n> <sbb−name>Wake Up Sbb</ sbb−name> <sbb−vendor>NIST</ sbb−vendor> <sbb−v e r s i o n>1 . 0</ sbb−v e r s i o n> </ r o o t −sbb> <d e f a u l t −p r i o r i t y>0</ d e f a u l t −p r i o r i t y> </ s e r v i c e> </ s e r v i c e −xml> Hay dos cosas importantes que debemos saber: 1. El servicio es identificado unicamente en el contenedor SLEE por la tupla (service´ name, service-vendor,service-version) 2. La ra´ del SBB debe ser referencia mediante un identificador unico compuesto ız ´ por la tupla (sbb-name, sbb-vendor, sbb-version) El fichero descriptor del servicio es unido a un SLEE Deployment Unit junto con el archivo SBB. El fichero wakeup-DU.jar tiene la siguiente estructura: /wakeup-service.xml /META-INF/deployable-unit.xml. Este fichero solo lista los archivos y servicios SLEE contenidos en el DU: jars/WakeUp-sbb.jar, wakeup-service.xml. /jar/WakeUp-sbb.jar. Veremos m´s adelante cual es el papel de este jar. a F.1.5.2. WakeUpSBB El WakeUpSBB est´ implementado en la clase WakeUpSBB.java y es declarado a a SLEE mediante el fichero descriptor sbb-jar.xml. Ambos ficheros son unidos en un unico archivo - WakeUp-sbb.jar, con la siguiente estructura: ´
- 393. F.1. EJEMPLO WAKE UP CALL 355 /META-INF/sbb-jar.xml - fichero descriptor del SBB /org/mobicents/* - Clases java F.1.5.2.1. sbb-jar.xml . El fichero descriptor declara El identificador unico del SBB - (Wake Up Sbb, NIST, 1.0) ´ Su clase Java de implementaci´n - org.mobicents.slee.examples.wakeup.WakeUpSbb. o Date cuenta que es en realidad una clase abstract. El SLEE crea una sub-clase concreta y la instancia en tiempo de proceso. Los m´todos abstract implementae dos por SLEE proveen una informaci´n contextual importante a la aplicaci´n en o o tiempo de progreso; Estas incluso permiten al SLEE proveer persistencia transparente de lo campos SBB. Esta t´cnica es tomada prestada de la especificaci´n e o EJB. La interfaz del Activity Context que ser´ usada par las acciones del timer a org.mobicents.slee.examples.wakeup. WakeUpSbbActivityContextInterface La lista de los eventos a los que est´ subscrito el SBB a ˆ SIP MESSAGE event - javax.sip.message.Request.MESSAGE. Date cuenta que este evento est´ tambi´n marcado como evento inicial. Esto significa a e que los eventos MESSAGE recibidos por el servicio Wake Up podr´ causar ıan una nueva instancia de la ra´ SBB creada para el ciclo de vida del servicio. ız Puedes mirar al servicio SBBProxy que transporta con Mobicents por referencia como crear una nueva ra´ SBB y el activity context para la llamada ız SIP. ˆ SLEE Timer event - javax.slee.facilities.TimerEvent. Este es el evento que causar´ un mensaje wake up enviado de vuelta al UA. a Referencia al SIP Resource Adaptor - jain-sip. El SBB usar´ el SIP RA para a interactuar con el UA. F.1.5.2.2. WakeUpSBB.java . La clase java del SBB tiene una docena m´s o menos de m´todos. Resaltaremos a e aquellos que son unicos al servicio y que ser´n muy diferentes a los de otro servicio ´ a orientado a SIP: onMessageEvent .
- 394. 356 ANEXO F. EJEMPLOS 1. Este m´todo es llamado cuando un MESSAGE request es recibido por SLEE. e El m´todo primero reconoce el recibo del mensaje de vuelta al UA. Este usa el e activity context creado por el servidor para la interacci´n con el client para llevar o a cuestas una respuesta SIP. public void onMessageEvent ( j a v a x . s i p . RequestEvent event , A c t i v i t y C o n t e x t I n t e r f a c e a // N o t i f i y t h e c l i e n t t h a t we r e c e i v e d t h e SIP MESSAGE r e q u e s t ServerTransaction st = ( ServerTransaction ) aci . getActivity ( ) ; Response r e s p o n s e = messageFactory . c r e a t e R e s p o n s e ( Response .OK, r e q u e s t ) ; s t . sendResponse ( r e s p o n s e ) ; 2. El m´todo crea un token next (NullActivity) y lo asocia con la instancia actual del e SBB. El mismo token ser´ pasado a el timer cuando este sea programado para a una futura respuesta al m´todo del SBB onTimerEvent(). La verdad es que el e c´digo parece m´s complejo y copioso de palabras de lo que realmente es. Puede o a ser simplificado mediante utilidades de ayuda. // CREATE A NEW NULL ACTIVITIY N u l l A c t i v i t y timerBus = this . nullActivityFactory . c r e a t e N u l l A c t i v i t y ( ) ; // ATTACH ITSELF TO THE NULL ACTIVITY // BY USING THE ACTIVITY CONTEXT INTERFACE A c t i v i t y C o n t e x t I n t e r f a c e timerBusACI = t h i s . nullACIFactory . g e t A c t i v i t y C o n t e x t I n t e r f a c e ( timerBus ) ; timerBusACI . a t t a c h ( sbbContext . g e t S b b L o c a l O b j e c t ( ) ) ; 3. Despu´s, el c´digo analiza el mensaje entrante, extrayendo el tiempo que tare o dar´ en lanzarse y el cuerpo del texto. a // PARSING THE MESSAGE BODY S t r i n g body = new S t r i n g ( r e q u e s t . getRawContent ( ) ) ; int i = body . indexOf ( ” ” ) ; S t r i n g t i m e r V a l u e = body . s u b s t r i n g ( 0 , i ) ; int t i m e r = I n t e g e r . p a r s e I n t ( t i m e r V a l u e ) ; S t r i n g bodyMessage = body . s u b s t r i n g ( i +1); 4. Entonces pide al SLEE que cree un typed view para el activity token: // SETTING VALUES ON THE ACTIVITY CONTEXT // USING THE SBB CUSTOM ACI Wa keUpSbbActivityContextInte rfac e myViewOfTimerBusACI = t h i s . a s S b b A c t i v i t y C o n t e x t I n t e r f a c e ( timerBusACI ) ; 5. Usando el WakeUpSbbActivityContextInterface, guardamos el cuerpo del mensaje en el token (NullActivity) creado m´s tarde par este prop´sito. a o myViewOfTimerBusACI . setBody ( bodyMessage ) ;
- 395. F.1. EJEMPLO WAKE UP CALL 357 6. Despu´s, buscamos la direcci´n del contacto del UA a donde la llamada del wake e o up deber´ responder: ıa // The From f i e l d o f each SIP MESSAGE has t h e UA Address o f // Record ( l o g i c a l a d d r e s s ) , which can be mapped t o a // c u r r e n t p h y s i c a l c o n t a c t a d d r e s s . The mapping i s // p r o v i d e d by t h e L o c a t i o n S e r v i c e , which works t o g e t h e r // with t h e SIP R e g i s t r a r s e r v i c e . FromHeader fromHeader = ( FromHeader ) r e q u e s t . getHeader ( FromHeader .NAME) ; Address fromAddress = fromHeader . g e t A d d r e s s ( ) ; URI contactURI = f i n d L o c a l T a r g e t ( fromHeader . g e t A d d r e s s ( ) . getURI ( ) ) ; Address c o n t a c t A d d r e s s = a d d r e s s F a c t o r y . c r e a t e A d d r e s s ( contactURI ) ; ContactHeader c o n t a c t H e a d e r = headerFactory . createContactHeader ( contactAddress ) ; 7. Guarda el contacto en el activity token: myViewOfTimerBusACI . s e t C o n t a c t ( c o n t a c t H e a d e r ) ; 8. Crea un timer y lo programa usando la facilidad timer de SLEE. Liga el token al timer para que pueda ser recuperado m´s tarde. a // SETTING THE TIMER BY USING THE VALUE // IN THE SIP MESSAGE BODY TimerOptions o p t i o n s = new TimerOptions ( ) ; o p t i o n s . s e t P e r s i s t e n t ( true ) ; t h i s . t i m e r F a c i l i t y . s e t T i m e r ( timerBusACI , null , System . c u r r e n t T i m e M i l l i s ( ) + timer *1000 , options ) ; onTimerEvent . 1. Cuando la alarma del timer programada por onMessageEvent() salta, la facilidad timer de SLEE genera un evento timer. Todos los SBBs ligados al token (NullActivity), que estaba asociado con el timer recibir´n el evento. a 2. Este m´todo ser´ invocado, porque el fichero sbb-jar.xml lo especifica. e a
- 396. 358 ANEXO F. EJEMPLOS 3. Este simplemente extraer´ el contacto y el cuerpo con el texto del token ... a public void onTimerEvent ( TimerEvent event , ActivityContextInterface aci ) // RETRIEVING STORED VALUE FROM THE ACTIVITY CONTEXT INTERFACE Wa keUpSbbActivityContextInte rfac e myViewOfACI = this . asSbbActivityContextInterface ( a c i ) ; Header c o n t a c t = myViewOfACI . g e t C o n t a c t ( ) ; S t r i n g body = myViewOfACI . getBody ( ) ; 4. ... y se los pasa al m´todo endWakeUpCall: e // SENDING BACK THE WAKE UP CALL sendWakeUpCall ( c o n t a c t , body ) ; sendWakeUpCall . 1. Este m´todo compone un nuevo SIP MESSAGE direccionado a toContact con e el texto dado de body y lo env´ ıa. Es interesante recalcar que para enviar el mensaje al UA, el m´todo usa el SIP e RA provider como est´ pedido en el fichero sbb-jar.xml. a El SIP provider es referenciado primero a la hora de que el Contenedor SLEE fije el contexto SBB - ver setSbbContext(): private void sendWakeUpCall ( Header toContact , S t r i n g body ) // G e t t i n g JAIN SIP Resource Adaptor i n t e r f a c e s fp = ( SipFactoryProvider ) myEnv . lookup ( ” s l e e / r e s o u r c e s / j a i n s i p / 1 . 1 / p r o v i d e r ” ) ; provider = fp . getSipProvider ( ) ; 2. La variable del proveedor es m´s tarde usado en el m´todo sendWakeUpCall()par a e establecer un transacci´n SIP con el UA y enviar el mensaje: o ClientTransaction ct = provider . getNewClientTransaction ( req ) ; c t . sendRequest ( ) ; F.1.6. Conclusiones El Servicio de llamada Wake Up Call muestra como crear un servicio SIP sencillo usando JAIN SLEE como modelo de programaci´n. S´lo coge un sencillo fichero Java o o SBB (Service Building Block) y algunas pocas l´ ıneas de XML wiring. Se ha visto la estructura de un servicio sencillo JAIN SLEE, la forma de recibir eventos del SIP RA y usar el Timer de JAIN SLEE.
- 397. F.2. EJEMPLO THIRD PARTY CALL CONTROL F.2. 359 Ejemplo Third party call control Esta es una aplicaci´n de control a terceros basada en web con realimentaci´n o o 1 es el t´rmino para la configuraci´n de la sesi´n instant´nea de los usuarios. 3PCC a e o o echa por un tercero distinta al que en realidad intercambia el media. Este tercero tiene el control de la sesi´n y puede terminarla o manipularla de distintas maneras, por o ejemplo, invitar de nuevo a las partes para cambiar las propiedades del media. F.2.1. F.2.1.1. Prerrequisitos JBoss y versiones de Java 3PPC ha sido probado con Mobicents corriendo en JBoss 3.2.8 usando JDK 1.4 o 1.5. F.2.1.2. Eclipse y Ant Si usas Ant desde Eclipse: Window --> Preferences --> Ant --> Runtime --> Global Entries must include $JAVA_HOME/lib/tools.jar Donde $JAVA HOME deber´ ser reemplazado por la ruta donde tengas instalado ıa Java. Ejemplo /opt/jdk1.5.0_06/lib/tools.jar Aseg´rate que la variable de entorno JBOSS HOME est´ fijada en carpeta donde u a tienes instalado JBoss. Ej: /opt/jboss-3.2.7 Como el proyecto tiene dependencias dentro de la estructura de instalaci´n de JBoss, o aseg´rate que has definido la variable classpath de Eclipse que hace referencia a la u carpeta de instalaci´n de JBoss. Usa o Window --> Preferences --> Java --> Build Path --> Classpath Variables Para crear una nueva variable classpath llamada ’JBOSS HOME’. F.2.1.3. Mobicents y Sip RA Necesitas tener Mobicents desplegado con el RA sip. Nota: Podr´ ejecutar el proxy ıas sip incluido en la distribuci´n de Mobicents pero la petici´n sip BYE ser´ procesada por o o a el app proxy que no es pertinente. Puede que te molesten los mensajes de depuraci´n o debido a esto. 1 Third party call control
- 398. 360 ANEXO F. EJEMPLOS El procedimiento de instalaci´n recomendado es usar el objetivo “auto-deploy-sip“ o y comentar la parte del bean shell script que despliega el proxy. Mira scripts/sip-deploy-sipraonly.bsh que tu puedes usar. Para establecer y desplegar Mobicents simplemente ejecuta el objetivo “auto-deploysip“ y (opcionalmente) reemplaza el fichero: $JBOSS HOME/server/all/deploy-mobicents/scripts/sip-deploy.bsh por este scripts/sipdeploy-sipraonly.bsh. F.2.1.4. Mobicents rar ipaddress issue Si usas una direcci´n diferente a 127.0.0.1 para ejecutar JBoss puede ser necesario o editar el fichero server/all/deploy/slee-ds.xml cambiando “localhost“ por tu direcci´n o ip en la siguiente linea: http://localhost:1099/SleeService Se ha observado que no es posible comunicar con 127.0.0.1:1099 en un sistema Linux a no ser que este cambio se haya echo. F.2.2. F.2.2.1. Instalar y ejecutar Servicio SLEE Ve a la carpeta 3ppc3pcc sip slee dentro de mobicents-examples y ejecuta: ant auto-deploy-ThirdPCCTrigger Nota: Este instalar´ el bean shell script “thirdPCCTrigger-deploy.bsh“ que debe a ser procesado despu´s de que el RA sip se haya desplegado. Para lograrlo, su nombre e debe ser alfanum´ricamente precedido por “sip-deploy-sipraonly.bsh“ o cualquier e nombre que tu uses para este fichero. (No tienes que cambiar nada pero si por cualquier raz´n quieres cambiar el nombre de este fichero ten cuidado con esta restricci´n) o o F.2.2.2. Aplicaci´n Web o El web app puede ser ejecutado de dos formas, usando dos servicios de llamada diferentes - ’Servlet’ y ’WebService’. Que ser´n configurados en un solo fichero de a propiedades. Cuando sea usado el servicio de llamada ’Servlet’, ser´ el web app (ej. a Servlet) que invoca el servicio SLEE (usando el SleeConnection). Por otro lado, cuando sea usado el servicio de llamada ’WebService’, el web app usa un cliente web service para invocar (a trav´s de ParlayX) un web service (WS) en la m´quina donde e a el servicio SLEE est´ desplegado. a Esto habilitar´ el web server y el contenedor SLEE container para ser desplegado a en dos m´quinas f´ a ısicamente separadas.
- 399. F.2. EJEMPLO THIRD PARTY CALL CONTROL F.2.2.2.1. 361 Plain web app . Ejecuta JBoss as´ ı: Ve a $JBOSS HOME Ejecuta run -c all -b tudireccionip Ve a la carpeta $mobicents-examples3pcc y ejecuta: ant deploy-3pcc_web_app-(hot) Abre el navegador web e introduce a est´ p´gina: a a http:tudireccionip:8080thirdpcc F.2.2.2.2. Web app + web service . Hay un objetivo que despliega el web app y el web service en la m´quina local, a emulando el caso de dos m´quinas separadas f´ a ısicamente. Ejecuta JBoss as´ ı: Ve a $JBOSS HOME Ejecuta run -c all -b tudireccionip Ve a la carpeta $mobicents-examples3pcc y ejecuta: ant deploy-3pcc_web_app+web_service-(hot) Abre el navegador web e introduce a est´ p´gina: a a http:tudireccionip:8080thirdpcc Verifica que el web service est´ en uso. a Hay otro objetivo para desplegar solo el web app y el cliente WS integrado - ’deploy3pcc web app+ws client-(hot)’. Sin embargo, antes de ejecutar este objetivo, necesitas desplegar el servicio SLEE y el servidor WS en la “otra m´quina“. a Si tienes problemas instalando y/o ejecutando la aplicaci´n, por favor consulta los o READMES y las notas de publicaci´n del proyecto espec´ o ıfico - Todo est´ ahi! a Nota: Para cambiar el servicio de llamada (’Servlet’ y ’WebService’), necesitas parar JBoss, replegar, cambiar el servicio de llamada e (en 3pcc web/common/etc/callservice.properties) y despu´s desplegarlos otra vez! No es suficiente con cambiar el fichero en el directorio server/all/deploy, ya que esta informaci´n es le´ por un singleton en tiempo de despliegue! o ıda
- 400. 362 ANEXO F. EJEMPLOS Nota: El sip UAs usado no debe estar registrado con el proxy transportado en Mobicents, este no funcionar´. En vez de dejar la aplicaci´n 3pcc direccionar el sip UAs a o directamente llam´ndoles por la direcci´n ip o registr´ndose con otro proxy. Un proxy a o a recomendado que ha sido probado con la aplicaci´n es el Sip Express Router disponible o gratuitamente de iptel.org. Otro buen proxy usado es Jain Sip Presence Proxy. (M´s a f´cil de usar y configurar que el Sip Express Router) a Una manera de verificar que se ha instalado correctamente el servicio SLEE es usar SleeGraph (otra aplicaci´n de ejemplo de Mobicents) que deber´ mostrar esto: o ıa Figura F.2: SleeGraphViewer
- 401. F.2. EJEMPLO THIRD PARTY CALL CONTROL 363 Pantallazos de la interfaz gr´fica: a Figura F.3: Call Launch Form Figura F.4: Status Feed Packpage F.2.2.3. M´tricas e Habiendo ejecutado la aplicaci´n, puede ser interesante probar una de las caraco ter´ ısticas compiladas en JSEE - La usage facility. Es muy f´cil facilitar estad´ a ısticas de
- 402. 364 ANEXO F. EJEMPLOS uso definiendo interfaces a medida de los Sbbs de la aplicaci´n. o Esta aplicaci´n provee un conjunto de m´tricas que est´ disponibles por MBeans, si o e a vamos a la direcci´n http://localhost:8080/jmx-console y nos desplazamos abajo hasta o la secci´n ’slee’, haz click en: o SbbUsageMBean=ServiceID[se.jayway.sip.slee.service.ThirdPCCTrigger-service #Jayway#0.1]/ SbbID[se.jayway.sip.slee.sbb.CallControlSbb#Jayway#0.1] Figura F.5: http://localhost:8080/jmx-console F.2.3. Dise˜ o n Esta secci´n subraya los temas de dise˜o del ejemplo en la aplicaci´n. o n o F.2.3.1. SBB design JSLEE define un modelo de componentes para aplicaciones as´ ıncronas basadas en eventos, los componentes son llamados Service Building Blocks, SBBs. Hay dos componentes SBBs que produciendo la l´gica del control de llamada. Solo uno es estrictamente o necesario y la raz´n para dividir la funcionalidad en dos es que uno de los componentes, o callControllsbb, es reusable porque no tiene dependencias a ning´n evento habitual usu ados para accionar el callflow o terminarlo y no hay dependencia de CallControlSbb a ThirdPCCTriggerSbb. Responsabilidades de los componentes respectivos:
- 403. F.2. EJEMPLO THIRD PARTY CALL CONTROL 365 ThirdPCCTriggerSbb – Recibir eventos habituales para accionar, terminar y cancelar el callflow. CallControlSbb – Administrar el n´cleo del callflow sip y compartir el estado del u callflow a componentes externos que quiera monitorizar el progreso. La interacci´n entre el ThirdPCCTriggerSbb y el CallControlSbb es de dos tipos: o 1. ThirdPCCTriggerSbb tiene una relaci´n hijo con CallControlSbb y crea un hijo o cuando una callflow es iniciada. 2. ThirdPCCTriggerSbb invoca m´todos as´ e ıncronos de la interfaz local de CallControlSbb para terminaci´n/cancelaci´n del callflow. o o Es posible usar el CallControlSbb en otra aplicaci´n que use estos dos mecanismos o de interacci´n. El CallControlSbb solo depende en los event types definidos en RA sip. o F.2.3.2. Compartici´n de Estado. o La compartici´n de estado entre la aplicaci´n Slee y los componentes externos se o o realiza implementado pasando una interfaz (StateCallback) de la aplicaci´n web a la o aplicaci´n SLEE. El objeto StateCallback es una propiedad de ThirdPCCTriggerEvent. o La implementaci´n aqu´ es muy sencilla y solo puede ser usado si el contenedor de o ı Servlets y el contenedor JSLEE est´n colocados en el mismo JVM. Pueden ser usadas a implementaciones apropiadas para clusters, por ejemplo JMS para distribuir el estado para ser comunicado de los SBBs a la aplicaci´n web. Esto ser´ transparente a la o ıa aplicaci´n JSLEE. o F.2.3.3. State machine El patr´n de estado se es sugerida en esta aplicaci´n. El estado de la m´quina es o o a derivable de un simple callflow recomendado en IETF. Las clases de estado son clases internas de CallControlSbb que es manejable. Sin embargo, para hacer que el estado de la m´quina se haga reusable las clases de estado a pueden ser normales, no internas. Esto es probablemente el buen camino para avanzar y el siguiente paso ser´ identificar la interfaz que el CallControlSbbdebe implementar a para externalizar las clases de estado. El prop´sito m´s interesante de esta refactorizaci´n es escribir nuevos CallCono a o trollSbbs que implementen diferentes mecanismos de compartici´n de estados. o F.2.4. F.2.4.1. Notas Caracter´ ısticas y limitaciones Soporte de autentificaci´n para INVITE pero no para BYE. Esto significa que el o web app no funciona con proxies que requieran la autentificaci´n de un BYE. o
- 404. 366 ANEXO F. EJEMPLOS Figura F.6: Diagrama de estado. Soporte para terminaci´n y cancelaci´n por eventos personalizados. o o Compartici´n de estado mediante JNDI. Esta no es la soluci´n recomendada y o o ser´ sustituida. a Manejo incompleto de excepciones en algunos casos. No es importante para hacer pruebas pero esto deber´ ser solucionado para proveer un ejemplo de best ıa practices. M´tricas a trav´s de par´metros de uso, ver la consola JMX jslee e e a F.2.4.2. Interoperabilidad La aplicaci´n ha sido probado satisfactoriamente con los siguientes UAs: o XLite par Windows y Linux Sipp (herramienta de pruebas) La aplicaci´n ha sido probada satisfactoriamente con los siguientes servidores proxy o http://www.iptel.org La aplicaci´n fall´ con los siguientes UAs: o o Windows Messenger ( El sonido funciona en una sola direcci´n) o SJ-Phone (Para windows) BYE no es reconocido por el SJ-Phone, y falla en otros escenarios. A pesar de esto la configuraci´n de la llamada funciona bien. o
- 405. F.2. EJEMPLO THIRD PARTY CALL CONTROL F.2.5. F.2.5.1. 367 C´digo Fuente o Controller Servlet Empezamos con la con el Servlet del controlador de la aplicaci´n web donde los http o requests son aceptados y los eventos JSLEE son despachados para controlar el servicio sip. Listado F.2: Controller Servlet ThirdPCCTriggerEvent e v e n t = new ThirdPCCTriggerEvent ( c a l l e r , c a l l e e ) ; // R e t r i e v e GUID g u i d = e v e n t . getGUID ( ) ; f i n a l S t r i n g eventName = ” s e . jayway . s i p . s l e e . e v e n t . ThirdPCCTriggerEvent ” ; f i n a l S t r i n g eventVendor = ”Jayway” ; f i n a l S t r i n g e v e n t V e r s i o n = ” 0 . 1 ” ; Este c´digo muestra una clase evento personalizado que encapsula las direcciones o sip de las partes. Tambi´n produce un GUID para la sesi´n 3pcc que e m´s tarde usada e o a para preguntar por la informaci´n del estado de la llamada o terminaci´n de la llamada. o o Los objetos final String son usados para identificar un EventID que contiene el contenedor JSLEE y est´ definido en el descriptor de despliegue del servicio. a Ahora la parte que en realidad despacha un evento:
- 406. 368 ANEXO F. EJEMPLOS Listado F.3: Controller Servlet S l e e C o n n e c t i o n conn = null ; // Now go on and e s t a b l i s h t h e c o n n e c t i o n conn = f a c t o r y . g e t C o n n e c t i o n ( ) ; // f a c t o r y i s o f type S l e e C o n n e c t i o n F a c t o r y EventTypeID eventTypeID = conn . getEventTypeID ( eventName , eventVendor , eventVersion ) ; conn . f i r e E v e n t ( event , eventTypeID , null , null ) ; Esto despacha nuestros eventos sin expecificar un ExternalActivityHandle opcional o Direcci´n (los dos argumentos nulos). o F.2.5.2. F.2.5.2.1. Servicio SLEE ThirdPCCTriggerSbb . Ahora algunas cosas interesantes suceden en el contenedor JSLEE. Date cuenta que despachamos un evento en el contenedor JSLEE como un todo, no especic´bamos una a aplicaci´n o un componente SBB. Es el trabajo del contenedor JSLEE averiguar que o componentes Sbb recibiran el evento disparado. El SBB ra´ de la aplicaci´n es ThirdPCCTriggerSbb y esta es la parte de su sbbız o jar.xml que hace a JSLEE instanciar una nueva ra´ SBB par nuestro evento: ız Listado F.4: sbb-jar.xml <e v e n t event−d i r e c t i o n=" Receive " i n i t i a l −e v e n t="True"> <event−name>ThirdPCCTriggerEvent</ event−name> <event−type−r e f> <event−type−name> s e . jayway . s i p . s l e e . e v e n t . ThirdPCCTriggerEvent </ event−type−name> <event−type−vendor>Jayway</ event−type−vendor> <event−type−v e r s i o n>0 . 1</ event−type−v e r s i o n> </ event−type−r e f> < i n i t i a l −event−s e l e c t v a r i a b l e=" ActivityContext " /> </ e v e n t>
- 407. F.2. EJEMPLO THIRD PARTY CALL CONTROL 369 Tambi´n tenemos que informar al contenedor que SBb es el SBB ra´ de nuestro e ız servicio, esto se hace en el descriptor de despliegue service.xml. Listado F.5: ThirdPCCTrigger-service <s e r v i c e −xml> <s e r v i c e> <d e s c r i p t i o n /> <s e r v i c e −name> s e . jayway . s i p . s l e e . s e r v i c e . ThirdPCCTrigger−s e r v i c e </ s e r v i c e −name> <s e r v i c e −vendor>Jayway</ s e r v i c e −vendor> <s e r v i c e −v e r s i o n>0 . 1</ s e r v i c e −v e r s i o n> <r o o t −sbb> <d e s c r i p t i o n /> <sbb−name> s e . jayway . s i p . s l e e . sbb . ThirdPCCTriggerSbb </ sbb−name> <sbb−vendor>Jayway</ sbb−vendor> <sbb−v e r s i o n>0 . 1</ sbb−v e r s i o n> </ r o o t −sbb> <d e f a u l t −p r i o r i t y>0</ d e f a u l t −p r i o r i t y> </ s e r v i c e> </ s e r v i c e −xml> El trabajo del ThirdPCCTriggerSbb es recibir eventos y realizar el trabajo correspondiente, recuerda que el n´cleo del trabajo del sip signaling son el deber de Callu ControllSbb. Cuando el evento llega al contenedor JSLEE en alguna etapa invoca el m´todo onThirdPCCTriggerEvent. e Este m´todo ilustra un mecanismo muy potente en JSLEE para que use la relaci´n e o hijo a CallControlSbb y conecte el hijo a un objeto nuevo ActivityContextInterface creado nuevo que corresponde a una transacci´n del cliente sip en la cual el primer o INVITE es enviado:
- 408. 370 ANEXO F. EJEMPLOS Listado F.6: ThirdPCCTriggerSbb // B u i l d t h e INVITE r e q u e s t Request r e q u e s t = s i p U t i l s . b u i l d I n v i t e ( c a l l e r A d d r e s s , calleeAddress , null , 1); // C r e a t e a new t r a n s a c t i o n based on t h e g e n e r a t e d r e q u e s t ClientTransaction ct = sipProvider . getNewClientTransaction ( request ) ; // Get a c t i v i t y c o n t e x t from f a c t o r y A c t i v i t y C o n t e x t I n t e r f a c e ac = activityContextInterfaceFactory . getActivityContextInterface ( ct ) ; Ahora tenemos un Request Sip, su transacci´n del cliente y su correspondiende Aco tivityContextInterface, continuaremos y crearemos un Sbb hijo, lo ligaremos al activity context y enviaremos el Request: Listado F.7: ThirdPCCTriggerSbb ChildRelation r e l a t i o n = getCallControlSbbChild ( ) ; // C r e a t e c h i l d SBB child = relation . create ( ) ; // Attach c h i l d SBB t o t h e a c t i v i t y c o n t e x t ac . a t t a c h ( c h i l d ) ; // Send t h e INVITE r e q u e s t c t . sendRequest ( ) ; F.2.5.2.2. CallControlSbb . Ahora que el sip signaling es iniciado, debemos tener cuidado con las respuestas que llegar´n y realizar el resto del trabajo. Esto se hace en los m´todos onXXXEvent en a e CallControlSbb que procesa los eventos definidos por el Sip RA. Uno de los m´todos m´s importantes es el evento onSuccessRespEvent y estas son e a algunas de las l´ ıneas de c´digo que se ejecutan cuando llega el OK 200 del primer INo VITE.
- 409. F.2. EJEMPLO THIRD PARTY CALL CONTROL 371 Listado F.8: CallControlSbb Object c o n t e n t = e v e n t . g e t R e s p o n s e ( ) . g e t C o n t e n t ( ) ; // This i s t h e SDP from t h e c a l l e e ( f i r s t p a r t y ) t h a t w i l l be s e n t t o c a l l e r S t r i n g c o n t e n t S t r i n g = null ; i f ( c o n t e n t instanceof byte [ ] ) { c o n t e n t S t r i n g = new S t r i n g ( ( byte [ ] ) c o n t e n t ) ; } e l s e i f ( c o n t e n t instanceof S t r i n g ) { contentString = ( String ) content ; } f i n a l byte [ ] s d p O f f e r = c o n t e n t S t r i n g . g e t B y t e s ( ) ; // Get t h e a d d r e s s e s from t h e s e s s i o n s S e s s i o n A s s o c i a t i o n sa = ( S e s s i o n A s s o c i a t i o n ) cache . get ( c a l l e e C a l l I d ) ; S e s s i o n c a l l e e S e s s i o n = sa . g e t C a l l e e S e s s i o n ( ) ; Address c a l l e e A d d r e s s = c a l l e e S e s s i o n . g e t S i p A d d r e s s ( ) ; // We u s e t h e i d e n t i t y o f t h e t h i r d p a r t y c a l l c o n t r o l l e r // a s c a l l e r a d d r e s s Address c a l l C o n t r o l A d d r e s s = s i p U t i l s . convertURIToAddress ( g e t C a l l C o n t r o l S i p A d d r e s s ( ) ) ; try { c a l l C o n t r o l A d d r e s s . setDisplayName ( ( ( SipURI ) c a l l e e A d d r e s s . getURI ( ) ) . g e t U s e r ( ) ) ; } catch ( P a r s e E x c e p t i o n e2 ) { // TODO Auto−g e n e r a t e d c a t c h b l o c k e2 . p r i n t S t a c k T r a c e ( ) ; } S e s s i o n c a l l e r S e s s i o n = sa . g e t C a l l e r S e s s i o n ( ) ; Address c a l l e r A d d r e s s = c a l l e r S e s s i o n . g e t S i p A d d r e s s ( ) ; Request r e q u e s t = s i p U t i l s . b u i l d I n v i t e ( c a l l C o n t r o l A d d r e s s , callerAddress , sdpOffer , 1); Esto muestra el trabajo de manejar la asociaci´n entre los dos di´logos de las partes o a en el call setup y manejar los nombres mostrados etc. Date cuenta que usamos una direcci´n sip especial (configurable) del call controller pero usamos el nombre mostrado o por las partes.
- 410. 372 ANEXO F. EJEMPLOS Cuando enviamos el segundo invite hay un mecanismo similar cuando crea una nueva ActivityContextInterface correspondiente a la nueva transacci´n del cliente sip pero o esta vez ligaremos la misma instancia del SBB al nuevo activity context. Un SBB puede estar asociado a m´ltiples activities context. u Listado F.9: CallControlSbb ActivityContextInterface aci = activityContextInterfaceFactory . getActivityContextInterface ( ct ) ; SbbLocalObject mySelf = sbbContext . g e t S b b L o c a l O b j e c t ( ) ; // Attach c h i l d SBB t o t h e a c t i v i t y c o n t e x t a c i . a t t a c h ( mySelf ) ; c t . sendRequest ( ) ; // c t i s a C l i e n t T r a n s a c t i o n
- 411. ´ F.3. MENSAJES SMPP A TRAVES DE GOOGLE TALK F.3. 373 Mensajes smpp a trav´s de Google Talk e La comunicaci´n en tiempo real es algo importante en la vida moderna. Inicialo mente, las aplicaciones de mensajer´ instant´nea comenzaron a aparecer en los a˜os ıa a n setenta en sistemas operativos multiusuario como UNIX, para facilitar la comunicaci´n o con otros usuarios conectados a la misma m´quina, m´s tarde en la red local, y despu´s a a e a trav´s de Internet. Actualmente, hay muchas islas de comunicaciones en Internet coe mo Skype o Google Talk que son ampliamente utilizados para mensajer´ instant´nea. ıa a Por otro lado, los tel´fonos m´viles son tambi´n muy utilizados y el servicio de mensajes e o e cortos podr´ ser adoptado por Google Talk para permitir al usuario utilizar la red de ıa m´viles. Entonces podemos ampliar GoogleTalk. El ejemplo de aplicaci´n Bot podr´ o o ıa remitir mensajes recibidos desde Google Talk, desde Google Talk al m´vil y viceversa. o Trabajamos en un modelo de “Cliente”. Estos no es el asunto para este aplicaci´n de o ejemplo, pero significa que los usuarios de GoogleTalk ver´n el dominio de los m´viles a o como un usuario virtual, y este usuario podr´ ser registrado en una lista de contactos. ıa Lo mismo para el abonado del m´vil, hay un n´mero del m´vil predefinido (corto o o u o largo) que servir´ como gateway con el dominio de GoogleTalk. Y en ambos casos, a la direcci´n adicional, nativa por otro lado, podr´ ser especificada en el cuerpo del o ıa mensaje para permitir reconocer el destinatario del mensaje. Entonces el formato del siguiente mensaje podr´ adoptarse por el siguiente gateway: ıa addressString Message text Donde addressString es nativa para el dominio de la direcci´n del usuario. El n´mero o u del m´vil en el formato E164 para mensajes dirigidos al usuario del m´vil y la direcci´n o o o de gmail para mensajes dirigidos a usuarios de GoogleTalk. F.3.1. C´digo fuente o Todo el c´digo fuente puede ser encontrado aqu´ o ı: mobicents.dev.java.net/source/browse/mobicents-examples/smpp-example F.3.2. Accediendo al RA desde SBB El SBB salva expl´ ıcitamente el RA object usando el elemento resource-adaptorentity-binding en el descriptor de despliegue del SBB.
- 412. 374 ANEXO F. EJEMPLOS Listado F.10: Funci´n setSbbContext o public void setSbbContext ( SbbContext sbbContext ) { t h i s . sbbContext = sbbContext ; try { l o g g e r . i n f o ( ” C a l l e d setSbbContext PtinAudioConf ” ) ; Context myEnv = ( Context ) new I n i t i a l C o n t e x t ( ) . lookup ( ” j a v a : comp/ env ” ) ; xmppProvider = ( XmppResourceAdaptorSbbInterface ) myEnv . lookup ( ” s l e e / r e s o u r c e s /xmpp / 2 . 0 / xmppinterface ” ) ; smppProvider = ( SmppProvider ) myEnv . lookup ( ” s l e e / r e s o u r c e s /smpp / 3 . 4 / smppinterface ” ) ; smppAcif = ( A c t i v i t y C o n t e x t I n t e r f a c e F a c t o r y ) myEnv . lookup ( ” s l e e / r e s o u r c e s /smpp / 3 . 4 / factoryprovider ” ); } catch ( NamingException ne ) { l o g g e r . warn ( ” Could not s e t SBB c o n t e x t : ” + ne . getMessage ( ) ) ; } } F.3.3. Handling server transactions Cada vez que es recibido un mensaje de SMSC, el RA emite un mensaje DELIVER SM. EL objeto RequestEvent podr´ ser usado para acceder directamente al objeto ıa de actividad ServerTransaction. El manejador de eventos responde al SMSC usando el m´todo respond(int) de transaction. e Listado F.11: Funci´n onSmsMessage o public void onSmsMessage ( RequestEvent event , ActivityContextInterface aci ) { l o g g e r . i n f o ( ” Sending message t o ” + a d d r e s s ) ; ... e v e n t . g e t T r a n s a c t i o n ( ) . res pon d ( T r a n s a c t i o n .OK) ; } F.3.4. Handling client transactions El objeto SmppProvider podr´ ser usado para preparar un mensaje saliente y una ıa transacci´n de un cliente. Asumimos que 0020 especifica el n´mero de ESME como del o u RA entity est´ configurado. El ActivityContextInterfaceFactory usada para permitir a a este SBB manejar eventos relacionados con la transacci´n del cliente. o
- 413. ´ F.3. MENSAJES SMPP A TRAVES DE GOOGLE TALK 375 Listado F.12: Funci´n onGoogleMessage o public void onGoogleMessage ( Message message , ActivityContextInterface aci ) { D i a l o g d i a l o g = smppProvider . g e t D i a l o g ( a d d r e s s , ” 0020 ” ) ; ShortMessage sms = d i a l o g . c r e a t e M e s s a g e ( ) ; sms . s e t T e x t ( t x t ) ; C l i e n t T r a n s a c t i o n tx= d i a l o g . c r e a t e S ub m i t S m T r a ns a c t i o n ( ) ; A c t i v i t y C o n t e x t I n t e r f a c e ac = smppAcif . g e t A c t i v i t y C o n t e x t I n t e r f a c e ( tx ) ; ac . a t t a c h ( sbbContext . g e t S b b L o c a l O b j e c t ( ) ) ; tx . send ( sms ) ; } F.3.5. Como instalarlo, configurarlo y arrancarlo 1. Bajar la ultima versi´n de mobicents y los ejemplos de mobicents del CVS. ´ o 2. Crear dos cuentas en gmail . 3. Logearse en Google Talk a trav´s de una cuenta . e 4. Usar la otra cuenta para fijar el usuario y la contrase˜a en el GatewaySbb.java n 5. Por ejemplo, si la cuenta gmail es [email protected] , entonces las variables de GatewaySbb.java quedar´ as´ ıan ı: private final String username = "est.universidad.leon" private final String password = "CSCHP06/07" 6. A˜ade esta cuenta a tu Google Talk . n 7. Ejecuta mobicents run -c all -b 127.0.0.1 . 8. Configura el SMPP PORT, el SYSTEM ID y el PASSWORD en el archivo SMPPSimconfsmppsim.props para que quede igual a %Mobicents-examples %libsmpprasmppra.properties (port, system id y passwd) 9. Ejecuta SMPPSim 10. Despliega el RA XMPP. %Mobicents Examples %libxmppraant deploy 11. Despliega el RA SMPP.
- 414. 376 ANEXO F. EJEMPLOS %Mobicents Examples %libsmppraant deploy 12. Despliega el smpp example. %Mobicents Examples %smpp-exampleant deploy El ejemplo funcionaba correctamente, pero tiene algunas carencias: Usa un RA SMPP modificado para funcionar con el SMPPsim. La contrase˜a y el usuario de SMPPsim tiene que ser exclusivamente num´ricos. n e Actualmente funciona solo en modo cliente. El Resource Adaptor funciona con un unico n´mero de m´vil. ´ u o Hay que instroducir a mano la direcci´n del gmail y del n´mero de tel´fono en el o u e c´digo del SBB. o Desde el seis de Julio del 2006 no hay progresos en el ra. Figura F.7: Mandando un sms a trav´s de SMPPsim e Debido a esto el SMPP RA no nos parece muy operativo, ya que solo funciona como una unica cuenta de entrada es decir solo puede recibir mensajes a un solo n´mero ´ u preconfigurado, en el ejemplo el 0020, con lo que la idea de crear un proxy de servicios SMPP no es factible. El RA solo funciona como cliente y no como servidor, modificando el SMPP RA b´sico se podr´ implementar creando adem´s un Proxy de mensajer´ a ıa a ıa.
- 415. F.4. EJEMPLO GOOGLE BOT F.4. Ejemplo Google bot F.4.1. 377 C´digo fuente o El c´digo fuente de este ejemplo est´ disponible en el CVS, as´ como en esta direcci´n o a ı o F.4.2. Dependencias Este ejemplo depende del RA XMPP 10.7 para funcionar. Dicho RA lo podemos encontrar dentro de la carpeta lib, disponible en el CVS. F.4.3. C´mo instalar, configurar y ejecutar o Para instalar, configurar y ejecutar, siga estos pasos: Obtenga la ultima versi´n de mobicents y de mobicents-examples del CVS. ´ o Cree 2 cuentas en Gmail. Reg´ ıstrese en Google Talk con una de esas cuentas. Use la otra cuenta para configurar el nombre de usuario y la contrase˜a en el n fichero GoogleTalkBot-sbb-jar.xml ˆ Por ejemplo, si la cuenta de gmail es [email protected], en el fichero GoogleTalkBot-sbb-jar.xml ponga su identificador de usuario, en este caso lucky1981, y su contrase˜a. Deber´ asemejarse a lo siguiente: n a <env-entry> <env-entry-name>username</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>lucky1981</env-entry-value> </env-entry> <env-entry> <env-entry-name>password</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>lucky_lucke</env-entry-value> </env-entry> ˆ A˜ade la cuenta anterior como tu contacto en Google Talk. n Ejecute Mobicents. Vaya a MOBICENTS EXAMPLES/lib/xmppra y ejecute ant deploy. Vaya a MOBICENTS EXAMPLES/googletalk-bot y ejecute ant deploy. (o simplemente, ejecute ant deploy-all en MOBICENTS EXAMPLES/googletalk-bot Ahora env´ un mensaje a la cuenta anterior desde Google Talk. Recibir´ ese ıe a mensaje en la consola de Jboss. Como respuesta a su mensaje, su contacto le devolver´ su mensaje indic´ndole cu´ntos caracteres tiene su mensaje. a a a
- 416. 378 ANEXO F. EJEMPLOS ˆ Por ejemplo, si manda el mensaje “Hello”, deber´ recibir como respuesta ıa en su ventana de Google Talk el mensaje “ 5 chars in message “Hello” ”. ˆ Si env´ el mensaje “Time” entonces la r´plica deber´ ser similar a lo siguıa e ıa iente: “ My system time is Thu Mar 23 01:40:31 IST 2006 ” Figura F.8: Resultado de la ejecuci´n. o F.4.4. Casos de uso Este ejemplo puede considerarse como un punto de partida para el desarrollo de servicios m´s sofisticados que ofrezcan mayores funcionalidades. Por ejemplo, los usuara ios se pueden registrar para recibir notificaciones instant´neas de una p´gina web de a a seguimiento de acciones. Otros ejemplos incluyen: 1. Servicio de llamada despertador. Similar al mostrado en el ejemplo de llamada despertador de SIP F.1 Usuario al servicio: “Wake me up at 10am‘” Servicio al usuario (a las 10am): “Wake up call as requested. It is 10am” 2. Servicio de alerta de juego online
- 417. F.4. EJEMPLO GOOGLE BOT 379 El usuario crea una sala de juego y opta por una notificaci´n de mensajer´ o ıa instant´nea cuando se hayan unido el n´mero de participantes necesario. a u Entonces pasa a la navegaci´n por internet. o Servicio al usuario: “Se han apuntado 5 de 5 participantes a su sala de juego. Por favor, comience el juego.” 3. Di´logos de aprobaci´n de procesos de negocio a o Servicio al usuario: Joe Doe solicita aprobaci´n para contratar a Alice Jenko ins. Por favor, responda con “S´ “No”, o “Trasladar a XYZ”. ı”, Usuario al servicio: “Trasladar a Michael Henson” Servicio al cliente de mensajer´ de Michael Henson: ’Joe Doe solicita aprobaci´n ıa o ...’. 4. Alerta de nuevos RSS y podcast Los servicios como Bloglines (http://www.bloglines.com) pueden aprovecharse de la infraestructura de Google Talk para enviar notificaciones RSS en vez de solicitar a los usuarios que instalen una aplicaci´n propietaria o en sus equipos. 5. Notificaciones de calendario un servicio SLEE se puede escribir para sincronizarse con un calendario de usuario mediante iCal o SyncML. Se pueden enviar a la cuenta de Google Talk del usuario mensajes recordatorios. El bot del calendario puede incluso soportar interacci´n con el usuario, como o ˆ “Recordar en 5”, queriendo decir que le reenv´ la notificaci´n en 5 ıe o minutos. ˆ “Aplazar para las 9am 11/05/05” ˆ “Cancelar”, lo que podr´ enviar una sugerencia al software del calenıa dario para enviar la notificaci´n al resto de participantes si el evento es o una entrevista. 6. Servicio de notificaci´n de ofertas de billetes de avi´n de ultima hora. o o ´ Southwest Airlines Ding! es una aplicaci´n que env´ a los usuarios ofertas o ıa actualizadas de billetes. Ding! ha sido descargado m´s de 1,3 millones de a veces y ha conseguido m´s de 50 millones de d´lares en compras desde que a o fue lanzada en febrero de 2005. Es poco probable que los usuarios descarguen e instalen una aplicaci´n para o cada aerolinea con la que tuvieran posibilidad de volar. Sin embargo, a˜adir un contacto por aerolinea a la lista de usuarios de Google n Talk es una opci´n realista. o 7. Alertas del mercado de acciones Este caso de uso apareci´ en un hilo en el foro de Google-Talk-Open o
- 418. 380 ANEXO F. EJEMPLOS Yahoo Messenger ofrece alertas instant´neas del mercado: a http://messenger.yahoo.com/intl/in/stocks.html Casi todos los d´ los proveedores de acciones informan de alg´n tipo de ıas u acciones. En vez de instalar un cliente especial solo para tareas de alerta, estos proveedores pueden simplemente enviar mensajes de IM a la gente que usa Google Talk. Esto les ahorrar´ los costes de desarrollar sus propias a aplicaciones clientes. Tambi´n incrementar´n el atractivo de su oferta, ya que e a sus clientes necesitar´n una aplicaci´n menos ejecut´ndose en su escritorio. a o a Un bot de acciones tambi´n podr´ soportar di´logos simples que ahorrar´ e ıa a ıan al usuario el tiempo de cambiar entre aplicaciones de escritorio: ˆ “Compra 10 XYZ”, desencadenar´ la compra inmediata de acciones ıa XYZ. ˆ “Vende ...” ˆ “Mant´n XYZ 5 horas”, lo que pospondr´ cualquier acci´n de come ıa o pra/venta sobre unas acciones determinadas 5 horas.
- 419. Anexo G Subversion G.1. Introducci´n o Subversion, tambi´n conocido como svn o SVN, es un software de sistema de e control de versiones dise˜ado espec´ n ıficamente para sustituir al actual CVS, por lo que tiene la mayor´ de las caracter´ ıa ısticas de este; Subversion soluciona muchos problemas del CVS, aumentando su funcionalidad y mejorando el rendimiento y dise˜o. Mun chos proyectos populares usan ya subversion, como Apache Software Foundation, KDE, GNOME, Freepascal, GCC, Python, Samba, Mono y muchos m´s. a Es un software libre bajo una licencia BSD modificada, la ultima versi´n es la 1.4.3, ´ o disponible desde el 25 de Enero del 2007. Una caracter´ ıstica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen cada uno un n´mero de revisi´n independiente. En cambio, todo u o el repositorio tiene un unico n´mero de versi´n que identifica un estado com´n de todos ´ u o u los archivos del repositorio en cierto punto del tiempo. G.2. clientes Los clientes m´s populares son tortoisesvn para Windows y el plugin de Eclipse a Subclipse. G.3. Subclipse Es un proyecto open source que integra Subversion en el IDE de Eclipse. Necesita Eclipse 3.2 y Mylar. G.3.1. G.3.1.1. Instalaci´n de Subclipse o Descarga con Eclipse por Subclipse 1. Bajar el plugin SVN para eclipse de http://subclipse.tigris.org 381
- 420. 382 ANEXO G. SUBVERSION 2. Haz click en Help → Software Updates → Find and Install Figura G.1: Find and Install 3. Selecciona Search for new features to install Figura G.2: Install/Update
- 421. G.3. SUBCLIPSE 383 4. Haz click en “New remote site”. Figura G.3: Install 5. La siguiente pantalla muestra el di´logo “New Remote Site”, rell´nalo con la ina e formaci´n correcta para instalar Mylar. o Para Eclipse 3.3M7 y posteriores Name: Mylar URL: http://download.eclipse.org/technology/mylar/update-site/e3.3 Para Eclipse 3.2 Name: Mylar URL: http://download.eclipse.org/technology/mylar/update-site/e3.2
- 422. 384 ANEXO G. SUBVERSION Figura G.4: New Update Site 6. Repite los pasos 4 y 5, pero esta vez para instalar Subclipse. Para Eclipse 3.2 y posterior. Name: Subclipse URL: http://subclipse.tigris.org/update 1.2.x 7. La primera vez que llegues a esta pantalla, aseg´rate que mylar y Subclipse est´n u a seleccionados antes de pulsar Next. Figura G.5: Install
- 423. G.3. SUBCLIPSE 385 8. La siguiente pantalla muestra todas las caracter´ ısticas que est´n disponibles para a instalar. Figura G.6: Instalaci´n o 9. Pulsa siguiente, acepta la licencia y confirma la instalaci´n. o Figura G.7: Confirmaci´n o
- 424. 386 ANEXO G. SUBVERSION Figura G.8: Proceso de instalaci´n o 10. Reinicia eclipse. Figura G.9: Aviso 11. Finalmente, despu´s de reiniciar Eclipse, lo primero que que tienes que querr´s e a hacer es abrir la perspectiva Repositorio Subclipse desde donde puedes definir tus repositorios SVN. Aseg´rate de haber consultado la ayuda online as´ como u ı las preferencias de Subclipse que est´n localizadas en Team → SVN. a
- 425. G.3. SUBCLIPSE 387 12. Windows → Open perspective → Other Figura G.10: Abrir perspectiva... Figura G.11: Abrir perspectiva
- 426. 388 ANEXO G. SUBVERSION 13. En la pesta˜a SVN Repository, haz click con el bot´n derecho, y ve a New → n o Repository Location... Figura G.12: Localizaci´n del Repositorio o 14. Introduce la direcci´n del Repositorio SVN o Figura G.13: Localizaci´n del Repositorio o
- 427. G.3. SUBCLIPSE 389 15. Introduce el nombre de usuario y la contrase˜a n Figura G.14: Usuario y Contrase˜a n 16. Ahora solo tienes que dar al bot´n derecho sobre el repositorio a˜adido en la o n pesta˜a de SVN Repository n Figura G.15: Checkout
- 428. 390 ANEXO G. SUBVERSION 17. Finalmente pulsa Finish Figura G.16: Checkout from SVN 18. Y despu´s de descargarlo, tendremos finalmente el proyecto del repositorio e Figura G.17: Proyecto descargado de SVN
- 429. Glosario 3GPP (3rd Generation Partnership Project) Es un acuerdo de colaboraci´n en tecnolog´ de telefon´ m´vil, que fue establecido o ıa ıa o en Diciembre de 1998. 3PCC (Third Party Call Control) Es el t´rmino para la configuraci´n de la sesi´n echa por un tercero distinta al e o o que en realidad intercambia el media. Este tercero tiene el control de la sesi´n o y puede terminarla o manipularla de distintas maneras, por ejemplo, invitar de nuevo a las partes para cambiar las propiedades del media AC (Activity Context) Objeto de dominio SLEE para encapsular el Activity definido por los Resources.Canal de eventos en el cual los eventos son lanzados y distribuidos API (Application Programming Interface) Interfaz de Programaci´n de Aplicaciones. es el conjunto de funciones y procedo imientos (o m´todos si se refiere a programaci´n orientada a objetos) que ofrece e o cierta librer´ para ser utilizado por otro software como una capa de abstracci´n. ıa o ATM (Asynchronous Transfer Mode) Tecnolog´ de telecomunicaci´n desarrollada para hacer frente a la gran demanda ıa o de capacidad de transmisi´n para servicios y aplicaciones. o AVP (Attribute Value Pairs) Son una representaci´n fundamental de datos, ofrecen una estructura de datos o open-ended que permite futuras extensions sin modificar el c´digo o datos exiso tente. Activity Abstracci´n para una cadena de eventos relacionados o BEA 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. 391
- 430. 392 Glosario BHCA (Busy Hour Call Attempts) Se trata de una medida de tr´fico en telecomunicaciones utilizada para evaluar y a planificar la capacidad de las redes telef´nicas o CLI (Command Line Interface) Herramienta implementada en el proyecto principal de Mobicents cuyo principal tarea es proporcionar un medio para automatizar el despliegue de los ejemplos, implementado en los fichero build.xml CORBA (Common Object Request Broker Architecture) (arquitectura com´n de intermediarios en peticiones a objetos), es un est´ndar u a que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocaci´n de m´todos remotos bajo un paradigma orientado a objetos. o e CPS (Calls Per Second) CRM (Customer Relationship Management) Es un t´rmino amplio que cubre conceptos usados por las organizaciones para e lograr sus relaciones con clientes, incluyendo almacenamiento y an´lisis de infora maci´n del cliente. o CVS (Concurrent Versions System) Es una aplicaci´n inform´tica que implementa un sistema de control de versiones: o a mantiene el registro de todo el trabajo y los cambios en los ficheros que forman un proyecto y permite que distintos desarrolladores colaboren Contenedor de aplicaciones Application Server (AS) es un software engine que ofrece aplicaciones a clientes, aplican t´ ıpicamente middleware y manejan la mayor´ de la l´gica de negocio y ıa o acceso de datos de la aplicaci´n. los AS J2EE m´s utilizados son WebLogic Server o a (BEA), JBoss (Red Hat), WebSphere (IBM) y Galssfish DD (Deployment Descriptors ) Es un componente de aplicaciones J2EE que describe como se debe desplegar (o implantar) una aplicaci´n web. JSLEE aplica los conceptos del DD para la o configuraci´n, despliegue y empaquetado o DSL (Digital Subscriber Line) T´rmino utilizado para referirse de forma global a todas las tecnolog´ que e ıas proveen una conexi´n digital sobre l´ o ınea de abonado de la red telef´nica local. o DSP(Digital signal processing) ´ Area de la ingenier´ que se dedica al an´lisis y procesamiento de se˜ales (audio, ıa a n voz, im´genes, video) que son discretas. a
- 431. Glosario 393 DTD (Digital Type Definition) Documento que muestra la descripci´n de estructura y sintaxis de un documento o XML o SGML DTMF (Dual-Tone Multi-Frequency) Sistema de marcaci´n por tonos, tambi´n llamado sistema multifrecuencial. Cuano e do el usuario pulsa en el teclado de su tel´fono la tecla correspondiente al d´ e ıgito que quiere marcar, se env´ dos tonos, de distinta frecuencia, que la central deıan scodifica a trav´s de filtros especiales, detectando instant´neamente que d´ e a ıgito se marc´. o EDA (Event Driven Architecture) Es un patr´n de arquitectura de software que promueve la producci´n, detenci´n, o o o consumo, y reacci´n a eventos o EJB (Enterprise Java Bean) Son una de las API que forman parte del est´ndar de construcci´n de aplicaa o ciones empresariales J2EE de Sun Microsystems. Su especificaci´n detalla c´mo o o los servidores de aplicaciones proveen objetos desde el lado del servidor. ESME (External Short Message Entity) Es un t´rmino originalmente inventado por Aldisco para describir una aplicaci´n e o externa que se conecta a un SMSC para activarlo en su env´ y/o recepci´n del ıo o SMS. USSD es parecido a telnet, mientras que SMS es parecido al correo Eclipslee Es un plug-in para Eclipse dise˜ado para facilitar la creaci´n de componentes de n o JAIN SLEE con una interfaz amigable Endpoint Punto final que determina un nodo que interviene en el intercambio de datos. GPL (General Public License) Es una licencia creada por la Free Software Foundation, y est´ orientada princia palmente a proteger la libre distribuci´n, modificaci´n y uso de software. o o Gateway(Pasarela) Es un dispositivo, con frecuencia un ordenador, que realiza la conversi´n de proo tocolos entre diferentes tipos de redes o aplicaciones HLR (Home Location Register) Base de datos central que contiene los detalles de cada tel´fono m´vil que est´ aue o a torizado a usar la red central GSM.
- 432. 394 Glosario IANA (Internet Assigned Numbers Authority ) es la Agencia de Asignaci´n de N´meros de Internet. Era el antiguo registro o u central de los protocolos Internet, como puertos, n´meros de protocolo y empresa, u opciones y c´digos. Fue sustituido en 1998 por ICANN o IETF (Internet Engineering Task Force) Es una organizaci´n internacional abierta de normalizaci´n, que tiene como obo o jetivos el contribuir a la ingenier´ de Internet. ıa IMS (IP Multimedia Subsystem) Es un est´ndar de arquitectura NGN para operadores de telefon´ que quieren a ıa proveer servicios multimedia fijos y m´viles. Usa una implementaci´n de voz sobre o o ip (VoIP) basada en una implementaci´n est´ndar del SIP de 3GPP o a INAP(Intelligent Network Application Part) Es un protocolo de se˜ales usado en arquitectura de redes inteligentes. Es una n parte del protocolo SS7, t´ ıpicamente ubicado en la capa superior de TCA. IOR (Interoperable Object Reference) En computaci´n distribuida, es una referencia a un objeto CORBA o RMI-IIOP. o ITU (International Telecommunication Union) Es una organizaci´n internacional establecida para estandarizar y regular radio y o telecomunicaciones internacionales. IVR (Interactive Voice Response) Es una tecnolog´ telef´nica que permite a un ordenador detectar la voz e inıa o teractuar mediante marcaci´n por tonos MDTF usando una llamada normal de o tel´fono e J2EE Rama de la familia Java que nos presenta una arquitectura orientada a servicios (SOA). Esta plataforma nos permite seguir un flujo de ejecuci´n orientado a o eventos, frente al flujo de ejecuci´n secuencial que se nos presenta normalmente. o JAAS (Java Authentication and Authorization Service) Es una Interfaz de Programaci´n de Aplicaciones que permite a las aplicaciones o Java acceder a servicios de control de autenticaci´n y acceso. o JAIN (Java for the Advanced Intelligent Network) La iniciativa JAIN define un conjunto de APIs Java como soporte para el desarrollo r´pido de productos de comunicaciones de pr´xima generaci´n basados en a o o Java y servicios para la plataforma Java.
- 433. Glosario 395 JAIN SLEE Es el unico est´ndar industrial dirigido hacia aplicaciones de comunicaciones ´ a m´viles. Posee una especificaci´n t´cnica no ambigua, una implementaci´n de o o e o referencia y un riguroso suite de pruebas. JCC (Java Call Control) Especificaci´n definida por un subgrupo de Jain que define interfaces de aplicao ciones para iniciar y manipular llamadas JCP (Java Community Process) El Proceso de la Comunidad Java, establecido en 1998, es un proceso formalizado el cual permite a las partes interesadas involucrarse en la definici´n de futuras o versiones y caracter´ ısticas de la plataforma Java. JDBC (Java DataBase Connectivity) API para Java que define como un cliente puede acceder a una base de datos. Provee de m´todos para consultas y actualizaci´n de datos en la base de datos. e o Est´ orientado a bases de datos relaccionales. a JMF (Java Media Framework) Es un protocolo de se˜ales usado por la arquitectura de redes inteligentes (IN). n Es una parte de la suite del protocolo SS7, t´ ıpicamente en la capa superior de TCAP. JMS (Java Message Service) API para mandar mensajes entre dos o mas clientes. JMX (Java Management Extensions) La tecnolog´ JMX provee herramientas para construcci´n distribuida, basada en ıa o web, modular y con soluciones din´micas para la administraci´n y monitorizaci´n a o o de dispositivos, aplicaciones y redes orientadas a servicios. JNDI (Java Naming and Directory Interface) Interfaz de Nombrado y Directorio Java es una Interfaz de Programaci´n de Aplio caciones para servicios de directorio. Esto permite a los clientes descubrir y buscar objetos y nombres a trav´s de un nombre. Mobicents hace uso del componente e JNDI de JBoss 8.2 para registrar servicios SLEE JPA (Java Persistence API) Es un framework para Java que permite a los desarrolladores administrar datos relacionales en Java Platform, Standard Edition y aplicaciones Java Platform, Java Enterprise Edition JPQL (Java Persistence Query Language) El Lenguaje de consulta Java Persistence API
- 434. 396 Glosario JSP (JavaServer Pages) Se trata de una tecnolog´ Java que permite a los desarrolladores software el desarıa rollo de HTML, XML o cualquier otro tipo de documentos basados en responder una petici´n de un cliente Web o JSR (Java Specification Request) Son documentos oficiales que describe especificaciones y tecnolog´ propuestas ıas para ser a˜adidas a la plataforma Java n JTA (Java Transaction API) JTA Especifica interfaces Java est´ndar entre un administrador de transacciones a y las partes envueltas en un sistema de transacciones distribuido: el administrador de recursos, el servidor de aplicaciones y las aplicaciones transaccionales. JBoss tiene un componente JTA que usa Mobicents para la Administraci´n de Transaco ciones JVM (Java Virtual Machine) M´quina Virtual de Java, programa nativo, capaz de interpretar y ejecutar ina strucciones expresadas en un c´digo binario especial (el Java bytecode), el cual o es generado por el compilador del lenguaje Java. LDAP (Lightwaight Directory Access Protocol) Protocolo de tipo cliente-servidor que proporciona los mecanismos necesarios para acceder a un servicio de directorio y recuperar la informaci´n all´ almacenada. o ı MBean(Managed Bean) Representa un recurso ejecutandose en la JVM como una aplicaci´n, es un servicio o tecnico de J2EE. Puede usarse para configurar aplicaciones, recolectar est´ticos a y notificar eventos. MGCP (Media Gateway Control Protocol) Se trata de un protocolo usado dentro de sistemas distribuidos de VoIP. Viene definido por RFC 3435 MLET (Management applet) Es una utilidad de Managed Bean pr cargar, instanciar y registrar MBeans en el MBeanServer desde un descriptor XML MM7 Protocolo usado para el env´ de mensajes multimedia. Se basa en el concepto de ıo Web Services y usa SOAP y HTTP para la comunicaci´n. Los mensajes multio media se env´ al servidor o al repetidor MMS con el m´todo POST del HTTP. ıan e El cuerpo del post contiene datos XML sobre la entrega y el mensaje multimedia como un adjunto MIME1 -multipart. 1 Multipurpose Internet Mail Extensions
- 435. Glosario 397 MMC (Mobicents Management Console) Es un subproyecto de Mobicents; Esta aplicaci´n basada en web J2EE permite a o un administrador interactuar con Slee para realizar funciones de administraci´n o desde un navegador web. MPCCS(Multi-Party Call Control Service) El Multi-party Call Control service aumenta la funcionalidad de un servicio de control de llamada gen´rico mediante el manejo de “leg“. Permite tambi´n ese e tablecer llamadas multy-party. MSC (Mobile Switching Center) Es la central telef´nica en la cual se realiza el control y conmutaci´n de las o o llamadas telef´nicas, dentro de su cobertura, as´ como tambi´n la interconexi´n o ı e o con otros operadores de telefon´ (fija, m´vil, etc). ıa o MSCML (Media Server Control Markup Language) Es un protocolo usado en conjunci´n con SIP para habilitar la entrega de servicios o de conferencia multimedia avanzados a trav´s de redes IP e Mid-dialog Request Una petici´n comienza una nueva transacci´n junto con un di´logo ya establecido, o o a como esta descrito en el RFC 3261 ?? secci´n 12.2. Ejemplos son: re-INVITEs, o BYE, MESSAGE. Middleware Es un software que conecta componentes software o aplicaciones. Con frecuencia es usado para sostener aplicaciones distribuidas complejas. Incluye servidores web, servidores de aplicaciones, sistemas de administraci´n de contenidos y hero ramientas similares que sostienen el desarrollo y entrega de aplicaciones NGIN (Next Generation Intelligent Networks) Siguiente generaci´n de Intelligent network o OMA (Open Mobile Alliance) Es una organizaci´n de est´ndares que desarrolla est´ndares abiertos para la o a a industria de los tel´fonos m´viles. e o ORB (Object Request Broker) En Computaci´n distribuida es el nombre que recibe una capa de software (tamo bi´n llamada middleware) que permite a los objetos realizar llamadas a m´todos e e situados en m´quinas remotas, a trav´s de una red. Maneja la transferencia de a e estructuras de datos, de manera que sean compatibles entre los dos objetos ORM (Object-relational mapping) Es una t´cnica de programaci´n para convertir datos entre tipos de sistemas e o incompatibles en bases de datos y lenguajes de programaci´n orientados a objetos. o
- 436. 398 Glosario OSS (Operations Support Systems) Son sistemas de computadores usados por proveedores de servicios de telecomunicaciones. Out-of-dialog Request Una petici´n que env´ fuera un di´golo existente. El ejemplo m´s com´n es un o ıa a a u INVITE original que puede dirigirse a un di´logo creado pero que es por definici´n a o enviado antes de que ning´n di´logo exista u a POJO (Plain Old Java Object) Es una clase del lenguaje de programaci´n Java. Este nombre se les da a las clases o que no son de alg´n tipo especial (EJBs, Java Beans, etc) y no cumplen ning´n u u otro rol ni implementan alguna interfaz especial. POSIX (Portable Operating System Interface Unix) Se trata de una familia de est´ndares de llamadas al sistema operativo definidos a por el IEEE y especificados formalmente en el IEEE 1003 POTS (Plain Old Telephone Service) Red telef´nica cl´sica o a PSTN (Public Switched Telephone Network) red con conmutaci´n de circuitos tradicional optimizada para comunicaciones de o voz en tiempo real. Parlay/OSA Parlay/OSA es un API que permite a los operadores y las aplicaciones de terceros acceder a las funcionalidades de la red a trav´s de un conjunto de interfaces e estandarizados y abiertos. Profile (Perfil) Elemento de JainSLEE que contiene datos almacenados. Estos datos almacenados tienen un esquema, que es un conjunto de atributos o propiedades. RA (Resource Adaptor) Adapta la interfaz particular y los requisitos de un Resource dentro de las interfaces y requisitos de Jain SLEE RFC (Request for Comments) Es un documento cuyo contenido es una propuesta oficial para un nuevo protocolo de la red Internet, que se explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambig¨edades u RFID (Radio Frequency IDentification) Es un sistema de almacenamiento y recuperaci´n de datos remoto que usa diso positivos denominados etiquetas, transpondedores o tags RFID. El prop´sito funo damental de la tecnolog´ RFID es transmitir la identidad de un objeto (similar ıa a un n´mero de serie unico) mediante ondas de radio. u ´
- 437. Glosario 399 RTC (Red Telef´nica Conmutada) o Red telef´nica cl´sica o a RTP(Real-time Transport Protocol) Es un protocolo de nivel de aplicaci´n (no de nivel de transporte, como su nombre o podr´ hacer pensar) utilizado para la transmisi´n de informaci´n en tiempo real, ıa o o como por ejemplo audio y v´ ıdeo en una video-conferencia. Radius Es un protocolo AAA para aplicaciones de acceso a la red o movilidad IP. Es el padre del protocolo actual Diameter. Resource Entidades externas que interact´an con otros sistemas fuera del SLEE, tales como u elementos de red , protocolos de pila, directorios ´ bases de datos o SBB (Service Building Block) Elemento de reuso definido por Jain SLEE. Es un componente software que env´ ıa y recibe eventos y lleva a cabo l´gica computacional basada en la recepci´n de o o eventos y su estado actual. SCF (Service Capability Features) Abstracci´n de la funcionalidad ofrecida por la red, accesible mediante el API de o OSA/Parlay. Algunas veces se les llama servicios SDP (Service Delivery Platform) Se refiere a una incorporaci´n reciente de un estilo arquitect´nico aplicado a o o los problemas de infraestructura de telecomunicaciones. Est´ dirigido a permitir a desarrollo y despliegue r´pido de nuevos servicios multimedia convergentes a SDP (Session Description Protocol) Es un formato para describir los pr´metros de la inicializaci´n del streaming a o media. Fue publicado por el IETF como RFC 4566[45] SIP (Session Initiation Protocol) Es un protocolo desarrollado con la intenci´n de ser el est´ndar para la iniciaci´n, o a o modificaci´n y finalizaci´n de sesiones interactivas de usuario donde intervienen o o elementos multimedia. En Noviembre del a˜o 2000, SIP fue aceptado como el n protocolo de se˜alizaci´n de 3GPP y elemento permanente de la arquitectura n o IMS. SLEE (Service Logic Execution Environment) Se trata de un servidor de aplicaciones. Es un contenedor para componentes software. La especificaci´n SLEE est´ dise˜ada y optimizada para EDA. o a n
- 438. 400 Glosario SMPP El protocolo de mensajes cortos peer-to-peer 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. SMSC (Short Message Service Center) Es un elemento de la red de tel´fonos m´viles que se encarga de entregar los e o mensajes SMS SNMP (Simple Network Management Protocol) Protocolo para gesti´n de redes. Consta de un agente en el dispositivo gestionable o que env´ informaci´n al gestor, para informarle del estado de ese dispositivo. ıa o SOA (Service-Oriented Architecture) Es un concepto de arquitectura de software que define la utilizaci´n de servicios o para dar soporte a los requerimientos de software del usuario Cualquier SOA contiene tres actores: Un solicitante de servicio, un proveedor de servicios, y un registro de servicios. SOAP (Simple Object Acces Protocol) Protocolo est´ndar bajo la supervisi´n del W3C para favorecer la comunicaci´n a o o de objetos en diferentes procesos mediante el uso de XML. Muy utilizado en servicios web. SQL (Structured Query Language) Lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas SS y SS7 La familia de sistemas de se˜alizaci´n son unos protocolos que permiten el esn o tablecimiento y el control de llamadas de tel´fonos en la red fija en todo el mundo. e Concretamente la versi´n 7 (SS7), separa los canales de se˜alizaci´n y datos, sieno n o do la versi´n m´s ampliamente utilizada hoy en d´ o a ıa. SoftPhone Es un software para realizar llamadas telef´nicas desde un ordenador. o Subversion Tambi´n conocido como svn o SVN, es un software de sistema de control de e versiones dise˜ado espec´ n ıficamente para sustituir al actual CVS TCAP (Transaction Capabilities Application Part) Provee un mecanismo para aplicaciones orientadas a transacciones
- 439. Glosario 401 TCK (Technology Compatibility Kit) Es un conjunto de pruebas que al menos comprueba nominalmente una implementaci´n particular supuesta de un Java Specification Request (JSR) para su o cumplimiento TPS (Transactions Per Second) Telco Es un t´rmino gen´rico para compa˜´ de telecomunicaciones e e nıas UDDI (Universal Description Discovery and Integration) Plataforma est´ndar que permite a las compa˜´ y aplicaciones descubrir y usar a nıas servicios web en internet r´pida, f´cil y din´micamente. a a a URI (Uniform Resource Identifier) Es una cadena corta de caracteres que identifica un´ ıvocamente un recurso, definido en RFC 2396[31] USSD (Unstructured Supplementary Service Data ) Es una capacidad de todo tel´fono GSM. Est´ generalmente asociado con tipos de e a servicios de tel´fono en tiempo real o instant´neo. No hay capacidades almacenar e a y enviar que es t´ ıpica de los mensajes cortos ’normales’ (en otras palabras, no est´ presente un SMSC en el procesamiento de la ruta). El tiempo de respuesta a para servicios interactivos basados en USSD son generalmente mas r´pidos que a aquellos usados por SMS VXML (Voice eXtensible Markup Language) Se trata de un est´ndar de W3C con formato XML que especifica di´logos intera a activos entre personas y ordenadores VoIP (Voice over Internet Protocol) Grupo de recursos que hacen posible que la se˜al de voz viaje a trav´s de Internet n e empleando un protocolo IP (Internet Protocol). WSDL (Web Services Definition Language) Documento XML que se utiliza para la descripci´n de las interfaces p´blicas o u de los servicios web. Describe la forma de comunicaci´n, es decir, los requisitos o del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su cat´logo. A menudo se usa junto con SOAP. a WSRP (Web Services for Remote Portlets) es un est´ndar para los agregadores de contenido para acceder y mostrar fuentes a de contenido almacenadas en un servidor remoto. Intenta facilitar el “plug and play” Wireless Redes de comunicaciones sin cable.
- 440. 402 Glosario Wireline Redes de comunicaciones con cable. XML (eXtensible Markup Language) Es un lenguaje de marcas de prop´sito general. Su prop´sito principal es facilitar o o la compartici´n d datos a trav´s diferentes sistemas de informaci´n o e o XMPP eXtensible Messaging and Presence Protocol, Protocolo extensible de mensajer´ ıa y presencia es un protocolo XML para mensajer´ instant´nea (tiempo casi real), ıa a presencia y servicios de petici´n y respuesta. o XSLT( Extensible Stylesheet Language Transformations) Para hacer transformaciones y consultas sobre documentos XML. ebXML (Electronic Business using XML es un lenguaje basado en XML que permite a empresas de todo tama˜o tener un n m´todo est´ndar para intercambiar mensajes de negocios, gestionar relaciones de e a negocio y definir y registrar procesos de negocio.
- 441. ´ Indice alfab´tico e 3rd Generation Partnership Project, 141 , 34 External Short Message Entity, 171 Hoja de ruta, 59, 185 Home Location Register (HLR), 53 Intelligent Network Application Part, 63 Interactive Voice Response (IVR), 108 International Telecommunication Union, 141 Internet Assigned Numbers Authority , 181 Internet Engineering Task Force, 141 Interoperable Object Reference (IOR), 126 AAA, 181 Acceso remoto, 338 Activity, 37 Activity Context (AC), 38 Activity Context Interface (ACI), 75 Asterisk, 113 J2EE, 14 Asynchronous Transfer Mode (ATM), 119 JAAS, 12 Attribute Value Pairs (AVP), 181 JAIN SIP, 141 JAIN SLEE, 15, 21 BEA, 11 Java Call Control (JCC), 15, 37, 53 Busy Hour Call Attempts (BHCA), 29 Java Community Process (JCP), 161 Java DataBase Connectivity (JDBC), 53 Calls Per Second (CPS), 62 Java Management Extensions (JMX), 12, Concurrent Versions System (CVS), 215 60, 117 CORBA, 125 Java Media Framework (JMF), 63, 120 Customer Relationship Management, 60 Java Message Service (JMS), 23 Java Naming and Directory Interface, 25, Descriptor desplegable (DD), 71 85 Diameter, 181 Java Persistence API (JPA), 63, 136 Digital signal processing (DSP), 117 Java Persistence Query Language (JPQL), Digital Subscriber Line(DSL), 116 136 Digital Type Definition (DTD), 282 Dual-Tone Multi-Frequency (DTMF), 178 Java Specification Request (JSR), 5, 141 Java Transaction API (JTA), 61 Eclipslee, 277 Java Virtual Machine (JVM), 30, 45 Endpoint, 118 JavaServer Pages (JSP), 24 Enterprise Java Bean (EJB), 24, 36 Lightweight Directory Access Protocol (LDAP), Enterprise Java Beans (EJB), 136 217, 332 Event Driven Architecture (EDA), 10, 60 Evento, 109, 111, 283 Managed Bean (MBean), 117, 337 Gateway, 124 Management applet (MLET), 108 General Public License (GPL), 63 Media Gateway Control Protocol (MGCP), 116 GoogleTalk, 373, 377 403
- 442. 404 Media Server Control Markup Language, 63 Mejores pr´cticas, 69 a Mid-dialog Request, 161 Middleware, 59 MM7, 18, 189 Mobicents, 59 Command Line Interface (CLI), 335 Foros, 67 Licencia, 63 Management Console (MMC), 342 Rendimiento, 62 Mobile Switching Center (MSC), 53 MPCCS, 128 ´ ´ INDICE ALFABETICO Persistence, 136 RA Parlay, 124 SIP, 140, 189, 350 SMPP, 171, 189, 373 XMPP, 176, 373, 377 SCF, 131 Server transaction activity, 164 Service Building Block (SBB), 40, 108, 109, 293, 341 Service Delivery Platform (SDP), 59 Service Logic Execution Environment, 10, 21 Servicio, 306, 340, 344 Servicios Mobicents, 189 Network management systems (NMS), 60 Session Description Protocol (SDP), 148, Next Generation Intelligent Networks, 60 154 Next Generation Networking, 11 Short Message Peer to Peer (SMPP), 16, 171 Object Request Broker (ORB), 126 Short Message Service Center (SMSC), 171 Open Mobile Alliance (OMA), 141 Signaling System 7 (SS7), 63 Operations Support Systems (OSS), 60 Simple Network Management Protocol, 12 Out-of-dialog Request, 161 SIP, 16, 104, 140 Addressing, 154 Parlay, 124 Dialogs, 159 Parlay X, 124, 360 Headers, 153 Perfil, 108, 110, 340 Listener, 145 Plain old telephone service (POTS), 59 Messages, 147 Profile, 50, 288 Request, 148 Public Switched Telephone Network (PSTN), Response, 149 15, 116 SipFactories, 147 Radio Frequency IDentification (RFID), 11, SipProvider, 144 60 SipStack, 142 Radius, 181 Transactions, 157 Real-time Transport Protocol(RTP), 117, SoftPhone, 271 178 SS7, 16 Request for Comments (RFC), 142 Structured Query Language (SQL), 321 Resource, 53 Subversion, 381 Resource Adaptors, 53, 62, 113, 339, 346 SVN, 381 Asterisk, 113, 189 Technology Compatibility Kit (TCK), 141, Diameter, 181, 189 265 Framework, 69 Third Party Call Control (3PCC), 159, 189, Media, 178, 189 359 MGCP, 116, 189 Parlay, 189 Transaction Capabilities Application Part, Parlay X, 189 63
- 443. ´ ´ INDICE ALFABETICO Transactions Per Second (TPS), 62 Unidad desplegable, 310, 343 Uniform Resource Identifier (URI), 147 USSD, 171 Voice eXtensible Markup Language, 178 Voice over Internet Protocol(VoIP), 116, 178 Web Services Definition Language, 12 WebLogic, 62 WebService (WS), 360 Wireless, 116 Wireline, 116 XMPP, 18, 176 405