despliegue en el sds ericsson -...

Servicio de Coche Compartido basado en el IMS

Capítulo III

Despliegue en el SDS Ericsson

En el primer capítulo dedicamos una sección a hablar del emulador del IMS que ibamos a usar.

Éste era el Service Development Studio de Ericsson, un plug-in para el entorno de desarrollo Eclipse.

También describimos su arquitectura emulada y su entorno de ejecución de pruebas.

En este nuevo capítulo nos encargaremos de explicar como desplegar el servicio diseñado en el

emulador. Abordaremos desde la creación de un proyecto hasta la ejecución de pruebas, pasando por la

adición de Servlets, clases, ficheros y la configuración del HSS. Terminaremos viendo los problemas

encontrados durante su despliegue y obtendremos algunas conclusiones derivadas del despliegue del

servicio.

1 Creación de un proyecto nuevo

En esta sección veremos como crear un proyecto en el SDS desde cero, como añadir Servlets,

Clases, Interfaces, ficheros XML y XSD; así como editarlos cómodamente.

Una vez arrancado el entorno de ejecución Eclipse, se efectúa la siguiente operación:

• File → New → Dynamic SIP/Web Project

A continuación en la Ilustración 1 se muestra la lista de herramientas disponibles que se

encuentran dentro del menú New.

80

Capítulo III: Despliegue en el SDS Ericsson

Al seleccionar Dynamic SIP/Web project se muestra un submenú como el que se aprecia en la

Ilustración 2. Como vemos, debemos darle un nombre al proyecto y después pulsar el botón Finish.

Con estos dos pasos ya tenemos creado un proyecto nuevo en la carpeta de trabajo y se

visualizará en Eclipse en el margen izquierdo, en la vista Project Exporer.

81

Ilustración 1: Ventana New. Creación de un proyecto nuevo.


1.1 Añadir un SIP Servlet

Como vemos en la Ilustración 1, en el menú New también existe la posiblidad de crear un nuevo

Servlet SIP. Si se selecciona SIP Servlet y se pulsa en el botón Next aparecerá una ventana como la

de la Ilustración 3.

Como puede apreciarse, sólo tenemos que indicar un nombre para la clase y el paquete en el que

queremos que se incluya. Al pinchar sobre el botón Next aparece el cuadro de diálogo mostrado en

la Ilustración 4. En ella se muestra la configuración del SIP Servlet, en la que debemos seleccionar

82

Ilustración 2: Submenú Dynamic SIP/Web Project.


los métodos a implementar y el nombre del recurso. En nuestro caso siempre elegiremos el recurso

SIP Factory y el método dependerá de cada caso1.

1 El método Java a implementar depende de la petición que vaya a recibir el Servlet. Si va a recibir un MESSAGE, por ejemplo, utilizaremos el método doMessage (SipServletRequest) donde el parámetro que recibe es justamente el MESSAGE.

83

Ilustración 3: Creación de nuevo SIP Servlet.


1.2 Añadir Clases e Interfaces Java al proyecto

Moviéndonos por el menú New también se observa la posibilidad de añadir Clases e Interfaces

Java al paquete del proyecto (com.carpooling). El cuadro de diálogo que ofrece Eclipse en cada

caso es el mostrado en las Ilustraciones 5 y 6, respectivamente.

De nuevo, se le da un nombre a la Clase o Interfaz y se incluyen dentro de nuestro proyecto.

Servlets, Clases e Interfaces son situados en la carpeta src como ficheros fuente que son.

84

Ilustración 4: Configuración del SIP Servlet.


85

Ilustración 5: Creación de una nueva Clase Java.


1.3 Añadir archivos XML, XSD y de texto

Como ya se describió en el capítulo anterior, durante el diseño del servicio se utilizan ficheros de

configuración XML para las cabeceras SIP y la base de datos. También se habló que el contenido de

los mensajes recibidos en cada Servlet se validaría contra archivos XSD (XML Schema Definition).

En el menú New se nos permite crear estos dos tipos de archivo, apareciendo agrupados bajo una

carpeta denominada XML. Al seleccionarlos aparecen los cuadros de diálogo de las Ilustraciones 7 y

8.

86

Ilustración 6: Creación de una nueva Interfaz Java.


