DESARROLLO DE UN LABORATORIO VIRTUAL PARA EL APRENDIZAJE DE MODELOS DE PROCESOS DE NEGOCIO

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS

I

T

UNIVERSIDAD DE CANTABRIA

Trabajo Fin de Grado

DESARROLLO DE UN LABORATORIO VIRTUAL PARA

EL APRENDIZAJE DE MODELOS DE PROCESOS DE

NEGOCIO

(Virtual laboratory development for the learning of

Business Process Models)

Para acceder al Título de

Graduado en

Ingeniería de Tecnologías de Telecomunicación

Autor: Claudia González Oliva

E.T.S. DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACION

G

I

T

T

CALIFICACIÓN DEL TRABAJO FIN DE GRADO

Realizado por: Claudia González Oliva

Director del TFG: Alberto Eloy García Gutiérrez

Título: “Desarrollo de un laboratorio virtual para el aprendizaje de

modelos de procesos de negocio.”

Title: “Virtual laboratory development for the learning of Business

Process Models”

Presentado a examen el día: 25 de Octubre de 2018

para acceder al Título de

G

I

T

T

Composición del Tribunal:

Presidente (Apellidos, Nombre): Sanz Gil, Roberto

Secretario (Apellidos, Nombre): García Gutiérrez, Alberto Eloy

Vocal (Apellidos, Nombre): Irastorza Teja, José Ángel

Este Tribunal ha resuelto otorgar la calificación de: ...

Fdo.: El Presidente

Fdo.: El Secretario

Fdo.: El Vocal

Fdo.: El Director del TFG

(sólo si es distinto del Secretario)

Vº Bº del Subdirector

Trabajo Fin de Grado Nº

3

Resumen

La importancia en el mundo empresarial relacionado con las TIC del uso de modelos normalizados para la gestión de servicios y de la propia empresa, hace que las herramientas BPM sean cada vez más importantes. Es por ello que el principal objetivo de este TFG es el de proponer un laboratorio virtual que permita definir prácticas en las que los alumnos puedan ver en primera persona cómo funciona un sistema BPMN (Business Process Model and Notation), y lo que es más importante, cómo se definen servicios de telecomunicaciones en base a la notación BPEL (Business Process Execution Language).

Inicialmente se parte de la necesidad de establecer una máquina virtual, sobre la que se instalará todo el software que sea necesario para poder tener un entorno virtual de diseño de servicios completamente operativo (al menos desde el punto de vista teórico). Una vez en funcionamiento, se analiza un ejemplo que integra diferentes opciones para su explotación dentro de una clase práctica de laboratorio.

4

Abstract

The relevance in the IT related business world of the use of normalized models for service management and business management makes BPM (Business Process Management) tools increasingly important. That is the reason why the main goal of this project is to propose a virtual laboratory that provides the environment to propose activities for students to see first-hand how a BPMN (Business Process Model and Notation) system works, and more importantly, how telecommunication services can be defined based on the BPEL (Business Process Execution Language) notation.

Initially, there is the need to establish a virtual machine, on which all the necessary software to have a fully functional virtual environment will be installed. Once operational, different options will be analyzed to use as laboratory activities.

5

Índice

2.1 BPM Business Process Management ... 12

2.2 WS-BPEL Web Services Business Process Execution Language... 13

2.2.1 Estructura básica del lenguaje ... 14

2.2.1.1 PartnerLinks ... 15

2.2.1.2 Variables... 15

2.2.1.3 FaultHandlers ... 15

2.2.1.4 Process ... 16

2.3 WSDL Web Services Description Language ... 17

2.4 BPMN Business Process Model and Notation ... 19

3. Aspectos prácticos ... 20 3.1 Laboratorio virtual ... 20 3.1.1 Máquina virtual ... 20 3.1.2 Oracle VM VirtualBox ... 21 3.2 OpenJDK ... 21 3.2.1 Synaptic ... 22 3.3 Apache Tomcat ... 22 3.4 Apache ODE ... 23 3.5 Eclipse... 25

3.5.1 Eclipse IDE Oxygen ... 25

3.5.2 BPEL Designer ... 25

4. Desarrollo ... 26

4.1 Instalación ... 26

4.1.1 Creación de máquina virtual... 26

4.1.2 OpenJDK ... 29

4.1.3 Apache ... 30

4.1.4 Eclipse IDE ... 33

6

4.2.1 Proyecto “codigo” ... 43

4.2.2 Proyecto “localizacion” ... 48

4.2.3 Proyecto “ventas” ... 49

5. Conclusiones y líneas de desarrollo futuro... 64

6. Bibliografía ... 66 7. Anexos ... 67 7.1 “codigo” ... 67 7.1.1 BPEL ... 67 7.1.2 WSDL ... 70 7.1.3 Deploy ... 72 7.2 “localizacion” ... 72 7.2.1 BPEL ... 72 7.2.2 WSDL ... 74 7.2.3 Deploy ... 76 7.3 “ventas” ... 76 7.3.1 BPEL ... 76 7.3.2 WSDL ... 80 7.3.3 Deploy ... 82 7.4 context.xml ... 82 7.5 server.xml ... 83

7

Índice de figuras

Figura 1: Elementos instalados ... 20

Figura 2: Esquema Apache ODE ... 24

Figura 3: Esquema de instalación ... 26

Figura 4: Creación de VM. Nombre y sistema operativo ... 27

Figura 5: Creación de VM. Tamaño de memoria ... 27

Figura 6: Creación de VM. Ubicación del archivo ... 27

Figura 7: Creación de VM. Vista de administrador ... 28

Figura 8: Configuración de VM. Selección de disco de inicio... 28

Figura 9: Configuración de VM. Tipo de instalación ... 29

Figura 10: Configuración de VM. Cuenta de superusuario ... 29

Figura 11: Instalación OpenJDK 8 ... 30

Figura 12: Comprobación de la versión de Java ... 30

Figura 13: Localización de ODE en webapps dentro de Tomcat ... 32

Figura 14: Apache Tomcat funcionando ... 33

Figura 15: Apache Tomcat apagado ... 33

Figura 16: Instalación Eclipse IDE. Certificado Eclipse ... 34

Figura 17: Eclipse IDE. Localización archivos de proyecto ... 34

Figura 18: Eclipse IDE. Instalación BPEL Designer ... 35

Figura 19: Eclipse IDE. Nuevo BPEL 2.0 ... 35

Figura 20: Eclipse IDE. Creación de servidor localhost. ... 36

Figura 21: Eclipse IDE. Configuración de classpath en el servidor ... 36

Figura 22: Eclipse IDE. Pestaña de servidor ... 37

Figura 23: Eclipse IDE. Servidor “localhost” funcionando ... 37

Figura 24: Práctica. Estructura proceso ... 39

Figura 25: Práctica. Proyecto “codigo”. Creación BPEL Project ... 40

Figura 26: Práctica. Proyecto “codigo”. Creación BPEL Process File ... 41

Figura 27: Práctica. Proyecto "codigo". Plantilla BPEL ... 42

Figura 28: Práctica. Proyecto "codigo". Archivos creados ... 42

Figura 29: Práctica. Proyecto "codigo". Barra lateral de actividades. ... 42

Figura 30: Práctica. Proyecto "codigo". codigoArtifacts.wsdl ... 43

Figura 31: Práctica. Proyecto "codigo". Datos de entrada ... 43

Figura 32: Práctica. Proyecto "codigo". Vista de diseño ... 44

Figura 33: Práctica. Proyecto "codigo". Configuración actividad receive ... 44

Figura 34: Práctica. Proyecto "codigo". Configuración actividad reply ... 44

Figura 35: Práctica. Proyecto "codigo". Assign Fixed Value to Variable ... 45

Figura 36: Práctica. Proyecto "codigo". Inicialización variable de output ... 45

