Una arquitectura orientada a servicios para la organización y desarrollo de eventos científicos

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad Matemática, Física y Computación Licenciatura en Ciencias de la Computación. Trabajo de Diploma Una arquitectura orientada a servicios para la organización y desarrollo de eventos científicos. Autoras:. Heidy Díaz Barrios Yania Alemán Rivas. Tutor:. Msc. Carlos A. Pereira Marín Santa Clara 2009.

(2) Dictamen.. Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencia de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. Firma de las autoras. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del tutor. Firma del jefe del Seminario.

(3) PENSAMIENTO. En el temor del Señor está la sabiduría; En apartarse del mal, la inteligencia. Job 28:28.. III.

(4) DEDICATORIA. A Dios, por su misericordia, porque nunca me abandonó. A mis padres, porque me amaron desde el primer día, porque sin ellos, simplemente, nada hubiese sido posible. Heidy. A Dios, mi único refugio, quien en todo momento me colmó de bendiciones. A mis padres que siempre me dieron el consuelo y la fortaleza en los momentos en que parecía desfallecer. A mi hermano, que desde su experiencia me ayudó y me dio el apoyo necesario para no impacientarme. Yania. IV.

(5) AGRADECIMIENTOS. A Dios, por conocerlo y convertirse en el tesoro de nuestra vida. A nuestros padres, que siempre nos alentaron para seguir adelante, aun en medio de las adversidades; por hacer suyas cada una de nuestras batallas y porque siempre confiaron en nosotras. A nuestra familia, por su bondad y cariño. A nuestros amigos, por estar siempre a nuestro lado y darnos su apoyo incondicionalmente. A nuestros hermanos en la fe, por siempre tenernos presentes en sus oraciones. Al tutor, por su guía. A Yandrek, por compartir su experiencia. A Carlos, por su paciencia, comprensión y ternura. A Sandy Pérez, porque siempre estuvo dispuesto a ayudarnos. A Yoan Pacheco, por dedicarnos parte de su tiempo desinteresadamente. A Yuniesky Abreu, por conservar su buen humor. Y a todos aquellos que de una forma u otra nos ayudaron a hacer realidad este sueño.. V.

(6) RESUMEN El presente trabajo propone la creación de una arquitectura orientada a servicios, a partir del análisis del modelo de procesos para la organización y desarrollo de eventos científicos, debido a la necesidad de tener un sistema informatizado capaz de agilizar y coordinar la gestión de estos eventos, de los cuales una significativa cantidad son celebrados cada año en la Universidad Central “Marta Abreu” de Las Villas. A través de la aplicación de los principios y las estrategias de esta tecnología orientada a servicios y el modelo de procesos del problema en cuestión,. se realizó el análisis y diseño,. lográndose, desde las tareas del mismo modelo, la creación de los servicios candidatos y sus operaciones correspondientes, para luego obtener la composición de estos en las diferentes capas definidas para la arquitectura. Altova XMLSpy 2008 fue la herramienta seleccionada para realizar la descripción de cada servicio, mediante el lenguaje de descripción de los servicios Web, con el cual además se generan los esquemas para los servicios descritos definiéndose nuevos tipos de datos.. VI.

(7) ABSTRACT The present work proposes the creation of an architecture oriented to the services. Talking into account the analysis done to the model of processes for the organization and development of scientific events, due to the need of creating and informatics system able to facilitate and coordinate the management of these events, from which a significant number are held in each area of the Central University of Las Villas “Marta Abreu”. Through the application of principles and strategies of this technology oriented to the services and the model of the process from this problem; an analysis was carried out, as well as a design oriented to the services, achieving, from the tasks of the model, the creation of the candidate services and their corresponding operations, to obtain later their composition in the different layers defined for the architecture. Altova XMLSpy 2008 was the selected tool to make a description of each service by means of the language description of the web services, through which are generated the schemas for the describe services, defining in this way, new kinds of data.. VII.

(8) ÍNDICE PENSAMIENTO...........................................................................................................III DEDICATORIA ...........................................................................................................IV AGRADECIMIENTOS.................................................................................................. V RESUMEN ...................................................................................................................VI ABSTRACT................................................................................................................ VII ÍNDICE...................................................................................................................... VIII INTRODUCCIÓN ..........................................................................................................1 CAPÍTULO 1. ANÁLISIS DE LA ARQUITECTURA ORIENTADA A SERVICIOS PARA EL MANEJO DE PROCESOS DE NEGOCIOS. .................................................4 1.1 La Gestión del Proceso de Negocio........................................................................4 ¿Qué es un Proceso de Negocio? .............................................................................4 BPM y SOA. ...........................................................................................................5 1.2 SOA primitivo .......................................................................................................6 Los servicios encapsulan la lógica............................................................................6 Los servicios se relacionan. .....................................................................................7 Los servicios se comunican......................................................................................7 Los servicios son diseñados. ....................................................................................8 El servicio es construido. .........................................................................................8 1.3 SOA Contemporánea. ............................................................................................9 Conceptos de primera generación de los servicios web. ......................................... 10 Conceptos de segunda generación WS-*................................................................11 Principios de la orientación a servicios................................................................... 12 Definiendo SOA Contemporánea........................................................................... 17 1.4 Capas y estrategias de la arquitectura orientada a servicios. .................................18 1.4.1 Capas que constituyen una arquitectura orientada a servicios. .......................18 Capa de servicio de aplicación ...............................................................................18 Capa de servicio de negocio...................................................................................19 Capa de servicio de orquestación ...........................................................................19 1.4.2 Estrategias de desarrollo de SOA. .................................................................20 Estrategia Top-down.............................................................................................. 21 Estrategia Botton-up ..............................................................................................21 VIII.

(9) Estrategia Ágil....................................................................................................... 22 CAPÍTULO 2. ANÁLISIS DEL MODELO DEL PROCESO DE NEGOCIO................24 2.1 Organización de eventos. .....................................................................................24 ¿Por qué organizar un evento? ...............................................................................24 Etapas de organización de un evento...................................................................... 25 Beneficios de la automatización de eventos............................................................25 2.2 Descripción de las actividades Aprobación y Planificación del modelo del proceso de negocio Organización de Eventos..........................................................................26 2.3 Análisis orientado a servicios...............................................................................29 Modelado de servicios (el proceso paso a paso). ....................................................31 CAPÍTULO 3. DISEÑO DE LA ARQUITECTURA DE LOS SERVICIOS..................42 3.1 Herramienta Altova XMLSpy 2008. ....................................................................42 3.2 Proceso de diseño de la arquitectura.....................................................................42 Creación de las WSDL. .........................................................................................43 Creación de los esquemas. .....................................................................................44 Descripción de las WSDL y los esquemas para cada servicio. ................................46 CONCLUSIONES ........................................................................................................57 RECOMENDACIONES ...............................................................................................58 BIBLIOGRAFÍA........................................................................................................... 59 ANEXOS ......................................................................................................................60. IX.

