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... 100
Figura 41. Modelo de programacin de WCF... 102
Figura 42. Binding de ABCSIS. 107
Figura 43. Servicio Acervo 107
Figura 44. Definicin del contrato de datos... 108
Figura 45. Generacin del contrato de datos para el manejo de excepciones 109
V
Figura 46. Invocacin de una excepcin 110
Figura 47. Definicin del servicio. 110
Figura 48. Cuenta de usuario ASPNET. 112
Figura 49. Creacin de un directorio virtual en IIS... 113
Figura 50. Directorio virtual y archivos del servicio Acervo. 113
Figura 51. Servicio Acervo hospedado en IIS... 114
Figura 52. WSDL del servicio Acervo. 115
Figura 53. Diagrama de flujo para la reservacin. 116
Figura 54. Archivo de configuracin de PHP. 117
Figura 55. Configuracin correspondiente para el soporte de SOAP en PHP 117
Figura 56. Constructor SoapClient para hacer referencia al servicio Acervo.. 118
Figura 57. Invocacin de la operacin BuscarFicha 119
Figura 58. Interfaz para consulta y reservacin de libros... 119
Figura 59. Resultados de la consulta. 120
Figura 60. Invocacin de la operacin BuscaAlumno..... 120
Figura 61. Usuario no encontrado en la base de datos... 121
Figura 62. Usuario vlido..... 122
Figura 63. Invocacin de la operacin Reservar.. 122
Figura 64. Ejemplar reservado.... 123
Figura 65. Generacin de excepcin de tipo SoapFault..... 123
Figura 66. Error en sentencia SQL..... 124
Figura 67. Entorno de prueba con Windows XP sobre VmWare... 128
Figura 68. Aplicacin utilizada en la prueba de rendimiento.. 134
Figura 69. Proceso de peticin-respuesta de la prueba de rendimiento.. 135
Figura 70. Cabecera HTTP enviada a la implementacin CGI.. 136
Figura 71. Respuesta exitosa por parte de la implementacin CGI.. 136
Figura 72. Peticin de bsqueda en ABCSIS con el mtodo POST..... 137
Figura 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... 138
Figura 75. Mltiples procesos en ejecucin en la modalidad CGI..... 139
Figura 76. Menor cantidad de recursos utilizados por el prototipo ABCSIS.... 140
Figura 77. Promedio de la prueba de ABCSIS con cinco eventos.... 141
Figura 78. Promedio de la prueba de ABCSIS con cincuenta eventos.... 142
Figura 79. Promedio de la prueba de ABCSIS con quinientos eventos... 143
Figura 80. Promedio de la prueba de ABCSIS con cinco mil eventos...... 143
Figura 81. Promedio de la prueba CGI con cinco eventos..... 144
Figura 82. Promedio de la prueba CGI con cincuenta eventos..... 145
Figura 83. Promedio de la prueba CGI con quinientos eventos.... 145
Figura 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 Sybase
2
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 Microsystems
3
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 Gartner
4
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 Aleph
5
, Alexandria
6
, Unicorn
7
, Virtua
8
e
Innopac
9
, 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
DCE
RPC
Pila de protocolos
Servidor
COM runtime
Proveedor de
Seguridad
DCE
RPC
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.
<SOAP-ENV:Body>
<s:SearchRequest xmlns:s=www.xmlbus.com/SearchService>
<p1>programacion</p1>
<p2>libros</p2>
<p3>visual basic</p3>
</s:SearchRequest>
</SOAP-ENV:Body>
39
La 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 (Guruge, 2004).
A diferencia de HTML, el XML no es un lenguaje de etiquetas verdadero, esto
debido a que no cuenta con etiquetas definidas. XML es un lenguaje de meta-
marcado, el cual, permite crear etiquetas personalizadas para cubrir necesidades
especficas, esto comnmente es conocido como: flexibilidad.
XML es en esencia un SGML fcil, ya que retiene bastantes funcionalidades
para hacerlo til y poderoso, sin embargo, elimin varias caractersticas redundantes
que hacen el SGML complejo y difcil de manejar.
XML puede ser transportado a travs de la red utilizando estndares y
protocolos conocidos como File Transfer Protocol (FTP), HyperText Transfer
Protocol (HTTP), SOAP y Simple Mail Transfer Protocol (SMTP). Desde que existen
los estndares de texto de documentos, no hay limitaciones acerca de cmo puedan
ser transportados, instalados o vistos.
Como mencionan Weerawarana, et. al. (2005), XML provee un conjunto de
conceptos principales para definir nuevos lenguajes, los cuales se detallan a
continuacin:
Elementos
Contiene un conjunto de atributos y algunos nodos hijos. Los nodos
hijos pueden ser otros elementos, texto, comentarios y otros tipos. Los
elementos son escritos utilizando los signos <>, ejemplo:
elemento inicial <libro> elemento final </libro>
Atributos
Son los nombres de los valores que estn asociados a un elemento. Un
elemento puede tener cualquier nmero de atributos y se escribe de la
siguiente forma:
<libro id=1 isbn=1234567890>
Comentarios
42
Los comentarios inician con la secuencia de caracteres <!-- y terminan
con -->, todo lo que encierra estas marcas es ignorado por el
procesador.
Documento
Un documento XML es una unidad que consiste exactamente de un
elemento (llamado elemento de documento) y puede contener
comentarios y otros elementos.
Texto literal
Los elementos pueden tener secuencias de caracteres basados en el
esquema de codificacin UNICODE. Una caracterstica clave de los
documentos hechos en XML es que todos los caracteres contenidos
son representados en UNICODE. Utilizando este esquema, XML puede
almacenar texto de cualquier lenguaje.

Usando estos conceptos, se pueden definir nuevos lenguajes, simplemente
nombrando cada uno de los elementos, validando su contenido y el tipo de texto que
esta permitido, como valores de los atributos y elementos de contenido.
XML es una familia de tecnologas: un lenguaje de marcado de datos, varios
modelos de contenido, un modelo de enlace, un namespace y varios mecanismos de
transformacin. Las siguientes tecnologas son miembros importantes de la familia
XML utilizados en la creacin de los servicios Web:
XML v1.0
Son las reglas para definir los elementos, atributos, y etiquetas de cierre
de un elemento principal, provee un modelo de datos abstractos y
formato de serializacin.
XML schema
Son documentos XML que definen los tipos de datos, contenido,
estructura y permiten la asociacin de elementos en el documento XML;
tambin es usado para describir instrucciones de procesamiento
semntica asociado con elementos del documento.
XML namespaces
43
El calificador de nombres para los elementos del documento XML.

Se dice que un documento XML esta bien formado cuando hace uso de los
Document Type Definition (DTD), esquemas XML o algn otro lenguaje de definicin
de estructuras. Los elementos que definen el formato del mensaje SOAP es un
ejemplo de esto (Weerawarana, et al., 2005).
Los DTDs fueron inventados por SGML, cuando XML fue creado, los DTD se
convirtieron en un mecanismo de facto para definir la estructura de los documentos
XML. El lenguaje DTD permite definir los nombres de los elementos, nmero de
elementos y las veces que aparecern. Sin embargo, con la llegada de los esquemas
XML el uso de DTD fue desapareciendo rpidamente.
Por su parte, los esquemas XML son documentos estructurados y creados
como especificacin por el World Wide Web Consortium (W3C). Los esquemas XML
permiten especificar estructuras de una mejor manera que los DTD (Weerawarana,
et al., 2005). Dentro de sus bondades, destacan la definicin de un conjunto de datos
primitivos que se pueden usar para definir atributos, elementos y valores recursivos
para definir estructuras complejas.
Una clara aplicacin del XML son los servicios Web, ya que la informacin
utilizada debe ser convertida de su formato original a XML, por ejemplo, si se tiene
los datos generales de un libro: titulo, autor, editorial, isbn en la base de datos de
SIABUC, el registro correspondiente tendra la informacin que se muestra en la
tabla 1.
Tabla1. Campos de un libro





Una vez que el programador realiza un anlisis de la informacin
correspondiente, se obtendra el siguiente documento en formato XML:
<libro>
<titulo>Automatizacion de Bibliotecas</titulo>
Nombre Tipo
Titulo Cadena
Autor Cadena
Editorial Cadena
ISBN Cadena
44
<autor>Hugo Ponce</>
<editorial>Universidad de Colima</editorial>
<isbn>0123456789</isbn>
</libro>

El programador ha creado un elemento llamado: libro, el cual es un documento
XML con la informacin contenida en la base de datos. Sin embargo, no se han
definido los tipos de datos en XML, es necesario un esquema.
Mediante el esquema se valida la informacin para que contenga los datos y la
estructura correctamente. El ejemplo del libro con el esquema apropiado sera el
siguiente:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="libro" type="TipoLibro"/>
<xsd:complexType name="TipoLibro">
<xsd:sequence>
<xsd:element name="titulo" type="xsd:string"/>
<xsd:element name="autor" type="xsd:string"/>
<xsd:element name="editorial" type="xsd:string"/>
<xsd:element name="isbn" type="xsd:long"/>
<xsd:sequence>
</xsd:complexType>
</xsd:schema>

Los servicios Web tambin utilizan mecanismos para validar los documentos,
similares a los esquemas XML, dicho mecanismo es llamado Web Services
Description Lenguaje (WSDL), en el siguiente apartado se menciona con ms detalle.



3.2.3 WSDL
Web Services Description Language fue creado en Septiembre del ao 2000,
utilizando la combinacin de dos lenguajes descriptores de servicio: Network
Application Services Specification Language (NASSL) de IBM y Services Description
Language (SDL) de Microsoft (Weerawarana, et al., 2005).
NASSL tiene una estructura similar al WSDL en trminos abstractos que eran
ligados a protocolos cableados especficos, sin embargo, era difcil utilizarlo con el
estilo RPC. SDL por su parte era la estructura opuesta, un servicio que era ofrecido
45
sobre mltiples protocolos era descrito como un servicio completamente diferente,
sin una descripcin comn de servicio. SDL estaba mucho mas centrada en los
mensajes que NAASL.
El WSDL es un esquema XML que define una estructura para describir las
interfaces de los servicios Web. Los creadores del WSDL fueron Microsoft e IBM,
tiempo despus tuvieron el apoyo de otras 25 compaas para someterlo al consorcio
W3C (Newcomer, 2002).
WSDL es el ncleo de la estructura de los servicios Web, provee un sentido
comn en el que los tipos de datos son representados y pasados a mensajes, as
como las operaciones que son ejecutadas en los mensajes y el mapeo de mensaje
sobre la red. Inicialmente el documento WSDL estaba definido en tres elementos
principales: definicin de tipos de datos, operaciones abstractas y enlace de
servicios.
Las partes incluyen la definicin de tipos de datos, mensajes y operaciones
abstractas, que son similares a las definiciones de interfaces en CORBA o DCOM
(Newcomer, 2002). Los mensajes pueden tener mltiples partes y pueden ser
definidas para usarse con la orientacin a procedimientos o la interaccin orientada a
documento. A travs de las capas de abstraccin, los mismos mensajes pueden ser
definidos y usados por mltiples puertos. A continuacin, en la figura 9 se muestra la
estructura del WSDL (trad. Newcomer, 2002, p. 23).

46

Figura 9. Estructura inicial del documento WSDL

El WSDL juega un rol importante que facilita muchas de las ventajas de los
servicios Web y la orientacin a servicio. Segn Weerawarana, et al., (2005) el
esquema WSDL es utilizado en los servicios Web en dos tipos de escenarios:
Descripcin de un servicio para sus clientes
En este tipo de descripcin, el documento WSDL describe un servicio
publicado para sus clientes. La descripcin consiste en una declaracin
de mensajes, operaciones de intercambio de mensajes y la ubicacin,
en resumen, es el mecanismo para interactuar con el servicio. El
propsito principal del WSDL en este escenario es el de permitir a un
cliente usar el servicio satisfactoriamente.
Descripcin de un servicio estndar para implementar el servicio
En este caso, el documento WSDL es un servicio estndar. Un ejemplo
de esto pueden ser las libreras, estas reciben y aceptan la compra de
un determinado libro. Un documento XML describe el formato del
mensaje, y la interaccin envuelta con la compra del libro ha sido
47
convenida por la editorial. Entonces, una editorial especfica puede
utilizar el WSDL y ofrecer el servicio, lo cual resulta en otro WSDL.

Un consumidor de servicio cliente utiliza el WSDL para ubicar el servicio
Web e invocar cualquiera de sus funciones pblicas disponibles. Existen
herramientas que permiten la integracin de servicios Web con poco cdigo, por
ejemplo, la herramienta desarrollada por IBM: Web Services Invocation Framework
(WSIF), este proyecto actualmente es dirigido por Apache XML (Fremantle, 2002).
Utilizando esta aplicacin se puede especificar el nombre del archivo WSDL y
automticamente invocar el servicio descrito.
En la figura 10 se muestran los esquemas de las versiones de los esquemas
WSDL, la versin 2.0 fue liberada el 26 de Junio del ao 2007, probablemente no se
har una nueva versin en algunos aos (Weerawarana, et al., 2005).














Figura 10. Versiones del WSDL
<types>

</types>
<message name=>

</message>
<porType name=>

</porType>
<binding name=>

</binding>
<service name=>

</service>
<definitions>
</definitions>

<types>

</types>
<binding name=>

</binding>
<service name=>
interface=>

</service>
<interface name=>

</interface>
<description>
</description>
Versin 1.1 Versin 2.0
48
Actualmente el consorcio W3C ha desarrollado herramientas prototipo para
convertir los documentos WSDL de la versin 1.1 a la versin 2.0. As como libreras
para leer, manipular y crear documentos WSDL en su versin 2.0 (World Wide Web
Consortium, 2007b).



3.2.4 SOAP
Hasta este punto se han definido los datos (XML) y se ha expresado la abstraccin
del servicio necesario para soportar la comunicacin y procesamiento del mensaje
(WSDL). Ahora, es importante definir la estructura del mensaje que ser enviado
desde una computadora a otra.
SOAP son las siglas de Simple Object Access Protocol, este protocolo fue
desarrollado por Microsoft, Developmentor y Userland Software. Posteriormente,
empresas como IBM y Lotus contribuyeron en la revisin de la especificacin que
resulto en la versin SOAP 1.1, misma que fue publicada en Abril del ao 2000. Esta
especificacin es ampliamente utilizada en la industria del software y forma las bases
de varios implementaciones interoperables (Weerawarana, et al., 2005).
Los creadores de SOAP 1.1 enviaron la especificacin al consorcio W3C en
Mayo del 2000, donde fue analizada por el grupo de trabajo del protocolo XML, cuyo
objetivo era la estandarizacin de SOAP.
La especificacin SOAP define la estructura para el intercambio de
informacin en XML a travs de Internet y de esta manera provee el mecanismo de
comunicacin para conectar los servicios Web. La estructura del mensaje es simple,
fcil de desarrollar y completamente neutral con respecto al sistema operativo,
lenguaje de programacin o plataforma de cmputo distribuido (Newcomer, 2002).
Este protocolo se encuentra en constante desarrollo y el encargado de su
evolucin es el consorcio W3C, actualmente se encuentra en su versin 1.2 (World
Wide Web Consortium, 2007a).
SOAP est fundamentado en el modelo de comunicacin de un solo sentido,
que asegura el envo de un mensaje desde el transmisor al receptor, incluye
49
intermediarios que pueden procesar o agregar partes al mensaje. La especificacin
SOAP contiene metodologas para adaptar los mensajes en un solo sentido para la
comunicacin al estilo RPC y tambin define como se transmiten documentos
completos en XML.
SOAP es un conjunto de convenciones que especifican el formato de un
mensaje a travs de un conjunto de reglas que gobiernan su procesamiento a lo
largo de su ruta. Estas convenciones describen como un mensaje es ensamblado y
que nodos los procesan (Weerawarana, et al., 2005).
Un mensaje SOAP es la unidad bsica de comunicacin entre nodos y esta
compuesto por 3 elementos principales: Envelope, Header y Body (Weerawarana, et
al., 2005). Cabe sealar que las etiquetas Envelope y Body son obligatorias dentro
del cuerpo del mensaje SOAP, en la figura 11 se muestra el esquema general de
este protocolo.












Figura 11. Estructura del protocolo SOAP

A continuacin se describe las etiquetas principales de ste protocolo:
Envelope
Define el inicio y el fin del mensaje, puede contener uno o ms
elementos header.
Header





SOAP Header
SOAP Envelope
Header Bloque 1
Header Bloque N





Body sub-elemento 1
Body sub-elemento N
SOAP Body
50
Contiene cualquier atributo opcional del mensaje usado en el
procesamiento del mismo.
Body
Contiene los datos XML que abarca el mensaje cuando es enviado,
tambin conocida como informacin de negocio.

Como se muestra en la figura 12, SOAP esta diseado para proveer un
protocolo de comunicacin abstracto, independiente, capaz de conectar dos o ms
sitios remotos (trad. Newcomer, 2002, p. 26). El sistema de comunicacin puede ser
construido utilizando cualquier combinacin de hardware y software que soporte el
acceso a Internet con sistemas existentes como .NET, Java, entre otros.

Figura 12. Mensajes SOAP interconectando sitios remotos

Un nodo es una implementacin de reglas de procesamiento descritas en la
especificacin SOAP que puede transmitir, recibir procesos retransmitir un mensaje
SOAP. Sin embargo, el nodo implementa el modelo de procesamiento SOAP,
tambin puede acceder a cualquier servicio que los protocolos de red subyacentes
deben proveer (Weerawarana, et al., 2005).
51
Los nodos pueden enviar y recibir mensajes SOAP, si un nodo transmite un
mensaje es llamado emisor, si recibe un mensaje es llamado receptor. Sin embargo,
algunos nodos deben hacer las dos funciones; recibir y transmitir mensajes, en este
caso son llamados intermediarios.
El emisor crea el mensaje, posteriormente el mensaje pasa a travs de varios
intermediarios antes de llegar a su destino final, en este sentido, es comn que un
mensaje SOAP pase a travs de varios nodos, y a este conjunto de nodos se le
conoce como: ruta del mensaje, esta interaccin se muestra en la figura 13.





Figura 13. Interaccin de los nodos en la ruta SOAP


El modelo de procesamiento SOAP
Segn Weerawarana, et al. (2005), la especificacin del mensaje SOAP se encuentra
expresada como informacin en formato XML. Esto significa que el emisor debe
crear un mensaje XML que el receptor puede reconstruir. Todos los mensajes
creados se encuentran basados en el estndar XML 1.0. A continuacin se muestra
un ejemplo de un mensaje SOAP bsico.
<?xml version='1.0'?>
<env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'>
<env:Header>
<p:BloqueUno xmlns:p='http://siabuc.ucol/b_uno'>
<p:prioridad>alta</p:prioridad>
<p:fecha>2009-08-01</p:fecha>
</p:BloqueUno>
</env:Header>
<env:Body>
<sb:libro xmlns:sb='http://siabuc.ucol.mx/lib'>
<sb:titulo>Automatizacion de Bibliotecas</sb:titulo>
<sb:autor>Hugo Ponce</sb:autor>
<sb:editorial>Universidad de Colima</sb:editorial>
Receptor Final Emisor Inicial
Intermediario Emisor Receptor
Ruta del mensaje SOAP
Intermediario
52
</sb:libro>
</env:Body>
</env:Envelope>

El elemento inicial Envelope contiene dos subelementos que son definidos en
SOAP: Header y Body. Sin embargo, el contenido de estos es especfico de la
aplicacin que crea y procesa el mensaje SOAP.
El elemento Header es opcional, su funcin dentro de SOAP es la de
transportar datos que no son parte de la informacin de negocio. Tambin define las
condiciones de fallo que pudieran ocurrir. En el ejemplo anterior, el elemento Header
incluye un elemento hijo que contiene un conjunto de caractersticas de parmetros
de servicio. Dentro de la especificacin SOAP, este elemento hijo es llamado header
block. Un elemento header puede contener varios header blocks, los cuales tienen su
propio namespace XML. La especificacin XML permite que los header blocks
apunten a nodos SOAP especficos para procesar el mensaje a lo largo de su ruta.
El modelo de procesamiento SOAP se refiere a que se pueden utilizar
diferentes especificaciones de servicio, con sus propias definiciones header, con la
finalidad de ensamblar un mensaje que tenga caractersticas ms complejas de
servicio, se tiene que definir una cabecera (header block) por cada servicio.
Por otra parte el elemento Body es obligatorio dentro del mensaje SOAP,
contiene la informacin del negocio del mensaje, es decir, la informacin que ser
transmitida del emisor hacia el receptor. La eleccin acerca de que tipo de
informacin se coloca dentro del elemento Header y dentro de Body corresponde al
diseo del sistema.
Existen otra serie de atributos que son opcionales como Rol, mustUnderstand
y Relay. La finalidad del atributo Rol es la de identificar el rol desempeado por el
header block, por su parte el elemento mustUnderstand se encarga de cerciorarse
que los nodos no ignoren los header block que son importantes para el propsito de
la aplicacin, mientras que Relay es un atributo booleano que indica la retransmisin
de una cabecera cuando no es procesada.


53
Mensajes de error
El protocolo SOAP provee un mecanismo para manejar los errores que se presentan
durante el procesamiento del mensaje. La informacin correspondiente al error es
etiquetada con env:Fault, el cual es un elemento hijo de env:Body.
El elemento env:Fault contiene a su vez dos elementos hijos: env:Code y
env:Reason. Tambin podra contener tres elementos ms de manera opcional:
env:Detail, env:Node y Env:Role.
El subelemento env:Code debe contener un elemento llamado env:Value, el
cual utiliza uno de los cinco cdigos de fallo definidos en la especificacin SOAP, los
cuales se mencionan a continuacin:
VersionMismatch
El mensaje no es soportado por la versin SOAP.
MustUnderstand
El nodo destino no entiende la cabecera en el mensaje que contiene el atributo
mustUnderstand.
DataEncodingUnknown
El nodo destino no logr entender la codificacin del mensaje.
Sender
El mensaje fue formado incorrectamente.
Receiver
El nodo receptor no pudo procesar el mensaje.

A continuacin se muestra un ejemplo con el funcionamiento del elemento
fault utilizando la especificacin SOAP:

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:flt="http://example.org/faults">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Receiver</env:Value>
<env:Subcode>
<env:Value>flt:ValorErroneo</env:Value>
54
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="es">Error en la base de datos</env:Text>
<env:Text xml:lang="us">Database Error</env:Text>
</env:Reason>
<env:Detail>
<flt:MyDetails>
<flt:Message>Base corrupta</flt:Message>
<flt:ErrorCode>3197</flt:ErrorCode>
</flt:MyDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>

