Proyecto de Grado

NDICE
DECLARACION DE DERECHOS DEL AUTOR

Al presentar este proyecto como uno de los requisitos para la obtencin del Grado Acadmico, de Licenciado en Ingeniera de Sistemas de la Universidad Mayor Real y Pontificia de San Francisco Xavier de Chuquisaca, autorizo a la direccin de Carrera de Ingeniera de Sistemas y a la Biblioteca de la Universidad, para hacer de este proyecto un documento disponible para su lectura segn las normas de la Universidad. As mismo manifiesto mi acuerdo para la utilizacin de ste, como material productivo, dentro del reglamento de Ciencia y tecnologa, siempre y cuando este uso no suponga ganancia econmica. Tambin 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 despus de su aprobacin. Atentamente,
Univ. Martha Eugenia Rojas Vera C.U.: 35-2039 Sucre, octubre de 2010
Ingeniera de Sistemas
ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX
RESUMEN
Ajustarse a las demandas cambiantes continuas del entorno de las Tecnologas de la Informacin (TI) es uno de los mayores retos para la Universidad San Francisco Xavier, as como para cualquier compaa. Este reto demanda al departamento de TI proveer un soporte apropiado que adapte los procesos dentro de la organizacin. El gran problema es que el entorno de TI de la Universidad es complejo y est compuesto por diferentes sistemas implementados en diversas tecnologas que no fueron diseados para ser integrados con otros. Este proyecto describe el concepto de Arquitectura Orientada al Servicio SOA como una solucin 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 interaccin de diferentes aplicaciones sin importar su plataforma, lenguaje de implementacin o ubicaciones utilizando servicios genricos y confiables que pueden ser usados como un bloque de construccin de aplicaciones. Este proyecto describe SOA a detalle, considerando diferentes conceptos, metodologas, tecnologas, requerimientos relacionados y un enfoque basado en Servicios Web con el propsito de lograr una figura completa y exacta de esta arquitectura, para luego finalmente aplicar todos estos conceptos con el desarrollo e implementacin de un Caso de estudio Prototipo. El mtodo que sigue la investigacin y desarrollo del proyecto es el Mtodo Cientfico, para el desarrollo del caso de estudio se sigue la metodologa RUP y dentro de sus fases se hace un anlisis y diseo orientado al servicio siguiendo la estrategia top-down. Al trmino de este trabajo se logr un documentar e implementar una Arquitectura Orientada al Servicio que represente la solucin para los problemas mencionados y se ajuste a los requerimientos del departamento de TI de la USFX,
Introduccin y Antecedentes del Proyecto
1. INTRODUCCIN Y OBJETIVOS
1.1. Introduccin o antecedentes del proyecto
La USFX, fundada el 27 de marzo de 1624, es una Institucin Nacional de estudios superiores con personalidad jurdica que goza de autonoma econmica, administrativa, financiera y funcional, conforme al Art. 92 de la Constitucin Poltica del Estado, que se constituye en una de las instituciones ms importantes del pas dentro del rea de la formacin acadmica de miles de universitarios, su aporte econmico tambin es importante ya que es una fuente generadora de trabajo. Est constituida por dependencias encargadas del rea administrativa, econmica, tecnolgica y acadmica, y es dentro del rea administrativa tecnolgica dentro de la cual ubicamos a la Direccin de Tecnologas de Informacin y Comunicacin cuyas tareas cubren las necesidades de la institucin en cuanto a tecnologa 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, Administracin de Bases de Datos, Telecomunicaciones y redes, Carnetizacin y los encargados de soporte tcnico. Adems cuenta con varios recursos informticos. Entre estos el sistema de Seguimiento Acadmico, Carnetizacin, Control de Asistencia, etc. El gestor de BD es SQL Server 2000 para los sistemas grandes y MySql para otros ms pequeos, 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 globalizacin, al dinamismo del entorno, el rpido crecimiento de la poblacin universitaria, que actualmente es de aproximadamente 30000 alumnos y en general a los rpidos avances de la tecnologa, la USFX debe estar adaptndose y evolucionando constantemente y eficientemente para brindar un mejor servicio, razn por la cual se est dando muchos cambios estructurales en la parte acadmica y administrativa. Esto lleva a que la estrategia del rea de TI no sea simplemente proveer y asegurar el funcionamiento de la tecnologa, sino que est debe estar alineada con la estrategia del negocio y convertirla en socio estratgico.
Por lo explicado anteriormente se pueden evidenciar las siguientes dificultades: El entorno tecnolgico que posee la USFX actualmente es complejo desde el punto de vista tcnico, ya que se compone de infraestructuras inflexibles donde la integracin de los sistemas resulta una labor difcil para el departamento de TI, ya que algunos sistemas no fueron diseados sobre plataformas o tecnologas compatibles entre s, ni acogiendo estndares de industria abiertos, por lo tanto se exigen desarrollos de adaptadores particulares. Actualmente se cuenta con sistemas desarrollados en diferentes lenguajes de programacin (Delphi, JAVA, PHP), que deben integrarse de forma sincrnica para satisfacer los nuevos requerimientos empresariales. Con el paso del tiempo la USFX ha llegado a tener programas similares. Cada departamento quiere algo ligeramente diferente, entonces ese departamento construye su propia versin de ese software, por ello se puede encontrar al interior varias versiones de ms o menos el mismo programa, con claro est- pequeas variaciones. Estas pequeas variaciones son lo que hace a los sistemas difciles de mantener, si se hace un cambio en la poltica de negocio que afecta a otras aplicaciones, se tiene que encontrar y cambiar cada instancia en cada aplicacin afectada. Y aun la ms pequea diferencia en la implementacin podra resultar en inconsistencias. Si bien en la USFX se tienen algunos sistemas que tratan de reutilizar servicios (los famosos servicios web), y una arquitectura de 5 capas basada en J2EE [20] slo para sus sistemas ms importantes, no cuenta con una arquitectura independiente de la plataforma sobre la cual deberan construirse todos los sistemas se han desarrollado. Para tratar de subsanar estos problemas la USFX ha desarrollado algunos servicios web, que cuentan con interfaces descritas en un lenguaje estndar, pero no es suficiente con crearlos, sino que se debe tener una arquitectura bien definida sobre la que estos servicios web van a implementarse. Por ello, esto no es una solucin a los problemas mencionados anteriormente.
En la Facultad de Tecnologa se ha elaborado una tesis titulada Desarrollo de Web Services para un Proveedor de Servicios de Aplicacin [1], que podr servir de referencia al momento de generar la documentacin y definir un Servicio Web. Dentro de los programas ya elaborados para solucionar problemas similares a los del presente proyecto, si bien no son aplicaciones en si son herramientas comerciales como WebSphere de IBM, Oracle SOA Suite, Bizuit Agile Buisness Suite, o de cdigo abierto como FUES y JBoss SOA Platform que es lo que se utilizar en el proyecto para conformar la arquitectura SOA. En la actualidad se encuentra una propuesta interesante: Arquitectura Orientada al Servicio (SOA) [4]. SOA nace como la evolucin de las aplicaciones monolticas que solucionaban necesidades especificas como: contabilidad, compras, etc. sin tener en cuenta otros sistemas empresariales y cmo integrarse con ellos, es por esto que las reas de TI tienen una serie de aplicaciones legadas que no pueden intercambiar informacin o conectarse entre ellas. SOA plantea una solucin para esta situacin, permitiendo interconectar sus aplicaciones corporativas y construir otras a partir de unidades funcionales llamadas servicios. SOA aporta una gua tecnolgica para ayudar a los desarrolladores de software a disear aplicaciones que sirvan, de forma adecuada, a los objetivos de la organizacin y que permitan adaptar las aplicaciones existentes, en servicios de valor para la organizacin. Es con la intencin de resolver los problemas descritos que surge este proyecto.
1.2.
Identificacin del problema central del proyecto
La Infraestructura Tecnolgica actual de la USFX que hace difcil integracin, interoperabilidad y reutilizacin de los sistemas existentes al interior ya sean nuevos desarrollos o sistemas legados, no brinda la flexibilidad de poder ampliar la funcionalidad de las aplicaciones actuales cuando sea necesario.
Planificacin de Actividades del Proyecto
1.3.
Abordaje o ruta de solucin del problema
Para resolver el problema identificado se pretende realizar un estudio en profundidad y una experimentacin prctica de la Arquitectura Orientada al Servicio, mediante un Anlisis de Literatura [11], documentando este proceso, obteniendo una Gua de Conceptos, mejores prcticas y tecnologas asociadas a la arquitectura SOA para posteriormente procesar la informacin y obtener un documento final. Finalmente se demuestran los conceptos y principios del desarrollo de Aplicaciones Orientadas al Servicio implementando un Bus de Servicios Empresarial (ESB) [13], para luego desarrollar un Sistema de Gestin Documental bajo esta arquitectura. El desarrollo del sistema seguir una metodologa de desarrollo iterativa e incremental: RUP [3]; tomando en cuenta que dentro de sus fases se hace un anlisis y diseo orientado al servicio [5] siguiendo la estrategia top-down para ciclos de vida de entrega SOA [4]. La informacin se almacena en formato XML [18], la interfaz grafica principal es orientada a la Web, como servidor utiliza Tomcat [16], y finalmente para implementar los servicios hace uso de Servicios Web [15].
Fig. 1.1 Ruta de Solucin Fuente: Elaboracin Propia
1.4.
Objetivos del Proyecto
a. Objetivo General Realizar un estudio de los aspectos conceptuales, y una experimentacin del proceso de definicin e implementacin de una arquitectura SOA que sea flexible para permitir la integracin de diversos servicios o aplicaciones mejorando el intercambio de informacin y adaptndose a los cambios constantes en los nuevos requerimientos dentro de los sistemas de la USFX y se ajuste a los requerimientos de dicha institucin.
b. Objetivos Especficos Elaborar un documento que contenga la base terica y los pasos a seguir para implementar y desarrollar aplicaciones bajo una Arquitectura SOA. Definir la Arquitectura de Referencia SOA que plasme los distintos componentes de la solucin SOA, principalmente Procesos de Negocio y Servicios y muestre cmo van a interactuar estos componentes. Esta Arquitectura de Referencia se define de acuerdo a las necesidades de la institucin. Definir un contexto de ejecucin SOA (ESB) [6] cuya funcin sea proveer una virtualizacin de los recursos de la empresa, permitiendo a la lgica de negocio de la empresa ser desarrollado y manejado independientemente de la infraestructura y de la provisin de esos servicios de negocio. Desarrollar un Sistema de Gestin Documental -como Caso de Estudio Prctico- bajo la arquitectura SOA, 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 ajustndose a las polticas que sigue la organizacin Definir procesos de negocio en conformidad al caso de estudio y que estarn compuestos de actividades que sern luego implementadas por los servicios de negocio.
Definir modelos de descripcin de servicio [14], compuestos de varios elementos como ser interfaz de servicio, funcionalidad, contrato de servicio [13], etc. que establezcan limitaciones tcnicas, requerimientos, informacin semntica, ajustndose a lo establecido por el Modelo de Referencia SOA de OASIS [15].
Implementar servicios como mecanismos para acceder a una o ms capacidades o funcionalidades requeridas que usen interfaces estndar [19] y estn de acuerdo con las polticas y limitaciones definidas por la descripcin de servicio
Implementar Gobernancia SOA [9] mediante la definicin de polticas de regulacin de servicios, incluyendo identificacin de roles, responsabilidades y dueos, etc.
Poner a prueba el Sistema de Gestin Documental sobre la arquitectura SOA durante un mnimo de dos meses, corrigiendo todos los errores detectados de manera que esta cumpla con todas las especificaciones y requisitos de la institucin, documentando todo el proceso.
c. Delimitaciones Si bien puede haber otras formas de implementar una arquitectura SOA, solo se considera una implementacin a travs de Servicios Web. Solo se utilizan las herramientas que se adecen a las necesidades de la USFX dentro de las muchas existentes en una SOA. Si bien se hace un estudio sobre herramientas basadas en software propietario solo se consideran y utilizan herramientas open source. No se instalan redes de computadoras ni equipos de computacin, pues se emplea la red y equipos existentes dentro de la USFX.
d. Suposiciones Para el estudio, desarrollo y culminacin exitosa y garantizada de la investigacin; se dispone de la informacin necesaria y suficiente existente en internet y algunos otros documentos escritos, que se utilizan como referencia y bibliografa. La institucin para la cual se realiza el proyecto tiene inters en el desarrollo del mismo y brinda toda la informacin que se requiera para la correcta formulacin del modelado del negocio. La institucin proporciona el entorno adecuado necesario para la implementacin exitosa del caso de estudio. La institucin cuenta con redes ya implementadas a nivel con acceso a internet. La institucin cuenta con al menos una PC Servidor donde se debe implementar el software necesario y la arquitectura propuesta SOA
1.5.
Justificacin del proyecto
a. Justificacin Operativa La implementacin del proyecto constituye un aporte que beneficia al personal de DTIC, brindndoles informacin sobre el uso de soluciones de Arquitectura Orientada a Servicios (SOA), como una herramienta trascendente para lograr incrementar su productividad, mejorar su eficiencia operativa y su velocidad de reaccin. b. Justificacin Tecnolgica La implementacin de un sistema bajo una Arquitectura Orientada al servicio, constituye un gran aporte tecnolgico ya que se convierte en un ejemplo prctico que muestra cmo 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, facilita el re uso del software, y sirve como la columna vertebral para los procesos de negocio y aplicaciones compuestas, mejora la consistencia de datos y la calidad eliminando procesos y almacenes de
Planificacin de Actividades del Proyecto 8
datos redundantes [21]. Es por lo tanto una alternativa seria, que debera ser tomada en cuenta por los Ingenieros de Sistemas, al momento de desarrollar aplicaciones -para hacerlas ms productivas, flexibles, ms seguras y manejables para gestionar procesos de negocio crticos a medida que evolucionan o cambian las necesidades del negocio-, y por las organizaciones o empresas al momento de decidir la arquitectura ms conveniente sobre la cual implementar sus sistemas.
1.6.
Diseo Metodolgico
1.6.1. Metodologa de Investigacin El mtodo utilizado en la investigacin y desarrollo del proyecto es el Mtodo Cientfico [11], se comenz con el diseo de preguntas de investigacin relativas al rea con el propsito de proveer las respuestas correspondientes. Entre los tipos de investigacin usados estn la investigacin aplicada [90], que es la que se realiza para conocer la realidad social, econmica, poltica, tecnolgica y cultura de su mbito y plantear soluciones concretas, reales, factibles y necesarias, y la investigacin exploratoria [90] que se efecta cuando el objetivo es examinar un tema o problema poco estudiado que no ha sido abordado antes. Como siguiente paso se identificaron los instrumentos y medios a travs de los cuales se efectu el mtodo entre los cuales se us el Anlisis de Literatura [10], para tener un conocimiento en profundidad del rea de investigacin, para recopilar otra informacin necesaria se recurri a tcnicas como la encuesta [2], que comprende el cuestionario [2] y la entrevista [2], a los profesionales de la DTIC del rea de inters. Luego se dio paso a la Implementacin [10] de la solucin propuesta, demostrando que realmente posee las ventajas propuestas, de tal manera que la solucin queda validada y comprobada.
1.6.2. Metodologa de Ingeniera 1.6.3. Gestin de proyecto 1.6.3.1. Investigacin Tabla 1.1 Planificacin de Actividades de Investigacin DAS 19 6 PRODUCTO Documento con la base terica Documento con referencias bibliogrficas encontradas Seleccionar y clasificar la informacin Extraer y obtener informacin Analizar y procesar la informacin Presentar la informacin 3 3 4 3 Documentos Organizados y Clasificados Documento con la inf. extrada Documento con la inf. procesada Documento final
ACTIVIDAD ETAPA DE INVESTIGACIN Buscar y Recolectar Informacin
Fuente: Elaboracin Propia
10
1.6.3.2.
Desarrollo del caso de estudio Tabla 1.2 Planificacin de Actividades de desarrollo del Sistema Das PRODUCTO Arquitectura de referencia
ACTIVIDAD
ITERACIN I
28
SOA y candidatos de servicio definidos
Inicio Determinar la naturaleza y el mbito de las solucin basada en el servicio en el contexto de la empresa Definir el contexto de ejecucin SOA a utilizar Identificar los candidatos de servicio y artefactos
9 3 2 3 Documento con la visin de la solucin 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
Elaboracin Elegir los servicios candidatos a usar e identificar procesos y funcionalidad de la aplicacin Determinar el mbito de los procesos identificados
20
Identificar servicios o componentes ya desarrollados Implementar el ESB ITERACIN II Elaboracin Especificar descripcin de servicios Construccin Configurar el ESB de acuerdo al contexto de la USFX Desarrollar la interfaz principal del sistema ITERACIN III
2 13 21
Documento con la descripcin de servicio
7 7 29
ESB configurado Interfaz definida Servicios Implementados
Referencias Bibliogrficas
11
Tabla 1.2 ACTIVIDAD Construccin
Planificacin de Actividades de desarrollo del Sistema Das PRODUCTO
Implementar interfaces de servicio Codificacin de los Servicios Configuracin avanzada del ESB Implementar la interfaz central de la aplicacin ITERACIN IV Construccin Codificacin de Servicios Implementar gobernancia de los servicios Pruebas de los servicios Desplegar los servicios Integrar la interfaz principal con los servicios ITERACIN V Transicin Pruebas del sistema integrado (Sistema de Gestin Documental) Administracin 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 Integracin realizada Sistema documental de Gestin
30 30
Sistema validado y probado Niveles de servicio verificados
12
2. MARCO TERICO CONCEPTUAL