(10) Introducción INTRODUCCIÓN Planteamiento del problema. Los eventos surgen como un reclamo de la sociedad, la cual ha necesitado reunirse por razones de asociarse en un determinado entorno geográfico, en colectivos y grupos. Son un hecho económico y cultural que permite un intercambio social, político, profesional y científico técnico. El interés de muchas instituciones por desarrollar y celebrar eventos, en los que se generen reuniones y encuentros entre muchas personas de diferentes lugares, se asocia con los beneficios que genera: regula la estacionalidad de la demanda turística, crea empleos generalmente calificados, moviliza localmente una gran cantidad de dinero como consecuencia del eslabonamiento productivo con otras actividades económicas y se constituye como un factor de multiplicación de los esfuerzos promocionales. Estos organismos, instituciones y empresas, tanto de carácter público como privado, han visto en la organización de eventos la vía más adecuada para el logro de sus objetivos. Asociaciones, fundaciones, colegios profesionales, universidades y entidades públicas de distintos sectores de la industria se sirven de este mercado para consolidar alianzas relacionales. La Universidad Central “Marta Abreu” de Las Villas (UCLV) organiza cada año más de una decena de importantes eventos nacionales e internacionales de corte científico principalmente, a los cuales asisten prestigiosos investigadores y académicos del país y de más allá de sus fronteras. Estos eventos son organizados por sus correspondientes comisiones ejecutivas, y a pesar de la gran popularidad de las comunicaciones digitales como Internet y el correo electrónico, esta organización no se realiza de manera completamente automatizada, por lo que el éxito del evento depende de la pericia y la profesionalidad del grupo de personas encargadas de concretar todos los detalles para un buen desempeño en la ejecución del evento en cuestión. La organización de eventos se ha convertido en una actividad altamente especializada, que requiere de conocimientos de equipos y de personal con perfil profesional bien. 1.

(11) Introducción tipificado o especializado. Un punto clave es determinar el objetivo real que motiva a organizarlo, de ahí los beneficios reales de su exitoso cumplimiento. Se sabe entonces que la organización de un evento puede estar sujeta a irregularidades provocadas por faltas o errores funcionales, incumplimientos de términos de entregas o revisión de información, ausencias eventuales de personas encargadas de actividades importantes en el proceso organizativo, deficiente planificación de las tareas a ejecutar en esta etapa, gasto innecesario de recursos, exceso de reuniones y otras tantas razones, propias del factor humano que pueden dar al traste con una buena ejecución del evento. El proceso de organización de un evento puede verse desde cierto punto de vista como el proceso de administración de un negocio, pronunciada en la naturaleza de los propios beneficios que su ejecución engendra, por tanto sería práctico pensar que una introducción mucho más eficiente de las tecnologías en el proceso organizativo de eventos, podría ser mucho más productivo y beneficioso si se aplica una integración de las tecnologías de gestión de procesos de negocios (siglas en inglés, BPM) y de arquitectura orientada a servicios (siglas en inglés, SOA), particularmente en servicios web; en aras de lograr integridad y operatividad de los factores que intervienen durante la organización de dichos eventos. (Marín, 2009) SOA es una metodología de desarrollo de software que conlleva a los desarrolladores a compartir y reutilizar código. Es una forma de hacer más con menos, donde las aplicaciones pueden ser construidas más rápidamente y cada vez con menos líneas de código original. La complejidad del proceso de gestión que se exige en la organización y desarrollo de eventos y la ventaja principal del paradigma SOA, que consiste en su capacidad de alineamiento con las necesidades de las organizaciones dinámicas y flexibles del siglo XXI, hacen muy necesario dar los primeros pasos en la creación de una plataforma que permita lograr tal efectividad. Además, en la actualidad no abundan los sistemas automatizados basados en estas tecnologías, que tengan como objetivo la organización de eventos. En este sentido, la mayoría de los sitios dedicados a esta temática, tienen carácter informativo o de gestión de contenidos (blogs), de existir alguna versión comercial en el mercado internacional podría ser costosa, y aun, si se pudiese obtener,. 2.

(12) Introducción probablemente esta no estaría acorde a las necesidades del centro, debido a que se elaboran de acuerdo a las expectativas del cliente. (España, 2006) Objetivo general. Diseñar una arquitectura orientada a servicios, a partir del modelo de procesos de negocio para la organización y desarrollo de eventos científicos en la Universidad Central “Marta Abreu” de Las Villas. Objetivos específicos. 1. Realizar el estudio y análisis de los procesos del modelo para la organización y desarrollo de eventos científicos y determinar los servicios que formarán parte de las capas de la arquitectura. 2. Diseñar la descripción de los servicios web para cada servicio y sus esquemas correspondientes. El presente documento consta de tres capítulos estructurados de la siguiente manera: Capítulo 1: Se plantea un estudio sobre la arquitectura orientada a servicios y su integración con las tecnologías de gestión de procesos de negocio. Se analizan los conceptos de SOA primitiva y contemporánea, con especial énfasis en los principios de la orientación a servicios, los diferentes tipos de capas que constituyen esta arquitectura, así como las estrategias de desarrollo. Capítulo 2: Mediante el análisis de los procesos del modelo de negocio, se realiza el modelado de los servicios, siguiendo los procedimientos para obtener los servicios candidatos que serán parte de la arquitectura a desarrollar. Capítulo 3: Una vez analizados los procesos, se procede al diseño de la arquitectura de los servicios modelados, mediante el uso de la herramienta Altova XMLSpy 2008, a través de la cual se crean las WSDL para describir los servicios y los esquemas, en los que se pueden definir nuevos tipos de datos, utilizados por las operaciones de las WSDL.. 3.

(13) Capítulo 1 CAPÍTULO 1. ANÁLISIS DE LA ARQUITECTURA ORIENTADA A SERVICIOS PARA EL MANEJO DE PROCESOS DE NEGOCIOS. En este capítulo se realizará un análisis exhaustivo de los fundamentos de la Arquitectura Orientada a Servicios, el cual permitirá conocer el surgimiento y evolución de esta tecnología, además de los beneficios que aporta su uso en la programación de servicios.. 1.1 La Gestión del Proceso de Negocio El interés de las organizaciones hoy no está limitado únicamente al desarrollo de software que automatice determinadas actividades individuales, sino que, tienen como objetivo final la automatización de todo el proceso de negocio, ya que de ello depende en gran parte su competitividad. ¿Qué es un Proceso de Negocio? Un proceso de negocio se puede ver como un conjunto estructurado de tareas, que contribuyen colectivamente a lograr los objetivos de una organización. Se registran y difunden en manuales de procedimientos, diagramas de flujo y hasta en forma verbal. Son la base operativa de una empresa y el éxito de la misma depende fuertemente de la eficiencia con que sean gestionados. Una mala gestión de los procesos trae aparejados altos costos, baja productividad, e inadecuados tiempos de respuesta tanto frente a las oportunidades como a las amenazas. Por esto el modelado de procesos viene siendo objeto de estudio desde hace ya tiempo. El concepto de Gestión de Procesos de Negocios (BPM), que debe sus siglas a la frase inglesa (Business Process Managment), engloba todas las actividades que son parte del ciclo de vida de un proceso de negocios, tales como el descubrimiento, diseño, simulación,. despliegue,. ejecución,. interacción,. monitoreo,. control,. análisis. y. optimización del proceso de negocios. (Agenda, 2008) BPM surge como la evolución natural de los sistemas de workflow y de los procesos de negocio de las empresas. Esto es debido a que la evolución del término proceso ha cambiado en el interior de las organizaciones; muchos de los procesos de las empresas actuales no se apoyan solo sobre una aplicación o un conjunto de aplicaciones internas,. 4.