Figura 37: Práctica. Proyecto "codigo". Detalles de binding ... 45

Figura 38: Práctica. Proyecto "codigo". Configuración de puerto ... 46

Figura 39: Práctica. Proyecto "codigo". deploy.xml ... 46

Figura 40: Práctica. Proyecto "codigo". Añadir proyecto al servidor localhost ... 47

Figura 41: Práctica. Proyecto "codigo". Comprobación correcta ... 47

Figura 42: Práctica. Proyecto "localizacion". Vista de diseño ... 48

Figura 43: Práctica. Proyecto "localizacion". Assign Fixed Value to Variable ... 48

Figura 44: Práctica. Proyecto "localizacion". Configuración de puerto ... 49

Figura 45: Práctica. Proyecto "localizacion". Comprobación correcta ... 49

Figura 46: Práctica. Proyecto "ventas". Plantilla BPEL ... 50

Figura 47: Práctica. Proyecto "ventas". Datos de entrada ... 50

Figura 48: Práctica. Proyecto "ventas". Data como estructura de input ... 51

8

Figura 50: Práctica. Proyecto "ventas". Archivos ... 52

Figura 51: Práctica. Proyecto "ventas". Invoke ... 52

Figura 52: Práctica. Proyecto "ventas". Partner Link Type ... 52

Figura 53: Práctica. Proyecto "ventas". Rol de Partner Link Type ... 53

Figura 54: Práctica. Proyecto "ventas". Detalles Invoke ... 53

Figura 55: Práctica. Proyecto "ventas". Detalles Invoke1 ... 53

Figura 56: Práctica. Proyecto "ventas". Opciones de configuración de nueva variable ... 54

Figura 57: Práctica. Proyecto "ventas". Variables añadidas ... 54

Figura 58: Práctica. Proyecto "ventas". Configuración actividad reply ... 55

Figura 59: Práctica. Proyecto "ventas". Configuración “Assign”. Inicialización de variable ... 55

Figura 60: Práctica. Proyecto "ventas". Configuración “Assign”. Variable “codigo” ... 55

Figura 61: Práctica. Proyecto "ventas". Configuración “Assign”. Variable “unidades” ... 55

Figura 62: Práctica. Proyecto "ventas". Configuración “Assign1”. Variable “resultadocodigo” 56 Figura 63: Práctica. Proyecto "ventas". Configuración “Assign2”. Inicialización de variable ... 56

Figura 64: Práctica. Proyecto "ventas". Configuración “Assign2”. No hay unidades ... 56

Figura 65: Práctica. Proyecto "ventas". Configuración “Assign3”. No existe tal código ... 56

Figura 66: Práctica. Proyecto "ventas". Configuración “Assign4”. Inicialización de variable. .. 57

Figura 67: Práctica. Proyecto "ventas". Configuración “Assign4”. Hay unidades ... 57

Figura 68: Práctica. Proyecto "ventas". Configuración “Assign4”. Variable “localizacion” ... 57

Figura 69: Práctica. Proyecto "ventas". Configuración “Assign5”. Variable “resultadolocalizacion” ... 57

Figura 70: Práctica. Proyecto "ventas". Configuración “Assign5”. Variable de salida ... 57

Figura 71: Práctica. Proyecto "ventas". Detalles de binding ... 58

Figura 72: Práctica. Proyecto "ventas". Configuración de puerto ... 58

Figura 73: Práctica. Proyecto "ventas". ventasArtifacts.wsdl ... 58

Figura 74: Práctica. Proyecto "ventas". deploy.xml ... 59

Figura 75: Práctica. Proyecto "ventas". SOAP Request y SOAP Response ... 59

Figura 76: Práctica. Proyecto "ventas". Comprobación localización ES. ... 60

Figura 77: Práctica. Proyecto "ventas". Comprobación "No hay unidades". ... 61

Figura 78: Práctica. Proyecto "ventas". Comprobación "No existe tal código" ... 61

Figura 79: Práctica. Proyecto "ventas". Comprobación localización EU. ... 62

Figura 80: Práctica. Proyecto "ventas". Comprobación "Lugar no determinado" ... 62

9

Acrónimos

BPEL: Business Process Execution Language

BPM: Business Process Management

BPML: Business Process Modeling Language

BPMN: Business Process Model and Notation

BPMS: Business Process Management Software

FOSS: Free Open Source Software

IBM: International Business Machines Corporation

IDE: Integrated Development Environment

JaCOb: Java Concurrent Objects

JDK: Java Development Kit

JNDI: Java Naming and Directory Interface

OASIS: Organization for the Advancement of Structured Information Standards

ODE: Orchestration Director Engine

OMG: Object Management Group

SOAP: Simple Object Access Protocol

TIC: Tecnologías de la Información y la Comunicación

UDDI: Universal Description, Discovery and Integration

URI: Uniform Resource Identifier

VM: Virtual Machine

WAR: Web Application Archive

WS-BPEL: Web Services Business Process Execution Language (BPEL)

WSDL: Web Services Description Language

WSFL: Web Services Flow Language

XML: Extensible Markup Language

XPath: XML Path Language

10

1. Introducción.

La relevancia en el ámbito profesional del uso de modelos y herramientas normalizadas para la gestión de servicios, especialmente en el mundo de las TIC, hace que sea de gran relevancia para un futuro Graduado, adquirir conocimientos relacionados con este tema, ya que las capacidades requeridas más demandadas dentro del mundo laboral de las TIC, pasan por competencias directamente relacionadas con la Gestión de los Servicios de Telecomunicación.

Precisamente, el Grado en Tecnologías de Ingeniería de Telecomunicación de la Universidad de Cantabria, cuenta con una asignatura optativa de la mención de Telemática denominada “Gestión de Servicios de Telecomunicación”. En esta materia se acerca a los alumnos a la gestión de servicios y , entre otras cosas diversas, se tratan modelos de gestión empresarial, se analizan y valoran las características que deben tener los Acuerdos de Nivel de Servicio y se centra el punto de vista en la empresa en temas como la regulación, distintos estándares y la normativa vigente.

También, desde el punto de vista más práctico, se trata el concepto de proceso, según el cual la vida de un servicio puede ser representada como un diagrama de flujo, con unas entradas, una lógica interna y una respuesta de salida. El típico ejemplo que se ve durante las clases es el de la fase de resolución de problemas en un departamento de atención al cliente, en la cual es necesario dar una respuesta satisfactoria al cliente, basándose en los datos de entrada.

De esta forma, la gestión de procesos, denominada BPM (Business Process Management), se convierte en un tema muy interesante, ya que permite aplicar de forma práctica toda la teoría de la Gestión en general, y conocer herramientas útiles que además, permiten facilitar el aprendizaje de los conceptos tratados en clase. Así, por ejemplo, los problemas de los centros de atención al cliente pueden ser modelado mediante un diagrama propuesto en papel, que puede ser simulado en una práctica de laboratorio, de forma que, el propio alumno pueda diseñar sus propios procesos y probar su correcto funcionamiento.

1.1 Objetivo

El principal objetivo de este trabajo es crear un laboratorio virtual en el que sea posible desarrollar el aprendizaje de BPM (Business Process Management) mediante el uso de la notación BPEL (Business Process Execution Language). La actual importancia de los modelos normalizados de gestión, como es el caso de ETOM, TMN o ITIL, centrados en las empresas relacionadas con las TIC (Tecnologías de la Información y la Comunicación), es el motivo por el que conocer dichas herramientas resulta especialmente útil para los alumnos.

Las actuales herramientas utilizadas por las empresas TIC son, en muchos casos, grandes suites informáticas, no solo complejas de manejar, sino tediosas de instalar y casi siempre muy caras. A efectos docentes, existen herramientas opensource que permiten replicar

11