1.7. Marco terico del dominio del problema
1.7.1. Arquitectura de Aplicacin Hace 20 aos, el concepto de arquitectura no estaba bien definido, entendido o comunicado. Los avances en las tecnologas de computacin forzaron el concepto debido a complejidades no manejadas en las Tecnologas de la Informacin (TI) que causaban un impacto en la eficiencia y costo. Los sistemas ya no eran percibidos como Cajas Negras mgicas y la participacin del negocio no estaba limitada a los requerimientos de negocio. Desde los principios de la computacin multiplataforma, se ha escrito mucho sobre el valor de la prctica de una arquitectura empresarial, y la razn de esto, es que la tecnologa de computacin y los sistemas se han vuelto mucho ms complejos. La cantidad de tecnologas, las formas en que esas tecnologas son utilizadas, y la multitud de alternativas disponibles como soluciones para un negocio dado crecen cada ao. El resultado es que literalmente hay miles de formas en que la tecnologa puede resolver una necesidad de negocio. Mientras esto es bueno en trminos de competitividad y precio, es malo en trminos de complejidad y sobrecarga. Lo bueno es que se tiene muchas alternativas y opciones para resolver un problema, y sin una arquitectura se termina implementando diferentes formas de resolver diferentes instancias del mismo problema [41]. La arquitectura de software es la descripcin de un sistema de software en trminos de sus componentes ms importantes, sus relaciones, y la informacin que pasa entre ellos. En esencia, la arquitectura es un plan para construir sistemas que satisfacen requerimientos biendefinidos y, por extensin, sistemas que poseen caractersticas necesarias para satisfacer esos requerimientos ahora y en el futuro. El propsito 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, organizacional y tcnico.
13
Una definicin 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 organizacin de un sistema de software La seleccin de los elementos estructurales y sus interfaces a partir de las cuales se compone el sistema. La composicin de estos elementos en sub sistemas ms grandes El estilo arquitectural que gua a la organizacin, estos elementos y sus interfaces, colaboraciones y su composicin. Otra definicin tomada de IEEE Std 1472000, dice La arquitectura es la organizacin fundamental de un sistema enfocada en sus componentes, relacionas entre ellos, y el entorno, y los principios que guan su diseo y evolucin. La mayora de las definiciones estn de acuerdo en que la arquitectura describe la composicin de los sistemas, pero difieren en la perspectiva de lo que es un sistema y que implica la composicin. 1.7.2. Proceso de Negocio Proceso de Negocio significa una coleccin de actividades de negocio que toma una o ms clases de entradas y crea una salida que es de valor al negocio. Una cita de W. Edwards Demming, fundador del movimiento de calidad dice: Si no podemos describir lo que ests haciendo como un proceso, no sabes lo que ests haciendo Una definicin comn es: Un Proceso de Negocio es una secuencia de tareas que ocurren en un orden definido, es ejecutado por humanos y/o sistemas para lograr una meta de negocio [32] La definicin muestra algunos puntos importantes:
Referencias Bibliogrficas 14
tarea: Una tarea es un tipo de actividad en la compaa, atmica en contexto, que contribuye para la obtener y completar una meta de negocio. En el mundo real una tarea puede ser: Firmar un contrato, contratar un empleado, revisar un documento, pagar una factura, calcular un descuento, restaurar un archivo, llenar un formulario, etc. Deben ser descritas con un verbo y un nombre que representa el lugar donde est siendo aplicada la accin.
secuencia: La secuencia demanda un orden lgico en el que las acciones deben ser ejecutadas. Este tipo de secuencia en escenarios reales puede ser vista como: Comprador compra un tem -> Comprador paga la factura -> Enviar la orden al comprador. Algo importante es que la secuencia no cambia, a menos de que ocurran cambios en las metas de negocio. Tambin se puede notar que la secuencia no es realizada por una persona; hay un tipo de interaccin entre un grupo de personas.
ejecutado por humanos y/o sistemas: Aqu se ve quin realiza estas actividades. Los humanos son lentos, cuando se les asigna una tarea, esta debe esperar que el humano la realice. Los sistemas por otra parte, solo ejecutan la accin lo ms rpido que pueden, o cuando la accin es necesaria.
Lograr una meta de negocio: Es la meta principal del trabajo.
1.7.3. Gestin de Procesos de Negocio (BPM) Se llama Gestin de procesos de negocio (Business Process Management o BPM en ingls) a la metodologa empresarial cuyo objetivo es mejorar la eficiencia a travs de la gestin sistemtica de los procesos de negocio, que se deben modelar, automatizar, y optimizar de forma continua. Como su nombre sugiere, BPM se enfoca en la administracin de los procesos del negocio. A travs del modelado de las actividades y procesos puede lograrse un mejor entendimiento del negocio y muchas veces esto presenta la oportunidad de mejorarlos. La automatizacin de los procesos reduce errores, asegurando que los mismos se comporten siempre de la misma manera y dando elementos que permitan visualizar el estado de los mismos. La administracin de los procesos permite asegurar que los mismos se ejecuten eficientemente, y la obtencin de
informacin que luego puede ser usada para mejorarlos. Es a travs de la informacin que se obtiene de la ejecucin diaria de los procesos, que se puede identificar posibles ineficiencias en los mismos, y actuar sobre las mismas para optimizarlos. 1.7.4. Aplicaciones empresariales Una aplicacin empresarial es la automatizacin de un proceso de negocio, o la automatizacin de funciones de negocio. 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 electrnica para que pueda ser convertido en informacin. El propsito no solo es soportar los procesos y funciones de negocio de la aplicacin sino tambin hacer los datos disponibles para producir informacin valiosa y otras funciones y proceso de negocio automatizados para otros negocios y unidades a lo largo de la empresa. Cuando el uso de estas aplicaciones de negocio estaba limitado a un nmero pequeo de personas que eran las nicas que manejaban estas funciones y procesos, no haba necesidad de descomponer estas aplicaciones y modularizar sus capacidades. No haba necesidad de exponer subconjuntos de funcionalidades de aplicacin para que puedan ser accedidas y usadas por una audiencia mayor de usuarios o de una forma diferente. Desafortunadamente, cuando esta necesidad surgi, el modelo adoptado, era replicar los datos necesarios y duplicar la lgica necesaria para proveer este subconjunto de capacidades en aplicaciones nuevas y separadas. Este era un enfoque costoso y que tomaba mucho tiempo. Debido a la sobrecarga de costo y tiempo, la mayora de las veces la forma en que encaraban la necesidad de informacin a lo largo de mltiples aplicaciones de negocio fue a travs de la inclusin de un humano en el proceso. Estos enfoques todava se usan hoy en da. En el pasado, el enfoque tradicional que requera que los usuarios tengan acceso a varias aplicaciones y conocimiento de mltiples interfaces de usuario para efectuar una actividad de negocio, era plausible. Era plausible porque la compaa controlaba el usuario (empleado) y tena el compromiso y el tiempo de capacitar a los empleados para navegar y usar todas las aplicaciones de negocio necesarias.
Estas complejidades eran ocultadas al cliente externo. La habilidad de servir al cliente externo estaba basada en una combinacin de varios sistemas usados por la compaa. Sin embargo, la interaccin con el cliente externo requera acceso a informacin o al procesamiento de una transaccin que no era realizado por el empleado que lo atenda [36]. 1.7.5. Integracin Punto a Punto El desarrollo de software hoy en da es orientado al proyecto. Los desarrolladores y arquitectos frecuentemente piensan en trminos de aplicaciones de software individuales, y sus diseos e implementaciones reflejan directamente este pensamiento. Como resultado, las aplicaciones individuales son integradas directamente con otra de una forma punto-a-punto. [42] Una integracin punto a punto ocurre cuando una aplicacin depende de otra. Por ejemplo en la figura, la aplicacin de Administrador de Contactos y Clientes (ACC) usa la interface Sistema de Facturacin. Se dice que la aplicacin CCM sabe sobre la aplicacin Sistema de Facturacin. Esto tipo de relacin tambin se la conoce como dependencia, porque una aplicacin depende de otra para funcionar correctamente.
<<componente>> Administrador de Contactos y Clientes
Facturacin
Facturacin usa ACC
<<componente>> Sistema de Facturacin
Fig 2.1. Integraciones punto a punto Fuente: (42)
17
La figura ilustra un entorno trivial, con solo dos aplicaciones y dos integraciones punto a punto. Para ser claro, la primera integracin permite al sistema ACC llamar a la aplicacin de Sistema de Facturacin. El segundo punto de integracin permite a la aplicacin de Sistema de Facturacin llamar al sistema ACC. Cuando el departamento de Tecnologas de la Informacin es pequeo, la integracin punto a punto es fcil de manejar. La figura 2 expande un poco el problema. Ahora la empresa tiene 8 sistemas de software y un total de 11 puntos de integracin. Esto ilustra un patrn comn en integracin: el nmero de puntos de integracin crece ms rpido que los sistemas que integramos. Tener ciertos sistemas de software duplicados o tener un gran nmero de sistemas de software es muy comn; grandes compaas pueden adquirir otras ms pequeas (por tanto adquieren el software de la compaa ms pequea) ms rpido de lo que pueden integrar estos nuevos sistemas adquiridos.
IO usa SF AC usa SF <<componente>> Sitio Web Atencin al Cliente Sitio Web usa AC <<componente>> Atencin al Cliente (AC) AC usa IO AC usa CP AC usa SI AC usa SI SF usa AC <<componente>> Sistema de Facturacin (SF) <<componente>> Administrador Contactos y Clientes (ACC) ACC usa SF
<<componente>> Ingreso de Ordenes (IO)
<<componente>> Catlogo de Productos (CP)
<<componente>> Sistema de Precios (SI)
<<componente>> Servicio de Inventario (SI)
Fig 2.2. Integraciones punto a punto de 8 sistemas Fuente: (42)

