P. 1
Proyecto De Grado

Proyecto De Grado

|Views: 1,521|Likes:
Published by Martha E. Rojas

More info:

Published by: Martha E. Rojas on Oct 10, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/21/2012

pdf

text

original

Sections

  • 1.1. Introducción o antecedentes del proyecto
  • 1.2. Identificación del problema central del proyecto
  • 1.3. Abordaje o ruta de solución del problema
  • 1.4. Objetivos del Proyecto
  • 1.5. Justificación del proyecto
  • 1.6.1. Metodología de Investigación
  • 1.6.2. Metodología de Ingeniería
  • 1.6.3.1. Investigación
  • 1.6.3.2. Desarrollo del caso de estudio
  • 1.7.1. Arquitectura de Aplicación
  • 1.7.2. Proceso de Negocio
  • 1.7.3. Gestión de Procesos de Negocio (BPM)
  • 1.7.4. Aplicaciones empresariales
  • 1.7.5. Integración Punto a Punto
  • 1.7.6. Metodologías de desarrollo de software y su evolución
  • 1.7.7. Integración de Aplicaciones Empresariales
  • 1.8. Referencia a proyectos similares
  • 1.9.1. Antecedentes y evolución de la Arquitectura de Software
  • 1.9.2. Evolución de la Arquitectura de lado del Servidor
  • 1.9.3. Progresión de la Arquitectura Mainframe
  • 1.9.4. Progresión de la Arquitectura Cliente/Servidor
  • 1.9.5. Progresión de la Arquitectura Distribuida
  • 1.9.6. Llamada a Procedimientos Remotos (RPC)
  • 1.9.7. Mensajería
  • 1.9.8. Arquitectura Orientada al Servicio (SOA)
  • 1.9.9. Principios de la Orientación al Servicio
  • 1.9.10. Servicio
  • 1.9.11.1. SOAP
  • 1.9.11.2. WSDL
  • 1.9.11.3. UDDI
  • 1.9.11.4. Esquema XML
  • 1.9.12. Interfaz de Servicio
  • 1.9.13. Bus de Servicios Empresarial
  • 1.9.14. Registro SOA
  • 1.10.1.1. JBoss
  • 1.10.1.2. JBoss Enterprise SOA Platform
  • 1.10.1.3. JBoss jBPM
  • 1.10.1.4. JBoss ESB
  • 1.10.1.5. Ediciones de JBoss Enterprise SOA Platform
  • 1.10.2.1. Spring Framework
  • 1.10.2.2. Spring Web Flow
  • 1.10.2.3. XFire
  • 1.10.2.4. Hibernate
  • 3.1.1. Antecedentes de la Institución
  • 3.1.2. Actividad a la que se dedica
  • 3.1.3. Misión
  • 3.1.4. Visión
  • 3.1.5. Valores
  • 3.1.6. Contexto Organizacional
  • 3.1.7. Contexto Social
  • 3.1.8. Contexto Tecnológico
  • 3.2.1. Datos replicados innecesariamente
  • 3.2.2. Lógica de negocio replicada
  • 3.2.3. Falta de una Arquitectura bien definida
  • 3.2.4. Interoperabilidad de los Sistemas
  • 3.2.5. Necesidad de Seguimiento del Ciclo de Vida de Documents
  • 3.2.6. Agilidad, Flexibilidad y Alineamiento
  • 3.3.1. Requerimientos Funcionales
  • 3.3.2. Requerimientos no Funcionales
  • 3.4.1. Identificación de Riesgos
  • 3.4.2. Proyección de los riesgos
  • 3.4.3. Mitigación y contingencia de los riesgos
  • 3.4.4. Caso de Estudio: Sistema de Gestión Documental
  • 3.4.5.1. Procesos de Negocio: Aprobación/Rechazo de Documentos
  • 3.4.5.2. Identificación de Servicios
  • 3.4.5.3. Proceso de Negocio: Control de Equipos
  • 3.4.5.4. Identificación de Servicios
  • 3.4.5.5. Otros Servicios
  • 3.4.6. Arquitectura de Referencia SOA
  • 4.1.1. Arquitectura Orientada al Servicio
  • 4.1.2. Caso de Estudio: Sistema de Gestión Documental
  • 4.1.3.1. Hardware
  • 4.1.3.2. Software
  • 4.2.1. Plan de Pruebas: Sistema de Gestión Documental
  • 4.2.2. Plan de Pruebas: Arquitectura Orientada al servicio
  • 4.2.3.1. Pruebas de Caja Negra
  • 4.2.3.2. Pruebas de Caja Blanca
  • 4.3. Puesta en Marcha
  • 5. CONCLUSIONES
  • 6. RECOMENDACIONES
  • 7. REFERENCIAS BIBLIOGRÁFICAS

ÍNDICE

DECLARACION DE DERECHOS DEL AUTOR
Al presentar este proyecto como uno de los requisitos para la obtención del Grado Académico, de Licenciado en Ingeniería de Sistemas de la Universidad Mayor Real y Pontificia de San Francisco Xavier de Chuquisaca, autorizo a la dirección de Carrera de Ingeniería de Sistemas y a la Biblioteca de la Universidad, para hacer de este proyecto un documento disponible para su lectura según las normas de la Universidad. Así mismo manifiesto mi acuerdo para la utilización de éste, como material productivo, dentro del reglamento de Ciencia y tecnología, siempre y cuando este uso no suponga ganancia económica. También cedo a la Universidad de San Francisco de Xavier de Chuquisaca los derechos parte o la totalidad de este proyecto, manteniendo derechos de autores durante un periodo de hasta 30 meses después de su aprobación. Atentamente,

Univ. Martha Eugenia Rojas Vera C.U.: 35-2039 Sucre, octubre de 2010

Ingeniería de Sistemas

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX

RESUMEN
Ajustarse a las demandas cambiantes continuas del entorno de las Tecnologías de la Información (TI) es uno de los mayores retos para la Universidad San Francisco Xavier, así como para cualquier compañía. Este reto demanda al departamento de TI proveer un soporte apropiado que adapte los procesos dentro de la organización. El gran problema es que el entorno de TI de la Universidad es complejo y está compuesto por diferentes sistemas implementados en diversas tecnologías que no fueron diseñados para ser integrados con otros. Este proyecto describe el concepto de “Arquitectura Orientada al Servicio” SOA como una solución para que la USFX puede organizar y estructurar su entorno de TI para enfrentar los problemas mencionados anteriormente. SOA es un estilo arquitectural que permite la interacción de diferentes aplicaciones sin importar su plataforma, lenguaje de implementación o ubicaciones utilizando servicios genéricos y confiables que pueden ser usados como un bloque de construcción de aplicaciones. Este proyecto describe SOA a detalle, considerando diferentes conceptos, metodologías, tecnologías, requerimientos relacionados y un enfoque basado en Servicios Web con el propósito de lograr una figura completa y exacta de esta arquitectura, para luego finalmente aplicar todos estos conceptos con el desarrollo e implementación de un Caso de estudio Prototipo. El método que sigue la investigación y desarrollo del proyecto es el Método Científico, para el desarrollo del caso de estudio se sigue la metodología RUP y dentro de sus fases se hace un análisis y diseño orientado al servicio siguiendo la estrategia top-down. Al término de este trabajo se logró un documentar e implementar una Arquitectura Orientada al Servicio que represente la solución para los problemas mencionados y se ajuste a los requerimientos del departamento de TI de la USFX,

Introducción y Antecedentes del Proyecto

1

Ingeniería de Sistemas

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX

1. INTRODUCCIÓN Y OBJETIVOS
1.1. Introducción o antecedentes del proyecto

La USFX, fundada el 27 de marzo de 1624, es una Institución Nacional de estudios superiores con personalidad jurídica que goza de autonomía económica, administrativa, financiera y funcional, conforme al Art. 92 de la Constitución Política del Estado, que se constituye en una de las instituciones más importantes del país dentro del área de la formación académica de miles de universitarios, su aporte económico también es importante ya que es una fuente generadora de trabajo. Está constituida por dependencias encargadas del área administrativa, económica, tecnológica y académica, y es dentro del área administrativa tecnológica dentro de la cual ubicamos a la Dirección de Tecnologías de Información y Comunicación cuyas tareas cubren las necesidades de la institución en cuanto a tecnología se refiere. La DTIC cuenta con cinco oficinas y una sala de servidores, la oficina principal donde trabaja el gerente, y otras cuatro oficinas donde se encuentran los departamentos de Desarrollo de Sistemas, Administración de Bases de Datos, Telecomunicaciones y redes, Carnetización y los encargados de soporte técnico. Además cuenta con varios recursos informáticos. Entre estos el sistema de Seguimiento Académico, Carnetización, Control de Asistencia, etc. El gestor de BD es SQL Server 2000 para los sistemas grandes y MySql para otros más pequeños, como lenguajes de desarrollo usa Java, PHP, Java Script, Delphi, etc. En lo que a redes se refiere cuenta con una intranet con salida a internet. Debido al alcance de la globalización, al dinamismo del entorno, el rápido crecimiento de la población universitaria, que actualmente es de aproximadamente 30000 alumnos y en general a los rápidos avances de la tecnología, la USFX debe estar adaptándose y evolucionando constantemente y eficientemente para brindar un mejor servicio, razón por la cual se está dando muchos cambios estructurales en la parte académica y administrativa. Esto lleva a que la estrategia del área de TI no sea simplemente proveer y asegurar el funcionamiento de la tecnología, sino que está debe estar alineada con la estrategia del negocio y convertirla en socio estratégico.

Introducción y Antecedentes del Proyecto

2