(14) Capítulo 1 como sucede con los sistemas de workflow tradicionales. Cada vez más las necesidades de las empresas se están orientando hacia procesos más complejos que engloban diferentes departamentos, filiales o socios, que pueden incluso estar geográficamente distribuidos. Cada una de estas entidades posee sus propios procesos que pueden ser más o menos heterogéneos y complejos. (Noel, 2005) BPM y SOA. La arquitectura orientada a servicios (SOA) no se trata de software o de un lenguaje de programación, SOA es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de las Tecnologías de la Información (TI) integrando los datos y la lógica de negocio de sus sistemas separados. Desarrollada a finales de los ´90, SOA establece un marco de trabajo para servicios de red – o tareas comunes de negocios – para identificar el uno al otro y comunicarlo. Las tecnologías BPM surgieron apoyadas en el concepto SOA de reciente aparición. Un ejemplo de esto es el problema de distribución y heterogeneidad de sistemas con los que se debe interactuar para completar el proceso de negocio, en este contexto la arquitectura SOA es más que apropiada. Es así que del modelado de procesos y de la arquitectura orientada a servicios, más precisamente del uso de servicios web (web services) surge un nuevo concepto denominado composición de servicios. Esta composición no solo permite modelar el proceso de negocio, sino que también maximiza las potencialidades que SOA brinda a través de la integración de datos y aplicaciones. SOA es una arquitectura esencial que brinda mayor flexibilidad a la infraestructura de las empresas, mientras que BPM consiste en una serie de actividades coordinadas para el negocio. Puede implementarse una sin la otra, sin embargo la sinergia de ambas trae consigo más beneficios. SOA facilita la tarea de conectar los procesos del negocio a los sistemas subyacentes, ahorrando en tiempo y en recursos tecnológicos. La adopción de BPM mientras se implementa SOA, permite la reutilización de sus componentes, minimizando la complejidad de los procesos de negocio. (Anónimo, 2007). 5.

(15) Capítulo 1 1.2 SOA primitivo La Arquitectura Orientada a Servicios (SOA) es un término que representa un modelo en el cual la lógica de automatización es descompuesta en pequeños e inconfundibles módulos de lógica. A continuación se analizarán los diferentes aspectos que constituyen las características de los servicios, los cuales son la base de SOA primitivo. Los servicios encapsulan la lógica. Para quedarse con su independencia, los servicios encapsulan la lógica dentro de un claro contexto utilizando servicios web. Este contexto puede ser especificado por una tarea de negocio, una entidad de negocio o cualquier otro agrupamiento lógico. El tamaño y potencial de la lógica representada por el servidor puede variar. Además, la lógica del servicio puede abarcar la lógica provista por otros servicios. En este caso, uno o más servicios son abarcados en un colectivo. Cuando se construye una solución automatizada consistente de servicios, cada servicio puede encapsular una tarea ejecutada en un paso individual o un sub-proceso formado de un conjunto de pasos. Un servicio puede igual encapsular la lógica del proceso completo. En los dos últimos casos, el extenso potencial representado por los servicios puede abarcar la lógica encapsulada por otros servicios. (Figura 1.2 a). Por los servicios usar la lógica que ellos encapsulan, pueden participar en la ejecución de actividades de negocio. Figura 1.2 a Los servicios pueden encapsular varias lógicas. 6.

(16) Capítulo 1 Los servicios se relacionan. Dentro de SOA los servicios pueden ser usados por otros servicios o programas. La relación entre los servicios es basada en un acuerdo que permite que los servicios interactúen estando conscientes de los demás. Esta conciencia es lograda a través del uso de las descripciones de servicio (WSDL). Una descripción de un servicio en su más básico formato establece el nombre del servicio y la información esperada y retornada por el servicio. La manera en la cual los servicios usan descripción de servicio resulta en una relación clasificada como acople bajo. Por ejemplo, un servicio A está consciente del servicio B porque el servicio A está en posesión de las descripciones del servicio de B (Figura 1.2 b).. Figura 1.2 b El servicio A tiene toda la información que necesita para comunicarse con el servicio B porque tiene acceso al servicio descripción del servicio B Para que los servicios interactúen y lleven a cabo algo significativo, deben intercambiar información. Un marco de comunicación capaz de conservar su relación de acople bajo es por consiguiente necesario. Tal marco es la mensajería. Los servicios se comunican. Luego que un servicio envía un mensaje por su camino, pierde el control de lo que pasa al mensaje a partir de entonces. Esta es la razón por la que se necesitan mensajes de protocolo de acceso a objetos simples (SOAP), que existan como módulos independientes de comunicación. Esto significa que los mensajes, como los servicios, deben ser autónomos, por tanto, los mensajes pueden ser equipados con suficiente inteligencia para gobernar por sí mismos sus partes del proceso lógico (Figura 1.2 c). Los servicios que. 7.

(17) Capítulo 1 proveen descripciones de servicio y se comunican vía mensajes forman una arquitectura básica.. Figura 1.2 c Un mensaje existe como una unidad independiente de comunicación. Los servicios son diseñados. Los principios de la orientación a servicios direcciona la cuestión del diseño de los componentes de esta arquitectura. Dichos principios se encargan de analizar cómo los servicios, las descripciones de servicios y los mensajes son diseñados y cómo las relaciones entre los servicios son definidas. Cuando una solución está formada por módulos de proceso lógico orientado a servicios, se convierte en una solución orientada a servicios. Con el conocimiento de los componentes que forman parte de la arquitectura básica y un conjunto de principios de diseño, se puede formar y estandarizar estos componentes. Todo lo que falta sería la plataforma que permite juntar los pedazos para construir la solución de automatización orientada a servicios. La tecnología de servicios web ofrece tal plataforma. El servicio es construido. Ningún desarrollo tecnológico ha sido tan adecuado y exitoso construyendo SOA como los servicios web. Todos los vendedores importantes de plataformas actualmente soportan la creación de soluciones orientadas a servicios, y muchos lo hacen con el entendimiento de que el soporte de SOA está basado en el uso de los servicios web. Por tanto, es importante enfocarse en cómo SOA puede y debe ser realizado a través del uso de la plataforma de tecnología de servicios web. Con todas las características señaladas en los sub-epígrafes anteriores, se describen los elementos fundamentales de lo que se llama SOA primitiva. 8.

(18) Capítulo 1 Un SOA era clasificado en diferentes formas, a menudo dependiendo de las tecnologías de implementación usadas para construir los servicios. Un modelo más cercano inspirado principalmente por el conjunto inicial de estándares de servicios web, definió SOA como una arquitectura modelada alrededor de tres componentes básicos: el servidor que hace la solicitud (service requestor), el servidor que provee la información (service provider) y el servicio registro (service registry). (López, 2008). Figura 1.2 d Una temprana encarnación de SOA.. 1.3 SOA Contemporánea. Continuamente se están concibiendo nuevas especificaciones de servicios web y construyendo cada vez más poderosos XML y soportes de servicios web dentro de las actuales tecnologías de plataforma. El resultado es una variación extendida de la arquitectura orientada a servicios, a la cual se hace referencia como SOA contemporánea. SOA contemporánea se construye encima del modelo de SOA primitiva influenciando la industria y el desarrollo de las tecnologías para ir más lejos en sus ideas originales. Aunque la tecnología de implementación requerida puede variar, las SOAs contemporáneas han evolucionado a un punto donde pueden ser asociadas con un conjunto de características comunes. En la Figura 1.2 se muestra los tres componentes esenciales que van a definir SOA contemporánea, los cuales serán explicados a través de este epígrafe.. 9.

(19) Capítulo 1. Figura 1.3 Influencias externas que forman y soportan SOA contemporánea. Conceptos de primera generación de los servicios web. Dentro de los conceptos de Primera Generación de estándares de servicios web se encuentran: •. WSDL (Web Services Description Language): basado en XML para describir la interfaz pública de un servicio web, que es su parte más importante porque asigna al servicio una identidad y permite su invocación, esto es la descripción abstracta. Esta descripción está compuesta por tipos (types), mensajes (message) e interfaces (portType), la cual define qué hace el servicio a través de los mensajes que envía y recibe. La segunda parte es la descripción concreta que establece el transporte y localización de la información. Está compuesta por la encuadernación (binding) y el servicio (services), que define el cómo y el dónde. Las WSDL permiten el acople bajo entre los servicios. Es la tecnología fundamental asociada al diseño de servicios. (Barco, 2007). •. SOAP (Simple Object Access Protocol): es el protocolo estándar de transporte para el procesado de mensajes a través de servicios web, permitiendo la comunicación. Cada mensaje SOAP es empaquetado en un recipiente conocido como sobre. El mensaje SOAP está estructurado por un encabezado (header) que contiene atributos relacionados con el procesamiento por el servidor, un cuerpo (body) que contiene la carga útil del mensaje y una sección de fallo (fault section) que contiene información de estado y error; todas encerradas en un sobre. La 10.

