ANÁLISIS Y PRUEBA DE CONCEPTO PARA LA ADOPCIÓN DE SOA...

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

115 ANEXOS

4. ANEXOS

4.1. INSTALACIÓN DEL BUNDLE

Este apartado no consiste únicamente en la propia instalación del bundle, la cual no es para nada complicada. Sino que también se explica cómo está estructurado dicho bundle y cómo llevar a cabo la compilación del mismo.

4.1.1. CÓDIGO FUENTE

Se va a comenzar describiendo los archivos en los que se basa la aplicación y cómo están organizados. Se cuenta con un total tres tipos de archivos: archivos de configuración xml, archivos java y templates velocity. Según el tipo y su función, el archivo irá colocado en una carpeta u otra dentro del directorio raíz del proyecto. La estructura del proyecto se muestra en la Figura B.4.1. Hay una serie de ficheros y carpetas que no aparecen en este esquema. No se han puesto pues son archivos que Eclipse genera automáticamente para gestionar el proyecto. Los archivos que han sido creados para nuestro proyecto son el pom.xml y todos los contenidos en la carpeta ‘src’. Los ficheros creados por Eclipse pueden consultarse en los archivos que acompañan a la memoria.

La estructura de ficheros que se ha seguido no es casual. Es la estructura propia de un proyecto Maven, la cual hay que seguir pues es la herramienta con la que se llevará a cabo la construcción del proyecto. Hay un fichero importante que falta, éste es el MANIFEST.MF. El hecho de que no esté es que hemos configurado el archivo pom.xml para que lo genere automáticamente (ya se hablará sobre el archivo pom.xml con más detenimiento).

Dentro de la carpeta ‘main’ hay dos carpetas. Una llamada ‘java’ y otra ‘resources’. Separamos así la definición de las clases Java del resto de archivos de configuración.

Figura B.4.1 - Estructura del proyecto


116 ANEXOS

Si nos fijamos en la carpeta java, vemos que hemos dividido las clases en dos paquetes. Uno de ellos, ‘utils’, contiene todas las clases creadas para realizar operaciones que no son capaces de realizar los componentes de Camel. El otro, ‘ws’, contiene la clase en la que hemos definido nuestro servicio web. Dentro de la carpeta ‘resources’ tenemos todas las plantillas velocity almacenadas en la carpeta ‘META-INF’. Dentro de esta carpeta ‘META-INF’ tenemos además una carpeta ‘spring’ que contiene el archivo de configuración del contexto de Camel. Finalmente tenemos el fichero pom.xml, el cual se encuentra directamente en el directorio raíz del proyecto. De todos los archivos dentro de la carpeta ‘src’ ya se ha hablado en profundidad en el Capítulo 3, en el apartado 3.2. Implementación Básica. Sin embargo el archivo pom.xml no se ha siquiera mencionado. Éste es el momento de hablar de este archivo.

Project Obejct Model

Un POM es la unidad de trabajo fundamental de Maven. Se trata de un archivo XML que contiene información acerca del proyecto. Además aporta detalles de configuración usados por Maven para construir el proyecto. El POM asigna valores por defecto a algunos parámetros, como pueden ser: el directorio donde se construirá el proyecto (donde ira el .jar), que es el directorio ‘target’; el directorio fuente, que es ‘src/main’… En este fichero también se configuran los plugins y los objetivos que pueden ser ejecutados. Cuando se ejecuta un objetivo, Maven busca en el POM del directorio raíz del proyecto, lee el POM, obtiene la información de configuración para ese objetivo y ejecuta el propio objetivo. Algunas de las configuraciones que pueden ser especificadas en el POM son las dependencias del proyecto, los plugins y objetivos que pueden ser ejecutados, los perfiles de ejecución… Un POM siempre tiene un nodo raíz ‘project’. Dentro de este nodo, Maven exige que como mínimo el POM tenga los siguientes parámetros, que por lo tanto hemos tenido que configurar:

modelVersion: Debe ponerse a 4.0.0 groupId: Es el identificador del grupo del proyecto. Se ha asignado como

groupId: com.abengoa.sim artifactId: El identificador del propio proyecto. Se le asignó el identificador

sistema-movilidad-soa.


117 ANEXOS

version: La versión del proyecto dentro del grupo. La versión actual del proyecto es la 1.0