gran parte de las funcionalidades de las herramientas profesionales, aunque al constar de elementos independientes, resulta bastante compleja su instalación. Este trabajo propone la creación de un entorno de desarrollo de BPM, sobre una máquina virtual que incluya todo el software necesario para crear y ejecutar aplicaciones de gestión de procesos. La máquina virtual debe ser compatible con las infraestructuras de los Laboratorios Docentes, para que así pueda ser migrada de la forma más simple posible a todos los ordenadores en los que los alumnos finalmente desarrollaran sus propios diseños.

1.2 Estructura

Este trabajo está dividido en 5 capítulos, de los cuales, además de este primero de introducción, el capítulo 2 describe los conceptos teóricos de BPM y los aspectos claves de los estándares WS-BPEL y WSDL, que son los dos lenguajes que se utilizan en el trabajo, así como la relación entre BPMN y BPEL y los motivos por los que se hace uso del estándar WS-BPEL. Seguidamente, en el capítulo 3 se describe todo el software necesario para implementación del entono de desarrollo propuesto, para ya en el capítulo 4 pasar a describir todo el proceso de creación de la máquina virtual, la instalación del software indicado anteriormente y el desarrollo de un ejemplo de uso, en forma de aplicación práctica de diferentes opciones del estándar WS-BPEL. Por último, en el capítulo 5 se presentan las conclusiones más importantes que se han obtenido durante el desarrollo de este trabajo y se plantean posibles líneas de desarrollo a realizar en trabajos futuros.

12

2. Conceptos teóricos

En este capítulo se trata la definición de BPM y sus características, se presentan aspectos claves del estándar WS-BPEL, se comentan los seis elementos que forman los servicios del documento WSDL se relaciona el estándar BPMN con BPEL y se justifica el uso de este último.

2.1 BPM Business Process Management

La definición oficial presentada por BPM.com [1] de la Gestión de Procesos de Negocio es:

“Business Process Management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.”

La traducción de esta definición puede presentarse como:

“La Gestión de Procesos de Negocio es una disciplina que involucra cualquier combinación de modelado, automatización, ejecución, control, medida y optimización de flujos de actividades de negocio, a favor de los objetivos de la empresa, abarcando sistemas, empleados, clientes y socios, dentro y más allá de los límites de la empresa.”

Según esta definición, la Gestión de Procesos de Negocio no es un producto, sino un conjunto de prácticas para definir, especificar y administrar los procesos de la empresa. Una empresa que aplique este modelo de gestión debe considerar los procesos como una serie de actividades de negocio que cooperan para llegar al objetivo marcado por la empresa, lo que se diferencia de la optimización local, en la que cada rama de la empresa evoluciona de forma independientemente.

Desde un punto de vista práctico, la Gestión de Procesos de Negocio cuenta con las siguientes funciones:

 Modelado: Se identifica, se define y se crea una representación del proceso completo para apoyar la comunicación.

 Automatización: Se refiere al trabajo que se realiza anteriormente para asegurar la correcta ejecución de los procesos.

 Ejecución: Se ponen en marcha diferentes instancias del proceso.

 Control: Se segura el curso correcto del proceso, por ejemplo, con entrenamiento y guías.

 Medida: Se determina la calidad del proceso con respecto a su finalidad de servir a su función.

 Optimización: el BPM es una actividad continua para mejorar los procesos. La mejora es relativa a los objetivos de la organización.

Además, es fundamental la última referencia en la que la empresa forma parte de un gran sistema en el que los clientes son parte del proceso y su interacción debe tenerse en cuenta.

13

Un argumento a favor de implementar este modelo es que, a diferencia de otros enfoques previos, trata de forma conjunta los procesos, la tecnología y los recursos humanos, facilitando la comunicación entre las distintas ramas de la empresa, tecnología y negocio. Un cuidadoso seguimiento de los procesos además facilita el cambio cuando sea necesario, en caso de que cambie la tecnología óptima o la actividad evolucione.

Al conjunto de herramientas que otorgan un soporte para aplicar BPM se las denomina Software de Gestión de Procesos de Negocio, BPMS (Business Process Management Software).

Existen múltiples herramientas que dan soporte para BPM, una de ellas es la que se utiliza en el proyecto, Eclipse IDE con la extensión BPEL Designer, pero también son destacables diversos recursos BPM de Oracle como “Oracle SOA Suite” y “Oracle BPM Suite” o recursos abiertos como los de la plataforma abierta “OpenESB”.

En este trabajo se decide utilizar la plataforma Eclipse IDE porque permite utilizar el lenguaje BPEL y además cuenta con múltiples extensiones para poder añadir más características.

2.2 WS-BPEL Web Services Business Process Execution Language

Su historia comienza con la lucha entre IBM y Microsoft en 2001 por hacerse con el lenguaje para grandes programas, WSFL y Xlang, respectivamente. Después, con la popularidad de BPML, tanto IBM como Microsoft, decidieron unir fuerzas y formar un nuevo lenguaje, BPEL4WS. Dos años más tarde, en 2003, junto con BEA Systems, SAP y Siebel Systems presentaron BPEL4WS 1.1 a OASIS para ser estandarizado y en Septiembre de 2004 se llamó a la especificación “WS-BPEL 2.0”.

Basado en XML, se trata de un lenguaje de orquestación que controla de forma centralizada la invocación de servicios web y permite, a través de su documento representar la lógica del sistema y los elementos que forman parte de él.

El objetivo de los servicios web es tener interoperabilidad entre diferentes aplicaciones utilizando para ello estándares web. Las especificaciones que definen dichos servicios son:

 SOAP (Simple Object Access Protocol): Define un protocolo de mensajes XML (Extensible Markup Language).

 WSDL (Web Services Description Language): Introduce una gramática común para la descripción de servicios.

 UDDI (Universal Description, Discovery and Integration): Aporta la infraestructura necesaria para publicar y descubrir servicios de forma sistemática. Estas tres especificaciones permiten interactuar a las distintas aplicaciones siguiendo un modelo independiente de la plataforma.

14

Los procesos de negocio pueden describirse como ejecutables o abstractos.

 Abstractos: Un proceso abstracto es parcialmente especificado y no está destinado a ser ejecutado, ya que puede omitir partes necesarias para su correcto funcionamiento. Los procesos abstractos tienen una función descriptiva. Una opción de los procesos abstractos es describir el comportamiento observable de los servicios ofrecidos por un proceso ejecutable. Otra opción es definir una plantilla que representase la lógica esencial del proceso.

 Ejecutables: Un proceso ejecutable debe ser especificado totalmente y se define un formato ejecutable que se apoya únicamente en los recursos de servicios web y datos XML.

La continuidad entre los procesos abstractos y ejecutables hacen posible que se puedan reutilizar plantillas manteniendo su función. Es una de las claves para el uso de WS-BPEL ya que permite desarrollar herramientas que sirven para reducir el coste. Así, por ejemplo, todos los supuestos de procesos que se desarrollan a lo largo de este trabajo son ejecutables.

De acuerdo con las especificaciones anteriores, WS-BPEL define un modelo y una gramática que sirve para describir el comportamiento de un proceso de negocio basado en las interacciones entre el proceso y sus socios. La interacción entre ellos ocurre a través de servicios web y la estructura de la relación a nivel de la interfaz se resume en lo que se denomina <partnerLink>. El proceso WS-BPEL define cómo múltiples interacciones con los socios se coordinan para alcanzar un objetivo, al igual que el estado y la lógica necesaria para coordinarlo. También se introducen mecanismos para lidiar con excepciones y errores de procesamiento.

WS-BPEL utiliza varias especificaciones XML:

 WSDL 1.1 y XML Schema 1.0 aportan el modelo de datos que utilizan los procesos WS-BPEL,

 XPath 1.0 y XSLT 1.0 aportan apoyo para la manipulación de datos.

Hay que tener en cuenta que todos los recursos externos se representan como servicios WSD, y que el uso de estas especificaciones por parte de WS-BPEL hace que sea totalmente adaptable a versiones futuras de dichos estándares.