(20) Capítulo 1 sección header es usada por numerosas extensiones WS-* para implementar rasgos del nivel empresarial. (Erl, 2005) •. UDDI (Universal Description, Discovery and Integration): proveyó el formato estandarizado del servicio registro. Es un directorio de servicios web con información guardada en formato XML. UDDI provee el potencial para los servicios web de ser registrados en una localización central, desde donde pueden ser descubiertos por los solicitadores de servicios. Publica dos tipos de interfaces: Publish API donde los proveedores pueden anunciar sus servicios y Enquery API donde los consumidores de servicios pueden consultar los servicios provistos basándose en la categoría, nombre de la compañía y ubicación geográfica. Distinto a WSDL y SOAP, UDDI aún no ha alcanzado la aceptación de toda la industria. (Pérez, 2007). •. XML (Extensible Markup Language): es un abarcador meta-lenguaje que permitió agregar inteligencia a los crudos documentos de datos. No solo se utiliza para representar información en una manera estandarizada, el lenguaje en sí es usado como la base para una serie de especificaciones adicionales. La arquitectura de representación de datos de XML representa la capa fundación de SOA. En ella, se establece el formato y estructura de mensajes viajando a través de los servicios; no se puede hacer un movimiento dentro de SOA sin involucrar a XML.. Desde una perspectiva de arquitectura física, esta primera variación de los servicios web basados en SOA actualmente va más allá del modelo de SOA primitivo (definido en el epígrafe anterior), el cual no necesitaba del servicio registro. El concepto de “habilidad para mostrarse o descubrirse” surgió con los principios de SOA Contemporánea. Conceptos de segunda generación WS-*. La Segunda Generación o Especificaciones WS-* es una extensión de la primera. Estas extensiones dirigen áreas específicas de funcionalidad con el total objetivo de elevar la tecnología de plataforma de los servicios web a un nivel empresarial. SOA se implementa mejor mediante los servicios web, y sobre todo a partir del surgimiento de las extensiones. Entre las especificaciones que más se destacan están WS-Coordination que estandariza el manejo e intercambio de información contextual, WS-Addressing que. 11.

(21) Capítulo 1 identifica una instancia específica de un servicio y agrega las propiedades de intercambio de mensaje para un mensaje específico, WS-Orchestration donde diferentes procesos pueden ser conectados sin haber reestructurado las soluciones que originalmente automatizan los procesos individualmente, además esta extensión llega a ser el corazón de SOA, WS-Coreography que es una actividad compleja que consta de una composición de servicio y una serie de patrones de intercambio de mensajes, WS-Policy que provee un medio de adjuntar propiedades tales como reglas, comportamientos, requerimientos y preferencias para los servicios web, eleva al total la calidad de la mensajería dentro de SOA y WS-Security que protege los mensajes SOAP y previene el mal uso de los servicios web, sus aspectos primarios son la identificación, la autentificación, la autorización, la integridad y la confidencialidad. Existen otras extensiones dentro de las especificaciones WS-* tales como WS-Correlation, WS-ReliableMessaging WSMetadataExchange, WS-Notification y WS-Eventing. (Erl, 2005) Principios de la orientación a servicios. SOA es un tipo de arquitectura tecnológica que cumple con los principios de la orientación a servicios. Cuando se implementa a través de la plataforma tecnológica de los servicios web, SOA brinda el potencial para soportar y proveer estos principios: Reusabilidad: sin tener en cuenta si existe oportunidad de reuso inmediato, los servicios son diseñados para soportar el reuso potencial. Un servicio es simplemente una colección de operaciones relacionadas. Es por tanto, la lógica encapsulada por las operaciones individuales las que deben ser consideradas reusables para justificar la representación como un servicio reusable. La mensajería indirectamente soporta la reusabilidad a través del uso de encabezados SOAP. Esto permite a los mensajes hacerse cada vez más dependientes de sí, agrupando los detalles de los metadatos con el contenido del mensaje en un solo paquete (el sobre SOAP).. 12.

(22) Capítulo 1. Figura 1.3 a. Un servicio reusable expone operaciones reusables. Contratos de servicios: para los servicios poder interactuar, no necesitan compartir nada sino que necesitan un contrato formal que describe cada servicio y define las condiciones de intercambio de información. Los contratos de servicios definen casi todo de las partes primarias de SOA. Un contrato de servicio bueno puede proveer información semántica que explique cómo un servicio puede llevar a cabo una tarea en particular. Esta información establece el acuerdo del proveedor de servicios y su solicitor de servicio.. Figura 1.3 b. El contrato de servicios formalmente define los componentes servicio, operación y mensaje de una arquitectura orientada a servicios.. 13.

(23) Capítulo 1 Acople bajo: los servicios deben ser diseñados para interactuar, manteniendo dependencias bajas. El bajo acople es una condición donde un servicio adquiere conocimientos de otro servicio, aun cuando permanece independiente del servicio. Esto es logrado a través del uso de contratos de servicio que permitan a los servicios interactuar dentro de parámetros definidos. Los servicios limitan la dependencia de los contratos de servicio, permitiendo a los proveedores subyacentes y a la solicitud lógica permanecer con el acople bajo. Abstracción: la única parte de un servicio que es visible al mundo exterior es la que es expuesta por el contrato de servicio. La lógica subyacente, más allá de lo expresado en las descripciones que forman el contrato, es invisible e irrelevante para los servicios solicitantes. Es este principio el que permite a los servicios actuar como cajas negras, escondiendo sus detalles de afuera. No existe límite de la cantidad de lógica que un servicio puede representar. Un servicio puede estar diseñado para desempeñar una tarea o ser posicionado como una puerta para una solución completa de automatización. Un servicio puede, técnicamente exponer la aplicación lógica de dos sistemas diferentes.. Figura 1.3 d. Los servicios ocultan la lógica, solo muestran el contrato. Composición: Los servicios pueden componer otros servicios. Esto permite a la lógica ser representada a diferentes niveles de granularidad y apoyar la reusabilidad y la creación. 14.

(24) Capítulo 1 de capas de abstracción. Colecciones de servicios pueden ser coordinadas y ensambladas en composiciones de servicios. La principal razón para implementar este principio es garantizar que los servicios sean diseñados de tal manera que participen como miembros eficaces de otras composiciones de servicio, si alguna vez se requiere. Esto es sin tener en cuenta si el servicio en sí compone a otros para llevar a cabo su trabajo.. Figura 1.3 e. La operación ActualizarTodo encapsula la composición del servicio. Autonomía: La lógica gobernada por un servicio reside en una frontera explícita. El servicio tiene control en esta frontera y no es dependiente de otros servicios para ejecutar su gobierno. La autonomía requiere que el rango de la lógica expuesta por un servicio exista en una frontera explícita. Esto elimina las dependencias de otros servicios, lo cual libera al servicio de corbatas que puedan inhibir su despliegue y evolución. Ausencia de estados: Los servicios no requieren manejar el estado de la información, pues esto puede obstaculizar su capacidad para permanecer con acople bajo. Los servicios deben ser diseñados para maximizar la ausencia de estado que ellos manejan y minimizar el tiempo que lo sostienen. El estado de información es un dato específico para una actividad corriente. Mientras que un servicio está procesando un mensaje, está temporalmente lleno de estados. Si un servicio es responsable de quedarse con un estado por un largo período de tiempo, su capacidad de permanecer disponible para otras peticiones será obstaculizada. 15.