Los tres últimos parámetros configuran por completo el nombre del proyecto. El nombre tiene la siguiente forma: <groupId>:<artifactId>:<version>. Por lo tanto el nombre de nuestro proyecto sería: com.abengoa.sim:sistema-movilidad-soa:1.0. Además de este nombre, podemos asignar otro parámetro llamado ‘name’. Este nombre aparecerá en la lista de bundles cuando lo instalemos en ServiceMix. Este nombre no es importante, simplemente debe ser un nombre entendible por una persona. Se le ha dado el valor “Proyecto J.Burgers :: Sistema Movilidad SOA” a este parámetro. Otro nodo importante en el fichero es el nodo ‘packaging’. Sirve para indicarle a Maven en qué formato queremos empaquetar nuestra aplicación. Puede ser .jar, .war… En nuestro caso se ha puesto ‘bundle’ pues nuestro objetivo es generar un bundle OSGi. Hasta ahora hemos definido cómo se llama nuestro proyecto y que lo que queremos generar es un bundle OSGi. Aún queda dar más información a Maven para que pueda generar el bundle. Nos queda añadir tres nodos: ‘dependencies’, ‘build’ y ‘properties’. Veamos cada uno de ellos empezando por el nodo ‘dependencies’.

Nodo <dependencies> El nodo ‘dependencies’ contiene una serie de nodos hijos ‘dependency’ que indica las dependencias que tiene nuestro bundle con otros módulos. Tenemos que indicar por tanto el nombre completo del módulo del que depende nuestro proyecto. Los nodos ‘dependency’ tienen la siguiente estructura:

Veamos una lista de las dependencias que hemos incluido en el POM:

com.abengoa.sim.servicios:serviciodeusuarios-api:[1.0.0,) org.apache.camel:camel-core:2.4.0-fuse-00-00 org.apache.camel:camel-cxf:2.4.0-fuse-00-00 org.apache.camel:camel-stream:2.4.0-fuse-00-00 org.apache.camel:camel-velocity:2.4.0-fuse-00-00 org.apache.camel:camel-http:2.4.0-fuse-00-00

<dependency>

<groupId>?</groupId>

<artifactId>?</artifactId>

<version>?</version>

</dependency>


118 ANEXOS

org.apache.camel:camel-jetty:2.4.0-fuse-00-00 Nuestro proyecto depende por tanto de la API del Servicio de Usuarios y de una serie de módulos de Camel. Necesitamos el módulo camel-core, que es el núcleo de Camel, el cual incluye una serie de componentes como: SEDA, Direct, File, Bean… Debido a que necesitamos más componentes, hemos tenido que añadir como dependencias otros módulos que incluyen componentes no aportados por el núcleo de Camel, los cuales son: CXF, Stream, Velocuty, Http y Jetty. En cuanto a las versiones, hemos indicado que se consulte el Servicio de Usuarios desde su versión 1.0.0 en adelante. En cuanto a los módulos de Camel, hemos indicado la versión de Camel que incluye nuestro ServiceMix instalado.

Nodo <properties> El nodo ‘properties’ sirve para definir propiedades. Estas son definidas como nodos hijo del nodo ‘properties’. Se puede acceder a estas propiedades desde cualquier lugar del POM poniendo el nombre de la propiedad entre ${·}. En nuestro POM hemos definido una propiedad:

Así para hacer referencia a la propiedad escribimos ${camel.version}. La utilidad de usar propiedades radica, en este caso, en la simplicidad a la hora de cambiar la versión. Si cambiamos a una versión nueva de Camel, únicamente tendremos que variar el nodo ‘camel.version’. Nos ahorramos así tener que modificar la versión en cada una de las dependencias de Camel.

Nodo <build> El nodo ‘build’ puede contener varios elementos. Pero hemos usado únicamente tres de ellos: ‘defaultGoal’, ‘resources’ y ‘plugins’. Con ‘defaultGoal’ indicamos a Maven cuál es el objetivo por defecto. Existen distintos objetivos que corresponden a las distintas fases de la construcción del proyecto. Por ejemplo tenemos el objetivo “compile”, que se limita a compilar el código fuente; el objetivo “package” que además lleva a cabo el empaquetado del código compilado en el formato que indiquemos; o el objetivo “install” que además instala el paquete en el repositorio local. En nuestro POM hemos puesto por defecto el objetivo “install”. Hay más objetivos además de los tres mencionados22. 22

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

<properties>

<camel.version>2.4.0-fuse-00-00</camel.version>

</properties>

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html


119 ANEXOS