La definición del proceso en WS-BPEL hace uso de uno o más servicios WSDL y aporta la descripción del comportamiento y las interacciones de la instancia relacionada con los socios y los recursos a través de interfaces de servicios web. Sigue el modelo WSDL en la separación entre el contenido del mensaje y la información de ejecución, por lo que WS-BPEL se encarga de los mensajes, mientras que WSDL se encarga de los protocolos de comunicación utilizados.

2.2.1 Estructura básica del lenguaje

Hay cuatro objetos fundamentales sobre los que se define el proceso: los agentes implicados, las variables asociadas, los manejadores de errores y el proceso en sí, A continuación, se describen las principales características de los mismos.

15

2.2.1.1 PartnerLinks

<partnerLinks> es el identificador mediante el cual se define a los diferentes

agentes/socios que interaccionan con el proceso. Cada <partnerLink> está caracterizado por un <partnerLinkType> y uno o dos roles.

Un <partnerLinkType> caracteriza la relación entre dos servicios, definiendo los roles y especificando el “portType” de cada servicio para recibir mensajes en la conversación. Cada rol concuerda con un “portType”. Se define también <partnerLinkType> como un tipo de definición incluida en el elemento <wsdl:definitions>.

Hay una diferencia importante en WSDL entre “portType” y puerto. “portType” define una funcionalidad abstracta, mientras que puerto se refiere a información de acceso, incluyendo los extremos de la comunicación “endpoints”. Los “bindings” son la unión entre ellos. La referencia a un “endpoint” hace posible seleccionar un proveedor para un tipo de servicio en particular y poder invocar sus operaciones.

Más de un <partnerLink> se puede caracterizar con el mismo <partnerLinkType> cuando hay varios socios diferentes, pero tienen el mismo rol. Cada <partnerLink> tiene un nombre diferente bajo el atributo “name”. El papel del proceso se indica mediante el atributo “myRole” y el del socio en el atributo “partnerRole”. En caso de que solo haya un rol, uno de los atributos se omite.

2.2.1.2 Variables

Bajo el calificativo de <variables>: se definen todos los valores usados por el proceso, a través de sus definiciones WSDL o XML. En principio, las variables van a contener todos los mensajes que normalmente se reciben, por lo que mantienen el estado del proceso y desde los cuales dichos estados pueden ser enviados.

WS-BPEL utiliza tres tipos de declaración de variables: “WSDL message type”, “XML Schema type (simple o complejo)” y “XML Schema element”. Para identificar de qué tipo es una variable se hace uso de los atributos: “message type”, “type”, “element”. Cada variable se declara en un <scope> y pertenece a ese rango, pudiendo estar definida como global o local, pero siempre y cuando su nombre sea único entre todas las variables del mismo rango y no contenenga el carácter “.”, que interfiere con XPath 1.0.

Su comportamiento también resulta especial, ya que si durante la ejecución del proceso se lee una variable antes de ser inicializada, se genera el fallo “uninitializedVariable”. Por tanto, las variables deben ser inicializadas a priori, y una vez inicializadas, pueden ser modificadas mediante lo que se denomina “actividades”. Así, por ejemplo, la actividad <assign> se utiliza para copiar e insertar datos en una variable. Para ello, la actividad copia un valor desde el origen “from-spec” al destino “to-spec” utilizando el elemento <copy>. Este valor puede ser variable, partnerLink, property, expresión, literal o empty. Para que la operación <copy> sea válida, el valor de origen y destino deben ser de tipos compatibles.

16

El control y manejo de errores recibe el nombre de <faultHandlers>: que es el objeto en el que se contienen los controladores de errores, y define las actividades que deben realizarse como respuesta a fallos.

2.2.1.4 Process

El objeto contenedor por excelencia es <process>, que es el que realmente describe del comportamiento normal asociado con el proceso. A su vez, el objeto proceso está caracterizado por atributos y actividades, organizados en diferentes niveles.

Los atributos de más alto nivel situados dentro de <process> son:

 queryLanguage. Especifica el lenguaje utilizado en la selección de nodos. Por defecto es "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"

 expressionLanguage. Especifica el lenguaje utilizado en <process>. Por defecto es "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"

 supressJoinFailure. Determina si el fallo joinFailure se reprime para todas las actividades en el proceso.

 exitOnStandardFault. Si su valor es “yes”, se sale del proceso cuando se produce el fallo joinFailure. Si su valor es “no”, entonces se maneja según esté descrito en el código.

Por su parte, las actividades WS-BPEL van a definir prácticamente todos los posibles comportamientos esperados por cualquier tipo de proceso a definir, tal como puede comprobarse en el siguiente listado::

 <receive>: permite al proceso esperar a un mensaje y la actividad se completa cuando llega el mensaje.

 <reply>: permite al proceso mandar un mensaje como respuesta a un mensaje recibido por una actividad como <receive>, <onMessage> o <onEvent>. La combinación forma una operación de petición respuesta.

 <invoke>: permite al proceso invocar una operación unidireccional o petición-respuesta en un “portType” ofrecido por un socio.

 <assign>: se utiliza para actualizar los valores de las variables con nueva información. Puede tener cualquier número de tareas.

 <validate>: se utiliza para validar los valores de las variables contra las definiciones asociadas XML y WSDL. Su atributo “variables” señala a las variables que son validadas.

 <throw>: se utiliza genera un fallo desde el proceso de negocio.

 <wait>: se utiliza para esperar un tiempo determinado o hasta un momento concreto.

 <empty>: instrucción que no especifica una operación.

 <sequence>:se utiliza para definir una serie de actividades a ser realizadas de forma secuencial.

 <if>: se utiliza para seleccionar una actividad para ser ejecutada de una serie de opciones.

 <while>: se utiliza para definir que la actividad incluida dentro se debe repetir mientras se verifique que el atributo “condition” es cierto.

17

 <repeatUntil>: se utiliza para definir que la actividad incluida dentro se debe repetir mientras se verifique que el atributo “condition” es cierto. La condición se comprueba después de completar la actividad.

 <forEach>: se utiliza para iterar la actividad incluida dentro N+1 veces.

 <pick>: se utiliza para esperar uno de los posibles mensajes o el paso de determinado tiempo. Cuando uno de estos sucede, se realiza la actividad hijo. Al completarse la actividad hijo se completa también la actividad <pick>.

 <flow>: se utiliza para especificar una o más actividades que deben ser realizadas a la vez.

 <scope>: se utiliza para definir una actividad con sus propios <parterLinks>,

<messageExchanges>, <variables>, <correlationSets>, <faultHandlers>, <compensationHandler>, <terminationHandler>, y <eventHandlers>.

 <compensateScope>: se utiliza para comenzar una compensación en un elemento interior determinado que se ha completado correctamente. Solo puede utilizarse en un <faultHandler>.

 <compensate>: se utiliza para comenzar una compensación en todos los elementos interiores, en orden. Solo puede utilizarse en un <faultHandler>.  <exit>: se utiliza para terminar inmediatamente una instancia.

 <rethrow>: se utiliza para hacer un <throw> de un fallo recogido en el

<faultHandler>.

 <extensionActivity>: se utiliza para introducir un nuevo tipo de actividad.

Adicionalmente, los procesos pueden hacer referencia a otras definiciones de procesos mediante el elemento <import>. Este elemento se utiliza dentro de un proceso WS-BPEL para declarar una dependencia en un XML Schema o una definición WSDL externa. Puede haber cualquier número de elementos <import> en el proceso y cada elemento contiene un atributo obligatorio y dos opcionales.

 “namespace”: Especifica un URI (Uniform Resource Identifier) que identifica las definiciones importadas. Es opcional, si un elemento import no tiene este atributo las definiciones importadas no deben contener un “targetNamespace”.

 “location”: Contiene un URI indicando la localización de un documento que contiene definiciones relevantes. Es opcional.

 “importType”: Atributo obligatorio que identifica el tipo de documento importado mediante un URI absoluto que identifica el lenguaje usado en el documento.

