Embed Size (px)
Citation preview
Universidad de Colima Facultad de Telemática
ABCSIS: ARQUITECTURA BASADA EN COMPONENTES DE SOFTWARE PARA LA INTEGRACIÓN DE SERVICIOS
TESIS
Que para obtener el grado de MAESTRO EN COMPUTACIÓN
PRESENTA: ING. HUGO CÉSAR PONCE SUÁREZ
ASESORES: M. en C. JOSÉ ROMÁN HERRERA MORALES
D. en C. PEDRO DAMIÁN REYES
COLIMA, COLIMA. NOVIEMBRE DE 2009
II
ÍNDICE
Resumen .................................................................................................................... 1 Abstract...................................................................................................................... 2 1. Introducción........................................................................................................... 3
1.1 Antecedentes ................................................................................................ 3 1.2 Descripción del problema.............................................................................. 5 1.3 Hipótesis ....................................................................................................... 6 1.4 Objetivos ....................................................................................................... 6 1.5 Alcances y Limitaciones................................................................................ 7 1.6 Descripción general de ABCSIS ................................................................... 8 1.7 Metodología .................................................................................................. 9 1.8 Estructura del documento de la tesis .......................................................... 10
2. Antecedentes....................................................................................................... 11
2.1 Marco Histórico................................................................................................ 11 2.2 Marco Contextual............................................................................................. 17
2.2.1 Los sistemas de automatización de bibliotecas ........................................ 17 2.2.2 Sistema Integral Automatizado de Bibliotecas de la Universidad de......... 19 Colima (SIABUC) ............................................................................................... 19
2.2.2.1 Arquitectura Actual de SIABUC .......................................................... 23 2.2.2.2 CGI WebS8......................................................................................... 24 2.2.2.3 API WebS8 ......................................................................................... 25
2.3 Trabajos Relacionados .................................................................................... 27 3 Marco Teórico....................................................................................................... 29
3.1 Arquitecturas Iniciales...................................................................................... 29 3.1.1 CORBA ..................................................................................................... 30 3.1.2 DCOM ....................................................................................................... 32
3.2 Servicios Web.................................................................................................. 35 3.2.1 La tecnología de los servicios Web........................................................... 39 3.2.2 XML........................................................................................................... 40 3.2.3 WSDL........................................................................................................ 44 3.2.4 SOAP ........................................................................................................ 48 3.2.5 UDDI ......................................................................................................... 54
3.3 Arquitectura Orientada a Servicio (SOA) ......................................................... 61 3.3.1 Concepto de SOA ..................................................................................... 61 3.3.2 Estructura de SOA .................................................................................... 66 3.3.3 Aplicación.................................................................................................. 68 3.3.4 Servicio ..................................................................................................... 69 3.3.5 Repositorio ................................................................................................ 70 3.3.6 Bus de Servicio ......................................................................................... 71
3.4 SOA con Servicios Web................................................................................... 73 4. Arquitectura ABCSIS........................................................................................... 75
4.1 Modelo Conceptual .......................................................................................... 75
III
4.2 Diseño arquitectónico ...................................................................................... 78 4.2.1 Arquitectura ABCSIS................................................................................. 80 4.2.2 Entorno de Comunicación ......................................................................... 82 4.2.3 Motor de datos y estructura de la base de datos ...................................... 83 4.2.4 Comunicación con la base de datos.......................................................... 85 4.2.5 Descripción de módulos y componentes................................................... 88
5. Desarrollo de ABCSIS ......................................................................................... 99
5.1 Creación del servicio...................................................................................... 106 5.2 Hosting del servicio........................................................................................ 112 5.3 Implementación del prototipo......................................................................... 116
6. Pruebas .............................................................................................................. 125
6.1 Prueba de operación...................................................................................... 126 6.1.1 Resultados .............................................................................................. 130
6.2 Prueba de rendimiento................................................................................... 133 6.2.1 Resultados .............................................................................................. 140
7. Resultados y conclusiones .............................................................................. 147
7.1 Análisis de los resultados .............................................................................. 147 7.2 Conclusiones ................................................................................................. 149 7.3 Trabajo futuro ................................................................................................ 151
Anexos ................................................................................................................... 157 Glosario.................................................................................................................. 158
IV
ÍNDICE DE FIGURAS
Figura 1. Ejemplo de funcionamiento de un servicio bajo ABCSIS..................... 8 Figura 2. Evolución de la Arquitectura Orientada a Servicios…………………… 15 Figura 3. Arquitectura actual de SIABUC8………………………………………… 23 Figura 4. Arquitectura CORBA………………………………………………………. 30 Figura 5. Arquitectura DCOM………………………………………………………... 33 Figura 6. Representación de un servicio Web…………………………………….. 36 Figura 7. Interfaz de los Servicios Web con los sistemas finales……………….. 37 Figura 8. Mensaje SOAP en XML…………………………………………………... 38 Figura 9. Estructura inicial del documento WSDL………………………………… 46 Figura 10. Versiones del WSDL…………………………………………………….. 47 Figura 11. Estructura del protocolo SOAP…………………………………………. 49 Figura 12. Mensajes SOAP interconectando sitios remotos…………………….. 50 Figura 13. Interacción de los nodos en la ruta SOAP…………………………….. 51 Figura 14. Localización de un servicio Web mediante UDDI…………………….. 56 Figura 15. Modelo operacional de los servicios Web…………………………….. 59 Figura 16. Estructura de SOA……………………………………………………….. 66 Figura 17. Elementos que conforman un servicio………………………………… 70 Figura 18. Ejemplo de funcionamiento de un servicio bajo ABCSIS……………. 75 Figura 19. Modelo de la arquitectura ABCSIS…………………………………….. 82 Figura 20. Diagrama entidad-relación para la reservación de un ejemplar……. 85 Figura 21. Parámetros de conexión a la base de datos PostgreSQL…………... 86 Figura 22. Conexión al servidor de PostgreSQL………………………………….. 87 Figura 23. Servicios y operaciones de ABCSIS…………………………………… 88 Figura 24. Operación para hacer reservaciones………………………………….. 89 Figura 25. Operación para buscar un alumno en la base de datos……………... 89 Figura 26. Operación para buscar una ficha bibliográfica en la base de datos... 90 Figura 27. Operación para obtener la disponibilidad de un ejemplar…………… 90 Figura 28. Operación para registrar un usuario en la base de datos…………… 92 Figura 29. Operación para verificación de no adeudos…………………………... 92 Figura 30. Operación para mostrar las multas pendientes por saldar………….. 93 Figura 31. Operación para obtener los préstamos pendientes………………….. 93 Figura 32. Operación para renovar ejemplares…………………………………… 94 Figura 33. Operación para obtener los préstamos de un usuario………………. 94 Figura 34. Operación para obtener listado de escuelas………………………….. 95 Figura 35. Operación para registrar una inconformidad………………………….. 95 Figura 36. Operación para listar las quejas pendientes por atender……………. 96 Figura 37. Operación para responder una inconformidad……………………….. 96 Figura 38. Operación para hacer sugerencias de compras bibliográficas……... 97 Figura 39. Operación para emitir comentarios sobre títulos consultados………. 97 Figura 40. Interoperabilidad entre varios sistemas operativos…………………... 100Figura 41. Modelo de programación de WCF……………………………………... 102Figura 42. Binding de ABCSIS………………………………………………………. 107Figura 43. Servicio Acervo…………………………………………………………… 107Figura 44. Definición del contrato de datos………………………………………... 108Figura 45. Generación del contrato de datos para el manejo de excepciones… 109
V
Figura 46. Invocación de una excepción…………………………………………… 110Figura 47. Definición del servicio……………………………………………………. 110Figura 48. Cuenta de usuario ASPNET……………………………………………. 112Figura 49. Creación de un directorio virtual en IIS………………………………... 113Figura 50. Directorio virtual y archivos del servicio Acervo………………………. 113Figura 51. Servicio Acervo hospedado en IIS……………………………………... 114Figura 52. WSDL del servicio Acervo………………………………………………. 115Figura 53. Diagrama de flujo para la reservación…………………………………. 116Figura 54. Archivo de configuración de PHP………………………………………. 117Figura 55. Configuración correspondiente para el soporte de SOAP en PHP… 117Figura 56. Constructor SoapClient para hacer referencia al servicio Acervo..… 118Figura 57. Invocación de la operación BuscarFicha……………………………… 119Figura 58. Interfaz para consulta y reservación de libros……………………..…. 119Figura 59. Resultados de la consulta………………………………………………. 120Figura 60. Invocación de la operación BuscaAlumno…………………………..... 120Figura 61. Usuario no encontrado en la base de datos……………………...…… 121Figura 62. Usuario válido……………………………………………………..……... 122Figura 63. Invocación de la operación Reservar…………………………..……… 122Figura 64. Ejemplar reservado……………………………………………..……….. 123Figura 65. Generación de excepción de tipo SoapFault………………...……….. 123Figura 66. Error en sentencia SQL………………………………………...……….. 124Figura 67. Entorno de prueba con Windows XP sobre VmWare………...……… 128Figura 68. Aplicación utilizada en la prueba de rendimiento…………………..… 134Figura 69. Proceso de petición-respuesta de la prueba de rendimiento……..… 135Figura 70. Cabecera HTTP enviada a la implementación CGI………………..… 136Figura 71. Respuesta exitosa por parte de la implementación CGI…………….. 136Figura 72. Petición de búsqueda en ABCSIS con el método POST……...…….. 137Figura 73. Script php que recibe los parámetros enviados con el método POST………………………………………………………………………..
137
Figura 74. Respuesta del servidor a una petición de búsqueda en ABCSIS…... 138Figura 75. Múltiples procesos en ejecución en la modalidad CGI…………...….. 139Figura 76. Menor cantidad de recursos utilizados por el prototipo ABCSIS….... 140Figura 77. Promedio de la prueba de ABCSIS con cinco eventos………...……. 141Figura 78. Promedio de la prueba de ABCSIS con cincuenta eventos…..…….. 142Figura 79. Promedio de la prueba de ABCSIS con quinientos eventos…..……. 143Figura 80. Promedio de la prueba de ABCSIS con cinco mil eventos…...……... 143Figura 81. Promedio de la prueba CGI con cinco eventos…………...………….. 144Figura 82. Promedio de la prueba CGI con cincuenta eventos……..…………... 145Figura 83. Promedio de la prueba CGI con quinientos eventos…..…………….. 145Figura 84. Promedio de la prueba CGI con cinco mil eventos……...…………… 146
VI
ÍNDICE DE TABLAS
Tabla 1. Campos de un libro……………………………………………………………… 43 Tabla 2. Evolución de la especificación UDDI………………………………………….. 55 Tabla 3. Capacidad de almacenamiento de PostgreSQL……………………………... 84 Tabla 4. Especificaciones de Address………………………………………………....... 102 Tabla 5. Bindings y sus características principales…………………………………….. 104 Tabla 6. Operaciones de servicio utilizadas en el prototipo…………………..………. 118 Tabla 7. Resultados de la encuesta aplicada en la prueba de Operación ….……………………………………………..................................
131
Tabla 8. Información de la prueba de ABCSIS con cinco eventos…………………… 141 Tabla 9. Información de la prueba de CGI con cinco eventos………………………… 144
1
Resumen
Esta tesis describe el diseño de una arquitectura de software orientada a servicios
basada en la tecnología de servicios Web para el software SIABUC (Sistema Integral
Automatizado de Bibliotecas de la Universidad de Colima), el cual es utilizado para
apoyar en tareas de gestión bibliotecaria. La arquitectura propuesta tiene como
finalidad ofrecer una serie de componentes para que personas con conocimientos en
programación interesadas en extender los servicios ofrecidos por SIABUC puedan
hacerlo a partir de la funcionalidad básica del mismo, por ejemplo desarrollar una
aplicación Web o una aplicación para dispositivos móviles. Entre las principales
ventajas de una arquitectura basada en servicios Web, se encuentran la herencia de
atributos, la independencia del lenguaje de programación, sistema operativo,
transporte de red y mecanismo de almacenamiento utilizado, así como el desarrollo
eficiente, mayor reutilización y mantenimiento simplificado del software. La
arquitectura propuesta se encuentra conformada por 4 capas: consumidores de
servicio, arquitectura ó infraestructura, interfaces de servicio e implementación del
servicio, el lenguaje de programación que se utilizó para su desarrollo fue Visual
Basic 2008 en combinación con el modelo de programación Windows
Communication Foundation (WCF). Actualmente, esta arquitectura forma parte de la
más reciente versión de SIABUC: SIABUC9.
Palabras Clave: Arquitectura de Componentes, Servicios Web, SOA,
Interoperabilidad, Sistemas de Gestión de Bibliotecas.
2
Abstract
This document describes the design of a service-oriented architecture based on Web-
services technology for SIABUC (Integrated Automated System Libraries at the
University of Colima); this software is used to provide library management tasks. The
proposed architecture is intended to offer a series of components that allows
programmers extend the services offered by SIABUC, from its basic core functionality
to more sophisticated services such as a Web or mobile software development for
example. Among the advantages of an architecture based on Web services, inherit
programming-language independence, platform-independence, networking and
storage mechanisms, as well as efficient software development, greater reuse and
software simplified maintenance. The proposed architecture is composed of 4 layers:
consumer, architecture, service interfaces and service implementation. The
programming language that was used for the development was Visual Basic 2008 in
combination with the programming model Windows Communication Foundation
(WCF). Currently, this architecture is part of the latest version of SIABUC: SIABUC9.
Keywords: Component Architecture, Web Services, SOA, Interoperability, Library
Management Systems.
3
1. Introducción En ésta sección se describen las características generales de ésta tesis como los
antecedentes, descripción del problema, hipótesis, objetivos, alcances y limitaciones,
descripción general de ABCSIS y finalmente la metodología utilizada para la
elaboración de dicho trabajo.
1.1 Antecedentes
La tecnología de cómputo distribuido ha sido desarrollada durante los últimos 30
años sin embargo al inicio de su desarrollo era muy cara su implementación, no fue
sino hasta principio de 1970 cuando esto cambio con la aparición de los mainframes,
los cuales fueron más accesibles de adquirir (Krafzig, et al., 2004).
Durante los años 80’s y 90’s la tecnología existente permitía a los equipos de
cómputo acceder a las aplicaciones de manera remota, fue entonces cuando la
ejecución lógica fue dividida entre un cliente y un servidor de base de datos. Para
ayudar en la labor de acceder a las aplicaciones de forma remota surge la tecnología
Common Object Request Broker Architecture (CORBA). La funcionalidad de CORBA
consistía en un identificador único llamado Object Request Broker (ORB) para
acceder a los objetos de manera remota, en lugar de proveer servidores que
expusieran un gran número de funciones remotamente accesibles.
La evolución del ámbito distribuido cambió su rumbo a mitad de los años 90’s,
un ejemplo de ello fue el año 1997 cuando Sun Microsystems introdujo la tecnología
de ambiente distribuido Enterprise Java Beans (EJB) (Krafzig, et al., 2004). EJB es
similar a CORBA, una característica importante de EJB es el concepto de
contenedor, que es el responsable para la administración de recursos como objetos,
conexiones y transacciones en un servidor EJB.
Algunas tecnologías como Remote Procedure Call (RPC), CORBA, Distributed
Component Object Model (DCOM) y EJB dieron inicio al surgimiento de un gran
número de soluciones de ámbito distribuido basadas en middleware. Sin embargo, el
surgimiento de estas soluciones presento un problema, la heterogeneidad de los
middleware, para hacer frente a este inconveniente surgió el Extensible Markup
Language (XML) como un formato independiente de los middleware para el
4
intercambio de datos y documentos entre diferentes aplicaciones (Krafzig, et al.,
2004).
Debido a la necesidad de un estándar para el intercambio de mensajes en
XML, la compañía Microsoft propuso la iniciativa de crear los servicios Web basados
en XML con la utilización del protocolo Simple Object Access Protocol (SOAP), y a su
vez, realizó un lenguaje de definición de interfaz llamado Web Service Description
Language (WSDL) para describir la interfaz de servicio, en la actualidad esta
iniciativa forma parte de los estándares del consorcio World Wide Web (W3C)1 donde
han colaborado las empresas más importantes e influyentes de la Web.
Con el problema de la heterogeneidad de los middleware, SOAP y WSDL
permitieron la unión de varios protocolos de comunicación de bajo nivel, por ejemplo,
SOAP permite la comunicación sobre un middleware existente.
El desarrollo de arquitecturas de cómputo distribuido como CORBA, DCOM,
EJB y servicios Web ha permitido la creación de aplicaciones de gran escala, de esta
manera, proveen las bases de la Arquitectura Orientada a Servicios (SOA por sus
siglas en inglés) (Krafzig, et al., 2004).
Desde el punto de vista tecnológico es importante contar con una arquitectura
de software que sea interoperable, escalable y que además permita la reutilización
de los servicios ofrecidos a los diferentes consumidores. De tal manera que si en el
futuro se desea hacer una actualización al servicio prestado, no se tenga que
modificar la aplicación completa, sino únicamente el servicio, es decir, la
independencia de los servicios. Esta es una de las ventajas de trabajar con SOA.
La utilización de SOA esta en aumento, según un estudio realizado por la
empresa de investigación tecnológica Gartner, predijo que para el 2010 el software
de aplicación tendrá un crecimiento del 80% en sus ganancias a través de productos
basados en SOA (Josuttis, 2007). Dentro de las ventajas que podemos mencionar
acerca de SOA destaca el desarrollo eficiente, reutilización de los servicios,
evolución, interoperabilidad e independencia de los servicios.
El desarrollo de este trabajo está enfocado en la creación de una Arquitectura
Basada en Componentes de Software para la Integración de Servicios (ABCSIS)
1 http://www.w3.org
5
para el Sistema Integral Automatizado de Bibliotecas de la Universidad de Colima
(SIABUC).
1.2 Descripción del problema
En el ámbito de sistemas de información, particularmente en el desarrollo de
sistemas de automatización bibliotecaria, existen en el mercado sistemas
bibliotecarios que ofrecen desde el punto de vista de interoperabilidad, enlace a sus
módulos mediante interfaces denominadas Application Programming Interface (API).
Es precisamente aquí donde se ha detectado un área de oportunidad muy fuerte en
el software SIABUC, ya que los usuarios que lo utilizan han externado a través del
departamento de soporte técnico la necesidad de realizar desarrollos
complementarios para integrarlos al sistema, de manera particular aquellos servicios
que se podrían realizar de manera remota o a distancia para aprovechar el uso de
Internet, como por ejemplo: la reservación de libros, verificación de status,
retroalimentación de novedades. Así mismo, se ha identificado que varias
instituciones cuentan con la infraestructura necesaria y recursos humanos
capacitados que cuentan con sistemas propios complementarios y tienen la
necesidad de enlazarlos con SIABUC, por ejemplo: el desarrollo de una aplicación
para la consulta/reservación de libros que interactúe con un sistema propietario de
control escolar, el cual puede estar basado en un entorno Web, en un dispositivo
móvil.
La solución a esta área de oportunidad fue el desarrollo de una arquitectura
que ofrece servicios Web de manera interoperable, dicha arquitectura es
denominada: Arquitectura Basada en Componentes de Software para la Integración
de Servicios (ABCSIS). La razón de crear esta arquitectura fue para enriquecer el
software SIABUC y proveer un medio que permite conectarlo con desarrollos
propietarios. Específicamente, se busca proveer a los desarrolladores de software
6
una herramienta que les permitan crear e implementar nuevos componentes que
puedan trabajar de manera transparente con SIABUC.
Una de las principales aportaciones de ABCSIS es que será el programador
quien decida el lenguaje y plataforma a utilizar, ya que al utilizar los servicios Web
estos ofrecen la ventaja de ser neutrales en cuanto al lenguaje de programación,
sistema operativo, protocolos de red y mecanismo de almacenamiento utilizado
(Newcomer, 2002). Además, con la utilización de SOA se permite la utilización de un
rango más amplio de interacciones de una manera más flexible que una integración
basada en API’s (Chen y Huang, 2006).
1.3 Hipótesis
La arquitectura ABCSIS permitirá, a las instituciones que hacen uso de SIABUC y
que cuenten con personal de perfil informático o áreas afines, poder implementar
mecanismos interoperables que permitan la comunicación con otras aplicaciones.
1.4 Objetivos 1.4.1 Objetivos Generales
Crear una metodología de desarrollo de software basado en SOA para el software
SIABUC, con la finalidad de extender los servicios que actualmente se ofrecen.
1.4.2 Objetivos Específicos
• Comprender el funcionamiento de los servicios Web y sus estándares XML
relacionados.
7
• Investigar acerca de la arquitectura SOA y su implementación con los
servicios Web.
• Entender el funcionamiento de los conceptos de SOA en el modelo de
programación Windows Communication Foundation.
• Realizar un análisis en SIABUC para identificar los servicios que pueden ser
extendidos con la arquitectura propuesta.
• Crear un prototipo tomando como base la arquitectura propuesta, el cual
estará conformado por un conjunto de servicios.
• Probar los servicios para detectar posibles fallas en una implementación
posterior.
• Invocar un servicio dentro de una aplicación prototipo.
1.5 Alcances y Limitaciones En este trabajo se realizó el diseño y creación de servicios utilizando como
arquitectura base SOA, tomando en cuenta las áreas de oportunidad más relevantes
en SIABUC. Para fines de prueba y demostración se creó un prototipo donde se
muestra la interacción entre el servicio de reservación, alojado en el servidor Web
Internet Information Server (IIS). El cliente fue desarrollado en el lenguaje de
programación PHP, con la finalidad de demostrar la independencia entre los
lenguajes de programación. Cuando el usuario hace una reservación a través del
prototipo se ve reflejada de manera automática en el módulo de Préstamo de
SIABUC, este módulo es el que cotidianamente utilizan en la biblioteca para registrar
los prestamos y devoluciones de material bibliográfico.
8
1.6 Descripción general de ABCSIS
Con la utilización de la arquitectura ABCSIS es posible crear componentes de
software que se conecten a SIABUC, de esta manera las personas interesadas en
desarrollar servicios adicionales a SIABUC podrán hacerlo de una manera
relativamente sencilla, por ejemplo, una aplicación Web ó una aplicación móvil que
incorporen la reservación de ejemplares, consulta de disponibilidad de ejemplares,
verificación de adeudos. Todo ello con la finalidad de proporcionar más y mejores
servicios bibliotecarios y acercarlos a los usuarios finales de una determinada
biblioteca o centro de información. Cabe señalar que estas opciones se encuentran
incorporadas en la versión completa de SIABUC, pero su funcionalidad solo se
puede utilizar mediante los clientes de escritorio o aplicaciones de tipo Windows.
A continuación, en la siguiente figura se muestra un esquema con el
funcionamiento/invocación de un servicio mediante ABCSIS. La imagen en cuestión
está basada en la estructura de la arquitectura SOA mostrada en la sección 3.3.2 de
este trabajo.
Figura 1. Ejemplo de funcionamiento de un servicio bajo ABCSIS
La descripción de los elementos que conforman la figura 1 incorporados a
SIABUC mediante ABCSIS funcionan de la siguiente manera:
Bus de Servicio
Crea
Cumple
Invoca
Describe
Busca
Programador
Aplicación
Repositorio de Servicio
Contrato WSDL
Servicio
Web
9
Repositorio de servicios Se trata de una descripción del servicio, la cual se
encuentra en un archivo Web Service Description Language (WSDL), en este archivo
se encuentra una descripción de la interfaz del servicio en formato XML.
Bus de Servicio Son los protocolos de red por el cual se invocará al servicio Web.
Servicio Este apartado lo conforman cada uno de los servicios a ofrecer.
Aplicación Son las distintas aplicaciones que los programadores (consumidores de
servicio) de las diferentes instituciones podrán realizar, en este sentido, el
programador puede realizar cualquier aplicación que necesite.
1.7 Metodología
Para la realización de este proyecto se siguieron una serie de pasos, los cuales se
describen a continuación:
• Investigación documental
Consiste en buscar información acerca de las tecnologías relacionadas con el
desarrollo de la arquitectura propuesta, principalmente artículos, así como
libros de actualidad, en el caso de los artículos la mayor fuente de consulta fue
la biblioteca digital ACM, así como artículos creados por empresas de
renombre como IBM, Microsoft y organismos independientes como Apache
Group, OASIS, entre otros.
• Diseño de la arquitectura
Elaboración del modelo conceptual de la arquitectura propuesta, básicamente
se genero un esquema de la arquitectura ABCSIS con el funcionamiento
propuesto.
• Desarrollo del prototipo funcional
Consistió en la elaboración de una aplicación que consume el servicio de
reservación de libros para demostrar su funcionalidad e interoperabilidad.
• Evaluación del prototipo funcional
Esta etapa consistió en realizar pruebas de operación y pruebas de
rendimiento.
10
• Documentación de la investigación
Consiste en redactar el documento de la tesis.
• Análisis de los resultados obtenidos.
1.8 Estructura del documento de la tesis
Esta tesis se encuentra organizada en 7 secciones:
Sección 1. Introducción Se describen las características generales de esta tesis
como los antecedentes, descripción del problema, hipótesis, objetivos, alcances y
limitaciones, descripción general de ABCSIS y finalmente la metodología utilizada
para la elaboración de dicho trabajo.
Sección 2. Antecedentes Se aborda los aspectos iniciales de la tecnología de
cómputo distribuido de manera general así como la evolución que ha tenido a lo largo
de la historia. Otro de los tópicos de este apartado es lo relacionado a los sistemas
de automatización bibliotecaria, SIABUC y su arquitectura, así como también los
trabajos relacionados a SOA y los sistemas bibliotecarios.
Sección 3. Marco Teórico Se mencionan de manera detallada los servicios Web y
SOA, así como el estado actual que guardan estas tecnologías. También se
mencionan las definiciones correspondientes a estos conceptos, los cuales son
utilizados en secciones posteriores.
Sección 4. Arquitectura de ABCSIS Se aborda todo lo relacionado con el desarrollo
de la arquitectura propuesta, desde el modelo conceptual hasta la descripción de los
componentes e interfaces.
Sección 5. Desarrollo de ABCSIS Se aborda la parte de programación de ABCSIS,
la creación del servicio, el hosting del servicio y un prototipo funcional.
Sección 6. Pruebas Este apartado trata sobre el empleo de pruebas de laboratorio y
posteriormente se llevó a cabo la interpretación de los resultados.
Sección 7. Conclusiones Se muestran los resultados obtenidos en las pruebas,
mediante el análisis de los mismos de forma cualitativa y cuantitativa, además se
hacen una serie de recomendaciones para trabajos futuros.
11
2. Antecedentes En este capitulo se aborda de manera introductoria dos aspectos fundamentales para
el desarrollo de la tesis, por una parte se mencionan los conceptos computacionales
y por otra, lo referente a los sistemas bibliotecarios, para finalmente, abordar los
trabajos relacionados tanto al aspecto tecnológico y al bibliotecario.
2.1 Marco Histórico
La tecnología de cómputo distribuida fue desarrollada a finales de los años 30’s.
Originalmente el cómputo de negocios significaba la utilización de computadoras
poderosas que costaban millones de dólares. Algunas de las primeras cosas que los
sistemas tenían para compartir entre ellos eran dispositivos como grabadoras y
sistemas de impresión. No fue sino hasta los años 70’s cuando la computadora se
hizo más sofisticada y a un precio mucho más accesible. Las instituciones de
investigación rápidamente se dieron cuenta que podían operar con menos
presupuesto y de forma independiente cuando fueron capaces de utilizar
computadoras pequeñas en lugar de mainframes (Krafzig, et. al., 2004).
Posteriormente, en la década de los 80’s la Universidad de Standford
mediante un proyecto para conectar su red, dio comienzo a la creación de la
compañía Sun Microsystems, en la actualidad esta compañía es uno de los mayores
vendedores de computadoras con sistema operativo Unix (Krafzig, et al., 2004). El
sistema operativo Unix fue diferente de sus predecesores y varios de sus sucesores
adoptaron el diseño de red como parte esencial del sistema operativo. De manera
particular dos ideas originan esta perspectiva orientada a la red; la primera es facilitar
el control a distancia de computadoras y programas, mientras que la segunda trata
de proveer servicios a otras computadoras en la red. La primera idea fue en el
sentido de crear herramientas como telnet, mientras que la segunda se trata de una
característica de impresión remota y suministrar espacio de almacenamiento con el
sistema de archivos Network File System (NFS) creado por Sun Microsystems en
1984 (Krafzig, et al., 2004). Derivado de estas herramientas surgió el estándar SUN-
RPC, el primer sistema que utilizó procedimientos remotos.
12
Aún cuando el cómputo distribuido se encontraba disponible en la década de
los 80’s solamente estaba enfocado principalmente al ámbito académico, lo cual
permaneció hasta los años 90’s. En esa época, los equipos de cómputo accedían a
sistemas de almacenamiento e impresión. Una gran cantidad de aplicaciones
residentes en el cliente hacían peticiones de forma remota a un servidor de base de
datos. Fue entonces cuando la ejecución lógica fue dividida entre un cliente y un
servidor de base de datos. La compañía Sybase2 por su parte, introdujo el concepto
de procedimientos almacenados, los cuales, consistían en funciones que eran
ejecutadas en la base de datos y no necesitaban enviarse al cliente.
Combinando los conceptos de las plataformas de cómputo distribuido como
Distributed Computing Environment (DCE) con el paradigma de la orientación a
objetos, surge Common Object Request Broker Architecture (CORBA). En lugar de
proveer servidores que expusieran un gran número de funciones remotamente
accesibles, la funcionalidad ahora, se descompone en un identificador único que es
accesible por objetos de manera remota. Diferentes objetos pueden comunicarse con
otros por medio del Object Request Broker (ORB). ORB provee mecanismos de
abstracción, como nombres de servicios, que se encargan de descubrir los objetos
en tiempo de ejecución. De manera similar a la programación orientada a objetos,
CORBA adopta el concepto de programación de interfaces, todos los objetos de
CORBA pueden ser implementados en varios lenguajes de programación, mientras
sus interfaces son descritas utilizando el lenguaje Interface Definition Language
(IDL). Krafzig, et al. (2004) mencionan que CORBA es ampliamente utilizado por la
tecnología de ambiente distribuido, especialmente en telecomunicaciones y servicios
financieros.
La evolución del ámbito distribuido cambió su rumbo a mitad de los años 90’s,
tomando en consideración las limitaciones de las arquitecturas de objeto distribuido.
Por su parte, Sun Microsystems3 introdujo un conjunto de APIS llamadas Enterprise
Java Beans (EJB) en el año 1997. EJB es similar a CORBA, una característica
importante de EJB es el concepto de contenedor, que es el responsable para la
2 http://www.sybase.com 3 http://www.sun.com
13
administración de recursos como objetos, conexiones y transacciones en un servidor
EJB. De manera similar a otras plataformas de computación remota como DCE y
CORBA, EJB incluye un alto nivel de servicios técnicos, como un administrador de
transacciones, llamada a servicios y seguridad.
Algunas tecnologías como RPC, CORBA, DCOM y EJB dieron inicio al
surgimiento de un gran número de soluciones de ámbito distribuido basadas en
middleware. Sin embargo, el surgimiento de estas soluciones presento un problema,
la heterogeneidad de los middleware, para hacer frente a este inconveniente surgió
el Extensible Markup Language (XML) como un formato independiente de los
middleware para el intercambio de datos y documentos entre diferentes aplicaciones
(Krafzig, et al., 2004).
A diferencia de otros lenguajes como CORBA IDL, Microsoft IDL o Java, XML
no requiere de una tecnología o middleware específico, en la actualidad es utilizado
como un formato de procesamiento de datos multiplataforma.
XML es muy potente debido a su enorme flexibilidad, sin embargo, presenta
un problema en la integración de aplicaciones de manera eficiente, ya que requiere
de un alto nivel de estructuras de datos y formatos de mensajes. Para resolver este
problema, surgieron estándares como XML Document Type Definition (DTD’s) y
esquemas para la especificación y validación de datos complejos en XML.
Debido a la necesidad de un estándar de mensajes XML de alto nivel,
Microsoft en el año 1998, se dio a la tarea de utilizar servicios Web basados en XML
con la creación del protocolo Simple Object Access Protocol (SOAP). La versión
inicial de SOAP fue específicamente creada para trabajar en la Web con el protocolo
HyperText Transfer Protocol (HTTP), debido a que en Internet ya estaban resueltos
varios problemas como la seguridad (SSL, firewall, control de acceso), disponibilidad
de la red, tráfico de red y administración de aplicaciones (Krafzig, et al., 2004).
Utilizando los métodos de petición GET y POST del protocolo HTTP, los
clientes SOAP son capaces de llamar a funciones que se encuentran previamente
establecidas en Internet. Pero el desarrollo de Microsoft no paro en este sentido, ya
que tiempo después, realizó un lenguaje de definición de interfaz llamado Web
Service Description Language (WSDL). WSDL describe la interfaz de servicio, tal
14
como IDL describe la interfaz de un objeto en CORBA. Con el problema de la
heterogeneidad de los middleware, SOAP y WSDL permitieron la unión de varios
protocolos de comunicación de bajo nivel, por ejemplo, SOAP permite la
comunicación sobre un middleware existente. SOAP fue evolucionando gracias a
IBM y Microsoft hasta convertirse en una estándar en el consorcio W3C en el año
2001.
El desarrollo de arquitecturas de cómputo distribuido como DCE, CORBA,
DCOM, EJB y servicios Web ha permitido la creación de aplicaciones de gran escala,
de esta manera, proveen las bases de Service Oriented Architecure (SOA) (Krafzig,
et al., 2004).
El término servicio ha sido utilizado en diferentes contextos y propósitos.
Hubbers, Ligthart y Terlouw (2007) definen un servicio como una manera uniforme
basada en estándares internacionales (XML, SOAP, WS), o que pueden ser basadas
en medios tradicionales y propietarios. Mientras que Krafzig, et al. (2004) definen un
servicio como un componente de software que contiene características funcionales
que encapsulan el concepto lógico con el que fue elaborado.
El núcleo de la orientación a servicio esta compuesta por tres áreas:
paradigmas de programación, tecnología distribuida y cómputo de negocio (Krafzig,
et al., 2004). Muchos de los conceptos originales encontrados en los lenguajes de
programación han trazado su propio camino dentro de la tecnología distribuida que
se utiliza para ofrecer acceso remoto a servicios de diferentes aplicaciones en
diferentes plataformas. Finalmente, la evolución de cómputo de negocio ha dado
origen a aplicaciones empaquetadas como Enterprise Resource Planning (ERP),
Customer Relationship Management (CRM) y Supply Chain Management (SCM), que
en la actualidad proveen los datos y la lógica del negocio.
En base a las definiciones anteriores de servicio y a la diversidad que existen
del mismo el término, se entiende por servicio al conjunto de funciones que son
encapsuladas para responder una petición. Mientras que la lógica del negocio se
entiende por la interfaz backend, se dice que es orientada a negocio porque utiliza
los conceptos de contrato, servicio y cliente.
15
Debido a la cercanía de los servicios a la funcionalidad del negocio, la
orientación a servicio tiene el potencial para ser el primer paradigma que
verdaderamente lleve a la tecnología y a la funcionalidad del negocio a un nivel
donde las personas puedan entender estos conceptos (Krafzig, et al., 2004).
En la figura 2, podemos apreciar la evolución que ha tenido SOA, partiendo
desde los lenguajes de bajo nivel como el ensamblador, hasta los lenguajes de alto
nivel como Java (trad. Krafzig, Banke y Slama 2004).
Figura 2. Evolución de la Arquitectura Orientada a Servicios
Orígenes del término SOA. En el año de 1994 Alexander Pasik, un analista de la empresa Gartner, acuño el
término SOA para una clase que formaba parte de un middleware. Pasik era
desarrollador de software desde antes que el lenguaje XML o los servicios Web
fueran inventados (Josuttis, 2007). Alexander decidió crear el término SOA porque la
definición cliente-servidor había perdido su significado clásico. Muchas industrias
habían comenzado a utilizar el término cliente-servidor para definir a una
computadora en un entorno distribuido. Una computadora cliente ejecutaba la
presentación lógica de la interfaz de usuario y la mayoría de la lógica del negocio.
Por su parte el servidor, almacenaba los datos en un sistema administrador de base
de datos y en ocasiones ejecutaba la lógica del negocio. En este sentido, los
términos cliente y servidor básicamente se referían al hardware.
Para evitar confusión entre los antiguos y los nuevos términos cliente-servidor,
Pasik menciono que la orientación a servicio es una gran ayuda para los
desarrolladores de SOA que trabajen con aplicaciones empresariales.
16
El momento real para SOA fue creado por los servicios Web, que inicialmente
fueron creados por Microsoft. Pronto, otras compañías como Oracle, HP, SAP y Sun
aportaron su capital para agrandar la idea y vender nuevos conceptos y
herramientas.
Tiempo después, los analistas comenzaron a ofrecer SOA como el concepto
clave para el futuro del desarrollo de software. Por ejemplo, la empresa de
consultoría e investigación tecnológica Gartner4 predijo que para el 2010 el software
de aplicación tendrá un crecimiento del 80% en sus ganancias a través de productos
basados en SOA (Josuttis, 2007).
Si bien es cierto que Pasik dio forma al término SOA, hasta el momento no
existe un grupo, organización o consorcio oficial que lleve la pauta en este sentido.
Recientemente el consorcio OASIS (Organization for the Advancement of Structured
Information Standards), una organización dedicada al desarrollo de estándares e-
business, ha liberado un borrador de un modelo de arquitectura SOA el cual esta
diseñado en el lenguaje UML 2 (OASIS, 2008a). Mientras que empresas como
Microsoft, IBM, Oracle y el Software Engineering Institute también cuentan con su
propio modelo de arquitectura SOA.
4 http://www.gartner.com/
17
2.2 Marco Contextual 2.2.1 Los sistemas de automatización de bibliotecas
Una de las primeras referencias en relación a este tema data del año 1958, fue en
este periodo cuando la Biblioteca del Congreso de los Estados Unidos comenzó este
proceso y tiempo después, en el año 1963, generó un reporte titulado: La
automatización en la Library of Congress, dicho trabajo se encontraba dividido en
tres áreas principales: procesamiento bibliográfico, búsquedas bibliográficas y
recuperación de documentos. Posteriormente, en el año 1965 se inició un proyecto
piloto conocido como Machine Readable Cataloging (MARC) (Brinati, 2003).
Sin embargo, el hablar de la automatización de bibliotecas no significa el
desplazamiento del bibliotecario, sino más bien, la utilización y aprovechamiento de
la tecnología en el sistema bibliotecológico.
La automatización pues, es el uso de la computadora para realizar los
procesos que se desarrollan cotidianamente en la biblioteca; los sistemas de
automatización son el conjunto de programas con funciones y acciones específicas
para agilizar los procesos en las bibliotecas, siendo la biblioteca el centro activo de
investigación e información en disciplinas extensas e interrelacionadas (Herrera-
Morales, et. al., 2004).
La automatización de bibliotecas fue un proceso difícil durante dos décadas,
sin embargo, esto ha ido transformándose paulatinamente y fue hasta los años 90’s
cuando éste término se concibe como un concepto mucho más amplio que involucra
el procesamiento de la información más allá de la generación de catálogos en línea
(Brinati, 2003).
Casi la totalidad de bibliotecas universitarias en México tienen automatizada
por lo menos alguna de sus áreas de trabajo, desafortunadamente son pocas las que
han logrado implementar un sistema de automatización integral (Lugo, 2000).
Hasta el año 1995 los sistemas más utilizados eran Microisis, SIABUC y
Logicat, éstos dos últimos fueron desarrollados en México, el primero de ellos fue
realizado por la Dirección General de Servicios Bibliotecarios de la Universidad de
Colima, mientras que el segundo fue hecho por una empresa privada (Lugo, 2000).
18
El sistema SIABUC ha evolucionado y el impacto y penetración que ha logrado
es evidente, la versión SIABUC8 es utilizada en más de 1500 instituciones públicas y
privadas de México, América Latina y el Caribe (Herrrera-Morales, 2007).
Otros sistemas utilizados son Aleph5, Alexandria6, Unicorn7, Virtua8 e
Innopac9, éstos sistemas incorporan muchos rasgos tecnológicos pero son
sumamente costosos ya que son elaborados por empresas transnacionales, por lo
que en la mayoría de las ocasiones resultan inaccesibles para las bibliotecas típicas
de instituciones latinoamericanas.
A continuación se menciona una breve reseña con algunas características de
estos sistemas:
Microisis
Este software fue creado por la Organización de las Naciones Unidas para la
Educación, la Ciencia y la Cultura (UNESCO) en los años 60’s, esta basado en
archivos y no cuenta con una arquitectura mediante la cual se permita hacer algún
tipo de desarrollo adicional con la información almacenada. La adquisición de este
software no tiene costo a través de distribuidores nacionales, la Universidad de
Colima a través del Centro Nacional de Edición Digital y Desarrollo de Tecnologías
de Información (CENEDIC) es distribuidor de este sistema a nivel nacional
(Universidad de Colima, 2006).
Logicat
Este sistema fue diseñado para la recuperación de información en normas
internacionales. La arquitectura que posee es cerrada debido a que los servicios que
ofrece a través de Internet están predeterminados y se basan principalmente en el
intercambio de mensajes entre el propio sistema para establecer la comunicación
con los usuarios finales (Grupo Sistemas Lógicos, 2007a).
Aleph
El sistema Aleph (Automated Library Expandable Program) fue desarrollado
en la década de los 80’s en la universidad Hebrea de Jerusalén, Israel y es
5 http://www.gsl.com.mx/aleph.html 6 http://www.alexandria.cl/ 7 http://www.sirsidynix.com/ 8 http://www.vtls.com/products/virtua 9 http://www.iii.com/index.php
19
distribuido por la empresa ExLibris. Dicho sistema utiliza la tecnología cliente-
servidor e incluye clientes basados en Microsoft Windows. Su arquitectura es semi-
abierta ya que ofrece enlaces mediante interfaces API hacia otras aplicaciones
(Grupo Sistemas Lógicos, 2007b).
Unicorn
Sirsi’s Unicorn Library Management System como actualmente se le conoce a
este sistema, es desarrollado por la empresa SirsiDynix, dicho sistema administra los
servicios técnicos y públicos de una biblioteca. Desde sus inicios ha utilizado la
arquitectura cliente-servidor. Cuenta con una arquitectura abierta ya que provee el
acceso mediante API’s a todos los módulos que lo componen (SIRSI, s.f.).
Innopac
En el ámbito bibliotecario este sistema es mejor conocido como
Innopac/Millenium, es distribuido por la empresa Innovate Interfaces, utiliza el
entorno Web en combinación con la plataforma Java. Dentro de los paquetes para
montar el acervo bibliográfico en Web se encuentra el AirPAC, el cual es un Online
Public Access Catalog (OPAC) diseñado especialmente para usuarios que buscan
información en el catálogo desde dispositivos móviles con acceso inalámbrico, su
arquitectura es cerrada al desarrollo ya que a diferencia de los sistemas anteriores
no provee API’s para acceder a la información que almacena (INNOVATIVE
Interfaces, 2006).
Hasta aquí se ha comentado los inicios de la automatización bibliotecaria, así
como algunos de los sistemas más utilizados en este ámbito, a continuación se
hablará acerca de SIABUC, sus inicios, los módulos que lo conforman, así como
también el impacto que ha tenido tanto en México como en Latinoamérica.
2.2.2 Sistema Integral Automatizado de Bibliotecas de la Universidad de Colima (SIABUC)
Fue en el año de 1983 cuando la Universidad de Colima incursionó en el ámbito
tecnológico, durante ese año se creo la Dirección de Desarrollo Bibliotecario, cuyo
20
objetivo principal fue estructurar un sistema de bibliotecas para apoyar con servicios
de información bibliográfica y documentar las labores sustantivas de docencia e
investigación en todos los campos de la Universidad, centralizando sus procesos de
adquisición, catalogación y clasificación. Debido a esto surgió la necesidad de
automatizar dichos procesos y servicios de información (Herrera-Morales, et al.,
2004).
Para satisfacer esas necesidades se realizó un estudio de experiencias sobre
sistemas de automatización bibliotecaria y sus casos de éxito en las bibliotecas
mexicanas, al identificar la carencia de este tipo de tecnología informática y el
desconocimiento por parte de los bibliotecarios se diseño SIABUC (Sistema Integral
Automatizado de Bibliotecas de la Universidad de Colima).
En aquel entonces, el objetivo principal de SIABUC era generar un fichero
electrónico que facilitara el proceso de impresión de los catálogos topográficos de la
entonces única biblioteca que tenia la Universidad, sin embargo, debido a la carencia
de este tipo de software se plantea el proyecto a nivel nacional ante Consejo
Nacional de Ciencia y Tecnología (CONACYT) y la Secretaría de Educación Pública
(SEP), con la finalidad de obtener recursos económicos para mejorarlo y
posteriormente ofrecerlo a las bibliotecas públicas mexicanas (Herrera-Morales, et
al., 2004).
SIABUC es un software que fue creado en la Universidad de Colima como
respuesta a una necesidad interna de preparar juegos de fichas catalográficas, sin
embargo, el proyecto creció y fue cubriendo gradualmente cada una de las tareas
comprendidas en el diagrama de flujo de actividades de las bibliotecas (Lugo, 2000).
El impacto y trascendencia que SIABUC ha tenido es evidente puesto que
actualmente es utilizado en más de 2500 instituciones públicas y privadas de México,
América Latina y el Caribe (Herrera-Morales, 2007).
Presencia de SIABUC en Latinoamérica La primera institución usuaria y representante de SIABUC en Costa Rica fue la
Escuela Centroamericana de Ganadería, en 1989, en Balsa de Atenas, provincia de
Alajuela.
21
Durante ese mismo año el Instituto Tecnológico de Costa Rica inicia con el
uso de SIABUC, actualmente cuentan con la versión SIABUC8 en funcionamiento.
En la actualidad, más de 50 bibliotecas son usuarias de SIABUC, dentro de las
instituciones más representativas en ese país se encuentran las siguientes: Corte
Interamericana de Derechos Humanos, Escuela de Ciencias del Deporte, Asamblea
Legislativa, Biblioteca Nacional, Instituto Nacional de Biodiversidad, Universidad
Latina, Universidad Veritas, Biblioteca de la Facultad de Letras, Instituto de Alajuela,
Fundación Omar Dengo, Sistema de Bibliotecas Públicas de Costa Rica, Universidad
para la Paz, entre otras.
Otro país centroamericano que utiliza SIABUC es Colombia, aquí las
instituciones pioneras son la Universidad de Cauca y la Universidad de Caldas.
Durante el 2003 se firmó un convenio entre la Universidad de Colima y el Ministerio
de Cultura de Colombia para un proyecto denominado “Apoyo para la
Sistematización de la Red Nacional de Bibliotecas Públicas”, esto con la finalidad de
que SIABUC8 fuera la herramienta de automatización utilizada en más de 500
bibliotecas en aquel país.
Mientras que en Nicaragua, la primera institución en utilizar SIABUC fue la
UNAN-León de Nicaragua y posteriormente la Universidad Centroamericana (UCA).
Actualmente son 42 las instituciones que tienen convenio firmado con la Universidad
de Colima para la utilización de SIABUC.
México por su parte no se queda atrás, hay varias instituciones importantes
que cuentan con SIABUC, dentro de las cuales destacan las siguientes: Centro de
Investigaciones del IPN, Colegio de Pilotos Aviadores de México, Centro de
Investigación en Matemáticas, Instituto Nacional de Astrofísica Óptica y Electrónica,
Universidad Autónoma de Guadalajara, Congreso del Estado de Michoacán, Hospital
General de México, Universidad del Valle de Atemajac, Universidad Autónoma
Chapingo, Museo de Historia Mexicana, Congreso del Estado de Morelia, INEGI
entre otras más.
Módulos que integran SIABUC SIABUC a diferencia de otros sistemas de automatización bibliotecaria es un sistema
22
integral, es decir, está conformado por varios módulos de manera conjunta y no
separados como otros sistemas, a continuación se describe una breve reseña de los
módulos que conforman SIABUC:
• Adquisiciones: Mediante este módulo es posible llevar a cabo un control de
los presupuestos, compras, pedidos, recepciones, donaciones y facturas, así
como también permite llevar a cabo la asignación de folios de los libros ó
números de inventario.
• Análisis: En este apartado se puede llevar a cabo la catalogación o
descripción de los diferentes tipos de materiales que se encuentran en la
biblioteca, como por ejemplo: libros, cd, dvd, mapas, revistas, folletos.
• Indizado: Prepara los índices de la base de datos para hacer posible la
búsqueda en el acervo bibliográfico.
• Estadísticas: Mediante esta aplicación se puede obtener información
concentrada sobre los procesos y tareas más importantes llevadas a cabo
con SIABUC.
• Préstamos: Con este módulo es posible llevar a cabo los procesos de
circulación o préstamo del material bibliográfico, incluye una serie de
herramientas para ayudar en esta labor así como una serie de reportes.
• Publicaciones: El objetivo principal de este módulo es el de registrar,
administrar y controlar el material hemerográfico como: revistas, periódicos,
boletines, gacetas y en general cualquier publicación seriada de divulgación
constante.
• Consultas: Este módulo reemplaza a los ficheros de consulta tradicionales,
permite que los usuarios exploren el acervo de la biblioteca de una forma
rápida y sencilla. Se pueden hacer búsquedas simples así como también
búsquedas avanzadas utilizando los operadores boléanos.
• Inventarios: La finalidad que pretende este módulo es la de comparar lo que
existe físicamente en el acervo contra lo que se tiene capturado en la base
de datos de SIABUC.
• Servicios: Con este módulo se puede llevar a cabo el préstamo y control de
los espacios (cubículos, salas de lectura) y equipos de cómputo que se
23
utilizan en las salas de consulta o de acceso a Internet de la biblioteca.
Además de estos módulos cuenta con dos componentes adicionales para
montar los registros bibliográficos en Internet, uno de ellos hace uso de la tecnología
Common Gateway Interface (CGI) y es llamado WebS8, mientras que el segundo
componente es una interfaz API, la cual se puede utilizar en combinación con
tecnologías como PHP y ASP. Estos componentes se describen a fondo en la
siguiente sección.
2.2.2.1 Arquitectura Actual de SIABUC
La arquitectura actual de SIABUC para la prestación del servicio de consulta a través
de Internet es cerrada tal como se puede apreciar en la figura 3, se encuentra
basada en la API WebS8dll ó en la implementación CGI WebS8. El objetivo principal
de estas dos aplicaciones es la de recuperar la información bibliográfica a través de
Internet utilizando las plataformas de Microsoft Windows.
En el departamento de soporte técnico de SIABUC los usuarios han externado
la necesidad de incorporar nuevas funcionalidades a SIABUC aparte de la consulta
Web, por ejemplo la reservación, esta limitante es la causa principal por la que
dichas funcionalidades no han sido muy explotadas. La arquitectura actual de
SIABUC se encuentra compuesta por dos capas: aplicación y acceso a datos, esta
arquitectura se puede apreciar en la figura 3.
Figura 3. Arquitectura actual de SIABUC8
Base de Datos
Interfaces de acceso a datos
Capa de Aplicación
Capa de Acceso a Datos
API WebS8dll / CGI
24
La capa de acceso a datos esta integrada por el motor Microsoft Access en su
versión 2000, mientras que la capa de aplicación esta conformada por la API
WebS8dll ó por el componente CGI.
A continuación, en los siguientes apartados se menciona con detalle lo
concerniente a la capa de aplicación de SIABUC8.
2.2.2.2 CGI WebS8
Common Gateway Interface (CGI) es una de las tecnologías estándar que provee el
paso de información entre el servidor y los clientes (explorador Web), las
aplicaciones CGI pueden ser escritas en cualquier lenguaje de programación como
Shell, C, C++, FORTRAN, Java. Sin embargo, Shell, Perl y C son los más utilizados
para desarrollar este tipo de aplicaciones (Misra y Murthy, 2001).
SIABUC utiliza la tecnología CGI para implementar las consultas del acervo a
través del Web, el núcleo de la implementación es una aplicación llamada
WebS8.exe.
Para montar las consultas en Web, además del WebS8 se requiere de un
servidor Web, una página de consultas, un archivo de configuración para los
parámetros y formatos de respuesta y las bases de datos previamente indexadas. El
servidor por su parte, debe cumplir ciertos requisitos para que el WebS8 funcione
correctamente, las cuales se mencionan a continuación:
- Compatible con sistemas operativos Microsoft Windows
- Compatible con CGI versión 1.1 en adelante
- Debe admitir la ejecución de programas de 32 bits
Los acervos que se pueden consultar son los que corresponden a los libros y
las revistas.
La aplicación WebS8 está realizada con el lenguaje de programación Visual
Basic 6, sin embargo dicha aplicación se entrega al usuario compilada, sin que este
pueda hacer modificación alguna.
25
La tecnología CGI fue una de las primeras en permitir contenido dinámico, sin
embargo, ha sido sustituida por tecnologías script como PHP, JSP ó ASP.
En la actualidad, debido a los ataques de virus en los equipos de cómputo, los
sistemas operativos como Windows han implementado mayores medidas de
seguridad, dichas medidas afectan la correcta ejecución de las aplicaciones CGI,
debido a esto, el departamento de SIABUC se dio a la tarea de realizar una nueva
implementación para montar los catálogos en Internet y estar a la vanguardia con
estas nuevas tecnologías y tendencias, esta nueva implementación se trata de una
interfaz API, la cual se describe con mayor detalle en el siguiente apartado.
2.2.2.3 API WebS8
Una API es una Interfaz de Programación de Aplicaciones, por la cual una aplicación
(servidor) expone su interfaz gráfica de usuario (UI) y contenido a otra aplicación
(cliente) (González y Guarino, 2005).
En Diciembre de 2006 el departamento de SIABUC realizó una interfaz de
software llamada API WebS8DLL, la cual permite programar aplicaciones adicionales
a los módulos de SIABUC, por ejemplo, la implementación de los catálogos de
consulta al acervo vía Web utilizando tecnologías script como PHP o ASP (Herrera-
Morales, 2006).
La API WebS8DLL esta conformada por un conjunto de código encapsulado
que contiene principalmente funciones y métodos, los cuales hacen posible la
conexión a la base de datos de SIABUC, el objetivo de esta API es realizar
búsquedas en el acervo bibliográfico y visualizar información seleccionada en
diferentes formatos preestablecidos (Herrera-Morales, 2006).
Para emplear esta API es necesario utilizar la plataforma de cómputo
adecuada que soporte la correcta instanciación de componentes ActiveX, debido a
que la API está desarrollada bajo esta tecnología propietaria de Microsoft solo es
posible implementarla bajo sistemas operativos Microsoft Windows.
El lenguaje de desarrollo recomendado para implementarla es ASP en
26
combinación con el servidor Web Internet Information Server (IIS) de Microsoft, sin
embargo, también es posible utilizarla con el lenguaje de programación PHP.
Actualmente, existe una nueva versión de SIABUC llamada SIABUC9, esta
nueva versión permitió la reestructuración del sistema y la incorporación de un nuevo
motor de base de datos, PostgreSQL. Debido a esto, también fue factible la creación
de un nuevo esquema de arquitectura para utilizarla en conjunto con esta nueva
versión de SIABUC.
27
2.3 Trabajos Relacionados
Esta sección presenta el trabajo relacionado para resolver los problemas de
integración de sistemas legados, así como también la integración de sistemas bajo la
arquitectura SOA.
La arquitectura SOA se ha caracterizado por su interoperabilidad entre
sistemas y la independencia de los servicios (Newcomer, 2004), sin embargo, a
pesar de estas ventajas no existe una empresa u organismo que se atribuya su
creación, ya que básicamente SOA ha sido una evolución de la manera en la que se
comunican los sistemas computacionales en ambientes heterogéneos.
Dentro de los aportes de SOA se encuentra la de resolver la problemática de
los sistemas legados, este tipo de sistemas son difíciles de mantener y se necesita
personal capacitado y experto en esta área para su administración (Electronic Data
System, 2008), sin embargo mediante SOA se pueden exponer las funcionalidades
de éstos como servicio (Arcelli, Tosi y Zanoni, 2008).
Podemos mencionar que existen trabajos antecedentes a este proyecto donde
se ha tratado de mejorar los servicios de SIABUC aplicando tecnologías como
servicios Web o encapsulamiento de código, por ejemplo, el realizado en el año 2002
por Santana (2002) en el que se integran los servicios de consulta de material
bibliográfico utilizando la plataforma .NET como herramienta de desarrollo,
desafortunadamente no se le dio seguimiento al proyecto y no se logró implantar.
Además de este trabajo existe otro similar, una herramienta llamada Sistema de
Solicitudes de Compra Bibliográfica (SISOCOBI) cuyo objetivo fue ayudar en el
proceso de compra de bibliografía, básicamente consiste en consumir los servicios
Web desarrollados por la compañía estadounidense Amazon y obtener la
información correspondiente a los libros (Ponce, et. al., 2004), al igual que el
desarrollo anterior es un componente adicional para SIABUC.
Sin embargo, fuera del ámbito bibliotecario existen trabajos relacionados
donde se ha utilizado la arquitectura SOA con éxito, como por ejemplo, el elaborado
en el año 2006 por Chen. y Huang (2006) la cual consistía de un agente que
soportaba reconfiguración dinámica para módems caseros. Otro trabajo similar, es el
presentado por Kajko-Mattsson, Lewis y Smith (2007), donde elaboraron una
28
arquitectura basada en SOA generando roles para la administración de sistemas
basados en SOA.
Otro caso de éxito de la implementación de SOA esta presentado en un
sistema de aerolíneas, donde se redujo el costo de transacciones y de operación
respecto a otra forma de implementación basada en tecnología IBM (Electronic Data
System, 2008).
Como se puede apreciar, el uso de SOA puede ser de gran ayuda para dar
compatibilidad a aquellos sistemas antiguos que por una u otra razón es necesario
conectar con nuevos sistemas, un caso particular referente a SIABUC es que
mediante el uso de SOA se podrá interconectar los sistemas que previamente se
encuentren en una institución como por ejemplo un sistema de control escolar para
incorporar a los alumnos de nuevo ingreso a SIABUC, y esto será de manera
transparente al usuario.
29
3 Marco Teórico En éste apartado se mencionan las tecnologías que dieron inicio al desarrollo de los
Servicios Web, SOA, su estado actual y las definiciones de éstos términos, las cuales
son utilizadas en secciones posteriores.
3.1 Arquitecturas Iniciales
En un principio, los programas estaban creados solamente por instrucciones binarias,
razón por la cual, esta propuesta de programación demostró ser lenta y difícil para
las personas, ya que debían memorizar grandes cadenas de caracteres en formato
binario.
A finales de 1950 comenzó la investigación en el área de programación
automatizada de sistemas, este enfoque permitía a los programadores desarrollar
aplicaciones en una codificación de alto nivel que eran fácilmente interpretadas por la
computadora (Albin, 2003).
Durante la década de los 80’s también hubo un cambio en el diseño de
aplicaciones, cambiaron del simple texto a interfaces gráficas de usuario (GUI). Sin
embargo, fue hasta final de esa década y principios de los años 90’s cuando el
término arquitectura de software comenzó a mostrarse en la literatura.
Intentar definir un término como arquitectura de software es una tarea que en
algunas ocasiones causa polémica, debido a que existe una gran diversidad de
opiniones en torno a este término. Un ejemplo claro de esto, se puede encontrar en
la página de Instituto de la Ingeniería de Software, la cual contiene una diversidad de
definiciones al respecto (Software Engineering Institute, 2008).
El Institute of Electrical and Electronics Engineers (IEEE) por su parte, define
la arquitectura de software como la práctica recomendada para la organización de un
sistema, contiene componentes y sus relaciones con otros en el entorno, así como
los principios que gobiernan su diseño y evolución (Gorton, 2006). A continuación, en
los siguientes apartados se describen las arquitecturas iniciales en el ámbito
distribuido que marcaron la pauta para la generación de lo que en la actualidad se
conoce como servicios Web.
30
3.1.1 CORBA
Las tecnologías de objeto distribuido son un miembro importante de la familia de los
middleware. Los middleware proveen un medio de comunicación para conectar
varios componentes de software en una aplicación con la finalidad de intercambiar
información en ambientes heterogéneos (Gorton, 2006).
CORBA es el acrónimo de Common Object Request Broker Architecture, el
cual, es un estándar adoptado por la Object Management Group (OMG) para permitir
la interoperabilidad entre aplicaciones heterogéneas en entornos distribuidos
heterogéneos, sin importar el lugar donde se encuentren ubicados (Tari y Bukhres,
2001).
OMG es un grupo formado en el año de 1989 por varias compañías, dentro
de las cuales destacan: IBM, DEC, Hewlett-Packard, HyperDesk, entre otras. El
objetivo de este grupo es el de desarrollar un mecanismo para interactuar con
objetos distribuidos.
El objetivo principal de CORBA es el de automatizar varias tareas de
programación en red, esta automatización de funciones es hecha a través de un
intermediario llamado Object Request Broker (ORB). El ORB es ejecutado en el host
y maneja de forma transparente los mensajes de petición entre el cliente y el
servidor. La transparencia se refiere al hecho de que los clientes no necesitan
conocer donde se encuentran los servidores. Además de esto, el ORB provee
servicios comunes como el envío de mensajes y comunicación del tipo Remote
Procedure Call (RPC) entre el cliente y el servidor (Tari y Bukhres, 2001).
Figura 4. Arquitectura CORBA
En la figura 4 se muestra la arquitectura CORBA, un cliente que quiere
acceder a un objeto del servidor tiene que hacer primero un enlace a través de la
Interfaz CORBA
Cliente
IIOP
ORB
Interfaz CORBA
Servidor
IIOP
ORB
31
interfaz CORBA. Los clientes hacen una petición de enlace a un ORB local a través
de la interfaz CORBA. Si el objeto existe en la computadora local, el ORB activa
localmente el objeto que procesa la petición. En caso contrario, el ORB hace una
petición a otro ORB conectado en la red utilizando el protocolo Internet Inter ORB
Protocol (IIOP) sobre TCP. Después de enlazar el objeto apropiado, el ORB cliente
envía una petición al ORB que se encuentra en el servidor (Kim y Han 2006).
Un objeto CORBA esta conformado por dos componentes: la interfaz y la
implementación; la interfaz no está vinculada a un lenguaje de programación
específico, en lugar de eso utiliza el Interface Definition Language (IDL), con lo que
traduce las diferentes implementaciones de otros lenguajes. El IDL es el lenguaje a
través del cual todas las aplicaciones de CORBA son definidas.
CORBA en conjunto con el IDL fueron creados por la OMG en el año de 1991,
en las versiones iniciales, la OMG se enfocó en la especificación de la parte central
de CORBA, el ORB. Mientras que en la versión actual, la especificación 3.0,
agregaron nuevas dimensiones y tres categorías principales: integración de Internet,
calidad del control de servicio y arquitectura de los componentes de CORBA.
De manera formal, las especificaciones 2 y 3 de CORBA se refieren a la
especificación completa de CORBA. La especificación 2.0 se refiere a la
interoperabilidad de CORBA y el protocolo IIOP, mientras que la especificación 3.0
se refiere al modelo de componentes de CORBA (Object Management Group, 2008).
Otra alternativa para resolver el problema de integración en entornos
distribuidos es Microsoft Distributed Componente Object Model (DCOM). A
continuación se describe esta tecnología.
32
3.1.2 DCOM
Distributed Component Object Model por su acrónimo en inglés, es un middleware
desarrollado por Microsoft que provee una estructura basada en un modelo orientado
a objetos, básicamente es la versión extendida de Component Object Model (COM)
(Tari y Bukhres, 2001).
COM es un componente de software que promueve la reutilización
permitiendo que aplicaciones y sistemas sean construidos a partir de componentes
binarios.
DCOM nació a mediados de los años 80’s como Dynamic Data Exchange
(DDE), un protocolo de comunicación diseñado por Microsoft que permitía a las
aplicaciones intercambiar mensajes mediante la memoria compartida. Tiempo
después surgió Object Linking and Embedding (OLE), el cual, era un modelo de
objetos compuesto para enlazar objetos creados por diferentes aplicaciones. A
diferencia de otros middleware, DCOM es un middleware basado en la orientación a
objetos. Una aplicación DCOM comprende un conjunto de objetos que proveen los
servicios de aplicación vía métodos de esos objetos.
Debido a que Microsoft es el único propietario de esta tecnología, no es
ampliamente aceptable por la industria de los middleware (Tari y Bukhres, 2001).
En figura 5 se muestra la arquitectura DCOM, el cliente quiere acceder a los
objetos de un servidor a través de las interfaces COM, las cuales verifican los
permisos del cliente invocando el proveedor de seguridad. Si el cliente tiene los
permisos adecuados, el COM runtime invoca al Distributed Computing Environment
Remote Procedure Call (DCE RPC), el cual utiliza la pila de protocolos para
establecer la comunicación. Por su parte, la pila de protocolos del lado del servidor
recibe la petición, la entrega al COM runtime y posteriormente procesa la petición
(Kim y Han, 2006).
DCOM evita que el programador escriba código complejo, también se encarga
de todas las comunicaciones entre las máquinas.
33
Figura 5. Arquitectura DCOM
DCOM y CORBA están basados en el modelo de orientación a objetos, DCOM
esta orientado al desarrollo de aplicaciones de escritorio, mientras que CORBA, esta
orientado al desarrollo de aplicaciones empresariales.
La principal diferencia entre CORBA y DCOM es la forma mediante la cual los
objetos del servidor son registrados. Ambos proveen una estructura para crear y
utilizar componentes que pueden interactuar con otros, así como con otras
aplicaciones, librerías y redes de una manera bien definida. CORBA fue diseñado
para soportar componentes que pudieran existir en cualquier parte de la red,
mientras que COM solamente se puede ejecutar en un solo sistema. Otra diferencia
notable entre CORBA y DCOM es la capa de programación, mediante esta capa
ejecutan el manejo de excepciones (Tari y Bukhres, 2001).
Una desventaja de esta tecnología es que solamente es soportado por el
sistema operativo Windows de Microsoft y no puede ser utilizada en la mayoría de
los entornos Web (Kim y Han, 2006).
La aplicación central de las tecnologías remotas como RPC, CORBA, DCOM y
Enterprise Java Beans (EJB) propiciaron el surgimiento de un gran número de
soluciones basadas en middleware. Sin embargo, el surgimiento de estas soluciones
presento un problema, la heterogeneidad de aplicaciones, para hacer frente a esta
problemática surgió el XML, el cual se hizo presente a mitad de los años 90’s como
un formato independiente de los middleware para el intercambio de datos y
documentos entre diferentes aplicaciones. A diferencia de otros lenguajes como
CORBA IDL, Microsoft IDL o Java, XML no requiere de una tecnología o middleware
Interfaz COM Interfaz COM
Cliente
COM runtime
Proveedor de Seguridad
DCERPC
Pila de protocolos
Servidor
COM runtime
Proveedor de Seguridad
DCERPC
Pila de protocolos
34
específico, en la actualidad es utilizado como un formato de procesamiento de datos
multiplataforma. El XML es utilizado ampliamente en la creación de los servicios
Web, su principal función es la definición de las interfaces de los servicios de manera
similar como el IDL lo hace en CORBA. En siguiente apartado se describe con mayor
profundidad la tecnología relacionada a los servicios Web.
35
3.2 Servicios Web
El Internet esta establecido y para tomar la ventaja de la red global, el concepto de
computación distribuida necesita ser adaptado. Primero, el Internet esta básicamente
desconectado, las conexiones son transitorias y temporales. Los servicios de
computación distribuida como seguridad y transacciones, tradicionalmente dependen
de una conexión a nivel de transporte. Segundo, en Internet los grupos pueden
conectarse sin previo conocimiento del otro, siguiendo los enlaces Uniform Resource
Locator (URL) y observando algunas reglas básicas. Para los servicios Web esto
significa que cualquier cliente puede acceder a los servicios Web publicados por
cualquier otro, tanto tiempo como la información del servicio este disponible,
entendible y los procesadores XML sean capaces de generar mensajes (Newcomer,
2002).
Las tecnologías tradicionales de cómputo distribuidas asumen de una manera
más acoplada las relaciones entre un cliente y un servidor. Debido a que los servicios
Web adoptan el modelo de publicación en Internet, es posible encapsular y publicar
un punto final específico o una operación, usando la definición de interfaz del servicio
Web.
Newcomer (2002) menciona que al igual que el efecto de viajar por tren entre
ciudades, los servicios Web comunican unos programas con otros en puntos
distantes a través de la red, transportando grandes cantidades de datos de una
manera eficiente y a bajo costo. El resultado obtenido es: velocidad y mejor
comunicación.
El Internet comenzó soportando interacciones de manera textual y gráfica, al
inicio, las personas lo utilizaban para cotizar productos, comprar, leer las noticias,
entre otras cosas (Newcomer, 2002). Este nivel de interacción era bueno para
diferentes propósitos, pero, las aplicaciones basadas en texto no soportaban muy
bien la interacción de software, específicamente la transferencia de una gran
cantidad de datos. Era necesario pues, un método más eficiente para permitir a las
aplicaciones interactuar directamente con otras.
Los servicios Web mejoraron el uso de Internet facilitando la comunicación
programa a programa. A través de la adopción extendida de los servicios Web, las
36
aplicaciones en varios lugares podían ser integradas e interconectadas como si
fueran parte de una misma aplicación
Existen varios conceptos para definir a los servicios Web, el World Wide Web
Consortium (2004) los define como sistemas de software diseñados para el
intercambio de datos entre aplicaciones sobre la red utilizando protocolos basados
en XML.
Autores de publicaciones como Newcomer (2002) por su parte, definen los
servicios Web como aplicaciones que utilizan un documento creado en XML, el cual,
tiene la estructura de un mensaje, posteriormente un programa envía una petición a
un servicio Web a través de la red y puede o no recibir una respuesta, si se obtiene
una respuesta, esta también debe tener la estructura de un mensaje XML.
Mientras que Guruge (2004) los define como un nuevo tipo de programación
orientada a objetos en el Web. Son componentes de software modulares,
independientes y autodescriptibles que están disponibles en la red.
Como se pudo observar en las definiciones anteriores todas coinciden en la
utilización de mensajes para el intercambio de información entre los servicios Web,
estos mensajes tienen que estar definidos bajo un protocolo para que las
aplicaciones las puedan interpretar, el protocolo utilizado para tal fin es llamado
Simple Object Access Protocol (SOAP), el cual, es un protocolo estandarizado
derivado de XML y es el encargado de definir entre otras cosas los servicios y sus
interfaces.
A continuación, en la figura 6, se representa la comunicación que se lleva a
cabo en los servicios Web.
Figura 6. Representación de un servicio Web
La computadora A necesita comunicarse con otra computadora B, ambas con
plataformas y lenguajes de programación diferentes, la comunicación se puede llevar
Computadora A
Lenguaje: .NET S. O. Windows
Computadora B
Lenguaje: Java S. O. Linux
XML
XML
37
a cabo debido a que utilizan los servicios Web como medio de comunicación en
combinación con XML.
Esta tecnología puede ser utilizada de muchas maneras, se puede ejecutar en
un ambiente tipo escritorio, así como también en clientes portátiles para acceder, por
ejemplo, a un sistema de reservaciones por Internet, también pueden ser utilizados
para conectar aplicaciones que se ejecuten en varias organizaciones de una misma
cadena en un entorno empresarial, entre otras aplicaciones más. Una de las ventajas
que tiene esta tecnología es que puede resolver el problema de la integración de
aplicaciones empresariales (EAI – Enterprise Application Integration), conectando
múltiples aplicaciones de una organización simple a una múltiple, tanto dentro como
fuera de un firewall.
Los servicios Web proveen un mecanismo de modernización para aplicaciones
heredadas, particularmente aquellos desarrollos que se ejecutan en mainframes y
minicomputadoras (Newcomer, 2002).
Tal como se muestra en la figura 7, los servicios Web encapsulan los datos,
presentando a la red una forma de interfaz con los sistemas finales, como sistemas
de base de datos, .NET, Java, entre otras aplicaciones (trad. Newcomer, 2002, p. 8).
Figura 7. Interfaz de los Servicios Web con los sistemas finales
Las interfaces de los servicios Web reciben un mensaje en XML de la red,
posteriormente transforman los datos recibidos en un formato entendible por el
sistema y de forma opcional, regresan un mensaje de respuesta. Las
38
implementaciones de software pueden ser creadas utilizando cualquier middleware,
lenguaje de programación ó sistema operativo.
En la actualidad, la mayoría de los servicios utilizados en Internet son
invocados introduciendo datos sobre formularios y enviando los datos en una cadena
URL. Por ejemplo: si deseamos buscar “libros de programación” en la página de
Google, la cadena de búsqueda será similar a la que se muestra a continuación:
http://www.google.com/search?q=libros+programacion&btnG=Google+Search
XML provee varias ventajas para transmitir datos a través de Internet, como
por ejemplo, perfeccionamiento de los datos, mayor flexibilidad y extensibilidad. La
misma búsqueda utilizando un mensaje de servicio Web quedaría tal como se
muestra en la figura 8 (Newcomer, 2002), dicha figura muestra el mensaje
formateado utilizando el protocolo SOAP.
Figura 8. Mensaje SOAP en XML
En los mensajes SOAP, el nombre de la petición de servicio y los parámetros
de entrada toman la forma de elementos XML. El ejemplo también ilustra el uso de
los XML namespace (xmlns), otro elemento importante de los servicios Web.
El nivel de abstracción en el que los servicios Web trabajan, abarca los estilos
de emulación como RPC, mensajes asíncronos, mensajes en un solo sentido,
broadcast y publicación/suscripción. La mayoría de los sistemas de administración de
base de datos como Oracle, SQL Server y DB2 soportan el parseo y transformación
de servicios, permitiendo la interacción directa entre los servicios Web y los sistemas
de bases de datos.
<SOAP-ENV:Body> <s:SearchRequest xmlns:s=”www.xmlbus.com/SearchService”> <p1>programacion</p1> <p2>libros</p2> <p3>visual basic</p3> </s:SearchRequest> </SOAP-ENV:Body>
39
La tecnología utilizada por los servicios Web abarca dos tipos de aplicaciones
interactivas: RPC y orientada a documentos.
En las interacciones RPC se necesita tomar la forma de un método o una
llamada a un procedimiento asociado a los parámetros de entrada – salida. En
contraste con la interacción orientada a documento, la orientación RPC envía un
documento formateado específicamente para ser estructurado en un programa o
base de datos. La característica principal de esta tecnología es que una vez enviado
el mensaje de petición se espera un mensaje de respuesta.
Por otra parte, la interacción orientada a documento consiste en hacer una
solicitud para tomar la estructura de un documento XML que se pretende procesar de
manera completa. Durante la ejecución de un proceso, el documento completo debe
ser intercambiado.
Por consiguiente, Cerami (2002) afirma que un servicio Web, es cualquier
servicio que cumpla lo siguiente:
• Se encuentre disponible en Internet o en la intranet
• Utilice mensajes estandarizados en XML
• No este ligado a un sistema operativo o lenguaje de programación en
particular
• Se auto describa utilizando la gramática del XML
• Se pueda localizar fácilmente a través de un mecanismo simple
3.2.1 La tecnología de los servicios Web
Los programas que interactúan en Internet deben ser capaces de encontrarse
mutuamente, descubriendo alguna forma de interconectarse y negociar algunas
modalidades de servicio, como seguridad, confiabilidad, entre otras. Algunas de esas
modalidades de servicio son cubiertos por tecnologías existentes y estándares
propuestos, pero otros no. La infraestructura de los servicios Web están siendo
diseñados y desarrollados para ser extensibles como el HyperText Markup Language
(HTML) y el XML.
40
Los servicios Web son importantes porque son capaces de enlazar
tecnologías, no reemplazan una tecnología existente. Por ejemplo, se podría decir
que lenguajes como Visual Basic, C#, C/C++ y Java reemplazaron a lenguajes
antiguos como COBOL y FORTRAN, sin embargo, muchos programas elaborados en
esos lenguajes aún se encuentran en nuestro entorno (Newcomer, 2002).
Los programadores deben tomar en cuenta a los servicios Web cuando
diseñan y desarrollan nuevos programas y bases de datos, pero esos programas y
bases de datos serán requeridos detrás del encapsulamiento de los servicios Web.
Los servicios Web no son programas ejecutables, sino que se encuentran
dentro de programas de aplicación y scripts. Requieren de varias tecnologías
basadas en XML para transportar y transformar datos dentro y fuera de programas y
bases de datos, dichas tecnologías se mencionan en los siguientes apartados.
3.2.2 XML
El eXtensible Markup Language es una de las bases fundamentales de los servicios
Web, gracias a este lenguaje de etiquetado es posible realizar los servicios Web.
XML es un mecanismo para la descripción de datos, puede ser utilizado con
cualquier tipo de datos, independientemente del tipo que se trate (Guruge, 2004).
Todos los parámetros de entrada y salida de un servicio Web así como su
estructura se encuentran definidos en XML. Para que las aplicaciones entiendan los
datos en XML necesitan un guía o parser, esto es, un nivel de inteligencia mutua que
lo comparten tanto el proveedor como el consumidor (Guruge, 2004).
El etiquetado es un medio para agregar anotaciones descriptivas alrededor del
contenido de un documento, sin interferir con el contenido original. Esta es la
ideología entorno a los lenguajes de marcado, la mayoría de ellos ha evolucionado
del Standard Generalizad Markup Language (SGML) que fue desarrollado por IBM
en los años 80’s (Guruge, 2004).
41
HTML es el lenguaje de etiquetas electrónicas más conocido y utilizado, esta
compuesto por un conjunto de etiquetas previamente definidas y es considerado
como el primer lenguaje de etiquetas de marcado (Guruge, 2004).
A diferencia de HTML, el XML no es un lenguaje de etiquetas verdadero, esto
debido a que no cuenta con etiquetas definidas. XML es un lenguaje de meta-
marcado, el cual, permite crear etiquetas personalizadas para cubrir necesidades
específicas, esto comúnmente es conocido como: flexibilidad.
XML es en esencia un SGML fácil, ya que retiene bastantes funcionalidades
para hacerlo útil y poderoso, sin embargo, eliminó varias características redundantes
que hacen el SGML complejo y difícil de manejar.
XML puede ser transportado a través de la red utilizando estándares y
protocolos conocidos como File Transfer Protocol (FTP), HyperText Transfer
Protocol (HTTP), SOAP y Simple Mail Transfer Protocol (SMTP). Desde que existen
los estándares de texto de documentos, no hay limitaciones acerca de cómo puedan
ser transportados, instalados o vistos.
Como mencionan Weerawarana, et. al. (2005), XML provee un conjunto de
conceptos principales para definir nuevos lenguajes, los cuales se detallan a
continuación:
• Elementos Contiene un conjunto de atributos y algunos nodos hijos. Los nodos
hijos pueden ser otros elementos, texto, comentarios y otros tipos. Los
elementos son escritos utilizando los signos ‘<>’, ejemplo:
elemento inicial <libro> elemento final </libro>
• Atributos Son los nombres de los valores que están asociados a un elemento. Un
elemento puede tener cualquier número de atributos y se escribe de la
siguiente forma: <libro id=”1” isbn=”1234567890”>
• Comentarios
42
Los comentarios inician con la secuencia de caracteres ‘<!--’ y terminan
con ‘-->’, todo lo que encierra estas marcas es ignorado por el
procesador.
• Documento Un documento XML es una unidad que consiste exactamente de un
elemento (llamado elemento de documento) y puede contener
comentarios y otros elementos.
• Texto literal Los elementos pueden tener secuencias de caracteres basados en el
esquema de codificación UNICODE. Una característica clave de los
documentos hechos en XML es que todos los caracteres contenidos
son representados en UNICODE. Utilizando este esquema, XML puede
almacenar texto de cualquier lenguaje.
Usando estos conceptos, se pueden definir nuevos lenguajes, simplemente
nombrando cada uno de los elementos, validando su contenido y el tipo de texto que
esta permitido, como valores de los atributos y elementos de contenido.
XML es una familia de tecnologías: un lenguaje de marcado de datos, varios
modelos de contenido, un modelo de enlace, un namespace y varios mecanismos de
transformación. Las siguientes tecnologías son miembros importantes de la familia
XML utilizados en la creación de los servicios Web:
• XML v1.0
Son las reglas para definir los elementos, atributos, y etiquetas de cierre
de un elemento principal, provee un modelo de datos abstractos y
formato de serialización.
• XML schema
Son documentos XML que definen los tipos de datos, contenido,
estructura y permiten la asociación de elementos en el documento XML;
también es usado para describir instrucciones de procesamiento
semántica asociado con elementos del documento.
• XML namespaces
43
El calificador de nombres para los elementos del documento XML.
Se dice que un documento XML esta bien formado cuando hace uso de los
Document Type Definition (DTD), esquemas XML o algún otro lenguaje de definición
de estructuras. Los elementos que definen el formato del mensaje SOAP es un
ejemplo de esto (Weerawarana, et al., 2005).
Los DTD’s fueron inventados por SGML, cuando XML fue creado, los DTD se
convirtieron en un mecanismo de facto para definir la estructura de los documentos
XML. El lenguaje DTD permite definir los nombres de los elementos, número de
elementos y las veces que aparecerán. Sin embargo, con la llegada de los esquemas
XML el uso de DTD fue desapareciendo rápidamente.
Por su parte, los esquemas XML son documentos estructurados y creados
como especificación por el World Wide Web Consortium (W3C). Los esquemas XML
permiten especificar estructuras de una mejor manera que los DTD (Weerawarana,
et al., 2005). Dentro de sus bondades, destacan la definición de un conjunto de datos
primitivos que se pueden usar para definir atributos, elementos y valores recursivos
para definir estructuras complejas.
Una clara aplicación del XML son los servicios Web, ya que la información
utilizada debe ser convertida de su formato original a XML, por ejemplo, si se tiene
los datos generales de un libro: titulo, autor, editorial, isbn en la base de datos de
SIABUC, el registro correspondiente tendría la información que se muestra en la
tabla 1. Tabla1. Campos de un libro
Una vez que el programador realiza un análisis de la información
correspondiente, se obtendría el siguiente documento en formato XML:
<libro> <titulo>Automatizacion de Bibliotecas</titulo>
Nombre Tipo Titulo CadenaAutor Cadena
Editorial CadenaISBN Cadena
44
<autor>Hugo Ponce</> <editorial>Universidad de Colima</editorial> <isbn>0123456789</isbn> </libro> El programador ha creado un elemento llamado: libro, el cual es un documento
XML con la información contenida en la base de datos. Sin embargo, no se han
definido los tipos de datos en XML, es necesario un esquema.
Mediante el esquema se valida la información para que contenga los datos y la
estructura correctamente. El ejemplo del libro con el esquema apropiado sería el
siguiente:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="libro" type="TipoLibro"/> <xsd:complexType name="TipoLibro">
<xsd:sequence> <xsd:element name="titulo" type="xsd:string"/> <xsd:element name="autor" type="xsd:string"/> <xsd:element name="editorial" type="xsd:string"/> <xsd:element name="isbn" type="xsd:long"/>
<xsd:sequence> </xsd:complexType>
</xsd:schema> Los servicios Web también utilizan mecanismos para validar los documentos,
similares a los esquemas XML, dicho mecanismo es llamado Web Services
Description Lenguaje (WSDL), en el siguiente apartado se menciona con más detalle.
3.2.3 WSDL
Web Services Description Language fue creado en Septiembre del año 2000,
utilizando la combinación de dos lenguajes descriptores de servicio: Network
Application Services Specification Language (NASSL) de IBM y Services Description
Language (SDL) de Microsoft (Weerawarana, et al., 2005).
NASSL tiene una estructura similar al WSDL en términos abstractos que eran
ligados a protocolos cableados específicos, sin embargo, era difícil utilizarlo con el
estilo RPC. SDL por su parte era la estructura opuesta, un servicio que era ofrecido
45
sobre múltiples protocolos era descrito como un servicio completamente diferente,
sin una descripción común de servicio. SDL estaba mucho mas centrada en los
mensajes que NAASL.
El WSDL es un esquema XML que define una estructura para describir las
interfaces de los servicios Web. Los creadores del WSDL fueron Microsoft e IBM,
tiempo después tuvieron el apoyo de otras 25 compañías para someterlo al consorcio
W3C (Newcomer, 2002).
WSDL es el núcleo de la estructura de los servicios Web, provee un sentido
común en el que los tipos de datos son representados y pasados a mensajes, así
como las operaciones que son ejecutadas en los mensajes y el mapeo de mensaje
sobre la red. Inicialmente el documento WSDL estaba definido en tres elementos
principales: definición de tipos de datos, operaciones abstractas y enlace de
servicios.
Las partes incluyen la definición de tipos de datos, mensajes y operaciones
abstractas, que son similares a las definiciones de interfaces en CORBA o DCOM
(Newcomer, 2002). Los mensajes pueden tener múltiples partes y pueden ser
definidas para usarse con la orientación a procedimientos o la interacción orientada a
documento. A través de las capas de abstracción, los mismos mensajes pueden ser
definidos y usados por múltiples puertos. A continuación, en la figura 9 se muestra la
estructura del WSDL (trad. Newcomer, 2002, p. 23).
46
Figura 9. Estructura inicial del documento WSDL
El WSDL juega un rol importante que facilita muchas de las ventajas de los
servicios Web y la orientación a servicio. Según Weerawarana, et al., (2005) el
esquema WSDL es utilizado en los servicios Web en dos tipos de escenarios:
• Descripción de un servicio para sus clientes En este tipo de descripción, el documento WSDL describe un servicio
publicado para sus clientes. La descripción consiste en una declaración
de mensajes, operaciones de intercambio de mensajes y la ubicación,
en resumen, es el mecanismo para interactuar con el servicio. El
propósito principal del WSDL en este escenario es el de permitir a un
cliente usar el servicio satisfactoriamente.
• Descripción de un servicio estándar para implementar el servicio En este caso, el documento WSDL es un servicio estándar. Un ejemplo
de esto pueden ser las librerías, estas reciben y aceptan la compra de
un determinado libro. Un documento XML describe el formato del
mensaje, y la interacción envuelta con la compra del libro ha sido
47
convenida por la editorial. Entonces, una editorial específica puede
utilizar el WSDL y ofrecer el servicio, lo cual resulta en otro WSDL.
Un consumidor de servicio ó cliente utiliza el WSDL para ubicar el servicio
Web e invocar cualquiera de sus funciones públicas disponibles. Existen
herramientas que permiten la integración de servicios Web con poco código, por
ejemplo, la herramienta desarrollada por IBM: Web Services Invocation Framework
(WSIF), este proyecto actualmente es dirigido por Apache XML (Fremantle, 2002).
Utilizando esta aplicación se puede especificar el nombre del archivo WSDL y
automáticamente invocar el servicio descrito.
En la figura 10 se muestran los esquemas de las versiones de los esquemas
WSDL, la versión 2.0 fue liberada el 26 de Junio del año 2007, probablemente no se
hará una nueva versión en algunos años (Weerawarana, et al., 2005).
Figura 10. Versiones del WSDL
<types> … </types>
<message name=”…”> … </message>
<porType name=”…”> … </porType>
<binding name=”…”> … </binding>
<service name=”…”> … </service>
<definitions>
</definitions>
<types> … </types>
<binding name=”…”> … </binding>
<service name=”…”> interface=”…”> … </service>
<interface name=”…”> … </interface>
<description>
</description>
Versión 1.1 Versión 2.0
48
Actualmente el consorcio W3C ha desarrollado herramientas prototipo para
convertir los documentos WSDL de la versión 1.1 a la versión 2.0. Así como librerías
para leer, manipular y crear documentos WSDL en su versión 2.0 (World Wide Web
Consortium, 2007b).
3.2.4 SOAP
Hasta este punto se han definido los datos (XML) y se ha expresado la abstracción
del servicio necesario para soportar la comunicación y procesamiento del mensaje
(WSDL). Ahora, es importante definir la estructura del mensaje que será enviado
desde una computadora a otra.
SOAP son las siglas de Simple Object Access Protocol, este protocolo fue
desarrollado por Microsoft, Developmentor y Userland Software. Posteriormente,
empresas como IBM y Lotus contribuyeron en la revisión de la especificación que
resulto en la versión SOAP 1.1, misma que fue publicada en Abril del año 2000. Esta
especificación es ampliamente utilizada en la industria del software y forma las bases
de varios implementaciones interoperables (Weerawarana, et al., 2005).
Los creadores de SOAP 1.1 enviaron la especificación al consorcio W3C en
Mayo del 2000, donde fue analizada por el grupo de trabajo del protocolo XML, cuyo
objetivo era la estandarización de SOAP.
La especificación SOAP define la estructura para el intercambio de
información en XML a través de Internet y de esta manera provee el mecanismo de
comunicación para conectar los servicios Web. La estructura del mensaje es simple,
fácil de desarrollar y completamente neutral con respecto al sistema operativo,
lenguaje de programación o plataforma de cómputo distribuido (Newcomer, 2002).
Este protocolo se encuentra en constante desarrollo y el encargado de su
evolución es el consorcio W3C, actualmente se encuentra en su versión 1.2 (World
Wide Web Consortium, 2007a).
SOAP está fundamentado en el modelo de comunicación de un solo sentido,
que asegura el envío de un mensaje desde el transmisor al receptor, incluye
49
intermediarios que pueden procesar o agregar partes al mensaje. La especificación
SOAP contiene metodologías para adaptar los mensajes en un solo sentido para la
comunicación al estilo RPC y también define como se transmiten documentos
completos en XML.
SOAP es un conjunto de convenciones que especifican el formato de un
mensaje a través de un conjunto de reglas que gobiernan su procesamiento a lo
largo de su ruta. Estas convenciones describen como un mensaje es ensamblado y
que nodos los procesan (Weerawarana, et al., 2005).
Un mensaje SOAP es la unidad básica de comunicación entre nodos y esta
compuesto por 3 elementos principales: Envelope, Header y Body (Weerawarana, et
al., 2005). Cabe señalar que las etiquetas Envelope y Body son obligatorias dentro
del cuerpo del mensaje SOAP, en la figura 11 se muestra el esquema general de
este protocolo.
Figura 11. Estructura del protocolo SOAP
A continuación se describe las etiquetas principales de éste protocolo:
• Envelope
Define el inicio y el fin del mensaje, puede contener uno o más
elementos header.
• Header
……
SOAP Header
SOAP Envelope
Header Bloque 1
Header Bloque N
……
Body sub-elemento 1
Body sub-elemento N
SOAP Body
50
Contiene cualquier atributo opcional del mensaje usado en el
procesamiento del mismo.
• Body
Contiene los datos XML que abarca el mensaje cuando es enviado,
también conocida como información de negocio.
Como se muestra en la figura 12, SOAP esta diseñado para proveer un
protocolo de comunicación abstracto, independiente, capaz de conectar dos o más
sitios remotos (trad. Newcomer, 2002, p. 26). El sistema de comunicación puede ser
construido utilizando cualquier combinación de hardware y software que soporte el
acceso a Internet con sistemas existentes como .NET, Java, entre otros.
Figura 12. Mensajes SOAP interconectando sitios remotos
Un nodo es una implementación de reglas de procesamiento descritas en la
especificación SOAP que puede transmitir, recibir procesos ó retransmitir un mensaje
SOAP. Sin embargo, el nodo implementa el modelo de procesamiento SOAP,
también puede acceder a cualquier servicio que los protocolos de red subyacentes
deben proveer (Weerawarana, et al., 2005).
51
Los nodos pueden enviar y recibir mensajes SOAP, si un nodo transmite un
mensaje es llamado emisor, si recibe un mensaje es llamado receptor. Sin embargo,
algunos nodos deben hacer las dos funciones; recibir y transmitir mensajes, en este
caso son llamados intermediarios.
El emisor crea el mensaje, posteriormente el mensaje pasa a través de varios
intermediarios antes de llegar a su destino final, en este sentido, es común que un
mensaje SOAP pase a través de varios nodos, y a este conjunto de nodos se le
conoce como: ruta del mensaje, esta interacción se muestra en la figura 13.
Figura 13. Interacción de los nodos en la ruta SOAP
El modelo de procesamiento SOAP
Según Weerawarana, et al. (2005), la especificación del mensaje SOAP se encuentra
expresada como información en formato XML. Esto significa que el emisor debe
crear un mensaje XML que el receptor puede reconstruir. Todos los mensajes
creados se encuentran basados en el estándar XML 1.0. A continuación se muestra
un ejemplo de un mensaje SOAP básico.
<?xml version='1.0'?> <env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'> <env:Header> <p:BloqueUno xmlns:p='http://siabuc.ucol/b_uno'> <p:prioridad>alta</p:prioridad> <p:fecha>2009-08-01</p:fecha> </p:BloqueUno> </env:Header> <env:Body> <sb:libro xmlns:sb='http://siabuc.ucol.mx/lib'> <sb:titulo>Automatizacion de Bibliotecas</sb:titulo> <sb:autor>Hugo Ponce</sb:autor> <sb:editorial>Universidad de Colima</sb:editorial>
Receptor FinalEmisor Inicial
Intermediario Emisor Receptor
Ruta del mensaje SOAP
Intermediario
52
</sb:libro> </env:Body> </env:Envelope>
El elemento inicial Envelope contiene dos subelementos que son definidos en
SOAP: Header y Body. Sin embargo, el contenido de estos es específico de la
aplicación que crea y procesa el mensaje SOAP.
El elemento Header es opcional, su función dentro de SOAP es la de
transportar datos que no son parte de la información de negocio. También define las
condiciones de fallo que pudieran ocurrir. En el ejemplo anterior, el elemento Header
incluye un elemento hijo que contiene un conjunto de características de parámetros
de servicio. Dentro de la especificación SOAP, este elemento hijo es llamado header
block. Un elemento header puede contener varios header blocks, los cuales tienen su
propio namespace XML. La especificación XML permite que los header blocks
apunten a nodos SOAP específicos para procesar el mensaje a lo largo de su ruta.
El modelo de procesamiento SOAP se refiere a que se pueden utilizar
diferentes especificaciones de servicio, con sus propias definiciones header, con la
finalidad de ensamblar un mensaje que tenga características más complejas de
servicio, se tiene que definir una cabecera (header block) por cada servicio.
Por otra parte el elemento Body es obligatorio dentro del mensaje SOAP,
contiene la información del negocio del mensaje, es decir, la información que será
transmitida del emisor hacia el receptor. La elección acerca de que tipo de
información se coloca dentro del elemento Header y dentro de Body corresponde al
diseño del sistema.
Existen otra serie de atributos que son opcionales como Rol, mustUnderstand
y Relay. La finalidad del atributo Rol es la de identificar el rol desempeñado por el
header block, por su parte el elemento mustUnderstand se encarga de cerciorarse
que los nodos no ignoren los header block que son importantes para el propósito de
la aplicación, mientras que Relay es un atributo booleano que indica la retransmisión
de una cabecera cuando no es procesada.
53
Mensajes de error El protocolo SOAP provee un mecanismo para manejar los errores que se presentan
durante el procesamiento del mensaje. La información correspondiente al error es
etiquetada con env:Fault, el cual es un elemento hijo de env:Body.
El elemento env:Fault contiene a su vez dos elementos hijos: env:Code y
env:Reason. También podría contener tres elementos más de manera opcional:
env:Detail, env:Node y Env:Role.
El subelemento env:Code debe contener un elemento llamado env:Value, el
cual utiliza uno de los cinco códigos de fallo definidos en la especificación SOAP, los
cuales se mencionan a continuación:
• VersionMismatch El mensaje no es soportado por la versión SOAP.
• MustUnderstand El nodo destino no entiende la cabecera en el mensaje que contiene el atributo
“mustUnderstand”.
• DataEncodingUnknown El nodo destino no logró entender la codificación del mensaje.
• Sender El mensaje fue formado incorrectamente.
• Receiver El nodo receptor no pudo procesar el mensaje.
A continuación se muestra un ejemplo con el funcionamiento del elemento
fault utilizando la especificación SOAP:
<?xml version="1.0"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:flt="http://example.org/faults"> <env:Body> <env:Fault> <env:Code> <env:Value>env:Receiver</env:Value> <env:Subcode> <env:Value>flt:ValorErroneo</env:Value>
54
</env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="es">Error en la base de datos</env:Text> <env:Text xml:lang="us">Database Error</env:Text> </env:Reason> <env:Detail> <flt:MyDetails> <flt:Message>Base corrupta</flt:Message> <flt:ErrorCode>3197</flt:ErrorCode> </flt:MyDetails> </env:Detail> </env:Fault> </env:Body> </env:Envelope>
El propósito de env:Reason es proporcionar un mensaje que sea fácil de
interpretar por cualquier persona, el elemento env:Text contiene la descripción del
mensaje en lenguajes alternativos, por su parte el elemento env:Detail puede
contener información adicional acerca del error generado. Finalmente, env:Node y
env:Role contienen la URI del nodo que genero la falla, cabe señalar que estos dos
elementos son opcionales.
3.2.5 UDDI
Después que se han definido los datos en los mensajes (XML), descrito los servicios
que serán recibidos, la manera de procesar el mensaje (WSDL) e identificado la
forma de enviar y recibir los mensajes (SOAP), es necesario dar a conocer o publicar
el servicio que se ha hecho y encontrar los servicios que otros ofrecen y que se
quieren utilizar. Esta es la función que Universal Description, Discovery and
Integration (UDDI) provee (Newcomer, 2002).
La especificación UDDI define un método estándar para publicar y descubrir
los componentes de software de una arquitectura orientada a servicio basados en
red (OASIS, 2004a). Esta especificación actualmente está a cargo del consorcio
55
OASIS10, desarrolladores de software empresarial y clientes. El propósito principal de
UDDI es el de representar los datos y metadatos de los servicios Web.
Cuando UDDI fue desarrollado estaba enfocada en UDDI Business Registry
(UBR), el cual, era una implementación pública del estándar UDDI que representaba
un directorio de servicios de comercio electrónico. Este directorio era considerado de
manera análoga al nodo principal de la base de datos del Domain Name System
(DNS) (OASIS, 2004a). Los detalles de la evolución con las distintas versiones de
UDDI se muestran en la tabla 2. Tabla 2. Evolución de la especificación UDDI
Versión UDDI
Año de liberación
Objetivo
1.0 2000 Crear el principio para registrar los servicios de los negocios basados en Internet.
2.0 2001 Proveer servicios de taxonomía flexible. Adaptación con los servicios Web.
3.0 2004 Soportar interacción segura de implementaciones públicas y privadas como el mayor elemento de SOA.
La versión 3.0 representa un gran avance en la evolución de la especificación
UDDI, esta versión es estable y compatible con las versiones anteriores del
estándar. Un registro UDDI provee un registro compartido de índices donde los
clientes pueden buscar servicios con lo cuales desean interactuar (Weerawarana, et
al., 2005).
La información utilizada por UDDI es definida en varios esquemas XML. El
estándar XML fue seleccionado debido a que ofrece una plataforma neutral de datos
y permite relaciones jerárquicas para ser descritas de forma natural. Por su parte
XML Schema Definition (XSD) fue escogida porque soporta varios tipos de datos y
fácilmente describe y valida la información basada en esquemas.
El consorcio OASIS señala que UDDI en combinación con XSD definen la
información que los usuarios y aplicaciones necesitan conocer para utilizar un
servicio Web (OASIS, 2004a). Y a la vez, forman un modelo de base de información
y una estructura de interacción de los registros UDDI.
10 http://www.oasis-open.org/home/index.php
56
Una vez que un servicio Web es registrado, los programadores hacen
consultas a paginas Web que funcionan como repositorios UDDI, algunos ejemplos
de este tipo de página son http://www.soapclient.com/uddisearch.html y
http://www.xmethods.net/ve2/index.po, una vez encontrado el servicio de nuestro
interés bastara con lograr interpretar el WSDL correspondiente, para finalmente
establecer la comunicación mediante el envío y recepción de mensajes SOAP.
En la figura 14, se muestra la interacción que se lleva a cabo para registrar un
servicio Web en un repositorio UDDI, primero se genera el WSDL que contendrá la
descripción del servicio, posteriormente este WSDL es registrado mediante una API
en el repositorio UDDI, una vez registrado estará accesible a los programadores para
que puedan localizar el servicio, cuando un programador se interesa en un servicio
Web en particular, accede de nueva cuenta a su WSDL y posteriormente lo interpreta
mediante algún lenguaje de programación para comunicarse con el vía SOAP (trad.
Newcomer, 2002, p. 28).
Figura 14. Localización de un servicio Web mediante UDDI
Algunos autores comentan que UDDI es un concepto similar a la sección
amarilla, sin embargo, Guruge (2004) menciona que UDDI es mucho mas que eso,
57
UDDI es un directorio de páginas que contiene los proveedores de servicio por
nombre. Debido a esto, la información contenida en UDDI se encuentra dividida en
tres categorías: páginas blancas, páginas amarillas y páginas verdes, las cuales se
detallan a continuación:
• Páginas blancas Las páginas blancas contienen información descriptiva acerca de las
organizaciones que proveen varios servicios. El nombre de la organización y la
descripción textual del contenido, la cual puede estar en varios idiomas.
Información de contacto para que la entidad también sea incluida en términos
de nombres de contacto, números de teléfono, números de fax, correos
electrónicos y URL.
• Páginas amarillas Información que describe un servicio Web utilizando diferentes clasificaciones
(taxonomías). Permite categorizar las empresas y los servicios que ofrecen así
como también su ubicación geográfica.
• Páginas verdes Contienen la información técnica necesaria para utilizar el servicio disponible.
Programación en UDDI Hasta este momento se ha definido la estructura de UDDI, sin embargo, es necesario
mencionar el mecanismo mediante el cual se puede por ejemplo, localizar, crear,
editar o guardar algún servicio, este mecanismo es posible llevarlo a cabo mediante
un par de API’s.
Básicamente son dos las API’s que están definidas en la especificación UDDI:
inquiry API y publishing API, cada API contiene un conjunto de funciones que se
pueden invocar mediante programación, el objetivo de estas funciones es generar
mensajes en XML para guardar un servicio creado, editarlo.
Inquiry API se utiliza para localizar información que ofrecen los servicios y la
forma de actuar en caso de alguna falla, mientras que publishing API, se utiliza para
58
crear, almacenar o actualizar información concentrada en el registro UDDI (Chappell,
2002).
Inquiry API consiste en localizar información acerca de un servicio que se ha
ofrecido, la especificación de ese servicio y la información acerca de lo que debe
hacer en caso de fallo, cabe señalar que esta API no requiere un método de
autentificación y por lo tanto puede ser utilizada a través del protocolo HTTP.
Mientras que publishing API, se utiliza para crear, almacenar, o actualizar
información localizada en un registro UDDI, todas las funciones utilizadas en esta
API requieren autentificación de acceso, debido a ello se utiliza el protocolo
HyperText Transfer Protocol Secure (HTTPS).
Además de la publishing API, existen otras API’s de seguridad, transferencia,
y suscripción, las cuales son opcionales (OASIS, 2004b).
Las funciones relacionadas con la inquiry API pueden ser utilizadas para
recuperar información del registro UDDI. A continuación se mencionan cada una de
ellas:
• find_binding
• find_business
• find_relatedBusiness
• find_service
• find_tModel
• get_bindingDetail
• get_businessDetail
• get_operationalInfo
• get_serviceDetail
• get_tModelDetail
Mientras que las funciones correspondientes de la API para publicar (Publish
API) son las encargadas de dar a conocer y actualizar información contenida en el
registro UDDI. A continuación se listan cada una de ellas:
• add_publisherAssertions
• delete_binding
59
• delete_business
• delete_publisherAssertions
• delete_service
• delete_tModel
• get_assertionStatusReport
• get_publisherAssertions
• get_registeredInfo
• save_binding
• save_business
• save_service
• save_tModel
• set_publisherAssertions
Ahora que los estándares XML, SOAP, WSDL y UDDI son utilizados en conjunto
para hacer posible los servicios Web, hacen que tengan un impulso a la siguiente
tecnología orientada a objeto. En la figura 15 se muestra el modelo de interacción de
las tecnologías de los servicios Web (trad. Guruge, 2004).
Figura 15. Modelo operacional de los servicios Web
60
En la actualidad, existen herramientas que incorporan la funcionalidad de
UDDI sin hacer toda esta tarea manualmente, a continuación se mencionan algunas
de ellas (Online Community for the Universal Description, Discovery and Integration
OASIS Standard, 2008):
• jUDDI Es una implementación Open Source que utiliza el lenguaje Java
implementando UDDI. Actualmente este proyecto esta a cargo Apache
Group y esta basado en la especificación UDDI 2.0.
• Novell: Nsure UDDI Server Agrega administración de seguridad a la especificación UDDI,
incrementando la seguridad y administración de los servicios Web.
Soporta la versión UDDI 2.0.
• OpenUDDI Server Es una implementación Open Source basada en la especificación
UDDI 3.0. Esta herramienta se encuentra basada en la Novell UDDI
Server.
Hasta aquí se ha definido uno de los elementos esenciales para el desarrollo
de este trabajo; los servicios Web, estos proveen la interoperabilidad y pueden
fácilmente ser extendidos para utilizarse en arquitecturas empresariales, sin
embargo, adquieren más valor cuando utilizan implementaciones basadas en Service
Oriented Architecture (SOA) (Newcomer y Lomow, 2004). Esto debido a que la
mayoría de los analistas y proveedores de software recomiendan la utilización de los
servicios Web como la mejor forma de realizar una implementación SOA (Josuttis,
2007). Ahora, es necesario definir SOA, sus características principales y su
estructura, esto se aborda con detalle en el siguiente apartado.
61
3.3 Arquitectura Orientada a Servicio (SOA)
3.3.1 Concepto de SOA
En el año de 1994 Alexander Pasik, un analista de la empresa Gartner, acuño el
término Service Oriented Architecture para una clase que formaba parte de un
middleware. Pasik era desarrollador de software desde antes que el lenguaje XML o
los servicios Web fueran inventados (Josuttis, 2007).
Pasik estaba creando el término SOA porque la definición cliente-servidor
había perdido su significado clásico. Muchas industrias habían comenzado a utilizar
el término cliente-servidor para definir a una computadora en un entorno distribuido.
Una computadora cliente ejecutaba la presentación lógica de la interfaz de usuario y
la mayoría de la lógica del negocio, mientras que el servidor, almacenaba los datos
en un sistema administrador de base de datos y en ocasiones ejecutaba la lógica del
negocio. En este sentido, los términos cliente y servidor se referían principalmente al
hardware.
Para evitar confusión entre los antiguos y los nuevos términos cliente-servidor,
Pasik menciono que la orientación a servicio es muy útil para desarrollar aplicaciones
empresariales.
Anteriormente, las aplicaciones compartidas se encontraban enfocadas en la
resolución de problemas manuales como el pago de nómina, facturación,
contabilidad, entre otros. En la actualidad, la mayoría de estas operaciones han sido
automatizadas, sin embargo, ahora se encuentra la incógnita acerca de mejorar la
habilidad de esos sistemas para encontrar nuevos requerimientos (Newcomer y
Lomow, 2004). La forma de hacerlo es agregando nuevas interfaces de usuario,
combinando varias fuentes de datos, integrando dispositivos móviles ó reemplazando
la aplicación anterior por una nueva.
El paradigma del desarrollo orientado a servicio no es nuevo, fue tomado
como un cambio en las tecnologías de información para desarrollar nuevos sistemas
y obtener aportaciones de manera rápida.
SOA no reemplaza la tecnología orientada a objetos (OO), sino que viene a
ser un complemento de ésta. Sin embargo, cabe señalar que SOA se separa
62
considerablemente del modelo OO ya que SOA es orientada a servicios mientras que
OO es orientado a objetos, clases y métodos.
SOA se enfoca en el modelo basado en servicios y soporta tecnologías
interoperables, además se encarga de resolver problemas prácticos que surgen por
las diferentes plataformas y lenguajes de programación (Gorton, 2006).
Es difícil encontrar una definición exacta acerca del término SOA, esto debido
a que existen varias definiciones al respecto, sin embargo, la mayoría de ellas
coinciden en el sentido de que SOA es un modelo que permite el intercambio de
información de manera interoperable e independiente, en los siguientes párrafos se
mencionan algunas definiciones al respecto.
Newcomer y Lomow (2004), definen SOA como un estilo de diseño que guía
todos los aspectos de creación y usa servicios de negocio a través de su ciclo de
vida (desde la concepción hasta su retiro). También permite a diferentes aplicaciones
el intercambio de datos independientemente del sistema operativo o lenguaje de
programación que se utilice.
Erl (2005), por su parte define a SOA como un término que representa un
modelo en donde la automatización lógica es descompuesta en pequeñas unidades
lógicas. De manera colectiva, esas unidades lógicas abarcan una pieza de
automatización lógica del negocio. Sin embargo, esas unidades pueden ser
distribuidas.
Por su parte, el consorcio OASIS define SOA como la representación de una
colección de las mejores prácticas y principios relacionadas a los servicios, nivel
empresarial y cómputo distribuido (OASIS, 2008b).
Mientras que Josuttis (2007), define SOA como un paradigma para la
realización y conservación de los procesos de negocio que abarcan los sistemas
distribuidos. También menciona que esta arquitectura se encuentra basada en tres
conceptos: servicios, interoperabilidad a través del Enterprise Service Bus (ESB) e
independencia (loose coupling). A continuación se definen estos tres conceptos:
• Servicio Es una pieza independiente de la funcionalidad del negocio, donde la
funcionalidad, puede ser simple o compleja.
63
• Enterprise Service Bus (ESB) Es una infraestructura que permite una gran interoperabilidad para los
servicios entre sistemas distribuidos. Hace que sea fácil distribuir los
procesos de negocios sobre múltiples sistemas usando diferentes
plataformas y tecnologías.
• Loose coupling El objetivo de este concepto es el de reducir las dependencias del
sistema. Debido a que los procesos de negocio se encuentran
distribuidos sobre múltiples backends, es importante minimizar los
efectos de modificaciones y fallas.
La finalidad de SOA es tener tareas individuales, las cuales son ejecutadas
por componentes especializados llamados servicios. El objetivo de los servicios es
coordinar los procesos de negocio, cada servicio es diseñado para facilitar su
reutilización, si otro proceso requiere que la misma tarea sea ejecutada, ésta hace
uso del servicio existente (Brown, 2008).
Brown (2008) define un servicio como una unidad bien definida que ejecuta un
trabajo y que además se encuentra empaquetada para un acceso fácil. El objetivo es
implementar la funcionalidad exactamente una vez, de una manera correcta y
hacerlo ampliamente accesible. El esfuerzo extra en la creación inicial del servicio es
pagado para evitar costos en desarrollo futuro.
Margolis y Sharpe (2007) mencionan que los servicios son independientes de
otro software a fin de que los cambios de una petición requieran pocos o ningún
cambio en el servicio.
Cuando los servicios Web están disponibles a través de un entorno
empresarial, los proyectos de integración orientados a servicios pueden enfocarse en
componer servicios Web en lugar de tratar con la incompatibilidad de aplicaciones en
varias computadoras, lenguajes de programación o paquetes de aplicación. Por
ejemplo, si se utilizan lenguajes de programación como Java, C++, Visual Studio,
CORBA, WebSphere MQ, o cualquier otra plataforma de desarrollo o sistema de
64
software, como J2EE o .NET, SOA provee la arquitectura y los servicios Web
proveen la unión de manera unificada.
Comparando los estándares del pasado, los servicios Web son mucho más
fáciles de entender y de utilizar (Newcomer y Lomow, 2004). La amplia adopción de
estos estándares facilita el imaginarnos un entorno en el que las aplicaciones tengan
interfaces de servicio. Y partiendo de esta visión, es fácil imaginar a personas
involucradas en las tecnologías de información ejecutando en la mayoría de sus
actividades interfaces de servicio Web.
La aplicación más importante de SOA es la de conectar varios sistemas que
automaticen procesos de negocios empresariales (Newcomer y Lomow, 2004).
Ejemplos clásicos de estos son el sistema de inventario de Wal-Mart, sistema de
reservación de American Airline’s y el sistema de administración de abastecimiento
de la empresa Dell. Las compañías necesitan sistemas que sean flexibles para
implementar operaciones especializadas, para cambiar tan fácil como las
operaciones de negocio cambien y responder tanto interna como externamente a
dichas condiciones de cambio.
Dentro de las ventajas de la utilización de SOA Newcomer y Lomow (2004)
menciona las siguientes:
• Desarrollo eficiente SOA promueve la modularidad porque los servicios son independientes,
esta modularidad tiene implicaciones positivas para el desarrollo de
aplicaciones compuestas.
• Mayor reutilización Una de las promesas de SOA es que el servicio reutilizable disminuirá
costos de desarrollo y velocidad de tiempo en la comercialización.
• Mantenimiento simplificado Simplifica el mantenimiento y reduce los costos debido a que las
aplicaciones desarrolladas en SOA son aplicaciones modulares e
independientes.
65
• Creciente adopción Debido a que las aplicaciones son modulares e independientes pueden
ser desarrolladas y extendidas en pequeñas unidades.
• Evolución Un servicio y su contrato de servicio encapsulan la lógica del negocio,
de forma tal, que otros servicios no necesitan conocer nada acerca de
la forma en la cual se provee el servicio, solamente acerca de lo que el
servicio toma como entrada y lo regresa como respuesta.
SOA en combinación con los servicios Web facilitan el desarrollo de servicios
que encapsulan funciones de negocio y que son fácilmente accesibles desde
cualquier otro servicio. Además, servicios complejos permiten un amplio rango de
opciones para combinar servicios Web y crear nuevas aplicaciones funcionales. La
tecnología de los servicios Web puede ser usada para resolver varios problemas de
las tecnologías de información, especialmente cuando se asocian piezas de software
diferentes. Los servicios Web proveen la interoperabilidad y pueden fácilmente ser
extendidos para ser utilizados en arquitecturas empresariales por su bajo costo y por
su valor en las tecnologías de información, sin embargo, adquieren más valor cuando
utilizan implementaciones basadas en SOA (Newcomer y Lomow, 2004).
El momento real para SOA fue concebido por los servicios Web, que
inicialmente fueron creados por Microsoft. Pronto, otras compañías como Oracle, HP,
SAP y Sun aportaron su capital para agrandar la idea y vender nuevos conceptos y
herramientas. Tiempo después los analistas de software comenzaron a ofrecer SOA
como el concepto clave para el futuro del desarrollo de software. Un ejemplo claro de
esto fue la empresa de consultoría e investigación Gartner (http://www.gartner.com),
la cual, predijo que para el 2010 el software de aplicación tendrá un crecimiento del
80% en sus ganancias a través de productos basados en SOA (Josuttis, 2007).
Por su parte Newcomer, et. al., (2004) menciona que la mayor ventaja de
implementar SOA utilizando servicios Web es que éstos son simples y de plataforma
neutral. Además, los proveedores de software han adoptado extensamente el
paradigma de desarrollo orientado a servicios basado en servicios Web.
66
Desde el punto de vista técnico, un servicio es un activo que tiene interfaces
bien diseñadas, claramente separadas de los servicios externos. Cada servicio
consiste de una o más operaciones, esas operaciones deberán ser implementadas
usando una variedad de tecnologías, pero ningún detalle de esas tecnologías estará
visible al servicio que hace la petición, porque el WSDL es utilizado para la
descripción del servicio, de esta forma, cualquier servicio que realice una petición lo
puede leer. Un servicio es diferente de un objeto ó un procedimiento porque es
definido mediante mensajes, los cuales, son intercambiados con otros servicios.
3.3.2 Estructura de SOA Krafzig, et al. (2004) definen la estructura de SOA en cuatro abstracciones
principales: aplicación, servicio, repositorio de servicios y bus de servicios, dicha
estructura está representada en la figura 16 (trad. Krafzig, Banke y Slama, 2004).
Figura 16. Estructura de SOA
La aplicación es el dueño de los procesos de negocio y son los elementos
activos de SOA, ya que envían el valor de SOA a los usuarios finales, el servicio
provee la funcionalidad para que la aplicación y otros servicios la puedan utilizar.
Arquitectura Orientada a Servicios (SOA)
Aplicación Servicio Repositorio de Servicios
Bus de Servicio
Contrato Implementa -ción
Interfaz
Lógica del negocio
Datos
67
Un servicio consiste de una implementación que provee los datos y la lógica
del negocio, un contrato de servicio especifica la funcionalidad, uso y restricciones
para un cliente del servicio, mientras que una interfaz de servicio expone físicamente
la funcionalidad.
El repositorio de servicio almacena los contratos de servicio individualmente y
el bus de servicio interconecta la aplicación con el servicio.
A continuación se describe cada uno de los elementos que integran la
arquitectura SOA:
• Aplicación Son los elementos activos de SOA, inician y controlan toda
la actividad de los sistemas empresariales. Hay diferentes tipos de
aplicaciones; una aplicación con una interfaz gráfica de usuario, como
una aplicación Web o un cliente que interactúe directamente con los
usuarios finales. Sin embargo, la aplicación no necesariamente tiene
que interactuar con los usuarios finales, ya que también puede ser un
archivo de procesamiento por lotes que se ejecute periódicamente.
• Servicio Un servicio es un componente de software que típicamente
encapsula el concepto de negocio de alto nivel.
• Repositorio de Servicios Un repositorio de servicios provee la
facilidad para descubrir servicios y adquirir toda la información
necesaria para usar los servicios. Sin embargo, mucha de la
información requerida ya es parte del contrato de servicio.
• Bus de Servicio El bus de servicio conecta todos los elementos de los
servicios SOA y la aplicación.
• Contrato Provee una especificación del propósito, la funcionalidad,
restricciones y uso del servicio. La forma de esta especificación puede
variar dependiendo del tipo de servicio. Un elemento opcional del
contrato de servicio es la definición de una interfaz formal basada en
lenguajes como IDL o WSDL. Sin embargo, es importante señalar que
si ninguna descripción formal del servicio se encuentra disponible, cada
servicio requiere de un contrato de servicio respectivamente.
68
• Implementación La implementación del servicio físicamente provee los
requerimientos lógicos y los datos apropiados. Consiste en la
implementación de uno o más objetos como programas, datos de
configuración y bases de datos.
• Interfaz Expone la funcionalidad del servicio a los clientes que se
conectan a el a través de la red. Sin embargo, la descripción de la
interfaz es parte del contrato de servicio, la implementación física de la
interfaz consiste de servicios que son incorporados dentro de los
clientes.
• Lógica del negocio Es parte de la implementación del servicio, esta
hecha para ser disponible a través de las interfaces de servicio.
• Datos Son propiamente los datos del servicio
3.3.3 Aplicación
Este elemento de SOA inicia y controla toda la actividad de los sistemas
empresariales. Hay diferentes tipos de aplicaciones, una aplicación con una interfaz
gráfica de usuario, una aplicación Web que interactúa directamente con otros
usuarios es el ejemplo mas claro de este tipo de aplicaciones (Krafzig, et al., 2004).
Sin embargo, la aplicación no necesariamente tiene que interactuar
directamente con los usuarios, puede ser incluso un archivo de procesamiento por
lotes que se ejecute cada cierto tiempo.
Es posible que la aplicación asigne responsabilidades a los procesos de
negocio de uno o más servicios. Un aspecto importante es que la aplicación siempre
inicia un proceso y es la encargada de recibir los resultados.
Este apartado es similar a las capas superiores de las aplicaciones multicapas
tradicionales.
69
3.3.4 Servicio
Krafzig, et al., (2004) definen un servicio como un componente funcional que
típicamente encapsula un alto nivel del concepto de negocio. Este componente es
uno de los más importantes dentro de SOA, ya que uno de los objetivos principales
de este paradigma es la orientación a los servicios y debido a la importancia que
tiene, esta compuesto por cinco elementos: contrato, interfaz, implementación, lógica
del negocio y datos, tal como se mostró en la figura 16, en los siguientes párrafos se
describen cada uno de ellos.
• Contrato Provee una especificación del propósito, funcionalidad,
restricciones y utilización del servicio. La forma de esta especificación
puede variar dependiendo del tipo de servicio en cuestión.
Un elemento opcional del contrato es la definición formal basada en
lenguajes como IDL ó WSDL. Aunque la definición formal agrega ciertos
beneficios como: abstracción e independencia de la tecnología.
El contrato de servicio puede imponer detalles semánticos en la
funcionalidad que no son parte del IDL o de la especificación WSDL.
Es importante destacar que cada servicio requiere un contrato de
servicio, particularmente si ninguna descripción formal basada en una
especificación como WSDL ó IDL se encuentra disponible.
• Interfaz Es la funcionalidad del servicio, la cual, es expuesta a los clientes
y es conectada al servicio utilizando los protocolos de red existentes. La
descripción de la interfaz es parte del contrato de servicio, la
implementación física de la interfaz esta compuesta por un service stub,
los cuales son incorporados dentro de los clientes de un servicio.
• Implementación La implementación del servicio físicamente provee la
lógica del negocio y los datos apropiados. Es la parte técnica que cumple
en su totalidad con el contrato de servicio. La implementación del servicio
consiste de uno o más elementos como programas, datos de
configuración y bases de datos.
70
• Lógica del negocio La lógica del negocio es encapsulada por el servicio y
forma parte de su implementación, se encuentra disponible a través de la
interfaz del servicio.
• Datos Son los datos propiamente del servicio.
Figura 17. Elementos que conforman un servicio
Para concluir, un servicio esta compuesto por datos, la lógica del negocio, así
como también de las interfaces y las descripciones de cada una de ellas. En la figura
17 se puede observar los componentes del servicio y la forma en la cual interactúan
(trad. Krafzig, Banke y Slama, 2004).
3.3.5 Repositorio
Un repositorio de servicios facilita el descubrimiento de servicios y adquiere toda la
información para utilizar los servicios, particularmente si éstos tienen que ser
descubiertos fuera del ámbito del proyecto que los creo (Krafzig, et al., 2004).
Sin embargo, mucha de la información requerida ya forma parte del contrato
de servicio, el repositorio de servicio puede proveer información adicional, como la
ubicación física del servicio, información acerca del proveedor, tarifas de uso (si
aplica), restricciones técnicas, detalles de seguridad así como también los niveles de
servicio disponibles.
71
Los repositorios que son utilizados a través de la integración de servicios
empresariales típicamente tienen diferentes requerimientos particulares, esos
repositorios son publicados a través de Internet. Estos requerimientos pueden ser
asuntos legales (términos y condiciones de uso), estilo de presentación, seguridad,
registro de usuario, suscripción del servicio, facturación y versiones.
Un repositorio es un elemento muy utilizado en SOA, sin embargo, se puede
construir una arquitectura basada en la metodología SOA y obtener muchos de los
beneficios sin utilizar un repositorio de servicios, un repositorio de servicios es
indispensable a largo plazo. Una arquitectura puede funcionar sin un repositorio
siempre y cuando el ámbito del servicio se encuentre en un solo proyecto, si tiene
pocos servicios o si todos los proyectos se encuentran hechos por las mismas
personas.
Un ejemplo de repositorio puede ser un conjunto de contratos de servicios
impresos ubicados en una oficina que es accesible por todos los proyectos.
3.3.6 Bus de Servicio
Un bus de servicio conecta todos los participantes de los servicios SOA y la
aplicación frontend entre si (Krafzig, et al., 2004).
Por ejemplo, si dos participantes necesitan comunicarse ó si una aplicación
frontend necesita invocar alguna funcionalidad básica del servicio, el bus de servicio
hace que esto suceda. En este sentido, el bus de servicio es similar al concepto de
bus de software que es definido en el contexto de CORBA. Sin embargo, existen
algunas diferencias significativas entre ambos conceptos, la más importante es que
el bus de servicio no necesariamente esta compuesto por una sola tecnología, sino
que comprende una gran variedad de productos y conceptos.
El bus de servicio se caracteriza por los siguientes elementos:
• Conectividad El propósito principal de un bus de servicio es el de
interconectar los participantes de una arquitectura SOA. Provee las
72
facilidades que permiten a los participantes de una aplicación SOA
invocar las funcionalidades del servicio.
• Heterogeneidad de tecnología El bus de servicio debe contener una
gran variedad de tecnologías diferentes. La realidad de las empresas
es caracterizada por tecnologías heterogéneas. Consecuentemente el
bus de servicio debe permitir conectar a los participantes que se
encuentran basados en diferentes lenguajes de programación, sistemas
operativos o entornos de ejecución diferentes.
• Heterogeneidad de conceptos de comunicaciones De forma similar
a la heterogeneidad de tecnologías, el bus de servicio también debe
contener una variedad de conceptos diferentes de comunicación.
Debido a los requerimientos divergentes de diferentes aplicaciones, el
bus de servicio debe permitir diferentes modos de comunicación.
• Servicios técnicos El objetivo principal del bus de servicio es la
comunicación, sin embargo, también debe proveer servicios técnicos
como el registro de eventos en bitácoras, auditoria, seguridad y
transacciones.
73
3.4 SOA con Servicios Web
La mayoría de los analistas y proveedores de software recomiendan solo una forma
apropiada para realizar un entorno SOA: los servicios Web. Debido a que son
considerados como la mejor forma para realizar una implementación SOA. Además,
se han convertido en un estándar de facto para las infraestructuras que utilizan SOA
(Josuttis, 2007). Según Juric, Loganathan, Sarang y Jennings (2007) la combinación
de SOA con los servicios Web ofrecen ciertos beneficios, los cuales se mencionan a
continuación:
• Autosuficientes Los servicios Web son autosuficientes en el sentido
de que no requieren de componentes instalados en el cliente. En el
servidor solamente se necesita una plataforma de desarrollo para crear
el servicio Web. Cuando el servicio esta listo, un cliente puede consumir
el servicio sin necesidad de instalar software adicional en la
computadora.
• Autodescriptibles Una interfaz de un servicio Web es publicada a
través de un documento WSDL. El documento WSDL define el formato
para el intercambio de mensajes y los tipos de datos usados en los
mensajes. Para consumir un servicio, el cliente necesita conocer
solamente el formato y contenido de una petición y mensaje de
respuesta.
• Modulares Los servicios Web proveen una abstracción más allá que
las tecnologías basadas en componentes como Java, CORBA, DCOM.
Usando varias de esas tecnologías se pueden crear componentes. Los
servicios Web conforman esos componentes para ofrecer un servicio al
cliente. Sin embargo, la interfaz de los componentes no es expuesta al
cliente. Esto se traduce en el desarrollo de software modular para crear
vistas más abstractas de un servicio de negocio.
• Accesibles sobre la Web Los servicios Web son publicados,
localizados e invocados sobre el Web, la descripción del servicio es
publicada utilizando WSDL; el servicio es localizado con ayuda del
74
registro UDDI y es invocado utilizando SOAP, todos estos protocolos
son basados en Web.
• Neutrales en lenguajes de programación, protocolos y plataformas Los servicios Web son de plataforma neutral debido a que utilizan el
XML; el cliente y el servicio pueden ejecutarse en plataformas
diferentes.
• Basados en estándares La tecnología de los servicios Web se
encuentra basada en estándares abiertos haciendo que sean fácilmente
interoperables con otros servicios Web. Los estándares utilizados son
SOAP, WSDL y UDDI, los cuales son basados en XML.
• Dinámicos Los servicios Web pueden ser descubiertos y consumidos
en tiempo de ejecución, sin la necesidad de tener conocimiento de ellos
durante la compilación.
• Compuestos Los servicios Web pueden conformar un servicio grande
utilizando la orquestación.
Sin embargo, el hecho de utilizar los servicios Web no significa que
automáticamente se implemente el modelo SOA. Esto solamente es una forma de
indicarle a los sistemas como interactuar entre si, sin que todos los demás aspectos
de SOA sean provistos (Josuttis, 2007).
Para finalizar, con la combinación de SOA y los servicios Web surge una
respuesta moderna a la integración de aplicaciones. SOA provee la arquitectura y los
Servicios Web proveen la unión de manera unificada.
75
4. Arquitectura ABCSIS En esta sección se aborda a detalle los aspectos de creación de la arquitectura
ABCSIS, desde la parte teórica con el funcionamiento y definición de los servicios,
hasta la manera mediante la cual éstos fueron desarrollados con programación.
4.1 Modelo Conceptual
Como ya se ha mencionado en secciones anteriores, ABCSIS esta compuesta por un
conjunto de servicios, cuando un programador desea realizar un cliente para
consumir un servicio, primero debe consultar su contrato correspondiente a través
del WSDL, una vez que el programador ha verificado el contrato sabe como invocar
el servicio, así como los parámetros necesarios para su funcionamiento. Obtenida
toda la información necesaria para invocar el servicio, el programador procede a
realizar la solicitud del mismo mediante el desarrollo de una aplicación, la cual, será
la encargada de interactuar de manera directa con el servicio, este proceso es
mostrado en la figura 18.
La figura en cuestión está basada en la estructura de la arquitectura SOA
propuesta por Krafzig, et al., (2004), en dicha propuesta los elementos principales
son aplicación, servicio, repositorio y bus de servicio, estos elementos fueron
mostrados en la figura 16.
Figura 18. Ejemplo de funcionamiento de un servicio bajo ABCSIS
Bus de Servicio
Crea
Cumple
Invoca
Describe
Busca
Programador
Aplicación
Repositorio de Servicio
Contrato WSDL
Servicio
Web
76
La descripción funcional de los elementos que conforman la figura 18
incorporados a SIABUC mediante ABCSIS se describe a continuación:
• Aplicación Son las distintas aplicaciones que los programadores
(consumidores de servicio) de las diferentes instituciones podrán realizar. Hay
diferentes tipos de aplicación, por ejemplo, una aplicación con interfaz gráfica
de usuario como una página Web o un programa de escritorio, sin embargo,
una aplicación no necesariamente tiene que interactuar directamente con el
usuario, un ejemplo de esto son los archivos de procesamiento por lotes. En el
caso de ABCSIS, la aplicación consiste de un prototipo en entorno Web
basado en el lenguaje de programación PHP que consume el servicio Acervo.
• Servicio Un servicio es una función que tiene interfaces bien definidas y que
no depende del estado de otros servicios. La arquitectura ABCSIS se
encuentra conformada por tres servicios principales: Acervo, Alumnos y
Retroalimentación, dichos servicios serán explicados con mayor detalle en
esta sección. Cabe señalar que cada servicio a su vez cuenta con varios
procedimientos que se encuentran vinculados al servicio, dentro del entorno
SOA estos procedimientos son llamados operaciones de servicio.
• Repositorio de servicios Tal como menciona Krafzig, et al., (2004) un
repositorio es un elemento muy utilizado en SOA, sin embargo, se puede
construir una arquitectura basada en la metodología SOA y obtener muchos
de los beneficios sin utilizar un repositorio de servicios, ya que estos son
indispensables a largo plazo o cuando se cuenta con un enorme equipo de
desarrollo de software. Una arquitectura puede funcionar sin un repositorio
siempre y cuando el ámbito del servicio se encuentre en un solo proyecto, si
tiene pocos servicios o si todos los proyectos se encuentran hechos por las
mismas personas.
Un ejemplo de repositorio puede ser desde un conjunto de servicios
impresos, una base de datos donde se describan aspectos como la ubicación
física del servicio, información acerca del proveedor, restricciones técnicas,
entre otros. Para el caso de ABCSIS no existe un repositorio como tal,
77
solamente se incluyeron los WSDL correspondientes a cada uno de los
servicios.
• Bus de Servicio El bus de servicio ó Enterprise Service Bus es la forma
mediante la cual los clientes invocan un determinado servicio que un
proveedor ofrece. El principal objetivo del bus de servicio es proveer la
interoperabilidad y la compatibilidad con sistemas legados haciendo uso de los
servicios Web mediante el protocolo SOAP. El bus de servicio utilizado en
ABCSIS son los servicios Web basados en XML.
78
4.2 Diseño arquitectónico
Un sistema basado en SOA consiste de servicios, aplicaciones y una arquitectura
que conecta las aplicaciones con los servicios. En este sentido, la arquitectura SOA
provee un mecanismo de comunicación estándar entre las aplicaciones y los
servicios existentes, debido a ello, una aplicación puede invocar un servicio
conociendo únicamente su WSDL correspondiente. Cada servicio representa una
tarea de negocio y a su vez provee una interfaz, la cual es invocada mediante un
protocolo que es conocido por los clientes que desean consumir el servicio (Kajko-
Mattsson, et al., 2007).
Considerando lo anterior, ABCSIS está conformada por cuatro elementos
principales: consumidores de servicio, la arquitectura propiamente, interfaces de
servicio e implementación del servicio. Los consumidores de servicio son las
aplicaciones cliente que se desarrollarán, la arquitectura provee un mecanismo
estándar de comunicación entre las aplicaciones y los servicios existentes, por su
parte, las interfaces es el medio por el cual se conoce la ubicación del servicio y los
parámetros que se necesitan, finalmente, la implementación del servicio corresponde
al proveedor del servicio, en este caso SIABUC, todo este proceso es mostrado en la
figura 19, para su diseño se consideró la arquitectura propuesta en un documento
denominado Service Migration And Reuse Technique (SMART), que fue elaborado
por el Instituto de Ingenieros de Software de la Universidad de Carnegie Mellon de
los Estados Unidos (Lewis, Morris, Smith y Simanta, 2008).
Hay una serie de modelos y propuestas de organismos, empresas y diversos
autores acerca de la mejor manera de representar una arquitectura basada en SOA,
dentro de las propuestas más representativas en este sentido destacan las de
Oracle, Microsoft, OASIS y la Universidad de Carnegie Mellon.
El modelo elaborado por el consorcio OASIS es denominado Reference Model
for Service Oriented Architecture 1.0 (OASIS, 2008a), este modelo consta de un
documento muy abstracto y aún se encuentra como borrador, incluso las
características claves de SOA como el servicio, contrato, repositorio, implementación
que se incluyen en el modelo OASIS, también se encuentran en el documento
SMART.
79
Posteriormente se analizó el modelo propuesto por Krafzig, et al., (2004), este
modelo se encuentra plasmado en la figura 16, sin embargo, solo hace referencia a
un solo servicio de manera particular, en cambio en el modelo SMART hace
referencia a varios servicios incluyendo los usuarios y los sistemas legados.
Por su parte las empresas Microsoft y Oracle a diferencia de las propuestas
anteriores, proponen un modelo en el cual involucran sus herramientas tecnológicas,
el modelo de Microsoft está definido en tres divisiones: aplicación, servicio y
componente. La parte de aplicación se refiere cuando el cliente consume un servicio
de algún proveedor, lo correspondiente al servicio es la comunicación que existe
entre los proveedores y los consumidores, mientras que la parte de componentes
son los entornos soportados por las aplicaciones (Microsoft Corporation, 2004). En el
caso particular de Oracle, el modelo propuesto de SOA involucra la utilización de su
base de datos en combinación con el lenguaje de programación Java y está dividido
en tres capas: enlace, infraestructura y servicio (Wrigth y Reynolds, 2009).
Los modelos anteriores no difieren mucho y coinciden en la utilización de los
siguientes elementos dentro de un modelo SOA: usuarios, servicios, proveedores,
contrato, interfaces y aplicación, siendo esto uno de los principales factores por lo
que el diseño de ABCSIS se baso en el documento SMART, además de que
contiene una mejor estructura de los componentes SOA, facilita su comprensión,
incluye los elementos más importantes de los modelos mencionados anteriormente y
particularmente interesante que no contiene herramientas propietarias de empresas
o proveedores de software.
Con el diseño de ABCSIS, las personas interesadas en desarrollo de software
podrán crear componentes adicionales que se conecten a SIABUC, por ejemplo, una
aplicación Web ó una aplicación móvil que incorpore la reservación de ejemplares,
consulta de disponibilidad de ejemplares, verificación de adeudos, todo ello con la
finalidad de proporcionar más y mejores servicios bibliotecarios y acercarlos a los
usuarios finales de una determinada biblioteca o centro de información. Cabe señalar
que estas opciones se encuentran actualmente incorporadas en la versión completa
de SIABUC con interfaz tipo escritorio, sin embargo, el objetivo es encapsularlas
80
como servicios Web para generar componentes adicionales que funcionen de
manera interoperable.
4.2.1 Arquitectura ABCSIS
Una vez definido como la arquitectura ABCSIS está basada en SOA es necesario
detallar la manera con la que cada servicio es incorporado dentro de dicha
arquitectura. Para esto se diseño un modelo conceptual estructurado en cuatro capas
principales, las cuales son las siguientes, consumidores de servicio, arquitectura,
interfaces de servicio e implementación del servicio, a continuación, se describe cada
uno de estas capas y al final se muestra el modelo propuesto en la figura 19.
Consumidores del servicio Esta capa la componen todas y cada una de las aplicaciones externas a SIABUC que
se quieran conectar de manera transparente a través de los servicios
proporcionados.
Un ejemplo de ello es el siguiente: en el departamento de soporte técnico de
SIABUC ha sido una sugerencia muy frecuente al inicio de cada ciclo escolar,
incorporar de manera automática la información de los alumnos de nuevo ingreso
que serán potenciales usuarios de los servicios bibliotecarios, sin embargo,
actualmente lo hacen de forma manual o mediante la manipulación directa de la base
de datos de SIABUC, lo cual, sino se tiene el debido cuidado puede causar
problemas muy graves en el funcionamiento de SIABUC, como por ejemplo colocar
usuarios con permisos de préstamo que no son adecuados, modificación de los
campos llave de las tablas de la base de datos, alteración en los nombres de los
campos, por mencionar algunos de los problemas mas frecuentes. Con la
incorporación de un servicio utilizando la arquitectura ABCSIS que registre de
manera automática esta información el problema puede quedar solucionado,
mediante el desarrollo de un sistema que consuma el servicio de registro automático
81
de alumnos, lo que evita la manipulación directa de la base de datos de SIABUC y la
captura individual de cada usuario.
Otro ejemplo de aplicación puede ser la reservación de libros, al igual que el
ejemplo anterior en la arquitectura ABCSIS se elaboró un servicio para la consulta y
reservación, de tal manera que el usuario puede consultar el acervo de la biblioteca y
si le interesa algún ejemplar en particular lo puede reservar (apartar) y
posteriormente pasar a recogerlo a la biblioteca.
Arquitectura La arquitectura es la encargada de interconectar a los consumidores con los
servicios propiamente. Se caracteriza particularmente por la independencia entre
cada uno de los servicios y se basa en el intercambio de mensajes para el envío de
la información. Los elementos que la conforman son datos, bus de servicio, interfaz,
contrato, repositorio de servicio, los cuales, se encuentran basados en la estructura
de la arquitectura SOA propuesta por Krafzig, et al., (2004).
Interfaces de Servicio Las interfaces son la puerta de entrada de cada uno de los servicios y su objetivo es
recibir los parámetros que el servicio interpreta.
Esta capa consiste de una serie de servicios organizados y que utilizan la
estructura de los servicios Web, esto permite que sean definidos de forma
independiente de la plataforma tecnológica utilizada.
Para efectos de organización de la presente tesis, los servicios se han dividido
en tres grupos: acervo, alumnos y retroalimentación, los cuales se encuentran
detallados en la sección 4.2.5.
Implementación del servicio Es uno de los extremos en la comunicación de los servicios, ésta es la parte que
compete al proveedor, los proveedores son aquellas instancias que proporcionan los
medios adecuados para interconectar uno de los extremos entre la comunicación
existente proveedor – consumidor.
82
En este caso, el proveedor de servicio será la base de datos de SIABUC, ya
que será la encargada de proporcionar toda la información necesaria que el
consumidor necesita para la implementación de una determinada aplicación.
Figura 19. Modelo de la arquitectura ABCSIS
4.2.2 Entorno de Comunicación
Para utilizar una arquitectura basada en SOA es necesario un mecanismo de
comunicación entre los diferentes servicios proporcionados. Este medio de
comunicación en SOA es llamado Enterprise Service Bus (ESB).
Aplicación ASP
Servicio
1
Internet
Arquitectura SOA
Servicio
2
Servicio
3
Servicio
4
Aplicación PHP
Aplicación VB
Bus de Servicio
Repositorio de Servicios
Contrato
Interfaz Datos
SIABUC Sistemas Legados Sistema Externo
Consumidores de Servicio
Arquitectura
Interfaces de Servicio
Implementación del Servicio
Usuario
83
El objetivo del ESB es el proveer interoperabilidad, conectividad,
transformación de datos y direccionamiento de los sistemas que se comunican a
través de servicios, esto es, un mecanismo de petición-respuesta de un servicio
desde un consumidor hacia un proveedor. El ESB debe proveer habilidades que
negocien con la seguridad, fiabilidad y administración de servicios, sin embargo, se
debe considerar un estándar como los servicios Web para ser un ESB, porque de
manera conceptual definen todo lo necesario para proveer la interoperabilidad entre
sistemas (Josuttis, 2007).
Una de las ventajas de utilizar los servicios en SOA es que estos se
encuentran basados en servicios Web con el formato XML, los servicios Web utilizan
de manera predeterminada el HTTP sobre el protocolo TCP, lo cual se puede
aprovechar en aquellos sistemas que utilicen algún firewall sin necesidad de cambiar
la reglas de filtrado que existan en la administración interna de red. Esto debido a
que la mayoría de las organizaciones protegen sus redes mediante la utilización de
estos sistemas para impedir ataques e intrusiones no deseadas cerrando casi todos
los puertos de comunicación excepto el puerto 80, que es el que utilizan los
navegadores de Internet, este mismo puerto es el que utilizan los servicios Web y
debido a esto no resultan bloqueados ni tampoco se necesita hacer una
configuración adicional para habilitar la comunicación entre ellos.
4.2.3 Motor de datos y estructura de la base de datos
El motor de base de datos utilizado para el desarrollo de este trabajo es PostgreSQL
en su versión 8.2. PostgreSQL es un Sistema Manejador de Bases de Datos
(DataBase Management System - DBMS) cliente - servidor de código abierto que
incorpora el modelo relacional y soporta lenguajes de consulta estándar SQL.
Funciona en plataformas UNIX, Linux y Windows NT/2000/2003/XP/Vista, además,
puede ser usado con la mayoría de los lenguajes de programación incluyendo C,
C++, Perl, Python, Java, Tcl, PHP y Visual Basic (Matthew y Stones, 2005).
84
Dentro de las características más importantes de este robusto motor de base
de datos destacan su capacidad de almacenamiento, misma que se puede apreciar
en la tabla 3 (PostgreSQL Global Development Group, 2008a).
Tabla 3. Capacidad de almacenamiento de PostgreSQL
Límite Valor Tamaño máximo de la base de datos Sin límite Tamaño máximo de los índices por tabla Sin límite Cantidad de registros por tabla Sin límite Tamaño máximo de la tabla 32 TB Tamaño máximo de un registro 1.6 TB Tamaño máximo de un campo 1 GB Cantidad de columnas por tabla 250-1600
A continuación, se presenta un ejemplo de diagrama entidad-relación donde
se muestran las tablas necesarias para el apartado de reservación de un libro
registrado en SIABUC. Una reservación no se puede llevar a cabo sino existe el
número de adquisición del ejemplar (número que identifica cada material bibliográfico
dentro de la biblioteca) y el número de cuenta del alumno, una vez que la reservación
ha sido efectuada no se puede eliminar el usuario, puesto que tiene una reservación
a su cargo.
Solo se muestra el apartado correspondiente a la reservación debido a que el
prototipo implementado es relacionado a este tópico. Cabe señalar que el diseño del
modelo de datos queda fuera del alcance de la tesis puesto que el sistema SIABUC
ya existía y se tomó parte de su modelo de datos existente que tiene relación con los
servicios que se implementaron en ABCSIS.
Las relaciones que se muestran en la figura 20 corresponden a lo siguiente: un
ejemplar solo puede tener una reservación activa, por ejemplar se entiende cualquier
material registrado en SIABUC (libro, revista, tesis) existente en la biblioteca y cada
reservación es hecha por un alumno.
85
Figura 20. Diagrama entidad-relación para la reservación de un ejemplar
4.2.4 Comunicación con la base de datos
En algunas aplicaciones es necesario contar con ciertos parámetros de configuración
para hacer flexible el programa y que cada persona lo personalice acorde a sus
necesidades, en ocasiones estos parámetros son colocados dentro del código o en
archivos de configuración.
Para el desarrollo de ABCSIS se utilizó el lenguaje de programación Visual
Basic provisto en el Integrated Development Environment (IDE) de Visual Studio
2008, dentro del conjunto de archivos creados para cada servicio se encuentra un
archivo de configuración en formato XML denominado web.config, este archivo
contiene valores de control para el servicio, dentro de esos valores destaca el
apartado con el cual se realiza la conexión a la base de datos, dicho apartado se
muestra en la figura 21. De esta manera, cuando el programador desarrolle un
cliente para consumir el servicio podrá manipular los parámetros de conexión a la
base de datos, esto debido a que cada vez que se realiza una conexión al servidor
de PostgreSQL es necesario hacerlo mediante una autentificación de usuario.
86
Figura 21. Parámetros de conexión a la base de datos PostgreSQL
A continuación se describe cada uno de los elementos de esta cadena de conexión:
name:
Nombre de la conexión, este valor es constante y no se debe modificar, puesto que
es utilizado de manera interna por el servicio para hacer referencia al driver de
conexión de la base de datos.
connectrionString: Representa la cadena de conexión a utilizar para autentificarse con el servidor
PostgreSQL, esta cadena de conexión esta conformada por varios elementos, sin
embargo los más importantes son Server, Database, UserId y Password.
• Server Es utilizado para indicar el nombre o dirección IP del servidor que tiene
instalada la base de datos de PostgreSQL.
• Database Representa el nombre de la base de datos a conectar, en este caso es
siabuc9.
• UserId Representa el nombre de usuario para autentificarse ante el servidor de
PostgreSQL.
• Password Representa la clave para validar el inicio de sesión del usuario.
El servidor PostgreSQL cuenta con una librería específica para realizar la
conexión con .NET llamada Npgsql.dll, sin embargo, cuando esta librería fue liberada
<connectionStrings> <clear/> <add name="PostgreSQLProvider" connectionString="Server=localhost; Port=9000;Database=siabuc9;UserId=NombreUsuario; Password=ElPassword;Encoding=UNICODE;Sslmode=Prefer; Pooling=true;"/> </connectionStrings>
87
no era totalmente compatible con las plataformas derivadas de Microsoft, es por eso
que, en el año 2003 el equipo de desarrollo de Npgsql adoptó un proyecto
denominado mono, con el objetivo de ofrecer una mejor compatibilidad y estabilidad
de dicha librería en las plataformas de los sistemas operativos Windows
(PostgreSQL Global Development Group, 2009b).
Mono, es un proyecto de libre distribución auspiciado por Novell para
desarrollar proyectos Open Source en UNIX. El objetivo del proyecto mono es
permitir a programadores UNIX construir aplicaciones multiplataformas en .NET,
adicionalmente, implementa varias tecnologías de Microsoft que han sido enviadas al
European Computer Manufacturers Association (ECMA) para su estandarización
(Novell, 2009).
Para realizar la conexión a la base de datos fue necesario la utilización de dos
librerías: Npgsql.dll y Mono.Security.dll, ambas incluidas dentro del proyecto
denominado mono.
Una vez definida la base de datos, los parámetros de conexión y las librerías
necesarias para establecer la conexión, es necesario describir la forma en la que se
utilizaron esos elementos en el servicio.
Debido a que la librería de Npgsql es independiente de Visual Basic, es
necesario agregar su referencia correspondiente al código y para utilizar los
componentes de dicha librería es necesario usar la sentencia Imports al inicio del
código, tal como se muestra en la figura 22.
Figura 22. Conexión al servidor de PostgreSQL
Una ventaja adicional que se obtiene al realizar la conexión de esta manera es
que no se necesita realizar la cadena de conexión cada vez que se hace un servicio,
debido a que fue definida previamente en el archivo de configuración web.config
mostrado en la figura 21.
Imports Npgsql Using PgCon As NpgsqlConnection = New NpgsqlConnection( _ System.Configuration.ConfigurationManager.ConnectionStrings ("PostgreSQLProvider").ConnectionString) ' Líneas de código End Using
88
4.2.5 Descripción de módulos y componentes
Como ya se mencionó anteriormente, los servicios a desarrollar se encuentran
organizados en tres grupos: acervo, alumnos y retroalimentación, y cada servicio a
su vez contiene un conjunto de funcionalidades, las cuales son llamadas
operaciones, en la figura 23 se muestran los grupos de servicios de ABCSIS y a
continuación se describen cada uno de éstos con sus respectivas operaciones.
Figura 23. Servicios y operaciones de ABCSIS
Servicio Acervo Este servicio esta orientado a las acciones directas que se pueden realizar sobre
algún ejemplar (libro, cd, dvd, folleto, revista) y está conformado por las siguientes
operaciones: reservación de ejemplares, búsqueda de usuarios, búsqueda de fichas
y verificación de disponibilidad de un determinado material.
Servicio Acervo Servicio Alumnos
Servicio Retroalimentación
Res
erva
Eje
mpl
ar
Bus
car A
lum
no
Bus
car f
icha
B
iblio
gráf
ica
Dis
poni
bilid
ad d
e ej
empl
ares
Reg
istro
de
usu
ario
s
Ver
ifica
ción
de
adeu
dos
Ver
ifica
ción
de
mul
tas
Det
alle
pré
stam
os
pend
ient
es
Ren
ovac
ión
de
ejem
plar
es
Det
alle
s pr
ésta
mos
hi
stór
icos
List
ados
de
escu
elas
Reg
istro
de
inco
nfor
mid
ades
List
ado
de
inco
nfor
mid
ades
Res
pues
ta
inco
nfor
mid
ad
Sug
eren
cia
de
com
pras
Com
enta
rios
sobr
e tít
ulos
ABCSIS
89
• Operación para reservar un ejemplar Actualmente, cuando el usuario necesita reservar algún ejemplar lo hace vía
telefónica o acude físicamente a la biblioteca para hacer la reservación, con este
operación podrá hacerlo desde cualquier computadora que tenga implementado
el servicio. La operación recibe tres parámetros: el número de cuenta del usuario,
nip (clave de acceso) y el número de adquisición del libro, retorna un mensaje
indicando si la reservación tuvo éxito o en caso contrario un mensaje de error.
Figura 24. Operación para hacer reservaciones
• Operación para buscar un alumno Antes de hacer la reservación de un libro es necesario autentificar al usuario, este
es el objetivo de esta operación, básicamente consiste en validar el registro del
alumno en la base de datos de usuarios de SIABUC. La interfaz de esta
operación recibe el número de cuenta del usuario y retorna verdadero si esta
registrado en la base de SIABUC ó falso en caso contrario.
Figura 25. Operación para buscar un alumno en la base de datos
• Operación para buscar una ficha bibliográfica Realiza la búsqueda de una ficha dentro de la base bibliográfica de SIABUC y
obtiene su información general: título, autor, editorial, ISBN, temas. Esta
operación es una de las más importantes, puesto que con ella se obtiene la
información general del material bibliográfico de una biblioteca, su interfaz recibe
cinco parámetros, los cuales se listan a continuación:
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function Reservar(ByVal NoCta As String, ByVal NiP As String, ByVal NoAdq As String) As String
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function BuscaAlumno(ByVal NoCta As String) As Boolean
90
• TipoDeBusqueda. Este parámetro se utiliza para seleccionar uno de entre
cuatro tipos de búsquedas posibles 0-ISBN, 1-Título, 2-Autor, 3-
Clasificación, 4-No. de Adquisición.
• TerminoDeBusqueda. Es una cadena que indica el término a buscar dentro
de la base de datos.
• FichaNext. Este parámetro se utiliza para indicar el número de ficha
siguiente a visualizar, este parámetro se utiliza básicamente para control
interno y visualización de la información.
• FichaPrev. Es similar al anterior, e indica la ficha anterior a visualizar.
• NoPag. Representa el paginado de resultados.
La información que retorna esta operación se encuentra agrupada en un
arreglo, el cual esta conformado por los siguientes elementos: autor, clasificación,
estado del ejemplar (prestado, en mantenimiento), ISBN, número de adquisición y
título del material bibliográfico registrado en SIABUC.
Figura 26. Operación para buscar una ficha bibliográfica en la base de datos
• Operación para consultar la disponibilidad de ejemplares Informa acerca del estado actual de un ejemplar: prestado, reservado ó en
mantenimiento. La interfaz de esta operación de servicio recibe como parámetro
el número de adquisición de un libro y el valor que retorna al igual que la
operación anterior es un arreglo con la siguiente información: no. de adquisición,
identificador de biblioteca (valor numérico), no. de ejemplar, no. de volumen, no.
de tomo y el estado actual del ejemplar (prestado, disponible).
Figura 27. Operación para obtener la disponibilidad de un ejemplar
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function BuscarFicha(ByVal TipoDeBusqueda As Byte, ByVal TerminoDeBusqueda As String, ByVal FichaNext As Double, ByVal FichaPrev As Double, ByVal NoPag As Integer) As RegistroABCSISFicha()
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function Disponibilidad2(ByVal NoFicha As Long) As RegistroABCSISEjemplares()
91
Servicio Alumnos Este grupo está orientado a las actividades directamente relacionadas con los
usuarios finales del sistema, los alumnos. Las operaciones que integran este servicio
son las siguientes: registro de los datos del usuario en SIABUC, verificación de
adeudo, verificación de multa, detalle de préstamos pendientes por entregar,
renovación de ejemplares, detalle de préstamos históricos y listado de escuelas.
• Operación para actualizar/registrar los datos del usuario en SIABUC El objetivo principal de esta operación de servicio es la de incorporar a la base de
datos de SIABUC los alumnos de nuevo ingreso de una determinada institución,
ya que anteriormente este proceso se realizaba manualmente ó manipulando
directamente la base de datos de SIABUC, lo cual es riesgoso sino se tiene el
cuidado adecuado. La interfaz de esta operación de servicio recibe los siguientes
parámetros:
• NumCuenta. Este parámetro se utiliza para grabar el número de cuenta ó
número de matricula del alumno.
• Nombre. Representa el nombre del alumno.
• Escuela. Parámetro de tipo entero que identifica a la escuela que
pertenece el alumno, para obtener este valor es necesario utilizar la
operación “ListarEscuelas”.
• Correo. Correo electrónico del alumno.
• Domicilio. Parámetro de tipo cadena para grabar el domicilio del alumno
• Colonia. Se utiliza para almacenar la colonia a la que pertenece el alumno.
• Ciudad. Parámetro de tipo cadena para almacenar la ciudad del alumno.
• CodPos. Representa el código postal.
• Telefono. Parámetro de tipo cadena para almacenar el telefono del alumno.
• NumGrupo. Este parámetro es de tipo entero y se utiliza para asociar al
alumno a un conjunto de políticas de prestamo que previamente se tienen
definidas en el sistema SIABUC.
• VigenciaIni. Inicio de vigencia del alumno, por lo regular esta vigencia se
otorga al inicio del ciclo escolar.
92
• VigenciaFin. Fin de vigencia del alumno para el acceso a los servicios
bibliotecarios.
Figura 28. Operación para registrar un usuario en la base de datos
• Operación para verificar adeudos Cada fin de semestre en las distintas escuelas y facultades de la Universidad de
Colima se les solicita a los alumnos un comprobante, para obtenerlo, el alumno
debe acudir físicamente a la biblioteca a solicitarlo. En el comprobante se hace
constar que el alumno no tiene ningún tipo de adeudo en la biblioteca, el adeudo
se puede generar porque aún no han entregado algún libro, porque no ha saldado
alguna multa pendiente o simplemente porque esta bloqueado en el sistema
SIABUC por algún tipo de anomalía hecha en la biblioteca.
Con esta operación de servicio se evitará que el alumno acuda a la biblioteca
para obtenerlo, el servicio buscará dentro de una biblioteca en particular algún
tipo de adeudo y sólo si el usuario no adeuda nada le permitirá imprimir dicho
comprobante. La interfaz de este servicio recibe el número de cuenta del usuario
y retorna un valor numérico que corresponde al total de préstamos pendientes por
entregar sino adeuda nada entonces se le expedirá la constancia correspondiente
de no adeudo.
Figura 29. Operación para verificación de no adeudos
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function RegUsuario(ByVal NumCuenta As String, ByVal Nombre As String, ByVal Escuela As Integer, ByVal Correo As String, ByVal Domicilio As String, ByVal Colonia As String, ByVal Ciudad As String, ByVal CodPos As String, ByVal Telefono As String, ByVal NumGrupo As Integer, ByVal VigenciaIni As String, ByVal VigenciaFin As String) As String
<OperationContract()> _ Function VAdeudo(ByVal NoCta As String) As Integer
93
• Operación para verificar multas Cuando el alumno entrega de forma tardía algún ejemplar, el sistema SIABUC
genera automáticamente una multa, la cual consiste en cobrar cierta cantidad
monetaria dependiendo de los días de entrega tardía y de las políticas
administrativas de cada biblioteca.
En ocasiones, el usuario acude a la biblioteca y por alguna razón no trae la
cantidad que se le esta solicitando, entonces la multa es generada pero esta
pendiente por saldar, estas multas pendientes por saldar son las que la operación
del servicio obtendrá y le presentará al usuario así como el monto de cada una de
las multas.
La interfaz de esta operación recibe como parámetro el número de cuenta del
usuario y retorna una estructura de datos con todas las multas que tuviera en ese
instante. La estructura que retorna esta integrada por los siguientes elementos:
fecha en la que se realizó la multa, monto de la multa y razón por la cual se
originó la multa.
Figura 30. Operación para mostrar las multas pendientes por saldar
• Operación para obtener el detalle de préstamos pendientes por entregar Esta operación consiste en informar al usuario acerca de los ejemplares que tiene
pendientes por entregar a la biblioteca. De esta manera, puede verificar la fecha
de entrega y evitar una multa.
La interfaz de esta operación de servicio recibe el número de cuenta del
usuario y retorna una estructura de datos con los siguientes elementos:
clasificación del libro, fecha de entrega, fecha de préstamo, número de
adquisición del ejemplar, cantidad de renovaciones, tipo de préstamo (en sala, a
domicilio, interbibliotecario) y el título del ejemplar.
Figura 31. Operación para obtener los préstamos pendientes
<OperationContract()> _ Function VMulta(ByVal NoCta As String) As RegistroABCSISMulta()
<OperationContract()> _ Function PPendientes(ByVal NoCta As String) As RegistroABCSISpPendientes()
94
• Operación para renovar ejemplares En la actualidad este servicio se realiza de dos maneras: vía telefónica o el
usuario acude directamente a la biblioteca a realizar la renovación. Esta
operación consiste en dar una prorroga en el tiempo de entrega del ejemplar.
La interfaz de esta operación recibe como parámetro el número de cuenta del
usuario y el número de adquisición del ejemplar. Con la finalidad de que los
usuarios no abusen de este servicio se coloco un parámetro adicional llamado
RenovarUnaVez de tipo booleano, si el valor de este parámetro es verdadero
solamente se permitirá renovar en una sola ocasión a través de este medio, en
caso contrario, permitirá hacer todas las renovaciones que previamente se
definieron como políticas de préstamo en SIABUC, otra de las funcionalidades de
este parámetro es que el bibliotecario tenga mayor incidencia en la renovación, ya
que si observa que el libro en cuestión tiene demasiada demanda dar oportunidad
a otras personas de utilizarlo.
Figura 32. Operación para renovar ejemplares
• Operación para obtener los detalles de préstamos históricos Mediante esta operación los usuarios podrán obtener un concentrado con
información de los ejemplares que han solicitado en la biblioteca durante un
periodo de tiempo. Esta interfaz recibe tres parámetros: el número de cuenta del
usuario, la fecha inicial y fecha final que se desea consultar en el reporte. Retorna
una estructura de datos que contiene información general de los ejemplares que
el usuario solicitó.
Figura 33. Operación para obtener los préstamos de un usuario
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function Renovar(ByVal NoCta As String, ByVal ElNiP As String, ByVal NoAdq As String, ByVal RenovarUnaVez As Boolean) As String
<OperationContract()> _ Function PHistoricos(ByVal NoCta As String, ByVal FInicio As String, ByVal FFin As String) As RegistroABCSISpHistoricos()
95
• Operación para obtener listado de escuelas Esta operación básicamente se utiliza de manera interna con otras operaciones.
Recibe como parámetro un número mediante el cual se identifican a cada una de
las bibliotecas capturadas en SIABUC. Retorna una estructura de datos con el
identificador y el nombre de la escuela.
Figura 34. Operación para obtener listado de escuelas
Servicio Retroalimentación Debido a que la Dirección General de Servicios Bibliotecarios de la Universidad de
Colima ha implantado un sistema de gestión de la calidad, se incorporaron algunos
rasgos para ayudar en este sentido. Este servicio está conformado por las siguientes
operaciones: registro de inconformidades, concentrado de inconformidades,
respuesta a una inconformidad, sugerencia de compra de bibliografía y comentarios
o recomendaciones sobre títulos (valoración, comentario, fecha)
• Operación para el registro de inconformidades Con esta operación se le brindará la oportunidad al usuario de emitir su libre
opinión acerca de algún tipo de servicio que se le proporcionó en la biblioteca,
actualmente este proceso se hace de manera escrita.
La interfaz de esta operación recibe el número de cuenta del usuario, su
nombre, un identificador que corresponde a la escuela que se registro en SIABUC
y la queja correspondiente. Retorna un mensaje el cual indica si la queja fue
guardada con éxito.
Figura 35. Operación para registrar una inconformidad
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function ListarEscuelas(ByVal IdBiblio As Integer) As RegistroABCSISEscuela()
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function RpteQueja(ByVal NoCta As String, ByVal Nombre As String, ByVal IdEscuela As Integer, ByVal LaQueja As String) As String
96
• Operación para obtener un concentrado de inconformidades Una vez que los usuarios han externado alguna inconformidad es necesario saber
cuales son para su posterior seguimiento o contestación, esta operación muestra
un concentrado con todas las quejas que aun no se han dado respuesta.
Esta interfaz no recibe ningún parámetro, sin embargo, retorna una estructura
de datos con las quejas que aun no han sido respondidas para que se les de el
seguimiento adecuado.
Figura 36. Operación para listar las quejas pendientes por atender
• Operación para responder una inconformidad Una vez que la queja fue emitida, es necesario darle seguimiento, es decir,
regresar una respuesta con el estado de la misma, si la queja fue leída, atendida
ó se llevó a cabo la disposición solicitada, esta será la función a cubrir por parte
de esta operación.
La interfaz de esta operación recibe como parámetro un identificador de la
queja a responder, la respuesta a la queja y un valor booleano que indica si la
queja es aplicable al sistema de calidad. Esta operación esta enlazada
directamente con la anterior, ya que la operación ‘concentrado de
inconformidades’ retorna un identificador que es necesario en la interfaz de esta
operación.
Figura 37. Operación para responder una inconformidad
• Operación de sugerencia de compra bibliográfica En algunas ocasiones los usuarios necesitan libros que no se encuentran en la
biblioteca por alguna razón, mediante esta operación el usuario podrá sugerir
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function ListarQuejas() As RegistroABCSISQueja()
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function RptaQueja(ByVal IdQueja As Long, ByVal Respuesta As String, ByVal Aplica As Boolean) As String
97
acerca de las nuevas adquisiciones de libros. Esta interfaz recibe como
parámetros los datos generales del usuario, los datos generales del ejemplar que
esta sugiriendo y una razón en la cual el usuario explica el motivo de la compra.
Retorna un mensaje indicando si la sugerencia de compra fue guardada o no.
Figura 38. Operación para hacer sugerencias de compras bibliográficas
• Operación para emitir comentarios o recomendaciones sobre títulos Esta operación consiste en emitir una breve reseña acerca del contenido de algún
libro consultado por el usuario, es decir, si el usuario considera que el libro que
consultó tiene un buen ó mal contenido y la razón por la cual opina de esa
manera, dichas reseñas se encontrarán a la vista de cualquier otro usuario para
futuras referencias.
Esta interfaz recibe como parámetros los datos generales del usuario, los
datos generales del ejemplar, una calificación del 0 al 10 la cual representara la
calidad del contenido del libro y la razón por la cual el usuario otorgó esa
calificación.
Figura 39. Operación para emitir comentarios sobre títulos consultados
Hasta aquí se abordaron los aspectos de diseño de ABCSIS, así como los
servicios que integran ésta arquitectura, sin embargo, solo se menciono lo
relacionado a los parámetros que reciben, ahora, es necesario entrar en detalle
acerca de la manera con la que fueron elaborados haciendo uso del modelo de
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function SugCompra(ByVal NoCta As String, ByVal Usuario As String, ByVal IdEscuela As Integer, ByVal ElTitulo As String, ByVal ElAutor As String, ByVal LaEditorial As String, ByVal ElISBN As String, ByVal LaSugerencia As String) As String
<OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function RecTitulos(ByVal NoCta As String, ByVal Usuario As String, ByVal IdEscuela As Integer, ByVal NumAdqui As String, ByVal ElTitulo As String, ByVal ElAutor As String, ByVal LaClasificacion As String, ByVal LaRecomendacion As String, ByVal Calificacion As Integer) As String
98
programación Windows Communication Foundation, estos detalles son explicados a
detalle en la siguiente sección.
99
5. Desarrollo de ABCSIS
Esta sección tiene como finalidad dar a conocer el procedimiento con el que se
crearon los servicios que forman parte de la arquitectura ABCSIS. Se encuentra
organizado por tres apartados, creación del servicio, hosting del servicio e
implementación del prototipo.
En el primer apartado, se aborda la manera mediante la cual se crearon los
servicios en el lenguaje de programación Visual Basic 2008 en combinación con la
tecnología Windows Communication Foundation (WCF), se utilizó este lenguaje de
programación debido a la familiaridad y conocimiento previo que ya se tenia con el
mismo, en el segundo apartado, se detalla la manera con la que se hospedó el
servicio en el servidor Web Internet Information Server, mientras que en el tercer
apartado, se describe lo relacionado a la creación del consumidor, en este caso, un
prototipo desarrollado en lenguaje de programación PHP.
Antes de dar a conocer la forma mediante la cual se crearon los servicios, es
necesario mencionar la tecnología con la cual fueron creados, debido a esto es
indispensable hablar acerca de WCF el cual forma parte del .NET Framework.
WCF conocido en sus inicios como Indigo, es un conjunto de tecnologías
orientado a servicios basado en el .NET Framework 3.0 cuyo objetivo principal es el
de simplificar el desarrollo de aplicaciones distribuidas seguras, confiables e
interoperables (Peiris y Mulder, 2007). Algunas de las ventajas que se obtienen al
utilizar este modelo de programación son las siguientes:
• Amplio soporte para los protocolos de los servicios Web (WS-I)
• Uso implícito de los principios de desarrollo orientado a servicios
• Una única API para el desarrollo de sistemas
WCF maneja la infraestructura de comunicación del sistema operativo
Windows Vista y ha sido extendido a Windows XP y Windows 2003 a través del .NET
Framework 3.0.
Según Microsoft Corporation (2009b), el .NET Framework (conocido
anteriormente como WinFX) es el modelo de programación de código administrado
100
de Microsoft para la creación de clientes de Windows, servidores y dispositivos
móviles incrustados.
WCF provee la infraestructura de comunicación que permite crear diversas
aplicaciones a través de un modelo simplificado basado en servicios. Microsoft dio a
conocer esta tecnología en su evento denominado Microsoft Product Developers
Conference en los Ángeles California en el año de 2003, desde entonces, esta
tecnología ha venido evolucionando y en la actualidad se encuentra disponible en el
Framework 3.5 (Peiris y Mulder, 2007).
Los objetivos principales de WCF se basan principalmente en tres aspectos:
• Unificación de tecnologías existentes
• Interoperabilidad a través de plataformas
• Desarrollo orientado a servicios
Figura 40. Interoperabilidad entre varios sistemas operativos
La interoperabilidad ha sido uno de los mas grandes problemas por resolver
para los proveedores de software, es por eso que empresas líderes en este ámbito
como Microsoft, IBM, BEA y Sun formaron la organización Web Service
Interoperability (WS-I), la cual consiste en un conjunto de especificaciones que
Servicio WCF
Mensaje SOAP
Mensaje SOAP
Sistemas Legados
Linux Windows Solaris
101
permite a las aplicaciones comunicarse con otras en diferentes plataformas, en este
sentido WCF soporta todo el conjunto de protocolos WS-I.
El método de comunicación en WCF se encuentra basado en mensajes y el
protocolo de mensajes nativo para tal fin es SOAP, el cual, como ya se comentó en
la sección tres, es un estándar que permite la comunicación con diferentes
tecnologías y plataformas de manera interoperable. En la figura 40 se puede apreciar
la interoperabilidad que se hace mediante SOAP, de esta manera haciendo uso de
WCF diversos sistemas heterogéneos pueden coexistir.
Para utilizar todo el conjunto de WCF es necesario cubrir algunos
requerimientos de software, los cuales se detallan a continuación: .NET Framework
3.0 o superior, sistema operativo Windows (XP sp2 o superior, 2003, 2008 ó Vista) y
el lenguaje de programación Visual Basic 2005 o superior.
Cabe señalar que para el desarrollo de los servicios se utilizaron las siguientes
herramientas de software:
• Visual Basic 2008
• .NET Framework 3.5
• Windows XP Professional Service Pack 3
• Servidor Web Internet Information Server (IIS) 5.1
Una vez mencionada la tecnología WCF también es necesario dar a conocer
los elementos necesarios para consumir un servicio, debido a que en los apartados
siguientes se mencionaran.
En la figura 41 se muestran estos elementos, dentro de los cuales, el elemento
primordial es el endpoint, adicionalmente existen elementos complementarios como
Behavior, Factory, Channel y Listener. Behavior se utiliza para hacer conversión de
mensajes para que el .NET los pueda interpretar, Factory permite la comunicación a
través de un canal de comunicación específico, Channel representa la forma
mediante la cual los protocolos son implementados y son los responsables de
transmitir un mensaje desde el cliente hasta el servicio y viceversa, finalmente
Listener es el encargado de aceptar los mensajes provenientes de los canales (Peiris
y Mulder, 2007, p. 54).
102
El endpoint es importante porque representa la puerta de entrada al servicio,
cada servicio puede tener varios endpoint, los cuales siempre se encuentran a la
espera de mensajes para el intercambio de información. Cada endpoint a su vez esta
compuesto por tres elementos: Address, Binding y Contract; los cuales son
conocidos con el prefijo “ABC”.
Figura 41. Modelo de programación de WCF
El address se utiliza para ubicar o conocer la dirección del servicio, y permite
la comunicación mediante el intercambio de mensajes. El address en WCF son
direcciones que definen el protocolo de comunicación utilizado, la computadora
donde esta ejecutándose el servicio y la ruta del mismo. En la tabla 4 se muestran
las especificaciones para el elemento address. Tabla 4. Especificaciones de Address
Sección Address Descripción Transporte Define el protocolo o medio de transporte PC Especifica el nombre de dominio completo de la
maquina Puerto Es un apartado opcional y es especificado como
:numero_puerto Ruta Es la ruta específica del servicio. Se puede definir
nombres de rutas como directorios separados por una diagonal. Ejemplo: /Biblio/ReservaLibro es la ruta de la siguiente dirección: http://localhost/Biblio/ReservaLibro
103
De esta manera, el formato de una dirección de servicio queda estructurado
de la siguiente forma:
transporte://<pc>[:numero_puerto]/ruta1/ruta2
La dirección anterior es similar al URL de una página Web, el transporte puede
ser cualquier transporte soportado como HTTP, TCP, Microsoft Meesage Queuing
(MSMQ) ó Named Pipes, pc es el nombre del servidor donde esta hospedado el
servicio, numero_puerto es el puerto donde el servicio esta a la escucha de
peticiones y finalmente ruta se utiliza principalmente para diferenciar los servicios
hospedados en la misma máquina. Cabe señalar que los servicios correspondientes
a ABCSIS fueron hospedados utilizando el servidor IIS de Windows XP Professional,
de tal manera que el address de cada servicio quedo de la siguiente manera:
http://dominio/grupo_servicio/servicio.svc
Donde:
dominio representa la ruta de acceso a la computadora a través de la red
grupo_servicio representa un directorio virtual dentro del servidor IIS
servicio.svc es el archivo que contiene información del servicio
El binding por su parte describe la forma en la que se establecerá la
comunicación entre el cliente y el servicio. WCF provee un conjunto de bindings que
se adaptan a las necesidades de cada aplicación, los cuales se muestran en la tabla
5 (Microsoft Corporation, 2009a). Sin embargo, si alguno de estos bindings no
satisface nuestras necesidades, se puede crear uno personalizado identificándolo
con el atributo CustomBinding.
Los binding mostrados en la tabla 5 que comienzan con el prefijo Net son
exclusivos de la plataforma Windows, estos binding son utilizados en aquellas
aplicaciones donde la interoperabilidad no es requerimiento importante. Algunos
autores como Kim y Han (2006), y personas dedicadas al desarrollo de software
mencionan que los servicios Web no son del todo eficientes debido al tiempo de
procesamiento causado por la utilización de XML, sin embargo, este problema ha
quedado resuelto con la utilización de estos bindings, cuya función es la de enviar y
recibir información en forma binaria, con esto, se aumenta considerablemente el
104
desempeño de los servicios Web, la desventaja de utilizar este tipo de binding es que
son propietarios de la plataforma Windows.
Tabla 5. Bindings y sus características principales
Finalmente, el contract es un acuerdo entre dos o más partes que especifican
los mensajes que serán intercambiados, así como los términos y las condiciones de
esos mensajes.
Un contract es una declaración que expone el comportamiento (contrato de
servicio), datos persistentes (contrato de datos) o la estructura del mensaje (contrato
de mensaje) (Peiris y Mulder, 2007).
Enlace Interoperabilidad Modo de Seguridad (valor predeterminado)
Sesión (Predeterminado)
Transacciones Dúplex
BasicHttpBinding Basic Profile 1.1 (Ninguno), transporte, mensaje, mixto
Ninguno, (ninguno)
(Ninguno) n/a
WSHttpBinding WS Ninguno, transporte, (mensaje), mixto
(Ninguno), transporte, sesión confiable
(Ninguno), Sí
n/a
WS2007Http Binding
WS-Security, WS-Trust, WS-SecureConversation, WS-SecurityPolicy
Ninguno, transporte, (mensaje), mixto
(Ninguno), transporte, sesión confiable
(Ninguno), Sí
n/a
WSDualHttp Binding
WS Ninguno, (mensaje)
(Sesión confiable) (Ninguno), Sí
Sí
WSFederationHttp Binding
WS-Federation Ninguno, (mensaje), mixto
(Ninguno), sesión confiable
(Ninguno), Sí
No
WS2007Federation HttpBinding
WS-Federation Ninguno, (mensaje), mixto
(Ninguno), sesión confiable
(Ninguno), Sí
No
NetTcpBinding .NET Ninguno, (transporte), mensaje
Sesión confiable, (transporte)
(Ninguno), Sí
Sí
NetNamedPipe Binding
.NET Ninguno, (Transporte)
Ninguno, (transporte)
(Ninguno), Sí
Sí
NetMsmqBinding .NET Ninguno, mensaje, (transporte), ambos
(Ninguno) (Ninguno), Sí
No
NetPeerTcpBinding Del mismo nivel Ninguno, mensaje, (transporte), mixto
(Ninguno) (Ninguno) Sí
MsmqIntegration Binding
MSMQ Ninguno, (transporte)
(Ninguno) (Ninguno), Sí
n/a
105
El contrato de servicio es el más utilizado y es el encargado de exponer los
métodos del servicio, también es conocido con el nombre de interfaz de servicio ó
comportamiento expuesto del servicio. Este tipo de contrato en .NET es representado
mediante clases con el atributo <ServiceContract()>, esta y otras clases están
contenidas dentro de un namespace llamado System.ServiceModel, el cual, es
necesario invocar en Visual Basic para utilizar las funcionalidades de WCF. Un
namespace se utiliza como un sistema de organización y permiten clasificar y
presentar elementos de programación que se exponen a otros programas y
aplicaciones (Microsoft Corporation, 2009c).
Una vez abordada la tecnología WCF es conveniente describir la manera
mediante la cual se desarrollaron los servicios de ABCSIS, lo cual, se describe en el
siguiente apartado.
106
5.1 Creación del servicio
Para crear un servicio haciendo uso de WCF se debe tomar en cuenta los siguientes
elementos: método, contrato de servicio, operación de servicio, contrato de datos,
manejo de errores, la ubicación donde el servicio estará hospedado, el binding y un
archivo de configuración del servicio.
El método son todas aquellas funcionalidades que deseamos estén
disponibles en el servicio para que los consumidores las utilicen, cada servicio puede
estar compuesto por uno ó varios métodos.
El contrato de servicio es el encargado de exponer los métodos que integran
el servicio para que un cliente los pueda consumir, sin embargo, para poder exponer
estos métodos es necesario indicarlo mediante el atributo operación de servicio.
El contrato de datos es necesario para retornar valores cuando se invocan los
servicios (haciendo uso de mensajes), esto porque en WCF no se pueden retornar
tipos de datos puesto que la comunicación esta basada en mensajes XML a través
del protocolo SOAP.
Los errores por su parte son generados basados en el estándar SOAP, mas
adelante en esta misma sección se mencionan los detalles para crear los
manejadores de errores.
Finalmente, cada servicio contiene un archivo de configuración basado en
XML llamado web.config, este archivo contiene entre otras cosas, los parámetros de
conexión a la base de datos de SIABUC.
Dado que la metodología para crear todos los servicios en ABCSIS fue la
misma, este apartado se enfocará solamente en la descripción de un servicio en
particular, el servicio Acervo, el cual contiene el método correspondiente a la
reservación de libros.
El primer elemento a tener en cuenta en el desarrollo de servicio es el binding,
con éste se define la comunicación entre el cliente y el servicio. Para el caso de
ABCSIS fue utilizado el BasicHttpBinding, ya que como se observó en la tabla 5, es
el único que ofrece compatibilidad con la especificación de los servicios Web WS-I
Basic Profile, y debido a esto durante la creación del consumidor resultó ser el más
interoperable entre los lenguajes de programación Visual Basic 2008 y PHP. La
107
definición del binding se hace en el archivo web.config, en la figura 42 se muestra un
extracto de éste archivo con el binding de ABCSIS, por su parte, el elemento address
no se definió puesto que los servicios se realizaron de manera local.
Figura 42. Binding de ABCSIS
Definidas las opciones de configuración ahora se comenzará a describir lo
correspondiente a la creación del servicio. Cada servicio esta definido por un
contrato, el cual se define mediante el atributo <ServiceContract()>, mientras que las
operaciones de servicio son declaradas con el atributo <OperationContract()>, estos
dos atributos forman parte del namespace System.ServiceModel.
En la figura 43 se muestra un extracto de código del servicio Acervo, en dicha
figura se puede apreciar la utilización de los atributos <ServiceContract()> y
<OperationContract()>. Este servicio contiene varias operaciones incorporadas, tal y
como se describió en la sección 4.2.5. También se puede apreciar la definición de la
interfaz del servicio y los métodos que expone mediante la función Reservar.
Figura 43. Servicio Acervo
Como se puede observar en la figura anterior, la interfaz de servicio esta
marcada con el atributo <ServiceContract()> y tiene una operación llamada Reservar,
la cual, tiene a su vez el atributo <OperationContract()>, si un método no contiene
<ServiceContract()> _ Public Interface IAcervo <OperationContract()> _ Function Reservar(ByVal NoCta As String, ByVal NoAdq As String) As String End Interface
<service behaviorConfiguration="ServicioAcervo.AcervoBehavior" name="ServicioAcervo.Acervo"> <endpoint address="" binding="basicHttpBinding" contract="ServicioAcervo.IAcervo"> <identity> <dns value="localhost" /> </identity> </endpoint> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
108
este atributo no podrá ser expuesto y por lo tanto no podrá ser utilizado por un
consumidor.
La operación Reservar regresa una cadena indicando si se llevo a cabo o no
una reservación exitosa, sin embargo, en algunas ocasiones es necesario regresar
un conjunto de registros almacenados en la base de datos, para estos casos es
necesario definir un contrato de datos.
Los contratos de datos hacen la serialización entre mensajes SOAP y objetos
.NET. Un contrato de datos es declarado con el atributo <DataContract()>, esta
compuesto por uno o varios elementos, los cuales son llamados miembros de datos,
los cuales son definidos con el atributo <DataMember()>, si un contrato de datos
contiene un miembro de dato que no esta marcado con dicho atributo no será
serializado por el runtime de WCF.
En la figura 44 se puede apreciar la creación de un contrato de datos que
corresponde a la operación Disponibilidad2, el resultado de invocar esta operación es
un valor del tipo RegistroABCSISEjemplares, ésta, es una clase que esta compuesta
por seis miembros de datos identificados con el atributo <DataMember()>.
Figura 44. Definición del contrato de datos
<ServiceContract()> _ Public Interface IAcervo <OperationContract()> _ Function Disponibilidad2(ByVal NoFicha As Long) As RegistroABCSISEjemplares() End Interface <DataContract()> _ Public Class RegistroABCSISEjemplares <DataMember()> _ Public NumAdqui As String <DataMember()> _ Public IdBiblio As Long <DataMember()> _ Public Ejemplar As Byte <DataMember()> _ Public Volumen As Byte <DataMember()> _ Public Tomo As Byte <DataMember()> _ Public Estado As String End Class
109
Hasta este momento se ha cubierto la parte correspondiente a la creación del
servicio con su respectiva interfaz y contratos, sin embargo, en ocasiones ocurren
errores durante la invocación del mismo. Para ello, el protocolo SOAP tiene una
forma específica de retornar códigos de error formateados mediante el atributo Fault,
el cual, debe especificar al menos dos valores; una descripción del error generado y
un código de error representado mediante un número.
Figura 45. Generación del contrato de datos para el manejo de excepciones
WCF por su parte también provee esta característica incorporada en la
creación de los servicios mediante el atributo <FaultContract()>. Para hacer uso de
esta funcionalidad es necesario definir un contrato de datos similar al de la figura 45,
solamente que aquí existe una pequeña diferencia al momento de crear los
miembros de datos, la diferencia consiste en agregar algunas propiedades para
especificar tanto la descripción del error como el número de error generado, cabe
señalar que con la utilización del modelo de programación WCF, el programador solo
se preocupa por la definición del servicio y su funcionalidad, la generación de
<DataContract()> _ Public Class ABCSISFault Private r_operacion As String Private r_tipoproblema As String <DataMember()> _ Public Property Operacion() As String Get Return r_operacion End Get Set(ByVal value As String) r_operacion = value End Set End Property <DataMember()> _ Public Property TipoProblema() As String Get Return r_tipoproblema End Get Set(ByVal value As String) r_tipoproblema = value End Set End Property End Class
110
mensajes SOAP lo hace de manera transparente el Common Language Runtime
(CLR) provisto en el .NET Framework, de esta manera se agiliza bastante el proceso
de creación de los servicios.
La manera con la que se atrapan los errores es muy similar a otros lenguajes
de programación mediante la instrucción try-catch, dicha instrucción es mostrada en
la figura 46.
Figura 46. Invocación de una excepción
Si ocurre un error, esta instrucción devuelve un valor del tipo ABCSISFault y a
su vez, regresa una descripción del código de error mediante la variable DescError,
así como el número de error correspondiente mediante la variable NumError, todo
esto formateado en mensajes XML para utilizarse con el protocolo SOAP.
Finalmente, la definición completa del servicio con sus respectiva interfaz,
<OperationContract()> y <FaultContract()> quedaría de la forma mostrada en la
figura 47.
Figura 47. Definición del servicio
Una vez creado el servicio es momento de compilarlo, al momento de hacer
esto, Visual Basic genera varios archivos, sin embargo, solo nos interesan algunos
Public Function Reservar(ByVal NoCta As String, ByVal NoAdq As String) As String Implements IAcervo.Reservar
Try 'Conjunto de instruccciones ' …
' … Catch ex As Exception
Dim ErrorFault As New ABCSISFault Throw New FaultException(Of ABCSISFault)(ErrorFault, _ New FaultReason(DescError), _ New FaultCode(NumError)
End Function
<ServiceContract()> _ Public Interface IAcervo <OperationContract()> _ <FaultContract(GetType(ABCSISFault))> _ Function Reservar(ByVal NoCta As String, ByVal NiP As String, ByVal NoAdq As String) As String
111
de estos; archivo de configuración web.config, archivo con extensión .svc
(acervo.svc) y una carpeta llamada bin.
El web.config como ya se mencionó es un archivo XML con parámetros
configurables para el servicio, el archivo acervo.svc contiene una directiva de
procesamiento que es ejecutada por .NET al momento de su invocación, y
finalmente, la carpeta bin esta compuesta por librerías necesarias para el
funcionamiento del servicio. Estos archivos se describirán con mayor detalle en la
sección 5.2.
De esta manera el servicio, su interfaz, address, binding y contract (ABC),
fueron implementados mediante WCF para cubrir los requisitos de una arquitectura
orientada a servicios mostrados en las figuras 16 y 19 del presente trabajo.
Hasta aquí se abordo lo correspondiente a la creación del servicio, sin
embargo, para que un cliente lo pueda utilizar es necesario hospedarlo en un
servidor, este proceso es descrito a continuación en la siguiente sección.
112
5.2 Hosting del servicio
Una vez creado el servicio es necesario publicarlo para que pueda ser consumido
por algún cliente, existen dos formas de publicar un servicio, la primera es a través
de un servidor Web y la segunda es a través de un servicio de Windows. Para el
caso de ABCSIS los servicios creados fueron hospedados en el servidor Web IIS de
Windows XP y fue necesario instalar el Service Pack 3 y el .NET Framework 3.5,
este último al momento de instalarse crea una cuenta de usuario llamada ASPNET la
cual gestiona la invocación relacionada a WCF.
Figura 48. Cuenta de usuario ASPNET
Para hospedar correctamente un servicio es necesario instalar primero el
servidor Web IIS y posteriormente el .NET Framework, en el caso de una variación
en el orden, puede presentarse un problema de acceso a la metabase de IIS con la
cuenta de usuario ASPNET. La metabase es una estructura que almacena
información de configuración del servidor IIS.
Después de tener instalado el IIS y el .Net Framework se procede a crear un
directorio virtual en el servidor, para este trabajo se creó un directorio llamado
ServicioAcervo. En la figura 49 se muestra la creación del directorio virtual, mientras
que en la figura 50 se presenta el directorio virtual creado y los archivos necesarios
del servicio Acervo.
113
Figura 49. Creación de un directorio virtual en IIS
Figura 50. Directorio virtual y archivos del servicio Acervo
Dentro del directorio virtual ServicioAcervo se colocaron los archivos
necesarios para hospedar el servicio en el servidor Web, los cuales se listan a
continuación:
• web.config – Archivo de configuración en XML
• acervo.svc – Contiene la definición de implementación del servicio
114
• carpeta bin – Esta carpeta contiene archivos y librerías necesarias para
implementar el servicio, dentro de las librerías destacan:
ServicioAcervo.dll, Npgsql.dll y Mono.Security.dll
Una vez que el servidor y el servicio están listos para ser utilizados es
necesario hacer una prueba, la cual consiste en invocar el servicio mediante su
dirección Web correspondiente, siguiendo el ejemplo, el servicio acervo esta
hospedado en la carpeta ServicioAcervo, de tal manera que la URL para acceder a
su ubicación quedaría: http://localhost/servicioacervo/acervo.svc, en la figura 51 se
muestra su invocación.
Figura 51. Servicio Acervo hospedado en IIS
De esta manera se puede verificar el funcionamiento correcto del servicio, sin
embargo, es necesario dar conocer toda la información que contiene.
Como ya se comentó anteriormente ABCSIS se encuentra orientado a
servicios Web, un elemento importante de los servicio Web es el WSDL el cual se
encarga de describir la forma mediante la que puede ser consumido dicho servicio,
ABCSIS también cuenta con un WSDL el cual es generado de manera automática
por el CLR de .NET Framework. Para tener acceso al WSDL del servicio Acervo
115
bastará con presionar el enlace mostrado en la parte superior de la figura 51 y
obtendremos algo similar a lo que se muestra en la figura 52.
Figura 52. WSDL del servicio Acervo
El WSDL es necesario para el programador, ya que de esta manera conocerá
todas las operaciones del servicio así como la ubicación del mismo, para finalmente
desarrollar un cliente que pueda consumirlo.
En el siguiente apartado se describe a detalle la forma mediante la cual se
creo un cliente en PHP para consumir el servicio Acervo.
116
5.3 Implementación del prototipo
Una vez que el servicio ha sido programado y publicado entonces se puede crear un
cliente para consumirlo. Una de las ventajas de SOA es la interoperabilidad que
ofrece, se pueden desarrollar aplicaciones por ejemplo en Visual Basic ó ASP
utilizando el .NET Framework, mediante PHP haciendo uso de una extensión
exclusiva para SOAP, ó Java a través de un proyecto denominado Web Services
Interoperability Techonologies (WSIT) (Sun Microsystems, 2007).
Este apartado corresponde a la creación de un cliente Web que se
interconecte con SIABUC con la finalidad de hacer reservaciones de material
bibliográfico, la aplicación fue desarrollada en el lenguaje de programación PHP
versión 5.2.6. La aplicación Web consiste en hacer una búsqueda para localizar un
ejemplar mediante cinco apartados posibles: ISBN, título, autor, clasificación y no. de
adquisición, una vez que se localiza el ejemplar se procede a reservarlo, para esto,
es necesario que el usuario proporcione dos datos para autentificarlo ante el sistema:
su numero de cuenta y una clave de acceso (nip) para hacer la reservación, en la
figura 53 se muestra un diagrama de flujo con el funcionamiento del prototipo.
Figura 53. Diagrama de flujo para la reservación
Ini cio
NO
SI
Reserva Exitosa
SI
NO
NO
SI
NO
SI
Hacer búsqueda
Hacer Reserva
Mostrar registros
Validar Usuario
Mostrar error
1
Nueva Búsqueda
Encontró Registro
1
Fin
Fin
SI
NO
Nueva Búsqueda
1
Fin
117
La razón por la cual se eligió el lenguaje de programación PHP es para
demostrar una de las principales funcionalidades que existe en ABCSIS, la
interoperabilidad.
PHP es un lenguaje de programación basado en script orientado al desarrollo
Web y que se puede embeber dentro de código HTML. La forma mediante la cual se
configura este lenguaje es a través de un archivo de texto plano llamado php.ini, el
cual, controla varias funcionalidades y extensiones de este lenguaje.
Una de las extensiones requeridas para la comunicación entre el proveedor y
el consumidor fue la relacionada con el protocolo SOAP, para hacer uso de esta
funcionalidad es necesario habilitar la librería php_soap.dll en el archivo php.ini, en la
figura 54 se muestra un extracto del archivo con la configuración utilizada.
Figura 54. Archivo de configuración de PHP
Para verificar que dicha extensión fue habilitada correctamente se realizó un
pequeño programa en PHP haciendo uso de la instrucción phpinfo, la cual nos
muestra la configuración actual, en la figura 55 se muestra una sección de ésta
configuración con la extensión SOAP instalada.
Figura 55. Configuración correspondiente para el soporte de SOAP en PHP
118
Antes de iniciar con la programación es necesario conocer la ubicación donde
esta hospedado el servicio (el address) así como también las operaciones que son
necesarias en nuestra aplicación, dichas operaciones son mostradas en la tabla 6 y
fueron extraídas del WSDL mostrado en la figura 52. Tabla 6. Operaciones de servicio utilizadas en el prototipo
Operación Parámetro/Entrada Parámetro/Salida BuscarFicha TipoBusqueda | Entero
TerminoDeBusqueda | Cadena FichaNext | Entero Largo FichaPrev | Entero Largo NoPag | Entero
Arreglo
BuscaAlumno NoCta | Cadena Verdadero/Falso Reservar NoCta | Cadena
Nip | Cadena NoAdq | Cadena
Cadena
Disponibilidad2 NoFicha | Entero Largo Arreglo
Definido lo anterior, es momento de crear el cliente haciendo uso de la librería
php_soap, la cual nos provee soporte para crear clientes SOAP en PHP,
específicamente a través de la instrucción SoapClient, dentro de los parámetros que
recibe se encuentra la dirección del WSDL del servicio, para nuestro ejemplo se creó
un constructor llamado $cliente con la sintaxis mostrada en la figura 56.
Figura 56. Constructor SoapClient para hacer referencia al servicio Acervo
A través del constructor $cliente podemos acceder a todas las operaciones del
servicio mencionadas en la tabla 6, sin embargo, cada operación requiere de algunos
parámetros para su funcionamiento.
La operación BuscarFicha recibe cinco parámetros dentro de los cuales
destacan los dos primeros TipoDeBusqueda y TerminoDeBusqueda. El primer
parámetro es un valor entero para indicar el tipo de búsqueda donde: 0 representa al
ISBN, 1 al título, 2 al autor, 3 a la clasificación y 4 al no. de adquisición, mientras que
el segundo parámetro es un valor de tipo cadena que indica el término a buscar.
Para mayor información acerca de los parámetros restantes favor de consultar la
sección 4.2.5.
$cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl ");
119
Para acceder a estos parámetros es necesario utilizar el operador “→”, el cual
hace referencia a una variable o un método, de tal manera que el código quedaría de
la manera mostrada en la figura 57.
Figura 57. Invocación de la operación BuscarFicha
En la variable $busqueda se almacenan los parámetros de entrada de la
operación mediante la instrucción $_POST, la cual, es necesaria para extraer el valor
pasado a través de la pagina Web mostrada en la figura 58.
Figura 58. Interfaz para consulta y reservación de libros
Por su parte la instrucción utf8_decode es necesaria para codificar el texto a
UTF8, posteriormente se invoca a la operación BuscarFicha enviándole la variable
$busqueda, después se obtiene la respuesta en BuscarFichaResult, cabe mencionar
que para poder acceder al resultado de alguna operación se debe agregar el prefijo
<?php $cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl "); $busqueda→TipoDeBusqueda = $_POST['opciones']; $busqueda→TerminoDeBusqueda = utf8_encode($_POST['txtbuscar']); $resp = $cliente→BuscarFicha($busqueda); $resp = $resp→BuscarFichaResult; settype($resp, "array"); ?>
120
Result al final del nombre de la operación, independientemente del nombre que
contengan, es decir, para invocar a la operación de búsqueda de la ficha se hace de
la siguiente manera BuscarFicha(parámetros), mientras que para acceder a los
valores de retorno se hace de mediante BuscarFichaResult(). Finalmente, mediante
la instrucción settype se convierte la variable $resp a un tipo array.
En caso de encontrar resultados con el término de búsqueda proporcionado
éstos se muestran en una página Web similar a la de la figura 59.
Figura 59. Resultados de la consulta
Si el usuario encontró el ejemplar que necesitaba presiona la leyenda
“Reservar”, de lo contrario realiza otra búsqueda mediante el enlace “Nueva
búsqueda”. Si el alumno intenta reservar un ejemplar, el prototipo primero verifica
que el usuario se encuentre registrado en la base de datos de SIABUC, para esto
utiliza la operación BuscaAlumno, lo cual es mostrado en la figura 60.
Figura 60. Invocación de la operación BuscaAlumno
<?php $cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl "); $lacuenta→NoCta= $_POST['txtcuenta']; $resp=$cliente→BuscaAlumno($lacuenta); $resp=$resp→BuscaAlumnoResult; ?>
121
Como se puede observar, la invocación es similar a la de la figura 56, sin
embargo, aquí no fue necesario hacer uso de la instrucción settype, esto debido a
que esta operación regresa un valor booleano y no un arreglo, como en el caso
anterior.
Siguiendo con el ejemplo prototipo, se eligió el ejemplar con no. de adquisición
114586, si el usuario proporciona un número de cuenta o nip inválido aparecerá un
mensaje como el que se muestra en la figura 61.
Figura 61. Usuario no encontrado en la base de datos
Sin embargo, para nuestro ejemplo se utilizó el número de cuenta 979663, el
cual corresponde a un usuario correctamente registrado en la base de datos de
SIABUC.
122
Figura 62. Usuario válido
Finalmente, si el usuario esta correctamente registrado es momento de hacer
el último paso, la reservación, la forma de invocar esta operación es como se
muestra en la figura 63.
Figura 63. Invocación de la operación Reservar
Si la reservación se hizo correctamente aparece un mensaje con el texto
“Reservación con Éxito!!”, en caso contrario nos aparecerá un mensaje de error.
Para comprobar que la reservación se hizo correctamente se realizó la misma
búsqueda, como se puede observar en la figura 64 ya no aparece el enlace para
realizar la reservación, ahora muestra el estado reservado.
<?php $cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl "); $res→NoCta= $_POST['txtcuenta']; $res→NoAdq= $_POST['numadqui2']; $res= $client→Reservar($res); $res= $res→ReservarResult; echo utf8_decode($res); ?>
123
Figura 64. Ejemplar reservado
Sin embargo, en algunas ocasiones suceden errores, para esto, PHP
proporciona un constructor llamado SoapFault mediante el cual se puede atrapar el
error generado. En la figura 65 se puede observar la forma mediante la cual se utilizó
el contrato de datos ABCSISFault.
Figura 65. Generación de excepción de tipo SoapFault
Una vez definido el constructor se puede acceder a sus métodos de la misma
manera que se hizo con las operaciones, mediante el operador “→”. Hay que
<?php try{
//Invocación de operaciones } catch (SoapFault $fault) {
echo "Ocurrió el error ".str_replace("s:","",$fault→faultcode)." ". utf8_decode($fault→faultstring)."\n\n";
echo "Operacion: ".$fault→detail→ABCSISFault→Operacion."\n"; echo "ProblemType: ". utf8_decode($fault→detail→ABCSISFault→TipoProblema)."\n";
} ?>
124
recordar que el contrato de datos ABCSISFault retorna un mensaje y un número de
error en caso de presentarse alguna excepción.
En la figura 66 se puede observar un error generado debido a una sentencia
Structured Query Language (SQL) mal formada.
Figura 66. Error en sentencia SQL
Hasta aquí, se mostraron los aspectos relacionados con la creación,
hospedaje y manejo de errores con los servicios haciendo uso del modelo de
programación WCF, la ventaja principal de crear los servicios utilizando este modelo,
es que el programador solo tiene que preocuparse por la definición del servicio y su
funcionalidad, ya que la generación de mensajes SOAP lo hace de manera
transparente el CLR provisto en el .NET Framework, de esta manera se agilizó
bastante el proceso de creación de los servicios integrados en ABCSIS.
125
6. Pruebas
Sommerville (2005) menciona que las pruebas es un proceso que intenta
proporcionar confianza en el software, el objetivo principal de realizarlas es
convencer a los desarrolladores del sistema y a los clientes que el software es lo
suficientemente bueno para su uso operacional.
Esta sección tiene como propósito detallar el proceso mediante el cual se
realizaron dos pruebas de software, prueba de operación y prueba de rendimiento. El
objetivo de la prueba de operación es que el usuario final instale el paquete de
ABCSIS y el CGI para que posteriormente opine mediante la contestación de un
cuestionario acerca de su utilidad y facilidad de implementación, mientras que el
objetivo de la prueba de rendimiento es el de conocer el comportamiento de ambas
implementaciones con un incremento gradual en las peticiones de consulta,
obteniendo los tiempos de petición-respuesta para posteriormente graficarlos.
El prototipo de reservación de libros de ABCSIS está compuesto por
búsquedas de material bibliográfico, estado del material (prestado, disponible) y
reservación (apartado), mientras que la implementación CGI sólo se encuentra
integrada por las búsquedas de libros.
126
6.1 Prueba de operación
Esta prueba corresponde a una serie de experimentos cuyos participantes fueron
encargados del área de sistemas, los cuales fueron seleccionados tomando como
base un perfil del área de sistemas el cual se detalla posteriormente. El objetivo del
experimento consistió en instalar y comparar el prototipo de reservación de libros
desarrollado con la arquitectura ABCSIS y la aplicación CGI que SIABUC utiliza
actualmente. Los participantes expresaron su percepción en relación a la utilidad y
facilidad en la implementación que obtuvieron al seguir los procesos para cada una
de las arquitecturas. Debido a que la aplicación CGI solamente comprende un
apartado de búsqueda de libros, la prueba queda restringida a realizar el mismo
proceso con el prototipo de ABCSIS.
Perfil del usuario de prueba Para seleccionar a los usuarios se buscó que cumplieran ciertos requisitos
relacionados con el área de informática o afín. Los requisitos son: haber cursado la
carrera de licenciatura en informática, ingeniería en sistemas ó ingeniería en
telemática; contar con conocimiento previo en el sistema SIABUC; tener
conocimientos básicos en estándares Web y en programación; dominar el sistema
operativo Windows.
Las personas seleccionas son las encargadas de los centros de cómputo de
las bibliotecas incorporadas al sistema bibliotecario de la Universidad de Colima,
debido a las labores que realizan cotidianamente en su trabajo cuentan con un perfil
informático-bibliotecario, gracias a esto, tienen experiencia tanto en el ámbito de
sistemas como en el bibliotecario, cubriendo de esta manera el perfil de prueba
establecido.
Material La prueba aquí presentada corresponde a una prueba de laboratorio, la
infraestructura utilizada para este experimento consistió de lo siguiente:
Hardware:
• PC con procesador Intel
127
• 2 Gb de memoria RAM
• 10 Gb de espacio libre en disco duro
Software:
• Windows XP Professional con service pack 3
• Servidor Web Internet Information Server
• Paquete con la implementación CGI de SIABUC8 (WebPaqS8.zip)
• Bases de datos de SIABUC8
• Prototipo con la implementación de reservación de ABCSIS
• Base de datos de SIABUC9
• .NET Framework 3.5
• PHP versión 5.2.6
• VMware Workstation
Cabe señalar que en la computadora de prueba ya se tenía previamente
instalado el SIABUC8 y el SIABUC9, así como el servidor Web IIS, esto con la
finalidad de que los participantes se dedicaran única y exclusivamente a instalar y
probar las herramientas adicionales de SIABUC, el CGI y el prototipo de reserva de
ABCSIS.
Objetivo Instalar, configurar y comparar el prototipo de reservación de libros desarrollado con
la arquitectura ABCSIS y la aplicación CGI que SIABUC utiliza actualmente.
Procedimiento
Para llevar a cabo las pruebas, a cada participante se le pidió evaluar el proceso de
instalación de las implementaciones ABCSIS y CGI en el sistema operativo Windows
XP Professional, el cual fue instalado sobre el programa VMware.
VMware es un software de virtualización para computadoras de escritorio y
portátiles, su característica principal es crear y ejecutar múltiples máquinas virtuales,
donde cada máquina virtual, representa un sistema operativo completo, incluyendo
128
procesador, memoria, dispositivos de red, periféricos (VMware Inc., 2009). La razón
de utilizar VMware es porque permitía crear el mismo entorno de prueba para todos
los usuarios sin excepción y que de esta manera ninguno tuviera ventajas o
diferencia alguna en cuanto al sistema operativo y aplicaciones previamente
instaladas.
Para que el participante realizara la prueba se le proporcionaron una serie de
documentos y aplicaciones necesarias, todos estos archivos se incluyeron en una
carpeta llamada “Prueba_ABCSIS”, la cual, contiene los siguientes archivos: Guía de
instalación de ABCSIS, Guía de instalación del CGI, Instalador de ABCSIS e
Instalador de PHP.
Figura 67. Entorno de prueba con Windows XP sobre VmWare
129
En la figura 67 se muestra el entorno de prueba con el sistema operativo
Windows XP ejecutándose sobre VmWare, adicionalmente, se puede observar la
carpeta “Prueba_ABCSIS”.
Dentro de la documentación proporcionada a cada participante se especifica
una serie de instrucciones a seguir, las cuales se mencionan a continuación de
manera general:
• Instalación del componente CGI
1. Instalar el paquete WebPaqS8.zip, este paquete contiene una
estructura y archivos necesarios para ejecutar la implementación CGI
de SIABUC8.
2. Copiar las base de datos de SIABUC8
3. Crear un directorio virtual dentro del servidor Web en la siguiente
ubicación C:\catalogos.
4. Asignar permisos de ejecución de aplicaciones CGI en el servidor.
5. Asignar permisos de lectura/escritura a la cuenta de invitado para
Internet, esta es una cuenta que comúnmente comienza con el prefijo
IUSR y es necesario habilitar éstos permisos de lo contrario la
implementación CGI no funciona correctamente.
6. Realizar una consulta en la interfaz de búsqueda.
• Instalación del prototipo de reservación de ABCSIS
1. Instalar el paquete de ABCSIS.
2. Crear los directorios virtuales correspondientes para la implementación
ABCSIS.
3. Verificar la correcta instalación de ABCSIS mediante la invocación del
servicio Acervo.
4. Configurar la conexión a la base de datos de SIABUC9, este proceso
se hace en un archivo llamado web.config.
5. Instalar el lenguaje de programación PHP en conjunto con la extensión
SOAP, esta librería es necesaria para poder acceder a la estructura del
servicio Acervo.
130
Al terminar de instalar las dos implementaciones se le proporcionó al usuario
una guía operativa, en éste documento se le pidió realizar algunas consultas en
ambas interfaces y posteriormente se le aplicó un cuestionario (para mayor detalle,
consultar Anexo), finalmente se le dio la palabra al participante para darle la
oportunidad de aclarar las dudas con respecto a la prueba.
El objetivo del cuestionario es conocer la percepción del participante mediante
la medición de las siguientes variables:
• Experiencia del participante
• Facilidad de instalación/configuración
• Documentación proporcionada
• Interconexión con otras aplicaciones como sistemas escolares o
administrativos de las instituciones usuarias de SIABUC
En el cuestionario fue aplicado a ocho personas y se utilizó la escala de Likert
como instrumento de medición. La escala de Likert se utiliza para medir las actitudes
o predisposiciones de manera individual en contextos sociales, se construye en base
a una serie de preguntas que reflejan una actitud positiva o negativa acerca de un
estímulo, regularmente cada pregunta esta compuesta de cinco a siete alternativas
de respuesta (Ávila, 2006).
6.1.1 Resultados
Para la obtención de los resultados de ésta prueba se aplicó un cuestionario basado
en la escala de Likert, el cuestionario se encuentra estructurado por ocho preguntas,
las cuales, están compuestas por cinco ítems de respuesta, cada ítem tiene un valor
numérico en la escala del uno al cinco, el uno corresponde a la respuesta donde el
usuario esta totalmente en desacuerdo con la pregunta, mientras que el cinco
corresponde a la respuesta con la cual esta totalmente de acuerdo.
131
La forma de medición del cuestionario se baso en sumar las respuestas
obtenidas y al final obtener un promedio, el cual estará en una escala del veinte al
cien por ciento. Del cuestionario aplicado se desprenden los resultados mostrados en
la tabla 6.
Tabla 7. Resultados de la encuesta aplicada en la prueba de operación
Participante P1 P2 P3 P4 P5 P6 P7 P8 Total Prom. % Experiencia en programación
2 4 2 2 5 4 4 5 28 3.5 70
Conocimiento WS 1 1 2 4 4 4 4 5 25 3.1 62 Instalación ABCSIS vs. CGI
5 5 5 5 5 4 5 2 36 4.5 90
Documentación 5 1 5 5 5 5 1 5 32 4.0 80 Fácil configuración ABCSIS
5 2 4 5 5 4 4 3 32 4.0 80
Fácil configuración CGI
4 4 5 5 4 4 4 4 34 4.3 86
Interconexión de ABCSIS con otros sistemas
5 3 5 4 5 4 4 5 35 4.4 88
Evaluación general ABCSIS
5 4 5 5 4 4 5 4 36 4.5 90
En base a los resultados anteriores se puede apreciar que el setenta por
ciento de los usuarios encuestados cuentan con experiencia en el ámbito de
programación, esto debido a que la mayoría de los encuestados son encargados de
centros de cómputo y su actividad principal no es el desarrollo de software, mientras
que en el aspecto de los conocimientos acerca de los protocolos relacionados con
los servicios Web solo el sesenta y dos por ciento los conoce.
Por otra parte, lo relacionado a la configuración de ABCSIS el ochenta por
ciento opinó que le resultó fácil de instalar, uno de los comentarios en éste sentido
fue que se tienen que hacer dos pruebas para verificar la correcta instalación de los
componentes de ABCSIS (las pruebas consisten en invocar dos páginas Web), la
5 4 3 2 1 Valor de la escala Total Total acuerdo desacuerdo 100 80 60 40 20 % de la escala
132
instalación del CGI por su parte no cuenta con un mecanismo similar, razón por la
cual obtuvo una mayor calificación en éste sentido.
Por su parte en el aspecto de instalación el noventa por ciento de los usuarios
evaluados expresaron que la instalación del prototipo de ABCSIS les resultó más
fácil de realizar, debido a que cuenta con un asistente que guía al usuario durante
todo el proceso, mientras que el CGI es un paquete compactado que se tiene que
descomprimir para posteriormente copiar una serie de archivos manualmente.
En cuanto a la factibilidad de interconexión de ABCSIS con otros sistemas
administrativos el ochenta y ocho por ciento consideró factible este proceso debido a
los servicios Web que trae incorporados y a su arquitectura basada en SOA.
Finalmente, el noventa por ciento de los usuarios encuestados consideraron
que esta nueva implementación es buena para el sistema SIABUC.
La presente prueba se aplicó a ocho participantes de los cuales tres fueron
mujeres y cinco hombres, el tiempo promedio que tardaron en realizar la prueba
oscilo entre una hora, a hora y media, cabe señalar que durante este tiempo veinte
minutos aproximadamente fueron consumidos por la instalación del .NET
Framework.
133
6.2 Prueba de rendimiento Las pruebas de rendimiento también conocidas como pruebas de estrés son
utilizadas para asegurarse que el sistema en cuestión pueda procesar su carga
esperada. Básicamente, consiste en planificar una prueba donde la carga de trabajo
se incremente paulatinamente hasta que el rendimiento del sistema sea inaceptable
(Sommerville, 2005).
La prueba realizada en esta sección consistió en hacer consultas a través de
la red de la Dirección General de Servicios Bibliotecarios tanto de la implementación
CGI como del prototipo de ABCSIS, el estudio se basó en realizar cinco pruebas con
cinco, cincuenta, quinientos y cinco mil peticiones de consulta, las cuales simulaban
a usuarios haciendo peticiones de consulta, debido a la variabilidad de la red se
realizaron varias pruebas para obtener un promedio estandarizado y posteriormente
observar el comportamiento de éstas tecnologías mediante gráficas de líneas.
Para la realización de esta prueba se utilizaron dos computadoras, una que
actúo como servidor y otra que actúo como cliente, la computadora servidor estaba
compuesta por un procesador Intel a 1.8 Ghz con 2 gb de RAM con las siguientes
aplicaciones instaladas:
• Windows 2008 Server sobre WmWare
• Implementación de consulta de SIABUC8
• Base de datos de SIABUC8
• Prototipo de reservación de ABCSIS
• Base de datos de SIABUC9
Mientras que las características técnicas de la computadora que se uso como
cliente son las siguientes:
Hardware:
• Pc con procesador Intel Centrino Duo a 1.6 Ghz
• 2 Gb de memoria RAM
• 10 Gb de espacio libre en disco duro
134
Software:
• Windows XP Professional con service pack 3
• Aplicación para simular las peticiones de consulta al servidor
Cabe señalar que se utilizó la misma información en ambas
implementaciones, es decir, la información contenida en la base de SIABUC8 se
convirtió al formato de SIABUC9 para poderla utilizarla en el prototipo de reservación
de ABCSIS, esto con la finalidad de consultar los mismos datos y que esto no
repercutiera en los tiempos de respuesta durante la prueba.
La prueba consistió en ejecutar una aplicación en la computadora cliente para
simular las peticiones (figura 68), la cual se conecta vía TCP al servidor y manda
solicitudes de consulta a través del método POST de HTML, cada petición la realiza
con un intervalo de 100 milisegundos; dicha aplicación fue elaborada en Visual Basic
6.0. Una vez que enviaba la petición de consulta al servidor, este respondía y la
aplicación almacenaba los tiempos de petición-respuesta en una bitácora en formato
de Excel, estos datos posteriormente se graficaron.
Figura 68. Aplicación utilizada en la prueba de rendimiento
135
A continuación, en la figura 69 se muestra el proceso de petición-respuesta en
ésta prueba.
Figura 69. Proceso de petición-respuesta de la prueba de rendimiento
Para el caso de la prueba en la implementación CGI se utilizó el método
POST enviándole como parámetros una serie de variables, las cuales se listan a
continuación:
• Txtlib. Se utiliza para colocar el parámetro de búsqueda
• Cantidad. Es el número de registros a desplegar por página
• FichaIni. Registro (ficha bibliográfica) a partir de la cual comenzará a
desplegar los resultados obtenidos
• ACERVO. Tipo de información a consultar, puede tener dos valores
LIBROS ó REVISTAS, para nuestro caso se optó por la búsqueda de
libros solamente.
• ArchivoCFG. Archivo de configuración con código HTML que se utiliza
para desplegar los registros obtenidos en la búsqueda.
A continuación, en la figura 70 se muestra la cabecera HTTP enviada a la
implementación CGI, en dicha figura se aprecia tanto el método POST como el
conjunto de parámetros enviados.
Pc-cliente Pc-servidor
Bitácora Excel
Envía peticiones
Responde a las peticiones
Se almacena la respuesta en
bitácora
136
Figura 70. Cabecera HTTP enviada a la implementación CGI
Mientras que la respuesta obtenida se muestra en la figura 71, cabe señalar
que conforme se aumentaba la carga de peticiones éstas respuestas tardaban arriba
de los sesenta segundos.
Figura 71. Respuesta exitosa por parte de la implementación CGI
Para el caso de ABCSIS la petición de consulta también se utilizó el método
POST, como se mencionó en la sección 5.3 Implementación del prototipo, para poder
utilizar cada servicio de ABCSIS es necesario hacer un constructor, para el presenta
trabajo este constructor fue hecho en el lenguaje PHP, la razón de hacerlo en éste
lenguaje fue para demostrar una de las características de ABCSIS la
interoperabilidad. A éste constructor, se le pasa como parámetro la dirección del
WSDL del servicio en cuestión, hecho lo anterior, se puede utilizar la interfaz del
HTTP/1.1 100 Continue Server: Microsoft-IIS/5.1 Date: Fri, 21 Aug 2009 03:39:05 GMT X-Powered-By: ASP.NET
HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Fri, 21 Aug 2009 03:39:05 GMT X-Powered-By: ASP.NET Connection: close Content-Type: text/html Cache-Control: public
<html> <body>
<!-- Registros obtenidos en la búsqueda --> </body> </html>
POST /catalogos/cgi-bin/web_s8.exe HTTP/1.1 Host: 148.213.21.80 Content-Type: application/x-www-form-urlencoded Content-Length: 74
txtLIB=mexico&Cantidad=10&FichaINI=1&ACERVO=LIBROS&ArchivoCFG=Lib_Gral.cfg
137
servicio, ésta interfaz es la encargada de recibir los parámetros, que para éste caso
se le enviaron a través del método POST, la petición de consulta es mostrada en la
figura 72.
Figura 72. Petición de búsqueda en ABCSIS con el método POST
Mientras que la estructura del script que recibe los parámetros es el que se
muestra en la figura 73.
Figura 73. Script php que recibe los parámetros enviados con el método POST
Como se puede apreciar tanto en la figura 70 como en la figura 72 las
variables txtlib y TerminoDeBusqueda contienen el mismo término, esto con la
<?php //Creación del constructor $wsdl= 'http://148.213.21.80/ServicioAcervo/Acervo.svc?wsdl'; $cliente = new SoapClient($wsdl); //Parámetros de búsqueda $params->TipoDeBusqueda= $_POST['tipobusqueda']; $params->TerminoDeBusqueda= $_POST['terminobusqueda']; $params->FichaNext= $_POST['fichanext']; $params->FichaPrev= $_POST['fichaprev']; $params->NoPag= $_POST['nopag']; //Invocación de la operación ValidaUsuario $ws=$cliente->BuscarFicha($params); //Obteniendo los resultados de la invocación $wsResult=$ws->BuscarFichaResult; //Imprimiendo el resultado de la invocación settype($wsResult, "array"); for($i=0; $i<10; $i++) { //Imprimir en pantalla cada uno de los valores } ?>
POST /pruebaabcsis/pruebaabcsis.php HTTP/1.1 Host: 148.213.21.80 Content-Type: application/x-www-form-urlencoded Content-Length: 69 tipobusqueda=1&terminobusqueda=mexico&fichanext=1&fichaprev=0&nopag=1
138
finalidad de que la información a consultar no fuera un factor determinante para que
una implementación tuviera ventajas sobre la otra en el tiempo de respuesta y que la
prueba fuera en condiciones semejantes.
Posteriormente, en caso de obtener una respuesta correcta el servidor
responde con la cabecera HTTP la cual es mostrada en la figura 74.
Figura 74. Respuesta del servidor a una petición de búsqueda en ABCSIS
Durante la ejecución de ésta aplicación el prototipo ABCSIS demostró una
característica que consistía en lo siguiente, cuando se hacia la petición del servicio la
primera ocasión tardaba entre treinta y cuarenta segundos en atender las consultas,
esto es un proceso normal debido a que tiene que instanciar los objetos del CLR de
.NET entre ellos el servicio de ASPNET, posteriormente las repuestas a las consultas
son muy rapidez y la mayoría de éstas se encuentran por debajo del segundo.
Otra de las cuestiones observadas fue la estabilidad que el prototipo de
ABCSIS mostró, ya que en situaciones con demasiada carga de trabajo siempre se
mantuvo en un rango de respuesta aceptable (por debajo de un segundo) mientras
que la aplicación CGI a medida que la carga de trabajo aumentaba su rendimiento
disminuía, esto demuestra una confiabilidad muy aceptable en el rendimiento de
ABCSIS.
HTTP/1.1 100 Continue Server: Microsoft-IIS/5.1 Date: Fri, 21 Aug 2009 04:02:17 GMT X-Powered-By: ASP.NET
HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Fri, 21 Aug 2009 04:02:17 GMT X-Powered-By: ASP.NET Connection: close X-Powered-By: PHP/5.2.6 Content-type: text/html <html> <body>
<!-- Registros obtenidos en la búsqueda --> </body> </html>
139
Otro de los aspectos que se pudieron observar en la prueba fue que a medida
que la cantidad de peticiones aumentaba se quedaban algunos procesos del CGI
colgados en memoria llegando en ocasiones al cien por ciento de la utilización de la
ésta, esto se puede apreciar en la figura 75 mediante la ejecución de la aplicación
CGI Web_s8.exe.
Figura 75. Múltiples procesos en ejecución en la modalidad CGI (web_s8.exe)
Lo anterior no sucedía con el prototipo de ABCSIS, en este caso la utilización
de los recursos utilizados en la computadora oscilaba entre el sesenta al sesenta y
nueve por ciento, esto se puede apreciar en la figura 76. El único factor de lentitud
detectado durante las pruebas de ABCSIS fue cuando se iniciaba la primer petición
de consulta ya que tardaba en iniciar el servicio Web de ABCSIS como se había
mencionado anteriormente, sin embargo, este mecanismo solo se hace en una sola
ocasión y posteriormente la velocidad de respuesta es muy veloz, en las gráficas
mostradas posteriormente se verá reflejado este dato.
Cabe señalar que esta prueba se realizó utilizando la red que cotidianamente
utiliza cualquier computadora de la Dirección General de Servicios Bibliotecarios,
140
razón por la cual no estaba exenta del tráfico de Internet, debido a esto, en
ocasiones el servidor excedía en su tiempo de respuesta, por lo que se optó por
definir un patrón o normalización en el tiempo de respuesta, de tal manera que
aquellas consultas que tardaban más de sesenta segundos en procesar fueron
tomadas como respuestas insatisfactorias tomando como tiempo de respuesta el
patrón de tiempo definido previamente.
Figura 76. Menor cantidad de recursos utilizados por el prototipo ABCSIS
A continuación, en la siguiente sección se muestran las gráficas y la
información tomada en base a las pruebas de rendimiento realizadas.
6.2.1 Resultados
En esta sección se muestran las gráficas obtenidas en base a los tiempos de
respuesta por parte de las implementaciones CGI y el prototipo ABCSIS.
141
Como ya se mencionó en el apartado anterior, se realizaron pruebas con
cinco, cincuenta, quinientos y cinco mil iteraciones, donde cada iteración esta
representada por un evento y el tiempo de respuesta esta representado en
segundos.
A continuación, se muestra la información relacionada a los tiempos de
ABCSIS y posteriormente se muestra lo relacionado al CGI. En la tabla 8 se muestra
la bitácora con los tiempos obtenidos en base a cada uno de los eventos, solo se
muestra la información relacionada a la prueba con cinco iteraciones por cuestiones
de espacio. Tabla 8. Información de la prueba de ABCSIS con cinco eventos
En esta primera prueba se puede observar que el tiempo de respuesta de
ABCSIS es muy estable, a continuación, en la figura 77 se muestra la gráfica con el
promedio de los tiempos de respuesta, en ésta figura se puede apreciar una línea
que oscila aproximadamente en los diecisiete segundos.
Promedio de las pruebas en red con 5 eventos - ABCSIS
0
5
10
15
20
1 2 3 4 5
Usuarios
Tiem
po (s
eg.)
Eventos
Figura 77. Promedio de la prueba de ABCSIS con cinco eventos
EventoA EventoB EventoC EventoD EventoE Promedio 18.047 18.504 18.14 17.39 15.188 17.4538 17.953 18.426 18.015 17.281 15.079 17.3508 17.844 18.301 17.906 17.171 14.969 17.2382 17.719 18.21 17.797 17.062 14.86 17.1296 17.609 18.066 17.687 16.953 14.75 17.013
142
A pesar de que se realizaron pocos eventos el tiempo de respuesta esta por
arriba del promedio general de las demás pruebas, las cuales se podrán observar a
continuación, la razón de esto es porque como se mencionó en la sección anterior
cuando se ejecuta por primera vez el servicio de ABCSIS tarda en instanciar algunos
de sus componentes en memoria.
Posteriormente se realizó la prueba con cincuenta eventos, en ésta prueba
existe una gran diferencia en la velocidad de respuesta, puesto que mejoró
considerablemente, anteriormente el promedio oscilaba en los diecisiete segundos y
en esta prueba oscila entre .05 y .06 segundos.
En la figura 78 se puede observar el promedio de los tiempos de respuesta, en
ésta figura se aprecia una diferencia de tiempo con respecto a la gráfica mostrada en
la figura 77.
Promedio de las pruebas en red con 50 eventos - ABCSIS
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49
Usuarios
Tiem
po (s
eg.)
Eventos
Figura 78. Promedio de la prueba de ABCSIS con cincuenta eventos
Después se realizó una prueba aumentado la carga de trabajo, la cual
consistió en ejecutar 500 eventos, el promedio ésta gráfica es mostrado en la figura
79, una de las características observadas es que a pesar del incremento en la
cantidad de ejecuciones persiste una estabilidad en el tiempo de respuesta.
143
Promedio de las pruebas en red con 500 eventos - ABCSIS
0
0.02
0.04
0.06
0.08
0.1
0.12
1 30 59 88 117 146 175 204 233 262 291 320 349 378 407 436 465 494
Usuarios
Tiem
po (s
eg.)
Eventos
Figura 79. Promedio de la prueba de ABCSIS con quinientos eventos
Finalmente, se ejecutó una prueba con cinco mil eventos, el promedio es
mostrado en la figura 80, en ésta figura se puede observar que a pesar de la carga
de trabajo, el tiempo de respuesta se encuentra por abajo del segundo
aproximadamente.
Promedio de las pruebas en red con 5000 eventos - ABCSIS
0
0.2
0.4
0.6
0.8
1
1 359 717 1075 1433 1791 2149 2507 2865 3223 3581 3939 4297 4655
Usuarios
Tiem
po (s
eg.)
Eventos
Figura 80. Promedio de la prueba de ABCSIS con cinco mil eventos
Hasta aquí se mostraron las pruebas de rendimiento relacionadas con
ABCSIS, a continuación, se muestra la información obtenida de las pruebas de
144
realizadas con el CGI. Al igual que en las pruebas anteriores, en la tabla 9 solo se
muestra los datos de los tiempos de respuesta correspondientes a la primer prueba
por cuestiones de espacio. Tabla 9. Información de la prueba de CGI con cinco eventos
La primera prueba realizada fue con cinco eventos, la mayor parte de los
eventos realizados muestran un tiempo de respuesta aceptable y con cierta
semejanza ya que la mayoría oscilaron sobre cuatro y cinco segundos de respuesta.
En esta prueba la aplicación CGI respondió conforme a lo esperado, sin
embargo, en gráficas posteriores se observará como a medida que la carga de
trabajo se va incrementando el rendimiento de la implementación CGI se va
decrementando, a tal grado que en algunas ocasiones el tiempo de respuesta fue
superior a los sesenta segundos. El promedio de esta prueba se muestra en la figura
81, aquí se puede apreciar una línea con un tiempo de respuesta por debajo de los
seis segundos, un tiempo de respuesta aceptable.
Promedio de las pruebas en red con 5 eventos - CGI
02468
1012141618
1 2 3 4 5
Usuarios
Tiem
po (s
eg.)
Eventos
Figura 81. Promedio de la prueba CGI con cinco eventos
EventoA EventoB EventoC EventoD EventoE Promedio 4.532 4.469 4.469 4.796 4.844 4.622 4.422 4.359 4.172 4.672 4.75 4.475 4.328 4.25 4.235 4.547 4.61 4.394 4.203 4.141 3.984 4.437 4.515 4.256 4.109 3.984 3.859 4.344 4.422 4.1436
145
Posteriormente, se realizó la prueba con cincuenta eventos, en esta prueba se
puede notar que el tiempo de respuesta se incrementó, sin embargo, a pesar de
esto, el tiempo de respuesta promedio sigue demostrando cierta estabilidad, ya que
se encuentra en once segundos aproximadamente.
Promedio de las pruebas en red con 50 eventos - CGI
0
5
10
15
20
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49
Usuarios
Tiem
po (s
eg.)
Eventos
Figura 82. Promedio de la prueba de CGI con cincuenta eventos
Después, se aumentó la carga de trabajo a quinientos eventos, en ésta
prueba se puede apreciar un incremento muy notable en los tiempos de respuesta ya
que algunos de éstos superaron los sesenta segundos definidos como el máximo
tiempo de respuesta deseable, por lo que se optó por delimitar la gráfica en este
intervalo.
Promedio de las pruebas en red con 500 eventos - CGI
0
10
20
30
40
50
60
70
1 29 57 85 113 141 169 197 225 253 281 309 337 365 393 421 449 477
Usuarios
Tiem
pos
(seg
.)
Eventos
Figura 83. Promedio de la prueba CGI con quinientos eventos
146
El promedio de ésta prueba también tiene un cambio significativo respecto a
las anteriores, en la figura 83 se puede observar que la estabilidad mostrada en las
pruebas anteriores aquí ya no esta presente, puesto que existe tiempos de respuesta
muy variables, los cuales se ven reflejados en crestas y valles, algunos de ellos muy
pronunciados en la gráfica.
Finalmente, se realizó la prueba con más carga de trabajo con el incremento
de cinco mil eventos, la mayoría de los tiempos de respuesta en ésta prueba
excedieron los sesenta segundos, debido a esto, en la figura 84 se puede observar
que los tiempos promedio de respuesta se encuentran aproximadamente en los
cincuenta segundos formando casi una línea debido a que fueron acotados por
excederse del tiempo de respuesta deseable. Adicionalmente se puede observar
como al inicio de la prueba el tiempo de respuesta es bueno, sin embargo a medida
que ésta avanza se va incrementando cada vez mas hasta llegar al límite esperado.
Promedio de las pruebas con 5000 eventos - CGI
0
10
20
30
40
50
60
70
1 355 709 1063 1417 1771 2125 2479 2833 3187 3541 3895 4249 4603 4957
Usuarios
Tiem
po (s
eg.)
Eventos
Figura 84. Promedio de la prueba CGI con cinco mil eventos
En esta sección se abordaron los detalles relacionados a las pruebas
realizadas de las implementaciones ABCSIS y CGI, se realizaron dos pruebas, la
primera de ellas orientada a los usuarios finales de las aplicaciones y la segunda al
rendimiento en situaciones de carga de trabajo considerables, en la siguiente sección
se hace un análisis de la información presentada y las conclusiones
correspondientes.
147
7. Resultados y conclusiones
En ésta sección se mencionan los resultados obtenidos durante la aplicación de la
prueba de operación y la prueba de rendimiento, los resultados se abordan desde un
punto de vista cuantitativo y cualitativo. También, se mencionan las posibles
aplicaciones de la arquitectura ABCSIS que actualmente se encuentran disponibles,
como es el caso de una implementación prototipo llamada iSIABUC, la cual funciona
como una distribución front-end de ejemplo para los usuarios de SIABUC. Finalmente
se mencionan las recomendaciones para trabajo futuro y las conclusiones.
7.1 Análisis de los resultados Prueba de operación Durante esta prueba se evaluaron varios aspectos, desde la experiencia del
participante hasta la implementación y facilidad de instalación de las tecnologías CGI
y el prototipo ABCSIS. A continuación se detallan cada una de ellas:
• Experiencia del programador
Durante la realización de la prueba de operación se pudo apreciar que el 70% de
los participantes cuentan con conocimientos en programación, esto, a pesar de
que no son desarrolladores de software, ya que la mayoría de ellos son
encargados de los diferentes centros de cómputo de las bibliotecas de la
Universidad de Colima.
• Comparación del proceso de instalación de ABCSIS vs. CGI
En cuanto a la instalación de ABCSIS el 90% de los participantes mencionaron
que este proceso fue más sencillo que la instalación del CGI, debido a que
ABCSIS cuenta con un asistente de instalación que guía al usuario paso a paso
durante este proceso, mientras que el CGI no cuenta con esa funcionalidad.
• Configuración de ABCSIS vs. CGI y conocimiento de los servicios Web
En el aspecto de configuración de ABCSIS el 80% de los participantes
mencionaron que les resultó fácil, sólo el 62% manifestó tener experiencia en
148
estándares y tecnologías Web, lo cual indica que el prototipo ABCSIS ha sido
apropiado, puesto que a pesar de que algunos participantes no tienen gran
experiencia en estas tecnologías lograron realizar la instalación e implementar
satisfactoriamente el prototipo ABCSIS.
• Interconexión de ABCSIS con otros sistemas y evaluación general
Finalmente, el 90% de los participantes encuestados calificaron como bueno el
prototipo ABCSIS, y debido a la incorporación de los servicios Web el 88%
consideran factible la interconexión de la arquitectura ABCSIS con otros sistemas.
Prueba de rendimiento Tomando como base los datos obtenidos en la prueba de rendimiento de la sección
6.2, se pudo observar que con la arquitectura ABCSIS se obtiene una estabilidad y
confiabilidad en los tiempos de respuesta a diferencia del CGI.
Esto se ve reflejado claramente en la prueba con mayor carga de trabajo realizada
con 5000 peticiones de consulta, en ésta prueba, el tiempo de respuesta mayor fue
de .07 segundos con el prototipo ABCSIS, mientras que la misma prueba realizada
con la implementación CGI la respuesta mayor fue de 48 segundos. Esta notable
diferencia a favor en los tiempos de respuesta, se debe a que ABCSIS no requiere
cargar en memoria un proceso por cada petición recibida mientras que la aplicación
CGI lo hace para cada una de estas peticiones, lográndose una gran confiabilidad en
situaciones de intensa carga de trabajo, garantizando de esta manera la respuesta
en el servicio de consultas a un número considerable de usuarios.
149
7.2 Conclusiones La información obtenida en la prueba de operación muestra que a pesar de que un
poco más de la mitad (62%) de los participantes tiene experiencia en el uso de las
nuevas tecnologías, y con ciertas carencias de actualización profesional, cumplen
con sus funciones encomendadas de apoyo técnico a las bibliotecas.
Esta realidad del perfil informático identificada en la prueba, puede ser incluso
más deficiente en otras instituciones. Para sostener esta aseveración se cuenta con
la experiencia que se ha obtenido con más de 5 años brindando soporte técnico a
infinidad de usuarios bibliotecarios e informáticos de instituciones a nivel
Latinoamérica. Estas condiciones prevalecen en las instituciones que usan SIABUC,
donde son pocas las que tienen el apoyo continuo del personal de informática, y por
eso es de suma importancia ofrecer un mecanismo tecnológico que facilite las tareas
de instalación, configuración y puesta en marcha, donde la plataforma ABCSIS viene
a cubrir esta carencia.
Con los resultados obtenidos en las pruebas, se puede concluir que se ha
cumplido el objetivo de este trabajo, encapsular una gran funcionalidad y ofrecerla
para que los usuarios finales puedan incorporarla a sus desarrollos, incluso de
manera más fácil y sencilla como se hacia con la plataforma anterior basada en CGI.
También, en base al cuestionario realizado, la hipótesis ha quedado comprobada, ya
que el 88% de los encuestados consideran factible la interconexión de ABCSIS con
otros sistemas.
Actualmente ya se encuentra disponible una aplicación funcional denominada
iSIABUC. El encargado de crear dicha aplicación también participó en la prueba y le
resultó muy fácil realizar el acoplamiento de ABCSIS con la aplicación front-end. La
aplicación consiste en una interfaz Web para SIABUC que consume todos los
servicios que ABCSIS provee, desarrollando así un mecanismo que ofrece distintos
servicios vía Web a la comunidad universitaria (Guedea, 2009). La dirección
electrónica para acceder a ésta aplicación es la siguiente:
http://siabuc.ucol.mx/s9mashup.
Las expectativas de este proyecto se han cumplido satisfactoriamente,
creando una metodología de desarrollo de software basado en SOA para el software
150
SIABUC, con la finalidad de extender los servicios que actualmente se ofrecen en la
biblioteca a partir de la funcionalidad básica existente en SIABUC.
151
7.3 Trabajo futuro Para la creación de la arquitectura propuesta en éste trabajo se utilizó la plataforma
Windows en combinación con el .NET Framework que éste sistema operativo ofrece,
si se desea que ABCSIS funcione completamente de manera interoperable se
recomienda elaborarla mediante otro lenguaje de programación, esto es factible de
realizar gracias al diseño propuesto basado SOA y a la implementación de los
servicios Web, para el caso del presente trabajo se realizó bajo Windows debido a
que es la plataforma nativa del software SIABUC.
Adicionalmente se sugiere la creación de los clientes para consumir los
servicios restantes de ABCSIS en los distintos lenguajes de programación: PHP,
ASP, Visual Basic. En este sentido, se propone la creación de una comunidad virtual
de desarrolladores de SIABUC donde participen los usuarios de las distintas
instituciones usuarias de SIABUC, para que compartan sus experiencias en la
utilización de ésta nueva arquitectura a los usuarios que carezcan de conocimientos
en desarrollo de software. Y debido a que la arquitectura ABCSIS esta orientada a
servicios, éstos se pueden extender fácilmente, identificando varias funcionalidades
para agregarlas a la versión ABCSIS 2.0, por ejemplo la creación de un nuevo
servicio para obtener un listado de las reservaciones que tiene actualmente un
usuario.
Como aplicaciones futuras, los servicios de ABCSIS se pueden incluir en un
repositorio para que se compartan con otros usuarios sin que se lucre o se obtengan
beneficios económicos, comerciales o de cualquier otra índole, sin la previa
autorización de la Universidad de Colima y bajo la firma de un convenio especial de
colaboración y desarrollo.
La finalidad de compartir las librerías es para desarrollar, por ejemplo,
aplicaciones adicionales para otras plataformas, aplicaciones para dispositivos
portátiles, entre otras. Y de esta manera consultar por ejemplo el estado de préstamo
de un determinado libro, consultar los adeudos por parte de un usuario en la
biblioteca, verificar los préstamos de libros que actualmente tiene el usuario.
152
Referencias
Albin, S. (2003). The Art of Software Architecture-Design Methods and Techniques. Estados Unidos : Wiley Publishing.
Arcelli, F., Tosi, Ch. y Zanoni, M. (2008). Can Design Pattern Detection be Useful for Legacy System Migration towards SOA?. Obtenido el 28 de Agosto de 2008 de la base de datos de ACM. Ávila, H. (2006). Introducción a la metodología de la investigación. Consultado el 21 de Julio de 2009, de http://www.eumed.net/libros/2006c/203/2k.htm Brinati, A. (2003). Transformación de los procesos productivos de una biblioteca tradicional a una biblioteca virtual. Trabajo presentado en el 2o. Congreso Internacional de Bibliotecología, Documentación y Archivística (CIBDA), Septiembre, Bolivia.
Brown, P. (2008). Implementing SOA: Total Architecture in Practice. Estados Unidos: Addison Wesley.
Cerami, E. (2002). Web Services Essentials. Distributed Applications with XML-RPC, SOAP, UDDI & WSDL. Estados Unidos: O’Reilly.
Chappell, D. (2002). Java Web Services. Using Java in Service-Oriented Architectures. Estados Unidos: O’Reilly.
Chen, I. y Huang Ch. (2006). An SOA-based software deployment management system. Obtenido el 29 de Noviembre de 2007 de la base de datos de ACM. Electronic Data System (2008). Service Oriented Architecture in the Airline Industry. Consultado el 26 de Agosto de 2008, de http://download.microsoft.com/download/a/7/0/a70394d4-164b-47e3-906d-71275b6b6ae3/EDS%20and%20Microsoft%20WP_SOA%20in%20the%20Airline%20 Industry.pdf
Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology and Design. Estados Unidos:Prentice Hall
Fremantle, P. (2002). Applying the Web services invocation framework. Consultado el 24 de Mayo de 2008, de http://www.ibm.com/developerworks/webservices/library/ws-appwsif.html
González, A. y Guarino, L. (2005). Platform-Independent Accesibility API: Accesible Document Object Model. Obtenido el 15 de Mayo de 2008 de la base de datos de ACM.
Gorton, I. (2006). Essential Software Architecture. Alemania : Springer.
Grupo Sistemas Lógicos (2007a). Logicat 2 mil 7. Consultado el 3 de Noviembre de 2007, en http://www.gsl.com.mx/logicat.html
153
Grupo Sistemas Lógicos (2007b). Aleph. Consultado el 3 de Noviembre de 2007, de http://www.gsl.com.mx/ppt/aleph.pdf
Guruge, A. (2004). Web Services – Theory and Practice. Estados Unidos: Elsevier Digital Press.
Guedea, H. (2009). Mashup para los servicios de SIABUC. Tesis de Ingenieria, Facultad de Telemática, Universidad de Colima.
Herrera-Morales, JR., Campos, J. L., Serrano, E., Pérez, L., Gutiérrez, J. R. (2004). Automatización de Bibliotecas con SIABUC. México: Universidad de Colima.
Herrera-Morales, JR. (2006). Guía de referencia técnica de la API WebS8DLL para SIABUC. México: Departamento de SIABUC. Universidad de Colima. Obtenido el 25 de Febrero de 2008 de http://siabuc.ucol.mx/docs/APIWebS8DLL.pdf
Herrrera-Morales, JR. (2007). SIABUC: más de 20 años apoyando la automatización de bibliotecas en Latinoamérica. Revista Iridia, Año 2, Vol. 4, 84-89.
Hubbers, J., Ligthart, A. y Terlouw, L. (2007). Ten Ways to Identify Services. The SOA Magazine, XII. Obtenido el 10 de Diciembre de 2007 de http://www.soamag.com/I13/1207-1.pdf
INNOVATIVE Interfaces (2006). Millennium. Consultado el 3 de Noviembre de 2007, de http://www.iii.com/mill/webopac.shtml
Josuttis, N. (2007). SOA in Practice. The Art of Distributed System Design. Estados Unidos: O’reilly.
Juric, M., Loganathan, R., Sarang, P. y Jennings, F. (2007). SOA Approach to Integration. XML Web Services, ESB, and BPEL in real-world SOA Projects. Reino Unido:Packt Publishing.
Kajko-Mattsson, M., Lewis, G. y Smith D. (2007). A framework for roles for development, evolution and maintenance of soa-based system. Obtenido el 15 de Septiembre de 2008 de la base de datos de ACM.
Kim, S. y Han, S. (2006). Performance comparison of DCOM, CORBA and Web Service. Obtenido el 20 de Febrero de 2008 de http://iec.cugb.edu.cn/WorldComp2006/PDP4837.pdf
Krafzig, D., Banke, K. y Slama D. (2004). Enterprise SOA: Service - Oriented Architecture Best Practices. Maryland: Pearson Education.
Lewis, G., Morris, E., Smith, D. y Simanta, S. (2008). SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment. Consultado el 18 de Septiembre de 2008 desde http://www.sei.cmu.edu/publications/documents/08.reports/08tn008.html
Lugo, M. (2000). Las bibliotecas universitarias mexicanas: apuntes para un diagnóstico. Métodos de Información, 7, 45-53.
154
Margolis, B. y Sharpe, J. (2007). SOA for the Business Developer-Concepts, BPEL, and SCA. Canada: MC Press.
Matthew, N. y Stones R. (2005). Beginning Databases with PostgreSQL. From Novice to Professional. New York, E.U.:Apress
Microsoft Corporation (2004). Understanding Service-Oriented Architecture. Obtenido el 14 de Agosto de 2009 de http://msdn.microsoft.com/en-us/library/aa480021.aspx#aj1soa_topic5
Microsoft Corporation (2009a). Configuración de enlaces proporcionados por el sistema. Obtenido el 03 de Enero de 2009 de http://msdn.microsoft.com/es-es/library/ms731092.aspx
Microsoft Corporation (2009b). Centro de desarrollo de .NET Framework. Obtenido el 21 de Abril de 2009 de http://msdn.microsoft.com/es-es/netframework/default.aspx
Microsoft Corporation (2009c). Namespace (Instrucción). Obtenido el 23 de Abril de 2009 de http://msdn.microsoft.com/es-es/library/0dx91cw5(VS.80).aspx
Misra, K. y Murthy, N. (2001). Using CGI Sripts to Develop a Generalizad On-line Timed Examination and Grading System. Obtenido el 15 de Mayo de 2008 de la base de datos de ACM.
Newcomer, E. (2002). Understanding Web Services: XML, WSDL, SOAP and UDDI. Boston, Estados Unidos : Addison-Wesley.
Newcomer, E. y Lomow G. (2004). Understanding SOA with Web Services. Maryland: Pearson Education.
Novell (2009). FAQ: General - Mono. Extraído el 04 de Enero de 2009 desde http://www.mono-project.com/FAQ:_General#Basics
Object Management Group (2008). CORBA FAQ. Consultado el 3 de Junio de 2008, de http://www.omg.org/gettingstarted/corbafaq.htm#VersionNumber Online community for the Universal Description, Discovery and Integration OASIS Standard (2008). Products UDDI. Consultado el 31 de Mayo de 2008, de http://uddi.xml.org/products Organization for the Advancement of Structured Information Standards. (2004a). Introduction to UDDI: Important Features and Functional Concepts. Consultado el 28 de Mayo de 2008, de http://uddi.xml.org/files/uddi-tech-wp.pdf
Organization for the Advancement of Structured Information Standards (2004b). UDDI Spec TC. Consultado el 31 de Mayo de 2008, de http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm
155
Organization for the Advancement of Structured Information Standards (2008a). Reference Architecture for Service Oriented Architecture Version 1.0. Obtenido el 01 de Septiembre de 2008, de http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.html
Organization for the Advancement of Structured Information Standards (2008b). SOA. Obtenido el 09 de Septiembre de 2008, de http://www.oasis-open.org/committees/tc_cat.php?cat=soa
Peiris, Ch. y Mulder, D. (2007). Pro WCF: Practical Microsoft SOA Implementation. Estados Unidos: Apress
Ponce, H., Herrera-Morales, JR. y Gutiérrez, P. (2004). SISOCOBI: Herramienta de Solicitud de Compras Bibliográficas para SIABUC basada en Web Services. Trabajo presentado en el XVII Congreso Nacional y III Congreso Internacional de Informática y Computación de ANIEI, Tepic – México.
PostgreSQL Global Development Group (2008a). PostgreSQL - About. Extraído el 25 de Noviembre de 2008 desde http://www.postgresql.org/about/
PostgreSQL Global Development Group (2009b). Npgsql adopted into the Mono Class Library. Extraído el 04 de Enero de 2009 desde http://www.postgresql.org/about/news.124
Santana, P. (2002). Aplicación de servicios Web en la reservación de libros para usuarios de SIABUC8. Trabajo presentado en el XV Congreso Nacional de Informática y Computación de ANIEI, Octubre, Guadalajara – México.
SIRSI (s.f.). Sistema de Gestión Integrada de Bibliotecas Unicorn. Consultado el 15 de Noviembre de 2007, de http://www.sirsidynix.com/Resources/Pdfs/Solutions/Products/Unicorn-es.pdf
Software Engineering Institute (2008). How do you define software architecture?. Consultado el 21 de Mayo de 2008, de http://www.sei.cmu.edu/architecture/definitions.html
Sommerville, I. (2005). Ingeniería de Software, 7ª Edición. Madrid: Pearson Educación. Sun Microsystems (2007). The WSIT Tutorial. Obtenido el 07 de Enero de 2009, de http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html
Tari, Z. y Bukhres, O. (2001). Fundamentals of Distributed Object Systems. The CORBA Perspective. Estados Unidos: John Wiley & Sons. Universidad de Colima (2006). ISIS-MEXICO. Consultado el 3 de Noviembre de 2007, en http://isis-mexico.ucol.mx/
VMware Inc. (2009). VMware Workstation. Consultado el 4 de Junio de 2009, en http://www.vmware.com/products/ws/
156
Weerawarana, S., Curbera, F., Leymann, F., Storey, T. y Ferguson, D. (2005). Web Services Platform Architecture: SOAP, WSDL, Ws-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More. Estados Unidos : Pearson Education.
World Wide Web Consortium (2007a). SOAP Version 1.2. Consultado el 15 de Mayo de 2008, de http://www.w3.org/TR/soap12-part1/
World Wide Web Consortium (2007b). Web Services Description Working Group. Consultado el 24 de Mayo de 2008, de http://www.w3.org/2002/ws/desc/
World Wide Web Consortium (2004). Web Services Glossary. Obtenido el 17 de Junio de 2008 de http://www.w3.org/TR/ws-gloss/
Wrigth, M. y Reynolds, A. (2009). Oracle SOA Suite Developer’s Guide. Reino Unido: Publishing Ltd.
157
Anexos Cuestionario de evaluación de ABCSIS
Carrera cursada: _______________________________________Género: M ( ) F ( ) Instrucciones: El presente cuestionario tiene como finalidad conocer la satisfacción en la implementación de la arquitectura ABCSIS. Por favor, marque con una X el número que más se acerque a su elección, siendo el número 5 el valor que representa el mayor grado de satisfacción, mientras que 1 representa el menor grado. 1.- ¿Tienes experiencia en programación Web?
Si tengo experiencia 5 4 3 2 1 No tengo experiencia 2.- ¿Conoces el paradigma de los servicios Web y los protocolos en los que se fundamenta?
Si lo conozco 5 4 3 2 1 No lo conozco 3.- ¿La arquitectura de ABCSIS te resulto fácil de configurar?
Fácil 5 4 3 2 1 Difícil 4.- ¿El proceso de instalación de ABCSIS fue fácil comparado con la instalación del CGI?
Fácil 5 4 3 2 1 Difícil 5.- ¿La documentación de ABCSIS comparada con la del CGI fue buena?
Buena 5 4 3 2 1 Mala 6.- ¿Cómo te resulto el proceso de configuración del CGI?
Fácil 5 4 3 2 1 Difícil 7.- ¿Consideras que con la arquitectura ABCSIS seria factible la interconexión de SIABUC con otros sistemas administrativos o escolares de tu institución?
Muy factible 5 4 3 2 1 Nada factible 8.- ¿En términos generales como consideras esta nueva implementación para SIABUC?
Buena 5 4 3 2 1 Mala
Gracias por tu participación!!!
158
Glosario Back-end Es la parte que procesa los datos que el usuario introdujo. Se caracteriza por estar oculto al usuario. Business Process (Proceso de negocio) Es un conjunto de medidas vinculadas o actividades que en su conjunto resultan de un negocio específico, ya sea interno o externo a la organización. Documentar los procesos de negocio incluye la descripción de lo que se hace, por qué se hace, cómo se hace, que (o qué sistema) lo hacen, así como qué tan bien se hace. Business Services (Servicios de negocio) Servicios preconstruidos basados en las políticas y mejores prácticas de la industria. Son únicos y proveen un valor de alto nivel. Consumer (Consumidor) Son los clientes que accedan a los servicios. Choreography (Coreografía) Define la secuencia y condiciones bajo las cuales múltiples agentes independientes cooperan para intercambiar mensajes con el fin de alcanzar un objetivo. Framework Grupo de tareas relacionadas para administrar un programa o proyecto de SOA. Governance (Governabilidad) Define el modelo para asegurar la óptima reutilización de servicios y la ejecución de políticas corporativas (diseño de negocio, diseño técnico y aplicación de seguridad) Granularity (Granularidad) Modularidad de un servicio. El nivel de detalle de un servicio. Mainframes Es una computadora grande, potente y costosa utilizada principalmente por una gran compañía para el procesamiento de una gran cantidad de datos; por ejemplo, para el procesamiento de transacciones bancarias. MARC MARC es el acrónimo de MAchine Readable Cataloging. Define el formato de datos que surgió como iniciativa de la Biblioteca del Congreso de los Estados Unidos. Provee el mecanismo mediante el cual las computadoras intercambian, usan e interpretan la información bibliográfica. Middleware Software para ejecutar una conversión, interpretación, consolidación e integración en nombre de las aplicaciones de negocio. OPAC Siglas de catálogo público de acceso en línea. Es una interfaz para la consulta de material bibliográfico de una biblioteca.
159
Orchestration (Orquestación) Es la secuencia y la prestación de servicios adicionales para procesar datos. Definición de las reglas para el flujo de servicios en un proceso. Provider (Proveedor) Es el creador de los servicios. Registry (Registro) Base de datos con la información de los servicios disponibles, no incluye los servicios físicamente. Repository (Repositorio) Base de datos con la información de los servicios disponibles.
![Universidad de Colima “ANÁLISIS, DISEÑO Y …digeset.ucol.mx/tesis_posgrado/Pdf/Carlos_Alberto_Perez_Ovando.pdf · Los dispositivos computacionales móviles de bolsillo [Butler2001]](https://img.pdfslide.es/doc/110x75/5bad0dc209d3f29b4f8ce3de/universidad-de-colima-analisis-diseno-y-los-dispositivos-computacionales.jpg)