El propsito de env:Reason es proporcionar un mensaje que sea fcil de
interpretar por cualquier persona, el elemento env:Text contiene la descripcin del
mensaje en lenguajes alternativos, por su parte el elemento env:Detail puede
contener informacin adicional acerca del error generado. Finalmente, env:Node y
env:Role contienen la URI del nodo que genero la falla, cabe sealar que estos dos
elementos son opcionales.



3.2.5 UDDI
Despus que se han definido los datos en los mensajes (XML), descrito los servicios
que sern recibidos, la manera de procesar el mensaje (WSDL) e identificado la
forma de enviar y recibir los mensajes (SOAP), es necesario dar a conocer o publicar
el servicio que se ha hecho y encontrar los servicios que otros ofrecen y que se
quieren utilizar. Esta es la funcin que Universal Description, Discovery and
Integration (UDDI) provee (Newcomer, 2002).
La especificacin UDDI define un mtodo estndar para publicar y descubrir
los componentes de software de una arquitectura orientada a servicio basados en
red (OASIS, 2004a). Esta especificacin actualmente est a cargo del consorcio
55
OASIS
10
, desarrolladores de software empresarial y clientes. El propsito principal de
UDDI es el de representar los datos y metadatos de los servicios Web.
Cuando UDDI fue desarrollado estaba enfocada en UDDI Business Registry
(UBR), el cual, era una implementacin pblica del estndar UDDI que representaba
un directorio de servicios de comercio electrnico. Este directorio era considerado de
manera anloga al nodo principal de la base de datos del Domain Name System
(DNS) (OASIS, 2004a). Los detalles de la evolucin con las distintas versiones de
UDDI se muestran en la tabla 2.
Tabla 2. Evolucin de la especificacin UDDI
Versin
UDDI
Ao de
liberacin
Objetivo
1.0 2000 Crear el principio para registrar los servicios de los
negocios basados en Internet.
2.0 2001 Proveer servicios de taxonoma flexible. Adaptacin con
los servicios Web.
3.0 2004 Soportar interaccin segura de implementaciones
pblicas y privadas como el mayor elemento de SOA.

La versin 3.0 representa un gran avance en la evolucin de la especificacin
UDDI, esta versin es estable y compatible con las versiones anteriores del
estndar. Un registro UDDI provee un registro compartido de ndices donde los
clientes pueden buscar servicios con lo cuales desean interactuar (Weerawarana, et
al., 2005).
La informacin utilizada por UDDI es definida en varios esquemas XML. El
estndar XML fue seleccionado debido a que ofrece una plataforma neutral de datos
y permite relaciones jerrquicas para ser descritas de forma natural. Por su parte
XML Schema Definition (XSD) fue escogida porque soporta varios tipos de datos y
fcilmente describe y valida la informacin basada en esquemas.
El consorcio OASIS seala que UDDI en combinacin con XSD definen la
informacin que los usuarios y aplicaciones necesitan conocer para utilizar un
servicio Web (OASIS, 2004a). Y a la vez, forman un modelo de base de informacin
y una estructura de interaccin de los registros UDDI.

10
http://www.oasis-open.org/home/index.php
56
Una vez que un servicio Web es registrado, los programadores hacen
consultas a paginas Web que funcionan como repositorios UDDI, algunos ejemplos
de este tipo de pgina son http://www.soapclient.com/uddisearch.html y
http://www.xmethods.net/ve2/index.po, una vez encontrado el servicio de nuestro
inters bastara con lograr interpretar el WSDL correspondiente, para finalmente
establecer la comunicacin mediante el envo y recepcin de mensajes SOAP.
En la figura 14, se muestra la interaccin que se lleva a cabo para registrar un
servicio Web en un repositorio UDDI, primero se genera el WSDL que contendr la
descripcin del servicio, posteriormente este WSDL es registrado mediante una API
en el repositorio UDDI, una vez registrado estar accesible a los programadores para
que puedan localizar el servicio, cuando un programador se interesa en un servicio
Web en particular, accede de nueva cuenta a su WSDL y posteriormente lo interpreta
mediante algn lenguaje de programacin para comunicarse con el va SOAP (trad.
Newcomer, 2002, p. 28).


Figura 14. Localizacin de un servicio Web mediante UDDI

Algunos autores comentan que UDDI es un concepto similar a la seccin
amarilla, sin embargo, Guruge (2004) menciona que UDDI es mucho mas que eso,
57
UDDI es un directorio de pginas que contiene los proveedores de servicio por
nombre. Debido a esto, la informacin contenida en UDDI se encuentra dividida en
tres categoras: pginas blancas, pginas amarillas y pginas verdes, las cuales se
detallan a continuacin:
Pginas blancas
Las pginas blancas contienen informacin descriptiva acerca de las
organizaciones que proveen varios servicios. El nombre de la organizacin y la
descripcin textual del contenido, la cual puede estar en varios idiomas.
Informacin de contacto para que la entidad tambin sea incluida en trminos
de nombres de contacto, nmeros de telfono, nmeros de fax, correos
electrnicos y URL.
Pginas amarillas
Informacin que describe un servicio Web utilizando diferentes clasificaciones
(taxonomas). Permite categorizar las empresas y los servicios que ofrecen as
como tambin su ubicacin geogrfica.
Pginas verdes
Contienen la informacin tcnica necesaria para utilizar el servicio disponible.


Programacin en UDDI
Hasta este momento se ha definido la estructura de UDDI, sin embargo, es necesario
mencionar el mecanismo mediante el cual se puede por ejemplo, localizar, crear,
editar o guardar algn servicio, este mecanismo es posible llevarlo a cabo mediante
un par de APIs.
Bsicamente son dos las APIs que estn definidas en la especificacin UDDI:
inquiry API y publishing API, cada API contiene un conjunto de funciones que se
pueden invocar mediante programacin, el objetivo de estas funciones es generar
mensajes en XML para guardar un servicio creado, editarlo.
Inquiry API se utiliza para localizar informacin que ofrecen los servicios y la
forma de actuar en caso de alguna falla, mientras que publishing API, se utiliza para
58
crear, almacenar o actualizar informacin concentrada en el registro UDDI (Chappell,
2002).
Inquiry API consiste en localizar informacin acerca de un servicio que se ha
ofrecido, la especificacin de ese servicio y la informacin acerca de lo que debe
hacer en caso de fallo, cabe sealar que esta API no requiere un mtodo de
autentificacin y por lo tanto puede ser utilizada a travs del protocolo HTTP.
Mientras que publishing API, se utiliza para crear, almacenar, o actualizar
informacin localizada en un registro UDDI, todas las funciones utilizadas en esta
API requieren autentificacin de acceso, debido a ello se utiliza el protocolo
HyperText Transfer Protocol Secure (HTTPS).
Adems de la publishing API, existen otras APIs de seguridad, transferencia,
y suscripcin, las cuales son opcionales (OASIS, 2004b).
Las funciones relacionadas con la inquiry API pueden ser utilizadas para
recuperar informacin del registro UDDI. A continuacin se mencionan cada una de
ellas:
find_binding
find_business
find_relatedBusiness
find_service
find_tModel
get_bindingDetail
get_businessDetail
get_operationalInfo
get_serviceDetail
get_tModelDetail

Mientras que las funciones correspondientes de la API para publicar (Publish
API) son las encargadas de dar a conocer y actualizar informacin contenida en el
registro UDDI. A continuacin se listan cada una de ellas:
add_publisherAssertions
delete_binding
59
delete_business
delete_publisherAssertions
delete_service
delete_tModel
get_assertionStatusReport
get_publisherAssertions
get_registeredInfo
save_binding
save_business
save_service
save_tModel
set_publisherAssertions

Ahora que los estndares XML, SOAP, WSDL y UDDI son utilizados en conjunto
para hacer posible los servicios Web, hacen que tengan un impulso a la siguiente
tecnologa orientada a objeto. En la figura 15 se muestra el modelo de interaccin de
las tecnologas de los servicios Web (trad. Guruge, 2004).

Figura 15. Modelo operacional de los servicios Web
60
En la actualidad, existen herramientas que incorporan la funcionalidad de
UDDI sin hacer toda esta tarea manualmente, a continuacin se mencionan algunas
de ellas (Online Community for the Universal Description, Discovery and Integration
OASIS Standard, 2008):
jUDDI
Es una implementacin Open Source que utiliza el lenguaje Java
implementando UDDI. Actualmente este proyecto esta a cargo Apache
Group y esta basado en la especificacin UDDI 2.0.
Novell: Nsure UDDI Server
Agrega administracin de seguridad a la especificacin UDDI,
incrementando la seguridad y administracin de los servicios Web.
Soporta la versin UDDI 2.0.
OpenUDDI Server
Es una implementacin Open Source basada en la especificacin
UDDI 3.0. Esta herramienta se encuentra basada en la Novell UDDI
Server.

Hasta aqu se ha definido uno de los elementos esenciales para el desarrollo
de este trabajo; los servicios Web, estos proveen la interoperabilidad y pueden
fcilmente ser extendidos para utilizarse en arquitecturas empresariales, sin
embargo, adquieren ms valor cuando utilizan implementaciones basadas en Service
Oriented Architecture (SOA) (Newcomer y Lomow, 2004). Esto debido a que la
mayora de los analistas y proveedores de software recomiendan la utilizacin de los
servicios Web como la mejor forma de realizar una implementacin SOA (Josuttis,
2007). Ahora, es necesario definir SOA, sus caractersticas principales y su
estructura, esto se aborda con detalle en el siguiente apartado.





61
3.3 Arquitectura Orientada a Servicio (SOA)
3.3.1 Concepto de SOA
En el ao de 1994 Alexander Pasik, un analista de la empresa Gartner, acuo el
trmino Service Oriented Architecture para una clase que formaba parte de un
middleware. Pasik era desarrollador de software desde antes que el lenguaje XML o
los servicios Web fueran inventados (Josuttis, 2007).
Pasik estaba creando el 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, mientras que 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 se referan principalmente al
hardware.
Para evitar confusin entre los antiguos y los nuevos trminos cliente-servidor,
Pasik menciono que la orientacin a servicio es muy til para desarrollar aplicaciones
empresariales.
Anteriormente, las aplicaciones compartidas se encontraban enfocadas en la
resolucin de problemas manuales como el pago de nmina, facturacin,
contabilidad, entre otros. En la actualidad, la mayora de estas operaciones han sido
automatizadas, sin embargo, ahora se encuentra la incgnita acerca de mejorar la
habilidad de esos sistemas para encontrar nuevos requerimientos (Newcomer y
Lomow, 2004). La forma de hacerlo es agregando nuevas interfaces de usuario,
combinando varias fuentes de datos, integrando dispositivos mviles reemplazando
la aplicacin anterior por una nueva.
El paradigma del desarrollo orientado a servicio no es nuevo, fue tomado
como un cambio en las tecnologas de informacin para desarrollar nuevos sistemas
y obtener aportaciones de manera rpida.
SOA no reemplaza la tecnologa orientada a objetos (OO), sino que viene a
ser un complemento de sta. Sin embargo, cabe sealar que SOA se separa
62
considerablemente del modelo OO ya que SOA es orientada a servicios mientras que
OO es orientado a objetos, clases y mtodos.
SOA se enfoca en el modelo basado en servicios y soporta tecnologas
interoperables, adems se encarga de resolver problemas prcticos que surgen por
las diferentes plataformas y lenguajes de programacin (Gorton, 2006).
Es difcil encontrar una definicin exacta acerca del trmino SOA, esto debido
a que existen varias definiciones al respecto, sin embargo, la mayora de ellas
coinciden en el sentido de que SOA es un modelo que permite el intercambio de
informacin de manera interoperable e independiente, en los siguientes prrafos se
mencionan algunas definiciones al respecto.
Newcomer y Lomow (2004), definen SOA como un estilo de diseo que gua
todos los aspectos de creacin y usa servicios de negocio a travs de su ciclo de
vida (desde la concepcin hasta su retiro). Tambin permite a diferentes aplicaciones
el intercambio de datos independientemente del sistema operativo o lenguaje de
programacin que se utilice.
Erl (2005), por su parte define a SOA como un trmino que representa un
modelo en donde la automatizacin lgica es descompuesta en pequeas unidades
lgicas. De manera colectiva, esas unidades lgicas abarcan una pieza de
automatizacin lgica del negocio. Sin embargo, esas unidades pueden ser
distribuidas.
Por su parte, el consorcio OASIS define SOA como la representacin de una
coleccin de las mejores prcticas y principios relacionadas a los servicios, nivel
empresarial y cmputo distribuido (OASIS, 2008b).
Mientras que Josuttis (2007), define SOA como un paradigma para la
realizacin y conservacin de los procesos de negocio que abarcan los sistemas
distribuidos. Tambin menciona que esta arquitectura se encuentra basada en tres
conceptos: servicios, interoperabilidad a travs del Enterprise Service Bus (ESB) e
independencia (loose coupling). A continuacin se definen estos tres conceptos:
Servicio
Es una pieza independiente de la funcionalidad del negocio, donde la
funcionalidad, puede ser simple o compleja.
63
Enterprise Service Bus (ESB)
Es una infraestructura que permite una gran interoperabilidad para los
servicios entre sistemas distribuidos. Hace que sea fcil distribuir los
procesos de negocios sobre mltiples sistemas usando diferentes
plataformas y tecnologas.
Loose coupling
El objetivo de este concepto es el de reducir las dependencias del
sistema. Debido a que los procesos de negocio se encuentran
distribuidos sobre mltiples backends, es importante minimizar los
efectos de modificaciones y fallas.

La finalidad de SOA es tener tareas individuales, las cuales son ejecutadas
por componentes especializados llamados servicios. El objetivo de los servicios es
coordinar los procesos de negocio, cada servicio es diseado para facilitar su
reutilizacin, si otro proceso requiere que la misma tarea sea ejecutada, sta hace
uso del servicio existente (Brown, 2008).
Brown (2008) define un servicio como una unidad bien definida que ejecuta un
trabajo y que adems se encuentra empaquetada para un acceso fcil. El objetivo es
implementar la funcionalidad exactamente una vez, de una manera correcta y
hacerlo ampliamente accesible. El esfuerzo extra en la creacin inicial del servicio es
pagado para evitar costos en desarrollo futuro.
Margolis y Sharpe (2007) mencionan que los servicios son independientes de
otro software a fin de que los cambios de una peticin requieran pocos o ningn
cambio en el servicio.
Cuando los servicios Web estn disponibles a travs de un entorno
empresarial, los proyectos de integracin orientados a servicios pueden enfocarse en
componer servicios Web en lugar de tratar con la incompatibilidad de aplicaciones en
varias computadoras, lenguajes de programacin o paquetes de aplicacin. Por
ejemplo, si se utilizan lenguajes de programacin como Java, C++, Visual Studio,
CORBA, WebSphere MQ, o cualquier otra plataforma de desarrollo o sistema de
64
software, como J2EE o .NET, SOA provee la arquitectura y los servicios Web
proveen la unin de manera unificada.
Comparando los estndares del pasado, los servicios Web son mucho ms
fciles de entender y de utilizar (Newcomer y Lomow, 2004). La amplia adopcin de
estos estndares facilita el imaginarnos un entorno en el que las aplicaciones tengan
interfaces de servicio. Y partiendo de esta visin, es fcil imaginar a personas
involucradas en las tecnologas de informacin ejecutando en la mayora de sus
actividades interfaces de servicio Web.
La aplicacin ms importante de SOA es la de conectar varios sistemas que
automaticen procesos de negocios empresariales (Newcomer y Lomow, 2004).
Ejemplos clsicos de estos son el sistema de inventario de Wal-Mart, sistema de
reservacin de American Airlines y el sistema de administracin de abastecimiento
de la empresa Dell. Las compaas necesitan sistemas que sean flexibles para
implementar operaciones especializadas, para cambiar tan fcil como las
operaciones de negocio cambien y responder tanto interna como externamente a
dichas condiciones de cambio.
Dentro de las ventajas de la utilizacin de SOA Newcomer y Lomow (2004)
menciona las siguientes:
Desarrollo eficiente
SOA promueve la modularidad porque los servicios son independientes,
esta modularidad tiene implicaciones positivas para el desarrollo de
aplicaciones compuestas.
Mayor reutilizacin
Una de las promesas de SOA es que el servicio reutilizable disminuir
costos de desarrollo y velocidad de tiempo en la comercializacin.
Mantenimiento simplificado
Simplifica el mantenimiento y reduce los costos debido a que las
aplicaciones desarrolladas en SOA son aplicaciones modulares e
independientes.


65
Creciente adopcin
Debido a que las aplicaciones son modulares e independientes pueden
ser desarrolladas y extendidas en pequeas unidades.
Evolucin
Un servicio y su contrato de servicio encapsulan la lgica del negocio,
de forma tal, que otros servicios no necesitan conocer nada acerca de
la forma en la cual se provee el servicio, solamente acerca de lo que el
servicio toma como entrada y lo regresa como respuesta.

SOA en combinacin con los servicios Web facilitan el desarrollo de servicios
que encapsulan funciones de negocio y que son fcilmente accesibles desde
cualquier otro servicio. Adems, servicios complejos permiten un amplio rango de
opciones para combinar servicios Web y crear nuevas aplicaciones funcionales. La
tecnologa de los servicios Web puede ser usada para resolver varios problemas de
las tecnologas de informacin, especialmente cuando se asocian piezas de software
diferentes. Los servicios Web proveen la interoperabilidad y pueden fcilmente ser
extendidos para ser utilizados en arquitecturas empresariales por su bajo costo y por
su valor en las tecnologas de informacin, sin embargo, adquieren ms valor cuando
utilizan implementaciones basadas en SOA (Newcomer y Lomow, 2004).
El momento real para SOA fue concebido por los servicios Web, que
inicialmente fueron creados por Microsoft. Pronto, otras compaas como Oracle, HP,
SAP y Sun aportaron su capital para agrandar la idea y vender nuevos conceptos y
herramientas. Tiempo despus los analistas de software comenzaron a ofrecer SOA
como el concepto clave para el futuro del desarrollo de software. Un ejemplo claro de
esto fue la empresa de consultora e investigacin Gartner (http://www.gartner.com),
la cual, 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).
Por su parte Newcomer, et. al., (2004) menciona que la mayor ventaja de
implementar SOA utilizando servicios Web es que stos son simples y de plataforma
neutral. Adems, los proveedores de software han adoptado extensamente el
paradigma de desarrollo orientado a servicios basado en servicios Web.
66
Desde el punto de vista tcnico, un servicio es un activo que tiene interfaces
bien diseadas, claramente separadas de los servicios externos. Cada servicio
consiste de una o ms operaciones, esas operaciones debern ser implementadas
usando una variedad de tecnologas, pero ningn detalle de esas tecnologas estar
visible al servicio que hace la peticin, porque el WSDL es utilizado para la
descripcin del servicio, de esta forma, cualquier servicio que realice una peticin lo
puede leer. Un servicio es diferente de un objeto un procedimiento porque es
definido mediante mensajes, los cuales, son intercambiados con otros servicios.



3.3.2 Estructura de SOA
Krafzig, et al. (2004) definen la estructura de SOA en cuatro abstracciones
principales: aplicacin, servicio, repositorio de servicios y bus de servicios, dicha
estructura est representada en la figura 16 (trad. Krafzig, Banke y Slama, 2004).












Figura 16. Estructura de SOA

La aplicacin es el dueo de los procesos de negocio y son los elementos
activos de SOA, ya que envan el valor de SOA a los usuarios finales, el servicio
provee la funcionalidad para que la aplicacin y otros servicios la puedan utilizar.
Arquitectura Orientada a
Servicios (SOA)
Aplicacin Servicio Repositorio
de Servicios
Bus de
Servicio
Contrato Implementa -
cin
Interfaz
Lgica del
negocio
Datos
67
Un servicio consiste de una implementacin que provee los datos y la lgica
del negocio, un contrato de servicio especifica la funcionalidad, uso y restricciones
para un cliente del servicio, mientras que una interfaz de servicio expone fsicamente
la funcionalidad.
El repositorio de servicio almacena los contratos de servicio individualmente y
el bus de servicio interconecta la aplicacin con el servicio.
A continuacin se describe cada uno de los elementos que integran la
arquitectura SOA:
Aplicacin Son los elementos activos de SOA, inician y controlan toda
la actividad de los sistemas empresariales. Hay diferentes tipos de
aplicaciones; una aplicacin con una interfaz grfica de usuario, como
una aplicacin Web o un cliente que interacte directamente con los
usuarios finales. Sin embargo, la aplicacin no necesariamente tiene
que interactuar con los usuarios finales, ya que tambin puede ser un
archivo de procesamiento por lotes que se ejecute peridicamente.
Servicio Un servicio es un componente de software que tpicamente
encapsula el concepto de negocio de alto nivel.
Repositorio de Servicios Un repositorio de servicios provee la
facilidad para descubrir servicios y adquirir toda la informacin
necesaria para usar los servicios. Sin embargo, mucha de la
informacin requerida ya es parte del contrato de servicio.
Bus de Servicio El bus de servicio conecta todos los elementos de los
servicios SOA y la aplicacin.
Contrato Provee una especificacin del propsito, la funcionalidad,
restricciones y uso del servicio. La forma de esta especificacin puede
variar dependiendo del tipo de servicio. Un elemento opcional del
contrato de servicio es la definicin de una interfaz formal basada en
lenguajes como IDL o WSDL. Sin embargo, es importante sealar que
si ninguna descripcin formal del servicio se encuentra disponible, cada
servicio requiere de un contrato de servicio respectivamente.
68
Implementacin La implementacin del servicio fsicamente provee los
requerimientos lgicos y los datos apropiados. Consiste en la
implementacin de uno o ms objetos como programas, datos de
configuracin y bases de datos.
Interfaz Expone la funcionalidad del servicio a los clientes que se
conectan a el a travs de la red. Sin embargo, la descripcin de la
interfaz es parte del contrato de servicio, la implementacin fsica de la
interfaz consiste de servicios que son incorporados dentro de los
clientes.
Lgica del negocio Es parte de la implementacin del servicio, esta
hecha para ser disponible a travs de las interfaces de servicio.
Datos Son propiamente los datos del servicio



3.3.3 Aplicacin
Este elemento de SOA inicia y controla toda la actividad de los sistemas
empresariales. Hay diferentes tipos de aplicaciones, una aplicacin con una interfaz
grfica de usuario, una aplicacin Web que interacta directamente con otros
usuarios es el ejemplo mas claro de este tipo de aplicaciones (Krafzig, et al., 2004).
Sin embargo, la aplicacin no necesariamente tiene que interactuar
directamente con los usuarios, puede ser incluso un archivo de procesamiento por
lotes que se ejecute cada cierto tiempo.
Es posible que la aplicacin asigne responsabilidades a los procesos de
negocio de uno o ms servicios. Un aspecto importante es que la aplicacin siempre
inicia un proceso y es la encargada de recibir los resultados.
Este apartado es similar a las capas superiores de las aplicaciones multicapas
tradicionales.