Las definiciones en la sección tipos de un documento WSDL importado por un proceso WS-BPEL se consideran importadas y están disponibles para usar en el proceso. Sin embargo, si un elemento externo es utilizado por un proceso WS-BPEL entonces el documento que define el elemento debe ser importado por el proceso.

2.3 WSDL Web Services Description Language

El lenguaje WSDL [3], basado en XML se utiliza para describir servicios como una serie de extremos que operan con mensajes en los que se incluye información. En la versión

18

1.1 hay tres tipos de binding: SOAP 1.1, HTTP GET/POST y MIME. En este trabajo se hace uso de SOAP, al ser el estándar más completo y con mayores funcionalidades adicionales a los esquemas de comunicación tradicionales.

El documento WSDL es un conjunto de definiciones donde los servicios se definen mediante seis elementos.

 Types: proporciona las definiciones de tipo de datos utilizadas para describir los mensajes intercambiados. Se utiliza el tipo XSD (XML Schema) para definir los tipos.

 Message: representa una definición abstracta de los datos transmitidos. Consiste en una o más partes lógicas. Los atributos de cada parte son “element”, “type” y

“name”.

 PortType: serie de operaciones abstractas. Cada operación se refiere a un mensaje de entrada y de salida. El atributo “name” otorga un nombre único en el documento WSDL.

Hay cuatro tipos de operaciones según la comunicación:

 One-way: El endpoint recibe un mensaje. Tiene un elemento “input” con atributos “message” y “name”.

 Request-response: El endpoint recibe un mensaje y manda un mensaje. Tiene tres elementos “input”, “output” y “fault” los tres con atributo

“message” y “name”.

 Solicit-response: El endpoint manda un mensaje y recibe un mensaje. Tiene tres elementos “input”, “output”, “fault” los tres con atributo

“message” y “name”.

 Notification: El endpoint manda un mensaje. Tiene un elemento “output” con atributo “message” y “name”.

 Binding: define un protocolo concreto y el formato de los datos para las operaciones y los mensajes definidos por un “portType”.

El propósito del elemento soap:binding es especificar que el binding es según el protocolo utilizado, en el caso de este proyecto, SOAP 1.1, y que cumple el formato: Sobre, Cabecera y Cuerpo. El atributo “style” indica si la operación es RPC, orientada a parámetros y valores de retorno, o document. Por su parte, en

soap:operation se especifica el valor de la cabecera “soapAction” para la

operación, y el elemento soap:body especifica cómo aparecen las partes del mensaje dentro del elemento.

 Port: especifica una dirección para el binding, definiendo un endpoint de la comunicación. Sus atributos son “name” y “binding”.

 Service: se utiliza para juntar una serie de puertos relacionados. El atributo “name” proporciona un nombre único entre todos los servicios.

Mientras que el lenguaje BPEL cuenta con la información de lo que hace un servicio, el lenguaje WSDL se encarga de aportar la información para poder interactuar con dicho servicio.

19

2.4 BPMN Business Process Model and Notation

Una de las desventajas en cuanto al uso de WS-BPEL es que no hay una notación gráfica estándar que represente el lenguaje de forma clara, ya que no es esa su función principal. Por eso, entre los distintos tipos de BPMS hay diferentes representaciones, que se benefician de que WS-BPEL está basado en estructuras de bloques, y así obtener una imagen de las actividades que forman el proceso.

Por ello, posteriormente, se propuso BPMN [4] (Business Process Model and Notation) como forma de representar BPEL de forma más visual. La especificación de BPMN incluye un mapeo parcial de BPMN a BPEL 1.1. Sin embargo, durante el desarrollo de ambas herramientas se observaron grandes diferencias entre las dos, que hacen que sea complicado o incluso imposible generar a partir de BPMN código WS-BPEL.

BPMN satisface uno de los retos de BPM, lograr la comunicación y el entendimiento de las distintas partes de la empresa a la hora de afrontar objetivos comunes, aun cuando se trata de metas sobre las que otras ramas de la empresa no tienen un conocimiento extenso de ellas. Poder reflejar la hoja de ruta a seguir para que las personas involucradas lo visualicen hace que se comprendan mejor los procesos del negocio y se facilite su implementación.

BPMN está actualmente mantenida por OMG (Object Management Group), siendo uno de los estándares de Gestión de Procesos de Negocio más populares debido a lo funcional que es en las empresas.

Aunque se trate de un estándar tan popular profesionalmente en la actualidad, para la realización de esta práctica no se ha utilizado, ya que al tratarse de un laboratorio para definir prácticas para los alumnos se ha considerado más relevante definir los servicios en base a la notación BPEL y WSDL y así tratar de primera mano con estos estándares.

20

3. Aspectos prácticos

En este apartado se hace un breve resumen de los principales elementos y herramientas que han sido necesarias para realización de este trabajo, teniendo en cuenta que el principal objetivo del mismo es eminentemente práctico, con la preparación de una plataforma BPM utilizable en prácticas de Laboratorio. Todo el software instalado se describe en la figura 1.

Figura 1: Elementos instalados

De forma resumida, el entorno de desarrollo BPM propuesto consiste en una máquina virtual sobre la que se despliegan las librerías de BPEL. Para ello es necesario preparar dicha máquina con los módulos de los que dependen dichas librerías, como es el caso de la Máquina Virtual de Java (JDK), un Servidor Web (Apache Tomcat), un sistema de orquestación (ODE) y un entorno de desarrollo multilenguaje (Eclipse). A continuación, se describe cada uno de estos elementos.

3.1 Laboratorio virtual

Un laboratorio virtual es un sistema que simula un entorno real sobre el que se puede practicar haciendo uso programas o recreando situaciones que pueden ser complejas de reproducir en máquinas reales. En este trabajo, este tipo de sistema permite al alumno tratar de forma práctica los conceptos teóricos tratados en el apartado 2 de esta memoria y de esta forma, observar y realizar actividades relacionadas con BPM, BPEL y BPMN, partiendo directamente de una plataforma con todos los elementos preinstalados.

El laboratorio virtual desarrollado en este trabajo consta de una máquina virtual llamada BPEL en la que se instala todo el software necesario para tener un entorno virtual operativo en el que desarrollar las prácticas de laboratorio y tener así un marco virtual de aprendizaje centrado en el tema de interés, la gestión de procesos, eliminando la complejidad de la preparación de todo el entorno de desarrollo.

3.1.1 Máquina virtual

Una máquina virtual no deja de ser más que un software que emula el comportamiento de un ordenador. Este ordenador virtual está limitado por los recursos asociados a esa

21

máquina virtual, pero por el contrario, éste puede ser copiado a diferentes ordenadores, Todo ello se traduce en la portabilidad de entornos más o menos complejos sin más que copiar máquinas virtuales preconfiguradas.

Las máquinas virtuales pueden clasificarse en dos tipos dependiendo de su funcionalidad.  Máquina virtual de sistema/hardware: la capa física puede repartirse entre máquinas virtuales teniendo cada una su SO. De esta forma, varios SO pueden funcionar en el mismo ordenador de forma aislada. Cada sistema simula su propio hardware y puede utilizar los recursos de un solo ordenador para ejecutar distintos servicios. El software que permite la virtualización es denominado hipervisor o monitor de máquina virtual y dependiendo de su tipo puede ejecutarse sobre el hardware directamente, si es de tipo 1, o sobre un SO, si es de tipo 2.

 Máquina virtual de proceso/aplicación: se ejecuta dentro de un SO como enlace entre un lenguaje de programación y el SO, en forma de contenedores. Sirve para proporcionar un entorno de ejecución independiente del SO y el hardware. En este trabajo se utilizan máquinas virtuales de sistema de tipo 2, con el hipervisor Oracle VM VirtualBox, que es gratuito y el más utilizado en los entornos de laboratorio donde se pretende desplegar el sistema de prácticas de gestión.