87

Ilustración 7: Creación de un nuevo fichero XML.


Eclipse permite una edición manual de los archivos .xml y .xsd y otra cómoda interfaz de diseño

para agregar elementos, atributos y restricciones (en el caso de los esquemas). La edición de diseño

ha sido mostrada en las Ilustraciones 9 y 10.

88

Ilustración 8: Creación de Esquema XML.


89

Ilustración 9: Edición de ficheros .xml en Eclipse Vista de diseño.


Por último, para la internacionalización del servicio es necesario la utilización de ficheros de

idiomas. Éstos, no son mas que archivos de texto con extensión .properties que los organizaremos

dentro del paquete com.carpooling.resources. El cuadro de diálogo para ficheros de texto se ha

representado en la Ilustración 11.

90

Ilustración 10: Edición de ficheros .xsd en Eclipse. Vista de diseño.


Al margen de la organización que hace Eclipse del proyecto, debemos tener en cuenta que el

proyecto va a ser albergado en un servidor y por tanto los ficheros de configuración debemos

alojarlos en una carpeta para que él los encuentre. Esta carpeta será:

• SDS/sailfin/domains/my_domain/config.

En el caso de este servicio, my_domain es que usa el SDS por defecto: ericsson.com.

91

Ilustración 11: Creación de nuevo fichero de texto.


1.4 Instalación de la Base de Datos

Como ya se comentó en el capítulo anterior, la base de datos usada, es la proporcionada por el

servidor XAMPP. Una vez descargado e instalado2, tenemos que descargar el conector JDBC para

bases de datos MySQL3. Tras descargarlo, tenemos que realizar dos operaciones:

1. Incluirlo en el AS. Debemos trasladar el archivo .jar a la carpeta:

C:\SDS\Genuitec\Profiles\EricssonSDS\sailfin\domains\my_domain\lib\ext

2. Configurar el AS mediante la consola de administración4. Si se despliega el menú

Resources → JDBC → Connection Pools y se selecciona New, aparecen los campos (que

hay que completar como sigue) :

◦ Name: MySQL

◦ Resource Type: java.sql.ConnectionPoolDataSource

◦ Database Vendor: MySQL

◦ Por otro lado, en la pestaña Adicional Propperties completan los campos URL y Url

con: jdbc:mysql://localhost:3306/carpooldb?user=root&password=

La siguiente ilustración muestra la configuración de la base de datos en el servidor GlassFish.