69
3.3.4 Servicio
Krafzig, et al., (2004) definen un servicio como un componente funcional que
tpicamente encapsula un alto nivel del concepto de negocio. Este componente es
uno de los ms importantes dentro de SOA, ya que uno de los objetivos principales
de este paradigma es la orientacin a los servicios y debido a la importancia que
tiene, esta compuesto por cinco elementos: contrato, interfaz, implementacin, lgica
del negocio y datos, tal como se mostr en la figura 16, en los siguientes prrafos se
describen cada uno de ellos.
Contrato Provee una especificacin del propsito, funcionalidad,
restricciones y utilizacin del servicio. La forma de esta especificacin
puede variar dependiendo del tipo de servicio en cuestin.
Un elemento opcional del contrato es la definicin formal basada en
lenguajes como IDL WSDL. Aunque la definicin formal agrega ciertos
beneficios como: abstraccin e independencia de la tecnologa.
El contrato de servicio puede imponer detalles semnticos en la
funcionalidad que no son parte del IDL o de la especificacin WSDL.
Es importante destacar que cada servicio requiere un contrato de
servicio, particularmente si ninguna descripcin formal basada en una
especificacin como WSDL IDL se encuentra disponible.
Interfaz Es la funcionalidad del servicio, la cual, es expuesta a los clientes
y es conectada al servicio utilizando los protocolos de red existentes. La
descripcin de la interfaz es parte del contrato de servicio, la
implementacin fsica de la interfaz esta compuesta por un service stub,
los cuales son incorporados dentro de los clientes de un servicio.
Implementacin La implementacin del servicio fsicamente provee la
lgica del negocio y los datos apropiados. Es la parte tcnica que cumple
en su totalidad con el contrato de servicio. La implementacin del servicio
consiste de uno o ms elementos como programas, datos de
configuracin y bases de datos.
70
Lgica del negocio La lgica del negocio es encapsulada por el servicio y
forma parte de su implementacin, se encuentra disponible a travs de la
interfaz del servicio.
Datos Son los datos propiamente del servicio.








Figura 17. Elementos que conforman un servicio

Para concluir, un servicio esta compuesto por datos, la lgica del negocio, as
como tambin de las interfaces y las descripciones de cada una de ellas. En la figura
17 se puede observar los componentes del servicio y la forma en la cual interactan
(trad. Krafzig, Banke y Slama, 2004).



3.3.5 Repositorio
Un repositorio de servicios facilita el descubrimiento de servicios y adquiere toda la
informacin para utilizar los servicios, particularmente si stos tienen que ser
descubiertos fuera del mbito del proyecto que los creo (Krafzig, et al., 2004).
Sin embargo, mucha de la informacin requerida ya forma parte del contrato
de servicio, el repositorio de servicio puede proveer informacin adicional, como la
ubicacin fsica del servicio, informacin acerca del proveedor, tarifas de uso (si
aplica), restricciones tcnicas, detalles de seguridad as como tambin los niveles de
servicio disponibles.
71
Los repositorios que son utilizados a travs de la integracin de servicios
empresariales tpicamente tienen diferentes requerimientos particulares, esos
repositorios son publicados a travs de Internet. Estos requerimientos pueden ser
asuntos legales (trminos y condiciones de uso), estilo de presentacin, seguridad,
registro de usuario, suscripcin del servicio, facturacin y versiones.
Un repositorio es un elemento muy utilizado en SOA, sin embargo, se puede
construir una arquitectura basada en la metodologa SOA y obtener muchos de los
beneficios sin utilizar un repositorio de servicios, un repositorio de servicios es
indispensable a largo plazo. Una arquitectura puede funcionar sin un repositorio
siempre y cuando el mbito del servicio se encuentre en un solo proyecto, si tiene
pocos servicios o si todos los proyectos se encuentran hechos por las mismas
personas.
Un ejemplo de repositorio puede ser un conjunto de contratos de servicios
impresos ubicados en una oficina que es accesible por todos los proyectos.



3.3.6 Bus de Servicio
Un bus de servicio conecta todos los participantes de los servicios SOA y la
aplicacin frontend entre si (Krafzig, et al., 2004).
Por ejemplo, si dos participantes necesitan comunicarse si una aplicacin
frontend necesita invocar alguna funcionalidad bsica del servicio, el bus de servicio
hace que esto suceda. En este sentido, el bus de servicio es similar al concepto de
bus de software que es definido en el contexto de CORBA. Sin embargo, existen
algunas diferencias significativas entre ambos conceptos, la ms importante es que
el bus de servicio no necesariamente esta compuesto por una sola tecnologa, sino
que comprende una gran variedad de productos y conceptos.
El bus de servicio se caracteriza por los siguientes elementos:
Conectividad El propsito principal de un bus de servicio es el de
interconectar los participantes de una arquitectura SOA. Provee las
72
facilidades que permiten a los participantes de una aplicacin SOA
invocar las funcionalidades del servicio.
Heterogeneidad de tecnologa El bus de servicio debe contener una
gran variedad de tecnologas diferentes. La realidad de las empresas
es caracterizada por tecnologas heterogneas. Consecuentemente el
bus de servicio debe permitir conectar a los participantes que se
encuentran basados en diferentes lenguajes de programacin, sistemas
operativos o entornos de ejecucin diferentes.
Heterogeneidad de conceptos de comunicaciones De forma similar
a la heterogeneidad de tecnologas, el bus de servicio tambin debe
contener una variedad de conceptos diferentes de comunicacin.
Debido a los requerimientos divergentes de diferentes aplicaciones, el
bus de servicio debe permitir diferentes modos de comunicacin.
Servicios tcnicos El objetivo principal del bus de servicio es la
comunicacin, sin embargo, tambin debe proveer servicios tcnicos
como el registro de eventos en bitcoras, auditoria, seguridad y
transacciones.



73
3.4 SOA con Servicios Web
La mayora de los analistas y proveedores de software recomiendan solo una forma
apropiada para realizar un entorno SOA: los servicios Web. Debido a que son
considerados como la mejor forma para realizar una implementacin SOA. Adems,
se han convertido en un estndar de facto para las infraestructuras que utilizan SOA
(Josuttis, 2007). Segn Juric, Loganathan, Sarang y Jennings (2007) la combinacin
de SOA con los servicios Web ofrecen ciertos beneficios, los cuales se mencionan a
continuacin:
Autosuficientes Los servicios Web son autosuficientes en el sentido
de que no requieren de componentes instalados en el cliente. En el
servidor solamente se necesita una plataforma de desarrollo para crear
el servicio Web. Cuando el servicio esta listo, un cliente puede consumir
el servicio sin necesidad de instalar software adicional en la
computadora.
Autodescriptibles Una interfaz de un servicio Web es publicada a
travs de un documento WSDL. El documento WSDL define el formato
para el intercambio de mensajes y los tipos de datos usados en los
mensajes. Para consumir un servicio, el cliente necesita conocer
solamente el formato y contenido de una peticin y mensaje de
respuesta.
Modulares Los servicios Web proveen una abstraccin ms all que
las tecnologas basadas en componentes como Java, CORBA, DCOM.
Usando varias de esas tecnologas se pueden crear componentes. Los
servicios Web conforman esos componentes para ofrecer un servicio al
cliente. Sin embargo, la interfaz de los componentes no es expuesta al
cliente. Esto se traduce en el desarrollo de software modular para crear
vistas ms abstractas de un servicio de negocio.
Accesibles sobre la Web Los servicios Web son publicados,
localizados e invocados sobre el Web, la descripcin del servicio es
publicada utilizando WSDL; el servicio es localizado con ayuda del
74
registro UDDI y es invocado utilizando SOAP, todos estos protocolos
son basados en Web.
Neutrales en lenguajes de programacin, protocolos y plataformas
Los servicios Web son de plataforma neutral debido a que utilizan el
XML; el cliente y el servicio pueden ejecutarse en plataformas
diferentes.
Basados en estndares La tecnologa de los servicios Web se
encuentra basada en estndares abiertos haciendo que sean fcilmente
interoperables con otros servicios Web. Los estndares utilizados son
SOAP, WSDL y UDDI, los cuales son basados en XML.
Dinmicos Los servicios Web pueden ser descubiertos y consumidos
en tiempo de ejecucin, sin la necesidad de tener conocimiento de ellos
durante la compilacin.
Compuestos Los servicios Web pueden conformar un servicio grande
utilizando la orquestacin.

Sin embargo, el hecho de utilizar los servicios Web no significa que
automticamente se implemente el modelo SOA. Esto solamente es una forma de
indicarle a los sistemas como interactuar entre si, sin que todos los dems aspectos
de SOA sean provistos (Josuttis, 2007).
Para finalizar, con la combinacin de SOA y los servicios Web surge una
respuesta moderna a la integracin de aplicaciones. SOA provee la arquitectura y los
Servicios Web proveen la unin de manera unificada.

75
4. Arquitectura ABCSIS
En esta seccin se aborda a detalle los aspectos de creacin de la arquitectura
ABCSIS, desde la parte terica con el funcionamiento y definicin de los servicios,
hasta la manera mediante la cual stos fueron desarrollados con programacin.

4.1 Modelo Conceptual
Como ya se ha mencionado en secciones anteriores, ABCSIS esta compuesta por un
conjunto de servicios, cuando un programador desea realizar un cliente para
consumir un servicio, primero debe consultar su contrato correspondiente a travs
del WSDL, una vez que el programador ha verificado el contrato sabe como invocar
el servicio, as como los parmetros necesarios para su funcionamiento. Obtenida
toda la informacin necesaria para invocar el servicio, el programador procede a
realizar la solicitud del mismo mediante el desarrollo de una aplicacin, la cual, ser
la encargada de interactuar de manera directa con el servicio, este proceso es
mostrado en la figura 18.
La figura en cuestin est basada en la estructura de la arquitectura SOA
propuesta por Krafzig, et al., (2004), en dicha propuesta los elementos principales
son aplicacin, servicio, repositorio y bus de servicio, estos elementos fueron
mostrados en la figura 16.











Figura 18. Ejemplo de funcionamiento de un servicio bajo ABCSIS
Bus de Servicio
Crea
Cumple
Invoca
Describe
Busca
Programador

Aplicacin



Repositorio de Servicio

Contrato
WSDL


Servicio
Web
76
La descripcin funcional de los elementos que conforman la figura 18
incorporados a SIABUC mediante ABCSIS se describe a continuacin:
Aplicacin Son las distintas aplicaciones que los programadores
(consumidores de servicio) de las diferentes instituciones podrn realizar. Hay
diferentes tipos de aplicacin, por ejemplo, una aplicacin con interfaz grfica
de usuario como una pgina Web o un programa de escritorio, sin embargo,
una aplicacin no necesariamente tiene que interactuar directamente con el
usuario, un ejemplo de esto son los archivos de procesamiento por lotes. En el
caso de ABCSIS, la aplicacin consiste de un prototipo en entorno Web
basado en el lenguaje de programacin PHP que consume el servicio Acervo.
Servicio Un servicio es una funcin que tiene interfaces bien definidas y que
no depende del estado de otros servicios. La arquitectura ABCSIS se
encuentra conformada por tres servicios principales: Acervo, Alumnos y
Retroalimentacin, dichos servicios sern explicados con mayor detalle en
esta seccin. Cabe sealar que cada servicio a su vez cuenta con varios
procedimientos que se encuentran vinculados al servicio, dentro del entorno
SOA estos procedimientos son llamados operaciones de servicio.
Repositorio de servicios Tal como menciona Krafzig, et al., (2004) un
repositorio es un elemento muy utilizado en SOA, sin embargo, se puede
construir una arquitectura basada en la metodologa SOA y obtener muchos
de los beneficios sin utilizar un repositorio de servicios, ya que estos son
indispensables a largo plazo o cuando se cuenta con un enorme equipo de
desarrollo de software. Una arquitectura puede funcionar sin un repositorio
siempre y cuando el mbito del servicio se encuentre en un solo proyecto, si
tiene pocos servicios o si todos los proyectos se encuentran hechos por las
mismas personas.
Un ejemplo de repositorio puede ser desde un conjunto de servicios
impresos, una base de datos donde se describan aspectos como la ubicacin
fsica del servicio, informacin acerca del proveedor, restricciones tcnicas,
entre otros. Para el caso de ABCSIS no existe un repositorio como tal,
77
solamente se incluyeron los WSDL correspondientes a cada uno de los
servicios.
Bus de Servicio El bus de servicio Enterprise Service Bus es la forma
mediante la cual los clientes invocan un determinado servicio que un
proveedor ofrece. El principal objetivo del bus de servicio es proveer la
interoperabilidad y la compatibilidad con sistemas legados haciendo uso de los
servicios Web mediante el protocolo SOAP. El bus de servicio utilizado en
ABCSIS son los servicios Web basados en XML.



78
4.2 Diseo arquitectnico
Un sistema basado en SOA consiste de servicios, aplicaciones y una arquitectura
que conecta las aplicaciones con los servicios. En este sentido, la arquitectura SOA
provee un mecanismo de comunicacin estndar entre las aplicaciones y los
servicios existentes, debido a ello, una aplicacin puede invocar un servicio
conociendo nicamente su WSDL correspondiente. Cada servicio representa una
tarea de negocio y a su vez provee una interfaz, la cual es invocada mediante un
protocolo que es conocido por los clientes que desean consumir el servicio (Kajko-
Mattsson, et al., 2007).
Considerando lo anterior, ABCSIS est conformada por cuatro elementos
principales: consumidores de servicio, la arquitectura propiamente, interfaces de
servicio e implementacin del servicio. Los consumidores de servicio son las
aplicaciones cliente que se desarrollarn, la arquitectura provee un mecanismo
estndar de comunicacin entre las aplicaciones y los servicios existentes, por su
parte, las interfaces es el medio por el cual se conoce la ubicacin del servicio y los
parmetros que se necesitan, finalmente, la implementacin del servicio corresponde
al proveedor del servicio, en este caso SIABUC, todo este proceso es mostrado en la
figura 19, para su diseo se consider la arquitectura propuesta en un documento
denominado Service Migration And Reuse Technique (SMART), que fue elaborado
por el Instituto de Ingenieros de Software de la Universidad de Carnegie Mellon de
los Estados Unidos (Lewis, Morris, Smith y Simanta, 2008).
Hay una serie de modelos y propuestas de organismos, empresas y diversos
autores acerca de la mejor manera de representar una arquitectura basada en SOA,
dentro de las propuestas ms representativas en este sentido destacan las de
Oracle, Microsoft, OASIS y la Universidad de Carnegie Mellon.
El modelo elaborado por el consorcio OASIS es denominado Reference Model
for Service Oriented Architecture 1.0 (OASIS, 2008a), este modelo consta de un
documento muy abstracto y an se encuentra como borrador, incluso las
caractersticas claves de SOA como el servicio, contrato, repositorio, implementacin
que se incluyen en el modelo OASIS, tambin se encuentran en el documento
SMART.
79
Posteriormente se analiz el modelo propuesto por Krafzig, et al., (2004), este
modelo se encuentra plasmado en la figura 16, sin embargo, solo hace referencia a
un solo servicio de manera particular, en cambio en el modelo SMART hace
referencia a varios servicios incluyendo los usuarios y los sistemas legados.
Por su parte las empresas Microsoft y Oracle a diferencia de las propuestas
anteriores, proponen un modelo en el cual involucran sus herramientas tecnolgicas,
el modelo de Microsoft est definido en tres divisiones: aplicacin, servicio y
componente. La parte de aplicacin se refiere cuando el cliente consume un servicio
de algn proveedor, lo correspondiente al servicio es la comunicacin que existe
entre los proveedores y los consumidores, mientras que la parte de componentes
son los entornos soportados por las aplicaciones (Microsoft Corporation, 2004). En el
caso particular de Oracle, el modelo propuesto de SOA involucra la utilizacin de su
base de datos en combinacin con el lenguaje de programacin Java y est dividido
en tres capas: enlace, infraestructura y servicio (Wrigth y Reynolds, 2009).
Los modelos anteriores no difieren mucho y coinciden en la utilizacin de los
siguientes elementos dentro de un modelo SOA: usuarios, servicios, proveedores,
contrato, interfaces y aplicacin, siendo esto uno de los principales factores por lo
que el diseo de ABCSIS se baso en el documento SMART, adems de que
contiene una mejor estructura de los componentes SOA, facilita su comprensin,
incluye los elementos ms importantes de los modelos mencionados anteriormente y
particularmente interesante que no contiene herramientas propietarias de empresas
o proveedores de software.
Con el diseo de ABCSIS, las personas interesadas en desarrollo de software
podrn crear componentes adicionales que se conecten a SIABUC, por ejemplo, una
aplicacin Web una aplicacin mvil que incorpore 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 actualmente incorporadas en la versin completa
de SIABUC con interfaz tipo escritorio, sin embargo, el objetivo es encapsularlas
80
como servicios Web para generar componentes adicionales que funcionen de
manera interoperable.



4.2.1 Arquitectura ABCSIS
Una vez definido como la arquitectura ABCSIS est basada en SOA es necesario
detallar la manera con la que cada servicio es incorporado dentro de dicha
arquitectura. Para esto se diseo un modelo conceptual estructurado en cuatro capas
principales, las cuales son las siguientes, consumidores de servicio, arquitectura,
interfaces de servicio e implementacin del servicio, a continuacin, se describe cada
uno de estas capas y al final se muestra el modelo propuesto en la figura 19.

Consumidores del servicio
Esta capa la componen todas y cada una de las aplicaciones externas a SIABUC que
se quieran conectar de manera transparente a travs de los servicios
proporcionados.
Un ejemplo de ello es el siguiente: en el departamento de soporte tcnico de
SIABUC ha sido una sugerencia muy frecuente al inicio de cada ciclo escolar,
incorporar de manera automtica la informacin de los alumnos de nuevo ingreso
que sern potenciales usuarios de los servicios bibliotecarios, sin embargo,
actualmente lo hacen de forma manual o mediante la manipulacin directa de la base
de datos de SIABUC, lo cual, sino se tiene el debido cuidado puede causar
problemas muy graves en el funcionamiento de SIABUC, como por ejemplo colocar
usuarios con permisos de prstamo que no son adecuados, modificacin de los
campos llave de las tablas de la base de datos, alteracin en los nombres de los
campos, por mencionar algunos de los problemas mas frecuentes. Con la
incorporacin de un servicio utilizando la arquitectura ABCSIS que registre de
manera automtica esta informacin el problema puede quedar solucionado,
mediante el desarrollo de un sistema que consuma el servicio de registro automtico
81
de alumnos, lo que evita la manipulacin directa de la base de datos de SIABUC y la
captura individual de cada usuario.
Otro ejemplo de aplicacin puede ser la reservacin de libros, al igual que el
ejemplo anterior en la arquitectura ABCSIS se elabor un servicio para la consulta y
reservacin, de tal manera que el usuario puede consultar el acervo de la biblioteca y
si le interesa algn ejemplar en particular lo puede reservar (apartar) y
posteriormente pasar a recogerlo a la biblioteca.

Arquitectura
La arquitectura es la encargada de interconectar a los consumidores con los
servicios propiamente. Se caracteriza particularmente por la independencia entre
cada uno de los servicios y se basa en el intercambio de mensajes para el envo de
la informacin. Los elementos que la conforman son datos, bus de servicio, interfaz,
contrato, repositorio de servicio, los cuales, se encuentran basados en la estructura
de la arquitectura SOA propuesta por Krafzig, et al., (2004).

Interfaces de Servicio
Las interfaces son la puerta de entrada de cada uno de los servicios y su objetivo es
recibir los parmetros que el servicio interpreta.
Esta capa consiste de una serie de servicios organizados y que utilizan la
estructura de los servicios Web, esto permite que sean definidos de forma
independiente de la plataforma tecnolgica utilizada.
Para efectos de organizacin de la presente tesis, los servicios se han dividido
en tres grupos: acervo, alumnos y retroalimentacin, los cuales se encuentran
detallados en la seccin 4.2.5.

Implementacin del servicio
Es uno de los extremos en la comunicacin de los servicios, sta es la parte que
compete al proveedor, los proveedores son aquellas instancias que proporcionan los
medios adecuados para interconectar uno de los extremos entre la comunicacin
existente proveedor consumidor.
82
En este caso, el proveedor de servicio ser la base de datos de SIABUC, ya
que ser la encargada de proporcionar toda la informacin necesaria que el
consumidor necesita para la implementacin de una determinada aplicacin.
Figura 19. Modelo de la arquitectura ABCSIS



4.2.2 Entorno de Comunicacin
Para utilizar una arquitectura basada en SOA es necesario un mecanismo de
comunicacin entre los diferentes servicios proporcionados. Este medio de
comunicacin en SOA es llamado Enterprise Service Bus (ESB).
Aplicacin
ASP

Servicio
1
Internet



Arquitectura SOA

Servicio
2

Servicio
3

Servicio
4
Aplicacin
PHP
Aplicacin
VB
Bus de Servicio
Repositorio de Servicios
Contrato
Interfaz Datos
SIABUC Sistemas Legados Sistema
Externo
Consumidores de Servicio
Arquitectura
Interfaces de Servicio
Implementacin del Servicio
Usuario
83
El objetivo del ESB es el proveer interoperabilidad, conectividad,
transformacin de datos y direccionamiento de los sistemas que se comunican a
travs de servicios, esto es, un mecanismo de peticin-respuesta de un servicio
desde un consumidor hacia un proveedor. El ESB debe proveer habilidades que
negocien con la seguridad, fiabilidad y administracin de servicios, sin embargo, se
debe considerar un estndar como los servicios Web para ser un ESB, porque de
manera conceptual definen todo lo necesario para proveer la interoperabilidad entre
sistemas (Josuttis, 2007).
Una de las ventajas de utilizar los servicios en SOA es que estos se
encuentran basados en servicios Web con el formato XML, los servicios Web utilizan
de manera predeterminada el HTTP sobre el protocolo TCP, lo cual se puede
aprovechar en aquellos sistemas que utilicen algn firewall sin necesidad de cambiar
la reglas de filtrado que existan en la administracin interna de red. Esto debido a
que la mayora de las organizaciones protegen sus redes mediante la utilizacin de
estos sistemas para impedir ataques e intrusiones no deseadas cerrando casi todos
los puertos de comunicacin excepto el puerto 80, que es el que utilizan los
navegadores de Internet, este mismo puerto es el que utilizan los servicios Web y
debido a esto no resultan bloqueados ni tampoco se necesita hacer una
configuracin adicional para habilitar la comunicacin entre ellos.