3.1.2 Oracle VM VirtualBox

Es un software de virtualización desarrollado por Oracle Corporation para arquitecturas x86/amd64. Actualmente es software libre y se encuentra bajo una licencia de GNU General Public License, versión 2 [5].

El SO sobre el que se instala se denomina sistema anfitrión, en este caso Windows 10 64 bit, mientras que los sistemas operativos adicionales instalados sobre él se denominan sistemas invitados, en este caso Ubuntu 16.04 64bit. Los invitados se pueden configurar independientemente y anfitrión e invitados pueden compartir las entradas y salidas del hardware del sistema anfitrión. Además, los discos duros de los invitados se almacenan en los anfitriones como archivos en un Virtual Disk Image, formato específico de VirtualBox.

Además, en este caso, cuenta con la ventaja de que es un software ya instalado en los ordenadores del laboratorio y ha sido utilizado por los alumnos y profesores en diversas prácticas, lo que hace que sea más fácil de manejar y su uso sea menos problemático. Su instalación será tratada en el apartado 4.1.1, Desarrollo, Instalación, Creación de máquina virtual.

3.2 OpenJDK

OpenJDK [6] es una implementación de software libre y de código abierto, FOSS, que tiene las herramientas necesarias para crear programas en Java. Incluye entre sus recursos una máquina virtual de proceso para poder ejecutar Java independientemente del SO. Se encuentra bajo licencia GNU General Public License, versión 2 con una GPL linking

22

exception, que permite a las librerías de código estar enlazadas con los programas que las usan sin que se apliquen los términos de la licencia al programa utilizado.

Al igual que VirtualBox, también es de Oracle, que está involucrado en varios proyectos open source. Varias distribuciones de Linux tienen OpenJDK como la implementación Java SE predeterminada y es también común encontrar proyectos basados en OpenJDK en el ámbito académico.

En este trabajo se utilizará OpenJDK 8, ya que es necesario para el correcto funcionamiento del programa Eclipse. Para obtenerlo se hará uso del programa Synaptic y su instalación será tratada en el apartado 4.1.2, Desarrollo, Instalación, Java.

3.2.1 Synaptic

Synaptic es un programa de manejo de paquetes, que consiste en la misma función que la línea de comandos apt-get pero con una interfaz de usuario más cómoda para poder instalar, actualizar, buscar, organizar y explorar paquetes y repositorios de una forma más visual.

3.3 Apache Tomcat

El software Apache Tomcat [7] es una implementación open source de: Java Servlet, JavaServer Pages, Java Expression Language y tecnologías Java WebSocket. Distribuido bajo la licencia Apache que permite utilizar el software, distribuirlo, modificarlo y no exige que las versiones derivadas se distribuyan con la misma licencia, lo que se diferencia de las licencias copyleft.

En cuanto a la arquitectura de Tomcat pueden tratarse distintos términos:

 Server: Representa el servlet, se encuentra en el directorio conf/server.xml y sus atributos, “address”, “port”, “shutdown”, representan todo el servlet completo. Utiliza el nombre Catalina.

 GlobalNamingResources: Define los recursos JNDI (Java Naming and Directory Interface) para el Server.

 Service: Representa la combinación de uno o más componentes Connector que comparten un solo motor para procesar peticiones. Puede haber uno o varios dentro de un Server.

 Engine: Representa toda la maquinaria de procesamiento de peticiones asociada a un Service en particular. Recibe y procesa todas las peticiones para uno o más Connectors. Un elemento Engine debe estar dentro de un elemento Service. Puede haber varios elementos Host, y uno es necesario y debe coincidir con el atributo

defaultHost.

 Realm: Representa una base de datos de nombres de usuario, contraseñas y roles asignados a los usuarios. Hay varios tipos de Database, en este proyecto se utiliza UserDatabaseRealm y LockOutRealm.

 Host: Representa un host virtual, que es la asociación del nombre de un servidor con el servidor en el que Tomcat está funcionando. Uno o más elementos de Host están dentro de un elemento Engine.

23

 Valve: Representa un componente que debe ser insertado en el proceso de petición de Catalina.

En este proyecto hay un Access Log Valve en el Host y registra todas las peticiones que el Host procesa. El output, determinado por el atributo directory, guarda la información según el formato del atributo pattern.

 HTTP Connector: Representa un conector que soporta HTTP/1.1. Permite a Catalina funcionar como un servidor web. Uno o varios pueden ser configurados como parte de un solo Service.

Para realizar este proyecto los atributos especificados en server.xml en los 2 conectores HTTP son:

 “port”: Puerto TCP en el que el Connector crea el socket del servidor y espera las conexiones entrantes.

 “protocol”: Protocolo para manejar el tráfico. Por defecto, HTTP/1.1.  “connectionTimeout”: Tiempo en milisegundos que el Connector espera

después de aceptar una conexión para recibir la URI.

 “redirectPort”: Puerto al que se redirige la petición que requiere transporte SSL.

 AJP Connector: Representa un conector que se comunica con un conector web mediante el protocolo AJP. El archivo server.xml también tiene un AJP Connector que cuenta con los atributos port, protocol y redirectPort.

 Context: Representa una aplicación web que es ejecutada en un host virtual. Cada aplicación web está basada en un archivo WAR (Web Application Archive). La aplicación utilizada para procesar cada petición HTTP es seleccionada por Catalina. Se pueden definir tantos elementos Context como se deseen, cada uno con un único nombre en un Host. También se pueden desplegar múltiples versiones de una aplicación web con la misma dirección al mismo tiempo.  Listener: Un elemento Listener define un componente que realiza acciones

cuando ocurren unos eventos específicos, normalmente cuando inicia o finaliza Tomcat. Los Listeners pueden estar dentro de un Server, Engine, Host o Context. En este proyecto se hará uso de la versión 9.0.8 de Apache Tomcat, necesario para ejecutar los programas realizados en Eclipse. Su instalación será tratada en el apartado 4.1.3, Desarrollo, Instalación, Apache Tomcat.

3.4 Apache ODE

Apache Orchestration Director Engine [8] sirve para ejecutar procesos de negocio definidos mediante el estándar WS-BPEL 2.0. Funciona intercambiando mensajes con uno o varios servicios web, maneja datos y errores.

Soporta dos capas de comunicación, una basada en Axis2 para soportar la comunicación con servicios web y otra basada en Java Business Integration.

24

ODE está escrito en Java y para ejecutarlo se requiere mínimo JDK 5.0 y puede funcionar en cualquier SO, pero su implementación de BPEL no consiste en mapear BPEL a Java, sino que se utiliza el JaCOb framework (Java Concurrent Objects).

Para poder utilizar ODE se requiere un servlet, que en el caso de este proyecto es Apache Tomcat.

En cuanto a su arquitectura, que puede ser observada en la figura 2, consiste en pequeños módulos que pueden ser ensamblados para hacer un BPMS: ODE BPEL Compiler, ODE BPEL Engine Runtime, ODE Data Access Objects, ODE Integration Layers y herramientas de usuario.

El sistema consiste en que el compilador convierte el documento de BPEL y el WSDL en un modelo de objetos con una estructura similar a BPEL o una lista de mensajes de error hacia el Runtime donde se respalda con la base de datos accesible por los Data Access Objects para poder lidiar con distintos problemas como por ejemplo llevar la cuenta de qué instancias hay y qué mensaje se destina a cada una, los valores de las variables para cada instancia, los partner links y el estado de la ejecución de proceso. La implementación de BPEL a nivel de instancia de mediante el JaCOb framework que proporciona un mecanismo de concurrencia a nivel de aplicación y un estado de ejecución. JaCOb aporta una máquina virtual para ejecutar BPEL. Además, ODE BPEL Runtime depende de las Integration Layers que permiten la comunicación con servicios web.