que cuentan con interfaces descritas en un lenguaje estándar. esto no es una solución a los problemas mencionados anteriormente. ni acogiendo estándares de industria abiertos. Cada departamento quiere algo ligeramente diferente. sino que se debe tener una arquitectura bien definida sobre la que estos servicios web van a implementarse. con –claro está. por lo tanto se exigen desarrollos de adaptadores particulares. Con el paso del tiempo la USFX ha llegado a tener programas similares. PHP). Por ello.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Por lo explicado anteriormente se pueden evidenciar las siguientes dificultades: El entorno tecnológico que posee la USFX actualmente es complejo desde el punto de vista técnico. Y aun la más pequeña diferencia en la implementación podría resultar en inconsistencias. entonces ese departamento construye su propia versión de ese software.pequeñas variaciones. Estas pequeñas variaciones son lo que hace a los sistemas difíciles de mantener. por ello se puede encontrar al interior varias versiones de más o menos el mismo programa. se tiene que encontrar y cambiar cada instancia en cada aplicación afectada. que deben integrarse de forma sincrónica para satisfacer los nuevos requerimientos empresariales. y una arquitectura de 5 capas basada en J2EE [20] sólo para sus sistemas más importantes. pero no es suficiente con crearlos. Si bien en la USFX se tienen algunos sistemas que tratan de reutilizar servicios (los famosos servicios web). si se hace un cambio en la política de negocio que afecta a otras aplicaciones. JAVA. ya que algunos sistemas no fueron diseñados sobre plataformas o tecnologías compatibles entre sí. ya que se compone de infraestructuras inflexibles donde la integración de los sistemas resulta una labor difícil para el departamento de TI. Para tratar de subsanar estos problemas la USFX ha desarrollado algunos servicios web. Introducción y Antecedentes del Proyecto 3 . no cuenta con una arquitectura independiente de la plataforma sobre la cual deberían construirse todos los sistemas se han desarrollado. Actualmente se cuenta con sistemas desarrollados en diferentes lenguajes de programación (Delphi.

de forma adecuada. es por esto que las áreas de TI tienen una serie de aplicaciones legadas que no pueden intercambiar información o conectarse entre ellas. no brinda la flexibilidad de poder ampliar la funcionalidad de las aplicaciones actuales cuando sea necesario. SOA plantea una solución para esta situación.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX En la Facultad de Tecnología se ha elaborado una tesis titulada “Desarrollo de Web Services para un Proveedor de Servicios de Aplicación” [1]. interoperabilidad y reutilización de los sistemas existentes al interior ya sean nuevos desarrollos o sistemas legados.2. sin tener en cuenta otros sistemas empresariales y cómo integrarse con ellos. En la actualidad se encuentra una propuesta interesante: Arquitectura Orientada al Servicio (SOA) [4]. etc. Identificación del problema central del proyecto La Infraestructura Tecnológica actual de la USFX que hace difícil integración. Dentro de los programas ya elaborados para solucionar problemas similares a los del presente proyecto. SOA nace como la evolución de las aplicaciones monolíticas que solucionaban necesidades especificas como: contabilidad. a los objetivos de la organización y que permitan adaptar las aplicaciones existentes. permitiendo interconectar sus aplicaciones corporativas y construir otras a partir de unidades funcionales llamadas servicios. compras. o de código abierto como FUES y JBoss SOA Platform que es lo que se utilizará en el proyecto para conformar la arquitectura SOA. SOA aporta una guía tecnológica para ayudar a los desarrolladores de software a diseñar aplicaciones que sirvan. Bizuit Agile Buisness Suite. Oracle SOA Suite. si bien no son aplicaciones en si son herramientas comerciales como WebSphere de IBM. en servicios de valor para la organización. 1. que podrá servir de referencia al momento de generar la documentación y definir un “Servicio Web”. Planificación de Actividades del Proyecto 4 . Es con la intención de resolver los problemas descritos que surge este proyecto.

la interfaz grafica principal es orientada a la Web. documentando este proceso. obteniendo una Guía de Conceptos.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 1.3. El desarrollo del sistema seguirá una metodología de desarrollo iterativa e incremental: RUP [3]. mejores prácticas y tecnologías asociadas a la arquitectura SOA para posteriormente procesar la información y obtener un documento final. mediante un Análisis de Literatura [11]. para luego desarrollar un Sistema de Gestión Documental bajo esta arquitectura.1 Ruta de Solución Fuente: Elaboración Propia Planificación de Actividades del Proyecto 5 . Abordaje o ruta de solución del problema Para resolver el problema identificado se pretende realizar un estudio en profundidad y una experimentación práctica de la Arquitectura Orientada al Servicio. Finalmente se demuestran los conceptos y principios del desarrollo de Aplicaciones Orientadas al Servicio implementando un Bus de Servicios Empresarial (ESB) [13]. Fig. y finalmente para implementar los servicios hace uso de Servicios Web [15]. La información se almacena en formato XML [18]. como servidor utiliza Tomcat [16]. 1. tomando en cuenta que dentro de sus fases se hace un análisis y diseño orientado al servicio [5] siguiendo la estrategia top-down para ciclos de vida de entrega SOA [4].

bajo la arquitectura SOA.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 1. Objetivos Específicos  Elaborar un documento que contenga la base teórica y los pasos a seguir para implementar y desarrollar aplicaciones bajo una Arquitectura SOA. Objetivos del Proyecto a.4.  Definir un contexto de ejecución SOA (ESB) [6] cuya función sea proveer una virtualización de los recursos de la empresa. permitiendo a la lógica de negocio de la empresa ser desarrollado y manejado independientemente de la infraestructura y de la provisión de esos servicios de negocio.  Definir la “Arquitectura de Referencia SOA” que plasme los distintos componentes de la solución SOA. Objetivo General Realizar un estudio de los aspectos conceptuales. Planificación de Actividades del Proyecto 6 . Esta Arquitectura de Referencia se define de acuerdo a las necesidades de la institución. b. y una experimentación del proceso de definición e implementación de una arquitectura SOA que sea flexible para permitir la integración de diversos servicios o aplicaciones mejorando el intercambio de información y adaptándose a los cambios constantes en los nuevos requerimientos dentro de los sistemas de la USFX y se ajuste a los requerimientos de dicha institución.  Desarrollar un Sistema de Gestión Documental -como Caso de Estudio Práctico. que automatice los procesos de registro y seguimiento (flujos de trabajo) de documentos en papel que son procesados por las diferentes unidades de la USFX ajustándose a las políticas que sigue la organización  Definir procesos de negocio en conformidad al caso de estudio y que estarán compuestos de actividades que serán luego implementadas por los servicios de negocio. principalmente Procesos de Negocio y Servicios y muestre cómo van a interactuar estos componentes.

 Poner a prueba el Sistema de Gestión Documental sobre la arquitectura SOA durante un mínimo de dos meses. requerimientos.  Implementar servicios como mecanismos para acceder a una o más capacidades o funcionalidades requeridas que usen interfaces estándar [19] y estén de acuerdo con las políticas y limitaciones definidas por la descripción de servicio  Implementar Gobernancia SOA [9] mediante la definición de políticas de regulación de servicios. etc. solo se considera una implementación a través de Servicios Web. compuestos de varios elementos como ser interfaz de servicio.  No se instalan redes de computadoras ni equipos de computación.  Solo se utilizan las herramientas que se adecúen a las necesidades de la USFX dentro de las muchas existentes en una SOA. ajustándose a lo establecido por el Modelo de Referencia SOA de OASIS [15]. Planificación de Actividades del Proyecto 7 . contrato de servicio [13]. responsabilidades y dueños. Delimitaciones  Si bien puede haber otras formas de implementar una arquitectura SOA. corrigiendo todos los errores detectados de manera que esta cumpla con todas las especificaciones y requisitos de la institución.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX  Definir modelos de descripción de servicio [14]. funcionalidad. información semántica.  Si bien se hace un estudio sobre herramientas basadas en software propietario solo se consideran y utilizan herramientas open source. que establezcan limitaciones técnicas. documentando todo el proceso. etc. incluyendo identificación de roles. c. pues se emplea la red y equipos existentes dentro de la USFX.

mejorar su eficiencia operativa y su velocidad de reacción. que se utilizan como referencia y bibliografía. Justificación del proyecto a. Justificación Operativa La implementación del proyecto constituye un aporte que beneficia al personal de DTIC.  La institución para la cual se realiza el proyecto tiene interés en el desarrollo del mismo y brinda toda la información que se requiera para la correcta formulación del modelado del negocio.5. brindándoles información sobre el uso de soluciones de “Arquitectura Orientada a Servicios (SOA)”. se dispone de la información necesaria y suficiente existente en internet y algunos otros documentos escritos. b. desarrollo y culminación exitosa y garantizada de la investigación. Suposiciones  Para el estudio. facilita el re uso del software.  La institución proporciona el entorno adecuado necesario para la implementación exitosa del caso de estudio. como una herramienta trascendente para lograr incrementar su productividad. mejora la consistencia de datos y la calidad eliminando procesos y almacenes de Planificación de Actividades del Proyecto 8 . Justificación Tecnológica La implementación de un sistema bajo una Arquitectura Orientada al servicio. constituye un gran aporte tecnológico ya que se convierte en un ejemplo práctico que muestra cómo implementar SOA. aporte que adquiere mayor relevancia si se toma en cuenta que este nuevo modelo de arquitectura extiende la vida de las aplicaciones legadas.   La institución cuenta con redes ya implementadas a nivel con acceso a internet. y sirve como la columna vertebral para los procesos de negocio y aplicaciones compuestas. La institución cuenta con al menos una PC Servidor donde se debe implementar el software necesario y la arquitectura propuesta SOA 1.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX d.

económica. reales. Entre los tipos de investigación usados están la investigación aplicada [90]. Metodología de Investigación El método utilizado en la investigación y desarrollo del proyecto es el Método Científico [11].Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX datos redundantes [21]. para recopilar otra información necesaria se recurrió a técnicas como la encuesta [2]. demostrando que realmente posee las ventajas propuestas. de tal manera que la solución queda validada y comprobada. Planificación de Actividades del Proyecto 9 . Luego se dio paso a la Implementación [10] de la solución propuesta. 1. Diseño Metodológico 1. que es la que se realiza para conocer la realidad social. que debería ser tomada en cuenta por los Ingenieros de Sistemas. Como siguiente paso se identificaron los instrumentos y medios a través de los cuales se efectuó el método entre los cuales se usó el Análisis de Literatura [10].6. flexibles. más seguras y manejables para gestionar procesos de negocio críticos a medida que evolucionan o cambian las necesidades del negocio-. que comprende el cuestionario [2] y la entrevista [2]. se comenzó con el diseño de preguntas de investigación relativas al área con el propósito de proveer las respuestas correspondientes. política. a los profesionales de la DTIC del área de interés. Es por lo tanto una alternativa seria. para tener un conocimiento en profundidad del área de investigación. y por las organizaciones o empresas al momento de decidir la arquitectura más conveniente sobre la cual implementar sus sistemas.1. y la investigación exploratoria [90] que se efectúa cuando el objetivo es examinar un tema o problema poco estudiado que no ha sido abordado antes. al momento de desarrollar aplicaciones -para hacerlas más productivas. tecnológica y cultura de su ámbito y plantear soluciones concretas. factibles y necesarias.6.

1.2.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 1.6. procesada Documento final ACTIVIDAD ETAPA DE INVESTIGACIÓN Buscar y Recolectar Información Fuente: Elaboración Propia Planificación de Actividades del Proyecto 10 .6. Metodología de Ingeniería 1. Investigación Tabla 1. extraída Documento con la inf.3.3.1 Planificación de Actividades de Investigación DÍAS 19 6 PRODUCTO Documento con la base teórica Documento con referencias bibliográficas encontradas Seleccionar y clasificar la información Extraer y obtener información Analizar y procesar la información Presentar la información 3 3 4 3 Documentos Organizados y Clasificados Documento con la inf. Gestión de proyecto 1.6.

2 Planificación de Actividades de desarrollo del Sistema Días PRODUCTO Arquitectura de referencia ACTIVIDAD ITERACIÓN I 28 SOA y candidatos de servicio definidos Inicio Determinar la naturaleza y el ámbito de las solución basada en el servicio en el contexto de la empresa Definir el contexto de ejecución SOA a utilizar Identificar los candidatos de servicio y artefactos 9 3 2 3 Documento con la visión de la solución orientada al servicio ESB definido Servicios identificados Arquitectura Primitiva SOA implementada Modelo de procesos Modelo de procesos con el ámbito definido Servicios identificados Bus de Servicios implementado Bus de Servicios Empresarial ya existentes Elaboración Elegir los servicios candidatos a usar e identificar procesos y funcionalidad de la aplicación Determinar el ámbito de los procesos identificados 20 4 1 Identificar servicios o componentes ya desarrollados Implementar el ESB ITERACIÓN II Elaboración Especificar descripción de servicios Construcción Configurar el ESB de acuerdo al contexto de la USFX Desarrollar la interfaz principal del sistema ITERACIÓN III 2 13 21 7 Documento con la descripción de servicio 7 7 29 ESB configurado Interfaz definida Servicios Implementados Referencias Bibliográficas 11 .Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 1.6.3.2. Desarrollo del caso de estudio Tabla 1.

2 ACTIVIDAD Construcción Planificación de Actividades de desarrollo del Sistema Días PRODUCTO Implementar interfaces de servicio Codificación de los Servicios Configuración avanzada del ESB Implementar la interfaz central de la aplicación ITERACIÓN IV Construcción Codificación de Servicios Implementar gobernancia de los servicios Pruebas de los servicios Desplegar los servicios Integrar la interfaz principal con los servicios ITERACIÓN V Transición Pruebas del sistema integrado (Sistema de Gestión Documental) Administración y monitoreo de los servicios 5 10 4 10 26 Interfaces de servicio Servicios Codificados ESB configurado Interfaz principal implementada Servicios integrados con la interfaz principal 7 4 3 4 8 60 Servicios Codificados Modelo de Gobernancia Servicios individuales probados Servicios desplegados Integración realizada Sistema documental de Gestión 30 30 Sistema validado y probado Niveles de servicio verificados Fuente: Elaboración Propia Referencias Bibliográficas 12 .Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Tabla 1.

es que la tecnología de computación y los sistemas se han vuelto mucho más complejos. Mientras esto es bueno en términos de competitividad y precio. Referencias Bibliográficas 13 . por extensión. El propósito fundamental de la arquitectura de software es ayudar a administrar la complejidad de los sistemas de software y las modificaciones que inevitablemente sufren los sistemas en respuesta a cambios externos en el entorno de negocio. La arquitectura de software es la descripción de un sistema de software en términos de sus componentes más importantes. la arquitectura es un plan para construir sistemas que satisfacen requerimientos biendefinidos y. las formas en que esas tecnologías son utilizadas. y la multitud de alternativas disponibles como soluciones para un negocio dado crecen cada año. Arquitectura de Aplicación Hace 20 años. el concepto de arquitectura no estaba bien definido.1. Lo bueno es que se tiene muchas alternativas y opciones para resolver un problema. se ha escrito mucho sobre el valor de la práctica de una arquitectura empresarial. entendido o comunicado.7. Desde los principios de la computación multiplataforma. organizacional y técnico. y la información que pasa entre ellos. MARCO TEÓRICO CONCEPTUAL 1. El resultado es que literalmente hay miles de formas en que la tecnología puede resolver una necesidad de negocio.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 2. y la razón de esto. Marco teórico del dominio del problema 1. y sin una arquitectura se termina implementando diferentes formas de resolver diferentes instancias del mismo problema [41]. En esencia. Los avances en las tecnologías de computación forzaron el concepto debido a complejidades no manejadas en las Tecnologías de la Información (TI) que causaban un impacto en la eficiencia y costo. sistemas que poseen características necesarias para satisfacer esos requerimientos ahora y en el futuro. Los sistemas ya no eran percibidos como “Cajas Negras” mágicas y la participación del negocio no estaba limitada a los requerimientos de negocio. La cantidad de tecnologías. sus relaciones.7. es malo en términos de complejidad y sobrecarga.

  La composición de estos elementos en sub sistemas más grandes El estilo arquitectural que guía a la organización.2. colaboraciones y su composición.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Una definición de arquitectura de software del libro The Rational Unified Process – An intrroduction por Booch y Krutchen (1999) dice: La arquitectura de software abarca las decisiones relevantes sobre:   La organización de un sistema de software La selección de los elementos estructurales y sus interfaces a partir de las cuales se compone el sistema. Otra definición tomada de IEEE Std 1472000. es ejecutado por humanos y/o sistemas para lograr una meta de negocio” [32] La definición muestra algunos puntos importantes: Referencias Bibliográficas 14 . estos elementos y sus interfaces. no sabes lo que estás haciendo” Una definición común es: “Un Proceso de Negocio es una secuencia de tareas que ocurren en un orden definido.7. Edwards Demming. y los principios que guían su diseño y evolución. 1. fundador del movimiento de calidad dice: “Si no podemos describir lo que estás haciendo como un proceso. La mayoría de las definiciones están de acuerdo en que la arquitectura describe la composición de los sistemas. dice “La arquitectura es la organización fundamental de un sistema enfocada en sus componentes. Proceso de Negocio Proceso de Negocio significa una colección de actividades de negocio que toma una o más clases de entradas y crea una salida que es de valor al negocio. Una cita de W. relacionas entre ellos. y el entorno. pero difieren en la perspectiva de lo que es un sistema y que implica la composición.

Los sistemas por otra parte. a menos de que ocurran cambios en las metas de negocio. En el mundo real una tarea puede ser: Firmar un contrato. Gestión de Procesos de Negocio (BPM) Se llama Gestión de procesos de negocio (Business Process Management o BPM en inglés) a la metodología empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio. o cuando la acción es necesaria. cuando se les asigna una tarea.7. Los humanos son lentos. etc. Deben ser descritas con un verbo y un nombre que representa el lugar donde está siendo aplicada la acción. También se puede notar que la secuencia no es realizada por una persona. esta debe esperar que el humano la realice. La automatización de los procesos reduce errores. Como su nombre sugiere. asegurando que los mismos se comporten siempre de la misma manera y dando elementos que permitan visualizar el estado de los mismos. A través del modelado de las actividades y procesos puede lograrse un mejor entendimiento del negocio y muchas veces esto presenta la oportunidad de mejorarlos. pagar una factura. 1. calcular un descuento. solo ejecutan la acción lo más rápido que pueden. Algo importante es que la secuencia no cambia. hay un tipo de interacción entre un grupo de personas.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX  “tarea”: Una tarea es un tipo de actividad en la compañía.  “Lograr una meta de negocio”: Es la meta principal del trabajo. y optimizar de forma continua. llenar un formulario. BPM se enfoca en la administración de los procesos del negocio.3. Este tipo de secuencia en escenarios reales puede ser vista como: Comprador compra un ítem -> Comprador paga la factura -> Enviar la orden al comprador. automatizar. restaurar un archivo. y la obtención de Referencias Bibliográficas 15 . que contribuye para la obtener y completar una meta de negocio. contratar un empleado.  “ejecutado por humanos y/o sistemas”: Aquí se ve quién realiza estas actividades. atómica en contexto.  “secuencia”: La secuencia demanda un orden lógico en el que las acciones deben ser ejecutadas. La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente. revisar un documento. que se deben modelar.

Aplicaciones empresariales Una “aplicación empresarial” es la automatización de un proceso de negocio. Debido a la sobrecarga de costo y tiempo. El proceso de automatizar procesos de negocio y funciones de negocio significa:   Mejorar la productividad de los trabajadores y la calidad y consistencia de su trabajo Guardar datos en forma electrónica para que pueda ser convertido en información. o la automatización de funciones de negocio. 1. En el pasado.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX información que luego puede ser usada para mejorarlos. Cuando el uso de estas aplicaciones de negocio estaba limitado a un número pequeño de personas que eran las únicas que manejaban estas funciones y procesos.7. El propósito no solo es soportar los procesos y funciones de negocio de la aplicación sino también hacer los datos disponibles para producir información valiosa y otras funciones y proceso de negocio automatizados para otros negocios y unidades a lo largo de la empresa. era replicar los datos necesarios y duplicar la lógica necesaria para proveer este subconjunto de capacidades en aplicaciones nuevas y separadas. Referencias Bibliográficas 16 . el enfoque tradicional que requería que los usuarios tengan acceso a varias aplicaciones y conocimiento de múltiples interfaces de usuario para efectuar una actividad de negocio. la mayoría de las veces la forma en que encaraban la necesidad de información a lo largo de múltiples aplicaciones de negocio fue a través de la inclusión de un humano en el proceso. el modelo adoptado. no había necesidad de descomponer estas aplicaciones y modularizar sus capacidades. Desafortunadamente. era plausible. Este era un enfoque costoso y que tomaba mucho tiempo. Estos enfoques todavía se usan hoy en día. y actuar sobre las mismas para optimizarlos.4. No había necesidad de exponer subconjuntos de funcionalidades de aplicación para que puedan ser accedidas y usadas por una audiencia mayor de usuarios o de una forma diferente. que se puede identificar posibles ineficiencias en los mismos. Era plausible porque la compañía controlaba el usuario (empleado) y tenía el compromiso y el tiempo de capacitar a los empleados para navegar y usar todas las aplicaciones de negocio necesarias. cuando esta necesidad surgió. Es a través de la información que se obtiene de la ejecución diaria de los procesos.

5. [42] Una integración punto a punto ocurre cuando una aplicación depende de otra. Por ejemplo en la figura. Como resultado. las aplicaciones individuales son integradas directamente con otra de una forma punto-a-punto.7. porque una aplicación depende de otra para funcionar correctamente. La habilidad de servir al cliente externo estaba basada en una combinación de varios sistemas usados por la compañía. la interacción con el cliente externo requería acceso a información o al procesamiento de una transacción que no era realizado por el empleado que lo atendía [36]. Integraciones punto a punto Fuente: (42) Referencias Bibliográficas 17 .Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Estas complejidades eran ocultadas al cliente externo.1. Se dice que la aplicación CCM “sabe” sobre la aplicación “Sistema de Facturación”. <<componente>> Administrador de Contactos y Clientes Facturación Facturación usa ACC <<componente>> Sistema de Facturación Fig 2. y sus diseños e implementaciones reflejan directamente este pensamiento. Esto tipo de relación también se la conoce como dependencia. la aplicación de “Administrador de Contactos y Clientes” (ACC) usa la interface Sistema de Facturación. Los desarrolladores y arquitectos frecuentemente piensan en términos de aplicaciones de software individuales. Integración Punto a Punto El desarrollo de software hoy en día es orientado al proyecto. Sin embargo. 1.

Tener ciertos sistemas de software duplicados o tener un gran número de sistemas de software es muy común.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX La figura ilustra un entorno trivial. Cuando el departamento de Tecnologías de la Información es pequeño. IO usa SF AC usa SF <<componente>> Sitio Web Atención al Cliente Sitio Web usa AC <<componente>> Atención al Cliente (AC) AC usa IO AC usa CP AC usa SI AC usa SI SF usa AC <<componente>> Sistema de Facturación (SF) <<componente>> Administrador Contactos y Clientes (ACC) ACC usa SF <<componente>> Ingreso de Ordenes (IO) <<componente>> Catálogo de Productos (CP) <<componente>> Sistema de Precios (SI) <<componente>> Servicio de Inventario (SI) Fig 2. Para ser claro. grandes compañías pueden adquirir otras más pequeñas (por tanto adquieren el software de la compañía más pequeña) más rápido de lo que pueden integrar estos nuevos sistemas adquiridos.2. la integración punto a punto es fácil de manejar. Ahora la empresa tiene 8 sistemas de software y un total de 11 puntos de integración. La figura 2 expande un poco el problema. El segundo punto de integración permite a la aplicación de Sistema de Facturación llamar al sistema ACC. la primera integración permite al sistema ACC llamar a la aplicación de Sistema de Facturación. Esto ilustra un patrón común en integración: el número de puntos de integración crece más rápido que los sistemas que integramos. Integraciones punto a punto de 8 sistemas Fuente: (42) Referencias Bibliográficas 18 . con solo dos aplicaciones y dos integraciones punto a punto.

El enfoque cascada para el desarrollo de software fue diseñado con la idea de que construir una pieza de software es como construir un puente: mientras mejor sea el diseño y el anteproyecto. Metodologías de desarrollo de software y su evolución Las metodologías de desarrollo de software tradicional deben mucho a las raíces de su ingeniería. En la realidad. El problema con el enfoque en cascada. Entonces los requerimientos de negocio son necesariamente un objetivo cambiante. Aquí es donde las capas de los usuarios finales. Esta disonancia de requerimientos se muestra en la figura: Interpretación Requerimiento Interpretación Interpretación Interpretación Software final Usuario Final Analista de Negocio Desarrollador Fig. Los negocios no pueden permanecer estables: si no se adaptan al mercado y los cambios necesarios estos no sobrevivirán. este enfoque está muy lejos de la perfección. Cada eslabón en la cadena pone su propia interpretación del requerimiento.6. hasta que el resultado final es diferente de lo que el negocio originalmente necesitaba.7. Existe también el problema de la “disonancia” de los requerimientos de negocio. los requerimientos de negocio están sujetos a cambio. y el negocio expresa ese valor como un conjunto de requerimientos de negocio. Desarrollar aplicaciones empresariales se trata de entregar valor a un negocio. 2. analistas y desarrolladores crean una cadena de susurros chinos []. mejor será el resultado. resultando en software que falla en satisfacer el requerimiento original. es que a diferencia de las leyes de la física y las propiedades de la construcción de metal y concreto. Desafortunadamente.3 Disonancia en los requerimientos Referencias Bibliográficas 19 .Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 1. este no es el único problema de las metodologías de desarrollo de software tradicional. y su comparación con la construcción de un puente.

y creando prototipos tempranamente. el enfoque tradicional en cascada para el desarrollo de software ha sido remplazado por otras metodologías más adaptables. 2.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fuente: (36) Hoy en día. Estas metodologías intentan eliminar la disonancia de requerimientos tratando de eliminar el hombre en el medio donde sea posible. el desarrollo ágil todavía tiene serias desventajas y limitaciones. para luego iterar hasta la versión final. Esta es una desventaja importante ya que casi siempre la interpretación del Analista de Negocios es más lógica y con vistas a futuro que la del Usuario Final que especifica el requerimiento original. También Referencias Bibliográficas 20 . A pesar de eso. Esto puede llevar al desarrollador a callejones sin salida gracias a un Usuario Final que no tiene la perspectiva necesaria. Aplicada al proyecto correcto. el desarrollo Ágil puede entregar software de valor más rápido y de manera más eficiente que el enfoque en cascada. Metodología ágil Fuente: (36) Lo más destacado de estas mejoras es la metodología “Ágil”.4. la más obvia es que elimina al Analista de Negocios. Esto permite un enfoque iterativo para el desarrollo de software con mejoras: Comparación Software final Interpretación Requerimiento Usuario Final Interpretación Interpretación Desarrollador Fig.

Referencias Bibliográficas 21 . puede entregar exitosamente software de valor en periodos de tiempo muy cortos. y aunque los lenguajes de programación son cada vez más simples. BPM se basa en eliminar el hombre en el medio donde sea posible. las que se dejan son las que causan mayor disonancia: el desarrollador todavía tiene que interpretar que quiere decir el Usuario Final. Una situación ideal sería una donde los Usuarios de Negocio puedan construir el software que necesitan ellos mismos. solo que esta vez el énfasis está en una alianza entre el Usuario Final y el Analista de negocio que trabajan en iteraciones para lograr el software final. y en el escenario correcto. sin tener que usar a los desarrolladores y analistas. BPM avanza un poco hacia este ideal. Desafortunadamente. aún estamos a años luz de que esto suceda.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX está el problema de que aunque se eliminan capas de interpretación. De forma parecida a la metodología Ágil. Sin embargo. Entonces aparece el concepto de Administración de Procesos de Negocio (BPM). Esto lleva a pérdida de tiempo en la realización de un prototipo que comienza muy lejos de lo que el negocio necesita.

La realidad del desarrollo BPM es que hace la relación entre el Usuario. para que los modelos de procesos de negocio estén más cerca al requerimiento original. permitiendo colaboración más cercana y un desarrollo más rápido. este es un método extraordinariamente rápido para desarrollar software.  Los modelos usualmente pueden ser producidos más rápido que el software. 2. pero no hace redundantes estos roles.5. Metodología BPM Fuente: (36) El reintegro del Analista de Negocio tiene ciertas ventajas:  El Analista de negocio es entrenado en la interpretación de requerimientos. el Analista de Negocio y el desarrollador más simbiótica y productiva. Esto no significa que los desarrolladores ya no son requeridos.  Los modelos de los Analistas de Negocio son mucho más fáciles de entender por un Usuario Final que el código o un prototipo de software. Referencias Bibliográficas 22 . y por otra entre el Analista de Negocio y el Desarrollador. BPM es un enfoque de colaboración para el desarrollo de software.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Generación Requerimiento Interpretación Interpretación de Software Requerimiento Usuario Final Analista de Negocio Modelado Comparación Requerimiento Modelado Fig. Debido a que el software producido por un sistema BPM es inicialmente generado del modelo de proceso del Analista de Negocio. Las capacidades del desarrollador son necesarias para poder implementar el sistema BPM. por una parte entre el Usuario Final y el Analista de Negocio.

Ingeniería de Sistemas

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX

1.7.7. Integración de Aplicaciones Empresariales El término Integración de Aplicaciones Empresariales (EAI) se ha vuelto popular con el crecimiento de la importancia de la integración, y con proyectos de integración más extensos. EAI no es un producto o un framework de integración específico, pero puede ser definido como la combinación de procesos, software, estándares, y hardware que permiten la integración punto-a-punto de varios sistemas empresariales, y les permiten parecerse a un solo sistema (Lam, Shankaranaman 2007) [30] El uso de EAI significa compartimiento sin restricciones de datos y procesos de negocio entre cualquier aplicación conectada (Linthicum 200) Desde una perspectiva de negocio, EAI puede ser visto como la ventaja competitiva que adquiere una compañía cuando todas sus aplicaciones son integradas en un solo sistema de información consistente. Desde una perspectiva técnica, EAI es el proceso en el que aplicaciones heterogéneas, funciones y datos son integrados, para poder permitir el uso compartido de datos y la integración de procesos de negocios a lo largo de todas las aplicaciones. El propósito es lograr este nivel de integración sin grandes cambios a las aplicaciones existentes y bases de datos, usando métodos eficientes que sean efectivos en cuanto a costo y tiempo. EAI está enfocado principalmente en la integración técnica de una aplicación. Los productos middleware son usados como herramientas de integración, pero, donde sea posible, el diseño e implementación de las aplicaciones quedan sin cambios. Los adaptadores permiten a la información y datos ser transportados a lo largo de estructuras heterogéneas y fronteras. El concepto de servicio no existe, así como la reducción de complejidad y redundancia. El concepto de servicio y estandarización solo vino más tarde con la emergencia de la Arquitectura Orientada al servicio (SOA), que remarcó la importancia de enfocarse en niveles funcionales dentro de la compañía, y sus procesos de negocio.

Referencias Bibliográficas

23

Ingeniería de Sistemas

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX

1.8. Referencia a proyectos similares
 Adeyinka Oluwaseyi. “Service Oriented Architectura & Web Service – Guidelines for Migrating from Legacy Systems and Financial Consideration”. Master Thesis de Blekinge Institute of Technology, Suecia, Enero 2008. En esta tesis se presentan directrices que pueden ser seguidas en lo referente a una Arquitectura Orientada al servicio a través del uso de Servicios Web, además identifica mejores prácticas para la implementación de SOA y los pasos para migrar exitosamente sistemas legados a sistemas orientados al servicio.  Jenny Franzen. “Factors to Succeed With SOA”. Tesis de Maestría en Informática para IT University of Goteborg. Suecia, 2008.

El propósito de esta tesis es de compartir experiencias de organizaciones que han adoptado SOA, para aprender cuales fueron los factores esenciales para tener éxito con ese enfoque arquitectural. En resumen el propósito de la tesis es responder a la pregunta de investigación “Qué factores son esenciales para tener éxito con SOA?”  Selda Guner. “Architectural Approaches, Concepts and Methodologies of Service Oriented Architecture”. Tesis para el Software System Institute Technical University Hamburg Harburg. Hamburgo, Alemania. Agosto, 2005

Esta tesis describe SOA a detalle considerando todos los enfoques, conceptos y metodologías que competen al modelo arquitectural de SOA. El desarrollo de aplicaciones basadas en el servicio, enfoques de integración, tecnologías para el desarrollo de SOA, frameworks y otros requerimientos son tratados en este estudio para lograr una figura exacta de SOA.

1.9. Marco teórico de ingeniería
1.9.1. Antecedentes y evolución de la Arquitectura de Software Las empresas y negocios fueron las primeras en adoptar las tecnologías de cómputo fuera de los establecimientos gubernamentales y militares. Grandes empresas invirtieron en varias partes del negocio –desde terminales Punto de Venta (POS) a computadoras Mainframe.
Referencias Bibliográficas 24

Ingeniería de Sistemas

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX

Inicialmente los mainframes proveían una arquitectura Centrada en el Modelo para administrar los datos de negocio y proceso. El concepto de arquitectura de software evolucionó cuando las empresas empezaron a adoptar computadoras y redes para compartir recursos. La necesidad de desacoplar estos sistemas y aplicaciones en entornos pequeños de red, resulto en lo que se conoce como una de las arquitecturas más importantes: cliente/servidor. Muchas de las arquitecturas que evolucionaron más tarde fueron influenciadas por esta arquitectura. La evolución de las arquitecturas distribuidas puede ser considerada una extensión de la arquitectura cliente/servidor. Claramente, el Interne y la World Wide Web causo el cambio en la naturaleza y la forma en las transacciones se realizan. Estos desafíos y oportunidades han causado que la arquitectura sea gobernada por requerimientos no funcionales de las empresas. Algunos de los requerimientos no funcionales incluyen desempeño, confiabilidad, disponibilidad y seguridad. Las empresas evolucionan constantemente, así también como las Tecnologías de la Información. Explicamos esta evolución como progresión, y podemos dividirlas en dos: Progresión de la Arquitectura del lado del servidor y Progresión de la Arquitectura de lado del Cliente. 1.9.2. Evolución de la Arquitectura de lado del Servidor Algunos eventos significantes en el lado del Servidor llamados eras incluyen los siguientes:     Era de mainframe Era de cliente/servidor Era distribuida Era de Internet

La figura 2.5 muestra la vista conceptual de la progresión de las arquitecturas de lado del cliente a lo largo del tiempo. Todas las arquitecturas evolucionaron y coexistieron con otras. Los sistemas mainframe dominaron en su respectiva era, pero aún están presentes en la era de Internet. Ninguna de estas arquitecturas desapareció por completo. Esto puede ser atribuido al Retorno de Inversión (ROI), dependencia del vendedor, etc. Es importante notar que las
Referencias Bibliográficas 25

Ingeniería de Sistemas

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX

nuevas tecnologías necesitan ser integradas con sistemas existentes. Estos sistemas son llamados “Sistemas Legados” [33].

Fig. 2.6. Progresión en las arquitecturas del lado Servidor Fuente: (33) 1.9.3. Progresión de la Arquitectura Mainframe Inicialmente, las computadoras mainframe dominaban las Tecnologías de la Información. Compañías como IBM y Digital dominaron el escenario por un gran periodo. Los sistemas Mainframe eran grandes, caros y solo podían ser adquiridas por corporaciones de gran o mediano tamaño. Estos sistemas representaban el músculo del hardware. Los sistemas mainframe eran esencialmente de una sola capa; la arquitectura era llamada Modelo Centralizado, y las aplicaciones eran ejecutadas en el CPU del mainframe. Este sistema estaba conectado a varias terminales que actuaban como conducto para la entrada/salida entre el sistema mainframe y el usuario. Estos sistemas mainframe eran conectados también a otros periféricos como impresoras, unidades de disco, lectores de tarjetas, etc. Vale la pena mencionar que algunas versiones de sistemas de mainframe no tenían ni siquiera consolas o terminales. Los lectores de tarjetas eran usados para ingresar los trabajos por lotes, y las impresoras eran usadas como la salida de estos sistemas.
Referencias Bibliográficas 26

7 muestra el modelo centralizado de la arquitectura mainframe. Sin embargo. Muchos fabricantes de mainframe vendían aplicaciones utilitarias que estaban disponibles para todos los usuarios del sistema mainframe. Estas aplicaciones utilitarias eran provistas en forma de sub rutinas. Modelo Centralizado de la Arquitectura Mainframe Fuente: (33) El sistema mainframe soportaba una memoria principal en la que la aplicación era cargada para su ejecución.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX La figura 4. Organizaciones como el Referencias Bibliográficas 27 .7. Figura 2. (5) Las subrutinas eran esencialmente algoritmos matemáticos codificados en un lenguaje de programación como FORTRAN. La memoria secundaria de estos sistemas almacenaban las aplicaciones de los usuarios. Una colección de esas sub rutinas era conocida como una librería. Cualquier individuo interesado en usar este servicio necesitaba llamar a la sub rutina apropiada desde su entorno de programación. estas aplicaciones estaban atadas completamente al sistema mainframe y podían ser usadas solo dentro de unos límites impuestos por el mainframe. El sistema se encuentra conectado a varias terminales.

la aplicación (y datos) y las interfaces de usuario podían manejar dos sistemas de manera diferente. 1. Los sistemas mainframe han sido el backbone de muchas grandes empresas por mucho tiempo. Estas sub rutinas proveían una variedad de servicios para empresas. El desarrollo de la arquitectura cliente/servidor siguió de cerca la aparición de computadoras más pequeñas y baratas como las microcomputadoras. minicomputadoras. International Mathematics and Statistics Library (IMSL). La posibilidad de poner en red esos sistemas dentro de la organización proveyó la base para la aparición de la arquitectura de dos-capas. ingenieros.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX “Numerical Algorithms Group (NAG). estos sistemas más pequeños eran asequibles para las Medianas Y Pequeñas Empresas. etc.8 muestra el concepto simplista de la arquitectura cliente/servidor. Progresión de la Arquitectura Cliente/Servidor El término cliente/servidor corresponde a un modelo de computación donde las aplicaciones cliente corriendo en una computadora personal acceden a información en servidores remotos. IBM Corporation proveyó varias sub rutinas relacionadas con el negocio que podían ser usadas por las aplicaciones apropiadas para llevar a cabo tareas de negocio como ordenar.4. y estaciones de trabajo. Referencias Bibliográficas 28 .9. Mientras el sistema servidor podía almacenar aplicaciones y datos. el sistema cliente podía manejar la interacción con el usuario. En esta arquitectura. científicos. Al contrario de lo que ocurría con los sistemas mainframe. mientras que la porción servidor provee un acceso centralizado y funcionalidad multi usuario. indexar. etc. La arquitectura cliente/servidor apareció a finales de 1970. y muchas aplicaciones desarrolladas en esos sistemas mainframe todavía son consideradas relevantes hoy en día. proveyeron sub rutinas en una variedad de sistemas mainframe. La figura 2. La porción cliente de la aplicación esta optimizada típicamente para la interacción con el usuario.

Estos sistemas.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fig. y las aplicaciones de acceso a datos eran ejecutadas en el sistema servidor. Una representación simple de la Arquitectura cliente/servidor Fuente: (33) A mediados de 1998 las computadoras de escritorio hicieron una revolución. conocidos como Computadoras Personales (PC).  La lógica de aplicaciones de negocio podía ser ejecutaba en el servidor o el cliente Referencias Bibliográficas 29 . La proliferación de las PC proveyó un entrono cliente ideal para la arquitectura cliente/servidor. 2. El entorno de red de dichas computadoras brindó facilidades de cómputo de negocio a un costo aceptable para el SMB. podían ser adquiridos por individuos y profesionales.8. La asequibilidad de computadoras pequeñas junto con el éxito de la arquitectura cliente/servidor se atribuye a algunas razones incluyendo:    La arquitectura era simple Las aplicaciones con interfaz se ejecutaban en el sistema cliente Los datos residían en el servidor.

Distributed Network Architecture (DNA) de DEC. En las arquitecturas distribuidas. los sistemas más potentes. Por tanto. Contribuyeron enormemente al gran crecimiento de las computadoras de escritorio. por tanto. Progresión de la Arquitectura Distribuida La arquitectura distribuida proveía un entorno en el que las aplicaciones podían ser divididas y distribuidas entre varios sistemas en un entorno de red. etc. El éxito de la arquitectura cliente/servidor fomentó a muchas grandes empresas a diversificar sus recursos de sistema y reducir dependencias en sistemas inflexibles y caros tales como los mainframe. la disponibilidad de una variedad de aplicaciones.9. la arquitectura distribuida. ninguna aplicación tiene un rol privilegiado y un proceso no depende de otro. La arquitectura distribuida porvee múltiples capas para el entorno de cómputo. un ciclo de desarrollo de aplicación relativamente corto. y los sistemas menos potentes proveían un entorno cliente perfecto [33]. en la que hay solo dos capas: cliente y servidor. Permitiendo a las PCs. eran conocidos como servidores para almacenar los datos. podían superar a los sistemas mainframe. Los entornos operativos de estos sistemas distribuidos proveían servicios básicos como compartición de recursos. El entorno cliente/servidor proveía un entorno ideal para los individuos que podían desarrollar una cantidad de programas y aplicaciones. La arquitectura distribuida. y mainframes coexistir. minicomputadoras.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX  El servidor también proveía compartición de recursos para todos los clientes. etc. y los resultados eran combinados para producir el resultado final. Las contribuciones de individuos y profesionales. etc. el costo del sistema. 1. Algunas arquitecturas distribuidas incluyen: System Netowrk Architectura (SNA) de IBM. Estas aplicaciones se ejecutaban en sus sistemas individuales. como las minicomputadoras. Dichos sistemas distribuidos.5. permite a varias computadoras estar en red y que las aplicaciones sean desplegadas de una manera distribuida. Referencias Bibliográficas 30 . la arquitectura cliente fomentó a la empresa a distribuir tareas específicas a sistemas apropiados. impresión. Por ejemplo. La arquitectura cliente/servidor puede ser solo un subconjunto de la arquitectura distribuida. transferencia de archivos. trabajando juntos. no es diferente de la arquitectura cliente/servidor.

9. Este modelo permitía a los sistemas en una red comunicarse en un entorno de arquitectura distribuida. Los siguientes subtítulos explican cómo estos nos ayudan en el desarrollo y despliegue de servicios en una arquitectura distribuida [33]. Referencias Bibliográficas 31 . Llamada a Procedimientos Remotos (RPC) El modelo RPC fue propuesto por Birrel y Nelson a mediados de los 1980 y fue estandarizado por Schroeder y Burrows a finales de 1980.6.9 muestra una representación de cómo los modelos RPC trabajan en un entorno distribuido.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Es importante remarcar que aunque los modelos de arquitectura distribuida propuestos por fabricantes individuales trabajan bien en aislamiento. problemas serios llegaron cuando las empresas necesitaban integrar dos o más redes distribuidas. el Llamado a Procedimientos Remotos (RPC) y la Mensajería representan mecanismos potentes que ayudan a lograr la integración entre diferentes plataformas. Esta incompatibilidad llevó a la industria hacia los sistemas abiertos y la aparición de protocolos de comunicación como TCP/IP. Esto sucedió en empresas que tenían despliegues de múltiples fabricantes en diferentes departamentos. El crecimiento de la arquitectura distribuida tiene cuatro aspectos importantes:     Llamadas a procedimientos remotos Acceso remoto a base de datos Procesamiento de transacciones distribuido Mensajería Entre estos. La figura 2. Diferentes fabricantes implementaron RPC de diferentes maneras. 1.

ActiveX.9. La tecnología COM permite el desarrollo de componentes de software. que permite la comunicación entre objetos remotos. Common Object Request Broker Architecture (CORBA) de Object Management Group (OMG) es una generalización de RPC. El modelo OMG incluía mejoras en el objeto del modelo RPC. y Microsoft Transaction Server (MTS). como Object Linking and Embedding (OLE). CORBA hace posible el desarrollo de aplicaciones y servicios que sean interoperables y puedan comunicarse con otras aplicaciones diferentes. tales componentes pueden interactuar en una manera inter operable. para integrar las aplicaciones en la red. Referencias Bibliográficas 32 . La base de Microsoft Distributed Component Object Model (DCOM) esencialmente emergió del Compontent Model Object (COM) introducido a mediados de 1990. como especificaciones COM. En un entorno distribuido.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fig. se construyen en la cima de las tecnologías COM y DCOM. El Método Remoto de Invocación (RMI) es de las tecnologías Java. 2. Esta arquitectura fue desarrollada por OMG para brindar portabilidad e interoperabilidad a lo largo de diferentes plataformas de hardware y entornos operativos. Otras tecnologías de Microsoft. Esta tecnología fue introducida a finales de 1990. DCOM se construye con la capa RPC. Llamadas a Procedimientos Remotos Fuente: (33) La implementación de Sun Microsystems es Sun RPC.

Con el paso del tiempo. el remitente y receptor no necesitan ejecutarse al mismo tiempo.9. La tecnología de mensajería introduce servidores de mensajes. Arquitectura Orientada al Servicio (SOA) Los conceptos que hoy en día están asociados con SOA comenzaron a surgir con la adopción de internet. y SonicMQ de Progress son algunas implementaciones populares de tecnologías de mensajería. En el Modelo de Comunicación Asíncrono. de diversos fabricantes. introduce comunicación asíncrona a la arquitectura distribuida. Qué es lo que era. Referencias Bibliográficas 33 . En el modelo de Comunicación Asíncrona. interoperables y descubribles. HTTP.9. MOM es una implementación de software en los sistemas distribuidos o cliente/servidor que residen en el lado cliente y servidor. más específicamente. y fue difundido rápidamente. extensible y federada compuesta de servicios potencialmente re usables. autónomos. Roy Schutle de Gartner Group había acuñado el término SOA. exactamente. La mensajería por otra parte. ágil.7. 1. La tecnología de mensajería es conocida como Messaging Oriented Middleware (MOM). la comunicación entre dos aplicaciones se bloquea hasta que el intercambio de mensajes se completa y puede ser comparado con un modelo de comunicación RPC. que pueden entregar o recibir mensajes de aplicaciones. MQSeries de IBM. por tanto incrementando la flexibilidad de la arquitectura distribuida. abierta. El remitente puede enviar mensajes. Las tecnologías de mensajería permiten enviar o recibir mensajes entre dos o más aplicaciones en red en una arquitectura distribuida y puede ser de forma síncrona o asíncrona. aparecieron varias cosas comunes en las diferentes definiciones: “Arquitectura Orientada al Servicio representa una arquitectura componible. El año 2003. Esto permite a los sistemas distribuidos o cliente/servidor comunicarse asíncronamente. MSMQ de Microsoft.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 1. y el mensaje será enviado al receptor cuando este esté conectado al sistema.8. seguía como algo difícil de cuantificar. implementados como Servicios Web. Mensajería Todas las comunicaciones discutidas anteriormente se refieren a un modo de comunicación síncrono o de modo de bloqueo.

Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX SOA puede establecer una abstracción de lógica de negocio y tecnología que puede introducir cambios en el modelado del proceso de negocio y la arquitectura técnica. que trae consigo distintos principios que fomentan la orientación al servicio. [4] “La arquitectura Orientada al Servicio es una estrategia de las Tecnologías de la Información que organiza funciones discretas contenidas en aplicaciones de negocio en servicios inter operables. Cuando es realizada a través de Servicios Web. Ilustración de un entorno SOA.10. resultando en un débil acoplamiento entre estos modelos. SOA es una forma de tecnología de arquitectura que se adhiere a los principios de la orientación al servicio. preservando las características exitosas de las arquitecturas tradicionales. SOA establece el potencial para soportar y promover estos principios a lo largo de los procesos de negocio de una empresa. basados en estándares que pueden ser combinados y re usados rápidamente para satisfacer las necesidades del negocio [BEA]” ESB Adaptadores Procesos de Negocio Orquestados Servicio Servicio Servicio Servicio Servicios Compuestos Transformadores Rou Routers Rou Servicios de Bajo Nivel Mensajería Rou Aplicaciones Empresariales APP 1 APP 2 APP 3 APP 4 Fig 2. SOA es una evolución de las plataformas pasadas. Fuente: (31) Referencias Bibliográficas 34 .

Principios de la Orientación al Servicio   Débil Acoplamiento: Los servicios mantienen una relación que minimiza dependencias. SOA es una partida de los viejos modelos de computación distribuida. definido por una o más descripciones de servicio y documentos relacionados. servicios.   Autonomía: Los servicios tienen control sobre la lógica que encapsulan. Los servicios de bajo nivel (o de fina granularidad) representan la capa de la cima de las aplicaciones empresariales.  Carencia de Estado: Los servicios minimizan la retención de información específica a una actividad. 1. hace énfasis en una afiliación de servicios débilmente acoplados que son autónomos por naturaleza. La capa de servicios compuestos representa servicios de gruesa granularidad que consisten de dos o más componentes. SOA en cambio.9. Estos componentes permiten a las capas inferiores interactuar con estos sistemas. En muchos aspectos. que estaban centrados en el intercambio de objetos distribuidos y funciones remotas.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX La figura 2.  Descubrimiento: Los servicios son diseñados para ser descriptivos para así poder ser encontrados y accedidos a través de mecanismos disponibles de descubrimiento. Abstracción: Mas allá de lo que se describe en el contrato de servicio.9. y procesos de negocio orquestados.2 muestra la relación entre las aplicaciones. Contrato de Servicio: Los servicios se adhieren a un acuerdo de comunicación. Componibilidad: Colecciones de servicios pueden ser coordinadas y ensambladas para formar servicios compuestos. los servicios ocultan lógica del mundo exterior.   Reusabilidad: La lógica se divide en servicio con la intención de promover el re uso. Referencias Bibliográficas 35 .

Servicio Un servicio es un mecanismo que brinda acceso a una o más capacidades. [14] Se puede acceder a un servicio mediante una interfaz de servicio. 2.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Implementa un contrato estándar Contrato de Servicio Estandarizado Débil Acoplamiento de Servicio Minimizar dependencias Implementa lógica re usable Minimiza la disponibilidad de Re usabilidad de Servicio Abstracción del Servicio meta información Implementa frontera independiente y un entorno de ejecución Autonomía de Servicio Componibilidad de Servicio Maximiza la componibilidad Implementa lógica adaptativa y libre de administración de estado Carencia de Estado del Servicio Implementan meta información comunicativa Descubrimiento de Servicios Servicio Fig. Los principios de SOA Fuente: (43) 1.11. donde el acceso es provisto usando una interfaz y es regulado por las políticas especificadas por la descripción del servicio. donde la interfaz tiene las especificaciones para acceder a las capacidades del servicio.9.10. La consecuencia de la invocación de un servicio es la realización de uno o más efectos del mundo real entre ellos: Referencias Bibliográficas 36 .

Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX   Información devuelta en respuesta a una solicitud de esa información Un cambio de estado de entidades definidas El consumidor del servicio en el primer caso no conoce la manera en que se genera la información. [26]. Las interfaces basadas en SOAP interactúan entre ellas mediante mensajes SOAP con formato XML para llevar datos y meta datos. [43] 1. SOAP SOAP es un protocolo de mensajería usado para transferir datos de aplicación en formato XML sobre un protocolo de transporte como HTTP. WSDL. [26] La orientación al servicio puede ser aplicada al diseño de los Servicios Web.9. el Registro Universal de Descubrimiento. Un servicio puede ser considerado como un contenedor de capacidades asociadas con un propósito común. Esquema XML.9. Existen tres implementaciones comunes de servicios: Servicios Web.11. 1. Descripción e Integración (UDDI) y otras tecnologías basadas en XML. Para lograr esto. para proveer un enfoque basado en estándares para sobreponerse a las diferencias de plataforma y lenguaje. los Servicios Web usan SOAP. La estructura de un mensaje SOAP es la siguiente: Referencias Bibliográficas 37 . El hecho de que los Servicios Web proveen un modelo arquitectural ya que el contrato de servicio es independiente de la plataforma. Hoy en día.1. las aplicaciones de Servicios Web usan SOAP como protocolo estándar para el intercambio de información de forma descentralizada y distribuida. Servicios Web Un Servicio Web es una manera de compartir lógica de aplicación a lo largo de varias máquinas corriendo sobre diferentes sistemas operativos y usando diferentes entornos de desarrollo. en el segundo caso no conoce de qué manera se cambió el estado. pudiendo ser extraída de una base de datos o generada dinámicamente. componentes y servicios REST.11. es ideal para el diseño de metas asociadas con la orientación al servicio.

9. ….  La segunda capa define el “binding” o “enlazamiento” de un Servicio Web. eso quiere decir el protocolo y formato para el cual son provistas las operaciones del Servicio Web. Además.  La tercera capa define la ubicación física (dirección.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX <SOAP-ENV:Envelope ` <SOAP_ENV:Header> …. ….... Esta interfaz puede consistir de una o más operaciones con parámetros de entrada y salida que usan tipos especificados en la primera sección del archivo WSDL.2.11. Referencias Bibliográficas 38 .. tienen tres capas de descripción. URL) donde el Servicio Web está disponible. WSDL Una descripción de servicio WSDL es un documento que describe a los servicios de abajo a arriba.  La primera capa describe la interfaz del servicio. Eso significa que empiezan con los tipos de dato usados y terminan con la ubicación (dirección) del servicio. </SOAP:Body> </SOAP-ENV:Envelope> ………> 1. </SOAP_ENV:Header> <SOAP:Body> ….

Usando estos elementos consumidores potenciales de Servicios Web pueden buscarlos.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fig. e Integración )es un estándar para el registro y búsqueda de Servicios Web dentro de directorios – como si fueran páginas amarillas. Descubrimiento. Esquema XML Un mensaje SOAP puede contener cualquier tipo de dato. además de una forma de determinar el tipo de dato que debe aparecer dentro de un mensaje. autor.9.4.11. 2. un proveedor de servicio usa UDDI para almacenar datos del servicio (descripción de servicio. Luego el consumidor potencial puede usar UDDI para ubicar un servicio apropiado.3. Primero. Un Esquema XML es una forma estándar de describir la estructura y el tipo de información que debe estar presente dentro de un mensaje XML Referencias Bibliográficas 39 .12. ubicación y las interfaces para acceder al mismo). La principal función de UDDI es proveer descubrimiento de servicio.9. 1.que contienen Servicios Web. Esto puede ser realizado mediante un humano usando un navegador o programáticamente [45]. Estructura de un documento WSDL Fuente: (44) 1. y se necesita una forma de expresar la estructura de un mensaje. UDDI UDDI (Descripción Universal.11.

Como se muestra en la figura. ya que además de describir las operaciones soportadas por el servicio.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX enviado a un Servicio Web. y detallar cómo el servicio será invocado.9. Bus de Servicios Empresarial En una Arquitectura Orientada al Servicio. Estos mensajes deben ser entregados rápidamente y su llegada debe ser garantizada. todas las piezas de software se comunican entre ellas mediante mensajes. los ESBs son diseñados para actuar como intermediarios entre los componentes SOA. Interfaz de Servicio Los servicios deben tener un contrato o una interfaz bien definida. 1. Este esquema necesita ser estandarizado y estar acompañado por un conjunto de APIs que puedan ser usadas para validar un documento XML contra su esquema. y procesos de negocio.9. Para transportar los mensajes entre los componentes de software es cuando se usa un Bus de Servicios Empresarial (ESB). Referencias Bibliográficas 40 . servicios de infraestructura.13. definir los requerimientos de datos para la información intercambiada.12. Un contrato es la especificación completa de un servicio entre un proveedor de servicio y un consumidor específico. también incorpora un Esquema XML que describe el formato del mensaje XML que será intercambiado. WSDL es un ejemplo de contrato. Debe existir de manera que pueda ser legible por los posibles clientes. Este contrato debe identificar qué operaciones están disponibles. 1. Un ESB es el nervio central de las comunicaciones en una Arquitectura Orientada al Servicio.

y garantizan la entrega de mensajes. 2.13.  Servicios de Interfaz: pueden validar mensajes contra sus definiciones de esquema. Referencias Bibliográficas 41 .  Servicios de Administración: Pueden monitorear su propio redimiendo. ayudando a mejorar los SLAs (Acuerdos de Nivel de Servicio) grabando y respondiendo a la latencia de mensajes.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fig. Bus de Servicios Empresarial Fuente: (6) Los servicios ofrecidos por un ESB son:  Servicios de Mensajería: Soportan varios tipos de mensajería. proveen enrutamiento inteligente basado en contenido. Pueden implementar prioridades de mensajes y aplicar reglas de negocio a lo largo de las aplicaciones o componentes que conectan. Soportan estándares de Servicios Web y proveen adaptadores de aplicación para interfaces que no son del tipo Servicio Web.

El siguiente diagrama ilustra el concepto: Registro de Servicios Encontrar Publicar Solicitante de Servicios Enlazar y ejecutar Proveedor de Servicios Fig.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX  Servicios de Mediación: transforman los mensajes entre formatos usados por aplicaciones que los envían y reciben.14. Publicar. 1.14. Encontrar y Ejecutar servicios Fuente: (45) Referencias Bibliográficas 42 . El solicitante de servicios encuentra la descripción del servicio en el registro y usa la información para enlazarse y ejecutar el servicio. autenticar y auditar la actividad dentro el ESB. El proveedor de servicios crea el servicio y publica la descripción del servicio en el registro. registro de servicios y solicitante de servicios. Registro SOA Una Arquitectura Orientada al Servicio está basada en la interacción entre tres principales funcionarios: proveedor de servicios.  Servicios de Metadata: relacionados a la mediación. 2. estos servicios pueden transformar datos de un formato a otro usando definiciones de metadata mantenidas en su propia versión de registro.  Servicios de seguridad: encriptan mensajes cuando es necesario e incluyen un modelo estándar de seguridad para autorizar.9.

2. Por otra parte para los programadores y analistas de negocio. JBoss Enterprise SOA Platform JBoss Enterprise SOA Platform es una plataforma certificada. una compañía que ofrece una versión de un sistema operativo de código abierto Linux. pero la compañía es la que gana dinero gracias al soporte de sus productos. El Registro SOA es sumamente importante ya que actúa como punto central de referencia dentro de SOA. el Registro SOA documenta las reglas y descripciones asociadas con cada componente dado.10. el registro SOA actúa como una referencia que ayuda a seleccionar y conectar componentes para crear aplicaciones compuestas y procesos. probada y con soporte para el desarrollo de soluciones de Arquitectura Orientada al Servicio desarrollada por Red Hat.10.1. [JBoss Enterprise SOA Platform Getting Starged Guide].1. que significa que añaden capacidades a sus funciones básicas y trabajan con una comunidad de desarrolladores que añaden aun más valor a los ofrecimientos de la compañía. El registro SOA contiene información sobre los componentes de SOA. Tecnologías para una Arquitectura Orientado al Servicio 1. JBoss JBoss es una división de Red Hat Software. Referencias Bibliográficas 43 .10. [6] 1. Los ofrecimientos de JBoss están basados en un modelo de código abierto. se define como el “dominio” de la arquitectura.10.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX El registro SOA es un tipo de catalogo electrónico donde almacenamos información que describe qué es lo que hace cada componente. También almacenan información sobre cómo cada componente se conecta con otros.1. Tiene dos roles: uno enraizado en el entorno operacional y otro en el mundo de los programadores y analistas de negocio. En el entorno operacional el Registro SOA provee información de referencia sobre los componentes de software que están ejecutándose o disponibles para su uso. Selección de Tecnologías y Herramientas 1.1. Por esta razón. En otras palabras. 1.

JBoss Clustering. Fig.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Esta plataforma integra varios framework y tecnologías incluyendo Hibernate. abierta y asequible. JBoss Enterprise Service Bus (ESB) y JBoss jBPM entre otros para proveer una infraestructura para integrar aplicaciones empresariales SOA. JBoss jBPM jBPM es una Suite de Administración de Procesos de Negocio (BPM) flexible. jBPM tiene un enfoque dual. Referencias Bibliográficas 44 .1. JBoss Application Server. Red Hat define a la su plataforma como simple. robusta y escalable. Seam. Abierta porque está dentro de lo que se conoce como open source o código abierto. 2. Asequible porque los costos de licencia son gratuitos. Actúa de puente entre los analistas de negocio y desarrolladores. Estos productos desarrollados por comunidades y certificados han sido combinados y probados para proveer una plataforma solida.3. servicio y soporte provisto por JBoss.10.15. JBoss Enterprise SOA Platform Fuente: (SOA Whitepaper) 1. JBoss Transactions. Los motores tradicionales BPM tienen un enfoque limitado a personal no técnico. los costos al cliente vienen del mantenimiento. los usuarios y desarrolladores puedan usarla. Ofrece características de administración de procesos de forma que ambos.

1. y luego JBoss lo hizo disponible como una tecnología open source. JBoss obtuvo el ESB (llamado “Rosetta”) de Aviva Canadá.5. jBPM sigue el estado de una ejecución de proceso durante esos periodos de espera.1. servicios de negocio. componentes de negocio y middleware para integrar y permitir la automatización de procesos de negocios. o ejecutar un script son automáticas.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX jBPM toma las descripciones de proceso como entrada. JBoss incluye muchas de las características de otros ofrecimientos más caros.1. El Lenguaje de Definición de Procesos de Negocio jBPM (jPDL) es uno de los lenguajes de procesos que se encuentra en la cima de este framework. Un proceso esta compuesto de actividades conectadas con transiciones. Referencias Bibliográficas 45 . como una persona que debe completar una tarea. El diagrama gráfico de un proceso es usado como la base para la comunicación entre usuarios no técnicos y desarrolladores. Algunas actividades. La compañía donó el ESB a JBoss. JBoss ESB intermedia las interacciones entre las aplicaciones empresariales.10. una de las más grandes compañías de seguros en Canadá.10. estas son la edición “Standalone” y las ediciones “EAP Embedded”. Ediciones de JBoss Enterprise SOA Platform Hay dos formas de la plataforma JBoss disponibles. Otras involucran una espera para una ocurrencia externa. incluyendo un registro de servicios y un repositorio de servicios además de soporte de múltiples servicios de mensajería. Cada ejecución de una definición de proceso es llamada una instancia de proceso. diseñado para permitir al usuario expresar los procesos de negocio gráficamente. jBPM administra las instancias de proceso. JBoss ESB JBoss ESB es el pegamento que une todos los componentes de JBoss Enterprise SOA Platform. Los procesos representan un flujo de ejecución. 1. como enviar email.4. Es un lenguaje intuitivo.

El contenedor trae agilidad y mejora las pruebas de aplicaciones y escalabilidad permitiendo que los componentes de software puedan ser desarrollados y probados en aislamiento. El contenedor es no-invasivo. Spring Framework Spring es un framework basado en Java/J2EE. y reduce la cantidad de código necesaria. Spring incluye:  El contenedor más liviano y completo. Tecnologías para el desarrollo de la Aplicación del Caso de Estudio 1.  Edición “Standalone”: La edición “Standalone” provee una solución liviana para despliegues donde solo se necesita la funcionalidad central de la Plataforma SOA. que provee una configuración centralizada y automatizada y el enlazamiento de los objetos de aplicación.   Una capa de abstracción para la administración de transacciones.2. e iBATIS Un framework de aplicaciones flexible MVC (Modelo Vista Controlador) construido en la cima de la funcionalidad Spring. 2002). Este framework es altamente configurable a través de Referencias Bibliográficas 46 . JDO. Una capa de abstracción JDBC que ofrece una jerarquía de excepciones.   Integración con Mapeos de SQL Hibernate. y luego escalados para el despliegue en cualquier entorno (J2SE o J2EE). Esta sola instalación provee un entorno completo para aplicaciones SOA.1. capaz de ensamblar un sistema complejo a partir de un conjunto de componentes débilemente acoplados.10. Seam. simplifica el manejo de errores. La edición “Standalone” no incluye componentes JBoss EAP que no son necesarios por los componentes centrales de SOA. 1. incluyendo Hibernate. y otros servicios.10.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX  EADP Embedded Edition: Es un entorno de despliegue de aplicaciones completo.2. basado en código publicado en el libro “Expert One-on-One J2EE Design and Development” por Rob Johnson (Wrox.

2. etc. iText y POI. Spring Web Flow Spring Web Flow es un módulo del framework Spring dirigido a definir y gestionar los flujos de páginas dentro de una aplicación web. resultados de las operaciones de proceso.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX interfaces y se acomoda a múltiples tecnologías de vista como JSP. Dependiendo de las opciones que escoja el usuario. la aplicación seguirá una ruta de páginas específicas u otra [38]. El flujo de páginas de una aplicación web consiste en la secuencia de páginas por las que pasa dicha aplicación en función de la conversación que mantenga con el usuario. Referencias Bibliográficas 47 .10.. Fig. 2. Un vistazo de los módulos de Spring Framework Fuente: (39) 1.16.2. Velocity. Tiles.

que pueden ser desplegados en cualquier contenedor como Tomcat. 2. Hibernate Hibernate es el framework de persistencia más popular dentro de la comunidad Java. Fig. XFire puede ser embebido fácilmente dentro de una aplicación java proveyendo una funcionalidad de servidor o cliente de Servicio Web.10. PicoContrainer y Plexus. Referencias Bibliográficas 48 . Así también como Servlets basados en Tomcat.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 1.4. Framework XFire Fuente: (Web Services on XFire –Sing Li) 1. o Jetty.10. XFire XFire es una nueva generación de framework de código abierto que simplifica la creción de Servicios Web java.3. directamente a partir de POJOs. XFire soporta otras tecnologías de contenedores de aplicaciones livianos como Spring. Con XFire. se puede crear Servicios Web a partir de archivos WAR de Servicios Web. Hibernate tiene como objetivo superar la impedancia entre la concordancia entre las aplicaciones orientadas a objetos y bases de datos relacionales.2.17.2.

Fig. conforme al Art. Además.18. Hibernate es un mediador que conecta un entorno orientado a objetos a un entorno relacionar. Almacenar. Provee servicios de persistencia para una aplicación realizando las operaciones necesarias en la comunicación entre entornos orientados a objetos y relacionales. permitiendo al mismo estar más enfocados en las reglas de negocio que la lógica de persistencia [40]. Análisis de la situación actual 3. Estructura del framework Hibernate Fuente: (40) 3. financiera y funcional. Antecedentes de la Institución La Universidad San Francisco Xavier.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Con Hibernate.1. administrativa. hace el código mas conciso. 92 de la Constitución Política del Estado.1. actualizar.1. fundada el 27 de marzo de 1624. eliminar y cargar datos puede ser hecho sin importar la forma de los objetos persistentes. Hibernate aumenta la efectividad de la aplicación y rendimiento. Referencias Bibliográficas 49 . se puede tratar a una base de datos como un almacén orientado a objetos. DESARROLLO DEL PROYECTO 3. 2. que se constituye en una de las instituciones más importantes del país dentro del área de la formación académica de miles de universitarios. es una Institución Nacional de estudios superiores con personalidad jurídica que goza de autonomía económica.

Telecomunicaciones y Redes. académica y tecnológica y esa dentro de esta última donde está la Dirección de Tecnologías de Información y Comunicación (DTIC) cuyas tareas cubren las necesidades de la institución en cuanto a tecnología se refiere. y otras cuatro oficinas donde se encuentran los departamentos de Desarrollo de Sistemas. mantenimiento y administración de redes y servicios Internet. Desarrollo de sistemas. económica. instalación. 9º y 10º semestre de Ingeniería de Sistemas en el área de diseño. La DTIC cuenta con cinco oficinas y una sala de servidores. dependiente de Vicerrectorado de la Universidad San Francisco Xavier. Capacitación a alumnos de 8º.2. Carnetización y los encargados de soporte técnico. la DTIC también cumple la función de Apoyo Académico que se refiere al:   Asesoramiento en la realización de varios Proyectos de Investigación y Proyectos de Grado a alumnos de 9º y 10º semestre de Ingeniería de Sistemas. Administración de Bases de Datos. fue creada fundamentalmente para el manejo de los recursos tecnológicos de información y comunicación actuales tan necesarios en las actividades de la Universidad. brinda apoyo a la misma cumpliendo las siguientes funciones:     Instalación y configuración de redes. Referencias Bibliográficas 50 . Apoyo y soporte técnico Además de estas funciones principales. 3. bajo la modalidad de pasantías. Creación y administración de Base de Datos.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Está constituida por dependencias encargadas del área administrativa. la oficina principal donde trabaja el gerente. Actividad a la que se dedica La Dirección de Tecnologías de Información y Comunicación.1.

integridad. administrando riesgos asociados con la implementación de nueva tecnología. procesos de toda actividad. planificar. confidencialidad y cumplimiento de la información. administrar y dar soporte al “Sistema de información Universitaria”. Valores Calidad: Debe estar en las personas.1. confiabilidad. Visión Proponer políticas e implementar estrategias. étnica.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 3.5. que genere. creando nuevas oportunidades. 3. en un proceso de mejora continua que lleve al éxito organizacional.1. cultural. 3. el cual está directamente alineado con el plan estratégico organizacional universitario de tal forma que permita el logro de nuevos objetivos organizacionales. Pluralismo: Tolerante. La administración efectiva de la información y de la tecnología relacionada que incrementen el potencial que tienen las TIC para cambiar radicalmente la Universidad. Referencias Bibliográficas 51 . desarrollar. humanos y de tiempo para cumplir las acciones propias.4. financieros.1. efectividad. reduciendo costos. disponibilidad. Misión Propiciar la existencia y uso de las tecnologías de información y comunicación en el ámbito universitario en todos sus estamentos. estimulen.3. aprovechando de manera eficiente los recursos y garantizando la eficiencia. integren y coordinen acciones orientadas al desarrollo y uso de las tecnologías de información y comunicación en la Universidad. Equidad: Como la aplicación de oportunidades a todos los sujetos y comunidades con el fin de mejorar sus condiciones de vida. no discriminatoria y que propende hacia la inclusión de hombres y mujeres independiente de su dependencia social. Eficiencia: Como el compromiso para el uso óptimo de los recursos físicos. política o religiosa. mantener.

6. Compromiso Social: Actuará con espíritu solidario a favor de los sectores más vulnerables del conjunto social. 3. la igualdad.1 Estructura Organizativa de la Universidad Fuente: [1] Referencias Bibliográficas 52 . con el respeto absoluto a las dimensiones social. el interés público. cultural.1. la libertad y la justicia. en defensa y desarrollo de la democracia. Contexto Organizacional Ubicación de la DTIC dentro de la estructura organizativa de la universidad Fig. política y religiosa. 3. étnica.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Humanismo: Entender al ser humano y su desarrollo integral como el elemento fundamental de todas las acciones de la sociedad.

Entre los más importantes están: Sistema Integrado de Contabilidad y Presupuestos (SICOPRE): Es el sistema más antiguo y aún en funcionamiento.1. se cuenta con un número aproximado de 800 personas.7. y hasta el día de hoy existen alrededor de 20 Sistemas Informáticos. Dentro del área docente. el de Servicios Académicos. el más importante es el Sistema de Calificaciones (eDocente). En cuanto al personal administrativo. Es usado por la Dirección Administrativa Financiera (DAF). 3. este Referencias Bibliográficas 53 . de las cuales más o menos 300 hacen uso de algún Sistema Informático. Estructura de la DTIC Fuente: [1] 3.2.1. Contexto Social Actualmente la Universidad cuenta con 30000 alumnos aproximadamente y todos ellos hacen uso al menos de un sistema. 3. cada una de ellas también hace uso de Sistemas Informáticos.8. Contexto Tecnológico Los Sistemas Informáticos dentro de la Universidad han comenzado a desarrollarse a partir de la década de los 90. hay más de XXX personas.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Estructura de la Dirección de Tecnologías de Información y Comunicación DTIC Dirección de Tecnologías de Información y Comunicación Telecomunicaciones y redes Administración de Base de Datos Carnetización Desarrollo de Sistemas Informáticos Soporte Técnico Fig.

etc. kardex. horarios. fue un proceso manual.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX sistema está programado en C sobre UNIX. en cuanto a base de datos se refiere. Sistema de Seguimiento Académico: es otro sistema importante. ConfigRED: Encargado de administrar y gestionar las redes dentro de la Universidad. Referencias Bibliográficas 54 . CosticRED: Encargado de la administración de dispositivos y recursos de red. 3. La migración hacia este nuevo sistema. proveedores. costos. Estos sistemas están desarrollados en Java sobre una arquitectura J2EE de 5 capas. Está basado en una arquitectura cliente-servidor. libreta de notas. y usando de técnicas de recolección de datos entre ellas entrevistas y cuestionarios se llegaron a identificar las siguientes necesidades y problemas al interior de la Universidad. y los dispositivos asociados a cada red. Gestión de la configuración de Redes y Telecomunicaciones: Este sistema se compone de varios sistemas entre ellos:    InfraRED: Encargado de administrar y gestionar la ubicación de los recursos o dispositivos de red. Análisis del dominio del problema Habiendo descrito la situación actual del sector de las Tecnologías de la Información de la Universidad San Francisco Xavier.2. y matriculaciones. como base de datos usa Informix y actualmente está siendo remplazado por el Sistema Integrado de Gestión y Modernización Administrativa (SIGMA). Sistema de Control de Asistencia: Está programado en Delphi 6. está programado en Delphi 5 y como gestor de base de datos tiene a SQL Server. Este sistema está encargado entre muchas otras cosas de: programaciones de materias. y está encargado de mantener un registro y controlar la asistencia del personal administrativo y docente de la Universidad.

Referencias Bibliográficas 55 . Esto resulta en un esfuerzo innecesario y una pérdida de tiempo para el desarrollador. Toda o una parte de algún proceso de negocio es útil para otro.3. ahora los estudiantes pueden programarse directamente a través de la Web. El punto es que.2. El desarrollador crea su propia base de datos. se tuvo que volver a programar las mismas funciones en lenguaje PHP. Para lograr lo mencionado anteriormente. Estos nuevos sistemas están influenciados por la forma en que trabaja el antiguo sistema. Datos replicados innecesariamente La Universidad San Francisco Xavier cuenta con alrededor de 20 sistemas. Para esto se hicieron uso de algunos procedimientos almacenados ya existentes. Cuando cierta Facultad o Departamento necesita una aplicación o sistema. era antes considerada como una actividad netamente interna. 3.2. el nuevo sistema en PHP deberá ser modificado. y rutinas de autenticación.1. y rutinas de autenticación similares en cada una de las aplicaciones existentes. Falta de una Arquitectura bien definida Habiendo explicado las anteriores falencias y teniendo en cuenta la cantidad de sistemas existentes y los que están aún por venir se puede decir que el entorno tecnológico es bastante complejo. Como consecuencia.2. conlleva una alta probabilidad de incurrir en costos y esfuerzo excesivos y puede no ser asequible por cuestiones técnicas o financieras.2. dicho sistema es desarrollado.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 3. Lógica de negocio replicada Los obstáculos comienzan a surgir cuando se dan cuenta que las necesidades de negocio no son islas aisladas. adaptarse a estos cambios evolucionistas sin considerar una arquitectura. sin embargo esta no es una solución deseable ya que repetimos código innecesariamente y en caso de que ocurra algún cambio en el Sistema principal de Seguimiento Académico. Mientras la habilidad de programar materias a un estudiante. dentro de la universidad hay cada vez más datos replicados. para ese fin como casi todas las aplicaciones se requiere un sistema de autenticación y almacenamiento de datos de usuario. 3. lo que da lugar a una integración mediante base de datos.

Lograr agilidad y flexibilidad requeriere una catalogo que liste las funciones y datos provistos por los servicios disponibles. informes. como documentos Word y HTML. Este módulo se encargará de guardar y organizar los documentos externos. Interoperabilidad de los Sistemas Interoperabilidad es la habilidad del software de diferentes sistemas de comunicarse con otras compartiendo datos y funcionalidad. Necesidad de Seguimiento del Ciclo de Vida de Documents Al interior del Departamento de Tecnologías de la Información y Comunicación de la Universidad existe un flujo de documentos de todo tipo. Dentro la DTIC existe un entorno heterogéneo de sistemas los cuales necesitan comunicarse entre ellos 3. evaluar y registrarse como un consumidor de servicio Capacidades de administrar el ciclo de vida de un Referencias Bibliográficas 56 . imágenes. Otras veces surge la necesidad de generar dichos documentos. visualización y edición de modo sencillo y rápido. Estos documentos normalmente vienen dados como ficheros informáticos en los formatos típicos de la ofimática. se necesita una forma eficiente de construir procesos de negocio a partir de servicios. permitiendo su búsuqeda. Cada funcionario crea documentos en su propia computadora. lo mejor que se puede hacer es incluir un gestor documental. por ejemplo cartas. facturas.5. documentos escaneados. etc. buscar. Por tanto. 3. Flexibilidad y Alineamiento La agilidad y flexiblidad ocurren cuando nuevos procesos pueden ser creados rápida y eficientemente a partir de un conbjunto existente de servicios.2. En adición. ficheros de texto.2. etc.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Mientras la complejidad y el tamaño de la infraestructura tecnológica van creciendo. Agilidad. normalmente para ser impresos a partir de datos existentes.2. 3. Desafío Reuso Requerimiento Arquitectural Habilidad de publicar.4.6. la necesidad de una arquitectura que maneje y administre estas complejidades se hace presente.

1.3. Proceso de Requerimientos 3.1. Requerimientos no Funcionales 3. Flexibilidad y Alineamiento Tener una arquitectura de referencia que defina los aspectos de negocio e información de SOA y su relación con la empresa.1. etc. Referencias Bibliográficas 57 .2. basado en la composición de servicios Integración de Aplicaciones y Datos Tener un modelo semántico común para la información compartida. carga de recursos. Resumen de los requerimientos arquitecturales Fuente: Elaboración propia 3. Tener una arquitectura de referencia que describa patrones comunes de integración Agilidad.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX servicio Habilidad de garantizar la disponibilidad de una versión de servicio Desarrollo Eficiente Tener una arquitectura de referencia que guie el desarrollo de servicio Usar BPM para definir procesos de negocios.4. Tabla 3.). Proceso de Análisis y Diseño 3. Requerimientos Funcionales 3. planificación temporal. Identificación de Riesgos La identificación de riesgos en un proyecto es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones. Tener un modelo semántico común que es usado para realizar el diseño de interfaz de servicio Usar técnicas de desarrollo apropiadas para asegurar la trazabilidad entre modelos de negocio y sistemas implementados.3.4.3.

puesto que esto podría causar retrasos en la entrega o el desarrollo de un sistema ineficiente. si es que éstas no son bien utilizadas o no se tienen muchos conocimientos de las mismas. algunos saben lo que quieren y otros no.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Durante el desarrollo del proyecto se identificaron distintos riesgos con respecto a la tecnología. el entorno de desarrollo.    El tiempo estimado no es suficiente para el desarrollo del proyecto El proyecto se llega a terminar sin realizar las pruebas suficientes Las pruebas realizadas no obtuvieron un resultado satisfactorio Riesgos relacionados con el cliente: No todos los clientes son iguales.    La tecnología es nueva para la organización La tecnología utilizada no tiene el soporte adecuado El desarrollador no posee el conocimiento suficiente sobre la tecnología elegida. etc. Riesgos Tecnológicos: El emplear nuevas tecnología puede llevar a concebir riesgos en el proyecto. Riesgos relacionados con el tiempo y las pruebas: El estimar el tiempo para realizar un proyecto no debe hacerse a la ligera.    El cliente no tiene una idea clara de lo que precisa El cliente tiene una idea clara pero no puede expresarla El cliente no está dispuesto a participar en las revisiones Riesgos del entorno de desarrollo: Las herramientas inapropiadas o ineficaces pueden estropear los esfuerzos en el desarrollo   No se cuenta con expertos para responder todas las preguntas que surjan sobre las herramientas No se cuenta con ayuda en línea o documentación de las herramientas empleadas Referencias Bibliográficas 58 . el tiempo.

Proyección de los riesgos Las escalas utilizadas para la probabilidad de ocurrencia y el impacto de riesgo son las siguientes: Muy Alta Alta Media Baja Muy Baja 10 8 5 3 1 Tabla.4. Riesgos Tecnológicos Referencias Bibliográficas 59 . Riesgo La tecnología es nueva para la organización La tecnología utilizada no tiene el soporte adecuado Probabilidad 10 8 Impacto 10 7 10 Total 100 56 80 El desarrollador no posee el conocimiento suficiente sobre 8 la tecnología elegida Tabla 3.2. 3. 3.5.4.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 3. Escala de probabilidad de ocurrencia del riesgo Fuente: (Elaboración Propia) Utilizando las escalas mencionadas. a continuación se presenta la estimación de los riesgos en base a la [probabilidad e impacto apreciados.4. Escala de probabilidad de ocurrencia del riesgo Fuente: (Elaboración Propia) Catastrófico Crítico Marginal Despreciable 10 7 4 1 Tabla.

Riesgos relacionados con el tiempo y las pruebas Fuente: (Elaboración propia) Riesgo El cliente no tiene una idea clara todo lo que precisa El cliente tiene una idea clara pero no sabe cómo expresarla El cliente no está dispuesto a participar en las revisiones 8 3 3 Probabilidad 7 Impacto Total 56 30 30 10 10 Tabla 3.7. a continuación se listan los riesgos por orden de probabilidad de impacto. Riesgos relacionados con el cliente Fuente: (Elaboración propia) Riesgo Probabilidad 7 Impacto Total 70 No se cuenta con expertos para responder todas las 10 preguntas que surjan sobre las herramientas No se cuenta con ayuda en línea o documentación de las 5 herramientas empleadas 7 35 Tabla 3.8. Referencias Bibliográficas 60 .6.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fuente: (Elaboración propia) Riesgo El tiempo estimado no es suficiente para el desarrollo del 8 proyecto El proyecto se llega a terminar sin las pruebas necesarias Las pruebas realizadas no tuvieron un 3 Probabilidad 7 Impacto Total 56 4 7 12 56 resultado 8 satisfactorio Tabla 3. Riesgos del Entorno de Desarrollo Fuente: (Elaboración propia) Teniendo los listados de riesgos presentados en las tablas anteriores.

4.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Riesgo La tecnología es nueva para la organización Probabilidad 10 Impacto 10 10 Total 100 80 El desarrollador no posee el conocimiento suficiente sobre 8 la tecnología elegida No se cuenta con expertos para responder todas las 10 preguntas que surjan sobre las herramientas Las pruebas realizadas no tuvieron un resultado 8 7 70 7 56 satisfactorio La tecnología utilizada no tiene el soporte adecuado El cliente no tiene una idea clara todo lo que precisa 8 8 7 7 7 56 56 56 El tiempo estimado no es suficiente para el desarrollo del 8 proyecto El proyecto se llega a terminar sin las pruebas necesarias 5 7 7 35 35 No se cuenta con ayuda en línea o documentación de las 5 herramientas empleadas El cliente tiene una idea clara pero no sabe cómo expresarla El cliente no está dispuesto a participar en las revisiones 3 3 10 10 30 30 Tabla 3.9. Riesgos ordenados por probabilidad e impacto Fuente: (Elaboración propia) 3.3. Mitigación y contingencia de los riesgos Riesgo Mitigación Contingencia información en La tecnología es nueva para la Planificar un proceso de Proporcionar organización El desarrollador no posee capacitación documentos y medios didácticos el Dedicar más horas en la Cambiar a otra tecnología más entendible conocimiento suficiente sobre la revisión de información tecnología elegida No se cuenta con expertos para Buscar información en línea responder todas las preguntas que surjan sobre las herramientas Consultar en foros con otros expertos Las pruebas realizadas no tuvieron Realizar las pruebas hasta Realizar pruebas con el personal un resultado satisfactorio conseguir un resultado apropiado Referencias Bibliográficas 61 .

4. Caso de Estudio: Sistema de Gestión Documental El sistema de gestión documental debe ser un sistema que cuente con las siguientes funciones básicas:      Autenticación de usuarios Seguimiento al ciclo de vida de documentos Búsqueda de documentos Iniciar un procesos de aprobación de documentos Creación de documentos a partir de plantillas Referencias Bibliográficas 62 . Fuente: (Elaboración propia) 3.10.4.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX satisfactorio La tecnología utilizada no tiene el Conseguir de otras fuentes Cambiar a una tecnología que soporte adecuado toda la información necesaria tenga el soporte necesario El cliente no tiene una idea clara Colaborar al cliente con la Programar más entrevistas todo lo que precisa identificación requerimientos El tiempo estimado no es suficiente Elaborar para el desarrollo del proyecto con detalle de la Replantear el tiempo de de planificación la elaboración del proyecto elaboración del proyecto El proyecto se llega a terminar sin Realizar las pruebas necesarias una buena Planificar un tiempo extra al desarrollo para realizar pruebas planificación de pruebas No se cuenta con ayuda en línea o Revisar documentación en Buscar otras herramientas que documentación de las herramientas otros idiomas (de preferencia tengan documentación empleadas Inglés) El cliente tiene una idea clara pero Planificar más reuniones para Ponerse en el lugar del cliente no sabe cómo expresarla conocer las necesidades del para entender sus necesidades cliente El cliente no está dispuesto a Hacer notar al cliente la Solicitar otro personal para que participar en las revisiones importancia de las revisiones participe en las revisiones Tabla 3. Mitigación y contingencia de los riesgos por orden de probabilidad e impacto.

pudiendo ser este aprobado o rechazado. INICIO Tareas Automatizadas Tareas Humanas Enviar Revisión Usuario Revisión Proyecto No Aprobado? Notificación Rechazo Supervisor Si Notificación Aceptación Almacenar Proyecto FIN Fig.5. Procesos de Negocio: Aprobación/Rechazo de Documentos Muchos documentos. Identificación de Servicios Referencias Bibliográficas 63 .4.4. como proyectos. Diagrama de Proceso de Negocio Aprobar Documento Fuente: (Elaboración Propia) 3. 3. y los primeros deben ser notificados una vez terminada la revisión.4.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 3.2. Este procesos tiene como meta u objetivo de negocio el de obtener un documento ya revisado.4.5.1. Procesos de Negocio Identificados 3. estos necesitan ser revisados y aprobados por usuarios de otro nivel. El flujo que sigue este proceso de negocio es el siguiente. especificaciones y presupuestos entre otros son creados por distintos usuarios.5.

se guarda el documento en la carpeta respectiva. etc. Servicio “Enviar Documento a Revisión” Dado un ID de supervisor y un ID de documento. se identificaron los siguientes servicios para este proceso de negocio:  Servicio “Enviar Documento a Revisión”: Este servicio copia el documento en una carpeta temporal de revisión dependiendo de la persona a la que se manda dicha revisión. Referencias Bibliográficas 64 . Servicio “Enviar Documento a Revisión” Fuente: Elaboración Propia  Servicio “Almacenar Documento”: Una vez aprobado o rechazado el documento. información sobre la revisión (fecha.9. Se almacena en la base de datos. este se almacena de manera permanente en un servidor. 3. Este servicio es considerado como una función de negocio y además.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Las preguntas necesarias para la identificación de servicios en una Arquitectura Orientada al Servicio son: “Es o será en algún momento el servicio re usable?” Es el servicio algo que tendrá utilidad más allá de la que brinda a la aplicación a la que pertenece? El servicio representa una función de negocio? [Executing SOA] Luego de haber hecho un análisis. versión. puede ser necesario para otros sistemas existentes o nuevos contar con esta funcionalidad.) Fig.

etc. El flujo que sigue el proceso es como sigue: Referencias Bibliográficas 65 . Servicio “Almacenar Documento” Fuente: Elaboración Propia 3.5.4. Dados otros datos como sobre la revisión se almacena en la base de datos el estado final del documento (aprobado/rechazado) Fig. servidores. para ello deben llenar unas fichas de “Control de Equipos” con las especificaciones del dispositivo.3. estos datos también son necesarios para el sistema Config-RED encargado del registro de dispositivos de red.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Servicio “Almacenar Documento” Dado el ID del documento. Proceso de Negocio: Control de Equipos Los diferentes técnicos de DTIC se encargan de registrar los dispositivos de red (computadoras. Por una parte se necesita obtener un documento en tipo Microsoft Office Word con los datos respectivos y por otra parte. switchs. ID del supervisor se almacena permanentemente el documento.9. routers. 3.) existentes dentro de todos los departamentos de la Universidad.

routers. por ejemplo dentro del catálogo de “Computadoras Pentium IV” hay varios productos específicos como una “Intel Pentium IV CPU 3.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX INICIO Tareas Automatizadas Tareas Humanas Inicia Creación Ficha Usuario Sistema Desplegar Dispositivos de Red Gestión Documental Completar Ficha Si Registrar Dispositivo de Red Usuario Sistema Almacenar Registro Config-RED FIN 3.  Servicio “Listar Productos”: Además de los catálogos. el sistema CosticRED tiene registrado dentro de cada catálogo los productos asociados al tipo de dispositivo.4. 3. etc.4.5. son muchos otros que también necesitan esta Referencias Bibliográficas 66 . hubs.4.  Identificación de Servicios Servicio “Listar Catálogos”: El sistema CosticRED mantiene catálogos de los diferentes dispositivos de red que pueden existir como ser computadoras. Además de este sistema.5. Este servicio será necesario también en la etapa “Creación de Ficha”.5.2 Ghz (Clone) D945PRN”. Esto será de utilidad para el Proceso de Negocio en la etapa de “Creación de Ficha”.  Otros Servicios Servicio de Autenticación: El sistema de gestión documental necesita un control de acceso a usuarios.

3. por tanto será publicado. Servicio de Autenticación Comparar nombre de usuario y contraseña con la base de datos existente. por tanto este sistema publicará el “Servicio de Autenticación”.8. 3. Servicio de Autenticación Fuente: Elaboración Propia  Servicio de Búsqueda de Documentos: El sistema de gestión documental contará con la funcionalidad de búsqueda de documentos. Fig.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX función. Se tiene un sistema desarrollado en PHP que se encarga de esto.9. Si existe devolver los datos del usuario. Fig. Después de un análisis se llega a la conclusión de que otros sistemas pueden en algún momento utilizar esta lógica de aplicación. Servicio de Búsqueda de Documentos Referencias Bibliográficas 67 . Servicio de Búsqueda de Documentos Devolver una lista de documentos con las palabras claves de búsqueda.

Devuelve una lista de los tipos de conectores de interface registrados en el sistema. Devuelve una lista de los tipos de interfaces registrados en el sistema.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fuente: Elaboración Propia  Servicio “Listar Tipos Interfaces”: Servicio publicado por la aplicación CosticRED.  Servicio “Listar Tipos Conectores”: Servicio publicado por la aplicación CosticRED. Devuelve una lista de las distintas velocidades de interfaces registradas en el sistema.10.  Servicio “Listar Velocidades Interfaces”: Servicio publicado por la aplicación CosticRED. Resumen de los Servicios Identificados Referencias Bibliográficas 68 . Nombre Servicio Sistema que lo publica Sistema de Autenticación Sistema de Gestión Documental Sistema ConfigRED Sistemas que lo Utilizan Sistema de Gestión Documental Sistema de Gestión Documental Sistema de Gestión Documental Sistema de Gestión Documental Sistema de Gestión Documental Sistema de Gestión Documental Lenguaje de Programación PHP Autenticación Buscar Documentos Listar Velocidades Interfaces Listar Tipos Interfaces Listar Tipos Conectores Listar Catálogos Java Java Sistema ConfigRED Java Sistema ConfigRED Java Sistema CosticRED Java Listar Productos Sistema CosticRED Sistema de Gestión Documental Sistema de Gestión Documental Java Almacenar Documento Enviar Documento a Revisión Java - Java Tabla 3.

Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Fuente: Elaboración Propia Proceso de Negocio Servicio Autenticación Buscar Documentos Listar Velocidades Interfaces Listar Conectores Interfaces Listar Tipos Interfaces Listar Catálogos Listar Productos Almacenar Documento Enviar Documento a Revisión X X X X Aprobación/Rechazo de Documentos Control de Equipos Tabla 3. Listar Tipos Interfaces Servicios Enviar Documento a Rev.11. Arquitectura de Referencia SOA Procesos de Bus de Servicios Empresarial ESB Negocio Orquestados Aprobación/Rechazo de Documentos Control de Equipos Almacenar Documento Listar Tipos Conectores Listar Listar Catálogos Listar Productos Velocidades Int.6.4. Referencias Bibliográficas 69 . Relación Servicios / Procesos de Negocio Fuente: Elaboración Propia 3. Buscar Documentos Autenticación Aplicaciones Empresariales Sistema de Gestión Documental Sistema de Autenticación CosticRED ConfigRED .

4. Proceso de Implementación El objetivo final no es en sí implementar un sistema. Arquitectura Orientada al Servicio Primeramente. Los sistemas operacionales pueden incluir Referencias Bibliográficas 70 .Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 4. que dan soporte a actividades de negocio. La figura muestra la Arquitectura de Referencia y las tecnologías utilizadas para cada capa.1. ANÁLISIS DE RESULTADOS Y LA PUESTA EN MARCHA 4. De Autenticación ConfigRED Capa de Sistemas Operacionales Esta capa incluye los sistemas que existen en el entorno tecnológico actual de la Universidad. Consumidor de Servicio Capa de Presentación Spring Framework/Java/JSP Capa de Integración (Jboss ESB) Capa de Procesos de Negocio Control Fichas Aprobación Documentos Capa de Servicios Proveedor de Servicio Conjunto de Servicios Web Sistemas Operacionales CosticRED Sist. sino más bien demostrar los conceptos investigados sobre la Arquitectura Orientada al Servicio poniéndolos en práctica. se definió una Arquitectura de Referencia SOA sobre la cual se implementó el Sistema de Gestión Documental.1.1.

Capa de Procesos de Negocio Un proceso de negocio es una representación de las distintas actividades coordinadas dentro de una empresa que realizan una función de negocio de alto nivel. [Open Source SOA] Capa de Integración Esta capa provee la capacidad a los consumidores de servicio de ubicar proveedores de servicio e iniciar invocaciones de servicio. Esta capa es también responsable de la administración del ciclo de vida del proceso. web. Los servicios son definidos de forma que sean accesibles e invocados por consumidores independientemente de la implementación.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX aplicaciones personalizadas. la capa de presentación representa cualquier cosa que pueda ser considerada como una interfaz de usuario para los servicios de cómputo. sistemas legados. pero con una variedad de modelos de entrega diferentes (móviles. Los datos e información que fluyen entre los pasos dentro de los procesos son también representados en esta capa. Capa de presentación Mirando toda la arquitectura. A través de estas tres capacidades básicas de Referencias Bibliográficas 71 . La capa de presentación puede ser considerada como la aplicación clásica. La información sintáctica se refiere a las operaciones de cada servicio. Capa de Servicios Esta capa incluye todos los servicios y la definición de cada uno de ellos que constituye su información sintáctica y semántica. lo que falta es el Sistema de Gestión Documental. gadgets. Por tanto. Los procesos representados en esta capa son el medio de conexión entre requerimientos de negocio y su manifestación como soluciones de Tecnologías de la Información. requerimientos para el acceso al servicio. y cualquier otro tipo de presentación). aplicaciones empaquetadas. mientras que la información semántica se refiere a políticas de servicio. la propia noción de lo que constituye una aplicación cambia. Esta capa representa a los procesos como una orquestación o una composición de servicios. y las diferentes bases de datos existentes. los mensajes de entrada y salida.

Fuente: Elaboración Propia 4.1.1. Lo bueno de la capa de integración es que cualquier función que pueda ser expuesta de una forma que siga estándares abiertos y protocolos podrá ser enchufada al ESB para que pueda formar parte de un ecosistema basado en servicios. Un ESB es una colección de patrones de arquitecturas que usan estándares abiertos y protocolos para implementar tres capacidades básicas de esta capa y proveer una capa entre los consumidores de servicio y proveedores de servicio exponiendo los servicios solo a través del ESB. Capas y Tecnologías Utilizadas.1. uno donde están desplegados las aplicaciones en Java y otro donde se encuentran las aplicaciones en PHP.3.1. Hardware Se utilizaron dos servidores. Capas Sistemas Operacionales Aplicaciones Legadas Elementos Aplicaciones Personalizadas Cualquier tipo de Servicios Web Tecnología Aplicación Jboss jBPM Jboss ESB Proceso de Negocio de Procesos Negocio Servicios Conjunto Servicios Integración Presentación de de Bus Servicios Empresarial Registro de Interfaces Usuario Interfaces Web/Escritorio Java/Spring Framework/JSP Tabla 4. Las características son las siguientes: Referencias Bibliográficas 72 . 4. La función de esta capa es normalmente definida como el Bus de Servicios Empresarial (ESB). enrutamiento y transformación de datos y protocolo.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX mediación.3. esta capa ayuda a fomentar un ecosistema de servicios donde los servicios pueden comunicarse entre ellos mientras son parte de un proceso de negocio.2.7. Especificación Técnica del Hardware y Software 4. Caso de Estudio: Sistema de Gestión Documental El objetivo principal es desarrollar este sistema bajo la Arquitectura Orientada al Servicio.

86 Intel Pentium 4 3 Ghz.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Servidor PHP Procesador Servidor Java Intel Quad Core 1.1.3.3 JBoss jBPM JBoss ESB JBoss Application Server 73 Referencias Bibliográficas .      Software Microsoft Windows XP Service Pack 3 JBoss SOA Platform 4.2. Ghz Memoria Conexión Disco Duro 2 GB 100 Mbps 500 GB 1 GB 100 Mbps 160 GB La infraestructura de red es la siguiente: 4.

Con SOA. gracias al desarrollo del Caso de Estudio. Plan de Pruebas: Arquitectura Orientada al servicio Las pruebas de software tradicional que se enfocaban en pruebas a nivel de código han evolucionado con las arquitecturas Distribuidas y de Servicios Web. la necesidad de probar la lógica de negocio aún existe. MySql) 4. muchos servicios SOA no tendrán una interfaz de usuario.2.2. Las pruebas de las Aplicaciones Web han introducido más pruebas para lógica de negocio a través de la interfaz de usuario de la aplicación. se tiene definida una Arquitectura SOA y un sistema desplegado bajo esta arquitectura. Los servicios que tienen problemas de calidad no serán reusados por los equipos de desarrollo.4 Eclipse Ganymede Adobe Dreamweaver CS4 Spring Framework XFire Web Services Framework XAMPP (Apache. Algunos de los desafíos de las pruebas en SOA son:     Servicios que no tienen interfaz de usuario Lógica de negocio dentro de los servicios Servicios externos a la organización La calidad del servicio será vital para promover el reuso y la facilitar la agilidad de negocio. por tanto debemos probar ambas. Referencias Bibliográficas 74 .Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX       PostgreSQL 8. Plan de Pruebas: Sistema de Gestión Documental 4. Proceso de Prueba Al término del proyecto. sin embargo. 4. que ha probado ser crítica cuando se despliegan nuevas soluciones.1.2.2. Un aumento significante en las actividades de prueba será necesario en un nivel de servicio.

seguridad. Desempeño y Funcionales forman los pilares de las Pruebas SOA.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Entonces cómo probamos la arquitectura SOA? Simplemente no lo hacemos. Interoperabilidad. Se deben probar la escalabilidad y robustez de los Servicios Web y determinar el desempeño de sus operaciones WSDL. interoperabilidad y seguridad. el “tester” debe hacer una prueba durante una duración específica para medir perfiles de robustez y resistencia. Los profesionales IT deben probar rápidamente los Servicios Web. como servicios.  Pilar I. en cambio debemos descomponemos la Arquitectura en sus partes componentes. Pruebas Funcionales y de Regresión Las pruebas de regresión y funcionales son el primer pilar de las pruebas SOA. Los Servicios Web son los bloques de construcción de SOA. perfiles de rendimiento para los Servicios Web. Dicha flexibilidad da la responsabilidad al personal de IT de todos los dominios (Desarrolladores. de desempeño. En otras palabras dividimos la arquitectura en dominios. Ingenieros de Redes. escalable interoperable y segura. gobernancia. Aparte de los perfiles de rendimiento. También se necesita determinar la escalabilidad mediante el bombardeo a los Servicios Web con diferentes mensajes SOAP a través de una amplia gama de clientes concurrentes.  Pilar III. Interoperabilidad 75 Referencias Bibliográficas . Solo adoptando estos pilares. Las interfaces de Servicios Web proveen flexibilidad al integrar activos TI a lo largo de los dominios internos y externos corporativos. las empresas pueden estar seguros de que la Arquitectura Orientada al Servicio es robusta.  Pilar II. Oficiales de Seguridad. Se debe determinar tiempos de respuesta. Asegurarse que los Servicios Web trabajan a la altura de los requerimientos funcionales. Casi todo activo TI ahora tiene una interface como una interface WSDL lista para mensajería SOAP/XML. probando cada componente. latencia. desde la más primitiva a la más sofisticada. etc. Desempeño El desempeño es el segundo pilar de las pruebas SOA. Las pruebas de Vulnerabilidad. y proabamos cada dominio de forma separada usando los enfoques y herramientas recomendados.

las aplicaciones consumidoras necesitan determinar características de interoperabilidad del Servicio Web en tiempo de diseño y ejecución .1. Las pruebas de perfiles WSI en tiempo de diseño combinadas con las pruebas del comportamiento de interoperabilidad de servicios Web en tiempo de diseño.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX La interoperabilidad es el 3er pilar de las Pruebas SOA. Usando Perfiles WSI nos asegura que los activos SOA son interoperables y el WSDL funcionara dentro de entornos heterogéneos Java. sistema operativo y lenguaje de programación. Probar la interoperabilidad de los servicios Web requiere crear suites de pruebas para un WSDL. proveer diagnósticos de vulnerabilidad. etc. Los Ingenieros de la Seguridad deben asegurarse que las vulnerabilidades de los Servicios Web como buffer overflows.2. los oficiales de la seguridad pueden medir perfiles de vulnerabilidad del Servicio Web. Las pruebas de interoperabilidad WSDL en tiempo de diseño no son suficientes. Estas pruebas aseguran que los Servicios Web son interoperables mediante el envió activo de solicitudes especializadas a los Servicios Web determinando si el Servicio Web responde. Plan de Pruebas Las técnicas como pruebas de caja Negra.2.3. y publicar técnicas de solución. 4. Mientras se consume un Servicios Web WSDL. payloads recursivos.NET. y malware traveling sobre los mensajes SOAP no afectan a los Servicios Web críticos. Pruebas de Caja Negra 76 Referencias Bibliográficas . determinar niveles de seguridad. schema posisoning. La necesidad de la habilidad de escanear rápidamente Servicios Web y aéreas de exposición.3. PHP. Aseguran que los activos IT pueden integrarse independientemente de la plataforma. Se necesita también pruebas de interoperabilidad en tiempo de ejecución. caja Blanca y caja Gris aplicadas a los sistemas tradicionales funcionan bien para los Servicios Web. . Creando tests especializados para un Servicio Web. Evaluación de la Vulnerabilidad La evaluación de la Vulnerabilidad es el 4to pilar de las pruebas SOA. Pilar IV. 4. Los desarrolladores deben ejecutar un conjunto de Perfiles WSI de pruebas y reportar los problemas de interoperabilidad con los WSDL de los Servicios Web.

librerías de terceros o otros Servicios Web que son usados para realizar la operación. El “tester” tiene una especificación y debe hacer ejercicios redundantes de invocación al servicio para asegurarse de que la operación probada funciona de forma esperada.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Las pruebas de caja negra se refieren a la técnica para probar un sistema sin conocimiento del funcionamiento interno del sistema.2. ya que como anteriormente mencionamos los Servicios Web no cuentan con interfaces de usuario. estados de ejecución. y lo que nos brinda esta aplicación es una interfaz de usuario para invocar Servicios Web y mostrar las salidas. Un “tester” de Caja Negra usualmente interactua con un sistema a través de una interfaz de usuario proveyendo datos de entrada y examinando las salidas sin saber donde y como se trabaja con las entradas. Cómo estas salidas son generadas o qué hay dentro de la Caja no es de importancia para el “tester”. Los “testers” de Caja Negra no tienen acceso al código fuente y tampoco tienen conocimiento de la Arquitectura del Sistema. Los “testers” de Caja Blanca tienen acceso al código fuente y están al tanto de la arquitectura del sistema. y busca errores como la falta de manejo de excepciones. lenguaje de programación. Referencias Bibliográficas 77 . El “tester” no está al tanto del sistema operativo. el software es probado con una variedad de entradas y las salidas son observadas para la corrección. Pruebas de Caja Blanca Las pruebas de Caja Blanca se refieren a la técnica de probar un sistema teniendo conocimiento del funcionamiento interno del sistema. En las pruebas de Caja Negro.2.3. El “tester” debe saber la ubicación del WSDL del Servicio Web pero no está al tanto de los detalles de implementación. manejo de excepciones internos. Para realizar estas pruebas haremos uso del software SOAPSonar. 4. Un “tester” de Caja Blanca usualmente analiza el código fuente.

Michel P. Alan. Luis (Coord. HOPKINS.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX 4. Indiana: Wiley Publishing Inc. 720 p. Service-Oriented Design and Development Methodology [en línea]. Madrid: Mc Graw Hill. “Patterns: Implementing an SOA Using an Enterprise Service Bus“. Robin. Service Oriented Architcture for Dummies. Willem-Jan. REFERENCIAS BIBLIOGRÁFICAS [1] BELLIDO SANTA MARIA. 640 p.). Introducción a la metodología de la investigación.pdf . BISHOP.nl/pub/papazogloump-2006-88. José Boris. Technology. 2005.eumed. Sucre. ROBINSON. Martin. BAROUIDI.3. Susan. Quinta edición. Primera edición. WebSphere Software. Thomas. Prentice Hall PTR. RECOMENDACIONES 7. Bolivia: Universidad San Francisco Xavier. ISBN: 0-470-054352.net/libros/2006c/203. Darrel (adap. [5] PAPAZOGLOU. BLOOR. VAN DEN HEUVEL. Puesta en Marcha 5. Hector Luis. 2006. 359 p. ISBN: 0-13-185858-0.. [2] AVILA BARAY. Facultad de Tecnología. Documento PDF. Joyanes Aguilar. 2006. Service-Oriented Architecture: Concepts. CONCLUSIONES 6. [4] ERL. Disponible en: http://www. [7] KEEN. [en línea]. Tesis (Ingeniero de Sistemas). Carol. Netherlands: Universidad de Tilburgh. [3] PRESMAN. ISBN: 0-07-709677-0. [en línea]. 2002.). Disponible en: http://infolab. [Consulta: 23 de mayo 2009] corrigió [6] HURWITZ. 2005. Referencias Bibliográficas 78 .uvt. [Consulta: 1 Mayo 2009]. Ingeniería del Software – Un enfoque práctico. Desarrollo de Web Services para un proveedor de Servicios de Aplicación. 2007. Roger. Rick. Ince. and Design. Judith.

MCCABE. [14] MACKENZIE.pdf [12] ERL.. LASKEY. [En línea]. [Consulta: 23 de mayo 2009] Referencias Bibliográficas 79 . United States. LASKEY. [en línea] Committee Draft 1.redbooks. [Consulta: 23 de mayo 2009] [15] ESTEFAB. [8] ROSEN. Inc.oasis-open. Olsson. En: Service-Oriented Architecture: Principles of Service Design. Disponible en: http://www. mayo 2006. En: Thesis Projects: A Guide for Students in Computer Science and Information Systems. Prentice Hall PTR. Kevin T. [Consulta: 9 mayo 2000].0. O’Reilly Media. SMITH.pdf.oasis-open. En: Reference Architecture for Service Oriented Architecture Version 1. LUBLINSKY. “Developing your Objectives and Choosing Methods”. En: Service-Oriented Architecture: Principles of Service Design. Springer-Verlag London. Mathew. Jeff A.. “Service Contracts Standardization and Design”. Michael. “Realizing Service Oriented Architectures View“. 2008.sciencebuddies.0/soa-ra-pr-01. pp 124161 ISBN: 0-13-234482-3. Pp 39-78. Indiana. Indianápolis. [10] BERNDTSSON. Francis. “Service Contracts Standarization and Design”. Thomas. Febrero. Thomas. Documento PDF. Disponible en: http://www.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX IBM. Ken. pp 204-210. 2008. 2008. Disponible en: http://docs. Mikael. Boris. ISBN: 978-0-470-22365-9. [en línea]. MCCABE.php?wg_abbrev=soa-rm.org/soa-rm/soara/v1.0.0. pp 54-70 ISBN: 1-85233332-4. United States.html. HANSSON Jorgen. Nikolai M. pp 47-59 ISBN: 0-596-52955-4. OASIS Reference Model for Service Oriented Architecture 1. Abril.org/committees/tc_home. Francis. [11] The Scientific Method.ibm. En: SOA Applied: Service Oriented Architecture and Design Strategies. “Designing Service Interfaces”. Wiley Publishing. [13] JOSUTTIS. 2008.com/redbooks/pdfs/sg246346. 2007. 2008. [9] ERL. [Consulta: 18 de mayo de 2009] http://www. “The Enterprise Service Bus”. Prentice Hall PTR. pp 124161 ISBN: 0-13-234482-3. United States. Ken. BJORN. 2006. En: SOA in Practice.org/science-fair-projects/scientific-method-handout.

360 p.Ingeniería de Sistemas ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX [16] BRITTAIN. Tomcat: The Definitive Guide. 9780596101060. Sams Publishing. Applied XML Solutions. Marchal. ISBN: [17] BERNOIT. 494 p. ISBN: 0672320541. 2007. O’Reilly. Referencias Bibliográficas 80 . 2000. Jason.

James. 2007. ESB. McGrawHill Osborne Media. Prentice Hall.Ingeniería de Sistemas UMRPSFXCH SOA COMO ARQUITECTURA PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX [18] HANSEN. Manning Publications.scribd. Primera edición: PACKT Publishing. Noviembre. Segunda edición: Wiley Publishing Inc. 2007. Marcia. ISBN: 1-932394-59-1. KAUFMAN. Primera edición: PACKT Publishing. Robin. [Consulta: 25 mayo 2009]. Principles of Service Design. ISBN: 0-13-234482-3. 382 p. 2006. Mark. 314 p. 243 p. Judith. Yuli. Septiembre. ISBN: 978-0-12374891-1 Primera edición: Referencias Bibliográficas 81 . Primera edición: Prentice Hall. 2003. 359 p. Matjaz B. TAYLOR.com/enterprise/article. Tesis (Masters of Computed Applications). ISBN: 978-0-470-52549-4 [25] JURIC. ISBN: 0072227117 [21] POWELL. Q&A: SOA Challenges for SMBs. Principles Techniques. Primera edición: Morgan Kaufmann Publications. Kunan. Composing Service-Oriented Solutions with PHP and ActiveBPEL. 512 p. Thomas. James E. Disponible en: http://esj. Nadir. Delhi: GGSIP University. 2007. LOGANATHAN. Eric.com/doc/964179/Service-Oriented-Arcitecture. and BPEL in real-world SOA projects. Disponible en: http://www. BLOOR. Understanding Enterprise SOA. 2007.. ISBN: 9780130449689 [19] UPPAL. 314 p. 608 p. SOA Approach to Integration. Ramesh.. Web Services. Service Oriented Architecture for Dummies (IBM Limited Ediion). [24] HURWITZ. 2010. Hugh. [23] EARL. Kashmere Gate. "SOA Basics".aspx?EditorialsID=3466 [Consulta: 26 abril 2002] [22] PULIER. [en línea]. Practical J2EE Application Architecture. ISBN: 9781-847192-70-7 [27] BEAN. XML. Indiana 2008. [20] GULZAR. En: Service Oriented Architecture [en línea]. SOA Using Java™ Web Services. 2009. Indiana. Primera edición. SOA and Web Services Interface Design. 76 p. and Standards. ISBN: 978-1-904811-17-6 [26] VASILIEV.. SOA and WS-BPEL. Primera edición.

. Primera edición: PACKT Publishing.. Mayo. 2008. CA. Julio. Kevin. Design and Architecture. SMITH. Primera edición: PACKT Publishing. Paul C. Using SOA and web services to build powerful Java applications.. Prakash. Primera edición: PACKT Publishing. Michael. Daniel. Diciembre. V. Implementing SOA: Total Architecture in Practice. LIEBHART. BINILDAS. ISBN: 978-0-321-50472-2 [35] BIEBERSTEIN. NG. 314 p. 314 p. Open Source SOA. WELKENBACH. Abril. Norbert. jBPM Developer Guide. 2008. MITRA. Tilak. ISBN: 978-0-470-14111-3 [29] BARAI. Boris. 225 p. 2007. Primera edición: PACKT Publishing. Primera edición: IBM Press. ISBN: 978-0-13-235374-1 [36] CUMBERLIDGE. 698 p. LAIRD. Marc. Primera edición: Wiley Publishing. ISBN: 978-1-847192-36-3 [37] ROSEN. ISBN: 978-0-470-22365-9 Referencias Bibliográficas 82 . Applied SOA. Matt. Inc. Service Analysis. 2008. 736 p.. 2008.Ingeniería de Sistemas UMRPSFXCH SOA COMO ARQUITECTURA PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX [28] BELL. LUBLINSKY. Primera edición: Addison-Wesley.Executing SOA: A Practical Guide for the Service Oriented Architect. A Practical Guide for Business Analysts. Guido. Dr. Junio. ISBN: 978-1-849681-04-9 [31] DAVIS. Service-Oriented Architecture: An Integration Blueprint. 2009. 2009. Primera edición: Manning Publications Co. ISBN: 978-1-933988-54-2 [32] SALATINO. Service Oriented Modeling.. Implementing SOA Using Java EE. Tony. . 2009. 449 p. Primera edición: John Wiley & Sons. 2010. Service Oriented Architecture and Design Strategies. ISBN: 978-1-847195-68-5 [33] KUMAR. Mauricio. Primera edición: Addison Wesley Professional. BALCER. Junio. Peter. 240 p. JONES. Business Process Management with JBoss jBPM. 371 p.. Jeff.. Vincenzo.. 188 p. ISBN: 978-1-847193-21-6 [30] SCHMUTZ. Robert G.. CASELLI. Malhar. 2008. Inc. B. Michael. NARAYAN. Service Oriented Architecture with Java. Keith . 387 p. Diciembre. ISBN: 978-0-321-49215-9 [34] BROWN.

915 p. ISBN: 978-1-849510-56-1 [41] SWEENEY. Ashish. Recommendations. SOA in Practice. Segunda edición: APress Publishing. 2008.Ingeniería de Sistemas UMRPSFXCH SOA COMO ARQUITECTURA PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX [38] LUPPKEN. Sven. Marzo. Concepts. A Problem-Solution Approach.NET & Windows Azure... Primera edición: PACKT Publishing. 2008. Primera edición: Prentice Hall. ISBN: 978-1-59059-979-2 [40] REZA. STAUBLE. 434 p. ISBN: 978-1-847195-42-5 [39] MAK. 344 p. Jeff.. Oracle Service Bus. 2009. ISBN: 0-596-52955-0 [45] MCGOVERN. Applying an Enterprise Architecture Approach. Nicolai M. The Art of Distributed System Design. Primera edición: PACKT Publishing Inc. JAIN. 2006. Oliver. Achieving Service-Oriented Architecture... Primera edición: O’Reilly Media. 383 p. 2009. Spring Recipes. ISBN: 978-0-13-158231-6 [44] JOSUTTIS. Spring Web Flow 2 Web Development. Inc. Mark. 2010. 2010. Inc. SIMS. Challenges.. Primera edición: Apress Inc. Rick. 753 p. David. 272 p. Enterprise Service Oriented Architectures. Thomas. RAY. 460 p. SOA with . 524 p. David. Markus. Realizing Service-Orientation with the Microsoft Platform. Spring Persistence with Hibernate. Smarat. RIEBER. Primera edición: John Wiley & Sons. ISBN: 1-4020-3704-X Referencias Bibliográficas 83 . The definitive guide to SOA. James. Gary. ISBN: 978-0470-60451-9 [42] DAVIES. Inc. Primera edición: Springer. ISBN: 978-1-4302-1057-3 [43] ERL. Noviembre. Ahmad. LITTLE. SCHOROW. 2005.

Ingeniería de Sistemas UMRPSFXCH SOA COMO ARQUITECTURA PARA LA IMPLEMENTACIÓN E INTEGRACIÓN DE SISTEMAS DE INFORMACIÓN EN LA USFX Referencias Bibliográficas 84 .

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->