4.2.3 Motor de datos y estructura de la base de datos
El motor de base de datos utilizado para el desarrollo de este trabajo es PostgreSQL
en su versin 8.2. PostgreSQL es un Sistema Manejador de Bases de Datos
(DataBase Management System - DBMS) cliente - servidor de cdigo abierto que
incorpora el modelo relacional y soporta lenguajes de consulta estndar SQL.
Funciona en plataformas UNIX, Linux y Windows NT/2000/2003/XP/Vista, adems,
puede ser usado con la mayora de los lenguajes de programacin incluyendo C,
C++, Perl, Python, Java, Tcl, PHP y Visual Basic (Matthew y Stones, 2005).
84
Dentro de las caractersticas ms importantes de este robusto motor de base
de datos destacan su capacidad de almacenamiento, misma que se puede apreciar
en la tabla 3 (PostgreSQL Global Development Group, 2008a).

Tabla 3. Capacidad de almacenamiento de PostgreSQL
Lmite Valor
Tamao mximo de la base de datos Sin lmite
Tamao mximo de los ndices por tabla Sin lmite
Cantidad de registros por tabla Sin lmite
Tamao mximo de la tabla 32 TB
Tamao mximo de un registro 1.6 TB
Tamao mximo de un campo 1 GB
Cantidad de columnas por tabla 250-1600

A continuacin, se presenta un ejemplo de diagrama entidad-relacin donde
se muestran las tablas necesarias para el apartado de reservacin de un libro
registrado en SIABUC. Una reservacin no se puede llevar a cabo sino existe el
nmero de adquisicin del ejemplar (nmero que identifica cada material bibliogrfico
dentro de la biblioteca) y el nmero de cuenta del alumno, una vez que la reservacin
ha sido efectuada no se puede eliminar el usuario, puesto que tiene una reservacin
a su cargo.
Solo se muestra el apartado correspondiente a la reservacin debido a que el
prototipo implementado es relacionado a este tpico. Cabe sealar que el diseo del
modelo de datos queda fuera del alcance de la tesis puesto que el sistema SIABUC
ya exista y se tom parte de su modelo de datos existente que tiene relacin con los
servicios que se implementaron en ABCSIS.
Las relaciones que se muestran en la figura 20 corresponden a lo siguiente: un
ejemplar solo puede tener una reservacin activa, por ejemplar se entiende cualquier
material registrado en SIABUC (libro, revista, tesis) existente en la biblioteca y cada
reservacin es hecha por un alumno.

85

Figura 20. Diagrama entidad-relacin para la reservacin de un ejemplar



4.2.4 Comunicacin con la base de datos
En algunas aplicaciones es necesario contar con ciertos parmetros de configuracin
para hacer flexible el programa y que cada persona lo personalice acorde a sus
necesidades, en ocasiones estos parmetros son colocados dentro del cdigo o en
archivos de configuracin.
Para el desarrollo de ABCSIS se utiliz el lenguaje de programacin Visual
Basic provisto en el Integrated Development Environment (IDE) de Visual Studio
2008, dentro del conjunto de archivos creados para cada servicio se encuentra un
archivo de configuracin en formato XML denominado web.config, este archivo
contiene valores de control para el servicio, dentro de esos valores destaca el
apartado con el cual se realiza la conexin a la base de datos, dicho apartado se
muestra en la figura 21. De esta manera, cuando el programador desarrolle un
cliente para consumir el servicio podr manipular los parmetros de conexin a la
base de datos, esto debido a que cada vez que se realiza una conexin al servidor
de PostgreSQL es necesario hacerlo mediante una autentificacin de usuario.
86







Figura 21. Parmetros de conexin a la base de datos PostgreSQL

A continuacin se describe cada uno de los elementos de esta cadena de conexin:
name:
Nombre de la conexin, este valor es constante y no se debe modificar, puesto que
es utilizado de manera interna por el servicio para hacer referencia al driver de
conexin de la base de datos.
connectrionString:
Representa la cadena de conexin a utilizar para autentificarse con el servidor
PostgreSQL, esta cadena de conexin esta conformada por varios elementos, sin
embargo los ms importantes son Server, Database, UserId y Password.
Server
Es utilizado para indicar el nombre o direccin IP del servidor que tiene
instalada la base de datos de PostgreSQL.
Database
Representa el nombre de la base de datos a conectar, en este caso es
siabuc9.
UserId
Representa el nombre de usuario para autentificarse ante el servidor de
PostgreSQL.
Password
Representa la clave para validar el inicio de sesin del usuario.

El servidor PostgreSQL cuenta con una librera especfica para realizar la
conexin con .NET llamada Npgsql.dll, sin embargo, cuando esta librera fue liberada
<connectionStrings>
<clear/>
<add name="PostgreSQLProvider" connectionString="Server=localhost;
Port=9000;Database=siabuc9;UserId=NombreUsuario;
Password=ElPassword;Encoding=UNICODE;Sslmode=Prefer;
Pooling=true;"/>
</connectionStrings>
87
no era totalmente compatible con las plataformas derivadas de Microsoft, es por eso
que, en el ao 2003 el equipo de desarrollo de Npgsql adopt un proyecto
denominado mono, con el objetivo de ofrecer una mejor compatibilidad y estabilidad
de dicha librera en las plataformas de los sistemas operativos Windows
(PostgreSQL Global Development Group, 2009b).
Mono, es un proyecto de libre distribucin auspiciado por Novell para
desarrollar proyectos Open Source en UNIX. El objetivo del proyecto mono es
permitir a programadores UNIX construir aplicaciones multiplataformas en .NET,
adicionalmente, implementa varias tecnologas de Microsoft que han sido enviadas al
European Computer Manufacturers Association (ECMA) para su estandarizacin
(Novell, 2009).
Para realizar la conexin a la base de datos fue necesario la utilizacin de dos
libreras: Npgsql.dll y Mono.Security.dll, ambas incluidas dentro del proyecto
denominado mono.
Una vez definida la base de datos, los parmetros de conexin y las libreras
necesarias para establecer la conexin, es necesario describir la forma en la que se
utilizaron esos elementos en el servicio.
Debido a que la librera de Npgsql es independiente de Visual Basic, es
necesario agregar su referencia correspondiente al cdigo y para utilizar los
componentes de dicha librera es necesario usar la sentencia Imports al inicio del
cdigo, tal como se muestra en la figura 22.



Figura 22. Conexin al servidor de PostgreSQL

Una ventaja adicional que se obtiene al realizar la conexin de esta manera es
que no se necesita realizar la cadena de conexin cada vez que se hace un servicio,
debido a que fue definida previamente en el archivo de configuracin web.config
mostrado en la figura 21.
Imports Npgsql
Using PgCon As NpgsqlConnection = New NpgsqlConnection( _
System.Configuration.ConfigurationManager.ConnectionStrings
("PostgreSQLProvider").ConnectionString)
' Lneas de cdigo
End Using
88
4.2.5 Descripcin de mdulos y componentes
Como ya se mencion anteriormente, los servicios a desarrollar se encuentran
organizados en tres grupos: acervo, alumnos y retroalimentacin, y cada servicio a
su vez contiene un conjunto de funcionalidades, las cuales son llamadas
operaciones, en la figura 23 se muestran los grupos de servicios de ABCSIS y a
continuacin se describen cada uno de stos con sus respectivas operaciones.
















Figura 23. Servicios y operaciones de ABCSIS

Servicio Acervo
Este servicio esta orientado a las acciones directas que se pueden realizar sobre
algn ejemplar (libro, cd, dvd, folleto, revista) y est conformado por las siguientes
operaciones: reservacin de ejemplares, bsqueda de usuarios, bsqueda de fichas
y verificacin de disponibilidad de un determinado material.


Servicio Acervo
Servicio
Alumnos
Servicio
Retroalimentacin
R
e
s
e
r
v
a

E
j
e
m
p
l
a
r

B
u
s
c
a
r

A
l
u
m
n
o

B
u
s
c
a
r

f
i
c
h
a

B
i
b
l
i
o
g
r

f
i
c
a

D
i
s
p
o
n
i
b
i
l
i
d
a
d

d
e

e
j
e
m
p
l
a
r
e
s

R
e
g
i
s
t
r
o

d
e


u
s
u
a
r
i
o
s

V
e
r
i
f
i
c
a
c
i

n

d
e

a
d
e
u
d
o
s

V
e
r
i
f
i
c
a
c
i

n

d
e

m
u
l
t
a
s

D
e
t
a
l
l
e

p
r

s
t
a
m
o
s

p
e
n
d
i
e
n
t
e
s

R
e
n
o
v
a
c
i

n

d
e

e
j
e
m
p
l
a
r
e
s

D
e
t
a
l
l
e
s

p
r

s
t
a
m
o
s

h
i
s
t

r
i
c
o
s

L
i
s
t
a
d
o
s

d
e

e
s
c
u
e
l
a
s

R
e
g
i
s
t
r
o

d
e

i
n
c
o
n
f
o
r
m
i
d
a
d
e
s

L
i
s
t
a
d
o

d
e

i
n
c
o
n
f
o
r
m
i
d
a
d
e
s

R
e
s
p
u
e
s
t
a


i
n
c
o
n
f
o
r
m
i
d
a
d

S
u
g
e
r
e
n
c
i
a

d
e

c
o
m
p
r
a
s

C
o
m
e
n
t
a
r
i
o
s

s
o
b
r
e

t

t
u
l
o
s

ABCSIS
89
Operacin para reservar un ejemplar
Actualmente, cuando el usuario necesita reservar algn ejemplar lo hace va
telefnica o acude fsicamente a la biblioteca para hacer la reservacin, con este
operacin podr hacerlo desde cualquier computadora que tenga implementado
el servicio. La operacin recibe tres parmetros: el nmero de cuenta del usuario,
nip (clave de acceso) y el nmero de adquisicin del libro, retorna un mensaje
indicando si la reservacin tuvo xito o en caso contrario un mensaje de error.




Figura 24. Operacin para hacer reservaciones

Operacin para buscar un alumno
Antes de hacer la reservacin de un libro es necesario autentificar al usuario, este
es el objetivo de esta operacin, bsicamente consiste en validar el registro del
alumno en la base de datos de usuarios de SIABUC. La interfaz de esta
operacin recibe el nmero de cuenta del usuario y retorna verdadero si esta
registrado en la base de SIABUC falso en caso contrario.



Figura 25. Operacin para buscar un alumno en la base de datos

Operacin para buscar una ficha bibliogrfica
Realiza la bsqueda de una ficha dentro de la base bibliogrfica de SIABUC y
obtiene su informacin general: ttulo, autor, editorial, ISBN, temas. Esta
operacin es una de las ms importantes, puesto que con ella se obtiene la
informacin general del material bibliogrfico de una biblioteca, su interfaz recibe
cinco parmetros, los cuales se listan a continuacin:
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function Reservar(ByVal NoCta As String, ByVal NiP As String,
ByVal NoAdq As String) As String
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function BuscaAlumno(ByVal NoCta As String) As Boolean
90
TipoDeBusqueda. Este parmetro se utiliza para seleccionar uno de entre
cuatro tipos de bsquedas posibles 0-ISBN, 1-Ttulo, 2-Autor, 3-
Clasificacin, 4-No. de Adquisicin.
TerminoDeBusqueda. Es una cadena que indica el trmino a buscar dentro
de la base de datos.
FichaNext. Este parmetro se utiliza para indicar el nmero de ficha
siguiente a visualizar, este parmetro se utiliza bsicamente para control
interno y visualizacin de la informacin.
FichaPrev. Es similar al anterior, e indica la ficha anterior a visualizar.
NoPag. Representa el paginado de resultados.
La informacin que retorna esta operacin se encuentra agrupada en un
arreglo, el cual esta conformado por los siguientes elementos: autor, clasificacin,
estado del ejemplar (prestado, en mantenimiento), ISBN, nmero de adquisicin y
ttulo del material bibliogrfico registrado en SIABUC.





Figura 26. Operacin para buscar una ficha bibliogrfica en la base de datos

Operacin para consultar la disponibilidad de ejemplares
Informa acerca del estado actual de un ejemplar: prestado, reservado en
mantenimiento. La interfaz de esta operacin de servicio recibe como parmetro
el nmero de adquisicin de un libro y el valor que retorna al igual que la
operacin anterior es un arreglo con la siguiente informacin: no. de adquisicin,
identificador de biblioteca (valor numrico), no. de ejemplar, no. de volumen, no.
de tomo y el estado actual del ejemplar (prestado, disponible).



Figura 27. Operacin para obtener la disponibilidad de un ejemplar
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function BuscarFicha(ByVal TipoDeBusqueda As Byte, ByVal
TerminoDeBusqueda As String, ByVal FichaNext As
Double, ByVal FichaPrev As Double, ByVal NoPag As
Integer) As RegistroABCSISFicha()
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function Disponibilidad2(ByVal NoFicha As Long) As
RegistroABCSISEjemplares()
91
Servicio Alumnos
Este grupo est orientado a las actividades directamente relacionadas con los
usuarios finales del sistema, los alumnos. Las operaciones que integran este servicio
son las siguientes: registro de los datos del usuario en SIABUC, verificacin de
adeudo, verificacin de multa, detalle de prstamos pendientes por entregar,
renovacin de ejemplares, detalle de prstamos histricos y listado de escuelas.

Operacin para actualizar/registrar los datos del usuario en SIABUC
El objetivo principal de esta operacin de servicio es la de incorporar a la base de
datos de SIABUC los alumnos de nuevo ingreso de una determinada institucin,
ya que anteriormente este proceso se realizaba manualmente manipulando
directamente la base de datos de SIABUC, lo cual es riesgoso sino se tiene el
cuidado adecuado. La interfaz de esta operacin de servicio recibe los siguientes
parmetros:
NumCuenta. Este parmetro se utiliza para grabar el nmero de cuenta
nmero de matricula del alumno.
Nombre. Representa el nombre del alumno.
Escuela. Parmetro de tipo entero que identifica a la escuela que
pertenece el alumno, para obtener este valor es necesario utilizar la
operacin ListarEscuelas.
Correo. Correo electrnico del alumno.
Domicilio. Parmetro de tipo cadena para grabar el domicilio del alumno
Colonia. Se utiliza para almacenar la colonia a la que pertenece el alumno.
Ciudad. Parmetro de tipo cadena para almacenar la ciudad del alumno.
CodPos. Representa el cdigo postal.
Telefono. Parmetro de tipo cadena para almacenar el telefono del alumno.
NumGrupo. Este parmetro es de tipo entero y se utiliza para asociar al
alumno a un conjunto de polticas de prestamo que previamente se tienen
definidas en el sistema SIABUC.
VigenciaIni. Inicio de vigencia del alumno, por lo regular esta vigencia se
otorga al inicio del ciclo escolar.
92
VigenciaFin. Fin de vigencia del alumno para el acceso a los servicios
bibliotecarios.







Figura 28. Operacin para registrar un usuario en la base de datos

Operacin para verificar adeudos
Cada fin de semestre en las distintas escuelas y facultades de la Universidad de
Colima se les solicita a los alumnos un comprobante, para obtenerlo, el alumno
debe acudir fsicamente a la biblioteca a solicitarlo. En el comprobante se hace
constar que el alumno no tiene ningn tipo de adeudo en la biblioteca, el adeudo
se puede generar porque an no han entregado algn libro, porque no ha saldado
alguna multa pendiente o simplemente porque esta bloqueado en el sistema
SIABUC por algn tipo de anomala hecha en la biblioteca.
Con esta operacin de servicio se evitar que el alumno acuda a la biblioteca
para obtenerlo, el servicio buscar dentro de una biblioteca en particular algn
tipo de adeudo y slo si el usuario no adeuda nada le permitir imprimir dicho
comprobante. La interfaz de este servicio recibe el nmero de cuenta del usuario
y retorna un valor numrico que corresponde al total de prstamos pendientes por
entregar sino adeuda nada entonces se le expedir la constancia correspondiente
de no adeudo.



Figura 29. Operacin para verificacin de no adeudos


<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function RegUsuario(ByVal NumCuenta As String, ByVal
Nombre As String, ByVal Escuela As Integer, ByVal
Correo As String, ByVal Domicilio As String, ByVal
Colonia As String, ByVal Ciudad As String, ByVal
CodPos As String, ByVal Telefono As String, ByVal
NumGrupo As Integer, ByVal VigenciaIni As String,
ByVal VigenciaFin As String) As String
<OperationContract()> _
Function VAdeudo(ByVal NoCta As String) As Integer
93
Operacin para verificar multas
Cuando el alumno entrega de forma tarda algn ejemplar, el sistema SIABUC
genera automticamente una multa, la cual consiste en cobrar cierta cantidad
monetaria dependiendo de los das de entrega tarda y de las polticas
administrativas de cada biblioteca.
En ocasiones, el usuario acude a la biblioteca y por alguna razn no trae la
cantidad que se le esta solicitando, entonces la multa es generada pero esta
pendiente por saldar, estas multas pendientes por saldar son las que la operacin
del servicio obtendr y le presentar al usuario as como el monto de cada una de
las multas.
La interfaz de esta operacin recibe como parmetro el nmero de cuenta del
usuario y retorna una estructura de datos con todas las multas que tuviera en ese
instante. La estructura que retorna esta integrada por los siguientes elementos:
fecha en la que se realiz la multa, monto de la multa y razn por la cual se
origin la multa.


Figura 30. Operacin para mostrar las multas pendientes por saldar

Operacin para obtener el detalle de prstamos pendientes por entregar
Esta operacin consiste en informar al usuario acerca de los ejemplares que tiene
pendientes por entregar a la biblioteca. De esta manera, puede verificar la fecha
de entrega y evitar una multa.
La interfaz de esta operacin de servicio recibe el nmero de cuenta del
usuario y retorna una estructura de datos con los siguientes elementos:
clasificacin del libro, fecha de entrega, fecha de prstamo, nmero de
adquisicin del ejemplar, cantidad de renovaciones, tipo de prstamo (en sala, a
domicilio, interbibliotecario) y el ttulo del ejemplar.



Figura 31. Operacin para obtener los prstamos pendientes
<OperationContract()> _
Function VMulta(ByVal NoCta As String) As RegistroABCSISMulta()
<OperationContract()> _
Function PPendientes(ByVal NoCta As String) As
RegistroABCSISpPendientes()
94
Operacin para renovar ejemplares
En la actualidad este servicio se realiza de dos maneras: va telefnica o el
usuario acude directamente a la biblioteca a realizar la renovacin. Esta
operacin consiste en dar una prorroga en el tiempo de entrega del ejemplar.
La interfaz de esta operacin recibe como parmetro el nmero de cuenta del
usuario y el nmero de adquisicin del ejemplar. Con la finalidad de que los
usuarios no abusen de este servicio se coloco un parmetro adicional llamado
RenovarUnaVez de tipo booleano, si el valor de este parmetro es verdadero
solamente se permitir renovar en una sola ocasin a travs de este medio, en
caso contrario, permitir hacer todas las renovaciones que previamente se
definieron como polticas de prstamo en SIABUC, otra de las funcionalidades de
este parmetro es que el bibliotecario tenga mayor incidencia en la renovacin, ya
que si observa que el libro en cuestin tiene demasiada demanda dar oportunidad
a otras personas de utilizarlo.




Figura 32. Operacin para renovar ejemplares

Operacin para obtener los detalles de prstamos histricos
Mediante esta operacin los usuarios podrn obtener un concentrado con
informacin de los ejemplares que han solicitado en la biblioteca durante un
periodo de tiempo. Esta interfaz recibe tres parmetros: el nmero de cuenta del
usuario, la fecha inicial y fecha final que se desea consultar en el reporte. Retorna
una estructura de datos que contiene informacin general de los ejemplares que
el usuario solicit.




Figura 33. Operacin para obtener los prstamos de un usuario
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function Renovar(ByVal NoCta As String, ByVal ElNiP As String,
ByVal NoAdq As String, ByVal RenovarUnaVez As
Boolean) As String
<OperationContract()> _
Function PHistoricos(ByVal NoCta As String, ByVal FInicio As
String, ByVal FFin As String) As
RegistroABCSISpHistoricos()
95
Operacin para obtener listado de escuelas
Esta operacin bsicamente se utiliza de manera interna con otras operaciones.
Recibe como parmetro un nmero mediante el cual se identifican a cada una de
las bibliotecas capturadas en SIABUC. Retorna una estructura de datos con el
identificador y el nombre de la escuela.




Figura 34. Operacin para obtener listado de escuelas

Servicio Retroalimentacin
Debido a que la Direccin General de Servicios Bibliotecarios de la Universidad de
Colima ha implantado un sistema de gestin de la calidad, se incorporaron algunos
rasgos para ayudar en este sentido. Este servicio est conformado por las siguientes
operaciones: registro de inconformidades, concentrado de inconformidades,
respuesta a una inconformidad, sugerencia de compra de bibliografa y comentarios
o recomendaciones sobre ttulos (valoracin, comentario, fecha)
Operacin para el registro de inconformidades
Con esta operacin se le brindar la oportunidad al usuario de emitir su libre
opinin acerca de algn tipo de servicio que se le proporcion en la biblioteca,
actualmente este proceso se hace de manera escrita.
La interfaz de esta operacin recibe el nmero de cuenta del usuario, su
nombre, un identificador que corresponde a la escuela que se registro en SIABUC
y la queja correspondiente. Retorna un mensaje el cual indica si la queja fue
guardada con xito.




Figura 35. Operacin para registrar una inconformidad
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function ListarEscuelas(ByVal IdBiblio As Integer) As
RegistroABCSISEscuela()
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function RpteQueja(ByVal NoCta As String, ByVal Nombre As
String, ByVal IdEscuela As Integer, ByVal LaQueja As
String) As String
96
Operacin para obtener un concentrado de inconformidades
Una vez que los usuarios han externado alguna inconformidad es necesario saber
cuales son para su posterior seguimiento o contestacin, esta operacin muestra
un concentrado con todas las quejas que aun no se han dado respuesta.
Esta interfaz no recibe ningn parmetro, sin embargo, retorna una estructura
de datos con las quejas que aun no han sido respondidas para que se les de el
seguimiento adecuado.



Figura 36. Operacin para listar las quejas pendientes por atender

Operacin para responder una inconformidad
Una vez que la queja fue emitida, es necesario darle seguimiento, es decir,
regresar una respuesta con el estado de la misma, si la queja fue leda, atendida
se llev a cabo la disposicin solicitada, esta ser la funcin a cubrir por parte
de esta operacin.
La interfaz de esta operacin recibe como parmetro un identificador de la
queja a responder, la respuesta a la queja y un valor booleano que indica si la
queja es aplicable al sistema de calidad. Esta operacin esta enlazada
directamente con la anterior, ya que la operacin concentrado de
inconformidades retorna un identificador que es necesario en la interfaz de esta
operacin.