(25) Capítulo 1. Figura 1.3 f. La ausencia de estado y la presencia de estos organizan el paso de un servicio mientras se procesa un mensaje. Descubrimiento: Los servicios deben permitir a sus descripciones ser descubiertas y entendidas por los humanos y las solicitudes de servicios que pueden ser capaces de hacer uso de su lógica. El descubrimiento ayuda a evitar la creación accidental de servicios redundantes o servicios que implementen la lógica redundante. Los metadatos adjuntos a un servicio necesitan describir suficientemente no solo el propósito de todo el servicio, sino también la funcionalidad ofrecida por sus operaciones. Aunque la primera generación de servicios web estándar incluía UDDI, pocas de las primeras implementaciones en realidad usaron servicios registros como parte de su ambiente. La causa era que no suficientes servicios web eran construidos para hacer valer un registro, otra probable razón es que el concepto de servicio-descubrimiento no fue diseñado dentro de la arquitectura. Un SOA serio va a contar con alguna forma de servicio registro o directorio para manejar las descripciones de los servicios. Finalmente se puede ver cómo el principio de reusabilidad se relaciona con otros.. 16.

(26) Capítulo 1. Definiendo SOA Contemporánea. SOA Contemporánea representa una arquitectura abierta, extensible, confederada y compuesta de habilidades que promueve la orientación a servicios y está formada de servicios autónomos, diversos vendedores, interoperabilidad, que se pueden descubrir y potencialmente reusar, implementados como servicios web. SOA puede establecer una abstracción del negocio lógico y tecnologías que pueden introducir cambios al modelado del proceso de negocio y a la arquitectura técnica, resultando en un acople bajo entre estos modelos. SOA es una evolución de pasadas plataformas, conservando características exitosas de arquitecturas tradicionales, y trayendo con esto inconfundibles principios que fomentan la orientación a servicios en soporte de una empresa orientada a servicios. SOA es idealmente estandarizada por toda una empresa, pero para lograr este estado se requiere una planeada transición y el soporte de un conjunto de tecnología aun desarrollándose. Esto podría decirse de una manera más reducida de la siguiente forma: “SOA es una forma de arquitectura de tecnología que se adhiere a los principios de orientación a servicios. Cuando se realiza a través de la tecnología de plataforma de servicios web, SOA establece el potencial para soportar y promover estos principios por todo el proceso de negocio y dominios de automatización de una empresa.” (Erl, 2005). 17.

(27) Capítulo 1 1.4 Capas y estrategias de la arquitectura orientada a servicios. Las estrategias surgen para organizar las fases del ciclo de vida de entrega de SOA, para así permitir la entrega de las capas de servicios especificadas. Esas fases se organizan en un proceso que puede acomodar las preferencias con consideraciones a aquellos tipos de capas de servicios que se quieren repartir, coordinar la entrega de aplicaciones de negocios y procesos de servicios; y soportar una transición hacia un SOA estándar que pueda ayudar a llevar a cabo de inmediato los requerimientos específicos del proyecto. 1.4.1 Capas que constituyen una arquitectura orientada a servicios. Las arquitecturas orientadas a servicios están configuradas en diferentes formas y tamaños, dependiendo principalmente de los tipos de servicios de los cuales están compuestas. Existen tres capas esenciales para este tipo de arquitectura, que a su vez se encuentran en la capa de interfaz de servicio, que permiten la mejor organización de los servicios requeridos. La siguiente figura muestra estas capas.. Figura 1.4.1 a Las tres capas de servicio primarias Capa de servicio de aplicación La capa de servicio de aplicación consta de servicios de aplicación que representan la lógica de tecnología específica. Los servicios de aplicación son idealmente servicios 18.

(28) Capítulo 1 genéricos y reusables compuestos por servicios de negocio, pero también pueden existir como servicios híbridos que contienen ambos, lógica de negocios y de aplicación. Estos servicios exponen funcionalidades dentro de un contexto de procesamiento específico, son agnósticos a la solución, pueden ser utilizados para lograr la interacción punto a punto con otros servicios de aplicación y normalmente son una mezcla de servicios. Capa de servicio de negocio La capa de servicio de negocio consta de servicios de este tipo, una implementación directa del modelo de servicio de negocio. Estos son idealmente directores que componen los servicios de aplicación para ejecutar su lógica. Aunque los servicios híbridos contienen lógica de negocio, estos no son clasificados como servicios de negocio, ellos son el alma de SOA contemporánea. El único propósito de los servicios destinados a la capa de servicios de negocio es representar su lógica en la mejor forma posible. Esta capa conduce a la creación de dos modelos: •. Servicio de negocio centrado en tarea encapsula la lógica del negocio específico para una tarea o proceso de negocio. Este tipo de servicio es requerido cuando la lógica del proceso de negocio no está centralizada como parte de una capa de orquestación.. •. Servicio de negocio centrado en entidad encapsula una entidad de negocio específica tal como una factura u hoja de tiempo. Estos servicios son provechosos para la creación de servicios sumamente reusables y servicios de proceso de negocio agnóstico que son compuestos por una capa de orquestación o por una capa de servicio consistente de servicios de negocio centrado en tareas, o por ambos.. Capa de servicio de orquestación La orquestación es más valiosa que un proceso de negocio estándar, permite enlazar directamente la lógica de procesos para la integración de servicios dentro de la lógica de flujo de trabajo. Esto combina el modelado del proceso de negocio con el modelado orientado a servicio y el diseño. Debido a que los lenguajes de orquestación (como WSBPEL) llevan a cabo la gestión de flujo de trabajo a través de un servicio de modelo del. 19.

(29) Capítulo 1 proceso, la orquestación lleva el proceso de negocio dentro de la capa de servicio como un director de composición maestro. La capa de servicio de orquestación consiste de uno o más servicios de procesos que componen servicios de negocios y de aplicación de acuerdo a las reglas de negocios y a la lógica del negocio incrustada dentro de las definiciones del proceso. La capa de servicio de abstracción introduce un nivel paternal de abstracción que alivia la necesidad para otros servicios de manejar los detalles de interacción requeridos para asegurar que las operaciones de los servicios sean ejecutadas en una secuencia específica. (Erl, 2005). Figura 1.4.1 b La capa de orquestación. 1.4.2 Estrategias de desarrollo de SOA. En el ciclo de vida de SOA se necesita organizar la secuencia de pasos para la construcción de servicios individuales dentro de un proceso, que pueda entre otras cosas, soportar una transición hacia un SOA estandarizado ayudando a completar de inmediato los requerimientos específicos del proyecto. El éxito de SOA dentro de una empresa depende generalmente de la extensión en la cual se estandariza cuando es sincronizada dentro de los negocios y los dominios de aplicación. Sin embargo, el éxito de un proyecto es medido por la extensión en la cual la solución completa los requerimientos esperados. 20.