El nodo ‘resources’ simplemente sirve para indicar donde se encuentra los recursos que necesita Maven para crear el proyecto. En el nodo ‘plugins’ se indica una serie de plugins necesarios para crear nuestro proyecto. El más importante es el plugin org.apache.felix:maven-bundle-plugin. Se trata de un plugin necesario para poder generar el bundle OSGi. Hay tres instrucciones importantes que le damos al plugin para generar el bundle:

Export-Package: Contiene una lista de paquetes a ser exportados por nuestro bundle. Por lo que estos paquetes son incluidos en el mismo. En nuestro caso hemos puesto los paquetes relacionados con el servicio de usuarios. Por ello, aunque no forme parte de nuestro código fuente, los paquetes del servicio de usuarios han sido incluidos de esta manera en nuestro bundle y pueden ser exportados.

Import-Package: Indicamos paquetes que son necesarios para nuestro bundle. Esos paquetes no son incluidos en nuestro bundle, sino que deben ser exportados por otros bundles dentro de ServiceMix para que el nuestro pueda hacer uso de ellos.

Private-Package: Similar a Export-Package. Salvo que los paquetes, aunque incluidos en nuestro bundle, no son exportados. Hemos incluido aquí todos los paquetes que empiezan por com.abengoa.sim. Los del servicio de usuarios también comienzan de esta forma, pero si hay paquetes incluidos como Export y Private son considerados como Export.

Con esto queda visto cómo está estructurado el proyecto, y cómo el Project Object Model sirve de ayuda a Maven para conocerlo. El siguiente paso será la construcción del bundle, para posteriormente instalarlo en ServiceMix.

4.1.2. GENERACIÓN DEL BUNDLE

Una vez que tenemos todo nuestro código bien estructurado como proyecto Maven en el espacio de trabajo de Eclipse ya podemos compilarlo y empaquetar el bundle. Para construir el proyecto hay que instalar Maven en nuestro ordenador, para ello simplemente hay que descargar la distribución binaria23 y descomprimirla en la carpeta deseada. Podríamos usar la consola de comandos para realizar las compilaciones, sin embargo se instaló un plugin de Maven24 para Eclipse para de esta forma tenerlo todo recogido en el entorno de desarrollo y de esta manera agilizar el proceso de desarrollo de la aplicación. Además de permitir realizar la compilación del proyecto directamente desde Eclipse, este plugin permite crear proyectos Maven desde cero o a partir de 23

http://maven.apache.org/download.html 24

http://m2eclipse.sonatype.org/

http://maven.apache.org/download.html

http://m2eclipse.sonatype.org/


120 ANEXOS

ciertos arquetipos. En el caso del presente proyecto se creó desde cero, pero existe un arquetipo de bundle OSGi que puede ser usado para empezar de forma más rápida. Se realizará la construcción del proyecto indicando que nuestro objetivo es ‘install’. De esta forma tras la compilación del código y su empaquetamiento como bundle, éste será instalado en el repositorio local que creamos al instalar Maven. Con el bundle en el repositorio local de Maven, sólo queda instalarlo en ServiceMix e iniciarlo.

4.1.3. INSTALACIÓN DEL BUNDLE EN SERVICEMIX

Antes de nada habrá que instalar Apache ServiceMix. Para ello, al igual que con Apache Maven, únicamente hay que descargar la distribución binaria proporcionada por FuseSource25 y descomprimirla en la ruta deseada. Arrancamos ServiceMix desde la consola de comandos y vemos algo como lo mostrado en la Figura B.4.2. Antes de instalar nuestro bundle hay que recordar que éste dependía de otros como camel-core, camel-http… Habrá por tanto que asegurar que estos bundles estén instalados antes de instalar el nuestro. Si ejecutamos el comando ‘list’ se nos muestra un listado con los bundles instalados además del estado en el que se encuentran (arrancado, parado…). Gracias a este comando podemos ver como ServiceMix viene con el bundle camel-core instalado por defecto, aun así tendremos que instalar el resto.

Figura B.4.2 - Consola: ServiceMix

El comando ‘osgi:install’ nos permite instalar un bundle. Sin embargo, no usaremos esta instrucción para instalar los bundles de los que depende nuestro proyecto. No lo haremos porque los bundles que queremos instalar dependen a su vez de otros, que también deberíamos instalar, lo que daría lugar a una tarea bastante tediosa. Por suerte, ServiceMix proporciona otro comando: ‘features:install’. Este comando permite instalar un cierto número de bundles con sus dependencias. Entre los bundles que podemos instalar están los que necesitamos: camel-stream, camel-cxf, 25