Figura 37. Operacin para responder una inconformidad

Operacin de sugerencia de compra bibliogrfica
En algunas ocasiones los usuarios necesitan libros que no se encuentran en la
biblioteca por alguna razn, mediante esta operacin el usuario podr sugerir
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function ListarQuejas() As RegistroABCSISQueja()
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function RptaQueja(ByVal IdQueja As Long, ByVal Respuesta As
String, ByVal Aplica As Boolean) As String
97
acerca de las nuevas adquisiciones de libros. Esta interfaz recibe como
parmetros los datos generales del usuario, los datos generales del ejemplar que
esta sugiriendo y una razn en la cual el usuario explica el motivo de la compra.
Retorna un mensaje indicando si la sugerencia de compra fue guardada o no.





Figura 38. Operacin para hacer sugerencias de compras bibliogrficas

Operacin para emitir comentarios o recomendaciones sobre ttulos
Esta operacin consiste en emitir una breve resea acerca del contenido de algn
libro consultado por el usuario, es decir, si el usuario considera que el libro que
consult tiene un buen mal contenido y la razn por la cual opina de esa
manera, dichas reseas se encontrarn a la vista de cualquier otro usuario para
futuras referencias.
Esta interfaz recibe como parmetros los datos generales del usuario, los
datos generales del ejemplar, una calificacin del 0 al 10 la cual representara la
calidad del contenido del libro y la razn por la cual el usuario otorg esa
calificacin.





Figura 39. Operacin para emitir comentarios sobre ttulos consultados

Hasta aqu se abordaron los aspectos de diseo de ABCSIS, as como los
servicios que integran sta arquitectura, sin embargo, solo se menciono lo
relacionado a los parmetros que reciben, ahora, es necesario entrar en detalle
acerca de la manera con la que fueron elaborados haciendo uso del modelo de
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function SugCompra(ByVal NoCta As String, ByVal Usuario As
String, ByVal IdEscuela As Integer, ByVal ElTitulo As
String, ByVal ElAutor As String, ByVal LaEditorial As
String, ByVal ElISBN As String, ByVal LaSugerencia As
String) As String
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function RecTitulos(ByVal NoCta As String, ByVal Usuario As
String, ByVal IdEscuela As Integer, ByVal NumAdqui As
String, ByVal ElTitulo As String, ByVal ElAutor As String,
ByVal LaClasificacion As String, ByVal LaRecomendacion
As String, ByVal Calificacion As Integer) As String
98
programacin Windows Communication Foundation, estos detalles son explicados a
detalle en la siguiente seccin.
99
5. Desarrollo de ABCSIS
Esta seccin tiene como finalidad dar a conocer el procedimiento con el que se
crearon los servicios que forman parte de la arquitectura ABCSIS. Se encuentra
organizado por tres apartados, creacin del servicio, hosting del servicio e
implementacin del prototipo.
En el primer apartado, se aborda la manera mediante la cual se crearon los
servicios en el lenguaje de programacin Visual Basic 2008 en combinacin con la
tecnologa Windows Communication Foundation (WCF), se utiliz este lenguaje de
programacin debido a la familiaridad y conocimiento previo que ya se tenia con el
mismo, en el segundo apartado, se detalla la manera con la que se hosped el
servicio en el servidor Web Internet Information Server, mientras que en el tercer
apartado, se describe lo relacionado a la creacin del consumidor, en este caso, un
prototipo desarrollado en lenguaje de programacin PHP.
Antes de dar a conocer la forma mediante la cual se crearon los servicios, es
necesario mencionar la tecnologa con la cual fueron creados, debido a esto es
indispensable hablar acerca de WCF el cual forma parte del .NET Framework.
WCF conocido en sus inicios como Indigo, es un conjunto de tecnologas
orientado a servicios basado en el .NET Framework 3.0 cuyo objetivo principal es el
de simplificar el desarrollo de aplicaciones distribuidas seguras, confiables e
interoperables (Peiris y Mulder, 2007). Algunas de las ventajas que se obtienen al
utilizar este modelo de programacin son las siguientes:
Amplio soporte para los protocolos de los servicios Web (WS-I)
Uso implcito de los principios de desarrollo orientado a servicios
Una nica API para el desarrollo de sistemas

WCF maneja la infraestructura de comunicacin del sistema operativo
Windows Vista y ha sido extendido a Windows XP y Windows 2003 a travs del .NET
Framework 3.0.
Segn Microsoft Corporation (2009b), el .NET Framework (conocido
anteriormente como WinFX) es el modelo de programacin de cdigo administrado
100
de Microsoft para la creacin de clientes de Windows, servidores y dispositivos
mviles incrustados.
WCF provee la infraestructura de comunicacin que permite crear diversas
aplicaciones a travs de un modelo simplificado basado en servicios. Microsoft dio a
conocer esta tecnologa en su evento denominado Microsoft Product Developers
Conference en los ngeles California en el ao de 2003, desde entonces, esta
tecnologa ha venido evolucionando y en la actualidad se encuentra disponible en el
Framework 3.5 (Peiris y Mulder, 2007).
Los objetivos principales de WCF se basan principalmente en tres aspectos:
Unificacin de tecnologas existentes
Interoperabilidad a travs de plataformas
Desarrollo orientado a servicios













Figura 40. Interoperabilidad entre varios sistemas operativos

La interoperabilidad ha sido uno de los mas grandes problemas por resolver
para los proveedores de software, es por eso que empresas lderes en este mbito
como Microsoft, IBM, BEA y Sun formaron la organizacin Web Service
Interoperability (WS-I), la cual consiste en un conjunto de especificaciones que
Servicio
WCF
Mensaje
SOAP
Mensaje
SOAP
Sistemas
Legados
Linux Windows Solaris
101
permite a las aplicaciones comunicarse con otras en diferentes plataformas, en este
sentido WCF soporta todo el conjunto de protocolos WS-I.
El mtodo de comunicacin en WCF se encuentra basado en mensajes y el
protocolo de mensajes nativo para tal fin es SOAP, el cual, como ya se coment en
la seccin tres, es un estndar que permite la comunicacin con diferentes
tecnologas y plataformas de manera interoperable. En la figura 40 se puede apreciar
la interoperabilidad que se hace mediante SOAP, de esta manera haciendo uso de
WCF diversos sistemas heterogneos pueden coexistir.
Para utilizar todo el conjunto de WCF es necesario cubrir algunos
requerimientos de software, los cuales se detallan a continuacin: .NET Framework
3.0 o superior, sistema operativo Windows (XP sp2 o superior, 2003, 2008 Vista) y
el lenguaje de programacin Visual Basic 2005 o superior.
Cabe sealar que para el desarrollo de los servicios se utilizaron las siguientes
herramientas de software:
Visual Basic 2008
.NET Framework 3.5
Windows XP Professional Service Pack 3
Servidor Web Internet Information Server (IIS) 5.1

Una vez mencionada la tecnologa WCF tambin es necesario dar a conocer
los elementos necesarios para consumir un servicio, debido a que en los apartados
siguientes se mencionaran.
En la figura 41 se muestran estos elementos, dentro de los cuales, el elemento
primordial es el endpoint, adicionalmente existen elementos complementarios como
Behavior, Factory, Channel y Listener. Behavior se utiliza para hacer conversin de
mensajes para que el .NET los pueda interpretar, Factory permite la comunicacin a
travs de un canal de comunicacin especfico, Channel representa la forma
mediante la cual los protocolos son implementados y son los responsables de
transmitir un mensaje desde el cliente hasta el servicio y viceversa, finalmente
Listener es el encargado de aceptar los mensajes provenientes de los canales (Peiris
y Mulder, 2007, p. 54).
102
El endpoint es importante porque representa la puerta de entrada al servicio,
cada servicio puede tener varios endpoint, los cuales siempre se encuentran a la
espera de mensajes para el intercambio de informacin. Cada endpoint a su vez esta
compuesto por tres elementos: Address, Binding y Contract; los cuales son
conocidos con el prefijo ABC.















Figura 41. Modelo de programacin de WCF

El address se utiliza para ubicar o conocer la direccin del servicio, y permite
la comunicacin mediante el intercambio de mensajes. El address en WCF son
direcciones que definen el protocolo de comunicacin utilizado, la computadora
donde esta ejecutndose el servicio y la ruta del mismo. En la tabla 4 se muestran
las especificaciones para el elemento address.
Tabla 4. Especificaciones de Address
Seccin Address Descripcin
Transporte Define el protocolo o medio de transporte
PC Especifica el nombre de dominio completo de la
maquina
Puerto Es un apartado opcional y es especificado como
:numero_puerto
Ruta Es la ruta especfica del servicio. Se puede definir
nombres de rutas como directorios separados por una
diagonal. Ejemplo: /Biblio/ReservaLibro es la ruta de la
siguiente direccin: http://localhost/Biblio/ReservaLibro
103
De esta manera, el formato de una direccin de servicio queda estructurado
de la siguiente forma:
transporte://<pc>[:numero_puerto]/ruta1/ruta2
La direccin anterior es similar al URL de una pgina Web, el transporte puede
ser cualquier transporte soportado como HTTP, TCP, Microsoft Meesage Queuing
(MSMQ) Named Pipes, pc es el nombre del servidor donde esta hospedado el
servicio, numero_puerto es el puerto donde el servicio esta a la escucha de
peticiones y finalmente ruta se utiliza principalmente para diferenciar los servicios
hospedados en la misma mquina. Cabe sealar que los servicios correspondientes
a ABCSIS fueron hospedados utilizando el servidor IIS de Windows XP Professional,
de tal manera que el address de cada servicio quedo de la siguiente manera:
http://dominio/grupo_servicio/servicio.svc
Donde:
dominio representa la ruta de acceso a la computadora a travs de la red
grupo_servicio representa un directorio virtual dentro del servidor IIS
servicio.svc es el archivo que contiene informacin del servicio

El binding por su parte describe la forma en la que se establecer la
comunicacin entre el cliente y el servicio. WCF provee un conjunto de bindings que
se adaptan a las necesidades de cada aplicacin, los cuales se muestran en la tabla
5 (Microsoft Corporation, 2009a). Sin embargo, si alguno de estos bindings no
satisface nuestras necesidades, se puede crear uno personalizado identificndolo
con el atributo CustomBinding.
Los binding mostrados en la tabla 5 que comienzan con el prefijo Net son
exclusivos de la plataforma Windows, estos binding son utilizados en aquellas
aplicaciones donde la interoperabilidad no es requerimiento importante. Algunos
autores como Kim y Han (2006), y personas dedicadas al desarrollo de software
mencionan que los servicios Web no son del todo eficientes debido al tiempo de
procesamiento causado por la utilizacin de XML, sin embargo, este problema ha
quedado resuelto con la utilizacin de estos bindings, cuya funcin es la de enviar y
recibir informacin en forma binaria, con esto, se aumenta considerablemente el
104
desempeo de los servicios Web, la desventaja de utilizar este tipo de binding es que
son propietarios de la plataforma Windows.

Tabla 5. Bindings y sus caractersticas principales

Finalmente, el contract es un acuerdo entre dos o ms partes que especifican
los mensajes que sern intercambiados, as como los trminos y las condiciones de
esos mensajes.
Un contract es una declaracin que expone el comportamiento (contrato de
servicio), datos persistentes (contrato de datos) o la estructura del mensaje (contrato
de mensaje) (Peiris y Mulder, 2007).
Enlace Interoperabilidad Modo de
Seguridad (valor
predeterminado)
Sesin
(Predeterminado)
Transacciones Dplex
BasicHttpBinding Basic Profile 1.1 (Ninguno),
transporte,
mensaje, mixto
Ninguno,
(ninguno)
(Ninguno) n/a
WSHttpBinding WS Ninguno,
transporte,
(mensaje), mixto
(Ninguno),
transporte, sesin
confiable
(Ninguno),
S
n/a
WS2007Http
Binding
WS-Security, WS-
Trust, WS-
SecureConversation,
WS-SecurityPolicy
Ninguno,
transporte,
(mensaje), mixto
(Ninguno),
transporte, sesin
confiable
(Ninguno),
S
n/a
WSDualHttp
Binding
WS Ninguno,
(mensaje)
(Sesin confiable) (Ninguno),
S
S
WSFederationHttp
Binding
WS-Federation Ninguno,
(mensaje), mixto

(Ninguno), sesin
confiable
(Ninguno),
S

No
WS2007Federation
HttpBinding
WS-Federation Ninguno,
(mensaje), mixto
(Ninguno), sesin
confiable
(Ninguno),
S
No
NetTcpBinding .NET Ninguno,
(transporte),
mensaje
Sesin confiable,
(transporte)
(Ninguno),
S
S
NetNamedPipe
Binding
.NET Ninguno,
(Transporte)
Ninguno,
(transporte)
(Ninguno),
S
S
NetMsmqBinding .NET Ninguno,
mensaje,
(transporte),
ambos
(Ninguno) (Ninguno),
S
No
NetPeerTcpBinding Del mismo nivel Ninguno,
mensaje,
(transporte),
mixto
(Ninguno) (Ninguno) S
MsmqIntegration
Binding
MSMQ Ninguno,
(transporte)
(Ninguno) (Ninguno),
S
n/a
105
El contrato de servicio es el ms utilizado y es el encargado de exponer los
mtodos del servicio, tambin es conocido con el nombre de interfaz de servicio
comportamiento expuesto del servicio. Este tipo de contrato en .NET es representado
mediante clases con el atributo <ServiceContract()>, esta y otras clases estn
contenidas dentro de un namespace llamado System.ServiceModel, el cual, es
necesario invocar en Visual Basic para utilizar las funcionalidades de WCF. Un
namespace se utiliza como un sistema de organizacin y permiten clasificar y
presentar elementos de programacin que se exponen a otros programas y
aplicaciones (Microsoft Corporation, 2009c).
Una vez abordada la tecnologa WCF es conveniente describir la manera
mediante la cual se desarrollaron los servicios de ABCSIS, lo cual, se describe en el
siguiente apartado.






106
5.1 Creacin del servicio
Para crear un servicio haciendo uso de WCF se debe tomar en cuenta los siguientes
elementos: mtodo, contrato de servicio, operacin de servicio, contrato de datos,
manejo de errores, la ubicacin donde el servicio estar hospedado, el binding y un
archivo de configuracin del servicio.
El mtodo son todas aquellas funcionalidades que deseamos estn
disponibles en el servicio para que los consumidores las utilicen, cada servicio puede
estar compuesto por uno varios mtodos.
El contrato de servicio es el encargado de exponer los mtodos que integran
el servicio para que un cliente los pueda consumir, sin embargo, para poder exponer
estos mtodos es necesario indicarlo mediante el atributo operacin de servicio.
El contrato de datos es necesario para retornar valores cuando se invocan los
servicios (haciendo uso de mensajes), esto porque en WCF no se pueden retornar
tipos de datos puesto que la comunicacin esta basada en mensajes XML a travs
del protocolo SOAP.
Los errores por su parte son generados basados en el estndar SOAP, mas
adelante en esta misma seccin se mencionan los detalles para crear los
manejadores de errores.
Finalmente, cada servicio contiene un archivo de configuracin basado en
XML llamado web.config, este archivo contiene entre otras cosas, los parmetros de
conexin a la base de datos de SIABUC.
Dado que la metodologa para crear todos los servicios en ABCSIS fue la
misma, este apartado se enfocar solamente en la descripcin de un servicio en
particular, el servicio Acervo, el cual contiene el mtodo correspondiente a la
reservacin de libros.
El primer elemento a tener en cuenta en el desarrollo de servicio es el binding,
con ste se define la comunicacin entre el cliente y el servicio. Para el caso de
ABCSIS fue utilizado el BasicHttpBinding, ya que como se observ en la tabla 5, es
el nico que ofrece compatibilidad con la especificacin de los servicios Web WS-I
Basic Profile, y debido a esto durante la creacin del consumidor result ser el ms
interoperable entre los lenguajes de programacin Visual Basic 2008 y PHP. La
107
definicin del binding se hace en el archivo web.config, en la figura 42 se muestra un
extracto de ste archivo con el binding de ABCSIS, por su parte, el elemento address
no se defini puesto que los servicios se realizaron de manera local.








Figura 42. Binding de ABCSIS

Definidas las opciones de configuracin ahora se comenzar a describir lo
correspondiente a la creacin del servicio. Cada servicio esta definido por un
contrato, el cual se define mediante el atributo <ServiceContract()>, mientras que las
operaciones de servicio son declaradas con el atributo <OperationContract()>, estos
dos atributos forman parte del namespace System.ServiceModel.
En la figura 43 se muestra un extracto de cdigo del servicio Acervo, en dicha
figura se puede apreciar la utilizacin de los atributos <ServiceContract()> y
<OperationContract()>. Este servicio contiene varias operaciones incorporadas, tal y
como se describi en la seccin 4.2.5. Tambin se puede apreciar la definicin de la
interfaz del servicio y los mtodos que expone mediante la funcin Reservar.




Figura 43. Servicio Acervo

Como se puede observar en la figura anterior, la interfaz de servicio esta
marcada con el atributo <ServiceContract()> y tiene una operacin llamada Reservar,
la cual, tiene a su vez el atributo <OperationContract()>, si un mtodo no contiene
<ServiceContract()> _
Public Interface IAcervo
<OperationContract()> _
Function Reservar(ByVal NoCta As String, ByVal NoAdq As String) As String
End Interface
<service behaviorConfiguration="ServicioAcervo.AcervoBehavior"
name="ServicioAcervo.Acervo">
<endpoint address="" binding="basicHttpBinding"
contract="ServicioAcervo.IAcervo">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
108
este atributo no podr ser expuesto y por lo tanto no podr ser utilizado por un
consumidor.
La operacin Reservar regresa una cadena indicando si se llevo a cabo o no
una reservacin exitosa, sin embargo, en algunas ocasiones es necesario regresar
un conjunto de registros almacenados en la base de datos, para estos casos es
necesario definir un contrato de datos.
Los contratos de datos hacen la serializacin entre mensajes SOAP y objetos
.NET. Un contrato de datos es declarado con el atributo <DataContract()>, esta
compuesto por uno o varios elementos, los cuales son llamados miembros de datos,
los cuales son definidos con el atributo <DataMember()>, si un contrato de datos
contiene un miembro de dato que no esta marcado con dicho atributo no ser
serializado por el runtime de WCF.
En la figura 44 se puede apreciar la creacin de un contrato de datos que
corresponde a la operacin Disponibilidad2, el resultado de invocar esta operacin es
un valor del tipo RegistroABCSISEjemplares, sta, es una clase que esta compuesta
por seis miembros de datos identificados con el atributo <DataMember()>.
Figura 44. Definicin del contrato de datos
<ServiceContract()> _
Public Interface IAcervo
<OperationContract()> _
Function Disponibilidad2(ByVal NoFicha As Long) As RegistroABCSISEjemplares()
End Interface

<DataContract()> _
Public Class RegistroABCSISEjemplares
<DataMember()> _
Public NumAdqui As String
<DataMember()> _
Public IdBiblio As Long
<DataMember()> _
Public Ejemplar As Byte
<DataMember()> _
Public Volumen As Byte
<DataMember()> _
Public Tomo As Byte
<DataMember()> _
Public Estado As String
End Class
109
Hasta este momento se ha cubierto la parte correspondiente a la creacin del
servicio con su respectiva interfaz y contratos, sin embargo, en ocasiones ocurren
errores durante la invocacin del mismo. Para ello, el protocolo SOAP tiene una
forma especfica de retornar cdigos de error formateados mediante el atributo Fault,
el cual, debe especificar al menos dos valores; una descripcin del error generado y
un cdigo de error representado mediante un nmero.















Figura 45. Generacin del contrato de datos para el manejo de excepciones

WCF por su parte tambin provee esta caracterstica incorporada en la
creacin de los servicios mediante el atributo <FaultContract()>. Para hacer uso de
esta funcionalidad es necesario definir un contrato de datos similar al de la figura 45,
solamente que aqu existe una pequea diferencia al momento de crear los
miembros de datos, la diferencia consiste en agregar algunas propiedades para
especificar tanto la descripcin del error como el nmero de error generado, cabe
sealar que con la utilizacin del modelo de programacin WCF, el programador solo
se preocupa por la definicin del servicio y su funcionalidad, la generacin de
<DataContract()> _
Public Class ABCSISFault
Private r_operacion As String
Private r_tipoproblema As String
<DataMember()> _
Public Property Operacion() As String
Get
Return r_operacion
End Get
Set(ByVal value As String)
r_operacion = value
End Set
End Property
<DataMember()> _
Public Property TipoProblema() As String
Get
Return r_tipoproblema
End Get
Set(ByVal value As String)
r_tipoproblema = value
End Set
End Property
End Class
110
mensajes SOAP lo hace de manera transparente el Common Language Runtime
(CLR) provisto en el .NET Framework, de esta manera se agiliza bastante el proceso
de creacin de los servicios.
La manera con la que se atrapan los errores es muy similar a otros lenguajes
de programacin mediante la instruccin try-catch, dicha instruccin es mostrada en
la figura 46.








Figura 46. Invocacin de una excepcin

Si ocurre un error, esta instruccin devuelve un valor del tipo ABCSISFault y a
su vez, regresa una descripcin del cdigo de error mediante la variable DescError,
as como el nmero de error correspondiente mediante la variable NumError, todo
esto formateado en mensajes XML para utilizarse con el protocolo SOAP.
Finalmente, la definicin completa del servicio con sus respectiva interfaz,
<OperationContract()> y <FaultContract()> quedara de la forma mostrada en la
figura 47.
Figura 47. Definicin del servicio