(30) Capítulo 1 dentro de un presupuesto dado y un tiempo límite. Para direccionar este problema se necesita de una estrategia. Esta debe estar basada en las prioridades de la organización para establecer el balance correcto de entre la entrega de los objetivos de migración de largo término y el cumplimiento de los requerimientos de corto tiempo. Para esto han surgido tres estrategias, cada una direccionando el problema de maneras diferentes, difiriendo en prioridades y consideraciones prácticas. Estrategia Top-down Promueve la promoción formal de la prioridad de los modelos de negocio corporativo para modelar las fronteras del servicio. Esta estrategia es mucho más un acercarse “primero al análisis” que requiere no solo de procesos de negocios para convertirse en orientado a servicios, sino que también promueve la creación o reorganización del todo de la organización del modelo de negocio. Para conocer los pasos a seguir cuando se usa esta estrategia, remitirse a los anexos. La estrategia top-down para construir SOA generalmente resulta en una arquitectura de servicios de alta calidad. El diseño y parámetros alrededor de cada servicio son analizados a fondo, maximizando el potencial de reusabilidad y las oportunidades para las composiciones racionalizadas. Ella soporta la creación de las tres capas de servicio. Todo esto pone las bases para una empresa estandarizada donde los servicios mantienen un estado de adaptabilidad, mientras se continúa para unificar la heterogeneidad existente. Los obstáculos para hacer un top-down usualmente son asociados con tiempo y dinero. Las organizaciones requieren invertir en el análisis de proyecto por adelantado que pueden tomar un trato grande de tiempo, proporcional al tamaño de la organización y las soluciones inmediatas, sin proyectar resultados inmediatos. Ver figura 1 de los Anexos. Estrategia Botton-up Esta estrategia fundamentalmente fomenta la creación de servicios como un medio para satisfacer los requerimientos centrados en aplicaciones. Los servicios web son construidos en base a las necesidades y modelados para encapsular la lógica de la aplicación para servir mejor a los requerimientos inmediatos de la solución. La. 21.

(31) Capítulo 1 integración es la motivación primaria para los diseños botton-up, donde la necesidad de tomar ventaja del marco de comunicaciones abierto de SOAP pueda ser encontrado por los servicios simplemente añadidos como envolturas para los sistemas patrimoniales. La mayoría de las organizaciones que actualmente construyen servicios web aplican bottom-up. La razón principal es que las organizaciones agregan servicios web a sus ambientes de aplicaciones existentes para influenciar el conjunto de tecnologías de servicios web. La arquitectura dentro de los servicios web es agregada sin alteraciones y los principios de la orientación a servicios son por tanto rara vez considerados. La estrategia bottom-up no es realmente una estrategia del todo. No es un acercamiento válido para lograr SOA contemporánea. Esta es una comprensión que golpea a muchas organizaciones cuando empiezan a usar orientación a servicios como un modelo de arquitectura más serio. Aunque el diseño de bottom-up permite la eficiente creación de servicios web por ser necesario para las aplicaciones, implementando una apropiada SOA, en un punto tardío puede resultar en un gran acuerdo de retro-repuesto o lo que es igual, la introducción de nuevas capas de servicio estandarizadas posicionadas sobre el tope de los servicios no estandarizados producidos por esta aproximación. Ver figura 2 de los Anexos. Estrategia Ágil El desafío es encontrar un balance aceptable entre las estrategias anteriores para lograr la incorporación de los principios del diseño orientado a servicios dentro del ambiente de análisis de negocios sin tener que esperar a integrar antes las tecnologías de servicios web dentro del ambiente técnico. Para muchas organizaciones esto es provechoso pues ven estos dos acercamientos como extremos y encuentran un adecuado terreno medio, de ahí su otro nombre “encontrarse en el medio”. Esto es posible definiendo un nuevo proceso que permita para el análisis del nivel de negocios encontrarse al mismo tiempo con el diseño del servicio y la evolución. Esta estrategia es más compleja que las anteriores porque necesita para completarse de dos conjuntos contrarios de requerimientos.. 22.

(32) Capítulo 1 Esta estrategia toma lo mejor de ambos mundos y los combina en una aproximación al cumplimiento de SOA que encuentra los requerimientos inmediatos sin poner en peligro la integridad de un modelo de organización del negocio y las calidades de la orientación a servicios de la arquitectura. Mientras se cumplimentan las necesidades de corto y largo término, la red resultante de emplear esta estrategia es aumentada, asociado el esfuerzo con cada entrega de servicio. El hecho de que esos servicios deban ser revisitados, rediseñados, remodelados y reorganizados, va a agregarlos proporcionalmente a la cantidad de servicios sujetos a este paso de retarea. Adicionalmente se impone el mantenimiento de las tareas que son requeridas para asegurar que los servicios existentes sean mantenidos con los modelos de negocio revisados. Aun con el proceso de mantenimiento, los servicios todavía corren el riesgo de perder el alineamiento con un constante cambio del modelo de negocio. Ver figura 3 de los Anexos. (López, 2008) Para la realización de este capítulo, se revisaron otras bibliografías que no fueron referenciadas de manera directa pero sirvieron de apoyo en la confección de este. Estas son: (Estévez, 2008), (Lira, 2007), (TIBCO, 2005), (Magazine, 2005). Conclusiones En este capítulo se realizó un estudio teórico de los fundamentos de SOA, la cual es considerada la próxima plataforma computacional de aplicación estándar. El concepto de SOA contemporáneo conduce a mejoras en la construcción de soluciones automatizadas así como la proliferación de fines orientados a servicios, beneficiando a las empresas como un todo. Entre las mejoras que introduce este nuevo concepto de SOA, se destaca la reducción de la complejidad y mejora de la calidad de los sistemas y de la productividad así como la eficiencia mediante la integración de procesos de información dentro y fuera de la empresa que permita una mayor agilidad y flexibilidad para responder a los cambios que se produzcan en el mercado. Los servicios reusables pueden ser ensamblados para formar nuevos servicios y aplicaciones compuestas, lo cual es uno de los principios claves del diseño SOA. Esto no solo reduce el tiempo y los costos, sino que además evita tener que crear y probar códigos nuevos, mitigando el riesgo de fallo en los procesos, puesto que SOA aprovecha los servicios probados en la producción.. 23.

(33) Capítulo 2 CAPÍTULO 2. ANÁLISIS DEL MODELO DEL PROCESO DE NEGOCIO. En el siguiente capítulo se realizará el análisis de dos de los procesos del modelo de negocio, siguiendo los pasos del análisis orientado a servicios. Este análisis permitirá generar los servicios candidatos que formarán las diferentes capas, y sus respectivas operaciones, todo esto basado en una estrategia de desarrollo escogida previamente.. 2.1 Organización de eventos. Los eventos surgen como un reclamo de la sociedad, la cual ha necesitado reunirse por razones de asociarse en un determinado entorno geográfico, en colectivos y grupos. Son un hecho económico y cultural que permite un intercambio social, político, profesional y científico técnico. Un evento tiene sus finalidades, se desarrolla en un plazo de tiempo previsto, consume recursos, tiene un alcance, una configuración, en él participan un conjunto de factores y partes interesadas en su desarrollo, genera conocimientos que se comparten, dispone de un presupuesto, cuenta con patrocinadores y clientes de los resultados, por tanto a los efectos de la organización y dirección del evento a partir de una programación dada, su comportamiento puede ser evaluado como un proyecto, una empresa o un negocio. Antes de organizar cualquier tipo de evento existen cuestiones fundamentales, en las cuales habrá que ganar claridad para garantizar la calidad de su ejecución. Las respuestas a las preguntas básicas del por qué, cuándo, cómo, cuánto y para quién se realizará un evento, deben ser contestadas una vez que se tenga pleno conocimiento de terminologías y conceptos, así como lineamientos, etapas, direcciones, misiones e indicaciones y consejos, surgidos a partir de la especialización de muchos profesionales en materia de organización de eventos. Se debe hacer énfasis en que todo evento, cualquiera que sea, es un suceso ÚNICO. ¿Por qué organizar un evento? Muchas pueden ser las razones por las cuales organizar un evento, pero haciendo un análisis previo, se pueden implicar los motivos para organizarlo y la utilidad que puede. 24.