http://fusesource.com/products/enterprise-servicemix/

http://fusesource.com/products/enterprise-servicemix/


121 ANEXOS

camel-http, camel-jetty y camel-velocity. Cuando hayamos instalado todos estos bundles ya podremos instalar el nuestro. Para instalar nuestro bundle usamos el comando ‘osgi:install’, al cual le pasamos la ruta en la que se encuentra nuestro bundle. Ya tenemos así nuestro bundle instalado en ServiceMix. Para arrancarlo y que los endpoint Jetty y CXF se pongan a la espera de mensajes usamos el comando ‘start’ indicando el ID que se le asignó al bundle cuando fue instalado.

4.2. EJEMPLO DE EJECUCIÓN Teniendo ya arrancado ServiceMix y nuestro bundle en ejecución tenemos todo listo para ver un ejemplo de ejecución. Para tener un proceso de BizAgi con el que hacer pruebas, primero tendremos que crearlo usando la aplicación web de BizAgi de desarrollo. Una vez creado el proceso probaremos a movilizarlo. Aunque sería fácil hacerlo, no vamos a tocar la aplicación de BizAgi en desarrollo para que apunte a nuestro servicio web para no molestar a los empleados que están trabajando con esta aplicación. En lugar de ello usaremos la herramienta SoapUI para mandar nosotros la petición al servicio web. Una vez hecha la petición, el mensaje deberá llegar a nuestra BlackBerry. Cuando llegue probaremos a rellenar el formulario y darle a procesar. Y deberíamos ver en la aplicación BizAgi que todo fue correctamente. Finalmente probaremos a crear un proceso desde la BlackBerry.

4.2.1. CREACIÓN DEL PROCESO DESDE LA APLICACIÓN WEB

Accederemos desde nuestro PC a través del navegador web a la aplicación BizAgi de desarrollo, con el usuario LDAP y la contraseña. Ya dentro de la aplicación en la pestaña ‘Procesos’ seleccionamos ‘Nuevo Proceso’. Nos sale un desplegable con las distintas sociedades de la empresa. Elegimos una y nos sale un menú como el de la Figura B.4.3. Elegimos por ejemplo el proceso ‘PRL110 Entrada a un espacio confinado’. Una vez creado, tenemos una pantalla con el formulario como se puede ver en la Figura B.4.4. Podemos ver el identificador del proceso, idProceso, así como el identificador de la primera actividad del mismo, idActividad. En este caso la primera actividad es la cumplimentación del formulario.


122 ANEXOS

Figura B.4.3 - Desplegable de procesos


123 ANEXOS

Figura B.4.4 - Ejemplo de formulario


124 ANEXOS

En el caso de este formulario tenemos el idActividad y el idProceso, 788311 y 78732 respectivamente. El proceso es el que acabamos de crear y la actividad es ‘Cumplimentar el formulario’. La sociedad de la cual hemos creado el proceso es la C10. Esta información nos hará falta cuando hagamos la petición a nuestro servicio web.

Si pinchamos en la pestaña de ‘Procesos pendientes’ vemos que tenemos nuestro proceso en el estado ‘Cumplimentar Formulario’, es decir, está esperando a que el formulario sea rellenado. Esto se puede ver en la Figura B.4.5.

Figura B.4.5- Procesos pendientes: tras crear proceso

Ya tenemos el proceso creado, ahora habrá que movilizar la actividad ‘Cumplimentar Formulario’

4.2.2. PRIMERA MOVILIZACIÓN

Una vez visto todo esto, vamos a pasar a mandar la petición de movilización de actividad a nuestro servicio web. Como ya se comentó, usaremos para ello SoapUI. Importamos el WSDL en SoapUI, elegimos el método movilizarActividad, rellenamos los parámetros de la petición y mandamos la petición. En la Figura B.4.6 vemos una captura justo en el momento antes de mandar la petición.

Figura B.4.6 - Petición por SoapUI


125 ANEXOS

Una vez que demos a enviar, aparecerán una serie de logs en Servicemix y llegará nuestro mensaje a la BlackBerry. Esto puede verse en las siguientes capturas.

Figura B.4.7 - ServiceMix: primera movilización