Una vez creado el servicio es momento de compilarlo, al momento de hacer
esto, Visual Basic genera varios archivos, sin embargo, solo nos interesan algunos
Public Function Reservar(ByVal NoCta As String, ByVal NoAdq As String) As
String Implements IAcervo.Reservar
Try
'Conjunto de instruccciones
'
'
Catch ex As Exception
Dim ErrorFault As New ABCSISFault
Throw New FaultException(Of ABCSISFault)(ErrorFault, _
New FaultReason(DescError), _
New FaultCode(NumError)
End Function
<ServiceContract()> _
Public Interface IAcervo
<OperationContract()> _
<FaultContract(GetType(ABCSISFault))> _
Function Reservar(ByVal NoCta As String, ByVal NiP As String, ByVal NoAdq As
String) As String
111
de estos; archivo de configuracin web.config, archivo con extensin .svc
(acervo.svc) y una carpeta llamada bin.
El web.config como ya se mencion es un archivo XML con parmetros
configurables para el servicio, el archivo acervo.svc contiene una directiva de
procesamiento que es ejecutada por .NET al momento de su invocacin, y
finalmente, la carpeta bin esta compuesta por libreras necesarias para el
funcionamiento del servicio. Estos archivos se describirn con mayor detalle en la
seccin 5.2.
De esta manera el servicio, su interfaz, address, binding y contract (ABC),
fueron implementados mediante WCF para cubrir los requisitos de una arquitectura
orientada a servicios mostrados en las figuras 16 y 19 del presente trabajo.
Hasta aqu se abordo lo correspondiente a la creacin del servicio, sin
embargo, para que un cliente lo pueda utilizar es necesario hospedarlo en un
servidor, este proceso es descrito a continuacin en la siguiente seccin.
112
5.2 Hosting del servicio
Una vez creado el servicio es necesario publicarlo para que pueda ser consumido
por algn cliente, existen dos formas de publicar un servicio, la primera es a travs
de un servidor Web y la segunda es a travs de un servicio de Windows. Para el
caso de ABCSIS los servicios creados fueron hospedados en el servidor Web IIS de
Windows XP y fue necesario instalar el Service Pack 3 y el .NET Framework 3.5,
este ltimo al momento de instalarse crea una cuenta de usuario llamada ASPNET la
cual gestiona la invocacin relacionada a WCF.
Figura 48. Cuenta de usuario ASPNET

Para hospedar correctamente un servicio es necesario instalar primero el
servidor Web IIS y posteriormente el .NET Framework, en el caso de una variacin
en el orden, puede presentarse un problema de acceso a la metabase de IIS con la
cuenta de usuario ASPNET. La metabase es una estructura que almacena
informacin de configuracin del servidor IIS.
Despus de tener instalado el IIS y el .Net Framework se procede a crear un
directorio virtual en el servidor, para este trabajo se cre un directorio llamado
ServicioAcervo. En la figura 49 se muestra la creacin del directorio virtual, mientras
que en la figura 50 se presenta el directorio virtual creado y los archivos necesarios
del servicio Acervo.
113

Figura 49. Creacin de un directorio virtual en IIS


Figura 50. Directorio virtual y archivos del servicio Acervo

Dentro del directorio virtual ServicioAcervo se colocaron los archivos
necesarios para hospedar el servicio en el servidor Web, los cuales se listan a
continuacin:
web.config Archivo de configuracin en XML
acervo.svc Contiene la definicin de implementacin del servicio
114
carpeta bin Esta carpeta contiene archivos y libreras necesarias para
implementar el servicio, dentro de las libreras destacan:
ServicioAcervo.dll, Npgsql.dll y Mono.Security.dll

Una vez que el servidor y el servicio estn listos para ser utilizados es
necesario hacer una prueba, la cual consiste en invocar el servicio mediante su
direccin Web correspondiente, siguiendo el ejemplo, el servicio acervo esta
hospedado en la carpeta ServicioAcervo, de tal manera que la URL para acceder a
su ubicacin quedara: http://localhost/servicioacervo/acervo.svc, en la figura 51 se
muestra su invocacin.
Figura 51. Servicio Acervo hospedado en IIS

De esta manera se puede verificar el funcionamiento correcto del servicio, sin
embargo, es necesario dar conocer toda la informacin que contiene.
Como ya se coment anteriormente ABCSIS se encuentra orientado a
servicios Web, un elemento importante de los servicio Web es el WSDL el cual se
encarga de describir la forma mediante la que puede ser consumido dicho servicio,
ABCSIS tambin cuenta con un WSDL el cual es generado de manera automtica
por el CLR de .NET Framework. Para tener acceso al WSDL del servicio Acervo
115
bastar con presionar el enlace mostrado en la parte superior de la figura 51 y
obtendremos algo similar a lo que se muestra en la figura 52.

Figura 52. WSDL del servicio Acervo

El WSDL es necesario para el programador, ya que de esta manera conocer
todas las operaciones del servicio as como la ubicacin del mismo, para finalmente
desarrollar un cliente que pueda consumirlo.
En el siguiente apartado se describe a detalle la forma mediante la cual se
creo un cliente en PHP para consumir el servicio Acervo.
116
5.3 Implementacin del prototipo
Una vez que el servicio ha sido programado y publicado entonces se puede crear un
cliente para consumirlo. Una de las ventajas de SOA es la interoperabilidad que
ofrece, se pueden desarrollar aplicaciones por ejemplo en Visual Basic ASP
utilizando el .NET Framework, mediante PHP haciendo uso de una extensin
exclusiva para SOAP, Java a travs de un proyecto denominado Web Services
Interoperability Techonologies (WSIT) (Sun Microsystems, 2007).
Este apartado corresponde a la creacin de un cliente Web que se
interconecte con SIABUC con la finalidad de hacer reservaciones de material
bibliogrfico, la aplicacin fue desarrollada en el lenguaje de programacin PHP
versin 5.2.6. La aplicacin Web consiste en hacer una bsqueda para localizar un
ejemplar mediante cinco apartados posibles: ISBN, ttulo, autor, clasificacin y no. de
adquisicin, una vez que se localiza el ejemplar se procede a reservarlo, para esto,
es necesario que el usuario proporcione dos datos para autentificarlo ante el sistema:
su numero de cuenta y una clave de acceso (nip) para hacer la reservacin, en la
figura 53 se muestra un diagrama de flujo con el funcionamiento del prototipo.















Figura 53. Diagrama de flujo para la reservacin
Ini
cio
NO
SI
Reserva
Exitosa
SI
NO
NO
SI
NO
SI
Hacer bsqueda
Hacer
Reserva
Mostrar
registros
Validar
Usuario
Mostrar
error
1
Nueva
Bsqueda
Encontr
Registro
1
Fin
Fin
SI
NO
Nueva
Bsqueda
1
Fin
117
La razn por la cual se eligi el lenguaje de programacin PHP es para
demostrar una de las principales funcionalidades que existe en ABCSIS, la
interoperabilidad.
PHP es un lenguaje de programacin basado en script orientado al desarrollo
Web y que se puede embeber dentro de cdigo HTML. La forma mediante la cual se
configura este lenguaje es a travs de un archivo de texto plano llamado php.ini, el
cual, controla varias funcionalidades y extensiones de este lenguaje.
Una de las extensiones requeridas para la comunicacin entre el proveedor y
el consumidor fue la relacionada con el protocolo SOAP, para hacer uso de esta
funcionalidad es necesario habilitar la librera php_soap.dll en el archivo php.ini, en la
figura 54 se muestra un extracto del archivo con la configuracin utilizada.








Figura 54. Archivo de configuracin de PHP

Para verificar que dicha extensin fue habilitada correctamente se realiz un
pequeo programa en PHP haciendo uso de la instruccin phpinfo, la cual nos
muestra la configuracin actual, en la figura 55 se muestra una seccin de sta
configuracin con la extensin SOAP instalada.






Figura 55. Configuracin correspondiente para el soporte de SOAP en PHP
118
Antes de iniciar con la programacin es necesario conocer la ubicacin donde
esta hospedado el servicio (el address) as como tambin las operaciones que son
necesarias en nuestra aplicacin, dichas operaciones son mostradas en la tabla 6 y
fueron extradas del WSDL mostrado en la figura 52.
Tabla 6. Operaciones de servicio utilizadas en el prototipo
Operacin Parmetro/Entrada Parmetro/Salida
BuscarFicha TipoBusqueda | Entero
TerminoDeBusqueda | Cadena
FichaNext | Entero Largo
FichaPrev | Entero Largo
NoPag | Entero
Arreglo
BuscaAlumno NoCta | Cadena Verdadero/Falso
Reservar NoCta | Cadena
Nip | Cadena
NoAdq | Cadena
Cadena
Disponibilidad2 NoFicha | Entero Largo Arreglo

Definido lo anterior, es momento de crear el cliente haciendo uso de la librera
php_soap, la cual nos provee soporte para crear clientes SOAP en PHP,
especficamente a travs de la instruccin SoapClient, dentro de los parmetros que
recibe se encuentra la direccin del WSDL del servicio, para nuestro ejemplo se cre
un constructor llamado $cliente con la sintaxis mostrada en la figura 56.


Figura 56. Constructor SoapClient para hacer referencia al servicio Acervo

A travs del constructor $cliente podemos acceder a todas las operaciones del
servicio mencionadas en la tabla 6, sin embargo, cada operacin requiere de algunos
parmetros para su funcionamiento.
La operacin BuscarFicha recibe cinco parmetros dentro de los cuales
destacan los dos primeros TipoDeBusqueda y TerminoDeBusqueda. El primer
parmetro es un valor entero para indicar el tipo de bsqueda donde: 0 representa al
ISBN, 1 al ttulo, 2 al autor, 3 a la clasificacin y 4 al no. de adquisicin, mientras que
el segundo parmetro es un valor de tipo cadena que indica el trmino a buscar.
Para mayor informacin acerca de los parmetros restantes favor de consultar la
seccin 4.2.5.
$cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl ");
119
Para acceder a estos parmetros es necesario utilizar el operador , el cual
hace referencia a una variable o un mtodo, de tal manera que el cdigo quedara de
la manera mostrada en la figura 57.







Figura 57. Invocacin de la operacin BuscarFicha

En la variable $busqueda se almacenan los parmetros de entrada de la
operacin mediante la instruccin $_POST, la cual, es necesaria para extraer el valor
pasado a travs de la pagina Web mostrada en la figura 58.
Figura 58. Interfaz para consulta y reservacin de libros

Por su parte la instruccin utf8_decode es necesaria para codificar el texto a
UTF8, posteriormente se invoca a la operacin BuscarFicha envindole la variable
$busqueda, despus se obtiene la respuesta en BuscarFichaResult, cabe mencionar
que para poder acceder al resultado de alguna operacin se debe agregar el prefijo
<?php
$cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl ");
$busquedaTipoDeBusqueda = $_POST['opciones'];
$busquedaTerminoDeBusqueda = utf8_encode($_POST['txtbuscar']);
$resp = $clienteBuscarFicha($busqueda);
$resp = $respBuscarFichaResult;
settype($resp, "array");
?>
120
Result al final del nombre de la operacin, independientemente del nombre que
contengan, es decir, para invocar a la operacin de bsqueda de la ficha se hace de
la siguiente manera BuscarFicha(parmetros), mientras que para acceder a los
valores de retorno se hace de mediante BuscarFichaResult(). Finalmente, mediante
la instruccin settype se convierte la variable $resp a un tipo array.
En caso de encontrar resultados con el trmino de bsqueda proporcionado
stos se muestran en una pgina Web similar a la de la figura 59.














Figura 59. Resultados de la consulta

Si el usuario encontr el ejemplar que necesitaba presiona la leyenda
Reservar, de lo contrario realiza otra bsqueda mediante el enlace Nueva
bsqueda. Si el alumno intenta reservar un ejemplar, el prototipo primero verifica
que el usuario se encuentre registrado en la base de datos de SIABUC, para esto
utiliza la operacin BuscaAlumno, lo cual es mostrado en la figura 60.
Figura 60. Invocacin de la operacin BuscaAlumno
<?php
$cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl ");
$lacuentaNoCta= $_POST['txtcuenta'];
$resp=$clienteBuscaAlumno($lacuenta);
$resp=$respBuscaAlumnoResult;
?>
121
Como se puede observar, la invocacin es similar a la de la figura 56, sin
embargo, aqu no fue necesario hacer uso de la instruccin settype, esto debido a
que esta operacin regresa un valor booleano y no un arreglo, como en el caso
anterior.
Siguiendo con el ejemplo prototipo, se eligi el ejemplar con no. de adquisicin
114586, si el usuario proporciona un nmero de cuenta o nip invlido aparecer un
mensaje como el que se muestra en la figura 61.
Figura 61. Usuario no encontrado en la base de datos

Sin embargo, para nuestro ejemplo se utiliz el nmero de cuenta 979663, el
cual corresponde a un usuario correctamente registrado en la base de datos de
SIABUC.
122















Figura 62. Usuario vlido

Finalmente, si el usuario esta correctamente registrado es momento de hacer
el ltimo paso, la reservacin, la forma de invocar esta operacin es como se
muestra en la figura 63.








Figura 63. Invocacin de la operacin Reservar

Si la reservacin se hizo correctamente aparece un mensaje con el texto
Reservacin con xito!!, en caso contrario nos aparecer un mensaje de error.
Para comprobar que la reservacin se hizo correctamente se realiz la misma
bsqueda, como se puede observar en la figura 64 ya no aparece el enlace para
realizar la reservacin, ahora muestra el estado reservado.
<?php

$cliente = new SoapClient("http://localhost/ServicioAcervo/Acervo.svc?wsdl ");
$resNoCta= $_POST['txtcuenta'];
$resNoAdq= $_POST['numadqui2'];
$res= $clientReservar($res);
$res= $resReservarResult;
echo utf8_decode($res);

?>
123














Figura 64. Ejemplar reservado

Sin embargo, en algunas ocasiones suceden errores, para esto, PHP
proporciona un constructor llamado SoapFault mediante el cual se puede atrapar el
error generado. En la figura 65 se puede observar la forma mediante la cual se utiliz
el contrato de datos ABCSISFault.








Figura 65. Generacin de excepcin de tipo SoapFault

Una vez definido el constructor se puede acceder a sus mtodos de la misma
manera que se hizo con las operaciones, mediante el operador . Hay que
<?php
try{
//Invocacin de operaciones
} catch (SoapFault $fault) {
echo "Ocurri el error ".str_replace("s:","",$faultfaultcode)." ".
utf8_decode($faultfaultstring)."\n\n";
echo "Operacion: ".$faultdetailABCSISFaultOperacion."\n";
echo "ProblemType: ".
utf8_decode($faultdetailABCSISFaultTipoProblema)."\n";
}
?>
124
recordar que el contrato de datos ABCSISFault retorna un mensaje y un nmero de
error en caso de presentarse alguna excepcin.
En la figura 66 se puede observar un error generado debido a una sentencia
Structured Query Language (SQL) mal formada.













Figura 66. Error en sentencia SQL

Hasta aqu, se mostraron los aspectos relacionados con la creacin,
hospedaje y manejo de errores con los servicios haciendo uso del modelo de
programacin WCF, la ventaja principal de crear los servicios utilizando este modelo,
es que el programador solo tiene que preocuparse por la definicin del servicio y su
funcionalidad, ya que la generacin de mensajes SOAP lo hace de manera
transparente el CLR provisto en el .NET Framework, de esta manera se agiliz
bastante el proceso de creacin de los servicios integrados en ABCSIS.

125
6. Pruebas
Sommerville (2005) menciona que las pruebas es un proceso que intenta
proporcionar confianza en el software, el objetivo principal de realizarlas es
convencer a los desarrolladores del sistema y a los clientes que el software es lo
suficientemente bueno para su uso operacional.
Esta seccin tiene como propsito detallar el proceso mediante el cual se
realizaron dos pruebas de software, prueba de operacin y prueba de rendimiento. El
objetivo de la prueba de operacin es que el usuario final instale el paquete de
ABCSIS y el CGI para que posteriormente opine mediante la contestacin de un
cuestionario acerca de su utilidad y facilidad de implementacin, mientras que el
objetivo de la prueba de rendimiento es el de conocer el comportamiento de ambas
implementaciones con un incremento gradual en las peticiones de consulta,
obteniendo los tiempos de peticin-respuesta para posteriormente graficarlos.
El prototipo de reservacin de libros de ABCSIS est compuesto por
bsquedas de material bibliogrfico, estado del material (prestado, disponible) y
reservacin (apartado), mientras que la implementacin CGI slo se encuentra
integrada por las bsquedas de libros.



126
6.1 Prueba de operacin
Esta prueba corresponde a una serie de experimentos cuyos participantes fueron
encargados del rea de sistemas, los cuales fueron seleccionados tomando como
base un perfil del rea de sistemas el cual se detalla posteriormente. El objetivo del
experimento consisti en instalar y comparar el prototipo de reservacin de libros
desarrollado con la arquitectura ABCSIS y la aplicacin CGI que SIABUC utiliza
actualmente. Los participantes expresaron su percepcin en relacin a la utilidad y
facilidad en la implementacin que obtuvieron al seguir los procesos para cada una
de las arquitecturas. Debido a que la aplicacin CGI solamente comprende un
apartado de bsqueda de libros, la prueba queda restringida a realizar el mismo
proceso con el prototipo de ABCSIS.

Perfil del usuario de prueba
Para seleccionar a los usuarios se busc que cumplieran ciertos requisitos
relacionados con el rea de informtica o afn. Los requisitos son: haber cursado la
carrera de licenciatura en informtica, ingeniera en sistemas ingeniera en
telemtica; contar con conocimiento previo en el sistema SIABUC; tener
conocimientos bsicos en estndares Web y en programacin; dominar el sistema
operativo Windows.
Las personas seleccionas son las encargadas de los centros de cmputo de
las bibliotecas incorporadas al sistema bibliotecario de la Universidad de Colima,
debido a las labores que realizan cotidianamente en su trabajo cuentan con un perfil
informtico-bibliotecario, gracias a esto, tienen experiencia tanto en el mbito de
sistemas como en el bibliotecario, cubriendo de esta manera el perfil de prueba
establecido.

Material
La prueba aqu presentada corresponde a una prueba de laboratorio, la
infraestructura utilizada para este experimento consisti de lo siguiente:
Hardware:
PC con procesador Intel
127
2 Gb de memoria RAM
10 Gb de espacio libre en disco duro

Software:
Windows XP Professional con service pack 3
Servidor Web Internet Information Server
Paquete con la implementacin CGI de SIABUC8 (WebPaqS8.zip)
Bases de datos de SIABUC8
Prototipo con la implementacin de reservacin de ABCSIS
Base de datos de SIABUC9
.NET Framework 3.5
PHP versin 5.2.6
VMware Workstation

Cabe sealar que en la computadora de prueba ya se tena previamente
instalado el SIABUC8 y el SIABUC9, as como el servidor Web IIS, esto con la
finalidad de que los participantes se dedicaran nica y exclusivamente a instalar y
probar las herramientas adicionales de SIABUC, el CGI y el prototipo de reserva de
ABCSIS.

Objetivo
Instalar, configurar y comparar el prototipo de reservacin de libros desarrollado con
la arquitectura ABCSIS y la aplicacin CGI que SIABUC utiliza actualmente.

Procedimiento
Para llevar a cabo las pruebas, a cada participante se le pidi evaluar el proceso de
instalacin de las implementaciones ABCSIS y CGI en el sistema operativo Windows
XP Professional, el cual fue instalado sobre el programa VMware.
VMware es un software de virtualizacin para computadoras de escritorio y
porttiles, su caracterstica principal es crear y ejecutar mltiples mquinas virtuales,
donde cada mquina virtual, representa un sistema operativo completo, incluyendo
128
procesador, memoria, dispositivos de red, perifricos (VMware Inc., 2009). La razn
de utilizar VMware es porque permita crear el mismo entorno de prueba para todos
los usuarios sin excepcin y que de esta manera ninguno tuviera ventajas o
diferencia alguna en cuanto al sistema operativo y aplicaciones previamente
instaladas.
Para que el participante realizara la prueba se le proporcionaron una serie de
documentos y aplicaciones necesarias, todos estos archivos se incluyeron en una
carpeta llamada Prueba_ABCSIS, la cual, contiene los siguientes archivos: Gua de
instalacin de ABCSIS, Gua de instalacin del CGI, Instalador de ABCSIS e
Instalador de PHP.

Figura 67. Entorno de prueba con Windows XP sobre VmWare

129
En la figura 67 se muestra el entorno de prueba con el sistema operativo
Windows XP ejecutndose sobre VmWare, adicionalmente, se puede observar la
carpeta Prueba_ABCSIS.
Dentro de la documentacin proporcionada a cada participante se especifica
una serie de instrucciones a seguir, las cuales se mencionan a continuacin de
manera general:
Instalacin del componente CGI
1. Instalar el paquete WebPaqS8.zip, este paquete contiene una
estructura y archivos necesarios para ejecutar la implementacin CGI
de SIABUC8.
2. Copiar las base de datos de SIABUC8
3. Crear un directorio virtual dentro del servidor Web en la siguiente
ubicacin C:\catalogos.
4. Asignar permisos de ejecucin de aplicaciones CGI en el servidor.
5. Asignar permisos de lectura/escritura a la cuenta de invitado para
Internet, esta es una cuenta que comnmente comienza con el prefijo
IUSR y es necesario habilitar stos permisos de lo contrario la
implementacin CGI no funciona correctamente.
6. Realizar una consulta en la interfaz de bsqueda.

Instalacin del prototipo de reservacin de ABCSIS
1. Instalar el paquete de ABCSIS.
2. Crear los directorios virtuales correspondientes para la implementacin
ABCSIS.
3. Verificar la correcta instalacin de ABCSIS mediante la invocacin del
servicio Acervo.
4. Configurar la conexin a la base de datos de SIABUC9, este proceso
se hace en un archivo llamado web.config.
5. Instalar el lenguaje de programacin PHP en conjunto con la extensin
SOAP, esta librera es necesaria para poder acceder a la estructura del
servicio Acervo.
130
Al terminar de instalar las dos implementaciones se le proporcion al usuario
una gua operativa, en ste documento se le pidi realizar algunas consultas en
ambas interfaces y posteriormente se le aplic un cuestionario (para mayor detalle,
consultar Anexo), finalmente se le dio la palabra al participante para darle la
oportunidad de aclarar las dudas con respecto a la prueba.
El objetivo del cuestionario es conocer la percepcin del participante mediante
la medicin de las siguientes variables:
Experiencia del participante
Facilidad de instalacin/configuracin
Documentacin proporcionada
Interconexin con otras aplicaciones como sistemas escolares o
administrativos de las instituciones usuarias de SIABUC

En el cuestionario fue aplicado a ocho personas y se utiliz la escala de Likert
como instrumento de medicin. La escala de Likert se utiliza para medir las actitudes
o predisposiciones de manera individual en contextos sociales, se construye en base
a una serie de preguntas que reflejan una actitud positiva o negativa acerca de un
estmulo, regularmente cada pregunta esta compuesta de cinco a siete alternativas
de respuesta (vila, 2006).



6.1.1 Resultados
Para la obtencin de los resultados de sta prueba se aplic un cuestionario basado
en la escala de Likert, el cuestionario se encuentra estructurado por ocho preguntas,
las cuales, estn compuestas por cinco tems de respuesta, cada tem tiene un valor
numrico en la escala del uno al cinco, el uno corresponde a la respuesta donde el
usuario esta totalmente en desacuerdo con la pregunta, mientras que el cinco
corresponde a la respuesta con la cual esta totalmente de acuerdo.
131
La forma de medicin del cuestionario se baso en sumar las respuestas
obtenidas y al final obtener un promedio, el cual estar en una escala del veinte al
cien por ciento. Del cuestionario aplicado se desprenden los resultados mostrados en
la tabla 6.





Tabla 7. Resultados de la encuesta aplicada en la prueba de operacin
Participante P1 P2 P3 P4 P5 P6 P7 P8 Total Prom. %
Experiencia en
programacin
2 4 2 2 5 4 4 5 28 3.5 70
Conocimiento WS 1 1 2 4 4 4 4 5 25 3.1 62
Instalacin ABCSIS
vs. CGI
5 5 5 5 5 4 5 2 36 4.5 90
Documentacin 5 1 5 5 5 5 1 5 32 4.0 80
Fcil configuracin
ABCSIS
5 2 4 5 5 4 4 3 32 4.0 80
Fcil configuracin
CGI
4 4 5 5 4 4 4 4 34 4.3 86
Interconexin de
ABCSIS con otros
sistemas
5 3 5 4 5 4 4 5 35 4.4 88
Evaluacin general
ABCSIS
5 4 5 5 4 4 5 4 36 4.5 90

En base a los resultados anteriores se puede apreciar que el setenta por
ciento de los usuarios encuestados cuentan con experiencia en el mbito de
programacin, esto debido a que la mayora de los encuestados son encargados de
centros de cmputo y su actividad principal no es el desarrollo de software, mientras
que en el aspecto de los conocimientos acerca de los protocolos relacionados con
los servicios Web solo el sesenta y dos por ciento los conoce.
Por otra parte, lo relacionado a la configuracin de ABCSIS el ochenta por
ciento opin que le result fcil de instalar, uno de los comentarios en ste sentido
fue que se tienen que hacer dos pruebas para verificar la correcta instalacin de los
componentes de ABCSIS (las pruebas consisten en invocar dos pginas Web), la
5 4 3 2 1 Valor de la escala
Total Total
acuerdo desacuerdo

100 80 60 40 20 % de la escala
132
instalacin del CGI por su parte no cuenta con un mecanismo similar, razn por la
cual obtuvo una mayor calificacin en ste sentido.
Por su parte en el aspecto de instalacin el noventa por ciento de los usuarios
evaluados expresaron que la instalacin del prototipo de ABCSIS les result ms
fcil de realizar, debido a que cuenta con un asistente que gua al usuario durante
todo el proceso, mientras que el CGI es un paquete compactado que se tiene que
descomprimir para posteriormente copiar una serie de archivos manualmente.
En cuanto a la factibilidad de interconexin de ABCSIS con otros sistemas
administrativos el ochenta y ocho por ciento consider factible este proceso debido a
los servicios Web que trae incorporados y a su arquitectura basada en SOA.
Finalmente, el noventa por ciento de los usuarios encuestados consideraron
que esta nueva implementacin es buena para el sistema SIABUC.
La presente prueba se aplic a ocho participantes de los cuales tres fueron
mujeres y cinco hombres, el tiempo promedio que tardaron en realizar la prueba
oscilo entre una hora, a hora y media, cabe sealar que durante este tiempo veinte
minutos aproximadamente fueron consumidos por la instalacin del .NET
Framework.



133
6.2 Prueba de rendimiento
Las pruebas de rendimiento tambin conocidas como pruebas de estrs son
utilizadas para asegurarse que el sistema en cuestin pueda procesar su carga
esperada. Bsicamente, consiste en planificar una prueba donde la carga de trabajo
se incremente paulatinamente hasta que el rendimiento del sistema sea inaceptable
(Sommerville, 2005).
La prueba realizada en esta seccin consisti en hacer consultas a travs de
la red de la Direccin General de Servicios Bibliotecarios tanto de la implementacin
CGI como del prototipo de ABCSIS, el estudio se bas en realizar cinco pruebas con
cinco, cincuenta, quinientos y cinco mil peticiones de consulta, las cuales simulaban
a usuarios haciendo peticiones de consulta, debido a la variabilidad de la red se
realizaron varias pruebas para obtener un promedio estandarizado y posteriormente
observar el comportamiento de stas tecnologas mediante grficas de lneas.
Para la realizacin de esta prueba se utilizaron dos computadoras, una que
acto como servidor y otra que acto como cliente, la computadora servidor estaba
compuesta por un procesador Intel a 1.8 Ghz con 2 gb de RAM con las siguientes
aplicaciones instaladas:
Windows 2008 Server sobre WmWare
Implementacin de consulta de SIABUC8
Base de datos de SIABUC8
Prototipo de reservacin de ABCSIS
Base de datos de SIABUC9

Mientras que las caractersticas tcnicas de la computadora que se uso como
cliente son las siguientes:
Hardware:
Pc con procesador Intel Centrino Duo a 1.6 Ghz
2 Gb de memoria RAM
10 Gb de espacio libre en disco duro


134
Software:
Windows XP Professional con service pack 3
Aplicacin para simular las peticiones de consulta al servidor

Cabe sealar que se utiliz la misma informacin en ambas
implementaciones, es decir, la informacin contenida en la base de SIABUC8 se
convirti al formato de SIABUC9 para poderla utilizarla en el prototipo de reservacin
de ABCSIS, esto con la finalidad de consultar los mismos datos y que esto no
repercutiera en los tiempos de respuesta durante la prueba.
La prueba consisti en ejecutar una aplicacin en la computadora cliente para
simular las peticiones (figura 68), la cual se conecta va TCP al servidor y manda
solicitudes de consulta a travs del mtodo POST de HTML, cada peticin la realiza
con un intervalo de 100 milisegundos; dicha aplicacin fue elaborada en Visual Basic
6.0. Una vez que enviaba la peticin de consulta al servidor, este responda y la
aplicacin almacenaba los tiempos de peticin-respuesta en una bitcora en formato
de Excel, estos datos posteriormente se graficaron.


Figura 68. Aplicacin utilizada en la prueba de rendimiento

135
A continuacin, en la figura 69 se muestra el proceso de peticin-respuesta en
sta prueba.








Figura 69. Proceso de peticin-respuesta de la prueba de rendimiento

Para el caso de la prueba en la implementacin CGI se utiliz el mtodo
POST envindole como parmetros una serie de variables, las cuales se listan a
continuacin:
Txtlib. Se utiliza para colocar el parmetro de bsqueda
Cantidad. Es el nmero de registros a desplegar por pgina
FichaIni. Registro (ficha bibliogrfica) a partir de la cual comenzar a
desplegar los resultados obtenidos
ACERVO. Tipo de informacin a consultar, puede tener dos valores
LIBROS REVISTAS, para nuestro caso se opt por la bsqueda de
libros solamente.
ArchivoCFG. Archivo de configuracin con cdigo HTML que se utiliza
para desplegar los registros obtenidos en la bsqueda.

A continuacin, en la figura 70 se muestra la cabecera HTTP enviada a la
implementacin CGI, en dicha figura se aprecia tanto el mtodo POST como el
conjunto de parmetros enviados.




Pc-cliente
Pc-servidor
Bitcora
Excel
Enva peticiones
Responde a las
peticiones
Se almacena la
respuesta en
bitcora
136







Figura 70. Cabecera HTTP enviada a la implementacin CGI

Mientras que la respuesta obtenida se muestra en la figura 71, cabe sealar
que conforme se aumentaba la carga de peticiones stas respuestas tardaban arriba
de los sesenta segundos.












Figura 71. Respuesta exitosa por parte de la implementacin CGI

Para el caso de ABCSIS la peticin de consulta tambin se utiliz el mtodo
POST, como se mencion en la seccin 5.3 Implementacin del prototipo, para poder
utilizar cada servicio de ABCSIS es necesario hacer un constructor, para el presenta
trabajo este constructor fue hecho en el lenguaje PHP, la razn de hacerlo en ste
lenguaje fue para demostrar una de las caractersticas de ABCSIS la
interoperabilidad. A ste constructor, se le pasa como parmetro la direccin del
WSDL del servicio en cuestin, hecho lo anterior, se puede utilizar la interfaz del
HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.1
Date: Fri, 21 Aug 2009 03:39:05 GMT
X-Powered-By: ASP.NET

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Fri, 21 Aug 2009 03:39:05 GMT
X-Powered-By: ASP.NET
Connection: close
Content-Type: text/html
Cache-Control: public

<html>
<body>
<!-- Registros obtenidos en la bsqueda -->
</body>
</html>
POST /catalogos/cgi-bin/web_s8.exe HTTP/1.1
Host: 148.213.21.80
Content-Type: application/x-www-form-urlencoded
Content-Length: 74

txtLIB=mexico&Cantidad=10&FichaINI=1&ACERVO=LIB
ROS&ArchivoCFG=Lib_Gral.cfg
137
servicio, sta interfaz es la encargada de recibir los parmetros, que para ste caso
se le enviaron a travs del mtodo POST, la peticin de consulta es mostrada en la
figura 72.






Figura 72. Peticin de bsqueda en ABCSIS con el mtodo POST

Mientras que la estructura del script que recibe los parmetros es el que se
muestra en la figura 73.
















Figura 73. Script php que recibe los parmetros enviados con el mtodo POST

Como se puede apreciar tanto en la figura 70 como en la figura 72 las
variables txtlib y TerminoDeBusqueda contienen el mismo trmino, esto con la
<?php
//Creacin del constructor
$wsdl= 'http://148.213.21.80/ServicioAcervo/Acervo.svc?wsdl';
$cliente = new SoapClient($wsdl);

//Parmetros de bsqueda
$params->TipoDeBusqueda= $_POST['tipobusqueda'];
$params->TerminoDeBusqueda= $_POST['terminobusqueda'];
$params->FichaNext= $_POST['fichanext'];
$params->FichaPrev= $_POST['fichaprev'];
$params->NoPag= $_POST['nopag'];

//Invocacin de la operacin ValidaUsuario
$ws=$cliente->BuscarFicha($params);

//Obteniendo los resultados de la invocacin
$wsResult=$ws->BuscarFichaResult;

//Imprimiendo el resultado de la invocacin
settype($wsResult, "array");
for($i=0; $i<10; $i++)
{
//Imprimir en pantalla cada uno de los valores
}
?>
POST /pruebaabcsis/pruebaabcsis.php HTTP/1.1
Host: 148.213.21.80
Content-Type: application/x-www-form-urlencoded
Content-Length: 69

tipobusqueda=1&terminobusqueda=mexico&fichanext=1
&fichaprev=0&nopag=1
138
finalidad de que la informacin a consultar no fuera un factor determinante para que
una implementacin tuviera ventajas sobre la otra en el tiempo de respuesta y que la
prueba fuera en condiciones semejantes.
Posteriormente, en caso de obtener una respuesta correcta el servidor
responde con la cabecera HTTP la cual es mostrada en la figura 74.













Figura 74. Respuesta del servidor a una peticin de bsqueda en ABCSIS

Durante la ejecucin de sta aplicacin el prototipo ABCSIS demostr una
caracterstica que consista en lo siguiente, cuando se hacia la peticin del servicio la
primera ocasin tardaba entre treinta y cuarenta segundos en atender las consultas,
esto es un proceso normal debido a que tiene que instanciar los objetos del CLR de
.NET entre ellos el servicio de ASPNET, posteriormente las repuestas a las consultas
son muy rapidez y la mayora de stas se encuentran por debajo del segundo.
Otra de las cuestiones observadas fue la estabilidad que el prototipo de
ABCSIS mostr, ya que en situaciones con demasiada carga de trabajo siempre se
mantuvo en un rango de respuesta aceptable (por debajo de un segundo) mientras
que la aplicacin CGI a medida que la carga de trabajo aumentaba su rendimiento
disminua, esto demuestra una confiabilidad muy aceptable en el rendimiento de
ABCSIS.
HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.1
Date: Fri, 21 Aug 2009 04:02:17 GMT
X-Powered-By: ASP.NET

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Fri, 21 Aug 2009 04:02:17 GMT
X-Powered-By: ASP.NET
Connection: close
X-Powered-By: PHP/5.2.6
Content-type: text/html

<html>
<body>
<!-- Registros obtenidos en la bsqueda -->
</body>
</html>
139
Otro de los aspectos que se pudieron observar en la prueba fue que a medida
que la cantidad de peticiones aumentaba se quedaban algunos procesos del CGI
colgados en memoria llegando en ocasiones al cien por ciento de la utilizacin de la
sta, esto se puede apreciar en la figura 75 mediante la ejecucin de la aplicacin
CGI Web_s8.exe.

Figura 75. Mltiples procesos en ejecucin en la modalidad CGI (web_s8.exe)

Lo anterior no suceda con el prototipo de ABCSIS, en este caso la utilizacin
de los recursos utilizados en la computadora oscilaba entre el sesenta al sesenta y
nueve por ciento, esto se puede apreciar en la figura 76. El nico factor de lentitud
detectado durante las pruebas de ABCSIS fue cuando se iniciaba la primer peticin
de consulta ya que tardaba en iniciar el servicio Web de ABCSIS como se haba
mencionado anteriormente, sin embargo, este mecanismo solo se hace en una sola
ocasin y posteriormente la velocidad de respuesta es muy veloz, en las grficas
mostradas posteriormente se ver reflejado este dato.
Cabe sealar que esta prueba se realiz utilizando la red que cotidianamente
utiliza cualquier computadora de la Direccin General de Servicios Bibliotecarios,
140
razn por la cual no estaba exenta del trfico de Internet, debido a esto, en
ocasiones el servidor exceda en su tiempo de respuesta, por lo que se opt por
definir un patrn o normalizacin en el tiempo de respuesta, de tal manera que
aquellas consultas que tardaban ms de sesenta segundos en procesar fueron
tomadas como respuestas insatisfactorias tomando como tiempo de respuesta el
patrn de tiempo definido previamente.

Figura 76. Menor cantidad de recursos utilizados por el prototipo ABCSIS

A continuacin, en la siguiente seccin se muestran las grficas y la
informacin tomada en base a las pruebas de rendimiento realizadas.



6.2.1 Resultados
En esta seccin se muestran las grficas obtenidas en base a los tiempos de
respuesta por parte de las implementaciones CGI y el prototipo ABCSIS.
141
Como ya se mencion en el apartado anterior, se realizaron pruebas con
cinco, cincuenta, quinientos y cinco mil iteraciones, donde cada iteracin esta
representada por un evento y el tiempo de respuesta esta representado en
segundos.
A continuacin, se muestra la informacin relacionada a los tiempos de
ABCSIS y posteriormente se muestra lo relacionado al CGI. En la tabla 8 se muestra
la bitcora con los tiempos obtenidos en base a cada uno de los eventos, solo se
muestra la informacin relacionada a la prueba con cinco iteraciones por cuestiones
de espacio.
Tabla 8. Informacin de la prueba de ABCSIS con cinco eventos





En esta primera prueba se puede observar que el tiempo de respuesta de
ABCSIS es muy estable, a continuacin, en la figura 77 se muestra la grfica con el
promedio de los tiempos de respuesta, en sta figura se puede apreciar una lnea
que oscila aproximadamente en los diecisiete segundos.
Promedio de las pruebas en red con 5 eventos - ABCSIS
0
5
10
15
20
1 2 3 4 5
Usuari os
T
i
e
m
p
o

(
s
e
g
.
)
Eventos

Figura 77. Promedio de la prueba de ABCSIS con cinco eventos

EventoA EventoB EventoC EventoD EventoE Promedio
18.047 18.504 18.14 17.39 15.188 17.4538
17.953 18.426 18.015 17.281 15.079 17.3508
17.844 18.301 17.906 17.171 14.969 17.2382
17.719 18.21 17.797 17.062 14.86 17.1296
17.609 18.066 17.687 16.953 14.75 17.013
142
A pesar de que se realizaron pocos eventos el tiempo de respuesta esta por
arriba del promedio general de las dems pruebas, las cuales se podrn observar a
continuacin, la razn de esto es porque como se mencion en la seccin anterior
cuando se ejecuta por primera vez el servicio de ABCSIS tarda en instanciar algunos
de sus componentes en memoria.
Posteriormente se realiz la prueba con cincuenta eventos, en sta prueba
existe una gran diferencia en la velocidad de respuesta, puesto que mejor
considerablemente, anteriormente el promedio oscilaba en los diecisiete segundos y
en esta prueba oscila entre .05 y .06 segundos.
En la figura 78 se puede observar el promedio de los tiempos de respuesta, en
sta figura se aprecia una diferencia de tiempo con respecto a la grfica mostrada en
la figura 77.
Promedio de las pruebas en red con 50 eventos - ABCSIS
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49
Usuari os
T
i
e
m
p
o

(
s
e
g
.
)
Eventos

Figura 78. Promedio de la prueba de ABCSIS con cincuenta eventos

Despus se realiz una prueba aumentado la carga de trabajo, la cual
consisti en ejecutar 500 eventos, el promedio sta grfica es mostrado en la figura
79, una de las caractersticas observadas es que a pesar del incremento en la
cantidad de ejecuciones persiste una estabilidad en el tiempo de respuesta.
143
Promedio de las pruebas en red con 500 eventos - ABCSIS
0
0.02
0.04
0.06
0.08
0.1
0.12
1 30 59 88 117 146 175 204 233 262 291 320 349 378 407 436 465 494
Usuari os
T
i
e
m
p
o

(
s
e
g
.
)
Eventos

Figura 79. Promedio de la prueba de ABCSIS con quinientos eventos

Finalmente, se ejecut una prueba con cinco mil eventos, el promedio es
mostrado en la figura 80, en sta figura se puede observar que a pesar de la carga
de trabajo, el tiempo de respuesta se encuentra por abajo del segundo
aproximadamente.

Promedio de las pruebas en red con 5000 eventos - ABCSIS
0
0.2
0.4
0.6
0.8
1
1 359 717 1075 1433 1791 2149 2507 2865 3223 3581 3939 4297 4655
Usuari os
T
i
e
m
p
o

(
s
e
g
.
)
Eventos

Figura 80. Promedio de la prueba de ABCSIS con cinco mil eventos

Hasta aqu se mostraron las pruebas de rendimiento relacionadas con
ABCSIS, a continuacin, se muestra la informacin obtenida de las pruebas de
144
realizadas con el CGI. Al igual que en las pruebas anteriores, en la tabla 9 solo se
muestra los datos de los tiempos de respuesta correspondientes a la primer prueba
por cuestiones de espacio.
Tabla 9. Informacin de la prueba de CGI con cinco eventos





La primera prueba realizada fue con cinco eventos, la mayor parte de los
eventos realizados muestran un tiempo de respuesta aceptable y con cierta
semejanza ya que la mayora oscilaron sobre cuatro y cinco segundos de respuesta.
En esta prueba la aplicacin CGI respondi conforme a lo esperado, sin
embargo, en grficas posteriores se observar como a medida que la carga de
trabajo se va incrementando el rendimiento de la implementacin CGI se va
decrementando, a tal grado que en algunas ocasiones el tiempo de respuesta fue
superior a los sesenta segundos. El promedio de esta prueba se muestra en la figura
81, aqu se puede apreciar una lnea con un tiempo de respuesta por debajo de los
seis segundos, un tiempo de respuesta aceptable.
Promedio de las pruebas en red con 5 eventos - CGI
0
2
4
6
8
10
12
14
16
18
1 2 3 4 5
Usuarios
T
i
e
m
p
o

(
s
e
g
.
)
Eventos

Figura 81. Promedio de la prueba CGI con cinco eventos
EventoA EventoB EventoC EventoD EventoE Promedio
4.532 4.469 4.469 4.796 4.844 4.622
4.422 4.359 4.172 4.672 4.75 4.475
4.328 4.25 4.235 4.547 4.61 4.394
4.203 4.141 3.984 4.437 4.515 4.256
4.109 3.984 3.859 4.344 4.422 4.1436
145
Posteriormente, se realiz la prueba con cincuenta eventos, en esta prueba se
puede notar que el tiempo de respuesta se increment, sin embargo, a pesar de
esto, el tiempo de respuesta promedio sigue demostrando cierta estabilidad, ya que
se encuentra en once segundos aproximadamente.
Promedio de las pruebas en red con 50 eventos - CGI
0
5
10
15
20
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49
Usuari os
T
i
e
m
p
o

(
s
e
g
.
)
Eventos

Figura 82. Promedio de la prueba de CGI con cincuenta eventos

Despus, se aument la carga de trabajo a quinientos eventos, en sta
prueba se puede apreciar un incremento muy notable en los tiempos de respuesta ya
que algunos de stos superaron los sesenta segundos definidos como el mximo
tiempo de respuesta deseable, por lo que se opt por delimitar la grfica en este
intervalo.
Promedio de las pruebas en red con 500 eventos - CGI
0
10
20
30
40
50
60
70
1 29 57 85 113 141 169 197 225 253 281 309 337 365 393 421 449 477
Usuari os
T
i
e
m
p
o
s

(
s
e
g
.
)
Eventos

Figura 83. Promedio de la prueba CGI con quinientos eventos
146
El promedio de sta prueba tambin tiene un cambio significativo respecto a
las anteriores, en la figura 83 se puede observar que la estabilidad mostrada en las
pruebas anteriores aqu ya no esta presente, puesto que existe tiempos de respuesta
muy variables, los cuales se ven reflejados en crestas y valles, algunos de ellos muy
pronunciados en la grfica.
Finalmente, se realiz la prueba con ms carga de trabajo con el incremento
de cinco mil eventos, la mayora de los tiempos de respuesta en sta prueba
excedieron los sesenta segundos, debido a esto, en la figura 84 se puede observar
que los tiempos promedio de respuesta se encuentran aproximadamente en los
cincuenta segundos formando casi una lnea debido a que fueron acotados por
excederse del tiempo de respuesta deseable. Adicionalmente se puede observar
como al inicio de la prueba el tiempo de respuesta es bueno, sin embargo a medida
que sta avanza se va incrementando cada vez mas hasta llegar al lmite esperado.
Promedio de las pruebas con 5000 eventos - CGI
0
10
20
30
40
50
60
70
1 355 709 1063 1417 1771 2125 2479 2833 3187 3541 3895 4249 4603 4957
Usuari os
T
i
e
m
p
o

(
s
e
g
.
)
Eventos

Figura 84. Promedio de la prueba CGI con cinco mil eventos

En esta seccin se abordaron los detalles relacionados a las pruebas
realizadas de las implementaciones ABCSIS y CGI, se realizaron dos pruebas, la
primera de ellas orientada a los usuarios finales de las aplicaciones y la segunda al
rendimiento en situaciones de carga de trabajo considerables, en la siguiente seccin
se hace un anlisis de la informacin presentada y las conclusiones
correspondientes.
147
7. Resultados y conclusiones
En sta seccin se mencionan los resultados obtenidos durante la aplicacin de la
prueba de operacin y la prueba de rendimiento, los resultados se abordan desde un
punto de vista cuantitativo y cualitativo. Tambin, se mencionan las posibles
aplicaciones de la arquitectura ABCSIS que actualmente se encuentran disponibles,
como es el caso de una implementacin prototipo llamada iSIABUC, la cual funciona
como una distribucin front-end de ejemplo para los usuarios de SIABUC. Finalmente
se mencionan las recomendaciones para trabajo futuro y las conclusiones.

7.1 Anlisis de los resultados
Prueba de operacin
Durante esta prueba se evaluaron varios aspectos, desde la experiencia del
participante hasta la implementacin y facilidad de instalacin de las tecnologas CGI
y el prototipo ABCSIS. A continuacin se detallan cada una de ellas:
Experiencia del programador
Durante la realizacin de la prueba de operacin se pudo apreciar que el 70% de
los participantes cuentan con conocimientos en programacin, esto, a pesar de
que no son desarrolladores de software, ya que la mayora de ellos son
encargados de los diferentes centros de cmputo de las bibliotecas de la
Universidad de Colima.

Comparacin del proceso de instalacin de ABCSIS vs. CGI
En cuanto a la instalacin de ABCSIS el 90% de los participantes mencionaron
que este proceso fue ms sencillo que la instalacin del CGI, debido a que
ABCSIS cuenta con un asistente de instalacin que gua al usuario paso a paso
durante este proceso, mientras que el CGI no cuenta con esa funcionalidad.

Configuracin de ABCSIS vs. CGI y conocimiento de los servicios Web
En el aspecto de configuracin de ABCSIS el 80% de los participantes
mencionaron que les result fcil, slo el 62% manifest tener experiencia en
148
estndares y tecnologas Web, lo cual indica que el prototipo ABCSIS ha sido
apropiado, puesto que a pesar de que algunos participantes no tienen gran
experiencia en estas tecnologas lograron realizar la instalacin e implementar
satisfactoriamente el prototipo ABCSIS.

Interconexin de ABCSIS con otros sistemas y evaluacin general
Finalmente, el 90% de los participantes encuestados calificaron como bueno el
prototipo ABCSIS, y debido a la incorporacin de los servicios Web el 88%
consideran factible la interconexin de la arquitectura ABCSIS con otros sistemas.

Prueba de rendimiento
Tomando como base los datos obtenidos en la prueba de rendimiento de la seccin
6.2, se pudo observar que con la arquitectura ABCSIS se obtiene una estabilidad y
confiabilidad en los tiempos de respuesta a diferencia del CGI.
Esto se ve reflejado claramente en la prueba con mayor carga de trabajo realizada
con 5000 peticiones de consulta, en sta prueba, el tiempo de respuesta mayor fue
de .07 segundos con el prototipo ABCSIS, mientras que la misma prueba realizada
con la implementacin CGI la respuesta mayor fue de 48 segundos. Esta notable
diferencia a favor en los tiempos de respuesta, se debe a que ABCSIS no requiere
cargar en memoria un proceso por cada peticin recibida mientras que la aplicacin
CGI lo hace para cada una de estas peticiones, logrndose una gran confiabilidad en
situaciones de intensa carga de trabajo, garantizando de esta manera la respuesta
en el servicio de consultas a un nmero considerable de usuarios.




149
7.2 Conclusiones
La informacin obtenida en la prueba de operacin muestra que a pesar de que un
poco ms de la mitad (62%) de los participantes tiene experiencia en el uso de las
nuevas tecnologas, y con ciertas carencias de actualizacin profesional, cumplen
con sus funciones encomendadas de apoyo tcnico a las bibliotecas.
Esta realidad del perfil informtico identificada en la prueba, puede ser incluso
ms deficiente en otras instituciones. Para sostener esta aseveracin se cuenta con
la experiencia que se ha obtenido con ms de 5 aos brindando soporte tcnico a
infinidad de usuarios bibliotecarios e informticos de instituciones a nivel
Latinoamrica. Estas condiciones prevalecen en las instituciones que usan SIABUC,
donde son pocas las que tienen el apoyo continuo del personal de informtica, y por
eso es de suma importancia ofrecer un mecanismo tecnolgico que facilite las tareas
de instalacin, configuracin y puesta en marcha, donde la plataforma ABCSIS viene
a cubrir esta carencia.
Con los resultados obtenidos en las pruebas, se puede concluir que se ha
cumplido el objetivo de este trabajo, encapsular una gran funcionalidad y ofrecerla
para que los usuarios finales puedan incorporarla a sus desarrollos, incluso de
manera ms fcil y sencilla como se hacia con la plataforma anterior basada en CGI.
Tambin, en base al cuestionario realizado, la hiptesis ha quedado comprobada, ya
que el 88% de los encuestados consideran factible la interconexin de ABCSIS con
otros sistemas.
Actualmente ya se encuentra disponible una aplicacin funcional denominada
iSIABUC. El encargado de crear dicha aplicacin tambin particip en la prueba y le
result muy fcil realizar el acoplamiento de ABCSIS con la aplicacin front-end. La
aplicacin consiste en una interfaz Web para SIABUC que consume todos los
servicios que ABCSIS provee, desarrollando as un mecanismo que ofrece distintos
servicios va Web a la comunidad universitaria (Guedea, 2009). La direccin
electrnica para acceder a sta aplicacin es la siguiente:
http://siabuc.ucol.mx/s9mashup.
Las expectativas de este proyecto se han cumplido satisfactoriamente,
creando una metodologa de desarrollo de software basado en SOA para el software
150
SIABUC, con la finalidad de extender los servicios que actualmente se ofrecen en la
biblioteca a partir de la funcionalidad bsica existente en SIABUC.
151
7.3 Trabajo futuro
Para la creacin de la arquitectura propuesta en ste trabajo se utiliz la plataforma
Windows en combinacin con el .NET Framework que ste sistema operativo ofrece,
si se desea que ABCSIS funcione completamente de manera interoperable se
recomienda elaborarla mediante otro lenguaje de programacin, esto es factible de
realizar gracias al diseo propuesto basado SOA y a la implementacin de los
servicios Web, para el caso del presente trabajo se realiz bajo Windows debido a
que es la plataforma nativa del software SIABUC.
Adicionalmente se sugiere la creacin de los clientes para consumir los
servicios restantes de ABCSIS en los distintos lenguajes de programacin: PHP,
ASP, Visual Basic. En este sentido, se propone la creacin de una comunidad virtual
de desarrolladores de SIABUC donde participen los usuarios de las distintas
instituciones usuarias de SIABUC, para que compartan sus experiencias en la
utilizacin de sta nueva arquitectura a los usuarios que carezcan de conocimientos
en desarrollo de software. Y debido a que la arquitectura ABCSIS esta orientada a
servicios, stos se pueden extender fcilmente, identificando varias funcionalidades
para agregarlas a la versin ABCSIS 2.0, por ejemplo la creacin de un nuevo
servicio para obtener un listado de las reservaciones que tiene actualmente un
usuario.
Como aplicaciones futuras, los servicios de ABCSIS se pueden incluir en un
repositorio para que se compartan con otros usuarios sin que se lucre o se obtengan
beneficios econmicos, comerciales o de cualquier otra ndole, sin la previa
autorizacin de la Universidad de Colima y bajo la firma de un convenio especial de
colaboracin y desarrollo.
La finalidad de compartir las libreras es para desarrollar, por ejemplo,
aplicaciones adicionales para otras plataformas, aplicaciones para dispositivos
porttiles, entre otras. Y de esta manera consultar por ejemplo el estado de prstamo
de un determinado libro, consultar los adeudos por parte de un usuario en la
biblioteca, verificar los prstamos de libros que actualmente tiene el usuario.


152
Referencias

Albin, S. (2003). The Art of Software Architecture-Design Methods and Techniques.
Estados Unidos : Wiley Publishing.

Arcelli, F., Tosi, Ch. y Zanoni, M. (2008). Can Design Pattern Detection be Useful for
Legacy System Migration towards SOA?. Obtenido el 28 de Agosto de 2008 de la base
de datos de ACM.

vila, H. (2006). Introduccin a la metodologa de la investigacin. Consultado el 21 de
Julio de 2009, de http://www.eumed.net/libros/2006c/203/2k.htm

Brinati, A. (2003). Transformacin de los procesos productivos de una biblioteca
tradicional a una biblioteca virtual. Trabajo presentado en el 2o. Congreso Internacional
de Bibliotecologa, Documentacin y Archivstica (CIBDA), Septiembre, Bolivia.

Brown, P. (2008). Implementing SOA: Total Architecture in Practice. Estados Unidos:
Addison Wesley.

Cerami, E. (2002). Web Services Essentials. Distributed Applications with XML-RPC,
SOAP, UDDI & WSDL. Estados Unidos: OReilly.

Chappell, D. (2002). Java Web Services. Using Java in Service-Oriented Architectures.
Estados Unidos: OReilly.

Chen, I. y Huang Ch. (2006). An SOA-based software deployment management system.
Obtenido el 29 de Noviembre de 2007 de la base de datos de ACM.

Electronic Data System (2008). Service Oriented Architecture in the Airline Industry.
Consultado el 26 de Agosto de 2008, de
http://download.microsoft.com/download/a/7/0/a70394d4-164b-47e3-906d-
71275b6b6ae3/EDS%20and%20Microsoft%20WP_SOA%20in%20the%20Airline%20
Industry.pdf

Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology and Design. Estados
Unidos:Prentice Hall

Fremantle, P. (2002). Applying the Web services invocation framework. Consultado el 24
de Mayo de 2008, de http://www.ibm.com/developerworks/webservices/library/ws-
appwsif.html

Gonzlez, A. y Guarino, L. (2005). Platform-Independent Accesibility API: Accesible
Document Object Model. Obtenido el 15 de Mayo de 2008 de la base de datos de ACM.

Gorton, I. (2006). Essential Software Architecture. Alemania : Springer.

Grupo Sistemas Lgicos (2007a). Logicat 2 mil 7. Consultado el 3 de Noviembre de 2007,
en http://www.gsl.com.mx/logicat.html

153
Grupo Sistemas Lgicos (2007b). Aleph. Consultado el 3 de Noviembre de 2007, de
http://www.gsl.com.mx/ppt/aleph.pdf

Guruge, A. (2004). Web Services Theory and Practice. Estados Unidos: Elsevier Digital
Press.

Guedea, H. (2009). Mashup para los servicios de SIABUC. Tesis de Ingenieria, Facultad
de Telemtica, Universidad de Colima.

Herrera-Morales, JR., Campos, J. L., Serrano, E., Prez, L., Gutirrez, J. R. (2004).
Automatizacin de Bibliotecas con SIABUC. Mxico: Universidad de Colima.

Herrera-Morales, JR. (2006). Gua de referencia tcnica de la API WebS8DLL para
SIABUC. Mxico: Departamento de SIABUC. Universidad de Colima. Obtenido el 25 de
Febrero de 2008 de http://siabuc.ucol.mx/docs/APIWebS8DLL.pdf

Herrrera-Morales, JR. (2007). SIABUC: ms de 20 aos apoyando la automatizacin de
bibliotecas en Latinoamrica. Revista Iridia, Ao 2, Vol. 4, 84-89.

Hubbers, J., Ligthart, A. y Terlouw, L. (2007). Ten Ways to Identify Services. The SOA
Magazine, XII. Obtenido el 10 de Diciembre de 2007 de
http://www.soamag.com/I13/1207-1.pdf

INNOVATIVE Interfaces (2006). Millennium. Consultado el 3 de Noviembre de 2007, de
http://www.iii.com/mill/webopac.shtml

Josuttis, N. (2007). SOA in Practice. The Art of Distributed System Design. Estados
Unidos: Oreilly.

Juric, M., Loganathan, R., Sarang, P. y Jennings, F. (2007). SOA Approach to Integration.
XML Web Services, ESB, and BPEL in real-world SOA Projects. Reino Unido:Packt
Publishing.

Kajko-Mattsson, M., Lewis, G. y Smith D. (2007). A framework for roles for development,
evolution and maintenance of soa-based system. Obtenido el 15 de Septiembre de 2008
de la base de datos de ACM.

Kim, S. y Han, S. (2006). Performance comparison of DCOM, CORBA and Web Service.
Obtenido el 20 de Febrero de 2008 de
http://iec.cugb.edu.cn/WorldComp2006/PDP4837.pdf

Krafzig, D., Banke, K. y Slama D. (2004). Enterprise SOA: Service - Oriented Architecture
Best Practices. Maryland: Pearson Education.

Lewis, G., Morris, E., Smith, D. y Simanta, S. (2008). SMART: Analyzing the Reuse
Potential of Legacy Components in a Service-Oriented Architecture Environment.
Consultado el 18 de Septiembre de 2008 desde
http://www.sei.cmu.edu/publications/documents/08.reports/08tn008.html

Lugo, M. (2000). Las bibliotecas universitarias mexicanas: apuntes para un diagnstico.
Mtodos de Informacin, 7, 45-53.
154

Margolis, B. y Sharpe, J. (2007). SOA for the Business Developer-Concepts, BPEL, and
SCA. Canada: MC Press.

Matthew, N. y Stones R. (2005). Beginning Databases with PostgreSQL. From Novice to
Professional. New York, E.U.:Apress

Microsoft Corporation (2004). Understanding Service-Oriented Architecture. Obtenido el
14 de Agosto de 2009 de http://msdn.microsoft.com/en-
us/library/aa480021.aspx#aj1soa_topic5

Microsoft Corporation (2009a). Configuracin de enlaces proporcionados por el sistema.
Obtenido el 03 de Enero de 2009 de http://msdn.microsoft.com/es-
es/library/ms731092.aspx

Microsoft Corporation (2009b). Centro de desarrollo de .NET Framework. Obtenido el 21
de Abril de 2009 de http://msdn.microsoft.com/es-es/netframework/default.aspx

Microsoft Corporation (2009c). Namespace (Instruccin). Obtenido el 23 de Abril de 2009
de http://msdn.microsoft.com/es-es/library/0dx91cw5(VS.80).aspx

Misra, K. y Murthy, N. (2001). Using CGI Sripts to Develop a Generalizad On-line Timed
Examination and Grading System. Obtenido el 15 de Mayo de 2008 de la base de datos
de ACM.

Newcomer, E. (2002). Understanding Web Services: XML, WSDL, SOAP and UDDI.
Boston, Estados Unidos : Addison-Wesley.

Newcomer, E. y Lomow G. (2004). Understanding SOA with Web Services. Maryland:
Pearson Education.

Novell (2009). FAQ: General - Mono. Extrado el 04 de Enero de 2009 desde
http://www.mono-project.com/FAQ:_General#Basics

Object Management Group (2008). CORBA FAQ. Consultado el 3 de Junio de 2008, de
http://www.omg.org/gettingstarted/corbafaq.htm#VersionNumber

Online community for the Universal Description, Discovery and Integration OASIS
Standard (2008). Products UDDI. Consultado el 31 de Mayo de 2008, de
http://uddi.xml.org/products

Organization for the Advancement of Structured Information Standards. (2004a).
Introduction to UDDI: Important Features and Functional Concepts. Consultado el 28 de
Mayo de 2008, de http://uddi.xml.org/files/uddi-tech-wp.pdf

Organization for the Advancement of Structured Information Standards (2004b). UDDI
Spec TC. Consultado el 31 de Mayo de 2008, de http://www.oasis-
open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm

155
Organization for the Advancement of Structured Information Standards (2008a).
Reference Architecture for Service Oriented Architecture Version 1.0. Obtenido el 01 de
Septiembre de 2008, de http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.html

Organization for the Advancement of Structured Information Standards (2008b). SOA.
Obtenido el 09 de Septiembre de 2008, de http://www.oasis-
open.org/committees/tc_cat.php?cat=soa

Peiris, Ch. y Mulder, D. (2007). Pro WCF: Practical Microsoft SOA Implementation.
Estados Unidos: Apress

Ponce, H., Herrera-Morales, JR. y Gutirrez, P. (2004). SISOCOBI: Herramienta de
Solicitud de Compras Bibliogrficas para SIABUC basada en Web Services. Trabajo
presentado en el XVII Congreso Nacional y III Congreso Internacional de Informtica y
Computacin de ANIEI, Tepic Mxico.

PostgreSQL Global Development Group (2008a). PostgreSQL - About. Extrado el 25 de
Noviembre de 2008 desde http://www.postgresql.org/about/

PostgreSQL Global Development Group (2009b). Npgsql adopted into the Mono Class
Library. Extrado el 04 de Enero de 2009 desde
http://www.postgresql.org/about/news.124

Santana, P. (2002). Aplicacin de servicios Web en la reservacin de libros para usuarios
de SIABUC8. Trabajo presentado en el XV Congreso Nacional de Informtica y
Computacin de ANIEI, Octubre, Guadalajara Mxico.

SIRSI (s.f.). Sistema de Gestin Integrada de Bibliotecas Unicorn. Consultado el 15 de
Noviembre de 2007, de
http://www.sirsidynix.com/Resources/Pdfs/Solutions/Products/Unicorn-es.pdf

Software Engineering Institute (2008). How do you define software architecture?.
Consultado el 21 de Mayo de 2008, de
http://www.sei.cmu.edu/architecture/definitions.html

Sommerville, I. (2005). Ingeniera de Software, 7 Edicin. Madrid: Pearson Educacin.

Sun Microsystems (2007). The WSIT Tutorial. Obtenido el 07 de Enero de 2009, de
http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

Tari, Z. y Bukhres, O. (2001). Fundamentals of Distributed Object Systems. The CORBA
Perspective. Estados Unidos: John Wiley & Sons.

Universidad de Colima (2006). ISIS-MEXICO. Consultado el 3 de Noviembre de 2007, en
http://isis-mexico.ucol.mx/

VMware Inc. (2009). VMware Workstation. Consultado el 4 de Junio de 2009, en
http://www.vmware.com/products/ws/

156
Weerawarana, S., Curbera, F., Leymann, F., Storey, T. y Ferguson, D. (2005). Web
Services Platform Architecture: SOAP, WSDL, Ws-Policy, WS-Addressing, WS-BPEL,
WS-Reliable Messaging, and More. Estados Unidos : Pearson Education.

World Wide Web Consortium (2007a). SOAP Version 1.2. Consultado el 15 de Mayo de
2008, de http://www.w3.org/TR/soap12-part1/

World Wide Web Consortium (2007b). Web Services Description Working Group.
Consultado el 24 de Mayo de 2008, de http://www.w3.org/2002/ws/desc/

World Wide Web Consortium (2004). Web Services Glossary. Obtenido el 17 de Junio de
2008 de http://www.w3.org/TR/ws-gloss/

Wrigth, M. y Reynolds, A. (2009). Oracle SOA Suite Developers Guide. Reino Unido:
Publishing Ltd.





157
Anexos
Cuestionario de evaluacin de ABCSIS


Carrera cursada: _______________________________________Gnero: M ( ) F ( )

Instrucciones:
El presente cuestionario tiene como finalidad conocer la satisfaccin en la implementacin de
la arquitectura ABCSIS. Por favor, marque con una X el nmero que ms se acerque a su
eleccin, siendo el nmero 5 el valor que representa el mayor grado de satisfaccin, mientras
que 1 representa el menor grado.


1.- Tienes experiencia en programacin Web?
Si tengo experiencia 5 4 3 2 1 No tengo experiencia


2.- Conoces el paradigma de los servicios Web y los protocolos en los que se fundamenta?
Si lo conozco 5 4 3 2 1 No lo conozco


3.- La arquitectura de ABCSIS te resulto fcil de configurar?
Fcil 5 4 3 2 1 Difcil


4.- El proceso de instalacin de ABCSIS fue fcil comparado con la instalacin del CGI?
Fcil 5 4 3 2 1 Difcil


5.- La documentacin de ABCSIS comparada con la del CGI fue buena?
Buena 5 4 3 2 1 Mala


6.- Cmo te resulto el proceso de configuracin del CGI?
Fcil 5 4 3 2 1 Difcil


7.- Consideras que con la arquitectura ABCSIS seria factible la interconexin de SIABUC con
otros sistemas administrativos o escolares de tu institucin?
Muy factible 5 4 3 2 1 Nada factible


8.- En trminos generales como consideras esta nueva implementacin para SIABUC?
Buena 5 4 3 2 1 Mala



Gracias por tu participacin!!!
158
Glosario

Back-end Es la parte que procesa los datos que el usuario introdujo. Se caracteriza
por estar oculto al usuario.

Business Process (Proceso de negocio) Es un conjunto de medidas vinculadas o
actividades que en su conjunto resultan de un negocio especfico, ya sea interno o
externo a la organizacin. Documentar los procesos de negocio incluye la
descripcin de lo que se hace, por qu se hace, cmo se hace, que (o qu sistema)
lo hacen, as como qu tan bien se hace.

Business Services (Servicios de negocio) Servicios preconstruidos basados en las
polticas y mejores prcticas de la industria. Son nicos y proveen un valor de alto
nivel.

Consumer (Consumidor) Son los clientes que accedan a los servicios.

Choreography (Coreografa) Define la secuencia y condiciones bajo las cuales
mltiples agentes independientes cooperan para intercambiar mensajes con el fin de
alcanzar un objetivo.

Framework Grupo de tareas relacionadas para administrar un programa o proyecto
de SOA.

Governance (Governabilidad) Define el modelo para asegurar la ptima
reutilizacin de servicios y la ejecucin de polticas corporativas (diseo de negocio,
diseo tcnico y aplicacin de seguridad)

Granularity (Granularidad) Modularidad de un servicio. El nivel de detalle de un
servicio.

Mainframes Es una computadora grande, potente y costosa utilizada principalmente
por una gran compaa para el procesamiento de una gran cantidad de datos; por
ejemplo, para el procesamiento de transacciones bancarias.

MARC MARC es el acrnimo de MAchine Readable Cataloging. Define el formato de
datos que surgi como iniciativa de la Biblioteca del Congreso de los Estados
Unidos. Provee el mecanismo mediante el cual las computadoras intercambian, usan
e interpretan la informacin bibliogrfica.

Middleware Software para ejecutar una conversin, interpretacin, consolidacin e
integracin en nombre de las aplicaciones de negocio.

OPAC Siglas de catlogo pblico de acceso en lnea. Es una interfaz para la
consulta de material bibliogrfico de una biblioteca.

159
Orchestration (Orquestacin) Es la secuencia y la prestacin de servicios
adicionales para procesar datos. Definicin de las reglas para el flujo de servicios en
un proceso.

Provider (Proveedor) Es el creador de los servicios.

Registry (Registro) Base de datos con la informacin de los servicios disponibles,
no incluye los servicios fsicamente.

Repository (Repositorio) Base de datos con la informacin de los servicios
disponibles.