Se utilizará la versión 1.3.8. y su instalación será tratada en el apartado 4.1.3 Desarrollo, Instalación, Apache ODE.

25

3.5 Eclipse

El software Eclipse IDE Oxygen y el plugin BPEL designer utilizados en este proyecto son dos de las diversas herramientas de software de código abierto soportadas por Eclipse y Eclipse Foundation, creado originalmente por IBM en 2001 y en la actualidad manejado por Eclipse Foundation, organización sin ánimo de lucro y al igual que el software destacado en los apartados anteriores, este también está bajo una licencia de software libre, en este caso se trata de la licencia Eclipse Public License.

3.5.1 Eclipse IDE Oxygen

El entorno de desarrollo integrado que se ha utilizado para realizar el proyecto es la versión de Eclipse IDE Oxygen 3A. Cuenta con diversas herramientas para desarrolladores Java, además, permite su uso con diferentes lenguajes de programación mediante extensiones o plug-ins.

3.5.2 BPEL Designer

El proyecto BPEL Designer [9] [10] es una extensión que permite crear, desplegar y probar procesos descritos mediante lenguaje WS-BPEL 2.0, estándar descrito en el apartado 2.2 Conceptos teóricos, WS-BPEL.

Las claves de este plugin son un editor gráfico para realizar los procesos BPEL, un modelo EMF que representa el estándar, un “validator” que produce alertas basadas en la especificación WS-BPEL 2.0, un marco de ejecución para desplegar los procesos y un marco de depuración del programa.

26

4. Desarrollo

Debido a que el software Oracle VM VirtualBox ya está en los ordenadores del laboratorio, el desarrollo del proyecto debe comenzar con la creación de la máquina virtual.

Para ello, primero se ha de descargar la imagen del SO que se utilizará, en este caso se descarga de la página web de Ubuntu. En este proyecto se utiliza una imagen correspondiente a Ubuntu 16.04.3 pero puede realizarse también con versiones más recientes.

4.1 Instalación

En la siguiente figura se resume el proceso de instalación que se ha seguido para la creación de la máquina final. Los siguientes apartados siguen la secuencia que se ha de seguir por motivo de dependencias entre los diferentes módulos.

Figura 3: Esquema de instalación

4.1.1 Creación de máquina virtual

Una vez abierto el administrador Oracle VM VirtualBox se han de seguir una serie de pasos, que comienzan con el clic a “Nueva” en la barra de herramientas.

A continuación, se abre una ventana emergente en la que se especifica el nombre deseado para la máquina virtual y el sistema operativo. Como aparece en la figura 4, se ha optado por denominar a la VM BPEL.

27

Figura 4: Creación de VM. Nombre y sistema operativo Figura 5: Creación de VM. Tamaño de memoria

En la siguiente ventana, correspondiente a la figura 5, se ha de seleccionar la memoria RAM reservada para la máquina virtual. En este caso, se han reservado 4096MB.

Los siguientes pasos tratan del disco duro para la máquina virtual. Se opta por “Crear un disco duro virtual ahora” seleccionando después el tipo de archivo como VirtualBox Disk Image y en el siguiente paso se elige que el almacenamiento sea reservado dinámicamente. Seguidamente se especifican tanto la ubicación como el tamaño máximo de la máquina virtual.

Se decide otorgar un límite lo suficientemente amplio como para poder trabajar cómodamente sin problemas de almacenamiento, como puede verse en la figura 6.

Figura 6: Creación de VM. Ubicación del archivo

Una vez terminado este paso, la máquina virtual ya está creada. Ahora aparece en la vista del administrador vista en la figura 7.

28

Figura 7: Creación de VM. Vista de administrador

Ahora, se ha de configurar el interior de la máquina virtual a la que se accede haciendo doble clic sobre ella. Y el primer paso es seleccionar la imagen descargada de Ubuntu anteriormente, como puede verse en la figura 8.

Figura 8: Configuración de VM. Selección de disco de inicio

Se instalará en inglés, ya que debido a la gran cantidad de material en Internet en dicho idioma sobre posibles problemas que puedan surgir a lo largo del uso de la máquina, la comparación de mensajes de error y dudas de manejo en general será más fluida. También en las opciones de instalación se acepta “Download updates while installing Ubuntu” ya que ahorra tiempo después de la instalación. Y se desestima instalar el software opcional ya que no cumple ninguna función útil para el desarrollo del trabajo.

El siguiente paso trata sobre cómo se debe instalar el SO, en la figura 9. Se detecta que no hay un SO existente y se dan una serie de opciones de las cuales se elige la primera, que consiste en borrarlo todo e instalar el SO.

29

Figura 9: Configuración de VM. Tipo de instalación

Después es necesario señalar la localización (Madrid) y el idioma del teclado (Spanish-Spanish), para lo que hay múltiples opciones.

Por último, se ha de crear la cuenta de superusuario, vista en la figura 10, que en este proyecto es la única que se ha creado en el sistema. Al igual que con la VM, se ha utilizado el nombre bpel y como contraseña, “telematica”, ya que es una de las más utilizadas en las cuentas del laboratorio a la hora de realizar las prácticas.

Figura 10: Configuración de VM. Cuenta de superusuario

Con esto se tiene ya una máquina virtual con el sistema operativo Ubuntu lista y preparada para que se instalen en ella todas las herramientas software necesarias.

4.1.2 OpenJDK

Para instalar Java, se ha optado por utilizar Synaptic, cuya descripción aparece en el apartado 3.2.1.

Primero, ya que no se encuentra por defecto instalado en esta versión de Ubuntu, ha de descargarse utilizando el comando:

30

Una vez descargado, se accede a él y de una forma sencilla se puede hacer uso de la herramienta de búsqueda, en este caso buscando por “jdk” y seleccionando la opción deseada se procede a instalar OpenJDK 8, como puede verse en la figura 11.

Figura 11: Instalación OpenJDK 8

Además, se comprueba que efectivamente se haya descargado la versión correcta, como se ve en la figura 12.

$ java -version

openjdk version "1.8.0_181"

OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-0ubuntu0.16.04.1-b13) OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

Figura 12: Comprobación de la versión de Java

4.1.3 Apache

Para obtener Apache Tomcat se descarga el archivo tar.gz desde uno de los mirrors de la página web de Apache. Además, debe verificarse la integridad de los archivos descargados y para ello se proporcionan tanto firmas OpenPGP como checksums, para poder verificar tanto la autenticidad como la integridad.

31

gpg: /home/bpel/.gnupg/trustdb.gpg: trustdb created

gpg: key F22C4FED: public key "Andy Armstrong <[email protected]>" imported gpg: key 86867BA6: public key "Jean-Frederic Clere (jfclere) <[email protected]>" imported

gpg: key E86E29AC: public key "kevin seguin <[email protected]>" imported gpg: key 307A10A5: public key "Henri Gomez <[email protected]>" imported

gpg: key 564C17A3: public key "Mladen Turk (*** DEFAULT SIGNING KEY ***) <[email protected]>" imported

gpg: key 7C037D42: public key "Yoav Shapira <[email protected]>" imported gpg: key 33C60243: public key "Mark E D Thomas <[email protected]>" imported gpg: key 2F6059E7: public key "Mark E D Thomas <[email protected]>" imported gpg: key 288584E7: public key "Rémy Maucherat <[email protected]>" imported gpg: key 0D811BBE: public key "Yoav Shapira <[email protected]>" imported gpg: key 731FABEE: public key "Tim Whittington (CODE SIGNING KEY) <[email protected]>" imported

gpg: key 0D498E23: public key "Mladen Turk (Default signing key) <[email protected]>" imported