2 Una guía de instalación para el S.O. Windows pueden encontrarse en [http://www.apachefriends.org/en/xampp-windows.html, 2012].

3 Podemos encontrarlo en la Web Oficial de MySQL: [http://dev.mysql.com/downloads/connector/j/, 2012]4 Para acceder a ella se arrancas el servidor, se abre un navegador Web con la url: http://localhost:4848.

92


2 Provisionamiento del servicio

En esta sección vamos a tratar la configuración de los elementos de la red del IMS para el

despliegue del servicio en ella. Empezaremos viendo la configuración de los dominios utilizados en

el servidor DNS. Continuaremos con el provisionamiento del HSS, en el que exploraremos el

filtrado de peticiones SIP, la creación de un perfil de servicio y terminaremos con los perfiles de

usuario.

2.1 Configuración del DNS

Para traducir los dominios utilizados a direcciones IP, debemos incluir los mismos en el servidor

DNS. Hemos utilizado dos dominios:

1. El del servidor. Se le ha asignado sip:ericsson.com.

2. El del Location Enabler. Se le ha asignado sip:location.ericsson.com.

La siguiente ilustración muestra la ventana de configuración del DNS.

93

Ilustración 12: Configuración de la Base de Datos en el Servidor de Aplicaciones.


2.2 Filtrado de peticiones SIP

Para controlar las condiciones que hacen que se ejecuten los distintos casos vistos en el carpítulo

anterior, el HSS dispone de dos herramientas de configuración que ya analizamos en el primer

capítulo: el Filtro de Criterios Iniciales (Initial Filter Criteria, IFCs) y los Puntos de Disparo del

Servicio (Service Point Trigger, SPT). En este apartado, se estudiará la configuración el servicio de

ofertas de conductores5.

2.2.1 IFCs

En nuestro servicio se definirán tantos IFCs como Servlets. Para añadir uno nuevo, en la pestaña

Definition se pulsa Add. Todos van a ser configurados con la misma condición de disparo: “All

triggers in a group true and at least one group true”. La Ilustración 14 muestra esta configuración.

5 No hay que olvidar que un servicio en el IMS se compone de pequeños servicios. Esto es, precisamente, la integración de servicios, uno de las características más importantes del IMS.

94

Ilustración 13: Configuración del servidor DNS.


2.2.2 SPTs

Cada IFC definido en el servicio tiene asociado un conjunto de SPTs en el que se definen los

métodos SIP que disparan el IFC y la uri a la que van destinados. Para añadir un SPT a un IFC, nos

situamos ahora en la pestaña Service Point Trigger y se pulsa Add.

En el caso del servicio de ofertas de conductores, tenemos un IFC que hemos denominado

Driver con dos SPTs:

1. DriverMessage: Se indica aquí que para que se dispare el servicio debe recibirse un SIP

MESSAGE. Este SPT se ha mostrado en la Ilustración 15.

2. DriverRequestURI: Con este SPT se especifica que la segunda condición de disparo deber

ser que el MESSAGE debe ir dirijido a sip:[email protected]. La Ilustración 16

representa este SPT.

Si se cumplen estas dos condiciones, el servicio se ejecuta.

95

Ilustración 14: Vista de IFCs.


96

Ilustración 15: SPT DriverMessage.

Ilustración 16: SPT DriverRequestURI.


2.2 Creación de un perfil de servicio

Un perfil de servicio está constituido por uno o más IFCs con sus correspondientes SPTs. Para

definir uno nuevo, en la pestaña Service Profile pulsamos el botón Add. Ahora se le da un nombre y

se activan los IFCs que lo componen. La siguiente imagen ilustra el perfil de servicio utilizado en

este proyecto y que se denomina carpooling. Como se observa, está formado por cinco IFCs:

Driver, Passenger, User, Carpool y LocationEnabler.

2.3 Creación de perfiles de usuario

Los usuarios que vayan a utilizar el servicio deben estar registrados en el HSS con el perfil de

ese servicio activado. Para crear perfiles de usuario, hay que seleccionar la pestaña User Profile, y

pulsar el botón Add. Se les define una uri SIP pública y otra privada y se le activa un perfil de

servicio. La siguiente ilustración muestra los usuarios registrados en el HSS con perfil de servicio

carpooling.

97

Ilustración 17: Perfil de servicio carpooling.


3 Configuración del descriptor de despliegue: archivos sip.xml y package-info.java

Hemos visto que el CSCF filtra las peticiones SIP que son reenviadas al AS según la uri y el

método SIP. Pero, ¿cómo distingue el AS el Servlet que debe atender a cada petición? J2EE (Java 2

Enterprise Edition) dispone de un mecanismo denominado descriptor de despliegue que permite

mapear uris SIP a un Servlet en concreto. Esto se consigue editando el fichero sip.xml.

En la vista de diseño del sip.xml, se selecciona con el botón derecho en el elemento sip-app y se

pulsa la opción: Add Child → servlet. Esta acción creará un nuevo elemento servlet con dos

elementos hijos:

1. servlet-name: Se le da un nombre.

2. servlet-class: Aquí se indica el nombre de la clase completa.

Con esto ya se ha definido el Servlet. Ahora sólo falta establecer unas reglas de mapeo y

asociarlas a dicho Servlet. Para ello, sobre sip-app se marca la opción: Add Child → servlet-

mapping. Se creará un elemento servlet-mapping con dos elementos hijos:

98

Ilustración 18: Perfiles de usuario.


1. servlet-name: El nombre del Servlet que hemos definido.

2. pattern: Éste elemento es la regla que debe cumplir el servlet. Viene por defecto con un

elemento hijo and y un subelemento and hijo del anterior. Estos elementos pueden

sustituirse por otros picando sobre ellos con el botón derecho y seleccionando la opción

Replace with que mostrará una lista con los elementos: contains, equals, exists, not, or y

subdomain-of.

En la Ilustración 19 se muestra la vista de diseño del fichero sip.xml y la configuración del

Servlet Driverbid.

Por otro lado, las aplicaciones dinámicas SIP/Web requieren la definición de un Servlet principal

que muestre la página Web de bienvenida al desplegar el servicio. Para ello es necesario crear un

fichero llamado package-info.java con la anotación @SipApplication6 que indica el nombre de la

6 La especificación SIP Servlet 1.1 define una serie de anotaciones en código que simplifican el desarrollo de aplicaciones SIP y hacen opcional el archivo sip.xml. Sin embargo, éste último parece más sencillo y flexible de usar aunque no permite definir el servlet principal.

99

Ilustración 19: Vista de diseño de sip.xml. Configuración del Servlet Driverbid.


aplicación y el Servlet principal, papel que en nuestro caso va a ser desempeñado por Driverbid.

El contenido de estos dos archivos será mostrado en el Anexo II.

4 Entorno de ejecución del SDS

En esta sección veremos las acciones a realizar para ejecutar el servicio. Empezaremos viendo

como arrancar todos los servidores: CSCF, DNS, AS y DB. Continuaremos viendo como realizar

una prueba con el ATF y por último la visualización de los resultados mediante los diagramas de

intercambio de mensajes que llegan y salen del CSCF, tomando como ejemplo la creación de un

perfil de usuario.

4.1 Arrancar los servidores

Para arrancar CSCF y DNS, en la pestaña SDS dentro de Eclipse se marca la opción Server →

CSCF/DNS → Start CSCF/DNS.

Para desplegar el servicio en el AS, se selecciona con el botón derecho en nuestro proyecto (vista

Package Explorer) la opción Run As → Run on Server y se espera a que sailfin muestre el estado

[Started, Synchronized].

Para arrancar la DB, se abre el XAMPP Control Panel y automáticamente será arrancado. Si se

pulsa en el botón Admin nos abrirá una nueva pesataña en nuestro navegador por defecto con la

interfaz phpMyAdmin que nos muestra todas las bases de datos asociadas al servidor y permite

navegar sobre ellas (Ilustración 20).

100


4.2 Ejecución de baterías de pruebas en el Automated Testing Framework (ATF)

El ATF permite ejecución de baterías de pruebas que son generados mediante scripts xml. Estos

scripts no hace falta crearlos manualmente, sino que desde la vista de ATF se ofrece una interfaz

muy intuitiva.

Al ATF se accede desde SDS → Test tools → Automated Testing Framework.

Para crear una nueva prueba, se pulsa en el botón Add Script aparecerá un nuevo script que

podemos nombrar y bajo él cuatro elementos:

1. User Agent: Usuarios que van a participar en la prueba. Se pueden añadir usuarios con el

botón Add User Agent.

2. Variables: Las variables que van a actualizarse durante la ejecución de la prueba. En nuestro

caso siempre usaremos la variable ServiceRoute que se actualizará con el valor de la

cabecera SIP service-route.

3. Test Cases: Los casos que va a contemplar la prueba. Para crear un nuevo caso se pulsa en

101

Ilustración 20: Interfaz phpMyAdmin.


Add Test Case.

4. Test Suites: Permite la ejecución de los casos definidos en 3. Para añadir uno nuevo hay que

pulsar el botón Add Test Suite. Para ejecutar, se selecciona un caso y se pulsa en Run Test

Suite.

4.3 Visualizando resultados con Visual Traffic Flow

El CSCF tiene la posibilidad de analizar en tiempo real los mensajes que pasan por él. Para

activarla sólo tenemos que ir a SDS → Server → CSCF → Analyse Log Real Time. Cuando

ejecutemos la prueba, el CSCF generará un diagrama de intercambio de mensajes que podremos

visualizar mediante la herramienta Visual Traffic Flow, que está accesible en el mismo menú

anterior. La siguiente ilustración muestra un diagrama de paso de mensajes durante la ejecución de

una de las pruebas.

102

Ilustración 21: Visualización de resultados con Visual Traffic Flow.


5 Problemas encontrados

En esta sección se van a explorar todas las dificultades encontradas a la hora del desarrollo de

este proyecto. En algunos casos veremos problemas de funcionamiento del SDS y otros por

desconocimiento que han requerido un esfuerzo de investigación mayor para su solución.

5.1 Ericsson ha dejado de dar soporte para el SDS

Tras la instalación y ejecución de Eclipse, en la ventana de instalación de nuevos plug-ins se

pudo observar que el SDS no se encontraba entre la lista de nuevas herramientas a instalar. Se probó

a utilizar la dirección del repositorio ftp donde está ubicado el software pero falla la conexión al

mismo.

Tras buscar en los foros del portal de desarrolladores de Ericsson, se econtró que el SDS ya no

formaba parte de los paquetes que ofrecen sus laboratorios.

Esto no sólo ha implicado hacer una mala instalación del SDS (lo que ha impedido la instalación

de nuevos plug-ins sobre Eclipse) sino que también ha dificultado la solución de los fallos que

sucedieron durante el desarrollo del servicio.

5.2 Inestabilidad del emulador

El emulador presenta cierta inestabilidad en alguna de sus herramientas que han dificultado la

ejecución, prueba y depuración del servicio. Por ejemplo, el CSCF parece desbordarse cuando las

pruebas implican a más de un usuario o muchos mensajes SIP. Esto complica el análisis de los

diagramas de flujo.

La primera ejecución de pruebas en el ATF da error en ocasiones debido a que el CSCF no envía

algún mensaje. Sin embargo, al comprobar el estado de la base de datos se observa que no ha

habido ninguna interrupción en la ejecución del servicio. Tras una segunda prueba, los resultados

son los esperados.

Además el AS tarda demasiado tiempo en arrancar e incluso en muchas ocasiones la primera y

la segunda vez que se arranca falla.

103


5.3 Pruebas con cliente Android fallidas

El SDS incorpora una herramienta para el desarrollo de clientes basados en Java ME7. Sin

embargo, la tendencia en telefonía móvil hace que las aplicaciones Java para sistemas Symbian

estén algo obsoletas. Android es un sistema operativo diseñado para móviles con pantalla táctil

cuyas aplicaciones se desarrollan en Java. Estas fueron las razones que llevaron a la realización una

aplicación probado sobre un teléfono Android utilizando también Eclipse8.

Sin embargo, el resultado obtenido no fue el esperado. Si bien el registro en la red lo hacía

correctamente, a la hora de enviar un SIP MESSAGE se producía un bucle entre los distintos CSCFs

sin aparente explicación.

5.4 Fallos tras los dos primeros Servlets

Tras desarrollar los dos primeros Servlets SIP, se observó que los mensajes nunca llegaban al

segundo. Se buscaron analogías en el desarrollo de servicios Web9, se descubrió la necesidad del

Descriptor de Despliegue, editando así el archivo sip.xml. Observando el fichero server.log dónde el

AS registra todos sus eventos, se observó que había un mensaje de error por no haber definido un

Servlet principal. Buscando en foros de Oracle10, se encontró que era necesario crear el archivo

package-info.java con las anotaciones SIP.

Con estas dos acciones el servicio se ejecutó a la perfección y se pudieron añadir los demás

Servlets con sólo volver a editar el descriptor de despliegue.

6 Conclusiones

Durante este capítulo hemos seguido todos los pasos necesarios para el despliegue y ejecución

del servicio en el emulador SDS. Pese a ser una configuración compleja, el SDS ofrece los

elementos necesarios para la depuración de errores con los mensajes de fallo del ATF y la cómoda

visualización de los diagramas de flujo. Sin embargo, el desinterés de Ericsson por esta herramienta

7 Java ME es una plataforma diseñada para sistemas embebidos, como por ejemplo, móviles.8 La información de la instalación del SDK de Android como plug-in de Eclipse se puede encontrar en

[http://developer.android.com/sdk/installing/installing-adt.html, 2012].9 Me apoyé en el estudio de [Bryan Bashram, Kathy Sierra y Bert Bates, 2004] sobre Servlets y jsp.10 Oracle es la multimancional americana que compró a la empresa desarrolladora del lenguaje Java, Sun

MicroSystems.

104


ha cortado su evolución, la solución de algunos bugs y su integración con clientes de telefonía

móvil más actuales.

105

despliegue en el sds ericsson -...

Documents