Vemos que todo ha ido bien. Primero se recibió la petición de movilización. Luego recibimos los mensajes del BES indicando que se recibió la petición de envío y que se realizó el mismo. Finalmente se ve que hemos recibido un asentimiento de la BlackBerry, por lo que debe haber recibido correctamente el mensaje. Entramos en la aplicación SIM de nuestra BlackBerry y vamos al módulo de BizAgi para ver las actividades. Veremos cómo efectivamente está ahí nuestra actividad (Figura B.4.8 a Figura B.4.10).

Figura B.4.8 - Comprobación actividades en BlackBerry [1]


126 ANEXOS



4.2.3. CUMPLIMENTAR EL FORMULARIO Y TRAMITAR

Vemos que funciona en el sentido BizAgi – BlackBerry. Para comprobar si funciona también en el sentido BlackBerry – BizAgi rellenaremos el formulario y le daremos a procesar. Veremos los mensajes que se imprimen en el log de ServiceMix, comprobaremos la respuesta que se ha dado a la BlackBerry y accederemos a la aplicación web de BizAgi para ver los cambios. En primer lugar se rellena el formulario y se procesa tal como se ve de la Figura B.4.11 a la Figura B.4.13.


127 ANEXOS

Figura B.4.11 - Cumplimentando formulario [1]




128 ANEXOS

Una vez procesado saltan una serie de mensajes en el log de Servicemix (Figura B.4.14). El primero nos indica que efectivamente se ha recibido un mensaje de la BlackBerry relacionado con BizAgi. Los otros dos son de nuevo respuestas del BES, en la que nos dice que nuestro mensaje a la BlackBerry (en el que indicamos que ha ido bien la tramitación) se ha enviado correctamente.

Figura B.4.14 - ServiceMix: Primera tramitación

En cuanto a la BlackBerry, el icono de la actividad pasará por dos estados. En el primero de ellos tendremos un mensaje con una flecha verde que indica que se ha enviado el formulario cumplimentado. La aplicación SIM pone este icono una vez que recibe por parte del endpoint Jetty el 200 OK. Una vez que la BlackBerry recibe el mensaje de confirmación de la tramitación ya le asigna el .

Figura B.4.15 - Fases estado tramitación [1]


129 ANEXOS



Vemos finalmente la pestaña de procesos pendientes de la aplicación BizAgi en la Figura B.4.18.

Figura B.4.18 - Procesos pendientes: Tras tramitar primera actividad


130 ANEXOS

Todo ha ido correctamente. El estado ha pasado de ‘Cumplimentar Formulario’ a ‘Pendiente Conformidad Recurso Preventivo’. Ahora se ha creado una nueva actividad en el proceso, esta actividad consiste en rellenar otro formulario para dar conformidad a la POC.

4.2.4. CREACIÓN DE UN PROCESO DESDE LA BLACKBERRY

Finalmente probaremos a crear un proceso desde la BlackBerry, para ello elegimos el módulo de BizAgi en la aplicación SIM y marcamos ‘Nuevo proceso’.


131 ANEXOS

Una vez hecho esto elegimos la sociedad de la cual queremos generar el proceso, y seleccionamos el proceso correspondiente.


132 ANEXOS

Una vez elegido, pulsamos ‘Iniciar proceso’. Si todo va correctamente deberíamos recibir el formulario correspondiente a la actividad ‘Cumplimentar Formulario’ del proceso ‘PRL01 Ferroviaria’. Si vamos atrás y entramos en ‘Mis actividades’ veremos que tenemos ya movilizada la actividad.


133 ANEXOS

Podemos también acceder a la aplicación web de BizAgi y veríamos como efectivamente aparecerá el proceso creado como proceso pendiente (Figura B.4.20). En la Figura B.4.19 podemos ver el LOG de ServiceMix. Se observa cómo se recibió el mensaje de la BlackBerry, luego llegan confirmaciones del BES. Estas confirmaciones son las correspondientes al push que se envía con el formulario del nuevo proceso creado. Finalmente llega el asentimiento que manda la BlackBerry al recibir el formulario.

Figura B.4.19 - ServiceMix: Inicio proceso desde BlackBerry

Figura B.4.20 - Procesos pendientes: tras crear proceso desde BlackBerry

ANÁLISIS Y PRUEBA DE CONCEPTO PARA LA ADOPCIÓN DE SOA...

Documents

Transcript of ANÁLISIS Y PRUEBA DE CONCEPTO PARA LA ADOPCIÓN DE SOA...