gpg: key A7A0233C: public key "Jeremy Boynes <[email protected]>" imported gpg: Total number processed: 13

gpg: imported: 13 (RSA: 3) gpg: no ultimately trusted keys found

$ gpg --verify apache-tomcat-9.0.8.tar.gz.asc apache-tomcat-9.0.8.tar.gz

gpg: Signature made vie 27 abr 2018 21:34:50 CEST using DSA key ID 33C60243 gpg: Good signature from "Mark E D Thomas <[email protected]>"

gpg: aka "Mark E D Thomas <[email protected]>"

gpg: aka "Mark E D Thomas <[email protected]>" gpg: WARNING: This key is not certified with a trusted signature!

gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DCFD 35E0 BF8C A734 4752 DE8B 6FB2 1E89 33C6 0243 Seguidamente, se descarga la distribución WAR de Apache ODE de forma similar a la descarga de Tomcat. Mientras que en Tomcat se dispone de checksum de referencia para SHA1 y SHA512, en este caso el algoritmo de checksum es SHA1. También se comprueba la firma PGP. $ sha1sum apache-ode-war-1.3.8.zip 67fd42646bf2bb1bab01cb557b513ff4e1eb5990 apache-ode-war-1.3.8.zip $ cat apache-ode-war-1.3.8.zip.sha1 67fd42646bf2bb1bab01cb557b513ff4e1eb5990 $ gpg --import KEYS

32

gpg: key D3F71223: public key "Matthieu Riou (CODE SIGNING KEY) <[email protected]>" imported

gpg: key 2EED13CE: public key "Alex Boisvert (CODE SIGNING KEY) <[email protected]>" imported

gpg: key 14A8A2BA: public key "Assaf Arkin <[email protected]>" imported

gpg: key 108F6019: public key "Alexis Midon (CODE SIGNING KEY) <[email protected]>" imported

gpg: key 3C966102: public key "Tammo van Lessen (CODE SIGNING KEY) <[email protected]>" imported

gpg: key BB2259D2: public key "Sathwik Bantwal Premakumar (CODE SIGNING KEY) <[email protected]>" imported

gpg: Total number processed: 6

gpg: imported: 6 (RSA: 2) gpg: no ultimately trusted keys found

$ gpg --verify apache-ode-war-1.3.8.zip.asc apache-ode-war-1.3.8.zip

gpg: Signature made jue 15 mar 2018 06:05:47 CET using RSA key ID BB2259D2 gpg: Good signature from "Sathwik Bantwal Premakumar (CODE SIGNING KEY) <[email protected]>"

gpg: WARNING: This key is not certified with a trusted signature!

gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E1E6 9364 6581 6BE2 60CF A5CC 96D5 FB4A BB22 59D2

Para llevar una idea clara de los directorios de los archivos, se crea otra carpeta llamada apache, en la que se copian ambas carpetas. Una vez ahí, se extrae la carpeta de Tomcat y a continuación, se debe extraer la carpeta de ODE y copiar la carpeta “ode.war” al directorio /home/bpel/apache/apache-tomcat-9.0.8/webapps. Después, debe extraerse también y debe quedar la carpeta webapps como aparece en la figura 13.

Figura 13: Localización de ODE en webapps dentro de Tomcat

Para comprobar que Tomcat esté bien instalado, se puede realizar la siguiente prueba y comprobar que funciona como se ve en la figura 14.

$ export CATALINA_HOME=/home/bpel/apache/apache-tomcat-9.0.8 $ export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64 $CATALINA_HOME/bin/startup.sh

Using CATALINA_BASE: /home/bpel/apache/apache-tomcat-9.0.8 Using CATALINA_HOME: /home/bpel/apache/apache-tomcat-9.0.8 Using CATALINA_TMPDIR: /home/bpel/apache/apache-tomcat-9.0.8/temp Using JRE_HOME: /usr/lib/jvm/java-1.8.0-openjdk-amd64

Using CLASSPATH:

/home/bpel/apache/apache-tomcat- 9.0.8/bin/bootstrap.jar:/home/bpel/apache/apache-tomcat-9.0.8/bin/tomcat-juli.jar

33

Figura 14: Apache Tomcat funcionando

Como aparece en la imagen, si se ve correctamente es que Apache Tomcat 9.0.8 está instalado correctamente.

Si se ejecuta el siguiente comando, la misma dirección deja de funcionar como aparece en la figura 15.

$CATALINA_HOME/bin/shutdown.sh

Using CATALINA_BASE: /home/bpel/apache/apache-tomcat-9.0.8 Using CATALINA_HOME: /home/bpel/apache/apache-tomcat-9.0.8 Using CATALINA_TMPDIR: /home/bpel/apache/apache-tomcat-9.0.8/temp Using JRE_HOME: /usr/lib/jvm/java-1.8.0-openjdk-amd64

Using CLASSPATH:

/home/bpel/apache/apache-tomcat- 9.0.8/bin/bootstrap.jar:/home/bpel/apache/apache-tomcat-9.0.8/bin/tomcat-juli.jar

Figura 15: Apache Tomcat apagado

4.1.4 Eclipse IDE

El siguiente paso es instalar el Eclipse IDE y para ello hay que descargarlo de la página web de Eclipse.

En este caso, se ha utilizado el instalador para facilitar el proceso. Al descargarse, da la opción de instalar los diferentes tipos de IDE (Integrated Development Environment) disponibles según el tipo de trabajo que quiera realizarse, en este caso, se utilizará “Eclipse IDE for Java EE developers” y se utilizará como carpeta de instalación una carpeta separada igual que para apache en este caso en el directorio /home/bpel llamada

34

eclipse. Después de aceptar el Acuerdo de Licencia se debe determinar si se acepta el certificado de Eclipse Foundation, visto en la figura 16.

Figura 16: Instalación Eclipse IDE. Certificado Eclipse

Cuando ya está el programa instalado, se puede acceder a él y antes de entrar se debe seleccionar la carpeta de trabajo en la que se localizarán los archivos de los proyectos realizados. En este caso, como aparece en la figura 17, se utiliza el directorio home/bpel/eclipse-workspace.

Figura 17: Eclipse IDE. Localización archivos de proyecto

El siguiente paso para configurar todo el software necesario es instalar la extensión BPEL Designer. Para ello, dentro de Eclipse en el menú “Help” haciendo clic sobre “Install New Software” se abre una ventana, que corresponde a la figura 18, en la que se puede utilizar la URL del repositorio desde donde se pueden descargar los elementos de BPEL Designer.

35

Figura 18: Eclipse IDE. Instalación BPEL Designer

Para actualizar el programa, se ha de reiniciar y una vez que se vuelve a abrir, se puede comprobar si la extensión ha sido correctamente instalada si al crear un proyecto nuevo ya sea desde la barra superior “File” > ”New” o desde el icono aparece la opción BPEL 2.0 que se ve en la figura 19.

Figura 19: Eclipse IDE. Nuevo BPEL 2.0

El siguiente paso antes de empezar a crear proyectos dentro de Eclipse es crear un servidor, para lo que se utilizará la configuración realizada en el apartado anterior de Apache Tomcat y Apache ODE.

Para poder acceder a la vista de los servidores se entra en la pestaña “Window” de la barra superior y dentro de “Show View” clicar en “Servers”.

A continuación, se añade un nuevo servidor Ode v1.x llamado “localhost” y se configura según se observa en la figura 20, utilizando la localización de Apache Tomcat y Apache ODE. El puerto debe coincidir con un puerto del archivo server.xml situado en /home/bpel/apache/apache-tomcat-9.0.8/conf que ha sido descrito en el apartado 3.3 y se incluye en el apartado de Anexos.

En este caso el archivo tiene los puertos 8080 y 9090. Debido a que el 8080 es el puerto por defecto puede que salte error porque esté ocupado con otras aplicaciones y al detectar