1.7.6. Metodologas de desarrollo de software y su evolucin Las metodologas de desarrollo de software tradicional deben mucho a las races de su ingeniera. El enfoque cascada para el desarrollo de software fue diseado con la idea de que construir una pieza de software es como construir un puente: mientras mejor sea el diseo y el anteproyecto, mejor ser el resultado. En la realidad, este enfoque est muy lejos de la perfeccin. Desarrollar aplicaciones empresariales se trata de entregar valor a un negocio, y el negocio expresa ese valor como un conjunto de requerimientos de negocio. El problema con el enfoque en cascada, y su comparacin con la construccin de un puente, es que a diferencia de las leyes de la fsica y las propiedades de la construccin de metal y concreto, los requerimientos de negocio estn sujetos a cambio. Los negocios no pueden permanecer estables: si no se adaptan al mercado y los cambios necesarios estos no sobrevivirn. Entonces los requerimientos de negocio son necesariamente un objetivo cambiante. Desafortunadamente, este no es el nico problema de las metodologas de desarrollo de software tradicional. Existe tambin el problema de la disonancia de los requerimientos de negocio. Aqu es donde las capas de los usuarios finales, analistas y desarrolladores crean una cadena de susurros chinos [], resultando en software que falla en satisfacer el requerimiento original. Cada eslabn en la cadena pone su propia interpretacin del requerimiento, hasta que el resultado final es diferente de lo que el negocio originalmente necesitaba. Esta disonancia de requerimientos se muestra en la figura:
Interpretacin
Requerimiento
Interpretacin
Interpretacin
Interpretacin
Software final
Usuario Final
Analista de Negocio
Desarrollador
Fig. 2.3 Disonancia en los requerimientos
19
Fuente: (36) Hoy en da, el enfoque tradicional en cascada para el desarrollo de software ha sido remplazado por otras metodologas ms adaptables. Estas metodologas intentan eliminar la disonancia de requerimientos tratando de eliminar el hombre en el medio donde sea posible, y creando prototipos tempranamente, para luego iterar hasta la versin final. Esto permite un enfoque iterativo para el desarrollo de software con mejoras:
Comparacin
Software final
Interpretacin
Requerimiento
Usuario Final
Interpretacin
Interpretacin
Desarrollador
Fig. 2.4. Metodologa gil Fuente: (36) Lo ms destacado de estas mejoras es la metodologa gil. Aplicada al proyecto correcto, el desarrollo gil puede entregar software de valor ms rpido y de manera ms eficiente que el enfoque en cascada. A pesar de eso, el desarrollo gil todava tiene serias desventajas y limitaciones, la ms obvia es que elimina al Analista de Negocios. Esta es una desventaja importante ya que casi siempre la interpretacin del Analista de Negocios es ms lgica y con vistas a futuro que la del Usuario Final que especifica el requerimiento original. Esto puede llevar al desarrollador a callejones sin salida gracias a un Usuario Final que no tiene la perspectiva necesaria. Tambin
20
est el problema de que aunque se eliminan capas de interpretacin, las que se dejan son las que causan mayor disonancia: el desarrollador todava tiene que interpretar que quiere decir el Usuario Final. Esto lleva a prdida de tiempo en la realizacin de un prototipo que comienza muy lejos de lo que el negocio necesita. Entonces aparece el concepto de Administracin de Procesos de Negocio (BPM). Una situacin ideal sera una donde los Usuarios de Negocio puedan construir el software que necesitan ellos mismos, sin tener que usar a los desarrolladores y analistas. Desafortunadamente, y aunque los lenguajes de programacin son cada vez ms simples, an estamos a aos luz de que esto suceda. Sin embargo, BPM avanza un poco hacia este ideal, y en el escenario correcto, puede entregar exitosamente software de valor en periodos de tiempo muy cortos. De forma parecida a la metodologa gil, BPM se basa en eliminar el hombre en el medio donde sea posible, 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.
21
Generacin
Requerimiento
Interpretacin
Interpretacin
de Software
Requerimiento
Usuario Final
Analista de Negocio
Modelado Comparacin
Requerimiento Modelado
Fig. 2.5. Metodologa BPM Fuente: (36) El reintegro del Analista de Negocio tiene ciertas ventajas: El Analista de negocio es entrenado en la interpretacin de requerimientos, para que los modelos de procesos de negocio estn ms cerca al requerimiento original. Los modelos de los Analistas de Negocio son mucho ms fciles de entender por un Usuario Final que el cdigo o un prototipo de software, permitiendo colaboracin ms cercana y un desarrollo ms rpido. Los modelos usualmente pueden ser producidos ms rpido que el software. Debido a que el software producido por un sistema BPM es inicialmente generado del modelo de proceso del Analista de Negocio, este es un mtodo extraordinariamente rpido para desarrollar software. Esto no significa que los desarrolladores ya no son requeridos. La realidad del desarrollo BPM es que hace la relacin entre el Usuario, el Analista de Negocio y el desarrollador ms simbitica y productiva, pero no hace redundantes estos roles. BPM es un enfoque de colaboracin para el desarrollo de software; por una parte entre el Usuario Final y el Analista de Negocio, y por otra entre el Analista de Negocio y el Desarrollador. Las capacidades del desarrollador son necesarias para poder implementar el sistema BPM.
1.7.7. Integracin de Aplicaciones Empresariales El trmino Integracin de Aplicaciones Empresariales (EAI) se ha vuelto popular con el crecimiento de la importancia de la integracin, y con proyectos de integracin ms extensos. EAI no es un producto o un framework de integracin especfico, pero puede ser definido como la combinacin de procesos, software, estndares, y hardware que permiten la integracin 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 aplicacin conectada (Linthicum 200) Desde una perspectiva de negocio, EAI puede ser visto como la ventaja competitiva que adquiere una compaa cuando todas sus aplicaciones son integradas en un solo sistema de informacin consistente. Desde una perspectiva tcnica, EAI es el proceso en el que aplicaciones heterogneas, funciones y datos son integrados, para poder permitir el uso compartido de datos y la integracin de procesos de negocios a lo largo de todas las aplicaciones. El propsito es lograr este nivel de integracin sin grandes cambios a las aplicaciones existentes y bases de datos, usando mtodos eficientes que sean efectivos en cuanto a costo y tiempo. EAI est enfocado principalmente en la integracin tcnica de una aplicacin. Los productos middleware son usados como herramientas de integracin, pero, donde sea posible, el diseo e implementacin de las aplicaciones quedan sin cambios. Los adaptadores permiten a la informacin y datos ser transportados a lo largo de estructuras heterogneas y fronteras. El concepto de servicio no existe, as como la reduccin de complejidad y redundancia. El concepto de servicio y estandarizacin solo vino ms tarde con la emergencia de la Arquitectura Orientada al servicio (SOA), que remarc la importancia de enfocarse en niveles funcionales dentro de la compaa, y sus procesos de negocio.
23
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 travs del uso de Servicios Web, adems identifica mejores prcticas para la implementacin de SOA y los pasos para migrar exitosamente sistemas legados a sistemas orientados al servicio. Jenny Franzen. Factors to Succeed With SOA. Tesis de Maestra en Informtica para IT University of Goteborg. Suecia, 2008.
El propsito 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 propsito de la tesis es responder a la pregunta de investigacin 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 metodologas que competen al modelo arquitectural de SOA. El desarrollo de aplicaciones basadas en el servicio, enfoques de integracin, tecnologas para el desarrollo de SOA, frameworks y otros requerimientos son tratados en este estudio para lograr una figura exacta de SOA.
1.9. Marco terico de ingeniera