(34) Capítulo 2 tener el mismo para los distintos campos o sectores involucrados, o sea, un punto clave es determinar el objetivo real que motiva a organizarlo, de ahí los beneficios reales de su exitoso cumplimiento. Etapas de organización de un evento. El proceso de organización de eventos encierra una serie de acciones, las cuales deben estar cohesionadas entre sí y casi perfectamente coordinadas por el grupo gestor, ellas están enmarcadas en un lapso de tiempo dividido en etapas. La correspondencia entre el evento y el proyecto en el proceso de dirección permite definir 5 etapas esenciales y las principales tareas y actividades que deben cumplirse en cada una de ellas, estas son: la previsión, donde la concepción y la aprobación del evento definen dos fases o momentos de la misma, la planificación, la ejecución y el cierre. Los procesos que serán analizados en este capítulo se enmarcan en la fase de concepción dentro de la etapa de previsión. Esta se inicia con la presentación de la idea a la dirección del centro, la cual evalúa la propuesta atendiendo a su factibilidad, posibles resultados e impacto en el ámbito donde se actúe, estudio de mercado, visión, elementos de medición del grado de satisfacción (o insatisfacción), etc. Implica tener una idea anticipada en la definición de objetivos generales, el tipo de evento, categoría y nombre, tema central y tópicos, posibles participantes, duración, sede captada y también posible presupuesto y vías de financiamiento. (Marín, 2009) Beneficios de la automatización de eventos. Un evento tiene sus finalidades, se desarrolla en un plazo de tiempo previsto, consume recursos, tiene un alcance, una configuración, en él participan un conjunto de factores y partes interesadas en su desarrollo, genera conocimientos que se comparten, dispone de un presupuesto, cuenta con patrocinadores y clientes de los resultados. Por tanto a los efectos de la organización y dirección del evento a partir de una programación dada, su comportamiento puede ser evaluado como un proyecto, una empresa o un negocio. Según lo antes descrito, es evidente que se necesita una mejor política para la gestión de la información y el conocimiento en la organización, donde prevalezca un flujo de las comunicaciones interiores canalizadas por e-mail de manera que se pueda reaccionar a las. 25.

(35) Capítulo 2 noticias con velocidad de reflejo. También se hace necesario un estudio “online” de los datos comerciales, financieros y de mercado para detectar pautas y compartir las revelaciones con prontitud. Es importante la interpretación de las tendencias generales y la personalización del servicio para el cliente individual, y por consiguiente convertir todos los procesos de soporte papel en procesos digitales, con lo cual se eliminan los cuellos de botella administrativos y los trabajadores superiormente cualificados. se. dedican a cometidos más importantes. (Gates, 1999) La UCLV no cuenta con un sistema automatizado para la organización de eventos, por tanto, se decidió dar los primeros pasos en aras de obtener un sistema basado en servicios web aprovechando el éxito del uso de la arquitectura SOA, que permita la mejor planificación y ejecución de los diversos eventos que se realizan en este centro cada año.. 2.2 Descripción de las actividades Aprobación y Planificación del modelo del proceso de negocio para la organización y desarrollo de eventos científicos. A continuación se hará la descripción de las tareas que se encuentran dentro de las actividades Aprobación y Planificación de la entidad Institución. Las actividades de Aprobación y Planificación comienzan con la tarea de ‘Pronóstico de los Resultados’, si se recomienda la aprobación se pasa a ‘Nombrar Comité Organizador’, de lo contrario termina el proceso. Luego se realiza la tarea ‘Analizar Condiciones Mínimas’, si es posible la ejecución se pasa a ‘Presentar Propuesta de Ejecución’ y luego se hace la ‘Solicitud de Aprobación de Ejecución del Evento’, si el evento es aprobado entonces se pasa a una etapa de Organización y si no, termina el proceso. Ahora se describirán cada una de las tareas de las dos actividades antes mencionadas. •. Pronósticos de los Resultados: Esta tarea se realiza si la idea es factible, asunto que se analiza en la etapa de Concepción. En ella se elabora un pronóstico de los resultados que pueda tener el evento y se hace una recomendación a partir de este pronóstico. Se definen cuotas de inscripción y de cursos en Moneda Nacional o Moneda Convertible para los participantes. Se pronostica la cantidad de posibles participantes extranjeros y nacionales según su categoría: delegado, acompañante,. 26.

(36) Capítulo 2 invitado, ponente o estudiante. Se toman en cuenta las posibles donaciones, patrocinios y auspicios. Se calcula el total de ingresos y el porciento de participación extranjera. Ejecutantes: Director, Consejo científico. •. Nombrar Comité Organizador: Se hace el nombramiento del Comité Organizador. Este comité está formado por todas las comisiones. Ejecutantes: Secretario Ejecutivo, Director, Promotor, Consejo científico.. •. Analizar Condiciones Mínimas: Se analizan las condiciones mínimas que se necesitan para comenzar la organización del evento y la existencia de estas. Se plantea o chequea la necesidad de infraestructura, personal y logística. Se introducen los posibles gastos por módulo de acreditación, salario del personal, solicitud de servicios, brindis y acto social, gastos en divulgación y papel (material gastable), compra de medios básicos o de rotación y los posibles ingresos por inscripción (cuotas), cursos, donaciones, auspicios, patrocinios y otros (alquiler, expo, paquete turístico, hospedaje). Se calculan los gastos totales, el presupuesto disponible y el punto de equilibrio, comprobando si los gastos son mayores que el 30 % del punto de equilibrio. Ejecutantes: Secretario Ejecutivo, Director. •. Presentar Propuesta de Ejecución: Se presenta una propuesta de la ejecución del evento. Ejecutantes: Secretario Ejecutivo, Director. •. Solicitud de Aprobación de Ejecución de Evento: Se presenta al Buró de Congresos todo el diseño de organización del evento, con su pronóstico de resultados y condiciones actuales para su organización. Ejecutantes: Representante buró de congresos. De las tareas antes descritas, las únicas que no se realizan de forma manual son Pronóstico de los Resultados y Analizar Condiciones Mínimas, el resto constituyen lo que se denomina tareas manuales. Por tanto, estas son las tareas que se analizarán en el próximo epígrafe para obtener los servicios de la arquitectura inicial. (Pérez, 2009). 27.

(37) Capítulo 2. Figura 2.2 a Modelo del Proceso de Negocio para la organización de eventos.. 28.

(38) Capítulo 2. Figura 2.2.b Etapas Aprobación y Planificación del modelo del proceso de negocio.. 2.3 Análisis orientado a servicios. El ciclo de vida de entrega de un proyecto SOA costa de una serie de pasos que necesitan ser completados para construir los servicios para una solución orientada a servicios dada. Las fases básicas del ciclo de vida de SOA son: 1. Análisis orientado a servicios. 2. Diseño orientado a servicios. 3. Desarrollo del servicio. 4. Prueba del servicio. 5. Despliegue del servicio. 6. Administración del servicio. Durante las dos primeras fases de análisis y desarrollo son incorporados dentro de la solución las características de SOA y los principios orientados a servicios. Los servicios individuales son modelados como candidatos en la etapa de análisis. El proceso de determinar cómo los requerimientos de automatización de los procesos pueden ser representados a través de la orientación a servicios es el dominio de la etapa de análisis. (autores, 2006) Las preguntas que se formulan durante esta fase son:. 29.

