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