1.9.1. Antecedentes y evolucin de la Arquitectura de Software Las empresas y negocios fueron las primeras en adoptar las tecnologas de cmputo fuera de los establecimientos gubernamentales y militares. Grandes empresas invirtieron en varias partes del negocio desde terminales Punto de Venta (POS) a computadoras Mainframe.
Inicialmente los mainframes provean 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 pequeos de red, resulto en lo que se conoce como una de las arquitecturas ms importantes: cliente/servidor. Muchas de las arquitecturas que evolucionaron ms tarde fueron influenciadas por esta arquitectura. La evolucin de las arquitecturas distribuidas puede ser considerada una extensin 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 desafos y oportunidades han causado que la arquitectura sea gobernada por requerimientos no funcionales de las empresas. Algunos de los requerimientos no funcionales incluyen desempeo, confiabilidad, disponibilidad y seguridad. Las empresas evolucionan constantemente, as tambin como las Tecnologas de la Informacin. Explicamos esta evolucin como progresin, y podemos dividirlas en dos: Progresin de la Arquitectura del lado del servidor y Progresin de la Arquitectura de lado del Cliente. 1.9.2. Evolucin 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 progresin 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 an estn presentes en la era de Internet. Ninguna de estas arquitecturas desapareci por completo. Esto puede ser atribuido al Retorno de Inversin (ROI), dependencia del vendedor, etc. Es importante notar que las
nuevas tecnologas necesitan ser integradas con sistemas existentes. Estos sistemas son llamados Sistemas Legados [33].
Fig. 2.6. Progresin en las arquitecturas del lado Servidor Fuente: (33) 1.9.3. Progresin de la Arquitectura Mainframe Inicialmente, las computadoras mainframe dominaban las Tecnologas de la Informacin. Compaas como IBM y Digital dominaron el escenario por un gran periodo. Los sistemas Mainframe eran grandes, caros y solo podan ser adquiridas por corporaciones de gran o mediano tamao. Estos sistemas representaban el msculo 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 tambin a otros perifricos como impresoras, unidades de disco, lectores de tarjetas, etc. Vale la pena mencionar que algunas versiones de sistemas de mainframe no tenan 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.
La figura 4.7 muestra el modelo centralizado de la arquitectura mainframe. El sistema se encuentra conectado a varias terminales.
Figura 2.7. Modelo Centralizado de la Arquitectura Mainframe Fuente: (33) El sistema mainframe soportaba una memoria principal en la que la aplicacin era cargada para su ejecucin. La memoria secundaria de estos sistemas almacenaban las aplicaciones de los usuarios. Sin embargo, estas aplicaciones estaban atadas completamente al sistema mainframe y podan ser usadas solo dentro de unos lmites impuestos por el mainframe. Muchos fabricantes de mainframe vendan aplicaciones utilitarias que estaban disponibles para todos los usuarios del sistema mainframe. Estas aplicaciones utilitarias eran provistas en forma de sub rutinas. (5) Las subrutinas eran esencialmente algoritmos matemticos codificados en un lenguaje de programacin como FORTRAN. Una coleccin de esas sub rutinas era conocida como una librera. Cualquier individuo interesado en usar este servicio necesitaba llamar a la sub rutina apropiada desde su entorno de programacin. Organizaciones como el
Numerical Algorithms Group (NAG), International Mathematics and Statistics Library (IMSL), proveyeron sub rutinas en una variedad de sistemas mainframe. Estas sub rutinas provean una variedad de servicios para empresas, cientficos, ingenieros, etc. IBM Corporation provey varias sub rutinas relacionadas con el negocio que podan ser usadas por las aplicaciones apropiadas para llevar a cabo tareas de negocio como ordenar, indexar, etc. Los sistemas mainframe han sido el backbone de muchas grandes empresas por mucho tiempo, y muchas aplicaciones desarrolladas en esos sistemas mainframe todava son consideradas relevantes hoy en da. 1.9.4. Progresin de la Arquitectura Cliente/Servidor El trmino cliente/servidor corresponde a un modelo de computacin donde las aplicaciones cliente corriendo en una computadora personal acceden a informacin en servidores remotos. La porcin cliente de la aplicacin esta optimizada tpicamente para la interaccin con el usuario, mientras que la porcin servidor provee un acceso centralizado y funcionalidad multi usuario. La arquitectura cliente/servidor apareci a finales de 1970. El desarrollo de la arquitectura cliente/servidor sigui de cerca la aparicin de computadoras ms pequeas y baratas como las microcomputadoras, minicomputadoras, y estaciones de trabajo. Al contrario de lo que ocurra con los sistemas mainframe, estos sistemas ms pequeos eran asequibles para las Medianas Y Pequeas Empresas. La posibilidad de poner en red esos sistemas dentro de la organizacin provey la base para la aparicin de la arquitectura de dos-capas. En esta arquitectura, la aplicacin (y datos) y las interfaces de usuario podan manejar dos sistemas de manera diferente. Mientras el sistema servidor poda almacenar aplicaciones y datos, el sistema cliente poda manejar la interaccin con el usuario. La figura 2.8 muestra el concepto simplista de la arquitectura cliente/servidor.
28
Fig. 2.8. Una representacin simple de la Arquitectura cliente/servidor Fuente: (33) A mediados de 1998 las computadoras de escritorio hicieron una revolucin. Estos sistemas, conocidos como Computadoras Personales (PC), podan ser adquiridos por individuos y profesionales. La proliferacin de las PC provey un entrono cliente ideal para la arquitectura cliente/servidor. El entorno de red de dichas computadoras brind facilidades de cmputo de negocio a un costo aceptable para el SMB. La asequibilidad de computadoras pequeas 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 residan en el servidor, y las aplicaciones de acceso a datos eran ejecutadas en el sistema servidor. La lgica de aplicaciones de negocio poda ser ejecutaba en el servidor o el cliente
29
El servidor tambin provea comparticin de recursos para todos los clientes.
El entorno cliente/servidor provea un entorno ideal para los individuos que podan desarrollar una cantidad de programas y aplicaciones. Las contribuciones de individuos y profesionales, un ciclo de desarrollo de aplicacin relativamente corto, la disponibilidad de una variedad de aplicaciones, el costo del sistema, etc. Contribuyeron enormemente al gran crecimiento de las computadoras de escritorio. 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. Permitiendo a las PCs, minicomputadoras, y mainframes coexistir, la arquitectura cliente foment a la empresa a distribuir tareas especficas a sistemas apropiados. Por ejemplo, los sistemas ms potentes, como las minicomputadoras, eran conocidos como servidores para almacenar los datos, y los sistemas menos potentes provean un entorno cliente perfecto [33]. 1.9.5. Progresin de la Arquitectura Distribuida La arquitectura distribuida provea un entorno en el que las aplicaciones podan ser divididas y distribuidas entre varios sistemas en un entorno de red. Estas aplicaciones se ejecutaban en sus sistemas individuales, y los resultados eran combinados para producir el resultado final. Dichos sistemas distribuidos, trabajando juntos, podan superar a los sistemas mainframe. En las arquitecturas distribuidas, ninguna aplicacin tiene un rol privilegiado y un proceso no depende de otro. La arquitectura distribuida, por tanto, permite a varias computadoras estar en red y que las aplicaciones sean desplegadas de una manera distribuida. La arquitectura distribuida porvee mltiples capas para el entorno de cmputo. Por tanto, la arquitectura distribuida, no es diferente de la arquitectura cliente/servidor. La arquitectura cliente/servidor puede ser solo un subconjunto de la arquitectura distribuida, en la que hay solo dos capas: cliente y servidor. Los entornos operativos de estos sistemas distribuidos provean servicios bsicos como comparticin de recursos, impresin, transferencia de archivos, etc. Algunas arquitecturas distribuidas incluyen: System Netowrk Architectura (SNA) de IBM, Distributed Network Architecture (DNA) de DEC, etc.
30
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 ms redes distribuidas. Esto sucedi en empresas que tenan despliegues de mltiples fabricantes en diferentes departamentos. Esta incompatibilidad llev a la industria hacia los sistemas abiertos y la aparicin de protocolos de comunicacin como TCP/IP. El crecimiento de la arquitectura distribuida tiene cuatro aspectos importantes: Llamadas a procedimientos remotos Acceso remoto a base de datos Procesamiento de transacciones distribuido Mensajera
Entre estos, el Llamado a Procedimientos Remotos (RPC) y la Mensajera representan mecanismos potentes que ayudan a lograr la integracin entre diferentes plataformas. Los siguientes subttulos explican cmo estos nos ayudan en el desarrollo y despliegue de servicios en una arquitectura distribuida [33]. 1.9.6. 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. Este modelo permita a los sistemas en una red comunicarse en un entorno de arquitectura distribuida. La figura 2.9 muestra una representacin de cmo los modelos RPC trabajan en un entorno distribuido. Diferentes fabricantes implementaron RPC de diferentes maneras.
31
Fig. 2.9. Llamadas a Procedimientos Remotos Fuente: (33) La implementacin de Sun Microsystems es Sun RPC. El Mtodo Remoto de Invocacin (RMI) es de las tecnologas Java. Esta tecnologa fue introducida a finales de 1990. Common Object Request Broker Architecture (CORBA) de Object Management Group (OMG) es una generalizacin de RPC. El modelo OMG inclua mejoras en el objeto del modelo RPC. CORBA hace posible el desarrollo de aplicaciones y servicios que sean interoperables y puedan comunicarse con otras aplicaciones diferentes. Esta arquitectura fue desarrollada por OMG para brindar portabilidad e interoperabilidad a lo largo de diferentes plataformas de hardware y entornos operativos. La base de Microsoft Distributed Component Object Model (DCOM) esencialmente emergi del Compontent Model Object (COM) introducido a mediados de 1990. La tecnologa COM permite el desarrollo de componentes de software, como especificaciones COM, para integrar las aplicaciones en la red. En un entorno distribuido, tales componentes pueden interactuar en una manera inter operable. DCOM se construye con la capa RPC, que permite la comunicacin entre objetos remotos. Otras tecnologas de Microsoft, como Object Linking and Embedding (OLE), ActiveX, y Microsoft Transaction Server (MTS), se construyen en la cima de las tecnologas COM y DCOM.
32
1.9.7. Mensajera Todas las comunicaciones discutidas anteriormente se refieren a un modo de comunicacin sncrono o de modo de bloqueo. La mensajera por otra parte, introduce comunicacin asncrona a la arquitectura distribuida. La tecnologa de mensajera introduce servidores de mensajes, que pueden entregar o recibir mensajes de aplicaciones. MQSeries de IBM, MSMQ de Microsoft, y SonicMQ de Progress son algunas implementaciones populares de tecnologas de mensajera. La tecnologa de mensajera es conocida como Messaging Oriented Middleware (MOM). MOM es una implementacin de software en los sistemas distribuidos o cliente/servidor que residen en el lado cliente y servidor. Esto permite a los sistemas distribuidos o cliente/servidor comunicarse asncronamente, por tanto incrementando la flexibilidad de la arquitectura distribuida. Las tecnologas de mensajera permiten enviar o recibir mensajes entre dos o ms aplicaciones en red en una arquitectura distribuida y puede ser de forma sncrona o asncrona. En el modelo de Comunicacin Asncrona, la comunicacin entre dos aplicaciones se bloquea hasta que el intercambio de mensajes se completa y puede ser comparado con un modelo de comunicacin RPC. En el Modelo de Comunicacin Asncrono, el remitente y receptor no necesitan
ejecutarse al mismo tiempo. El remitente puede enviar mensajes, y el mensaje ser enviado al receptor cuando este est conectado al sistema. 1.9.8. Arquitectura Orientada al Servicio (SOA) Los conceptos que hoy en da estn asociados con SOA comenzaron a surgir con la adopcin de internet, ms especficamente, HTTP. El ao 2003, Roy Schutle de Gartner Group haba acuado el trmino SOA, y fue difundido rpidamente. Qu es lo que era, exactamente, segua como algo difcil de cuantificar. Con el paso del tiempo, aparecieron varias cosas comunes en las diferentes definiciones: Arquitectura Orientada al Servicio representa una arquitectura componible, abierta, gil, extensible y federada compuesta de servicios potencialmente re usables, autnomos, de diversos fabricantes, interoperables y descubribles, implementados como Servicios Web.
33
SOA puede establecer una abstraccin de lgica de negocio y tecnologa que puede introducir cambios en el modelado del proceso de negocio y la arquitectura tcnica, resultando en un dbil acoplamiento entre estos modelos. SOA es una evolucin de las plataformas pasadas, preservando las caractersticas exitosas de las arquitecturas tradicionales, que trae consigo distintos principios que fomentan la orientacin al servicio. SOA es una forma de tecnologa de arquitectura que se adhiere a los principios de la orientacin al servicio. Cuando es realizada a travs de Servicios Web, SOA establece el potencial para soportar y promover estos principios a lo largo de los procesos de negocio de una empresa. [4] La arquitectura Orientada al Servicio es una estrategia de las Tecnologas de la Informacin que organiza funciones discretas contenidas en aplicaciones de negocio en servicios inter operables, basados en estndares que pueden ser combinados y re usados rpidamente 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
Mensajera
Rou
Aplicaciones Empresariales
APP 1
APP 2
APP 3
APP 4
Fig 2.10. Ilustracin de un entorno SOA. Fuente: (31)
34
La figura 2.2 muestra la relacin entre las aplicaciones, servicios, y procesos de negocio orquestados. Los servicios de bajo nivel (o de fina granularidad) representan la capa de la cima de las aplicaciones empresariales. Estos componentes permiten a las capas inferiores interactuar con estos sistemas. La capa de servicios compuestos representa servicios de gruesa granularidad que consisten de dos o ms componentes. En muchos aspectos, SOA es una partida de los viejos modelos de computacin distribuida, que estaban centrados en el intercambio de objetos distribuidos y funciones remotas. SOA en cambio, hace nfasis en una afiliacin de servicios dbilmente acoplados que son autnomos por naturaleza. 1.9.9. Principios de la Orientacin al Servicio Dbil Acoplamiento: Los servicios mantienen una relacin que minimiza dependencias. Contrato de Servicio: Los servicios se adhieren a un acuerdo de comunicacin, definido por una o ms descripciones de servicio y documentos relacionados. Autonoma: Los servicios tienen control sobre la lgica que encapsulan. Abstraccin: Mas all de lo que se describe en el contrato de servicio, los servicios ocultan lgica del mundo exterior. Reusabilidad: La lgica se divide en servicio con la intencin de promover el re uso. Componibilidad: Colecciones de servicios pueden ser coordinadas y ensambladas para formar servicios compuestos. Carencia de Estado: Los servicios minimizan la retencin de informacin especfica a una actividad. Descubrimiento: Los servicios son diseados para ser descriptivos para as poder ser encontrados y accedidos a travs de mecanismos disponibles de descubrimiento.
35
Implementa un contrato estndar
Contrato de Servicio Estandarizado
Dbil Acoplamiento de Servicio
Minimizar dependencias
Implementa lgica re usable Minimiza la disponibilidad de
Re usabilidad de Servicio
Abstraccin del Servicio
meta informacin
Implementa frontera independiente y un entorno de ejecucin
Autonoma de Servicio
Componibilidad de Servicio
Maximiza la componibilidad
Implementa lgica adaptativa y libre de administracin de estado
Carencia de Estado del Servicio
Implementan meta informacin comunicativa
Descubrimiento de Servicios
Servicio
Fig. 2.11. Los principios de SOA Fuente: (43) 1.9.10. Servicio Un servicio es un mecanismo que brinda acceso a una o ms capacidades, donde el acceso es provisto usando una interfaz y es regulado por las polticas especificadas por la descripcin del servicio. [14] Se puede acceder a un servicio mediante una interfaz de servicio, donde la interfaz tiene las especificaciones para acceder a las capacidades del servicio. La consecuencia de la invocacin de un servicio es la realizacin de uno o ms efectos del mundo real entre ellos:
Informacin devuelta en respuesta a una solicitud de esa informacin Un cambio de estado de entidades definidas
El consumidor del servicio en el primer caso no conoce la manera en que se genera la informacin, pudiendo ser extrada de una base de datos o generada dinmicamente; en el segundo caso no conoce de qu manera se cambi el estado. Un servicio puede ser considerado como un contenedor de capacidades asociadas con un propsito comn. Existen tres implementaciones comunes de servicios: Servicios Web, componentes y servicios REST. [43] 1.9.11. Servicios Web Un Servicio Web es una manera de compartir lgica de aplicacin a lo largo de varias mquinas corriendo sobre diferentes sistemas operativos y usando diferentes entornos de desarrollo. Para lograr esto, los Servicios Web usan SOAP, WSDL, Esquema XML, el Registro Universal de Descubrimiento, Descripcin e Integracin (UDDI) y otras tecnologas basadas en XML, para proveer un enfoque basado en estndares para sobreponerse a las diferencias de plataforma y lenguaje. [26] La orientacin al servicio puede ser aplicada al diseo de los Servicios Web. El hecho de que los Servicios Web proveen un modelo arquitectural ya que el contrato de servicio es independiente de la plataforma, es ideal para el diseo de metas asociadas con la orientacin al servicio. 1.9.11.1. SOAP
SOAP es un protocolo de mensajera usado para transferir datos de aplicacin en formato XML sobre un protocolo de transporte como HTTP. Hoy en da, las aplicaciones de Servicios Web usan SOAP como protocolo estndar para el intercambio de informacin de forma descentralizada y distribuida. [26]. Las interfaces basadas en SOAP interactan entre ellas mediante mensajes SOAP con formato XML para llevar datos y meta datos. La estructura de un mensaje SOAP es la siguiente:
37
<SOAP-ENV:Envelope ` <SOAP_ENV:Header> .. .. </SOAP_ENV:Header> <SOAP:Body> .. .. </SOAP:Body> </SOAP-ENV:Envelope>
>
1.9.11.2.
WSDL
Una descripcin de servicio WSDL es un documento que describe a los servicios de abajo a arriba. Eso significa que empiezan con los tipos de dato usados y terminan con la ubicacin (direccin) del servicio. Adems, tienen tres capas de descripcin. La primera capa describe la interfaz del servicio. Esta interfaz puede consistir de una o ms operaciones con parmetros de entrada y salida que usan tipos especificados en la primera seccin del archivo WSDL. 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. La tercera capa define la ubicacin fsica (direccin, URL) donde el Servicio Web est disponible.
38
Fig. 2.12. Estructura de un documento WSDL Fuente: (44) 1.9.11.3. UDDI
UDDI (Descripcin Universal, Descubrimiento, e Integracin )es un estndar para el registro y bsqueda de Servicios Web dentro de directorios como si fueran pginas amarillas- que contienen Servicios Web. La principal funcin de UDDI es proveer descubrimiento de servicio. Primero, un proveedor de servicio usa UDDI para almacenar datos del servicio (descripcin de servicio, autor, ubicacin y las interfaces para acceder al mismo). Usando estos elementos consumidores potenciales de Servicios Web pueden buscarlos. Luego el consumidor potencial puede usar UDDI para ubicar un servicio apropiado. Esto puede ser realizado mediante un humano usando un navegador o programticamente [45]. 1.9.11.4. Esquema XML
Un mensaje SOAP puede contener cualquier tipo de dato, y se necesita una forma de expresar la estructura de un mensaje, adems de una forma de determinar el tipo de dato que debe aparecer dentro de un mensaje. Un Esquema XML es una forma estndar de describir la estructura y el tipo de informacin que debe estar presente dentro de un mensaje XML
enviado a un Servicio Web. Este esquema necesita ser estandarizado y estar acompaado por un conjunto de APIs que puedan ser usadas para validar un documento XML contra su esquema. 1.9.12. Interfaz de Servicio Los servicios deben tener un contrato o una interfaz bien definida. Un contrato es la especificacin completa de un servicio entre un proveedor de servicio y un consumidor especfico. Debe existir de manera que pueda ser legible por los posibles clientes. Este contrato debe identificar qu operaciones estn disponibles, definir los requerimientos de datos para la informacin intercambiada, y detallar cmo el servicio ser invocado. WSDL es un ejemplo de contrato, ya que adems de describir las operaciones soportadas por el servicio, tambin incorpora un Esquema XML que describe el formato del mensaje XML que ser intercambiado. 1.9.13. Bus de Servicios Empresarial En una Arquitectura Orientada al Servicio, todas las piezas de software se comunican entre ellas mediante mensajes. Estos mensajes deben ser entregados rpidamente y su llegada debe ser garantizada. Para transportar los mensajes entre los componentes de software es cuando se usa un Bus de Servicios Empresarial (ESB). Un ESB es el nervio central de las comunicaciones en una Arquitectura Orientada al Servicio. Como se muestra en la figura, los ESBs son diseados para actuar como intermediarios entre los componentes SOA, servicios de infraestructura, y procesos de negocio.
40
Fig. 2.13. Bus de Servicios Empresarial Fuente: (6) Los servicios ofrecidos por un ESB son: Servicios de Mensajera: Soportan varios tipos de mensajera, proveen enrutamiento inteligente basado en contenido, y garantizan la entrega de mensajes. Servicios de Administracin: Pueden monitorear su propio redimiendo, ayudando a mejorar los SLAs (Acuerdos de Nivel de Servicio) grabando y respondiendo a la latencia de mensajes. Pueden implementar prioridades de mensajes y aplicar reglas de negocio a lo largo de las aplicaciones o componentes que conectan. Servicios de Interfaz: pueden validar mensajes contra sus definiciones de esquema. Soportan estndares de Servicios Web y proveen adaptadores de aplicacin para interfaces que no son del tipo Servicio Web.
41
Servicios de Mediacin: transforman los mensajes entre formatos usados por aplicaciones que los envan y reciben.
Servicios de Metadata: relacionados a la mediacin, estos servicios pueden transformar datos de un formato a otro usando definiciones de metadata mantenidas en su propia versin de registro.
Servicios de seguridad: encriptan mensajes cuando es necesario e incluyen un modelo estndar de seguridad para autorizar, autenticar y auditar la actividad dentro el ESB.
1.9.14. Registro SOA Una Arquitectura Orientada al Servicio est basada en la interaccin entre tres principales funcionarios: proveedor de servicios, registro de servicios y solicitante de servicios. El proveedor de servicios crea el servicio y publica la descripcin del servicio en el registro. El solicitante de servicios encuentra la descripcin del servicio en el registro y usa la informacin para enlazarse y ejecutar el servicio. El siguiente diagrama ilustra el concepto:
Registro de Servicios
Encontrar
Publicar
Solicitante de Servicios
Enlazar y ejecutar
Proveedor de Servicios
Fig. 2.14. Publicar, Encontrar y Ejecutar servicios Fuente: (45)
42
El registro SOA es un tipo de catalogo electrnico donde almacenamos informacin que describe qu es lo que hace cada componente. 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 informacin de referencia sobre los componentes de software que estn ejecutndose o disponibles para su uso. Por otra parte para los programadores y analistas de negocio, el registro SOA acta como una referencia que ayuda a seleccionar y conectar componentes para crear aplicaciones compuestas y procesos. Tambin almacenan informacin sobre cmo cada componente se conecta con otros. En otras palabras, el Registro SOA documenta las reglas y descripciones asociadas con cada componente dado. El Registro SOA es sumamente importante ya que acta como punto central de referencia dentro de SOA. El registro SOA contiene informacin sobre los componentes de SOA. Por esta razn, se define como el dominio de la arquitectura. [6]
1.10. Seleccin de Tecnologas y Herramientas

1.10.1. Tecnologas para una Arquitectura Orientado al Servicio 1.10.1.1. JBoss
JBoss es una divisin de Red Hat Software, una compaa que ofrece una versin de un sistema operativo de cdigo abierto Linux. Los ofrecimientos de JBoss estn basados en un modelo de cdigo abierto, que significa que aaden capacidades a sus funciones bsicas y trabajan con una comunidad de desarrolladores que aaden aun ms valor a los ofrecimientos de la compaa, pero la compaa es la que gana dinero gracias al soporte de sus productos. 1.10.1.2. JBoss Enterprise SOA Platform
JBoss Enterprise SOA Platform es una plataforma certificada, probada y con soporte para el desarrollo de soluciones de Arquitectura Orientada al Servicio desarrollada por Red Hat. [JBoss Enterprise SOA Platform Getting Starged Guide].
43
Esta plataforma integra varios framework y tecnologas incluyendo Hibernate, Seam, JBoss Transactions, JBoss Clustering, JBoss Application Server, JBoss Enterprise Service Bus (ESB) y JBoss jBPM entre otros para proveer una infraestructura para integrar aplicaciones empresariales SOA. Estos productos desarrollados por comunidades y certificados han sido combinados y probados para proveer una plataforma solida, robusta y escalable. Red Hat define a la su plataforma como simple, abierta y asequible. Asequible porque los costos de licencia son gratuitos, los costos al cliente vienen del mantenimiento, servicio y soporte provisto por JBoss. Abierta porque est dentro de lo que se conoce como open source o cdigo abierto.
Fig. 2.15. JBoss Enterprise SOA Platform Fuente: (SOA Whitepaper) 1.10.1.3. JBoss jBPM
jBPM es una Suite de Administracin de Procesos de Negocio (BPM) flexible. Acta de puente entre los analistas de negocio y desarrolladores. Los motores tradicionales BPM tienen un enfoque limitado a personal no tcnico. jBPM tiene un enfoque dual. Ofrece caractersticas de administracin de procesos de forma que ambos, los usuarios y desarrolladores puedan usarla.
44
jBPM toma las descripciones de proceso como entrada. Un proceso esta compuesto de actividades conectadas con transiciones. Los procesos representan un flujo de ejecucin. El diagrama grfico de un proceso es usado como la base para la comunicacin entre usuarios no tcnicos y desarrolladores. Cada ejecucin de una definicin de proceso es llamada una instancia de proceso. jBPM administra las instancias de proceso. Algunas actividades, como enviar email, o ejecutar un script son automticas. Otras involucran una espera para una ocurrencia externa, como una persona que debe completar una tarea. jBPM sigue el estado de una ejecucin de proceso durante esos periodos de espera. El Lenguaje de Definicin de Procesos de Negocio jBPM (jPDL) es uno de los lenguajes de procesos que se encuentra en la cima de este framework. Es un lenguaje intuitivo, diseado para permitir al usuario expresar los procesos de negocio grficamente. 1.10.1.4. JBoss ESB
JBoss ESB es el pegamento que une todos los componentes de JBoss Enterprise SOA Platform. JBoss obtuvo el ESB (llamado Rosetta) de Aviva Canad, una de las ms grandes compaas de seguros en Canad. La compaa don el ESB a JBoss, y luego JBoss lo hizo disponible como una tecnologa open source. JBoss ESB intermedia las interacciones entre las aplicaciones empresariales, servicios de negocio, componentes de negocio y middleware para integrar y permitir la automatizacin de procesos de negocios. JBoss incluye muchas de las caractersticas de otros ofrecimientos ms caros, incluyendo un registro de servicios y un repositorio de servicios adems de soporte de mltiples servicios de mensajera. 1.10.1.5. Ediciones de JBoss Enterprise SOA Platform
Hay dos formas de la plataforma JBoss disponibles, estas son la edicin Standalone y las ediciones EAP Embedded.
45
EADP Embedded Edition: Es un entorno de despliegue de aplicaciones completo. Esta sola instalacin provee un entorno completo para aplicaciones SOA, incluyendo Hibernate, Seam, y otros servicios.
Edicin Standalone: La edicin Standalone provee una solucin liviana para despliegues donde solo se necesita la funcionalidad central de la Plataforma SOA. La edicin Standalone no incluye componentes JBoss EAP que no son necesarios por los componentes centrales de SOA.
1.10.2. Tecnologas para el desarrollo de la Aplicacin del Caso de Estudio 1.10.2.1. Spring Framework
Spring es un framework basado en Java/J2EE, basado en cdigo publicado en el libro Expert One-on-One J2EE Design and Development por Rob Johnson (Wrox, 2002). Spring incluye: El contenedor ms liviano y completo, que provee una configuracin centralizada y automatizada y el enlazamiento de los objetos de aplicacin. El contenedor es no-invasivo, capaz de ensamblar un sistema complejo a partir de un conjunto de componentes dbilemente acoplados. 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, y luego escalados para el despliegue en cualquier entorno (J2SE o J2EE). Una capa de abstraccin para la administracin de transacciones. Una capa de abstraccin JDBC que ofrece una jerarqua de excepciones, simplifica el manejo de errores, y reduce la cantidad de cdigo necesaria. Integracin con Mapeos de SQL Hibernate, JDO, e iBATIS Un framework de aplicaciones flexible MVC (Modelo Vista Controlador) construido en la cima de la funcionalidad Spring. Este framework es altamente configurable a travs de
46
interfaces y se acomoda a mltiples tecnologas de vista como JSP, Velocity, Tiles, iText y POI.
Fig. 2.16. Un vistazo de los mdulos de Spring Framework Fuente: (39) 1.10.2.2. Spring Web Flow
Spring Web Flow es un mdulo del framework Spring dirigido a definir y gestionar los flujos de pginas dentro de una aplicacin web. El flujo de pginas de una aplicacin web consiste en la secuencia de pginas por las que pasa dicha aplicacin en funcin de la conversacin que mantenga con el usuario. Dependiendo de las opciones que escoja el usuario, resultados de las operaciones de proceso, etc., la aplicacin seguir una ruta de pginas especficas u otra [38].
1.10.2.3.
XFire
XFire es una nueva generacin de framework de cdigo abierto que simplifica la crecin de Servicios Web java. Con XFire, se puede crear Servicios Web a partir de archivos WAR de Servicios Web, directamente a partir de POJOs, que pueden ser desplegados en cualquier contenedor como Tomcat, o Jetty. As tambin como Servlets basados en Tomcat, XFire soporta otras tecnologas de contenedores de aplicaciones livianos como Spring, PicoContrainer y Plexus. XFire puede ser embebido fcilmente dentro de una aplicacin java proveyendo una funcionalidad de servidor o cliente de Servicio Web.
Fig. 2.17. Framework XFire Fuente: (Web Services on XFire Sing Li) 1.10.2.4. Hibernate
Hibernate es el framework de persistencia ms popular dentro de la comunidad Java. Hibernate tiene como objetivo superar la impedancia entre la concordancia entre las aplicaciones orientadas a objetos y bases de datos relacionales.
48
Con Hibernate, se puede tratar a una base de datos como un almacn orientado a objetos. Hibernate es un mediador que conecta un entorno orientado a objetos a un entorno relacionar. Provee servicios de persistencia para una aplicacin realizando las operaciones necesarias en la comunicacin entre entornos orientados a objetos y relacionales. Almacenar, actualizar, eliminar y cargar datos puede ser hecho sin importar la forma de los objetos persistentes. Adems, Hibernate aumenta la efectividad de la aplicacin y rendimiento, hace el cdigo mas conciso, permitiendo al mismo estar ms enfocados en las reglas de negocio que la lgica de persistencia [40].
Fig. 2.18. Estructura del framework Hibernate Fuente: (40)
3. DESARROLLO DEL PROYECTO

3.1. Anlisis de la situacin actual
3.1.1. Antecedentes de la Institucin La Universidad San Francisco Xavier, fundada el 27 de marzo de 1624, es una Institucin Nacional de estudios superiores con personalidad jurdica que goza de autonoma econmica, administrativa, financiera y funcional, conforme al Art. 92 de la Constitucin Poltica del Estado, que se constituye en una de las instituciones ms importantes del pas dentro del rea de la formacin acadmica de miles de universitarios.
Est constituida por dependencias encargadas del rea administrativa, econmica, acadmica y tecnolgica y esa dentro de esta ltima donde est la Direccin de Tecnologas de Informacin y Comunicacin (DTIC) cuyas tareas cubren las necesidades de la institucin en cuanto a tecnologa 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, Administracin de Bases de Datos, Telecomunicaciones y Redes, Carnetizacin y los encargados de soporte tcnico. 3.1.2. Actividad a la que se dedica La Direccin de Tecnologas de Informacin y Comunicacin, dependiente de Vicerrectorado de la Universidad San Francisco Xavier, fue creada fundamentalmente para el manejo de los recursos tecnolgicos de informacin y comunicacin actuales tan necesarios en las
actividades de la Universidad, brinda apoyo a la misma cumpliendo las siguientes funciones: Instalacin y configuracin de redes. Creacin y administracin de Base de Datos. Desarrollo de sistemas. Apoyo y soporte tcnico
Adems de estas funciones principales, la DTIC tambin cumple la funcin de Apoyo Acadmico que se refiere al:
Asesoramiento en la realizacin de varios Proyectos de Investigacin y Proyectos de Grado a alumnos de 9 y 10 semestre de Ingeniera de Sistemas. Capacitacin a alumnos de 8, 9 y 10 semestre de Ingeniera de Sistemas en el rea de diseo, instalacin, mantenimiento y administracin de redes y servicios Internet, bajo la modalidad de pasantas.
50
3.1.3. Misin Propiciar la existencia y uso de las tecnologas de informacin y comunicacin en el mbito universitario en todos sus estamentos; planificar, desarrollar, mantener, administrar y dar soporte al Sistema de informacin Universitaria, el cual est directamente alineado con el plan estratgico organizacional universitario de tal forma que permita el logro de nuevos objetivos organizacionales, aprovechando de manera eficiente los recursos y garantizando la eficiencia, efectividad, confiabilidad, integridad, disponibilidad, confidencialidad y
cumplimiento de la informacin. 3.1.4. Visin Proponer polticas e implementar estrategias, que genere, estimulen, integren y coordinen acciones orientadas al desarrollo y uso de las tecnologas de informacin y comunicacin en la Universidad. La administracin efectiva de la informacin y de la tecnologa relacionada que incrementen el potencial que tienen las TIC para cambiar radicalmente la Universidad, creando nuevas oportunidades, reduciendo costos, administrando riesgos asociados con la implementacin de nueva tecnologa, en un proceso de mejora continua que lleve al xito organizacional. 3.1.5. Valores Calidad: Debe estar en las personas, procesos de toda actividad. Equidad: Como la aplicacin de oportunidades a todos los sujetos y comunidades con el fin de mejorar sus condiciones de vida. Eficiencia: Como el compromiso para el uso ptimo de los recursos fsicos, financieros, humanos y de tiempo para cumplir las acciones propias. Pluralismo: Tolerante, no discriminatoria y que propende hacia la inclusin de hombres y mujeres independiente de su dependencia social, tnica, cultural, poltica o religiosa.
51
Humanismo: Entender al ser humano y su desarrollo integral como el elemento fundamental de todas las acciones de la sociedad, con el respeto absoluto a las dimensiones social, tnica, cultural, poltica y religiosa. Compromiso Social: Actuar con espritu solidario a favor de los sectores ms vulnerables del conjunto social, en defensa y desarrollo de la democracia, el inters pblico, la igualdad, la libertad y la justicia. 3.1.6. Contexto Organizacional Ubicacin de la DTIC dentro de la estructura organizativa de la universidad
Fig. 3.1 Estructura Organizativa de la Universidad Fuente: [1]
52
Estructura de la Direccin de Tecnologas de Informacin y Comunicacin

DTIC Direccin de Tecnologas de Informacin y Comunicacin
Telecomunicaciones y redes
Administracin de Base de Datos
Carnetizacin Desarrollo de Sistemas Informticos
Soporte Tcnico
Fig. 3.2. Estructura de la DTIC Fuente: [1] 3.1.7. Contexto Social Actualmente la Universidad cuenta con 30000 alumnos aproximadamente y todos ellos hacen uso al menos de un sistema, el de Servicios Acadmicos. En cuanto al personal administrativo, se cuenta con un nmero aproximado de 800 personas, de las cuales ms o menos 300 hacen uso de algn Sistema Informtico. Dentro del rea docente, hay ms de XXX personas, cada una de ellas tambin hace uso de Sistemas Informticos, el ms importante es el Sistema de Calificaciones (eDocente). 3.1.8. Contexto Tecnolgico Los Sistemas Informticos dentro de la Universidad han comenzado a desarrollarse a partir de la dcada de los 90, y hasta el da de hoy existen alrededor de 20 Sistemas Informticos. Entre los ms importantes estn: Sistema Integrado de Contabilidad y Presupuestos (SICOPRE): Es el sistema ms antiguo y an en funcionamiento. Es usado por la Direccin Administrativa Financiera (DAF), este
sistema est programado en C sobre UNIX, como base de datos usa Informix y actualmente est siendo remplazado por el Sistema Integrado de Gestin y Modernizacin Administrativa (SIGMA). La migracin hacia este nuevo sistema, en cuanto a base de datos se refiere, fue un proceso manual. Sistema de Seguimiento Acadmico: es otro sistema importante, 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, libreta de notas, kardex, horarios, y matriculaciones. Est basado en una arquitectura cliente-servidor. Sistema de Control de Asistencia: Est programado en Delphi 6, y est encargado de mantener un registro y controlar la asistencia del personal administrativo y docente de la Universidad. Gestin de la configuracin de Redes y Telecomunicaciones: Este sistema se compone de varios sistemas entre ellos: InfraRED: Encargado de administrar y gestionar la ubicacin de los recursos o dispositivos de red. CosticRED: Encargado de la administracin de dispositivos y recursos de red, proveedores, costos, etc. ConfigRED: Encargado de administrar y gestionar las redes dentro de la Universidad, y los dispositivos asociados a cada red. Estos sistemas estn desarrollados en Java sobre una arquitectura J2EE de 5 capas.
3.2.
Anlisis del dominio del problema
Habiendo descrito la situacin actual del sector de las Tecnologas de la Informacin de la Universidad San Francisco Xavier, y usando de tcnicas de recoleccin de datos entre ellas entrevistas y cuestionarios se llegaron a identificar las siguientes necesidades y problemas al interior de la Universidad.
54
3.2.1. Datos replicados innecesariamente La Universidad San Francisco Xavier cuenta con alrededor de 20 sistemas. Cuando cierta Facultad o Departamento necesita una aplicacin o sistema, dicho sistema es desarrollado, para ese fin como casi todas las aplicaciones se requiere un sistema de autenticacin y almacenamiento de datos de usuario. El desarrollador crea su propia base de datos, y rutinas de autenticacin. Como consecuencia, dentro de la universidad hay cada vez ms datos replicados, y rutinas de autenticacin similares en cada una de las aplicaciones existentes. Esto resulta en un esfuerzo innecesario y una prdida de tiempo para el desarrollador. 3.2.2. Lgica de negocio replicada Los obstculos comienzan a surgir cuando se dan cuenta que las necesidades de negocio no son islas aisladas. Toda o una parte de algn proceso de negocio es til para otro. Mientras la habilidad de programar materias a un estudiante, era antes considerada como una actividad netamente interna, ahora los estudiantes pueden programarse directamente a travs de la Web. Estos nuevos sistemas estn influenciados por la forma en que trabaja el antiguo sistema. Para lograr lo mencionado anteriormente, se tuvo que volver a programar las mismas funciones en lenguaje PHP. Para esto se hicieron uso de algunos procedimientos almacenados ya existentes, lo que da lugar a una integracin mediante base de datos, sin embargo esta no es una solucin deseable ya que repetimos cdigo innecesariamente y en caso de que ocurra algn cambio en el Sistema principal de Seguimiento Acadmico, el nuevo sistema en PHP deber ser modificado. 3.2.3. Falta de una Arquitectura bien definida Habiendo explicado las anteriores falencias y teniendo en cuenta la cantidad de sistemas existentes y los que estn an por venir se puede decir que el entorno tecnolgico es bastante complejo. El punto es que, adaptarse a estos cambios evolucionistas sin considerar una arquitectura, conlleva una alta probabilidad de incurrir en costos y esfuerzo excesivos y puede no ser asequible por cuestiones tcnicas o financieras.
55
Mientras la complejidad y el tamao de la infraestructura tecnolgica van creciendo, la necesidad de una arquitectura que maneje y administre estas complejidades se hace presente. 3.2.4. Interoperabilidad de los Sistemas Interoperabilidad es la habilidad del software de diferentes sistemas de comunicarse con otras compartiendo datos y funcionalidad. Dentro la DTIC existe un entorno heterogneo de sistemas los cuales necesitan comunicarse entre ellos 3.2.5. Necesidad de Seguimiento del Ciclo de Vida de Documents Al interior del Departamento de Tecnologas de la Informacin y Comunicacin de la Universidad existe un flujo de documentos de todo tipo. Cada funcionario crea documentos en su propia computadora, por ejemplo cartas, facturas, informes, etc. Estos documentos normalmente vienen dados como ficheros informticos en los formatos tpicos de la ofimtica, como documentos Word y HTML, imgenes, ficheros de texto, documentos escaneados, etc. Otras veces surge la necesidad de generar dichos documentos, normalmente para ser impresos a partir de datos existentes. Por tanto, lo mejor que se puede hacer es incluir un gestor documental. Este mdulo se encargar de guardar y organizar los documentos externos, permitiendo su bsuqeda, visualizacin y edicin de modo sencillo y rpido. 3.2.6. Agilidad, Flexibilidad y Alineamiento La agilidad y flexiblidad ocurren cuando nuevos procesos pueden ser creados rpida y eficientemente a partir de un conbjunto existente de servicios. Lograr agilidad y flexibilidad requeriere una catalogo que liste las funciones y datos provistos por los servicios disponibles. En adicin, se necesita una forma eficiente de construir procesos de negocio a partir de servicios.
Desafo Reuso Requerimiento Arquitectural Habilidad de publicar, buscar, evaluar y
registrarse como un consumidor de servicio Capacidades de administrar el ciclo de vida de un

servicio Habilidad de garantizar la disponibilidad de una versin de servicio Desarrollo Eficiente Tener una arquitectura de referencia que guie el desarrollo de servicio Usar BPM para definir procesos de negocios, basado en la composicin de servicios Integracin de Aplicaciones y Datos Tener un modelo semntico comn para la informacin compartida. Tener una arquitectura de referencia que describa patrones comunes de integracin Agilidad, Flexibilidad y Alineamiento Tener una arquitectura de referencia que defina los aspectos de negocio e informacin de SOA y su relacin con la empresa. Tener un modelo semntico comn que es usado para realizar el diseo de interfaz de servicio Usar tcnicas de desarrollo apropiadas para asegurar la trazabilidad entre modelos de negocio y sistemas implementados.
Tabla 3.1. Resumen de los requerimientos arquitecturales Fuente: Elaboracin propia
3.3.
Proceso de Requerimientos
3.3.1. Requerimientos Funcionales 3.3.2. Requerimientos no Funcionales
3.4.
Proceso de Anlisis y Diseo
3.4.1. Identificacin de Riesgos La identificacin de riesgos en un proyecto es un intento sistemtico para especificar las amenazas al plan del proyecto (estimaciones, planificacin temporal, carga de recursos, etc.).
Durante el desarrollo del proyecto se identificaron distintos riesgos con respecto a la tecnologa, el tiempo, el entorno de desarrollo, etc. Riesgos Tecnolgicos: El emplear nuevas tecnologa puede llevar a concebir riesgos en el proyecto, si es que stas no son bien utilizadas o no se tienen muchos conocimientos de las mismas. La tecnologa es nueva para la organizacin La tecnologa utilizada no tiene el soporte adecuado El desarrollador no posee el conocimiento suficiente sobre la tecnologa elegida.
Riesgos relacionados con el tiempo y las pruebas: El estimar el tiempo para realizar un proyecto no debe hacerse a la ligera, puesto que esto podra causar retrasos en la entrega o el desarrollo de un sistema ineficiente. 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, algunos saben lo que quieren y otros no. 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 lnea o documentacin de las herramientas empleadas
58
3.4.2. Proyeccin 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. 3.4. Escala de probabilidad de ocurrencia del riesgo Fuente: (Elaboracin Propia)
Catastrfico Crtico Marginal Despreciable
10 7 4 1
Tabla. 3.4. Escala de probabilidad de ocurrencia del riesgo Fuente: (Elaboracin Propia)
Utilizando las escalas mencionadas, a continuacin se presenta la estimacin de los riesgos en base a la [probabilidad e impacto apreciados.
Riesgo La tecnologa es nueva para la organizacin La tecnologa 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 tecnologa elegida
Tabla 3.5. Riesgos Tecnolgicos

Fuente: (Elaboracin 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.6. Riesgos relacionados con el tiempo y las pruebas Fuente: (Elaboracin propia)
Riesgo El cliente no tiene una idea clara todo lo que precisa El cliente tiene una idea clara pero no sabe cmo 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. Riesgos relacionados con el cliente Fuente: (Elaboracin 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 lnea o documentacin de las 5 herramientas empleadas
35
Tabla 3.8. Riesgos del Entorno de Desarrollo Fuente: (Elaboracin propia)
Teniendo los listados de riesgos presentados en las tablas anteriores, a continuacin se listan los riesgos por orden de probabilidad de impacto.
60
Riesgo La tecnologa es nueva para la organizacin
Probabilidad 10
Impacto 10 10
Total 100 80
El desarrollador no posee el conocimiento suficiente sobre 8 la tecnologa 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
70
56
satisfactorio La tecnologa 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 lnea o documentacin de las 5 herramientas empleadas El cliente tiene una idea clara pero no sabe cmo 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: (Elaboracin propia) 3.4.3. Mitigacin y contingencia de los riesgos
Riesgo Mitigacin Contingencia informacin en
La tecnologa es nueva para la Planificar un proceso de Proporcionar organizacin El desarrollador no posee capacitacin
documentos y medios didcticos
el Dedicar ms horas en la Cambiar a otra tecnologa ms entendible
conocimiento suficiente sobre la revisin de informacin tecnologa elegida No se cuenta con expertos para Buscar informacin en lnea 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
61
satisfactorio La tecnologa utilizada no tiene el Conseguir de otras fuentes Cambiar a una tecnologa que soporte adecuado toda la informacin necesaria tenga el soporte necesario
El cliente no tiene una idea clara Colaborar al cliente con la Programar ms entrevistas todo lo que precisa identificacin requerimientos El tiempo estimado no es suficiente Elaborar para el desarrollo del proyecto con detalle de la Replantear el tiempo de de
planificacin
la elaboracin del proyecto
elaboracin del proyecto El proyecto se llega a terminar sin Realizar las pruebas necesarias una buena Planificar un tiempo extra al desarrollo para realizar pruebas
planificacin de pruebas
No se cuenta con ayuda en lnea o Revisar documentacin en Buscar otras herramientas que documentacin de las herramientas otros idiomas (de preferencia tengan documentacin empleadas Ingls)
El cliente tiene una idea clara pero Planificar ms reuniones para Ponerse en el lugar del cliente no sabe cmo 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.10. Mitigacin y contingencia de los riesgos por orden de probabilidad e impacto. Fuente: (Elaboracin propia) 3.4.4. Caso de Estudio: Sistema de Gestin Documental El sistema de gestin documental debe ser un sistema que cuente con las siguientes funciones bsicas: Autenticacin de usuarios Seguimiento al ciclo de vida de documentos Bsqueda de documentos Iniciar un procesos de aprobacin de documentos Creacin de documentos a partir de plantillas
62
3.4.5. Procesos de Negocio Identificados 3.4.5.1. Procesos de Negocio: Aprobacin/Rechazo de Documentos
Muchos documentos, como proyectos, especificaciones y presupuestos entre otros son creados por distintos usuarios, estos necesitan ser revisados y aprobados por usuarios de otro nivel, y los primeros deben ser notificados una vez terminada la revisin. Este procesos tiene como meta u objetivo de negocio el de obtener un documento ya revisado, pudiendo ser este aprobado o rechazado. El flujo que sigue este proceso de negocio es el siguiente.
INICIO
Tareas Automatizadas Tareas Humanas
Enviar Revisin
Usuario
Revisin Proyecto
No
Aprobado? Notificacin Rechazo
Supervisor
Si
Notificacin Aceptacin
Almacenar Proyecto
FIN
Fig. 3.4. Diagrama de Proceso de Negocio Aprobar Documento Fuente: (Elaboracin Propia) 3.4.5.2. Identificacin de Servicios
63
Las preguntas necesarias para la identificacin de servicios en una Arquitectura Orientada al Servicio son: Es o ser en algn momento el servicio re usable? Es el servicio algo que tendr utilidad ms all de la que brinda a la aplicacin a la que pertenece? El servicio representa una funcin de negocio? [Executing SOA] Luego de haber hecho un anlisis, se identificaron los siguientes servicios para este proceso de negocio: Servicio Enviar Documento a Revisin: Este servicio copia el documento en una carpeta temporal de revisin dependiendo de la persona a la que se manda dicha revisin. Este servicio es considerado como una funcin de negocio y adems, puede ser necesario para otros sistemas existentes o nuevos contar con esta funcionalidad.
Servicio Enviar Documento a Revisin

Dado un ID de supervisor y un ID de documento, se guarda el documento en la carpeta respectiva. Se almacena en la base de datos, informacin sobre la revisin (fecha, versin, etc.)
Fig. 3.9. Servicio Enviar Documento a Revisin Fuente: Elaboracin Propia
Servicio Almacenar Documento: Una vez aprobado o rechazado el documento, este se almacena de manera permanente en un servidor.
64
Servicio Almacenar Documento

Dado el ID del documento, ID del supervisor se almacena permanentemente el documento. Dados otros datos como sobre la revisin se almacena en la base de datos el estado final del documento (aprobado/rechazado)
Fig. 3.9. Servicio Almacenar Documento Fuente: Elaboracin Propia 3.4.5.3. Proceso de Negocio: Control de Equipos
Los diferentes tcnicos de DTIC se encargan de registrar los dispositivos de red (computadoras, servidores, routers, switchs, etc.) existentes dentro de todos los departamentos de la Universidad, para ello deben llenar unas fichas de Control de Equipos con las especificaciones del dispositivo. Por una parte se necesita obtener un documento en tipo Microsoft Office Word con los datos respectivos y por otra parte, estos datos tambin son necesarios para el sistema Config-RED encargado del registro de dispositivos de red. El flujo que sigue el proceso es como sigue:
65
INICIO
Tareas Automatizadas Tareas Humanas
Inicia Creacin Ficha Usuario Sistema Desplegar Dispositivos de Red Gestin Documental
Completar Ficha
Si
Registrar Dispositivo de Red
Usuario Sistema
Almacenar Registro
Config-RED
FIN
3.4.5.4.
Identificacin de Servicios
Servicio Listar Catlogos: El sistema CosticRED mantiene catlogos de los diferentes dispositivos de red que pueden existir como ser computadoras, routers, hubs, etc. Esto ser de utilidad para el Proceso de Negocio en la etapa de Creacin de Ficha.
Servicio Listar Productos: Adems de los catlogos, el sistema CosticRED tiene registrado dentro de cada catlogo los productos asociados al tipo de dispositivo, por ejemplo dentro del catlogo de Computadoras Pentium IV hay varios productos especficos como una Intel Pentium IV CPU 3.2 Ghz (Clone) D945PRN. Este servicio ser necesario tambin en la etapa Creacin de Ficha.
3.4.5.5.
Otros Servicios
Servicio de Autenticacin: El sistema de gestin documental necesita un control de acceso a usuarios. Adems de este sistema, son muchos otros que tambin necesitan esta
66
funcin. Se tiene un sistema desarrollado en PHP que se encarga de esto, por tanto este sistema publicar el Servicio de Autenticacin.
Servicio de Autenticacin
Comparar nombre de usuario y contrasea con la base de datos existente. Si existe devolver los datos del usuario.
Fig. 3.8. Servicio de Autenticacin Fuente: Elaboracin Propia Servicio de Bsqueda de Documentos: El sistema de gestin documental contar con la funcionalidad de bsqueda de documentos. Despus de un anlisis se llega a la conclusin de que otros sistemas pueden en algn momento utilizar esta lgica de aplicacin, por tanto ser publicado.
Servicio de Bsqueda de Documentos

Devolver una lista de documentos con las palabras claves de bsqueda.
Fig. 3.9. Servicio de Bsqueda de Documentos

Fuente: Elaboracin Propia Servicio Listar Tipos Interfaces: Servicio publicado por la aplicacin CosticRED. Devuelve una lista de los tipos de interfaces registrados en el sistema. Servicio Listar Tipos Conectores: Servicio publicado por la aplicacin CosticRED. Devuelve una lista de los tipos de conectores de interface registrados en el sistema. Servicio Listar Velocidades Interfaces: Servicio publicado por la aplicacin CosticRED. Devuelve una lista de las distintas velocidades de interfaces registradas en el sistema.
Nombre Servicio Sistema que lo publica Sistema de Autenticacin Sistema de Gestin Documental Sistema ConfigRED Sistemas que lo Utilizan Sistema de Gestin Documental Sistema de Gestin Documental Sistema de Gestin Documental Sistema de Gestin Documental Sistema de Gestin Documental Sistema de Gestin Documental Lenguaje de Programacin PHP
Autenticacin
Buscar Documentos Listar Velocidades Interfaces Listar Tipos Interfaces Listar Tipos Conectores Listar Catlogos
Java
Java
Sistema ConfigRED
Java
Sistema ConfigRED
Java
Sistema CosticRED
Java
Listar Productos
Sistema CosticRED Sistema de Gestin Documental Sistema de Gestin Documental
Java
Almacenar Documento Enviar Documento a Revisin
Java
Java
Tabla 3.10. Resumen de los Servicios Identificados


Proceso de Negocio Servicio Autenticacin Buscar Documentos Listar Velocidades Interfaces Listar Conectores Interfaces Listar Tipos Interfaces Listar Catlogos Listar Productos Almacenar Documento Enviar Documento a Revisin X X X X Aprobacin/Rechazo de Documentos
Control de Equipos
Tabla 3.11. Relacin Servicios / Procesos de Negocio Fuente: Elaboracin Propia
3.4.6. Arquitectura de Referencia SOA
Procesos de
Bus de Servicios Empresarial ESB
Negocio Orquestados
Aprobacin/Rechazo de Documentos Control de Equipos
Almacenar Documento
Listar Tipos Conectores Listar Listar Catlogos Listar Productos Velocidades Int. Listar Tipos Interfaces
Servicios
Enviar Documento a Rev. Buscar Documentos Autenticacin
Aplicaciones Empresariales
Sistema de Gestin Documental
Sistema de Autenticacin
CosticRED
ConfigRED
.
4. ANLISIS DE RESULTADOS Y LA PUESTA EN MARCHA

4.1. Proceso de Implementacin
El objetivo final no es en s implementar un sistema, sino ms bien demostrar los conceptos investigados sobre la Arquitectura Orientada al Servicio ponindolos en prctica. 4.1.1. Arquitectura Orientada al Servicio Primeramente, se defini una Arquitectura de Referencia SOA sobre la cual se implement el Sistema de Gestin Documental. La figura muestra la Arquitectura de Referencia y las tecnologas utilizadas para cada capa.
Consumidor de Servicio
Capa de Presentacin
Spring Framework/Java/JSP
Capa de Integracin (Jboss ESB)
Capa de Procesos de Negocio
Control Fichas
Aprobacin Documentos
Capa de Servicios
Proveedor de Servicio
Conjunto de Servicios Web
Sistemas Operacionales
CosticRED
Sist. De Autenticacin
ConfigRED
Capa de Sistemas Operacionales Esta capa incluye los sistemas que existen en el entorno tecnolgico actual de la Universidad, que dan soporte a actividades de negocio. Los sistemas operacionales pueden incluir
aplicaciones personalizadas, aplicaciones empaquetadas, sistemas legados, y las diferentes bases de datos existentes. Capa de Servicios Esta capa incluye todos los servicios y la definicin de cada uno de ellos que constituye su informacin sintctica y semntica. La informacin sintctica se refiere a las operaciones de cada servicio, los mensajes de entrada y salida, mientras que la informacin semntica se refiere a polticas de servicio, requerimientos para el acceso al servicio. Los servicios son definidos de forma que sean accesibles e invocados por consumidores independientemente de la implementacin. Capa de Procesos de Negocio Un proceso de negocio es una representacin de las distintas actividades coordinadas dentro de una empresa que realizan una funcin de negocio de alto nivel. Esta capa representa a los procesos como una orquestacin o una composicin de servicios. Esta capa es tambin responsable de la administracin del ciclo de vida del proceso. Los datos e informacin que fluyen entre los pasos dentro de los procesos son tambin representados en esta capa. Los procesos representados en esta capa son el medio de conexin entre requerimientos de negocio y su manifestacin como soluciones de Tecnologas de la Informacin. Capa de presentacin Mirando toda la arquitectura, lo que falta es el Sistema de Gestin Documental. La capa de presentacin puede ser considerada como la aplicacin clsica, pero con una variedad de modelos de entrega diferentes (mviles, web, gadgets, y cualquier otro tipo de presentacin), la propia nocin de lo que constituye una aplicacin cambia. Por tanto, la capa de presentacin representa cualquier cosa que pueda ser considerada como una interfaz de usuario para los servicios de cmputo. [Open Source SOA] Capa de Integracin Esta capa provee la capacidad a los consumidores de servicio de ubicar proveedores de servicio e iniciar invocaciones de servicio. A travs de estas tres capacidades bsicas de
mediacin, enrutamiento y transformacin de datos y protocolo, esta capa ayuda a fomentar un ecosistema de servicios donde los servicios pueden comunicarse entre ellos mientras son parte de un proceso de negocio. La funcin de esta capa es normalmente definida como el Bus de Servicios Empresarial (ESB). Un ESB es una coleccin de patrones de arquitecturas que usan estndares abiertos y protocolos para implementar tres capacidades bsicas de esta capa y proveer una capa entre los consumidores de servicio y proveedores de servicio exponiendo los servicios solo a travs del ESB. Lo bueno de la capa de integracin es que cualquier funcin que pueda ser expuesta de una forma que siga estndares abiertos y protocolos podr ser enchufada al ESB para que pueda formar parte de un ecosistema basado en servicios.
Capas Sistemas Operacionales Aplicaciones Legadas Elementos Aplicaciones Personalizadas Cualquier tipo de Servicios Web Tecnologa Aplicacin Jboss jBPM Jboss ESB Proceso de Negocio de Procesos Negocio
Servicios Conjunto Servicios
Integracin
Presentacin de
de Bus Servicios Empresarial Registro
de Interfaces Usuario
Interfaces Web/Escritorio Java/Spring Framework/JSP
Tabla 4.7. Capas y Tecnologas Utilizadas. Fuente: Elaboracin Propia 4.1.2. Caso de Estudio: Sistema de Gestin Documental El objetivo principal es desarrollar este sistema bajo la Arquitectura Orientada al Servicio. 4.1.3. Especificacin Tcnica del Hardware y Software 4.1.3.1. Hardware
Se utilizaron dos servidores, uno donde estn desplegados las aplicaciones en Java y otro donde se encuentran las aplicaciones en PHP. Las caractersticas son las siguientes:
Servidor PHP Procesador
Servidor Java
Intel Quad Core 1.86 Intel Pentium 4 3 Ghz. Ghz
Memoria Conexin Disco Duro
2 GB 100 Mbps 500 GB
1 GB 100 Mbps 160 GB
La infraestructura de red es la siguiente:
4.1.3.2.
Software
Microsoft Windows XP Service Pack 3 JBoss SOA Platform 4.3 JBoss jBPM JBoss ESB JBoss Application Server
73
PostgreSQL 8.4 Eclipse Ganymede Adobe Dreamweaver CS4 Spring Framework XFire Web Services Framework XAMPP (Apache, MySql)
4.2. Proceso de Prueba

Al trmino del proyecto, gracias al desarrollo del Caso de Estudio, se tiene definida una Arquitectura SOA y un sistema desplegado bajo esta arquitectura, por tanto debemos probar ambas. 4.2.1. Plan de Pruebas: Sistema de Gestin Documental 4.2.2. Plan de Pruebas: Arquitectura Orientada al servicio Las pruebas de software tradicional que se enfocaban en pruebas a nivel de cdigo han evolucionado con las arquitecturas Distribuidas y de Servicios Web. Las pruebas de las Aplicaciones Web han introducido ms pruebas para lgica de negocio a travs de la interfaz de usuario de la aplicacin, que ha probado ser crtica cuando se despliegan nuevas soluciones. Con SOA, la necesidad de probar la lgica de negocio an existe; sin embargo, muchos servicios SOA no tendrn una interfaz de usuario. Algunos de los desafos de las pruebas en SOA son: Servicios que no tienen interfaz de usuario Lgica de negocio dentro de los servicios Servicios externos a la organizacin La calidad del servicio ser vital para promover el reuso y la facilitar la agilidad de negocio. Los servicios que tienen problemas de calidad no sern reusados por los equipos de desarrollo. Un aumento significante en las actividades de prueba ser necesario en un nivel de servicio.
74
Entonces cmo probamos la arquitectura SOA? Simplemente no lo hacemos, en cambio debemos descomponemos la Arquitectura en sus partes componentes, desde la ms primitiva a la ms sofisticada, probando cada componente. En otras palabras dividimos la arquitectura en dominios, como servicios, seguridad, gobernancia, y proabamos cada dominio de forma separada usando los enfoques y herramientas recomendados. Las pruebas de Vulnerabilidad, Interoperabilidad, Desempeo y Funcionales forman los pilares de las Pruebas SOA. Solo adoptando estos pilares, las empresas pueden estar seguros de que la Arquitectura Orientada al Servicio es robusta, escalable interoperable y segura. Los Servicios Web son los bloques de construccin de SOA. Casi todo activo TI ahora tiene una interface como una interface WSDL lista para mensajera SOAP/XML. Las interfaces de Servicios Web proveen flexibilidad al integrar activos TI a lo largo de los dominios internos y externos corporativos. Dicha flexibilidad da la responsabilidad al personal de IT de todos los dominios (Desarrolladores, Ingenieros de Redes, Oficiales de Seguridad, etc. Asegurarse que los Servicios Web trabajan a la altura de los requerimientos funcionales, de desempeo, interoperabilidad y seguridad. Pilar I. Pruebas Funcionales y de Regresin
Las pruebas de regresin y funcionales son el primer pilar de las pruebas SOA. Los profesionales IT deben probar rpidamente los Servicios Web. Pilar II. Desempeo
El desempeo es el segundo pilar de las pruebas SOA. Se deben probar la escalabilidad y robustez de los Servicios Web y determinar el desempeo de sus operaciones WSDL. Se debe determinar tiempos de respuesta, latencia, perfiles de rendimiento para los Servicios Web. Aparte de los perfiles de rendimiento, el tester debe hacer una prueba durante una duracin especfica para medir perfiles de robustez y resistencia. Tambin se necesita determinar la escalabilidad mediante el bombardeo a los Servicios Web con diferentes mensajes SOAP a travs de una amplia gama de clientes concurrentes. Pilar III. Interoperabilidad
75
La interoperabilidad es el 3er pilar de las Pruebas SOA. Mientras se consume un Servicios Web WSDL, las aplicaciones consumidoras necesitan determinar caractersticas de interoperabilidad del Servicio Web en tiempo de diseo y ejecucin . Los desarrolladores deben ejecutar un conjunto de Perfiles WSI de pruebas y reportar los problemas de interoperabilidad con los WSDL de los Servicios Web. Usando Perfiles WSI nos asegura que los activos SOA son interoperables y el WSDL funcionara dentro de entornos heterogneos Java, PHP, .NET, etc. Las pruebas de interoperabilidad WSDL en tiempo de diseo no son suficientes. Se necesita tambin pruebas de interoperabilidad en tiempo de ejecucin. Probar la interoperabilidad de los servicios Web requiere crear suites de pruebas para un WSDL. 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. Las pruebas de perfiles WSI en tiempo de diseo combinadas con las pruebas del comportamiento de interoperabilidad de servicios Web en tiempo de diseo. Aseguran que los activos IT pueden integrarse independientemente de la plataforma, sistema operativo y lenguaje de programacin. Pilar IV. Evaluacin de la Vulnerabilidad La evaluacin de la Vulnerabilidad es el 4to pilar de las pruebas SOA. Creando tests especializados para un Servicio Web, los oficiales de la seguridad pueden medir perfiles de vulnerabilidad del Servicio Web. Los Ingenieros de la Seguridad deben asegurarse que las vulnerabilidades de los Servicios Web como buffer overflows, payloads recursivos, schema posisoning, y malware traveling sobre los mensajes SOAP no afectan a los Servicios Web crticos. La necesidad de la habilidad de escanear rpidamente Servicios Web y areas de exposicin, determinar niveles de seguridad, proveer diagnsticos de vulnerabilidad, y publicar tcnicas de solucin. 4.2.3. Plan de Pruebas Las tcnicas como pruebas de caja Negra, caja Blanca y caja Gris aplicadas a los sistemas tradicionales funcionan bien para los Servicios Web. 4.2.3.1. Pruebas de Caja Negra
76
Las pruebas de caja negra se refieren a la tcnica para probar un sistema sin conocimiento del funcionamiento interno del sistema. Los testers de Caja Negra no tienen acceso al cdigo fuente y tampoco tienen conocimiento de la Arquitectura del Sistema. Un tester de Caja Negra usualmente interactua con un sistema a travs de una interfaz de usuario proveyendo datos de entrada y examinando las salidas sin saber donde y como se trabaja con las entradas. En las pruebas de Caja Negro, el software es probado con una variedad de entradas y las salidas son observadas para la correccin. Cmo estas salidas son generadas o qu hay dentro de la Caja no es de importancia para el tester. El tester no est al tanto del sistema operativo, lenguaje de programacin, libreras de terceros o otros Servicios Web que son usados para realizar la operacin. Para realizar estas pruebas haremos uso del software SOAPSonar, ya que como anteriormente mencionamos los Servicios Web no cuentan con interfaces de usuario, y lo que nos brinda esta aplicacin es una interfaz de usuario para invocar Servicios Web y mostrar las salidas. El tester debe saber la ubicacin del WSDL del Servicio Web pero no est al tanto de los detalles de implementacin, estados de ejecucin, manejo de excepciones internos. El tester tiene una especificacin y debe hacer ejercicios redundantes de invocacin al servicio para asegurarse de que la operacin probada funciona de forma esperada. 4.2.3.2. Pruebas de Caja Blanca
Las pruebas de Caja Blanca se refieren a la tcnica de probar un sistema teniendo conocimiento del funcionamiento interno del sistema. Los testers de Caja Blanca tienen acceso al cdigo fuente y estn al tanto de la arquitectura del sistema. Un tester de Caja Blanca usualmente analiza el cdigo fuente, y busca errores como la falta de manejo de excepciones.
77
4.3. Puesta en Marcha
5. CONCLUSIONES 6. RECOMENDACIONES 7. REFERENCIAS BIBLIOGRFICAS

[1] BELLIDO SANTA MARIA, Jos Boris. Desarrollo de Web Services para un proveedor de Servicios de Aplicacin. Tesis (Ingeniero de Sistemas). Sucre, Bolivia: Universidad San Francisco Xavier, Facultad de Tecnologa, 2005. [2] AVILA BARAY, Hector Luis. Introduccin a la metodologa de la investigacin. [en lnea]. 2006, Documento PDF. Disponible en: http://www.eumed.net/libros/2006c/203. [Consulta: 1 Mayo 2009].
[3] PRESMAN, Roger. Ingeniera del Software Un enfoque prctico. Ince, Darrel (adap.); Joyanes Aguilar, Luis (Coord.). Quinta edicin. Madrid: Mc Graw Hill, 2002. 640 p. ISBN: 0-07-709677-0. [4] ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, 2005. 720 p. ISBN: 0-13-185858-0. [5] PAPAZOGLOU, Michel P; VAN DEN HEUVEL, Willem-Jan. Service-Oriented Design and Development Methodology [en lnea]. Netherlands: Universidad de Tilburgh, 2006. Disponible en: http://infolab.uvt.nl/pub/papazogloump-2006-88.pdf . [Consulta: 23 de mayo 2009] corrigi [6] HURWITZ, Judith; BLOOR, Robin; BAROUIDI, Carol. Service Oriented Architcture for Dummies. Primera edicin. Indiana: Wiley Publishing Inc., 2007. 359 p. ISBN: 0-470-054352. [7] KEEN, Martin; BISHOP, Susan; HOPKINS, Alan; ROBINSON; Rick. Patterns: Implementing an SOA Using an Enterprise Service Bus. [en lnea]. WebSphere Software,
IBM,
mayo
2006.
Documento
PDF.
Disponible
en:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf. [Consulta: 9 mayo 2000]. [8] ROSEN, Michael, LUBLINSKY, Boris, SMITH, Kevin T. Designing Service Interfaces. En: SOA Applied: Service Oriented Architecture and Design Strategies.. Indianpolis, Indiana, Wiley Publishing, 2008. pp 204-210. ISBN: 978-0-470-22365-9. [9] ERL, Thomas. Service Contracts Standardization and Design. En: Service-Oriented Architecture: Principles of Service Design. United States, Prentice Hall PTR, 2008. pp 124161 ISBN: 0-13-234482-3. [10] BERNDTSSON, Mikael, HANSSON Jorgen, BJORN, Olsson. Developing your Objectives and Choosing Methods. En: Thesis Projects: A Guide for Students in Computer Science and Information Systems. Springer-Verlag London, 2008. pp 54-70 ISBN: 1-85233332-4. [11] The Scientific Method. [En lnea]. [Consulta: 18 de mayo de 2009]
http://www.sciencebuddies.org/science-fair-projects/scientific-method-handout.pdf [12] ERL, Thomas. Service Contracts Standarization and Design. En: Service-Oriented Architecture: Principles of Service Design. United States, Prentice Hall PTR, 2008. pp 124161 ISBN: 0-13-234482-3. [13] JOSUTTIS, Nikolai M. The Enterprise Service Bus. En: SOA in Practice. United States, OReilly Media, Inc. 2007. pp 47-59 ISBN: 0-596-52955-4. [14] MACKENZIE, Mathew, LASKEY, Ken, MCCABE, Francis. OASIS Reference Model for Service Oriented Architecture 1.0. [en lnea] Committee Draft 1.0, Febrero, 2006. Disponible en: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm. [Consulta: 23 de mayo 2009] [15] ESTEFAB, Jeff A., LASKEY, Ken, MCCABE, Francis. Realizing Service Oriented Architectures View. En: Reference Architecture for Service Oriented Architecture Version 1.0. [en lnea], Abril, 2008. Pp 39-78. Disponible en: http://docs.oasis-open.org/soa-rm/soara/v1.0/soa-ra-pr-01.html. [Consulta: 23 de mayo 2009]
[16] BRITTAIN, Jason. Tomcat: The Definitive Guide. 9780596101060.
OReilly, 2007. 494 p. ISBN:
[17] BERNOIT, Marchal. Applied XML Solutions. Sams Publishing, 2000. 360 p. ISBN: 0672320541.
80
Ingeniera de Sistemas UMRPSFXCH
SOA COMO ARQUITECTURA PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX
[18] HANSEN, Mark. SOA Using Java Web Services. Primera edicin. Prentice Hall, 2007. 359 p. ISBN: 9780130449689 [19] UPPAL, Kunan. "SOA Basics". En: Service Oriented Architecture [en lnea]. Tesis (Masters of Computed Applications). Kashmere Gate, Delhi: GGSIP University, 2007. Disponible en: http://www.scribd.com/doc/964179/Service-Oriented-Arcitecture. [Consulta: 25 mayo 2009]. [20] GULZAR, Nadir. Practical J2EE Application Architecture. Primera edicin. McGrawHill Osborne Media, 2003. 512 p. ISBN: 0072227117 [21] POWELL, James E. Q&A: SOA Challenges for SMBs. [en lnea]. Disponible en: http://esj.com/enterprise/article.aspx?EditorialsID=3466 [Consulta: 26 abril 2002] [22] PULIER, Eric; TAYLOR, Hugh. Understanding Enterprise SOA. Manning Publications, 2006. 243 p. ISBN: 1-932394-59-1. [23] EARL, Thomas. Principles of Service Design. Primera edicin: Prentice Hall, Indiana 2008. 608 p. ISBN: 0-13-234482-3. [24] HURWITZ, Judith; BLOOR, Robin; KAUFMAN, Marcia. Service Oriented Architecture for Dummies (IBM Limited Ediion). Segunda edicin: Wiley Publishing Inc., Indiana, 2009. 76 p. ISBN: 978-0-470-52549-4 [25] JURIC, Matjaz B.; LOGANATHAN, Ramesh. SOA Approach to Integration. XML, Web Services, ESB, and BPEL in real-world SOA projects. Primera edicin: PACKT Publishing, Noviembre, 2007. 382 p. ISBN: 978-1-904811-17-6 [26] VASILIEV, Yuli. SOA and WS-BPEL. Composing Service-Oriented Solutions with PHP and ActiveBPEL. Primera edicin: PACKT Publishing., Septiembre, 2007. 314 p. ISBN: 9781-847192-70-7 [27] BEAN, James. SOA and Web Services Interface Design. Principles Techniques, and Standards. Primera edicin: Morgan Kaufmann Publications, 2010. 314 p. ISBN: 978-0-12374891-1 Primera edicin:
81
[28] BELL, Michael. Service Oriented Modeling. Service Analysis, Design and Architecture. Primera edicin: John Wiley & Sons, Inc., 2008. 387 p. ISBN: 978-0-470-14111-3 [29] BARAI, Malhar; BINILDAS, CA; CASELLI, Vincenzo. Service Oriented Architecture with Java. Using SOA and web services to build powerful Java applications. Primera edicin: PACKT Publishing, Junio, 2008. 188 p. ISBN: 978-1-847193-21-6 [30] SCHMUTZ, Guido; WELKENBACH, Peter; LIEBHART, Daniel. Service-Oriented Architecture: An Integration Blueprint. Primera edicin: PACKT Publishing., Junio, 2010. 225 p. ISBN: 978-1-849681-04-9 [31] DAVIS, Jeff. Open Source SOA. Primera edicin: Manning Publications Co., 2009. 449 p. ISBN: 978-1-933988-54-2 [32] SALATINO, Mauricio. jBPM Developer Guide. Primera edicin: PACKT Publishing., Diciembre, 2009. 371 p. ISBN: 978-1-847195-68-5 [33] KUMAR, B. V.; NARAYAN; Prakash, NG; Tony. Implementing SOA Using Java EE. Primera edicin: Addison-Wesley, Diciembre, 2009. 314 p. ISBN: 978-0-321-49215-9 [34] BROWN, Paul C. Implementing SOA: Total Architecture in Practice. Primera edicin: Addison Wesley Professional, Abril, 2008. 736 p. ISBN: 978-0-321-50472-2 [35] BIEBERSTEIN, Norbert; LAIRD, Robert G. ; JONES, Dr. Keith ; MITRA, Tilak. .Executing SOA: A Practical Guide for the Service Oriented Architect. Primera edicin: IBM Press., Mayo, 2008. 240 p. ISBN: 978-0-13-235374-1 [36] CUMBERLIDGE, Matt. Business Process Management with JBoss jBPM. A Practical Guide for Business Analysts. Primera edicin: PACKT Publishing., Julio, 2007. 314 p. ISBN: 978-1-847192-36-3 [37] ROSEN, Michael; LUBLINSKY, Boris; SMITH, Kevin; BALCER, Marc. Applied SOA. Service Oriented Architecture and Design Strategies. Primera edicin: Wiley Publishing, Inc., 2008. 698 p. ISBN: 978-0-470-22365-9
82
[38] LUPPKEN, Sven; STAUBLE, Markus. Spring Web Flow 2 Web Development. Primera edicin: PACKT Publishing., Marzo, 2009. 272 p. ISBN: 978-1-847195-42-5 [39] MAK, Gary. Spring Recipes. A Problem-Solution Approach. Primera edicin: Apress Inc., 2008. 753 p. ISBN: 978-1-59059-979-2 [40] REZA, Ahmad. Spring Persistence with Hibernate. Primera edicin: PACKT Publishing Inc., Noviembre, 2009. 460 p. ISBN: 978-1-849510-56-1 [41] SWEENEY, Rick. Achieving Service-Oriented Architecture. Applying an Enterprise Architecture Approach. Primera edicin: John Wiley & Sons, Inc., 2010. 383 p. ISBN: 978-0470-60451-9 [42] DAVIES, Jeff; SCHOROW, David; RAY, Smarat; RIEBER, David. The definitive guide to SOA. Oracle Service Bus. Segunda edicin: APress Publishing, Inc., 2008. 524 p. ISBN: 978-1-4302-1057-3 [43] ERL, Thomas. SOA with .NET & Windows Azure. Realizing Service-Orientation with the Microsoft Platform. Primera edicin: Prentice Hall, 2010. 915 p. ISBN: 978-0-13-158231-6 [44] JOSUTTIS, Nicolai M. SOA in Practice. The Art of Distributed System Design. Primera edicin: OReilly Media, Inc., 2005. 344 p. ISBN: 0-596-52955-0 [45] MCGOVERN, James; SIMS, Oliver; JAIN, Ashish; LITTLE, Mark. Enterprise Service Oriented Architectures. Concepts, Challenges, Recommendations. Primera edicin: Springer, 2006. 434 p. ISBN: 1-4020-3704-X
83
84

Proyecto de Grado

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto de Grado

Cargado por

Copyright:

Formatos disponibles

NDICE

DECLARACION DE DERECHOS DEL AUTOR

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Introduccin y Antecedentes del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Introduccin y Antecedentes del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Introduccin y Antecedentes del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Identificacin del problema central del proyecto

Planificacin de Actividades del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Abordaje o ruta de solucin del problema

Fig. 1.1 Ruta de Solucin Fuente: Elaboracin Propia

Planificacin de Actividades del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Objetivos del Proyecto

Planificacin de Actividades del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Planificacin de Actividades del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Justificacin del proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Planificacin de Actividades del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

ACTIVIDAD ETAPA DE INVESTIGACIN Buscar y Recolectar Informacin

Fuente: Elaboracin Propia

Planificacin de Actividades del Proyecto

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

SOA y candidatos de servicio definidos

Documento con la descripcin de servicio

ESB configurado Interfaz definida Servicios Implementados

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Tabla 1.2 ACTIVIDAD Construccin

Planificacin de Actividades de desarrollo del Sistema Das PRODUCTO

Sistema validado y probado Niveles de servicio verificados

Fuente: Elaboracin Propia

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

2. MARCO TERICO CONCEPTUAL

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Lograr una meta de negocio: Es la meta principal del trabajo.

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Facturacin usa ACC

<<componente>> Sistema de Facturacin

Fig 2.1. Integraciones punto a punto Fuente: (42)

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

<<componente>> Ingreso de Ordenes (IO)

<<componente>> Catlogo de Productos (CP)

<<componente>> Sistema de Precios (SI)

<<componente>> Servicio de Inventario (SI)

Fig 2.2. Integraciones punto a punto de 8 sistemas Fuente: (42)

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

Fig. 2.3 Disonancia en los requerimientos

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX

1.8. Referencia a proyectos similares

1.9. Marco terico de ingeniera

ARQUITECTURA ORIENTADA AL SERVICIO PARA LA IMPLEMENTACIN E INTEGRACIN DE SISTEMAS DE INFORMACIN EN LA USFX