(39) Capítulo 2 1. ¿Qué servicios se necesita construir? 2. ¿Que lógica debe ser encapsulada por cada servicio? El total de objetivos de esta fase son los siguientes: •. Definir un conjunto preliminar de operaciones de servicios candidatos.. •. Agrupar las operaciones de servicios candidatos dentro del contexto lógico. Estos contextos representan los servicios candidatos.. •. Definir las fronteras preliminares de los servicios tal que estos no se superpongan a ningún servicio existente o planeado.. •. Identificar la lógica encapsulada con el reuso potencial.. •. Garantizar que el contexto de la lógica encapsulada sea apropiada para su uso destinado.. •. Definir cualquier modelo de composición preliminar conocido.. El proceso de análisis orientado a servicios depende de la estrategia de descubrimiento escogida para producir el servicio. La estrategia escogida va a determinar las capas de abstracción que forman las capas de servicios de un ambiente de solución. En el problema que se planteó se usará la estrategia Ágil debido a la necesidad de ganar en tiempo, pues dicha estrategia permite desarrollar el análisis y diseño de los servicios en paralelo con la elaboración del modelo del proceso de negocio. Esto resulta más complicado pues se requiere re-diseñar, re-elaborar, re-desplegar y re-probar para lograr así una alienación con el actual estado del modelo de negocio, a medida que este va teniendo cambios. Ver Figura 3 de los Anexos. La siguiente figura muestra el conjunto de pasos pertenecientes al análisis orientado a servicios, los que se describirán a continuación.. 30.

(40) Capítulo 2. Figura 2.3 a Procesos del análisis orientado a servicios. La estructura en las diferentes capas de servicios que forman una arquitectura es la siguiente: 1. La orquestación compone los servicios de negocio y posiblemente los servicios de aplicación. 2. Los servicios de negocio componen los servicios de aplicación para ejecutar la lógica de negocio. 3. Los servicios de aplicación interactúan con sistemas subyacentes para procesar las funciones requeridas. Modelado de servicios (el proceso paso a paso). En la fase de análisis se producen los servicios abstractos candidatos que pueden o no ser realizados como parte del diseño final concreto. Una vez que las restricciones, los requerimientos y las limitaciones específicas para el ambiente de implementación son factorizadas, el diseño final de un servicio es una significante partida del candidato original correspondiente debido a que estuvo sujeto a las realidades de la arquitectura técnica en la cual se espera que resida. Así que en este estado no se producen servicios,. 31.

(41) Capítulo 2 sino que se crean servicios candidatos. Estos últimos y las operaciones de ellos son el resultado final de un proceso llamado modelado de servicio, del cual se explicarán los pasos más significativos. Ver Figura 4 de los Anexos. Paso 1: Descomponer el proceso de negocio. Se tomarán los procesos que son objeto de estudio, Pronóstico de los Resultados y Analizar Condiciones Mínimas, para desglosar las operaciones de cada uno lo mayor posible. Pronóstico de los Resultados: •. Definir cuotas de inscripción y de cursos en moneda nacional y en moneda convertible.. •. Pronosticar cantidad de inscripciones tanto de nacionales como de extranjeros.. •. Chequear la validez de los datos entrados.. •. Estimar ingresos por cursos de pre y post eventos en moneda nacional y en moneda convertible.. •. Estimar cantidad de presupuesto que se debe adquirir por donaciones, patrocinio y auspicio.. •. Calcular la suma de todos los ingresos.. •. Estimar el total de participantes, el 30% de este total debe ser de participación extranjera para recomendar la aprobación del evento.. Analizar Condiciones Mínimas: •. Chequear necesidades de infraestructura, personal, y logística (tales como local, medios básicos, aseguramiento de todo tipo).. •. Plantear posibles gastos en módulo de acreditación, salario del personal, solicitud de servicios, brindis y acto social, de divulgación y compra de medios.. •. Chequear la validez de los datos entrados.. •. Calcular posibles gastos totales.. •. Chequear presupuesto disponible, si no hay presupuesto, ver posibilidad de préstamo; si existe la posibilidad continuar, de lo contrario finalizar.. 32.

(42) Capítulo 2 •. Chequear si las ganancias son mayores o no que el 30% de los ingresos una vez logrado el punto de equilibrio (Ingresos – Gastos > 30% Ingresos), para aprobar la ejecución.. Figura 2.3 b Representación del proceso Pronóstico de los Resultados.. 33.

(43) Capítulo 2. Figura 2.3 c Representación del proceso Analizar Condiciones Mínimas. Paso 2: Identificar las operaciones de los servicios de negocio candidatos. Existen pasos que no pertenecen a la lógica potencial que debe ser encapsulada por los servicios candidatos como son aquellos que no se pueden automatizar y todos los que no necesitan ser parte de la solución. Seguidamente solo se mostrarán aquellas tareas que no son manuales. 34.

(44) Capítulo 2 Pronóstico de los Resultados: •. Chequear la validez de los datos entrados.. •. Calcular la suma de todos los ingresos.. •. Estimar el total de participantes, el 30% de este total debe ser de participación extranjera para recomendar la aprobación del evento.. Calcular Condiciones Mínimas: •. Chequear la validez de los datos entrados.. •. Calcular posibles gastos totales.. •. Chequear si las ganancias son mayores o no que el 30% de los ingresos una vez logrado el punto de equilibrio (Ingresos – Gastos > 30% Ingresos), para aprobar la ejecución.. Paso 3: La lógica de orquestación abstracta. Este paso se realiza si en la solución del problema se cuenta con una capa de orquestación. Como los servicios candidatos que se producirán pueden por sí mismos encapsular la lógica del negocio, no se cree necesario tener una capa de orquestación. Paso 4: Crear los servicios de negocio candidatos. Revisando los pasos del proceso se puede determinar uno o más contextos lógicos en los cuales estos pasos son agrupados, cada contexto representa un servicio candidato y dependerán del tipo de servicio de negocio que se haya escogido para construir. Los centrados en tareas requerirán un contexto específico para el proceso y los centrados en entidad introducen la necesidad de agrupar los pasos del proceso de acuerdo a sus relaciones con las entidades definidas anteriormente. Lo importante no es la cantidad de pasos en cada grupo sino establecer el conjunto requerido de contextos. A continuación se agruparán las operaciones de acuerdo a la tarea que realicen: Chequear datos de entrada. •. Verificar que los datos entrados sean números no negativos.. 35.

(45) Capítulo 2 •. Verificar que los datos sean enteros no negativos. (Se refiere al número de personas y cantidad de inscripciones al evento y por cursos).. Realizar cálculos. •. Calcular la suma de todos los ingresos.. •. Calcular el 30% del total de participantes y comparar con la cantidad de extranjeros.. •. Calcular posibles gastos totales.. •. Calcular el 30% de los ingresos y comparar con las ganancias.. Mensajería y notificación •. Si la participación extranjera sobrepasa el 30% del total de participantes, enviar un mensaje de recomendar la aprobación del evento.. •. Si las ganancias sobrepasan el 30% de los ingresos, enviar un mensaje aprobación de ejecución del evento.. 36.

(46) Capítulo 2. Figura 2.3 d Los primeros servicios candidatos Paso 5: Refinar y aplicar los principios de la orientación a servicios. Se centrará la atención especialmente en la reusabilidad y la autonomía debido a que es importante el asegurarse de que cada operación del servicio candidato que se identifique sea potencialmente reusable y tan autónoma como sea posible. En el caso del servicio candidato Mensajería y Notificación, existen dos operaciones de enviar mensajes, de las cuales la acción de enviar mensaje de aprobación de la ejecución depende directamente de que se haya enviado antes el mensaje de recomendar aprobación del evento. Por tanto se considera que se deben unir estas dos operaciones en una única acción de Enviar mensaje de notificación. Para el servicio candidato Chequear Datos de Entrada, existen dos operaciones que permiten el chequeo de diferentes tipos de datos. Estas serán consolidadas en una sola operación llamada Chequear validez de los datos, que hará al servicio candidato más reusable. En el servicio candidato Calcular, se cree necesario separar sus operaciones en tres servicios candidatos que se llamarán Cálculo Pronóstico, Cálculo Condiciones y Cálculos Totales. Los dos primeros realizan las operaciones específicas de sus correspondientes procesos, mientras que el servicio Cálculos Totales fue creado pues es usado por ambos procesos, logrando la reusabilidad de este servicio.. 37.