web services siabuc9
TRANSCRIPT
-
Universidad de Colima Facultad de Telemtica
ABCSIS: ARQUITECTURA BASADA EN COMPONENTES DE SOFTWARE PARA LA INTEGRACIN DE SERVICIOS
TESIS
Que para obtener el grado de MAESTRO EN COMPUTACIN
PRESENTA: ING. HUGO CSAR PONCE SUREZ
ASESORES: M. en C. JOS ROMN HERRERA MORALES
D. en C. PEDRO DAMIN REYES
COLIMA, COLIMA. NOVIEMBRE DE 2009
-
II
NDICE
Resumen .................................................................................................................... 1 Abstract...................................................................................................................... 2 1. Introduccin........................................................................................................... 3
1.1 Antecedentes ................................................................................................ 3 1.2 Descripcin del problema.............................................................................. 5 1.3 Hiptesis ....................................................................................................... 6 1.4 Objetivos ....................................................................................................... 6 1.5 Alcances y Limitaciones................................................................................ 7 1.6 Descripcin general de ABCSIS ................................................................... 8 1.7 Metodologa .................................................................................................. 9 1.8 Estructura del documento de la tesis .......................................................... 10
2. Antecedentes....................................................................................................... 11
2.1 Marco Histrico................................................................................................ 11 2.2 Marco Contextual............................................................................................. 17
2.2.1 Los sistemas de automatizacin 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 Terico....................................................................................................... 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 tecnologa 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 Aplicacin.................................................................................................. 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 Diseo arquitectnico ...................................................................................... 78 4.2.1 Arquitectura ABCSIS................................................................................. 80 4.2.2 Entorno de Comunicacin ......................................................................... 82 4.2.3 Motor de datos y estructura de la base de datos ...................................... 83 4.2.4 Comunicacin con la base de datos.......................................................... 85 4.2.5 Descripcin de mdulos y componentes................................................... 88
5. Desarrollo de ABCSIS ......................................................................................... 99
5.1 Creacin del servicio...................................................................................... 106 5.2 Hosting del servicio........................................................................................ 112 5.3 Implementacin del prototipo......................................................................... 116
6. Pruebas .............................................................................................................. 125
6.1 Prueba de operacin...................................................................................... 126 6.1.1 Resultados .............................................................................................. 130
6.2 Prueba de rendimiento................................................................................... 133 6.2.1 Resultados .............................................................................................. 140
7. Resultados y conclusiones .............................................................................. 147
7.1 Anlisis 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. Evolucin 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. Representacin 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. Interaccin de los nodos en la ruta SOAP.. 51 Figura 14. Localizacin 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-relacin para la reservacin de un ejemplar. 85 Figura 21. Parmetros de conexin a la base de datos PostgreSQL... 86 Figura 22. Conexin al servidor de PostgreSQL.. 87 Figura 23. Servicios y operaciones de ABCSIS 88 Figura 24. Operacin para hacer reservaciones.. 89 Figura 25. Operacin para buscar un alumno en la base de datos... 89 Figura 26. Operacin para buscar una ficha bibliogrfica en la base de datos... 90 Figura 27. Operacin para obtener la disponibilidad de un ejemplar 90 Figura 28. Operacin para registrar un usuario en la base de datos 92 Figura 29. Operacin para verificacin de no adeudos... 92 Figura 30. Operacin para mostrar las multas pendientes por saldar.. 93 Figura 31. Operacin para obtener los prstamos pendientes.. 93 Figura 32. Operacin para renovar ejemplares 94 Figura 33. Operacin para obtener los prstamos de un usuario. 94 Figura 34. Operacin para obtener listado de escuelas.. 95 Figura 35. Operacin para registrar una inconformidad.. 95 Figura 36. Operacin para listar las quejas pendientes por atender. 96 Figura 37. Operacin para responder una inconformidad.. 96 Figura 38. Operacin para hacer sugerencias de compras bibliogrficas... 97 Figura 39. Operacin para emitir comentarios sobre ttulos consultados. 97 Figura 40. Interoperabilidad entre varios sistemas operativos... 100Figura 41. Modelo de programacin de WCF... 102Figura 42. Binding de ABCSIS. 107Figura 43. Servicio Acervo 107Figura 44. Definicin del contrato de datos... 108Figura 45. Generacin del contrato de datos para el manejo de excepciones 109
-
V
Figura 46. Invocacin de una excepcin 110Figura 47. Definicin del servicio. 110Figura 48. Cuenta de usuario ASPNET. 112Figura 49. Creacin 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 reservacin. 116Figura 54. Archivo de configuracin de PHP. 117Figura 55. Configuracin correspondiente para el soporte de SOAP en PHP 117Figura 56. Constructor SoapClient para hacer referencia al servicio Acervo.. 118Figura 57. Invocacin de la operacin BuscarFicha 119Figura 58. Interfaz para consulta y reservacin de libros... 119Figura 59. Resultados de la consulta. 120Figura 60. Invocacin de la operacin BuscaAlumno..... 120Figura 61. Usuario no encontrado en la base de datos... 121Figura 62. Usuario vlido..... 122Figura 63. Invocacin de la operacin Reservar.. 122Figura 64. Ejemplar reservado.... 123Figura 65. Generacin de excepcin de tipo SoapFault..... 123Figura 66. Error en sentencia SQL..... 124Figura 67. Entorno de prueba con Windows XP sobre VmWare... 128Figura 68. Aplicacin utilizada en la prueba de rendimiento.. 134Figura 69. Proceso de peticin-respuesta de la prueba de rendimiento.. 135Figura 70. Cabecera HTTP enviada a la implementacin CGI.. 136Figura 71. Respuesta exitosa por parte de la implementacin CGI.. 136Figura 72. Peticin de bsqueda en ABCSIS con el mtodo POST..... 137Figura 73. Script php que recibe los parmetros enviados con el mtodo POST..
137
Figura 74. Respuesta del servidor a una peticin de bsqueda en ABCSIS... 138Figura 75. Mltiples procesos en ejecucin 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. Evolucin de la especificacin UDDI.. 55 Tabla 3. Capacidad de almacenamiento de PostgreSQL... 84 Tabla 4. Especificaciones de Address....... 102 Tabla 5. Bindings y sus caractersticas principales.. 104 Tabla 6. Operaciones de servicio utilizadas en el prototipo... 118 Tabla 7. Resultados de la encuesta aplicada en la prueba de Operacin ...................................
131
Tabla 8. Informacin de la prueba de ABCSIS con cinco eventos 141 Tabla 9. Informacin de la prueba de CGI con cinco eventos 144
-
1
Resumen
Esta tesis describe el diseo de una arquitectura de software orientada a servicios
basada en la tecnologa 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 gestin bibliotecaria. La arquitectura propuesta tiene como
finalidad ofrecer una serie de componentes para que personas con conocimientos en
programacin interesadas en extender los servicios ofrecidos por SIABUC puedan
hacerlo a partir de la funcionalidad bsica del mismo, por ejemplo desarrollar una
aplicacin Web o una aplicacin para dispositivos mviles. Entre las principales
ventajas de una arquitectura basada en servicios Web, se encuentran la herencia de
atributos, la independencia del lenguaje de programacin, sistema operativo,
transporte de red y mecanismo de almacenamiento utilizado, as como el desarrollo
eficiente, mayor reutilizacin y mantenimiento simplificado del software. La
arquitectura propuesta se encuentra conformada por 4 capas: consumidores de
servicio, arquitectura infraestructura, interfaces de servicio e implementacin del
servicio, el lenguaje de programacin que se utiliz para su desarrollo fue Visual
Basic 2008 en combinacin con el modelo de programacin Windows
Communication Foundation (WCF). Actualmente, esta arquitectura forma parte de la
ms reciente versin de SIABUC: SIABUC9.
Palabras Clave: Arquitectura de Componentes, Servicios Web, SOA, Interoperabilidad, Sistemas de Gestin 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. Introduccin En sta seccin se describen las caractersticas generales de sta tesis como los
antecedentes, descripcin del problema, hiptesis, objetivos, alcances y limitaciones,
descripcin general de ABCSIS y finalmente la metodologa utilizada para la
elaboracin de dicho trabajo.
1.1 Antecedentes
La tecnologa de cmputo distribuido ha sido desarrollada durante los ltimos 30
aos sin embargo al inicio de su desarrollo era muy cara su implementacin, no fue
sino hasta principio de 1970 cuando esto cambio con la aparicin de los mainframes,
los cuales fueron ms accesibles de adquirir (Krafzig, et al., 2004).
Durante los aos 80s y 90s la tecnologa existente permita a los equipos de
cmputo acceder a las aplicaciones de manera remota, fue entonces cuando la
ejecucin lgica 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 tecnologa
Common Object Request Broker Architecture (CORBA). La funcionalidad de CORBA
consista 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 nmero de funciones remotamente accesibles.
La evolucin del mbito distribuido cambi su rumbo a mitad de los aos 90s,
un ejemplo de ello fue el ao 1997 cuando Sun Microsystems introdujo la tecnologa
de ambiente distribuido Enterprise Java Beans (EJB) (Krafzig, et al., 2004). EJB es
similar a CORBA, una caracterstica importante de EJB es el concepto de
contenedor, que es el responsable para la administracin de recursos como objetos,
conexiones y transacciones en un servidor EJB.
Algunas tecnologas como Remote Procedure Call (RPC), CORBA, Distributed
Component Object Model (DCOM) y EJB dieron inicio al surgimiento de un gran
nmero 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 estndar para el intercambio de mensajes en
XML, la compaa Microsoft propuso la iniciativa de crear los servicios Web basados
en XML con la utilizacin del protocolo Simple Object Access Protocol (SOAP), y a su
vez, realiz un lenguaje de definicin de interfaz llamado Web Service Description
Language (WSDL) para describir la interfaz de servicio, en la actualidad esta
iniciativa forma parte de los estndares del consorcio World Wide Web (W3C)1 donde
han colaborado las empresas ms importantes e influyentes de la Web.
Con el problema de la heterogeneidad de los middleware, SOAP y WSDL
permitieron la unin de varios protocolos de comunicacin de bajo nivel, por ejemplo,
SOAP permite la comunicacin sobre un middleware existente.
El desarrollo de arquitecturas de cmputo distribuido como CORBA, DCOM,
EJB y servicios Web ha permitido la creacin de aplicaciones de gran escala, de esta
manera, proveen las bases de la Arquitectura Orientada a Servicios (SOA por sus
siglas en ingls) (Krafzig, et al., 2004).
Desde el punto de vista tecnolgico es importante contar con una arquitectura
de software que sea interoperable, escalable y que adems permita la reutilizacin
de los servicios ofrecidos a los diferentes consumidores. De tal manera que si en el
futuro se desea hacer una actualizacin al servicio prestado, no se tenga que
modificar la aplicacin completa, sino nicamente el servicio, es decir, la
independencia de los servicios. Esta es una de las ventajas de trabajar con SOA.
La utilizacin de SOA esta en aumento, segn un estudio realizado por la
empresa de investigacin tecnolgica Gartner, predijo que para el 2010 el software
de aplicacin tendr un crecimiento del 80% en sus ganancias a travs de productos
basados en SOA (Josuttis, 2007). Dentro de las ventajas que podemos mencionar
acerca de SOA destaca el desarrollo eficiente, reutilizacin de los servicios,
evolucin, interoperabilidad e independencia de los servicios.
El desarrollo de este trabajo est enfocado en la creacin de una Arquitectura
Basada en Componentes de Software para la Integracin de Servicios (ABCSIS)
1 http://www.w3.org
-
5
para el Sistema Integral Automatizado de Bibliotecas de la Universidad de Colima
(SIABUC).
1.2 Descripcin del problema
En el mbito de sistemas de informacin, particularmente en el desarrollo de
sistemas de automatizacin bibliotecaria, existen en el mercado sistemas
bibliotecarios que ofrecen desde el punto de vista de interoperabilidad, enlace a sus
mdulos 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 travs del
departamento de soporte tcnico la necesidad de realizar desarrollos
complementarios para integrarlos al sistema, de manera particular aquellos servicios
que se podran realizar de manera remota o a distancia para aprovechar el uso de
Internet, como por ejemplo: la reservacin de libros, verificacin de status,
retroalimentacin 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 aplicacin
para la consulta/reservacin de libros que interacte con un sistema propietario de
control escolar, el cual puede estar basado en un entorno Web, en un dispositivo
mvil.
La solucin 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 Integracin
de Servicios (ABCSIS). La razn de crear esta arquitectura fue para enriquecer el
software SIABUC y proveer un medio que permite conectarlo con desarrollos
propietarios. Especficamente, 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 programacin,
sistema operativo, protocolos de red y mecanismo de almacenamiento utilizado
(Newcomer, 2002). Adems, con la utilizacin de SOA se permite la utilizacin de un
rango ms amplio de interacciones de una manera ms flexible que una integracin
basada en APIs (Chen y Huang, 2006).
1.3 Hiptesis
La arquitectura ABCSIS permitir, a las instituciones que hacen uso de SIABUC y
que cuenten con personal de perfil informtico o reas afines, poder implementar
mecanismos interoperables que permitan la comunicacin con otras aplicaciones.
1.4 Objetivos 1.4.1 Objetivos Generales
Crear una metodologa 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 Especficos
Comprender el funcionamiento de los servicios Web y sus estndares XML relacionados.
-
7
Investigar acerca de la arquitectura SOA y su implementacin con los servicios Web.
Entender el funcionamiento de los conceptos de SOA en el modelo de programacin Windows Communication Foundation.
Realizar un anlisis 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 implementacin posterior.
Invocar un servicio dentro de una aplicacin prototipo.
1.5 Alcances y Limitaciones En este trabajo se realiz el diseo y creacin de servicios utilizando como
arquitectura base SOA, tomando en cuenta las reas de oportunidad ms relevantes
en SIABUC. Para fines de prueba y demostracin se cre un prototipo donde se
muestra la interaccin entre el servicio de reservacin, alojado en el servidor Web
Internet Information Server (IIS). El cliente fue desarrollado en el lenguaje de
programacin PHP, con la finalidad de demostrar la independencia entre los
lenguajes de programacin. Cuando el usuario hace una reservacin a travs del
prototipo se ve reflejada de manera automtica en el mdulo de Prstamo de
SIABUC, este mdulo es el que cotidianamente utilizan en la biblioteca para registrar
los prestamos y devoluciones de material bibliogrfico.
-
8
1.6 Descripcin general de ABCSIS
Con la utilizacin 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 podrn hacerlo de una manera
relativamente sencilla, por ejemplo, una aplicacin Web una aplicacin mvil que
incorporen la reservacin de ejemplares, consulta de disponibilidad de ejemplares,
verificacin de adeudos. Todo ello con la finalidad de proporcionar ms y mejores
servicios bibliotecarios y acercarlos a los usuarios finales de una determinada
biblioteca o centro de informacin. Cabe sealar que estas opciones se encuentran
incorporadas en la versin completa de SIABUC, pero su funcionalidad solo se
puede utilizar mediante los clientes de escritorio o aplicaciones de tipo Windows.
A continuacin, en la siguiente figura se muestra un esquema con el
funcionamiento/invocacin de un servicio mediante ABCSIS. La imagen en cuestin
est basada en la estructura de la arquitectura SOA mostrada en la seccin 3.3.2 de
este trabajo.
Figura 1. Ejemplo de funcionamiento de un servicio bajo ABCSIS
La descripcin 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
Aplicacin
Repositorio de Servicio
Contrato WSDL
Servicio
Web
-
9
Repositorio de servicios Se trata de una descripcin del servicio, la cual se encuentra en un archivo Web Service Description Language (WSDL), en este archivo
se encuentra una descripcin 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. Aplicacin Son las distintas aplicaciones que los programadores (consumidores de servicio) de las diferentes instituciones podrn realizar, en este sentido, el
programador puede realizar cualquier aplicacin que necesite.
1.7 Metodologa
Para la realizacin de este proyecto se siguieron una serie de pasos, los cuales se
describen a continuacin:
Investigacin documental Consiste en buscar informacin acerca de las tecnologas relacionadas con el
desarrollo de la arquitectura propuesta, principalmente artculos, as como
libros de actualidad, en el caso de los artculos la mayor fuente de consulta fue
la biblioteca digital ACM, as como artculos creados por empresas de
renombre como IBM, Microsoft y organismos independientes como Apache
Group, OASIS, entre otros.
Diseo de la arquitectura Elaboracin del modelo conceptual de la arquitectura propuesta, bsicamente
se genero un esquema de la arquitectura ABCSIS con el funcionamiento
propuesto.
Desarrollo del prototipo funcional Consisti en la elaboracin de una aplicacin que consume el servicio de
reservacin de libros para demostrar su funcionalidad e interoperabilidad.
Evaluacin del prototipo funcional Esta etapa consisti en realizar pruebas de operacin y pruebas de
rendimiento.
-
10
Documentacin de la investigacin Consiste en redactar el documento de la tesis.
Anlisis de los resultados obtenidos. 1.8 Estructura del documento de la tesis
Esta tesis se encuentra organizada en 7 secciones:
Seccin 1. Introduccin Se describen las caractersticas generales de esta tesis como los antecedentes, descripcin del problema, hiptesis, objetivos, alcances y
limitaciones, descripcin general de ABCSIS y finalmente la metodologa utilizada
para la elaboracin de dicho trabajo.
Seccin 2. Antecedentes Se aborda los aspectos iniciales de la tecnologa de cmputo distribuido de manera general as como la evolucin que ha tenido a lo largo
de la historia. Otro de los tpicos de este apartado es lo relacionado a los sistemas
de automatizacin bibliotecaria, SIABUC y su arquitectura, as como tambin los
trabajos relacionados a SOA y los sistemas bibliotecarios.
Seccin 3. Marco Terico Se mencionan de manera detallada los servicios Web y SOA, as como el estado actual que guardan estas tecnologas. Tambin se
mencionan las definiciones correspondientes a estos conceptos, los cuales son
utilizados en secciones posteriores.
Seccin 4. Arquitectura de ABCSIS Se aborda todo lo relacionado con el desarrollo de la arquitectura propuesta, desde el modelo conceptual hasta la descripcin de los
componentes e interfaces.
Seccin 5. Desarrollo de ABCSIS Se aborda la parte de programacin de ABCSIS, la creacin del servicio, el hosting del servicio y un prototipo funcional.
Seccin 6. Pruebas Este apartado trata sobre el empleo de pruebas de laboratorio y posteriormente se llev a cabo la interpretacin de los resultados.
Seccin 7. Conclusiones Se muestran los resultados obtenidos en las pruebas, mediante el anlisis de los mismos de forma cualitativa y cuantitativa, adems 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 tecnolgico y al bibliotecario.
2.1 Marco Histrico
La tecnologa de cmputo distribuida fue desarrollada a finales de los aos 30s.
Originalmente el cmputo de negocios significaba la utilizacin de computadoras
poderosas que costaban millones de dlares. Algunas de las primeras cosas que los
sistemas tenan para compartir entre ellos eran dispositivos como grabadoras y
sistemas de impresin. No fue sino hasta los aos 70s cuando la computadora se
hizo ms sofisticada y a un precio mucho ms accesible. Las instituciones de
investigacin rpidamente se dieron cuenta que podan operar con menos
presupuesto y de forma independiente cuando fueron capaces de utilizar
computadoras pequeas en lugar de mainframes (Krafzig, et. al., 2004).
Posteriormente, en la dcada de los 80s la Universidad de Standford
mediante un proyecto para conectar su red, dio comienzo a la creacin de la
compaa Sun Microsystems, en la actualidad esta compaa 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 diseo 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
caracterstica de impresin 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 estndar SUN-
RPC, el primer sistema que utiliz procedimientos remotos.
-
12
An cuando el cmputo distribuido se encontraba disponible en la dcada de
los 80s solamente estaba enfocado principalmente al mbito acadmico, lo cual
permaneci hasta los aos 90s. En esa poca, los equipos de cmputo accedan a
sistemas de almacenamiento e impresin. Una gran cantidad de aplicaciones
residentes en el cliente hacan peticiones de forma remota a un servidor de base de
datos. Fue entonces cuando la ejecucin lgica fue dividida entre un cliente y un
servidor de base de datos. La compaa Sybase2 por su parte, introdujo el concepto
de procedimientos almacenados, los cuales, consistan en funciones que eran
ejecutadas en la base de datos y no necesitaban enviarse al cliente.
Combinando los conceptos de las plataformas de cmputo distribuido como
Distributed Computing Environment (DCE) con el paradigma de la orientacin a
objetos, surge Common Object Request Broker Architecture (CORBA). En lugar de
proveer servidores que expusieran un gran nmero 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
abstraccin, como nombres de servicios, que se encargan de descubrir los objetos
en tiempo de ejecucin. De manera similar a la programacin orientada a objetos,
CORBA adopta el concepto de programacin de interfaces, todos los objetos de
CORBA pueden ser implementados en varios lenguajes de programacin, mientras
sus interfaces son descritas utilizando el lenguaje Interface Definition Language
(IDL). Krafzig, et al. (2004) mencionan que CORBA es ampliamente utilizado por la
tecnologa de ambiente distribuido, especialmente en telecomunicaciones y servicios
financieros.
La evolucin del mbito distribuido cambi su rumbo a mitad de los aos 90s,
tomando en consideracin 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 ao 1997. EJB es similar a CORBA, una caracterstica
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
administracin de recursos como objetos, conexiones y transacciones en un servidor
EJB. De manera similar a otras plataformas de computacin remota como DCE y
CORBA, EJB incluye un alto nivel de servicios tcnicos, como un administrador de
transacciones, llamada a servicios y seguridad.
Algunas tecnologas como RPC, CORBA, DCOM y EJB dieron inicio al
surgimiento de un gran nmero 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 tecnologa o middleware especfico, 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 integracin 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 estndares como XML Document Type Definition (DTDs) y
esquemas para la especificacin y validacin de datos complejos en XML.
Debido a la necesidad de un estndar de mensajes XML de alto nivel,
Microsoft en el ao 1998, se dio a la tarea de utilizar servicios Web basados en XML
con la creacin del protocolo Simple Object Access Protocol (SOAP). La versin
inicial de SOAP fue especficamente 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, trfico de red y administracin de aplicaciones (Krafzig, et al., 2004).
Utilizando los mtodos de peticin 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 despus, realiz un lenguaje de definicin 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 unin de varios
protocolos de comunicacin de bajo nivel, por ejemplo, SOAP permite la
comunicacin sobre un middleware existente. SOAP fue evolucionando gracias a
IBM y Microsoft hasta convertirse en una estndar en el consorcio W3C en el ao
2001.
El desarrollo de arquitecturas de cmputo distribuido como DCE, CORBA,
DCOM, EJB y servicios Web ha permitido la creacin de aplicaciones de gran escala,
de esta manera, proveen las bases de Service Oriented Architecure (SOA) (Krafzig,
et al., 2004).
El trmino servicio ha sido utilizado en diferentes contextos y propsitos.
Hubbers, Ligthart y Terlouw (2007) definen un servicio como una manera uniforme
basada en estndares 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 caractersticas funcionales
que encapsulan el concepto lgico con el que fue elaborado.
El ncleo de la orientacin a servicio esta compuesta por tres reas:
paradigmas de programacin, tecnologa distribuida y cmputo de negocio (Krafzig,
et al., 2004). Muchos de los conceptos originales encontrados en los lenguajes de
programacin han trazado su propio camino dentro de la tecnologa distribuida que
se utiliza para ofrecer acceso remoto a servicios de diferentes aplicaciones en
diferentes plataformas. Finalmente, la evolucin de cmputo 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 lgica del negocio.
En base a las definiciones anteriores de servicio y a la diversidad que existen
del mismo el trmino, se entiende por servicio al conjunto de funciones que son
encapsuladas para responder una peticin. Mientras que la lgica 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 cercana de los servicios a la funcionalidad del negocio, la
orientacin a servicio tiene el potencial para ser el primer paradigma que
verdaderamente lleve a la tecnologa 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 evolucin 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. Evolucin de la Arquitectura Orientada a Servicios
Orgenes del trmino SOA. En el ao de 1994 Alexander Pasik, un analista de la empresa Gartner, acuo el
trmino 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 trmino SOA porque la
definicin cliente-servidor haba perdido su significado clsico. Muchas industrias
haban comenzado a utilizar el trmino cliente-servidor para definir a una
computadora en un entorno distribuido. Una computadora cliente ejecutaba la
presentacin lgica de la interfaz de usuario y la mayora de la lgica del negocio.
Por su parte el servidor, almacenaba los datos en un sistema administrador de base
de datos y en ocasiones ejecutaba la lgica del negocio. En este sentido, los
trminos cliente y servidor bsicamente se referan al hardware.
Para evitar confusin entre los antiguos y los nuevos trminos cliente-servidor,
Pasik menciono que la orientacin 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 compaas como Oracle, HP, SAP y Sun
aportaron su capital para agrandar la idea y vender nuevos conceptos y
herramientas.
Tiempo despus, los analistas comenzaron a ofrecer SOA como el concepto
clave para el futuro del desarrollo de software. Por ejemplo, la empresa de
consultora e investigacin tecnolgica Gartner4 predijo que para el 2010 el software
de aplicacin tendr un crecimiento del 80% en sus ganancias a travs de productos
basados en SOA (Josuttis, 2007).
Si bien es cierto que Pasik dio forma al trmino SOA, hasta el momento no
existe un grupo, organizacin o consorcio oficial que lleve la pauta en este sentido.
Recientemente el consorcio OASIS (Organization for the Advancement of Structured
Information Standards), una organizacin dedicada al desarrollo de estndares e-
business, ha liberado un borrador de un modelo de arquitectura SOA el cual esta
diseado en el lenguaje UML 2 (OASIS, 2008a). Mientras que empresas como
Microsoft, IBM, Oracle y el Software Engineering Institute tambin cuentan con su
propio modelo de arquitectura SOA.
4 http://www.gartner.com/
-
17
2.2 Marco Contextual 2.2.1 Los sistemas de automatizacin de bibliotecas
Una de las primeras referencias en relacin a este tema data del ao 1958, fue en
este periodo cuando la Biblioteca del Congreso de los Estados Unidos comenz este
proceso y tiempo despus, en el ao 1963, gener un reporte titulado: La
automatizacin en la Library of Congress, dicho trabajo se encontraba dividido en
tres reas principales: procesamiento bibliogrfico, bsquedas bibliogrficas y
recuperacin de documentos. Posteriormente, en el ao 1965 se inici un proyecto
piloto conocido como Machine Readable Cataloging (MARC) (Brinati, 2003).
Sin embargo, el hablar de la automatizacin de bibliotecas no significa el
desplazamiento del bibliotecario, sino ms bien, la utilizacin y aprovechamiento de
la tecnologa en el sistema bibliotecolgico.
La automatizacin pues, es el uso de la computadora para realizar los
procesos que se desarrollan cotidianamente en la biblioteca; los sistemas de
automatizacin son el conjunto de programas con funciones y acciones especficas
para agilizar los procesos en las bibliotecas, siendo la biblioteca el centro activo de
investigacin e informacin en disciplinas extensas e interrelacionadas (Herrera-
Morales, et. al., 2004).
La automatizacin de bibliotecas fue un proceso difcil durante dos dcadas,
sin embargo, esto ha ido transformndose paulatinamente y fue hasta los aos 90s
cuando ste trmino se concibe como un concepto mucho ms amplio que involucra
el procesamiento de la informacin ms all de la generacin de catlogos en lnea
(Brinati, 2003).
Casi la totalidad de bibliotecas universitarias en Mxico tienen automatizada
por lo menos alguna de sus reas de trabajo, desafortunadamente son pocas las que
han logrado implementar un sistema de automatizacin integral (Lugo, 2000).
Hasta el ao 1995 los sistemas ms utilizados eran Microisis, SIABUC y
Logicat, stos dos ltimos fueron desarrollados en Mxico, el primero de ellos fue
realizado por la Direccin 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 penetracin que ha logrado
es evidente, la versin SIABUC8 es utilizada en ms de 1500 instituciones pblicas y
privadas de Mxico, Amrica Latina y el Caribe (Herrrera-Morales, 2007).
Otros sistemas utilizados son Aleph5, Alexandria6, Unicorn7, Virtua8 e
Innopac9, stos sistemas incorporan muchos rasgos tecnolgicos pero son
sumamente costosos ya que son elaborados por empresas transnacionales, por lo
que en la mayora de las ocasiones resultan inaccesibles para las bibliotecas tpicas
de instituciones latinoamericanas.
A continuacin se menciona una breve resea con algunas caractersticas de
estos sistemas:
Microisis
Este software fue creado por la Organizacin de las Naciones Unidas para la
Educacin, la Ciencia y la Cultura (UNESCO) en los aos 60s, esta basado en
archivos y no cuenta con una arquitectura mediante la cual se permita hacer algn
tipo de desarrollo adicional con la informacin almacenada. La adquisicin de este
software no tiene costo a travs de distribuidores nacionales, la Universidad de
Colima a travs del Centro Nacional de Edicin Digital y Desarrollo de Tecnologas
de Informacin (CENEDIC) es distribuidor de este sistema a nivel nacional
(Universidad de Colima, 2006).
Logicat
Este sistema fue diseado para la recuperacin de informacin en normas
internacionales. La arquitectura que posee es cerrada debido a que los servicios que
ofrece a travs de Internet estn predeterminados y se basan principalmente en el
intercambio de mensajes entre el propio sistema para establecer la comunicacin
con los usuarios finales (Grupo Sistemas Lgicos, 2007a).
Aleph
El sistema Aleph (Automated Library Expandable Program) fue desarrollado
en la dcada de los 80s en la universidad Hebrea de Jerusaln, 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 tecnologa 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 Lgicos, 2007b).
Unicorn
Sirsis Unicorn Library Management System como actualmente se le conoce a
este sistema, es desarrollado por la empresa SirsiDynix, dicho sistema administra los
servicios tcnicos y pblicos de una biblioteca. Desde sus inicios ha utilizado la
arquitectura cliente-servidor. Cuenta con una arquitectura abierta ya que provee el
acceso mediante APIs a todos los mdulos 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 combinacin con la plataforma Java. Dentro de los paquetes para
montar el acervo bibliogrfico en Web se encuentra el AirPAC, el cual es un Online
Public Access Catalog (OPAC) diseado especialmente para usuarios que buscan
informacin en el catlogo desde dispositivos mviles con acceso inalmbrico, su
arquitectura es cerrada al desarrollo ya que a diferencia de los sistemas anteriores
no provee APIs para acceder a la informacin que almacena (INNOVATIVE
Interfaces, 2006).
Hasta aqu se ha comentado los inicios de la automatizacin bibliotecaria, as
como algunos de los sistemas ms utilizados en este mbito, a continuacin se
hablar acerca de SIABUC, sus inicios, los mdulos que lo conforman, as como
tambin el impacto que ha tenido tanto en Mxico como en Latinoamrica.
2.2.2 Sistema Integral Automatizado de Bibliotecas de la Universidad de Colima (SIABUC)
Fue en el ao de 1983 cuando la Universidad de Colima incursion en el mbito
tecnolgico, durante ese ao se creo la Direccin de Desarrollo Bibliotecario, cuyo
-
20
objetivo principal fue estructurar un sistema de bibliotecas para apoyar con servicios
de informacin bibliogrfica y documentar las labores sustantivas de docencia e
investigacin en todos los campos de la Universidad, centralizando sus procesos de
adquisicin, catalogacin y clasificacin. Debido a esto surgi la necesidad de
automatizar dichos procesos y servicios de informacin (Herrera-Morales, et al.,
2004).
Para satisfacer esas necesidades se realiz un estudio de experiencias sobre
sistemas de automatizacin bibliotecaria y sus casos de xito en las bibliotecas
mexicanas, al identificar la carencia de este tipo de tecnologa informtica y el
desconocimiento por parte de los bibliotecarios se diseo SIABUC (Sistema Integral
Automatizado de Bibliotecas de la Universidad de Colima).
En aquel entonces, el objetivo principal de SIABUC era generar un fichero
electrnico que facilitara el proceso de impresin de los catlogos topogrficos 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 Tecnologa (CONACYT) y la Secretara de Educacin Pblica
(SEP), con la finalidad de obtener recursos econmicos para mejorarlo y
posteriormente ofrecerlo a las bibliotecas pblicas 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 catalogrficas, 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 ms de 2500 instituciones pblicas y privadas de Mxico,
Amrica Latina y el Caribe (Herrera-Morales, 2007).
Presencia de SIABUC en Latinoamrica La primera institucin usuaria y representante de SIABUC en Costa Rica fue la
Escuela Centroamericana de Ganadera, en 1989, en Balsa de Atenas, provincia de
Alajuela.
-
21
Durante ese mismo ao el Instituto Tecnolgico de Costa Rica inicia con el
uso de SIABUC, actualmente cuentan con la versin SIABUC8 en funcionamiento.
En la actualidad, ms de 50 bibliotecas son usuarias de SIABUC, dentro de las
instituciones ms representativas en ese pas 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,
Fundacin Omar Dengo, Sistema de Bibliotecas Pblicas de Costa Rica, Universidad
para la Paz, entre otras.
Otro pas 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
Sistematizacin de la Red Nacional de Bibliotecas Pblicas, esto con la finalidad de
que SIABUC8 fuera la herramienta de automatizacin utilizada en ms de 500
bibliotecas en aquel pas.
Mientras que en Nicaragua, la primera institucin en utilizar SIABUC fue la
UNAN-Len de Nicaragua y posteriormente la Universidad Centroamericana (UCA).
Actualmente son 42 las instituciones que tienen convenio firmado con la Universidad
de Colima para la utilizacin de SIABUC.
Mxico por su parte no se queda atrs, 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 Mxico, Centro de
Investigacin en Matemticas, Instituto Nacional de Astrofsica ptica y Electrnica,
Universidad Autnoma de Guadalajara, Congreso del Estado de Michoacn, Hospital
General de Mxico, Universidad del Valle de Atemajac, Universidad Autnoma
Chapingo, Museo de Historia Mexicana, Congreso del Estado de Morelia, INEGI
entre otras ms.
Mdulos que integran SIABUC SIABUC a diferencia de otros sistemas de automatizacin bibliotecaria es un sistema
-
22
integral, es decir, est conformado por varios mdulos de manera conjunta y no
separados como otros sistemas, a continuacin se describe una breve resea de los
mdulos que conforman SIABUC:
Adquisiciones: Mediante este mdulo es posible llevar a cabo un control de los presupuestos, compras, pedidos, recepciones, donaciones y facturas, as
como tambin permite llevar a cabo la asignacin de folios de los libros
nmeros de inventario.
Anlisis: En este apartado se puede llevar a cabo la catalogacin o descripcin 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 bsqueda en el acervo bibliogrfico.
Estadsticas: Mediante esta aplicacin se puede obtener informacin concentrada sobre los procesos y tareas ms importantes llevadas a cabo
con SIABUC.
Prstamos: Con este mdulo es posible llevar a cabo los procesos de circulacin o prstamo del material bibliogrfico, incluye una serie de
herramientas para ayudar en esta labor as como una serie de reportes.
Publicaciones: El objetivo principal de este mdulo es el de registrar, administrar y controlar el material hemerogrfico como: revistas, peridicos,
boletines, gacetas y en general cualquier publicacin seriada de divulgacin
constante.
Consultas: Este mdulo reemplaza a los ficheros de consulta tradicionales, permite que los usuarios exploren el acervo de la biblioteca de una forma
rpida y sencilla. Se pueden hacer bsquedas simples as como tambin
bsquedas avanzadas utilizando los operadores bolanos.
Inventarios: La finalidad que pretende este mdulo es la de comparar lo que existe fsicamente en el acervo contra lo que se tiene capturado en la base
de datos de SIABUC.
Servicios: Con este mdulo se puede llevar a cabo el prstamo y control de los espacios (cubculos, salas de lectura) y equipos de cmputo que se
-
23
utilizan en las salas de consulta o de acceso a Internet de la biblioteca.
Adems de estos mdulos cuenta con dos componentes adicionales para
montar los registros bibliogrficos en Internet, uno de ellos hace uso de la tecnologa
Common Gateway Interface (CGI) y es llamado WebS8, mientras que el segundo
componente es una interfaz API, la cual se puede utilizar en combinacin con
tecnologas como PHP y ASP. Estos componentes se describen a fondo en la
siguiente seccin.
2.2.2.1 Arquitectura Actual de SIABUC
La arquitectura actual de SIABUC para la prestacin del servicio de consulta a travs
de Internet es cerrada tal como se puede apreciar en la figura 3, se encuentra
basada en la API WebS8dll en la implementacin CGI WebS8. El objetivo principal
de estas dos aplicaciones es la de recuperar la informacin bibliogrfica a travs de
Internet utilizando las plataformas de Microsoft Windows.
En el departamento de soporte tcnico de SIABUC los usuarios han externado
la necesidad de incorporar nuevas funcionalidades a SIABUC aparte de la consulta
Web, por ejemplo la reservacin, 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: aplicacin 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 Aplicacin
Capa de Acceso a Datos
API WebS8dll / CGI
-
24
La capa de acceso a datos esta integrada por el motor Microsoft Access en su
versin 2000, mientras que la capa de aplicacin esta conformada por la API
WebS8dll por el componente CGI.
A continuacin, en los siguientes apartados se menciona con detalle lo
concerniente a la capa de aplicacin de SIABUC8.
2.2.2.2 CGI WebS8
Common Gateway Interface (CGI) es una de las tecnologas estndar que provee el
paso de informacin entre el servidor y los clientes (explorador Web), las
aplicaciones CGI pueden ser escritas en cualquier lenguaje de programacin como
Shell, C, C++, FORTRAN, Java. Sin embargo, Shell, Perl y C son los ms utilizados
para desarrollar este tipo de aplicaciones (Misra y Murthy, 2001).
SIABUC utiliza la tecnologa CGI para implementar las consultas del acervo a
travs del Web, el ncleo de la implementacin es una aplicacin llamada
WebS8.exe.
Para montar las consultas en Web, adems del WebS8 se requiere de un
servidor Web, una pgina de consultas, un archivo de configuracin para los
parmetros 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 continuacin:
- Compatible con sistemas operativos Microsoft Windows
- Compatible con CGI versin 1.1 en adelante
- Debe admitir la ejecucin de programas de 32 bits
Los acervos que se pueden consultar son los que corresponden a los libros y
las revistas.
La aplicacin WebS8 est realizada con el lenguaje de programacin Visual
Basic 6, sin embargo dicha aplicacin se entrega al usuario compilada, sin que este
pueda hacer modificacin alguna.
-
25
La tecnologa CGI fue una de las primeras en permitir contenido dinmico, sin
embargo, ha sido sustituida por tecnologas script como PHP, JSP ASP.
En la actualidad, debido a los ataques de virus en los equipos de cmputo, los
sistemas operativos como Windows han implementado mayores medidas de
seguridad, dichas medidas afectan la correcta ejecucin de las aplicaciones CGI,
debido a esto, el departamento de SIABUC se dio a la tarea de realizar una nueva
implementacin para montar los catlogos en Internet y estar a la vanguardia con
estas nuevas tecnologas y tendencias, esta nueva implementacin 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 Programacin de Aplicaciones, por la cual una aplicacin
(servidor) expone su interfaz grfica de usuario (UI) y contenido a otra aplicacin
(cliente) (Gonzlez 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 mdulos de SIABUC, por ejemplo, la implementacin de los catlogos de
consulta al acervo va Web utilizando tecnologas script como PHP o ASP (Herrera-
Morales, 2006).
La API WebS8DLL esta conformada por un conjunto de cdigo encapsulado
que contiene principalmente funciones y mtodos, los cuales hacen posible la
conexin a la base de datos de SIABUC, el objetivo de esta API es realizar
bsquedas en el acervo bibliogrfico y visualizar informacin seleccionada en
diferentes formatos preestablecidos (Herrera-Morales, 2006).
Para emplear esta API es necesario utilizar la plataforma de cmputo
adecuada que soporte la correcta instanciacin de componentes ActiveX, debido a
que la API est desarrollada bajo esta tecnologa propietaria de Microsoft solo es
posible implementarla bajo sistemas operativos Microsoft Windows.
El lenguaje de desarrollo recomendado para implementarla es ASP en
-
26
combinacin con el servidor Web Internet Information Server (IIS) de Microsoft, sin
embargo, tambin es posible utilizarla con el lenguaje de programacin PHP.
Actualmente, existe una nueva versin de SIABUC llamada SIABUC9, esta
nueva versin permiti la reestructuracin del sistema y la incorporacin de un nuevo
motor de base de datos, PostgreSQL. Debido a esto, tambin fue factible la creacin
de un nuevo esquema de arquitectura para utilizarla en conjunto con esta nueva
versin de SIABUC.
-
27
2.3 Trabajos Relacionados
Esta seccin presenta el trabajo relacionado para resolver los problemas de
integracin de sistemas legados, as como tambin la integracin 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
creacin, ya que bsicamente SOA ha sido una evolucin de la manera en la que se
comunican los sistemas computacionales en ambientes heterogneos.
Dentro de los aportes de SOA se encuentra la de resolver la problemtica de
los sistemas legados, este tipo de sistemas son difciles de mantener y se necesita
personal capacitado y experto en esta rea para su administracin (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 tecnologas como
servicios Web o encapsulamiento de cdigo, por ejemplo, el realizado en el ao 2002
por Santana (2002) en el que se integran los servicios de consulta de material
bibliogrfico utilizando la plataforma .NET como herramienta de desarrollo,
desafortunadamente no se le dio seguimiento al proyecto y no se logr implantar.
Adems de este trabajo existe otro similar, una herramienta llamada Sistema de
Solicitudes de Compra Bibliogrfica (SISOCOBI) cuyo objetivo fue ayudar en el
proceso de compra de bibliografa, bsicamente consiste en consumir los servicios
Web desarrollados por la compaa estadounidense Amazon y obtener la
informacin 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 ao 2006 por Chen. y Huang (2006) la cual consista de un agente que
soportaba reconfiguracin dinmica para mdems 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 administracin de sistemas
basados en SOA.
Otro caso de xito de la implementacin de SOA esta presentado en un
sistema de aerolneas, donde se redujo el costo de transacciones y de operacin
respecto a otra forma de implementacin basada en tecnologa 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 razn 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 institucin 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 Terico En ste apartado se mencionan las tecnologas que dieron inicio al desarrollo de los
Servicios Web, SOA, su estado actual y las definiciones de stos trminos, las cuales
son utilizadas en secciones posteriores.
3.1 Arquitecturas Iniciales
En un principio, los programas estaban creados solamente por instrucciones binarias,
razn por la cual, esta propuesta de programacin demostr ser lenta y difcil para
las personas, ya que deban memorizar grandes cadenas de caracteres en formato
binario.
A finales de 1950 comenz la investigacin en el rea de programacin
automatizada de sistemas, este enfoque permita a los programadores desarrollar
aplicaciones en una codificacin de alto nivel que eran fcilmente interpretadas por la
computadora (Albin, 2003).
Durante la dcada de los 80s tambin hubo un cambio en el diseo de
aplicaciones, cambiaron del simple texto a interfaces grficas de usuario (GUI). Sin
embargo, fue hasta final de esa dcada y principios de los aos 90s cuando el
trmino arquitectura de software comenz a mostrarse en la literatura.
Intentar definir un trmino como arquitectura de software es una tarea que en
algunas ocasiones causa polmica, debido a que existe una gran diversidad de
opiniones en torno a este trmino. Un ejemplo claro de esto, se puede encontrar en
la pgina de Instituto de la Ingeniera 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 prctica recomendada para la organizacin de un
sistema, contiene componentes y sus relaciones con otros en el entorno, as como
los principios que gobiernan su diseo y evolucin (Gorton, 2006). A continuacin, en
los siguientes apartados se describen las arquitecturas iniciales en el mbito
distribuido que marcaron la pauta para la generacin de lo que en la actualidad se
conoce como servicios Web.
-
30
3.1.1 CORBA
Las tecnologas de objeto distribuido son un miembro importante de la familia de los
middleware. Los middleware proveen un medio de comunicacin para conectar
varios componentes de software en una aplicacin con la finalidad de intercambiar
informacin en ambientes heterogneos (Gorton, 2006).
CORBA es el acrnimo de Common Object Request Broker Architecture, el
cual, es un estndar adoptado por la Object Management Group (OMG) para permitir
la interoperabilidad entre aplicaciones heterogneas en entornos distribuidos
heterogneos, sin importar el lugar donde se encuentren ubicados (Tari y Bukhres,
2001).
OMG es un grupo formado en el ao de 1989 por varias compaas, 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
programacin en red, esta automatizacin de funciones es hecha a travs de un
intermediario llamado Object Request Broker (ORB). El ORB es ejecutado en el host
y maneja de forma transparente los mensajes de peticin entre el cliente y el
servidor. La transparencia se refiere al hecho de que los clientes no necesitan
conocer donde se encuentran los servidores. Adems de esto, el ORB provee
servicios comunes como el envo de mensajes y comunicacin 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 travs de la
Interfaz CORBA
Cliente
IIOP
ORB
Interfaz CORBA
Servidor
IIOP
ORB
-
31
interfaz CORBA. Los clientes hacen una peticin de enlace a un ORB local a travs
de la interfaz CORBA. Si el objeto existe en la computadora local, el ORB activa
localmente el objeto que procesa la peticin. En caso contrario, el ORB hace una
peticin a otro ORB conectado en la red utilizando el protocolo Internet Inter ORB
Protocol (IIOP) sobre TCP. Despus de enlazar el objeto apropiado, el ORB cliente
enva una peticin al ORB que se encuentra en el servidor (Kim y Han 2006).
Un objeto CORBA esta conformado por dos componentes: la interfaz y la
implementacin; la interfaz no est vinculada a un lenguaje de programacin
especfico, 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
travs del cual todas las aplicaciones de CORBA son definidas.
CORBA en conjunto con el IDL fueron creados por la OMG en el ao de 1991,
en las versiones iniciales, la OMG se enfoc en la especificacin de la parte central
de CORBA, el ORB. Mientras que en la versin actual, la especificacin 3.0,
agregaron nuevas dimensiones y tres categoras principales: integracin 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
especificacin completa de CORBA. La especificacin 2.0 se refiere a la
interoperabilidad de CORBA y el protocolo IIOP, mientras que la especificacin 3.0
se refiere al modelo de componentes de CORBA (Object Management Group, 2008).
Otra alternativa para resolver el problema de integracin en entornos
distribuidos es Microsoft Distributed Componente Object Model (DCOM). A
continuacin se describe esta tecnologa.
-
32
3.1.2 DCOM
Distributed Component Object Model por su acrnimo en ingls, es un middleware
desarrollado por Microsoft que provee una estructura basada en un modelo orientado
a objetos, bsicamente es la versin extendida de Component Object Model (COM)
(Tari y Bukhres, 2001).
COM es un componente de software que promueve la reutilizacin
permitiendo que aplicaciones y sistemas sean construidos a partir de componentes
binarios.
DCOM naci a mediados de los aos 80s como Dynamic Data Exchange
(DDE), un protocolo de comunicacin diseado por Microsoft que permita a las
aplicaciones intercambiar mensajes mediante la memoria compartida. Tiempo
despus 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 orientacin a
objetos. Una aplicacin DCOM comprende un conjunto de objetos que proveen los
servicios de aplicacin va mtodos de esos objetos.
Debido a que Microsoft es el nico propietario de esta tecnologa, 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 travs 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 comunicacin. Por su parte, la pila de protocolos del lado del servidor
recibe la peticin, la entrega al COM runtime y posteriormente procesa la peticin
(Kim y Han, 2006).
DCOM evita que el programador escriba cdigo complejo, tambin se encarga
de todas las comunicaciones entre las mquinas.
-
33
Figura 5. Arquitectura DCOM
DCOM y CORBA estn basados en el modelo de orientacin 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, libreras y redes de una manera bien definida. CORBA fue diseado
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 programacin, mediante esta capa
ejecutan el manejo de excepciones (Tari y Bukhres, 2001).
Una desventaja de esta tecnologa es que solamente es soportado por el
sistema operativo Windows de Microsoft y no puede ser utilizada en la mayora de
los entornos Web (Kim y Han, 2006).
La aplicacin central de las tecnologas remotas como RPC, CORBA, DCOM y
Enterprise Java Beans (EJB) propiciaron el surgimiento de un gran nmero de
soluciones basadas en middleware. Sin embargo, el surgimiento de estas soluciones
presento un problema, la heterogeneidad de aplicaciones, para hacer frente a esta
problemtica surgi el XML, el cual se hizo presente a mitad de los aos 90s 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 tecnologa 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
especfico, en la actualidad es utilizado como un formato de procesamiento de datos
multiplataforma. El XML es utilizado ampliamente en la creacin de los servicios
Web, su principal funcin es la definicin 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 tecnologa 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
computacin distribuida necesita ser adaptado. Primero, el Internet esta bsicamente
desconectado, las conexiones son transitorias y temporales. Los servicios de
computacin distribuida como seguridad y transacciones, tradicionalmente dependen
de una conexin 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 bsicas. Para los servicios Web esto
significa que cualquier cliente puede acceder a los servicios Web publicados por
cualquier otro, tanto tiempo como la informacin del servicio este disponible,
entendible y los procesadores XML sean capaces de generar mensajes (Newcomer,
2002).
Las tecnologas tradicionales de cmputo distribuidas asumen de una manera
ms acoplada las relaciones entre un cliente y un servidor. Debido a que los servicios
Web adoptan el modelo de publicacin en Internet, es posible encapsular y publicar
un punto final especfico o una operacin, usando la definicin 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 travs de la red, transportando grandes cantidades de datos de una
manera eficiente y a bajo costo. El resultado obtenido es: velocidad y mejor
comunicacin.
El Internet comenz soportando interacciones de manera textual y grfica, al
inicio, las personas lo utilizaban para cotizar productos, comprar, leer las noticias,
entre otras cosas (Newcomer, 2002). Este nivel de interaccin era bueno para
diferentes propsitos, pero, las aplicaciones basadas en texto no soportaban muy
bien la interaccin de software, especficamente la transferencia de una gran
cantidad de datos. Era necesario pues, un mtodo ms eficiente para permitir a las
aplicaciones interactuar directamente con otras.
Los servicios Web mejoraron el uso de Internet facilitando la comunicacin
programa a programa. A travs de la adopcin extendida de los servicios Web, las
-
36
aplicaciones en varios lugares podan ser integradas e interconectadas como si
fueran parte de una misma aplicacin
Existen varios conceptos para definir a los servicios Web, el World Wide Web
Consortium (2004) los define como sistemas de software diseados 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 enva una peticin a
un servicio Web a travs de la red y puede o no recibir una respuesta, si se obtiene
una respuesta, esta tambin debe tener la estructura de un mensaje XML.
Mientras que Guruge (2004) los define como un nuevo tipo de programacin
orientada a objetos en el Web. Son componentes de software modulares,
independientes y autodescriptibles que estn disponibles en la red.
Como se pudo observar en las definiciones anteriores todas coinciden en la
utilizacin de mensajes para el intercambio de informacin 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 continuacin, en la figura 6, se representa la comunicacin que se lleva a
cabo en los servicios Web.
Figura 6. Representacin de un servicio Web
La computadora A necesita comunicarse con otra computadora B, ambas con
plataformas y lenguajes de programacin diferentes, la comunicacin 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 comunicacin en
combinacin con XML.
Esta tecnologa puede ser utilizada de muchas maneras, se puede ejecutar en
un ambiente tipo escritorio, as como tambin en clientes porttiles para acceder, por
ejemplo, a un sistema de reservaciones por Internet, tambin pueden ser utilizados
para conectar aplicaciones que se ejecuten en varias organizaciones de una misma
cadena en un entorno empresarial, entre otras aplicaciones ms. Una de las ventajas
que tiene esta tecnologa es que puede resolver el problema de la integracin de
aplicaciones empresariales (EAI Enterprise Application Integration), conectando
mltiples aplicaciones de una organizacin simple a una mltiple, tanto dentro como
fuera de un firewall.
Los servicios Web proveen un mecanismo de modernizacin 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 programacin sistema operativo.
En la actualidad, la mayora 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 programacin en la pgina de
Google, la cadena de bsqueda ser similar a la que se muestra a continuacin:
http://www.google.com/search?q=libros+programacion&btnG=Google+Search
XML provee varias ventajas para transmitir datos a travs de Internet, como
por ejemplo, perfeccionamiento de los datos, mayor flexibilidad y extensibilidad. La
misma bsqueda utilizando un mensaje de servicio Web quedara 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 peticin de servicio y los parmetros
de entrada toman la forma de elementos XML. El ejemplo tambin ilustra el uso de
los XML namespace (xmlns), otro elemento importante de los servicios Web.
El nivel de abstraccin en el que los servicios Web trabajan, abarca los estilos
de emulacin como RPC, mensajes asncronos, mensajes en un solo sentido,
broadcast y publicacin/suscripcin. La mayora de los sistemas de administracin de
base de datos como Oracle, SQL Server y DB2 soportan el parseo y transformacin
de servicios, permitiendo la interaccin directa entre los servicios Web y los sistemas
de bases de datos.
programacion libros visual basic
-
39
La tecnologa 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 mtodo o una
llamada a un procedimiento asociado a los parmetros de entrada salida. En
contraste con la interaccin orientada a documento, la orientacin RPC enva un
documento formateado especficamente para ser estructurado en un programa o
base de datos. La caracterstica principal de esta tecnologa es que una vez enviado
el mensaje de peticin se espera un mensaje de respuesta.
Por otra parte, la interaccin 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 ejecucin 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 programacin en
particular
Se auto describa utilizando la gramtica del XML Se pueda localizar fcilmente a travs de un mecanismo simple
3.2.1 La tecnologa de los servicios Web
Los programas que interactan 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 tecnologas existentes y estndares
propuestos, pero otros no. La infraestructura de los servicios Web estn siendo
diseados 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
tecnologas, no reemplazan una tecnologa existente. Por ejemplo, se podra 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 an se encuentran en nuestro entorno (Newcomer, 2002).
Los programadores deben tomar en cuenta a los servicios Web cuando
disean y desarrollan nuevos programas y bases de datos, pero esos programas y
bases de datos sern requeridos detrs del encapsulamiento de los servicios Web.
Los servicios Web no son programas ejecutables, sino que se encuentran
dentro de programas de aplicacin y scripts. Requieren de varias tecnologas
basadas en XML para transportar y transformar datos dentro y fuera de programas y
bases de datos, dichas tecnologas 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 descripcin de datos, puede ser utilizado con
cualquier tipo de datos, independientemente del tipo que se trate (Guruge, 2004).
Todos los parmetros 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 gua 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
ideologa entorno a los lenguajes de marcado, la mayora de ellos ha evolucionado
del Standard Generalizad Markup Language (SGML) que fue desarrollado por IBM
en los aos 80s (Guruge, 2004).
-
41
HTML es el lenguaje de etiquetas electrnicas ms conocido y utilizado, esta
compuesto por un conjunto de etiquetas previamente definidas y es considerado
como el primer lenguaje de etiquetas de marcado (Guru