TESIS, Integración e Interoperabilidad de Sistemas Informáticos (2007)

5/6/2018 TESIS, Integración e Interoperabilidad de Sistemas Informáticos (2007) - slidepdf.com

http://slidepdf.com/reader/full/tesis-integracion-e-interoperabilidad-de-sistemas-informaticos-2007 1/105

UNIVERSIDAD TECNOLOGICA METROPOLITANA

ESCUELA DE INFORMATICA

Interoperabilidad e Integracion de SistemasInformaticos de la Iglesia Catolica en Chile

TRABAJO DE TITULO PARA OPTAR AL

TITULO DE INGENIERO INFORMATICO

Profesor Guıa : Mauro Castillo Valdes

Alumno : David Castro Salinas

SANTIAGO - CHILE 2007

ii



...a mi familia, a mi novia y a la iglesia Cat´ olica.

iii



Agradecimientos

“Cumple tu la mision que te ha sido confiada, tu pequena mision, la que solo

tu puedes cumplir; tu solo en toda la creacion puedes llenar esa mision. Si no la

realizas quedara sin hacerse, ¡tu mision!, mision de generosidad.” (Padre Alberto

Hurtado)

Primeramente quisiera agradecer a Dios por el don de la Fe, y por todas las

experiencias tanto las malas como las buenas, las que han sido base para miformacion personal, tambien por darme una gran familia, que ha sido una cuna

de amor y de buenas ensenanzas.

Quiero agradecer a mis padres, David y Marıa Isabel, por incentivar mi for-

macion como profesional, por entregar las herramientas necesarias, y por todo su

amor y comprension en mis momentos de estres y mal genio. Tambien agradecer

a mis hermanas Ivette, Sandra y a mi sobrina Dayana. A mi ya fallecida Tıa Oli-

via, quien nos enseno el valor de la oracion, y nos acompana desde la morada del

Padre.

A mi novia Marilyn, quien ha acompanado y ayudado en la redaccion de latesis, y ha sido pilar fundamental en mis ultimos anos de estudiante.

A la Conferencia Episcopal de Chile, que ha permitido, financiado y acom-

panado en el desarrollo del proyecto de integracion. A Monsenor Cristian Con-

treras Villaroel, Obispo Auxiliar de Santiago y Secretario General de la CECH; a

Enrique Palet Secretario adjunto CECH para Gestion y Comunicaciones; a Jaime

Coiro, Director de Comunicaciones y Prensa CECH; Nilda Quezada, Directora de

la Oficina de Estadısticas para la Pastoral; y en especial, a mi gran amigo Carlos

Correa, Coordinador de la Comision Nacional de Informatica para la Pastoral y

Webmaster de Iglesia.cl.A mi profesor Guıa, el Doctor Mauro Castillo Valdes, quien acompano, esti-

mulo y corrigio el proyecto. Tambien le agradezco, sus consejos y la motivacion

para continuar con el proyecto en sus minutos cuando todo se nublaba.

A mis amigos y companeros de la universidad, a mis amigos de la Vicarıa de

Pastoral Universitaria, a mis amigos de la vida y a los que ya han partido.

Con mucho carino, les doy las gracias.

iv



´Indice

Agradecimientos IV

Tabla de contenidos V

Indice de Figuras VIII

Introduccion 1

Organizacion del Documento 2

1. LA INSTITUCION 31.1. Iglesia Catolica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. La Conferencia Episcopal de Chile . . . . . . . . . . . . . . . . . . 4

1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4. Motivacion Personal . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. FUNDAMENTACION TEORICA 10

2.1. Estado Actual de la Integracion de Sistemas . . . . . . . . . . . . 122.1.1. Analisis de Casos . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1.1. Tendencias en Europa . . . . . . . . . . . . . . . 13

2.1.1.2. Herramientas de Integracion Existentes . . . . . . 13

2.1.1.3. Bibliotecas Interconectadas . . . . . . . . . . . . 14

2.1.1.4. Proyecto Relpe . . . . . . . . . . . . . . . . . . . 15

2.2. Bases de Datos Federadas . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1. Definicion de Base de Datos Federada . . . . . . . . . . . . 17

2.2.2. Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.3.1. Capas del Esquema . . . . . . . . . . . . . . . . . 192.2.4. Sistemas Distribuidos Versus Sistemas Federados . . . . . 19

2.2.5. Soluciones Comerciales . . . . . . . . . . . . . . . . . . . . 20

2.3. Servicios Web (Webservices) . . . . . . . . . . . . . . . . . . . . . 22

2.3.1. WebServices . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.2. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.3. SOAP (Simple Object Access Protocol) . . . . . . . . . . . 23

2.3.4. UDDI (Universal Services Description Language) . . . . . 25

2.3.5. WSDL (Web Services Description Language) . . . . . . . . 25

2.3.6. Clase NuSoap . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4. Arquitectura Orientada a Servicios (SOA) . . . . . . . . . . . . . 27

v



2.4.1. Concepto Arquitectura Orientada a Servicios . . . . . . . . 27

2.4.2. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.3. Diseno y Desarrollo de un SOA . . . . . . . . . . . . . . . 28

2.4.4. Componentes de un SOA . . . . . . . . . . . . . . . . . . . 28

2.5. Seguridad Informatica . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5.2. Seguridad Fısica y Seguridad Logica . . . . . . . . . . . . 312.5.3. Principios de la Seguridad Informatica . . . . . . . . . . . 31

2.5.4. Criterios y normativas de seguridad . . . . . . . . . . . . . 32

2.6. Legislacion Europea sobre Interoperabilidad . . . . . . . . . . . . 34

2.6.1. Legislacion Europea . . . . . . . . . . . . . . . . . . . . . 34

2.6.2. Marcos de Interoperabilidad . . . . . . . . . . . . . . . . . 35

2.6.2.1. Objetivos del Marco de Interoperabilidad . . . . 35

2.6.3. Servicios Interoperables en Produccion . . . . . . . . . . . 37

3. SITUACION ACTUAL 38

3.1. Situacion Sin Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 403.1.1. Oficina de Estadısticas para la Pastoral . . . . . . . . . . . 41

3.1.1.1. Sistema Directorio Virtual de la Iglesia Catolica

en Chile . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.1.2. Modelo de Datos Nativo . . . . . . . . . . . . . . 42

3.1.2. Oficina de Comunicaciones de la CECH . . . . . . . . . . . 43

3.1.2.1. Sistema de Administracion de Contenidos (SAC) 43

3.1.2.2. Modelo de Datos Nativo . . . . . . . . . . . . . . 44

3.1.3. Portal Web Iglesia.cl . . . . . . . . . . . . . . . . . . . . . 45

3.1.3.1. Bases de Datos Iglesia.cl . . . . . . . . . . . . . . 45

3.1.4. Sistema de Archivo Historico de Documentos . . . . . . . . 47

3.1.5. Sistema de Archivo Historico de Fotografıas . . . . . . . . 48

3.2. Despues de la Integracion de los Sistemas . . . . . . . . . . . . . . 49

3.3. Problematica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4. Analisis de Alternativas de Solucion . . . . . . . . . . . . . . . . . 50

3.4.1. Creacion de un Nuevo Sistema . . . . . . . . . . . . . . . . 51

3.4.2. Integracion de Plataformas . . . . . . . . . . . . . . . . . . 52

3.4.3. Compra de un Software Comercial . . . . . . . . . . . . . 53

3.4.4. Eleccion de la Solucion . . . . . . . . . . . . . . . . . . . . 54

4. SOLUCION PROPUESTA 554.1. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2. Ob jetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . 57

4.3. Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.4. Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.5. Alcances y Limitaciones . . . . . . . . . . . . . . . . . . . . . . . 61

vi



5. El SISTEMA 62

5.1. Analisis de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.1. Recursos de Hardware . . . . . . . . . . . . . . . . . . . . 62

5.1.2. Recursos de Software . . . . . . . . . . . . . . . . . . . . . 63

5.1.2.1. PHP (PHP: Pre-procesador de Hipertexto) . . . . 63

5.1.2.2. Motor de Bases de Datos MySql . . . . . . . . . 64

5.2. Diseno de la Arquitectura . . . . . . . . . . . . . . . . . . . . . . 655.2.1. Esquema de Servidores . . . . . . . . . . . . . . . . . . . . 65

5.2.2. Paso de mensajes Cliente Proveedor . . . . . . . . . . . . . 66

5.2.3. Aplicacion de Bloom99 . . . . . . . . . . . . . . . . . . . . 68

5.3. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.1. Construccion Modulo Integracion . . . . . . . . . . . . . . 70

5.3.1.1. Clase NuSoap . . . . . . . . . . . . . . . . . . . . 71

5.3.1.2. Parametrizacion de clase . . . . . . . . . . . . . . 72

5.3.1.3. Implementacion de Servidores . . . . . . . . . . . 72

5.3.1.4. Implementacion de Clientes . . . . . . . . . . . . 75

5.3.2. Modulo de Integracion y su Implementacion . . . . . . . . 76

5.3.3. Implementacion de Pagina Central de Datos . . . . . . . . 77

5.3.4. Paginas de Resultado . . . . . . . . . . . . . . . . . . . . . 78

Conclusiones 80

Trabajo Futuro 83

Bibliografıa 85

ANEXOS 885.4. Organizacion del Codigo Fuente . . . . . . . . . . . . . . . . . . . 88

5.4.1. Directorio de Servidores . . . . . . . . . . . . . . . . . . . 88

5.4.2. Directorio de Cliente Generico . . . . . . . . . . . . . . . . 91

5.5. XML (eXtensible Markup Languaje) . . . . . . . . . . . . . . . . 94

5.5.1. ¿Que es XML? . . . . . . . . . . . . . . . . . . . . . . . . 94

5.5.2. Funcionalidades de XML . . . . . . . . . . . . . . . . . . . 94

5.5.3. Ventajas del XML . . . . . . . . . . . . . . . . . . . . . . 95

5.5.4. Utilizacion de XML mediante APIs . . . . . . . . . . . . . 96

5.5.5. XML y la Interoperabilidad . . . . . . . . . . . . . . . . . 97

5.5.6. Futuro XML . . . . . . . . . . . . . . . . . . . . . . . . . . 98

vii



´Indice de figuras

1.1. Organigrama Conferencia Episcopal de Chile.(fuente:www.iglesia.cl) 5

2.1. Esquema Sistema de Intercambio de Contenidos Relpe . . . . . . 16

2.2. Esquema federado de bases de datos . . . . . . . . . . . . . . . . 18

2.3. Componentes basicos de un Webservices . . . . . . . . . . . . . . 23

2.4. Esquema de paso de mensajes entre componentes SOAP . . . . . 24

2.5. Ejemplo de estructura basica . . . . . . . . . . . . . . . . . . . . . 29

3.1. Pagina Interior del Sistema de Directorio Virtual . . . . . . . . . 41

3.2. Modelo de Datos Directorio Virtual . . . . . . . . . . . . . . . . . 42

3.3. Pagina Principal del Sistema SAC . . . . . . . . . . . . . . . . . . 43

3.4. Modelo de datos SAC . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5. Pagina Principal Porta Web Iglesia.cl . . . . . . . . . . . . . . . . 45

3.6. Modelo de Datos Portal Iglesia.cl . . . . . . . . . . . . . . . . . . 46

3.7. Modelo de datos Documental . . . . . . . . . . . . . . . . . . . . 47

3.8. Modelo de datos Fotografıas . . . . . . . . . . . . . . . . . . . . . 48

3.9. Esquema de Integracion . . . . . . . . . . . . . . . . . . . . . . . 54

4.1. Estructura de Integracion a Nivel de Servidores . . . . . . . . . . 56

5.1. Esquema de Arquitectura por Capas . . . . . . . . . . . . . . . . 65

5.2. Esquema Comunicacion Entre Servidores . . . . . . . . . . . . . . 66

5.3. Paso de mensajes entre clientes y proveedores . . . . . . . . . . . 67

5.4. Esquema Bloom99 Para los Sistemas Integrados . . . . . . . . . . 69

5.5. Esquema Interno de un Sistema Integrado . . . . . . . . . . . . . 70

5.6. Esquema SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.7. Esquema de peticion de recursos del Cliente a los Proveedores de

servicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.8. Modificacion clase NuSoap cliente. . . . . . . . . . . . . . . . . . . 73

5.9. Codigo Fuente Implementacion de Servidor. . . . . . . . . . . . . 74

5.10. WSDL estadısticas. . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.11. Funciones estadısticas. . . . . . . . . . . . . . . . . . . . . . . . . 76

5.12. Pagina Principal Sistema Integrado . . . . . . . . . . . . . . . . . 77

5.13. Interfaz Portal Iglesia.cl (Resultado de la consulta integrada) . . . 79

viii



Introduccion

En el presente trabajo se desarrolla la construccion de un sistema integrador,

el que ocupando las nuevas tecnologıas XML que pontencian y flexibilizan las apli-

caciones basadas en Internet, junto a ello las arquitecturas orientadas a servicios

(SOA) para la estructuracion y orquestacion de los servicios ofrecidos por sistemas

heterogeneos, y las teorıas de las bases de datos federadas que permiten concebir

a un conjunto de bases de datos heterogeneas y con como si esta fuese una sola.

En el documento se plantea la construccion de modulos interoperables para

la integracion de los sistemas informaticos existentes en la Conferencia Episcopal

de Chile (CECH), de tal forma que estos en base a parametros del sistema pue-

dan relacionarse entre sı, y que ademas permita, la integracion de nuevas fuentes

de recursos, de tal forma, que otros sistemas puedan consumir sus recursos com-

partidos libremente. Tambien se propone que la union de estos recursos puedan

ser recogidos en el portal Web iglesia.cl, el que agrupara la informacion que es

consumida desde los distintos sistemas componentes resultantes de la integracion.

El proyecto contempla la revision bibliografica de los temas involucrados, la

construccion de prototipos para probar la tecnologıa, la eleccion de los protocolos

e implementacion de los modulos integradores, documentacion de las funcionalida-des y metodo de acceso a los recursos compartidos por cada sistema, y finalmente

la implementacion en el portal Iglesia.cl, el que reune toda la informacion adecua-

damente anexada con cada recurso obtenido gracias a la integracion.

1



Organizacion del Documento

El trabajo se encuentra organizado de la siguiente forma:

En el primer capıtulo se entrega el marco teorico, el cual contiene los con-

tenidos relacionados con el proyecto de una forma simple y con una profun-

didad del tema directamente relacionada con la importancia de estos para

el proyecto. Tambien se realiza una revision de proyectos en los cuales han

aplicado tecnicas y metodologıas de integracion, dando a conocer proyectos

que han sido exitosos en forma analisis de casos.

En el segundo capıtulo se realiza un analisis a la situacion anterior a la

implementacion del proyecto, revisando uno a uno los sistemas relacionados

y revisando funcionalidades y modelos de datos. Tambien se presenta la

problematica existente y las posibles soluciones, a las que se le realiza un

analisis de beneficios y desventajas de cada solucion.

La solucion final propuesta se expone en el tercer capıtulo, que es la resultan-

te del analisis de posibles soluciones, la definicion de los objetivos generales

del proyecto, la metodologıa a utilizar y los resultados esperados.

El sexto capıtulo se centra en el sistema integrado como tal, realizando un

analisis de los recursos existentes en cuanto a hardware y software, el diseno

de la arquitectura adecuada, la implementacion de las clases de servidor y

cliente, y la implementacion final en el portal Iglesia.cl.

2



Capıtulo 1LA INSTITUCION

1.1. Iglesia Catolica

La Iglesia Catolica Apostolica Romana o Iglesia Catolica como es mas

comunmente llamada, es una institucion no estatal y sin fines de lucro, en la

que se organiza la comunidad de los cristianos catolicos creyentes de todo el

mundo. Su sede central, se encuentra en el Estado independiente de la Ciudad

del Vaticano, que es un enclave dentro de la ciudad de Roma, en la Republica

Italiana. Su jefe de estado, es S.S. el Papa.

La Iglesia Catolica cuenta con miembros en cada uno de los paıses de la Tierra. Es

una organizacion jerarquica en la que el clero ordenado esta dividido en obispos,

presbıteros y diaconos. Territorialmente, la Iglesia Catolica esta organizada en

diocesis, cada una de ellas a cargo de un obispo. Estas, a su vez, se reunen en

provincias, que conforman una arquidiocesis. Otras jerarquıas son las prelaturas

y los vicariatos.

La Iglesia Catolica de Chile, esta compuesta de 27 jurisdicciones eclesiales:

5 arquidiocesis, 18 diocesis, 2 prelaturas, 1 vicariato apostolico, 1 obispado

castrense y 1 prelatura personal.

El organismo colegiado que reune a todos los obispos catolicos de cada paıs

se denomina Conferencia Episcopal, en donde los cargos son determinados por

eleccion, entre los propios obispos de la nacion.

3



4

1.2. La Conferencia Episcopal de Chile

La Conferencia Episcopal de Chile (CECH), es el organismo en el cual los

Obispos ejercitan conjuntamente algunas funciones pastorales, en espıritu de

colegialidad, para el servicio del Pueblo de Dios y para promover conforme a

la norma del derecho canonico, el mayor bien que la Iglesia proporciona a los

hombres.

En conformidad a lo establecido por el canon 449-2, la Conferencia Episcopal

tiene personalidad jurıdica publica y corporativa ante el derecho canonico y goza

ante el derecho civil de personalidad jurıdica de derecho publico cuyo ejercicio,

en los asuntos en que se requiera, se llevara a efecto segun los presentes estatutos

y las normas comunes de derecho cf . art. 26 , c).

La CECH esta compuesta por los Arzobispos y Obispos Diocesanos, los Adminis-

tradores Diocesanos y todos los equiparados en derecho a los Obispos Diocesanos,

el Obispo Castrense, los Coadjutores y Auxiliares y los Obispos Titulares que

desempenen cargos nacionales conferidos por la Santa Sede o por la Conferencia

Episcopal.

Son organos constitutivos de la CECH

a) la Asamblea Plenaria (AP);

b) el Comite Permanente (C.P.);

c) la Comision Pastoral (COP);

d) la Presidencia;

e) la Secretarıa General (SG).

REF. No 280/2001



5

Figura 1.1: Organigrama Conferencia Episcopal de Chile.(fuente:www.iglesia.cl)



6

1.3. Justificacion

El uso de la informatica para comunicarse ha marcado e impulsado el surgi-

miento de una nueva epoca cultural. Cada vez mas personas y entidades incor-

poran el correo electronico, Internet, la transmision inalambrica o satelital en su

vida diaria. No solo existe hoy un nuevo medio de comunicacion social -Internet-

sino que nos movemos en una nueva realidad comunicativa con caracterısticas del

todo particulares que han llevado a la abolicion, en cierta manera, del tiempo y

del espacio. Las nuevas tecnologıas han traıdo consigo la articulacion de nuevos

lenguajes y la emergencia de una nueva cultura.

Pero este nuevo fenomeno de comunicacion no nace aislado, sino que es here-

dero de toda la riqueza del Magisterio1 en esa materia. La Iglesia, fiel al decreto

conciliar “Inter Mirifica”2, esta participando en forma activa dentro de este nuevo

panorama. En su mision evangelizadora acompana e impulsa tambien el progreso

humano ofreciendole los valores evangelicos.

En su Carta Apostolica “El rapido desarrollo”, dirigida a los responsables de

las Comunicaciones Sociales, S.S. Juan Pablo II recogio la ensenanza del Magiste-

rio sobre la importancia del uso de las tecnologıas de la informacion al servicio de

la evangelizacion de la cultura, senalando: “La Iglesia, de hecho, no esta llamada

solamente a usar los medios de comunicacion para difundir el Evangelio sino, sobre

todo hoy mas que nunca, a integrar el mensaje de salvacion en la “nueva cultura”

que estos poderosos medios crean y amplifican. La Iglesia advierte que el uso de

las tecnicas y tecnologıas de comunicacion contemporaneas forman parte de su

propia mision en el tercer milenio”. Juan Pablo II manifiesta que “Internet no

solo proporciona recursos para una mayor informacion, sino que tambien habitua

a las personas a una comunicacion interactiva. Muchos cristianos ya estan utili-

zando este nuevo instrumento de modo creativo, explorando las potencialidades

para la evangelizacion, para la educacion, para la comunicacion interna, para la

1Magisterio: autoridad que en materia de dogma y moral ejercen el Papa y los obispos, seg unla Real Academia de la Lengua Espanola

2http://www.vatican.va/archive/hist councils/ii vatican council/documents/vat-ii decree 19631204 inter-mirifica sp.html



7

administracion y el gobierno”.

La Iglesia tambien necesita comprender y usar las tecnologıas de informacion,

en general, e Internet, en particular, como un medio de comunicaciones internas.

El Pontificio Consejo para las Comunicaciones Sociales sostiene que esto “requie-

re tener claramente en cuenta su caracter especial de medio directo, inmediato,

interactivo y participativo” y lo define como un “instrumento que se puede usar

creativamente para varios aspectos de administracion y gobierno” . En este sen-

tido, los documentos del Magisterio insisten en la necesidad de ir al ritmo del

despliegue tecnologico: “No es aceptable quedarse atras tımidamente por miedo a

la tecnologıa o por cualquier otra razon, considerando las numerosas posibilidades

positivas que ofrece Internet”.

Coherentemente con esta lınea, la CECH, ha visualizado los beneficios que

aporta la incorporacion y uso de los medios tecnologicos a los que se hace refe-

rencia, desplegando esfuerzos humanos y tecnicos que han redundado en avances

importantes. Prueba de ello, es que la CECH3 ha buscado ir de la mano con los

avances informaticos incorporando a su trabajo diario los medios tecnicos para

beneficio de su labor pastoral y de su gestion. Ademas, la CECH ha desarrollado

su sitio Web www.iglesia.cl que desde 2003 ha implementado modulos de automa-

tizacion de contenidos, documentos y bases de datos. En el 2003 se creo la Oficina

de Estadısticas para la pastoral que busca automatizar los registros de la Iglesia

en Chile para su posterior procesamiento estadıstico, y a partir de este ano 2007,

se ha impulsado con mayor fuerza la penetracion en las diocesis del software de

administracion Office Eclesial.El Area de Comunicaciones de la CECH ha sido pieza fundamental en el

desarrollo y mantencion de algunas de las plataformas antes mencionadas ins-

titucionalizandolas en su Comision Nacional de Informatica. Hoy dıa, el Area de

Comunicaciones visualiza una nueva oportunidad para aunar esfuerzos y criterios

en pos de una mejor utilizacion aun de las tecnologıas por medio de la integracion

de sus sistemas.

3http://noticias.iglesia.cl/noticia.php?id=2852



8

1.4. Motivacion Personal

“...Cumple tu la mision que te ha sido confiada, tu pequena mision, la que solo

tu puedes cumplir; tu solo en toda la creacion puedes llenar esa mision. Si no la

realizas quedara sin hacerse, ¡tu mision!, mision de generosidad...” (Padre Alberto

Hurtado)

Antes de proponerme a realizar la integracion de los sistemas en la Iglesia

Catolica en Chile, y utilizar las nuevas tecnologıas como lo son los Webservices,

las Arquitecturas Orientadas a Servicios (SOA), las Bases de Datos Federadas y

el propio XML, eran otros los motivos que hacıan importante realizar mi proyecto

de titulo en funcion de la Iglesia Catolica y su mision. Estos motivos estan direc-

tamente relacionados con el estrecho vınculo y compromiso de mas quince anos de

trabajo pastoral, el que fue reforzado por la busqueda de herramientas que ayuda-

ran en la labor pastoral de coordinador de la pastoral del liceo politecnico Andes

de la fundacion Duoc UC, y apoyo tecnico para las labores pastoral de los demas

miembros de la organizacion, liceo donde obtuve el tıtulo de ´´Tecnico en Control

de Procesos Industriales Computarizados”. Luego al ingresar a la Universidad, mi

querida Universidad Tecnologica Metropolitana y seguir la carrera de Ingenierıa

en Informatica y continuar el vınculo con la Iglesia Catolica y junto a ello reali-

zando la formacion de la pastoral universitaria de la misma, continue buscando

formas de contribuir a la evangelizacion con herramientas de las tecnologıas de

la informacion actuales, para ası llegar a mas personas. El primer proyecto fue

desarrollar un pagina interactiva para la pastoral de la universidad y otras orga-

nizaciones sociales, el siguiente paso fue contribuir con herramientas informaticasen la Vicarıa de la Pastoral Universitaria (VPU), lo que dio paso a integrar el

equipo de desarrollo Web del portal IGLESIA.cl de la Conferencia Episcopal de

Chile (CECH) como voluntario, labor desempenada por mas de cinco anos.

En Iglesia.cl junto al equipo de desarrollo, primeramente se realizo un estudio

para saber cuales eran las tecnologıas que han de satisfacer de manera optima

los futuros requerimientos de proyectos pensando a largo plazo. Los primeros

sistemas fueron orientados a solucionar la administracion de grandes cantidades

de noticias y recortes de prensa que a diario debıan ser publicados en formato

HTML. La construccion de diversos sistemas a medida para distintas areas de laIglesia Catolica genero en estas instituciones un mayor grado de confianza y alta

aceptacion hacia las nuevas tecnologıas y utilizacion de cada sistema.

Con el tiempo, y con la coexistencia de varios sistemas en distintas ubicaciones

fısicas, tanto de los departamentos de la CECH y los sistemas propietarios del

CELAM4, nacio la necesidad de contar con la informacion de los demas sistemas

en forma mucho mas transparente y rapida, y la unica forma de acceder a esta

informacion era accediendo a cada sistema dıa a dıa. La otra situacion era que

existıan un gran valor y riqueza de informacion que los usuarios finales del portal

4CELAM Conferencia Episcopal Latino Americana



9

iglesia.cl estaban desaprovechando por estar distribuida en sistemas que ellos no

tenıan acceso, ni conocimiento de su existencia.

La integracion de los sistemas nace entonces como una gran alternativa a los

problemas presentados, y representa un gran desafıo ya que esta implementacion

requiere de una analisis a fondo de cada uno de los sistemas comprometidos, la

busqueda de estandares actuales y una revision bibliografica importante.Otro factor importante que motivo el desarrollo de este proyecto, fue la par-

ticipacion en las jornadas chilenas de computacion 2002, en la Universidad de

Atacama, donde expuso la doctora Regina Motz sobre una investigacion que esta-

ban realizando sobre bases de datos federadas, XML y Webservices, y su desarrollo

practico para la integracion de sistemas publicos. El impacto de dicho trabajo fue

tal que muchos de los asistentes a las charlas quedaron motivados a investigar e

implementar nuevas soluciones en base a la propuesta presentada, personalmente

dicha motivacion fue el primer paso hacia los sistemas integradores de contenidos,

lo se tradujo en comenzar la preparacion de prototipos mucho antes de egresar dela universidad, realizando pruebas de funcionalidad y rendimiento con distintos

lenguajes.

Finalmente, puedo decir que el compromiso con la Iglesia Catolica y mi interes

personal en aplicar los conocimientos adquiridos en mi carrera profesional, para

lograr llegar con el mensaje del evangelio a mucha mas personas, utilizando los

medios de comunicacion mas importantes que actualmente existen, como lo es la

Internet, han dado paso al presente trabajo. Sin duda un proyecto de tıtulo con

el tema de integracion e interoperabilidad, podrıa haberse realizado en cualquier

area de la empresa, tanto publica o privada, pero el fuerte llamado que nos hizo elpapa Juan Pablo II en su Carta Apostolica “El rapido desarrollo”, que nos dice:

“Internet no solo proporciona recursos para una mayor informacion, sino que tam-

bien habitua a las personas a una comunicacion interactiva. Muchos cristianos ya

estan utilizando este nuevo instrumento de modo creativo, explorando las poten-

cialidades para la evangelizacion, para la educacion, para la comunicacion interna,

para la administracion y el gobierno”, es por ello, que la desafiante propuesta de

Juan Pablo II, personalmente me invita a no quedarme en solo “hacer lo que es

necesario hacer”, sino que me motiva a investigar nuevas formas de colocar las

tecnologıas de la informacion en funcion de las personas, pensado en que detrasde un computador existe una persona que realiza un trabajo con mucho amor y

que estas herramientas tecnologicas pueden hacer que ese mensaje pueda llegar

a muchos mas, y para terminar quisiera colocar como medidor de trabajo en el

proyecto, la frase del padre Alberto Hurtado; “La misi on del universitario es la

del estudioso que traduce esos ideales grandes del hombre de la calle en solucio-

nes tecnicas, aplicables, realizables, bien pensadas”, lo que traduce mi esfuerzo en

este proyecto, el que fue respaldado al colocar el proyecto humildemente en las

manos de Dios, y recibir el refuerzo de la oracion de tantas personas vinculadas a

la CECH y la Iglesia Universal.



Capıtulo 2FUNDAMENTACIONTEORICA

La administracion de los datos se ha hecho cada vez mas compleja, es por

ello que diferentes autores proponen diferentes teorıas de administracion de lainformacion, partiendo de las aplicaciones computacionales de escritorio que ad-

ministran datos orientados al usuario final, hasta los grandes sistemas integrados

que proveen todo en una sola plataforma.

En el mundo cada vez mas se requiere de contar con informacion a la mano

segundo a segundo, informacion que significa millones de dolares (o euros) en la

certeza de una buena decision estrategica, pero como contar con la informacion si

esta se encuentra dispersa en diferentes sistemas computacionales, con diferentes

plataformas, y mas aun, sin ninguna compatibilidad en esquema de datos ni en sus

estructuras. Todo ello ha llevado a juntar todas las tecnologıas existentes y crearmetodos con los cuales los sistemas que son totalmente heterogeneos se puedan

comunicar, y mas aun, que estos sistemas con un bajo costo formen una gran

plataforma de consulta con datos constantemente actualizados.

En este capıtulo se muestra el contexto global en cual se enmarca la teorıa de

integracion de sistemas y de los temas relacionados con la ingenierıa de software.

Cabe senalar que el presente marco teorico es abordado como un resumen de los

temas relacionados, pero con una profundidad relativa a la importancia de cada

tematica, sin intencion de desviar la atencion en cada tema particular, sino serun aporte a la globalidad requerida. Este comprendera tres temas que son muy

importantes para el proyecto: Bases de datos federadas (Ver Capıtulo 2.2), que

toca las definiciones y conceptos clave de integracion de bases de datos y como

estas se pueden aplicar a la federacion de sistemas; XML (Ver Capıtulo 5.5.1) como

estandar para el paso de mensajes y su aplicaci on en proyectos de integracion; y

Webservices (Ver Capıtulo 2.3.1) en el que se profundiza sobre la utilizacion de

estos en un gran numero de proyectos, que van desde compartir un contenido

hasta la utilizacion en sistemas de agentes inteligentes.

La revision bibliografica que se ha obtenido es fruto de una exhaustiva busque-da en libros y en documentacion oficial disponible de la Internet. Entre las fuentes

10



11

mas importantes se tiene los documentos tecnicos y recomendaciones de la W3C

[26], tambien los papers sobre el tema BLOOM99 del doctor espanol Alberto

Abello [3] (Universitat Politecnica de Catalunya) y la doctora Marta Oliva (Uni-

versitat de Lleida), quienes amablemente facilitaron su documentacion despues de

haberlos contactado vıa mail sobre dudas tecnicas en la implementacion de siste-

mas integrados; otras fuentes importantes fueron los sitios espanoles de gobiernoen los que tratan sobre las tendencias a la integracion de sistemas en Europa [1].



12

2.1. Estado Actual de la Integracion de Sistemas

En el mundo existen actualmente grandes cantidades de sistemas informaticos

que se encuentran aislados en un solo computador o una red corporativa, sin inter-

accion con los demas componentes de la red, de los cuales no se pueden obtener

indicadores ni beneficios mas alla de lo que cada sistema permite entregar por

separado, es por ello, que ha nacido la necesidad de crear nuevos y m as complejos

sistemas que vinculen y concentren esta informacion. Una de las primeras solu-

ciones fue crear gigantescos repositorios (datawarehouse) [27], en los cuales solo

se ingresa la informacion una vez, quedando como un archivo historico que puede

ser consultado muchas veces. Por otro, lado han surgido una cantidad importante

de investigaciones de tecnologıas alternativas para lograr una integracion robusta

y escalable, siendo su principal cuna la Union Europea.

Las principales investigaciones realizadas sobre la interoperabilidad e integra-

cion de sistemas estan siendo llevadas por grupos de investigacion, de los cuales

se puede mencionar el “Grupo de Investigacion en Sistemas de Gestion de Bases

de Datos Federadas” 1, conformado por academicos de distintas universidades,

los que entregan los principales aportes en la creacion de esquemas federados [3].

Otra fuente importante de aportes en cuanto a la integracion de sistemas son las

empresas privadas, las cuales han visto lo beneficioso que resulta la integracion

de distintos sistemas heterogeneos, aun mas, con la llegada de la WEB3.0 o Web-

sematica2, han dado paso a una Internet mucho mas inteligente, en el cual los

sitios componentes de estas redes entregaran significado de sus contenidos, para

luego poder compartirlos como un todo.Se han propuesto numerosos trabajos para el acceso a la informacion almace-

nada en las bases de datos heterogeneas y otras fuentes como los sistemas legados3.

Segun Zachary [28], con el crecimiento y perfeccionamiento de las redes en general

y de la Internet en particular, el numero de fuentes de las que se puede extraer

datos se ha incrementado notablemente, aunque la cantidad de informacion sea

una gran ventaja, tambien plantea numerosos problemas, ya que Internet es un

entorno dinamico en el cual no se puede asegurar la permanencia de los datos y

sus fuentes.

Otro aporte a la integracion de sistemas lo expone el academico Araque [14]en su tesis doctoral, quien dice “para que un usuario pueda acceder a multiples

fuentes de datos de un modo integrado, es decir, como si se tratase de una so-

la base de datos, hace falta instalar un sistema que produzca un acoplamiento

entre esas fuentes. Sin acoplamiento, el acceso no es integrado, y hace falta ac-

ceder separadamente a cada una de las fuentes, y luego combinar las respectivas

respuestas”.

1Grupo de Investigacion en Sistemas de Gestion de Bases de Datos Federadas y Almacenesde Datos, ver mas informacion en http://lsi.ugr.es/ bdf/

2Mas informacion de la Websematica http://www.w3c.es/Divulgacion/Guiasbreves/WebSemantica3Sistema Legado: sistemas operacionales ya existentes, en el cual es necesario recuperar ,

analizar y depurar la informacion antes de integrarla



13

2.1.1. Analisis de Casos

Siendo una tendencia mundial de optimizar los recursos existentes y obte-

ner mayor beneficios de ellos, es que en distintos ambitos relacionados con la

informatica se aplica la integracion de sistemas, intentando con ellos obtener in-

teroperabilidad entre ellos. A continuacion se presentan algunos casos en que se

esta aplicando los conceptos tratados en este documento.

2.1.1.1. Tendencias en Europa

En Europa se dan los primeros acercamientos a los conceptos de integracion

de sistemas, naciendo de una necesidad publica de mantener informacion constan-

temente actualizada de los distintos servicios publicos, en los cuales sus primeras

pruebas fueron realizadas en sistemas de documentacion bibliografica, dando co-

mo resultado la primera biblioteca virtual que recogıa informacion de bibliotecas

locales cuyos sistemas estaban realizados en distintas plataformas y lenguajes deinformacion. Luego de la integracion de las bibliotecas se procedio a la integra-

cion de la informacion del servicio de salud espanol, lo cual creo la necesidad de

parte de las organizaciones privadas y del gobierno de “comprender las necesi-

dades especıficas tanto de la administracion publica como de los ciudadanos en

relacion a los servicios electronicos ofrecidos por la administracion publica” [10]

hecho analizado por la W3C en sus oficinas espanolas.

La tendencia por la integracion de sistemas mediante bases de datos federadas

para brindar un servicio integrado, ha dado buenos resultados, pero tambien han

creado nuevas problematicas como lo es la privacidad de los datos. La privacidad

de los datos en Espana y en todo la Union Europea es un tema bien estudiado, en

el cual se revisan metodos mas avanzados de criptografıa, estructuras de bases de

datos con mayores niveles de seguridad y modelado de datos en esquemas como

BLOOM99 [3] nacido en Barcelona para integracion federada con altos niveles de

seguridad.

2.1.1.2. Herramientas de Integracion Existentes

Existen muchas herramientas ofrecidas por empresas, como tambien se ofrece

la asesorıa en la integracion de sistemas heterogeneos. La gran mayorıa de estas

empresas ofrecen un servicio completo que va desde la revision de sus sistemas

para verificar las posibilidades de unificar procesos entre ellos, hasta la imple-

mentacion de una completa solucion reconstruyendo todos sus sistemas. Estas

integraciones estan siendo lideradas por las grandes empresas de software, como

los son Microsoft, HP4 latinoamerica, Oracle, etc.

Las asesorıas entregadas por estas empresas pretenden recoger toda la riqueza

4

Mas informacion http://h30095.www3.hp.com/servicios/



14

de los sistemas existentes, los cuales luego de haber sido revisados, son inventa-

riados para dar paso a un modelamiento en Arquitectura Orientada a Servicios

(SOA Ver capıtulo 2.4) , y junto con los altos mandos, definen estrategias en con-

junto para la mejor utilizacion de la informacion que originalmente esta dispersa

y que despues de la integracion se lograra complementar para obtener mayores

beneficios de esta nueva herramienta.El gobierno espanol ha optado por la solucion de HP5 (Hp eGovernment Fra-

meWork), en la que HP ha desarrollado una soluci on basada en multitecnologıa y

multifabricante, con el fin de ofrecer a las administraciones publicas una vision de

sus servicios global, unica y bajo la perspectiva del ciudadano. Esta herramienta

ha sido creada para modernizar las aplicaciones y facilitar el cumplimiento de los

estandares, y ası permitir la interoperabilidad tecnica y semantica de los sistemas.

El futuro de estas nuevas herramientas de integracion junto al SOA, se en-

cuentran en la creacion de Shared Services6 y Semantic Web Services7. Todo ello

ha favorecido un potencial incremento en el uso de esta tecnologıa en sectorescomo la banca o las telecomunicaciones, que buscan en las plataformas de SOA

los elementos basicos para la prestacion de servicios de valor anadido.

2.1.1.3. Bibliotecas Interconectadas

Uno de los grandes beneficiados con las herramientas de integraci on han sido

las bibliotecas, las que sin duda han sido pioneras en temas de estandarizaci on

de metadatos8, los que posibilitan una mejor interaccion entre ellos. Uno de los

recursos mayormente utilizado en la integracion, ha sido el registro bibliotecarioen XML (Ver Capıtulo 5.5.1).

Una gran sistemas bibliotecarios, cuentan con sistemas heterogeneos de infor-

macion, los que pueden ser accedidos por otros sistemas o entre si, para compartir

informacion, tanto de sus catalogos de libros o de material digitalizado, y gracias

a los metadatos, los que sirven para referenciar, etiquetar y describir recursos,

pueden descubrir y localizar el material disponible en los sistemas que componen

la integracion.

Un ejemplo de inteoperabilidad e integracion de sistemas bibliotecarios es la

Biblioteca Virtual Miguel de Cervantes9

, la que ha contado con los beneficios de laintegracion para interactuar con otras bibliotecas. Otro punto importante donde

se ha tocado el tema de integracion de contenidos de las bibliotecas es en el 10th

European Conference on Digital Libraries (ECDL 2006)10, dando grandes pasos

5Mas informcion http://www.gobiernoelectronico.org/node/51396Shared Services: Servicios compartidos que van desde un organismo al resto y desde estos a

los usuarios7Semantic Web Services: Combinacion de los servicios de Web Semantica y Servicios Web

gracias a la interaccion entre las aplicaciones que soportan estos servicios.8Mas informacion de Metadatos orientados a la Interoperabilidad disponible en

http://www.tdx.cbuc.es/TDX-0316104-132946/9Biblioteca Virtual Miguel de Cervantes http://www.cervantesvirtual.com/index.jsp10Mas informacion www.ecdl2006.org



15

hacia una integracion global.

2.1.1.4. Proyecto Relpe

El proyecto RELPE11 es una red de portales educativos con caracterısticas

de autonomıa, de servicio publico y gratuitos, designados para tal efecto por losministerios de educacion de cada paıs. Sus principios orientadores son: cada paıs

desarrolla su propio portal de acuerdo a su proyecto educativo e intereses naciona-

les aprovechando la experiencia de los otros socios, y los contenidos desarrollados

por todos los portales miembros son de libre circulaci on en la Red. Este proyec-

to, esta basado en la integracion de contenidos por medio de la tecnologıa Web

Services.

Este proyecto en Chile lo esta manejando Fundacion Chile en conjunto con

la empresa de informatica I2c.cl12, y en sus pruebas el autor de este documento

tambien asesoro la configuracion y puesta en marcha del sistema integrador.A la finalizacion del proyecto presentado, tambien el autor de este documento

ha creado una nueva herramienta de integracion de contenidos para www.relpe.org,

herramienta basada ıntegramente en el paso de informacion entre servidores por

medio de archivos XML entre ellos.

En la figura 2.1, se presenta el esquema presentado para el nuevo sistema de

intercambio de informacion, proyecto presentado por la empresa I2c.cl y desarro-

llado por el autor del presente documento.

11Mas Informacion http://ww2.relpe.org/12Mas Informacion http://www.i2c.cl/



16

Figura 2.1: Esquema Sistema de Intercambio de Contenidos Relpe



17

2.2. Bases de Datos Federadas

La cantidad de informacion existente en el mundo ha crecido exponencialmen-

te, lo que ha resultado caotico, y por ello nace la pregunta ¿Quien administrara tal

cantidad de informacion ? o ¿Para que sirve tanta informacion valiosa si no se

puede consultar de manera beneficiosa?. En respuesta a ello, ha nacido la idea de

generar cooperacion entre fuentes independientes de informacion, logrando ası te-

ner acceso a multiples bases de datos autonomas y heterogeneas, es decir, tener

la capacidad de poder acceder a los datos como si se tratase de una sola base de

datos.

Las bases de datos comenzaron a utilizarse en los anos sesenta, periodo en el

que fueron fuertemente ocupadas en areas relacionadas con grandes cantidades de

informacion, y no fue hasta los ochenta que junto a la proliferaci on de los sistemas

heterogeneos y distribuidos, sistemas en base a Internet que nacio el concepto de

bases de datos federadas en manos de Hammer y McLeod en 1979, trabajo que

luego fue retomado por Heimbigner y McLeod en 1985 y posteriormente por Sheth

y Larson en 1990, y actualmente el tema es estudiado por Saltor.

En general, los manejadores de bases de datos federados tienen la funcion de

compartir solo la informacion que quieran compartir las entidades participantes,

ademas los usuarios locales pueden acceder de forma transparente a los demas

datos compartidos, como si se tratase de una sola base de datos, sin embargo no

es algo sencillo, aunque muy util [22].

2.2.1. Definicion de Base de Datos Federada

Un sistema de bases de datos federado es una coleccion de sistemas de bases

de datos cooperativos y autonomos. En un sistema federado de bases de datos, los

usuarios tienen acceso a la informacion de los distintos sistemas a traves de una

interfaz comun; sin embargo, no existe un esquema global que describa a todos los

datos de las distintas bases de datos, en su lugar hay varios esquemas unificados,

cada uno describiendo porciones de bases de datos y archivos para el uso de cierto

perfil de usuarios [23].

2.2.2. Propiedades

Las bases de datos federadas son muy importantes para la decision de que tipo

de federacion utilizar. Entre estas propiedades se encuentran:

1. Es ser transparente a los usuarios.

2. Se aprecia como una sola base de datos (concepto de interoperacion).

3. Se conforma por un conjunto de bases de datos heterogeneas, lo que sig-nifica que pueden participar distintos sistemas operativos, diferentes tipos



18

Figura 2.2: Esquema federado de bases de datos

de hardware, diferentes manejadores de bases de datos (red, relacional u

orientada a objetos), y/o diferentes estructuras de datos.

4. Las bases de datos que participan en la federacion mantienen su autonomıa,

lo que quiere decir que cada elemento de la federaci on decide con quien,

que y como compartir sus datos.

5. El Manejador de Bases de Datos Federadas (MBDF) recibe una consulta

sencilla y este a su vez la descompone en varias consultas parciales, ademas

debe contar con un optimizador de recursos.

6. Permite ser distribuida fısicamente en diferentes lugares e incluso en lugares

muy lejanos.

2.2.3. Arquitectura

En la arquitectura de las bases de datos federadas se puede diferenciar dos

grandes areas, la primera referente al software de aplicacion y la segunda sobre la

arquitectura del esquema federado. En el area de esquema federado se debe resol-

ver las heterogeneidades sintacticas13 y semanticas14 de los distintos componentes

13Sintatica: Parte de la gramatica que ensena a coordinar y unir las palabras para formar lasoraciones y expresar conceptos. Conjunto de reglas que definen las secuencias correctas de loselementos de un lenguaje de programacion.(RAE.es)

14Sematico: Perteneciente o relativo a la significacion de las palabras.(RAE.es)



19

de la base de datos. La heterogeneidad sintactica se da por la autonomıa de los

componentes de la base de datos y sus diferencias en sus disenos de modelo de

datos. En cambio, la heterogeneidad semantica se da por la interpretacion que se

tiene de los elementos por parte de las diferentes bases de datos componentes [9].

2.2.3.1. Capas del Esquema

Las capas del esquema, resuelven las areas de heterogeneidad semantica y

sintactica en un sistema federado, las cuales deben cumplir tres aspectos basicos:

la autonomıa, heterogeneidad y sistema distribuido. Uno de los esquemas mas

utilizados para las bases de datos federados es la arquitectura ANSI/SPARC de

3 niveles propuesta en 1977 por Casamayor [5].

2.2.4. Sistemas Distribuidos Versus Sistemas Federados

Es muy facil confundir un sistema distribuido15 de informacion con un sistema

federado [21] de datos, pero las diferencias entre ellos son muy importantes al

minuto de elegir una solucion a una problematica especifica, las semejanzas y

diferencias se presentan a continuacion:

• Semejanzas

a ) Los datos estan en diversas ubicaciones.

b) Las instalaciones estan interconectadas.c) Ambos tienen dos componentes; global/local y federado/componente.

d ) Reciben peticiones que son resueltas en una sola respuesta.

15Bases de datos distribuida: Es un conjunto de bases de datos conectadas por red, permitiendocompartir informacion y acceder a los miembros de la red.



20

• Diferencias

SMBD Federados SMBD Distribuidos

Diseno Manejan un diseno top -

down, existe una sola ba-

se de datos y se distribuyeen diferentes ubicaciones.

Se fragmenta o se replica.

Maneja un diseno Botton

- up, las bases de datos ya

existen y se identifica co-mo se formaran las fede-

raciones.

Niveles Local y global Federado y componente

Autonomıa Carece de autonomıa, ya

que la BD esta bajo las

reglas del sistema global.

Cada BD compone el sis-

tema federado, es autono-

ma, y por tanto tiene sus

propios prilivegios.

Transparencia Los usuarios ven la BD

como una sola y no se sa-

be como se encuentra dis-

tribuida fısicamente.

Existen dos tipos de

usuarios, el primero es el

que ve la base de datos

como si fuera unica, y

los usuarios locales que

ven un componente de

la base de datos y no

pueden ver la federacion.

2.2.5. Soluciones Comerciales

Existen varias empresas e instituciones que trabajan para solucionar los

problemas de interoperabilidad, sin embargo muy pocos trabajan para la ad-

ministracion global, algunas de las companıas que trabajan en soluciones son

Augsoft16, Oracle17(actualmente ofrece paquetes listos para la integracion en

Latino America), Sybase. En general, los grandes manejadores de bases de datos

contienen algunas herramientas para lograr la integracion, sin embargo, tienen

un producto especıfico para conectarse con otros manejadores, donde cada uno

se vende por separado siendo sus costos demasiado elevados.

En el proyecto propuesto se requerıa del estudio de este tipo de bases de datos

porque el fundamento de la interoperabilidad e integracion de sistemas contempla

como concepto base la estructuracion, funcionamiento y comportamiento de las

bases de datos federadas.

La modelacion de las bases de datos federadas estan soportadas por el modelo

16

ver mas informacion en http://odbcrouter.com17http://www.oracle.com/solutions/integration/index.html



21

bloom99 [3], el que permitira concebir el proyecto propuesto como un conjunto

de bases de datos unificada por un motor central, siendo esa la fase inicial la

cual sera explicada en el capitulo 5.4. El estudio del funcionamiento de las bases

de datos federadas permitira establecer el comportamiento funcional de los com-

ponentes de la integracion para ası asegurar la correcta interoperabilidad entre

ellos.



22

2.3. Servicios Web (Webservices)

Cuando hablamos de Webservices (Servicios Web), hablamos de una tecnologıa

muy reciente, y por su utilidad tambien ha sido una de las mas difundidas. Se

puede decir que los Webservices es una de las tendencias clave en la integraci on

de sistemas, como tambien es de gran ayuda en las nuevas metodologıas para

compartir datos de distintas fuentes por sus caracterısticas de control, seguridad

y sus metodos estandar actuales. Para ello, ha debido pasar por varias etapas

de crecimiento, lo que ha dado paso a estudios con diversos planteamientos y

postulados, lo que colocan a los Webservices como uno de los est andares mas

importantes junto a XML en los proximos anos.

2.3.1. WebServices

Los Webservices como lo explica el W3C [25], son aplicaciones que intercam-bian datos entre si con el objetivo de ofrecer servicios, en el cual existen proveedores

que prestan sus servicios como procedimientos remotos y usuarios clientes que so-

licitan un servicio especıfico llamando a estos procedimientos a traves de la Web,

los que son comunmente de tamano pequeno y formados por varios componen-

tes que comparten su informacion de forma segura y estructurada con las demas

aplicaciones, en forma rapida y estandarizada. Estas aplicaciones o servicios son

publicados en directorios, los que pueden ser invocados y ejecutados vıa HTTP18,

en el cual su trasporte es por el lenguaje estandar XML (ver mas en Cap.5.5.1).

Otra definicion es dada a los Servicios WEB por la W3C [25] es que estos son“conjunto de aplicaciones o de tecnologıas con capacidad para interoperar en la

Web. Estas aplicaciones o tecnologıas intercambian datos entre sı con el objetivo

de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimien-

tos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a

traves de la Web”.

La utilizacion de los Webservices ha sido potenciada por tratarse de un

estandar aceptado por la W3C [25] y que a diferencia de otras tecnologıas de inte-

gracion, permite compartir funcionalidades entre sistemas heterogeneos de forma

transparente, mediante el intercambio de datos vıa XML, siendo su unico requisitoel establecimiento de conexiones TCP/IP.

Los Webservices proporcionan “mecanismos de comunicacion estandares en-

tre diferentes aplicaciones, que interactuan entre sı para presentar informacion

dinamica al usuario. Para proporcionar interoperabilidad y extensibilidad entre

estas aplicaciones, y que al mismo tiempo sea posible su combinacion para reali-

zar operaciones complejas, es necesaria una arquitectura de referencia estandar”,

como lo explica la W3C. Por lo que simplifica mucho la integraci on de distintas

18(HyperText Transmission Protocol) Protocolo para transferir archivos o documentos hiper-

texto a traves de la red. Se basa en una arquitectura cliente/servidor.



23

Figura 2.3: Componentes basicos de un Webservices

plataformas y lenguajes de programacion. es decir, a modo de ejemplo, podemos

tener un Servidor Webservices escrito en PHP (Pre Procesador de Hipertexto) y

un usuario cliente en lenguaje Java o algun lenguaje de la serie Microsoft .NET.

2.3.2. Componentes

La caracterıstica principal de los Webservices es la “capacidad de compartir

recursos en forma de objetos y que estos puedan ser utilizados f acilmente por los

sistemas cliente”, y para ello utilizan el protocolo de comunicaciones SOAP, que

junto a los lenguajes de descripcion de Webservices (WSDL), mas un sistema de

l´ ogica interna y un sistema de directorio (UDDI) para el registro de los recursos

a compartir componen un Servicio Web.

En el grafico 2.3 se muestran los componentes basicos de un Webservices,

estos componentes se dividen en los necesarios para la implementacion y los que

se requieren para la publicacion de los recursos a compartir.

Los componentes para la publicacion son el lenguaje de descripcion de Web-services (WSDL) y el directorio de Servicios Web (UDDI), en cambio para la

implementacion los componentes son el protocolo SOAP y la l´ ogica , que contem-

pla la organizacion y control de los recursos a compartir.

2.3.3. SOAP (Simple Object Access Protocol)

SOAP es un protocolo de comunicacion basado en XML, que sirve para la in-

vocacion de los servicios Web a traves de HTTP como protocolo de transporte [8].

Es independiente de la plataforma y del lenguaje, y cuenta con implementacionespara la gran mayorıa de estas.



24

Figura 2.4: Esquema de paso de mensajes entre componentes SOAP

La especificacion SOAP indica como se deben codificar los mensajes que cir-

culan entre las aplicaciones. Tratandose de un protocolo simplificado de llamadas

a procedimientos remotos RPC (Remote Procedure Call).

La implementacion de SOAP sobre PHP mas recomendable es NuSOAP.

- Paso de Mensajes en Especificacion SOAP: A continuacion se presentan

los pasos que sigue un mensa je en la especificacion SOAP:

1. Un mensaje que se enviara desde una aplicacion cliente a la aplicacion

servidor, solicitando la ejecucion de un metodo al que pasan una serie

de parametros.

2. Un mensaje que se enviara desde la aplicacion servidor al cliente, y que

contendra datos XML con los resultados de la ejecucion del metodosolicitado.

3. Un mensaje SOAP pretende representar la misma estructura que posee

una carta contemplandose incluso el sobre.

- Logica: La logica es el componente que se encarga de procesar la petici on

de informacion solicitada. La tarea de este componente es responder a la

peticion y para ello puede acceder a bases de datos propios, comunicarse

con otros Webservices o invocar a las APIs de otras aplicaciones solicitando

informacion o parte de ella para generar la respuesta a la petici on. En lalogica, podemos encontrar varias formas de resolver el problema, y es por ello



25

que se hace importante una buena documentacion del proceso del negocio y

de los recursos a los cuales se puede obtener. En algunos casos, los encargados

de los recursos Webservices manejan mapas de datos que permiten establecer

correctamente la logica para la obtencion, de forma optima de los recursos

Web a compartir.

2.3.4. UDDI (Universal Services Description Language)

Son directorios donde es posible publicar los servicios de los Webservices, lo

que permite a los posibles usuarios obtener informacion referente a la invocacion

y ejecucion del Webservice. Los directorios UDDI ofrecen grupos de interfaces

que posibilitan la publicacion y obtencion de los recursos disponibles, cuya infor-

macion es clasificada segun se desee obtener el servicio. Uno de los UDDI mas

conocidos y con mayor cantidad de herramientas para el usuario y administrado-

res es XMethods (http : //www.xmethods.net/), en el cual despues del registro yverificacion del usuario, este puede agregar la url de su WDSL y con ello realizar

pruebas de funcionamiento o ofrecerlo como servicio al resto del mundo.

Clasificacion UDDI segun obtencion de servicio

Archivos Descripcion

Informacion del ne-

gocio:

Aquı podemos encontrar informacion sobre

quien publica el servicio.

Informacion de servi-cio:

Se refiere a la descripcion del tipo de servicioofrecido.

Informacion de enla-

ce:

Se entrega la direccion para acceder al servicio

(la direccion es representada por la URL del

recurso)

2.3.5. WSDL (Web Services Description Language)

Es un protocolo basado en XML que permite describir el acceso a un WebService, a traves de la descripcion de los distintos metodos o funciones que estan

disponibles en este [13].

Podrıamos decir que es el manual de operacion del Web Service, porque nos

indica cuales son las interfaces que provee el Servicio Web y los tipos de datos

necesarios para la utilizacion del mismo.

Se puede establecer una equivalencia entre el documento WSDL y un ”contra-

to” que especifica los servicios que el servidor se compromete a ofrecer al cliente,

siempre que este los solicite de forma adecuada.



26

2.3.6. Clase NuSoap

NuSOAP es un kit de herramientas (ToolKit) para desarrollar Web Services

bajo el lenguaje PHP. Esta compuesto por una serie de clases que hacen mas facil

el desarrollo de Web Services. Provee soporte para el desarrollo de clientes (aque-

llos que consumen los Web Services) y de servidores (aquellos que los proveen).

NuSOAP esta basado en SOAP 1.1, WSDL 1.1 y HTTP 1.0/1.1.NuSoap es la implementacion mas recomendable para PHP, y desde la version

5.0 de PHP viene incluida dentro de sus paquetes. La pagina principal del

proyecto se encuentra disponible en http : //sourceforge.net/projects/nusoap/.

El proyecto contemplo el estudio de diversas alternativas de tecnologıas para

el paso seguro de datos a traves la Web, de las cuales se resolvio que la mas

adecuada para el proyecto era la utilizacion de los webservices en conjunto con la

herramienta NuSoap, permitiendo ası una gran transparencia en la paso de datos

entre servidores.



27

2.4. Arquitectura Orientada a Servicios (SOA)

La dispersion de los recursos informaticos de las empresas ha sido un de los

grandes problemas para optimizar muchos de los procesos en que ellos operan, y

la unificacion de ellos representa unos de los grandes paradigmas actuales, y es

aca donde tenemos a SOA como la union de diversas tecnicas, metodologıas y tec-

nologıas relacionadas con los Webservices (Ver capıtulo 2.3.1) y la creciente idea

de ver las distintas areas de la empresa con funciones y servicios por separado,

ademas darle una mayor relevancia a la posibilidad de contar con la informacion de

estas areas en una sola plataforma, han creado la necesidad de contar con una nue-

va arquitectura que permita organizar todo estas fuentes de informacion en forma

estandarizada, y para ello se busca la armonıa entre los proveedores19 de servicios

Web y los consumidores20 de estos, es por ello, que la Arquitectura Orientada a

Servicios SOA entrega una metodologıa para la realizacion y documentacion de

las actividades de integracion y consolidacion de sistemas integrados.

2.4.1. Concepto Arquitectura Orientada a Servicios

La Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA)

es un concepto relacionado con la arquitectura de software, que define la utilizacion

de los servicios Web para dar soporte a los requerimientos de software del usuario

[17].

La Arquitectura Orientada a Servicios proporciona una metodologıa para do-

cumentar las capacidades del negocio (informacion del tipo de funciones e infor-macion que cuenta el proveedor de servicios21) y ademas puede ayudar en las

actividades propias de integracion y consolidacion.

2.4.2. Funcionamiento

Cuando estamos en un ambiente SOA, identificamos a cada recurso como un

nodo de la red compuesta por proveedores y consumidores de recursos. Aquı po-

demos ver que los nodos hacen disponibles sus recursos a los demas participantes

de la red como servicios independientes a los que tienen acceso de un modo es-

tandarizado. La mayorıa de las definiciones SOA utilizan los servicios Web para

tal efecto, empleando SOAP y WSDL (Ver capıtulo 2.3.5) en su implementacion,

19Proveedor: La funcion que brinda un servicio en respuesta a una llamada o peticion desdeun consumidor.

20Consumidor: La funcion que consume el resultado del servicio provisto por un proveedor.21Servicios: Una funcion sin estado, auto-contenida, que acepta una(s) llamada(s) y devuelve

una(s) respuesta(s) mediante una interfaz bien definida. Los servicios pueden tambien ejecutarunidades discretas de traba jo como serıan editar y procesar una transaccion. Los servicios nodependen del estado de otras funciones o procesos. La tecnologıa concreta utilizada para prestar

el servicio no es parte de esta definicion.



28

no obstante se puede implementar una arquitectura SOA utilizando cualquier tec-

nologıa basada en servicios [4]. Al contrario que las arquitecturas orientadas a

objetos, los SOAs estan formados por servicios de aplicacion debilmente acopla-

dos y altamente interoperables. Para la comunicacion entre los servicios, se utiliza

la definicion formal WSDL que es independiente de la plataforma y del lenguaje

de programacion, de esta forma se encapsulan las particularidades de una imple-mentacion especifica, logrando de esta forma una mayor integracion entre servicios

dados por los lenguajes de programacion o las tecnologıas utilizadas. En un SOA

se trabaja con servicios “sin estado”, lo que significa que los servicios no son de-

pendientes de la condicion de ningun otro servicio. Reciben en la llamada toda

la informacion que necesitan para dar una respuesta, y debido a que los servicios

son “sin estado”, pueden ser secuenciados (orquestados) en numerosas secuencias

(algunas veces llamadas tuberıas o pipelines) para realizar la logica del negocio.

2.4.3. Diseno y Desarrollo de un SOA

La utilizacion de la metodologıa de modelado y diseno de aplicaciones SOA se

conoce como analisis y diseno orientado a servicios, la que entrega un marco de

trabajo para el desarrollo de software interoperable desde su concepci on, imple-

mentacion y puesta en marcha. Lo que significa, que para que un proyecto SOA

tenga exito, en todas las etapas de ingenierıa de software tiene que estar presen-

te la mentalidad de crear servicios comunes, los que seran orquestados22 por los

clientes o middleware23 para implementar sus procesos de negocio.

2.4.4. Componentes de un SOA

Cuando hablamos de un SOA, estamos hablando de un conjunto de servicios

residentes en Internet o en una intranet usando servicios Web. Los conceptos

relacionados son XML, HTTP, SOAP, WSDL, UDDI (Ver capıtulo 2.3.4). Sin

embargo, hay que considerar que un sistema SOA no necesariamente necesita

utilizar estos estandares para ser “orientado a servicios”, aunque es altamente

recomendado su utilizacion.

La Arquitectura Orientada a Servicios sirvio de base para estructurar de forma

adecuada los diferentes componentes de la integracion, ademas permitio establecer

lineamentos claros para construccion de nuevas herramientas de integracion y

ademas definio parametros necesarios en la construccion de los nuevos sistemas que

se construyan, dando paso a si a la consideracion de de construccion de sistemas

orientados a entregar servicios y no unicamente al usuario directo de la aplicacion.

22Orquestar: Secuenciar los servicios y proveer la logica adicional para procesar datos. Noincluye la presentacion de los datos. Coordinacion.

23Middleware: es un software de conectividad que ofrece un conjunto de servicios que hacenposible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogeneas.Mas informacion http://middleware.objectweb.org/



29

Figura 2.5: Ejemplo de estructura basica



30

2.5. Seguridad Informatica

Los sistemas de informacion actuales son cada vez mas complejos, y si toma-

mos en cuenta que hace menos de veinte anos la informacion se obtenıa de los

datos almacenados en archivos de caracteres convenientemente codificados. Esta

informacion era utilizada normalmente para la comunicacion entre los diferentes

departamentos de las empresas o para ser trasmitida fuera de los lımites de estas.

Pero actualmente la informacion es administrada por sistemas de informacion, que

en la mayorıa de los casos son conectados a redes externas, en las cuales su infor-

macion ha sido centralizada para obtener mayores beneficios de estas, o en otros

casos la informacion ha sido distribuida convenientemente en Internet, pero en

ambos casos existen vulnerabilidades que continuamente han sido aprovechadas

por Hackers u otro tipo de usuarios daninos que con intensiones de robar infor-

macion, danar sistemas o simplemente aprender de los errores de otros, prueban y

penetran sistemas por los mas diversos medios. Como consecuencia de este incre-

mento de la vulnerabilidad, los proyectos de software han debido integrar dentro

de su proceso de elaboracion el concepto de seguridad informatica, tarea que ca-

da vez es mas difıcil definir y con metodos cada vez mas complejos de construir,

dando paso a nuevos estandares y utilizacion de metodos formales que permitan

la verificacion y validacion de las operaciones realizadas.



31

2.5.1. Definiciones

- Seguridad Informatica: El termino seguridad informatica viene del concepto

“seguridad”, el cual segun la Real Academia de la Lengua Espanola es “cua-

lidad de seguro”, que a su vez significa “libre y exento de todo peligro, dano o

riesgo” 24. A partir de estas definiciones mal se podrıa decir que la seguridad

informatica es “la cualidad de un sistema informatico exento de peligro” [2], pero como la seguridad no es un producto, sino un proceso, por tanto, no

es un bien medible, aunque si se pueden desarrollar diversas herramientas

para cuantificar de alguna forma la seguridad informatica. Basado en esos

terminos una definicion mas acertada la entrega el Dr. Ramio, quien postula

que seguridad informatica es “un conjunto de metodos y herramientas des-

tinados a proteger la informacion y por ende los sistemas informaticos ante

cualquier amenaza, un proceso en el cual participan ademas las personas.

Concienciarlas de su importancia en el proceso sera algo crıtico”.

- Hacker: Definicion inicial de los ingenieros del MIT que hacıan alardes de sus

conocimientos en informatica. Entre muchas clasificaciones estan las de Whi-

te Hat (generalmente no delictivos), Blak Hat (generalmente es delictivo) y

Grey Hat (reconvertidos por la empresa)25.

- Cracker: Persona que intenta de forma ilegal romper la seguridad de un sistema

por diversion o interes.

- Script kiddie: Un inexperto, normalmente un adolescente, que usara progra-

mas que descarga de Internet para atacar sistemas.

2.5.2. Seguridad Fısica y Seguridad Logica

La seguridad informatica contempla dos enfoques distintos [2]: la seguridad

fısica, que puede asociarse a la proteccion del sistema ante las amenazas fısicas,

incendios, inundaciones, edificios, cables, control de accesos de personas, etc.; y la

seguridad logica con la proteccion de la informacion en su propio medio, mediante

el enmascaramiento de la misma, usando tecnicas de criptografıa, las que son com-

plementarias, tanto ası, que en muchos casos cuesta diferenciar donde comienza

una y donde termina la otra, y entre ellas se encuentra la gestion de la seguridad

que contempla los planes de contingencias, polıticas de seguridad, normativas, etc.

2.5.3. Principios de la Seguridad Informatica

Existen tres principios basicos que deben considerarse en la seguridad in-

formatica, los que estan relacionados con el acceso mas facil, la caducidad del

24fuente: www.rae.es25Ver mas informacion http://www.umanizales.edu.co/encuentrohackers/tiposh.htm



32

secreto y la eficiencia de las medidas tomadas [2].

1er principio: “El intruso al sistema utilizara el artilugio que haga mas facil su

acceso y posterior ataque”. Existira una diversidad de frentes desde los que

puede producirse un ataque, tanto internos como externos. Esto dificultara el

analisis de riesgo ya que el delincuente aplicara la filosofıa del ataque hacia el

punto mas debil: el equipo o las personas. Por ello nace la pregunta ¿Cuales

son los puntos debiles de un sistema informatico?

2o principio: “Los datos confidenciales deben protegerse solo hasta que ese secre-

to pierda su valor como tal” se habla, por tanto, de la caducidad del sistema

de proteccion (tiempo en el que debe mantenerse la confidencialidad o se-

creto del dato). Haciendo la pregunta ¿Cuanto tiempo debera protegerse un

dato?

3er principio: “Las medidas de control se implementan para que tengan un com-portamiento efectivo, eficiente, sean faciles de usar y apropiadas al medio”.

- Efectivo: que funcionen en el momento oportuno.

- Eficiente: que optimicen los recursos del sistema.

- Apropiadas: que pasen desapercibidas para el usuario.

- Y lo mas importante: ningun sistema de control resulta efectivo hasta que

debemos utilizarlo al surgir la necesidad de aplicarlo. Junto con la creaci on

de conciencia a los usuarios, este sera uno de los grandes problemas de la

gestion de la seguridad informatica.

2.5.4. Criterios y normativas de seguridad

Los siguientes son criterios y normativas26 de seguridad que actualmente se

trabajan (tambien las instituciones gubernamentales estan implementandolas, lo

que le da mas seriedad y relevancia a estas normativas):

1. Criterio de evaluacion TSEC - Trusted Computer System Evaluation Crite-

ria, tambien conocido como Orange Book.

2. Criterio de evaluacion ITSEC - Information Technology Security Evaluation

Criteria.

3. Criterio de evaluacion CC - Common Criteria: incluye los dos anteriores.

4. Normativa internacional ISO 17799 (27001): La norma ISO 17799 tiene su

origen en la norma britanica BS7799-1 el que constituye un codigo de buenas

practicas para la gestion de la seguridad de la informacion 27, en esta se

26Ver mas informacion www.ccn.cni.es27

http://www.aenor.es/desarrollo/normalizacion/normas/resultadobuscnormas.asp?campobuscador=17799



33

establece la base comun para desarrollar normas de seguridad dentro de las

organizaciones. Esta norma ha logrado ser reconocida a nivel internacional,

contando actualmente con 36 objetivos de control y 127 controles, pero esta

norma aun no es certificable. Tambien presenta criterios y recomendaciones

basicas para establecer polıticas de seguridad.

El proyecto desde su concepcion ha sido encarecidamente enfocado cumplir

con las normas estandares de seguridad informatica, ademas se ha apoyado con

ello a consientizar al area informatica sobre los riegos de una programacion que

no contemple desde su desarrollo el aspecto de la seguridad de la informacion.



34

2.6. Legislacion Europea sobre Interoperabili-

dad

La interoperabilidad no es un tema aislado de unos cuantos investigadores,

sino es un tema que cada vez toma mayor importancia en los distintos rinconesdel mundo. A media que se van conociendo sus beneficios. Uno de los pioneros en

la investigacion sobre la integracion de sistemas e interoperabilidad, es la Union

Europea y principalmente sus universidades, las cuales han aportado gran parte

de las publicaciones existentes sobre el tema. Ademas de las investigaciones so-

bre interoperabilidad, se han creado lineamientos y leyes que estan aportando a

la estandarizacion en funcion de la interoperabilidad de muchos de los servicios

publicos, donde cada vez son mas exigidos por los ciudadanos como lo expone el

ministro espanol de Administraciones Publicas, Jordi Sevilla28 “se debera atender

el derecho de los ciudadanos a ser atendidos de forma telematica, servicio quedejara de ser una potestad de las distintas administraciones, para pasar a ser una

obligaci´ on ” y con ello se da un valor agregado al gobierno digital.

Si revisamos algunos de los planes de accion en tecnologıas de la informacion

europeos, encontraremos dentro de ellos que la preocupacion por la integracion de

los sistemas es realmente un tema importante, y para ello revisaremos algunos de

sus planes de accion relacionados a la interoperabilidad:

“El Marco de Interoperabilidad Europeo apoya la estrategia de la Union Eu-

ropea a proporcionar servicios eGovernment centrados en el usuario, a nivel pan-

europeo, la interoperabilidad de servicios y sistemas entre administraciones publi-cas, ası como entre empresa y el publico (ciudadanos, negocios)”, texto obtenido

del plan de acciones de la Comision Europea de E-Government (eEurope 2005)29.

“En cuanto a los trabajos de ISO, la finalizacion de los Borradores de Nor-

ma Internacional (DIS) esta programada para los anos 1999/2000. La familia de

normas contempla no solo el intercambio de datos, sino tambien la interoperabi-

lidad entre sistemas en el sentido OSE (Open System Environment). Los grupos

de trabajo de ISO/TC211 han tomado como punto de partida los resultados de

CEN/TC287”.

2.6.1. Legislacion Europea

La Union Europea esta muy preocupada de la penetraci on de los sistemas en

cada uno de sus servicios a los usuarios, es por ello que ha formado el equipo de

28ver mas en http://www.gobiernoelectronico.org/node/491829Comision Europea de E-Government

Mas informacion http://ec.europa.eu/idabc/en/chapter/5883



35

personas e instituciones RED GEALC30, que nace como un espacio de intercam-

bio de conocimiento, expertos y soluciones en todos los temas relacionados con el

gobierno electronico, con el fin de facilitar la colaboracion y el esfuerzo compar-

tido entre los gobiernos de la region, a traves de aquellas personas que tienen la

responsabilidad de manejar el dıa a dıa del gobierno electronico en sus respecti-

vos paıses, junto a ello existe tambien el avanzado decreto del gobierno espanolREAL DECRETO 209/200331, en el cual se regula los registros telematicos, los

certificados y transmisiones telematicas.

El equipo de Innovaciones y Alianzas para el Desarrollo de la SEDI/OEA

(Organizacion de Estados Americanos) y el Instituto para la Conectividad en las

Americas (ICA) han unido sus fuerzas para apoyar la creacion y el desarrollo de

la Red de Lıderes de Gobierno Electronico de America Latina y El Caribe (RED

GEALC), y en el 2006 se sumo el apoyo del Banco Interamericano de Desarrollo

(BID) a traves de su programa de Bienes Publicos Regionales. Uno de los grandes

aportes y misiones de este grupo esta basado en el documento de eLAC 2007,en la Meta 15 correspondiente a Gobierno Electronico, en el que se establecio la

importancia de “crear y/o fortalecer medios de intercambio sobre servicios de

gobierno electronico, tales como la Red de gobierno electronico de America Latina

y el Caribe (REDGEALC)....”

2.6.2. Marcos de Interoperabilidad

Los Marcos de Interoperabilidad son aquellos documentos donde se describe y

detalla que protocolos y formatos son considerados estandares abiertos32 en ma-yor o menor medida, por parte de quien redacta el marco. Generalmente suelen

tener tras de sı, un amplio estudio de protocolos y formatos informaticos y una

dilucidacion argumentada para cada uno de sus elementos de si cumple las con-

diciones para ser aceptado como estandar abierto o no. Es relativamente comun

que las decisiones de si algo cumple o no las condiciones de interoperabilidad y de

apertura, sean complejas, pues suelen existir muchos parametros que medir. Es

siempre muy interesante basarse en trabajos realizados por otras entidades para

ası no tener que re-inventar la rueda cada vez.

2.6.2.1. Objetivos del Marco de Interoperabilidad

Para ayudar en la mejor estructuracion del marco de interoperabilidad se han

establecido objetivos claves en el que se entregan los lineamentos y estrategias

para el desarrollo de este, los objetivos son [24]:

30Red GEALC: Red de Lıderes de Gobierno Electronico de America Latina y El Caribe.Mas informacion en http://www.redgealc.net/

31Ver Mas informacion en http://www.csi.map.es/csi/pg2023.htm32

Mas informacion disponible en http://www.estandaresabiertos.com/



36

1. Apoyar la estrategia de la Union Europea en cuanto a la provision de ser-

vicios electronicos centrados en el usuario, mediante la interoperabilidad de

los servicios y sistemas de las administraciones publicas, ası como entre las

administraciones, los ciudadanos y las empresas, a nivel paneuropeo.

2. Complementar los marcos nacionales de interoperabilidad en aquellas areas

que no pueden ser tratadas adecuadamente desde una perspectiva puramente

nacional.

3. Ayudar a conseguir la interoperabilidad en y entre diferentes areas sectoria-

les, especialmente en el contexto del Programa IDABC33 y en otros progra-

mas e iniciativas comunitarias relevantes.

Respecto a la legislacion relacionada con la interoperabilidad, existe el Real

Decreto 263/1996, que dice que en conformidad con normas nacionales e interna-

cionales exigibles; “Existencia de compatibilidad entre el emisor y el destinatario,utilizacion de codigos y formatos o disenos de registro establecidos por la AGE34;

Publicacion de la relacion de las aplicaciones, medios y soportes a traves de los

cuales se podran efectuar las comunicaciones y notificaciones, especificando, en su

caso, los formatos y codigos normalizados para su utilizacion.” Y recomienda: “Es-

tablecer unos estandares mınimos en la Administracion que faciliten el desarrollo

de los servicios y su uso por parte de ciudadanos y empresas. ... Para conseguir-

lo sera necesaria la adopcion de sistemas y estandares abiertos (XML y HTML)

compatibles con las infraestructuras existentes en las Administraciones Publicas

que permitan interoperar independientemente de las estrategias particulares demarca”.

Tambien existen una serie de recomendaciones que apoyan la interoperabilidad

entre sistemas, entre las mas importantes se encuentra la “recomendaci´ on tecnica

11”35 , que esta a nivel back-office36, y se refiere a los aspectos de interoperabilidad

tecnica que debieran ser considerados:

1. Integracion de datos y middleware

2. Estandares basados en XML

3. Estandares basados en EDI37

4. Servicios Web

33IDABC stands for Interoperable Delivery of European eGovernment Services34AGE: Asociacion de Geografos Espanoles35Mas informacion en http://www.csi.map.es/csi/pg3315.htm36BACK OFFICE (trastienda de la oficina) es la parte de las empresas donde tienen lugar las

tareas destinadas a gestionar la propia empresa y con las cuales el cliente no necesita contactodirecto.

37EDI (Electronic Data Interchange): El Intercambio Electronico de Datos es un conjunto

coherente de datos estructurado conforme a normas estandares para la transmision por medioselectronico entre entidades.



37

5. Arquitectura de aplicaciones distribuidas

6. Servicios de interconexion

7. Protocolos de transferencia de ficheros y mensajes

8. Transporte y seguridad de mensajes

9. Servicios de almacenamiento de mensajes

10. Acceso a buzones de correo

11. Servicios de directorio y de nombres de dominio

12. Servicios de red.

Tambien como referencia podemos citar el documento “criterios de conserva-

cion” [20] preparado por la Consejo Superior de Informatica para el impulso de la

Administracion Electronica.

2.6.3. Servicios Interoperables en Produccion

Entre los sistemas que ya se encuentran en creacion existe una gama estatal

que se encuentra realizando pruebas de interoperabilidad, entre estos estan los

siguientes:

1. Portal de las Administraciones de la Union Europea (Your Europe)

http://europa.eu.int/youreurope/

2. Portal Europeo de Movilidad Profesional EURES

http://europa.eu.int/eures/home.jsp?lang=es

3. Portal Europeo de Oportunidades de Formacion, PLOTEUS

http://europa.eu.int/ploteus/portal/home.jsp

4. SOLVIT http://europa.eu.int/solvit/site/

5. Tu Voz en Europa (Your Voice)

http://europa.eu.int/yourvoice/

6. Observatorio de la Administracion electronica

http://europa.eu.int/idabc/en/chapter/140

El nacimiento del proyecto tiene directa relacion con la tendencia en Europa de

establecer la integracion de los servicios a los ciudadanos, esta tendencia ha sido

apoyada por legislaciones rigurosas y proyectos que buscan orientar a brindar una

mejor utilizacion de los recursos, es por ello que fue de mucha importancia conocer

cuales eran las directrices que forjaron la gran utilizaci on de la interoperabilidad

e integracion de sistemas en Europa, sobre todo cuando esta ha dado tan buenosresultados.



Capıtulo 3

SITUACION ACTUAL

El portal Iglesia.cl desde un comienzo ha buscado brindar informacion actuali-

zada de la iglesia, y particularmente de los temas de Chile, como tambien ofrecer

servicios formativos y recursos para la evangelizacion. Para esto se comenzo en

1999 con un servidor Macintosh con 128 MB de RAM, y con un acceso de ADSL

dedicado de 512 Kbps con el cual brindaba servicio Hosting 65 sitios de las distin-

tas areas de la institucion. La pagina principal contaba con noticias en formato

HTML las que actualizaban diariamente el equipo de periodistas y disenadores en

forma manual, teniendo un archivo de formato HTML por cada noticia, haciendo

de este un proceso lento y complejo, el cual se hacia cada vez mas inviable en el

tiempo debido a la dificultad para realizar indexacion y busquedas. En el ano 2003,

nace la necesidad por parte de la Vicarıa de pastoral universitaria (www.vpu.cl)

de integrar nuevas tecnologıas a los servicios Web entregados, estos nuevos reque-

rimientos eran la utilizacion de una plataforma dinamica con utilizacion de bases

de datos para una mejor comunicacion con los usuarios de la pagina. Este nuevo

requerimiento creo en Iglesia.cl la necesidad de integrar nuevas tecnologıas a su

servidor, resultando de esto un servidor mucho mas potente y ubicado fısicamente

en la Universidad Catolica de Chile, el que contaba con el sistema operativo MAC

OS X de plataforma UNIX, soporte para PHP (pre-procesador de hipertexto)

y servidor de bases de datos Mysql. En este proceso realizamos la instalaci on y

configuracion y pruebas de funcionamiento del servidor junto al equipo que actual-

mente formo parte en Iglesia.cl. La implementacion de esta nueva tecnologıa dio

paso a nuevos desafıos los cuales dieron como resultado varios sistemas, entre los

que se destaca el sistema de administracion de contenidos (http://sac.iglesia.cl) el

cual administra los datos estructurales del portal (noticias, documentos, recortes

de prensa), sistema que cuenta tambien con administracion de perfiles de usuarios

(actualmente existen 3 administradores y 23 corresponsales de noticias de todas

las diocesis Chile), brindando acceso solo a los recursos correspondientes a cada

perfil de usuario y como valor agregado avisando a los administradores del sistemay al corresponsal respectivo mediante un e-mail sobre el evento ocurrido. Otras

38



39

implementaciones importantes son la administracion de informacion sobre obis-

pos, vicarıas, parroquias, sacerdotes, diaconos, casas de retiro, colegios catolicos,

congregaciones y santuarios, los cuales estan disponibles actualmente en el sitio

www.iglesia.cl.

Tras los antecedentes de la situacion actual se requiere dar un paso hacia delan-

te y lograr la integracion de los sistemas actualmente existentes en la institucion,para mantener la informacion permanentemente actualizada entre los sistemas y

brindar en conjunto un mejor servicio a la comunidad.

Ademas se cuenta con el paquete de software de analisis estadıstico SPSS, el

cual permite complejos analisis estadısticos, el que se utilizara para procesar los

datos extraıdos del sistema final.



40

3.1. Situacion Sin Sistema

Antes de la integracion de los sistemas, solo existıa un conjunto de sistemas, lo-

calizados en distintos lugares fısicos (servidores), ademas no contaban con ningun

tipo de comunicacion entre ellos, y que ademas los usuarios directos e indirectos

de dichos sistemas tambien son diferentes.

A continuacion se presentara la situacion existente antes del integracion de los

sistemas, realizandose una descripcion de cada uno de los sistemas por separado,

y para un mejor entendimiento del problema, se describira la estructura organiza-

cional de cada uno, la descripcion del sistema que le corresponde, y su modelo de

bases de datos en estado nativo, es decir, el modelo de datos que existıa durante

la creacion de la federacion de sistemas.

A continuacion se presentan las entidades con sus respectivos sistemas antes

de realizar la integracion, como lo son la oficina de estadısticas para la pastoral,

oficina de comunicaciones de la CECH, y el portal Web Iglesia.cl, sistema de

administracion de documentos y el sistema historico de fotografıas.

Sistema Funciones

Sistema Directorio Virtual

de la Iglesia en Chile.

Informacion de personas, organizaciones y es-

tructuras organizacionales.

Sistema de Administracion

de Contenidos (SAC)

Contiene las noticias a nivel de todas las

diocesis de Chile, documentos eclesiales, y los

recortes de prensa vinculados a la iglesia yque a diario aparecen en la prensa nacional.

Sistema del Portal Web Igle-

sia.cl

Administra la informacion de organizaciones

eclesiales, casas de retiros, diocesis, personas

del diaconado. Ademas entrega el servicio de

hosting a paginas catolicas.

Sistema de Archivo Histori-

co de Documentos

Contiene una completa coleccion de documen-

tos eclesiales.

Sistema de Archivo Histori-

co de Fotografıas

Administra un conjunto importante de recur-

sos fotograficos de distintas areas de la igle-

sia representando un gran valor de interes

academico y periodıstico.



41

Figura 3.1: Pagina Interior del Sistema de Directorio Virtual

3.1.1. Oficina de Estadısticas para la Pastoral

La Oficina de Estadısticas para la Pastoral, de la Conferencia Episcopal de

Chile, inicio sus funciones el 1◦ de octubre de 2003. Su proposito es la implemen-

tacion de un servicio estadıstico y de analisis de la informacion religiosa de la

Iglesia Catolica en Chile. Entre sus funciones esta la de centralizar la informa-

cion referida a las diocesis, institutos de religiosos y religiosas, agentes pastorales

y pastorales especializadas; homogenizar criterios estadısticos, y elaborar analisis

de datos. La Oficina de Estadısticas para la Pastoral, depende de la Secretarıa

General de la Conferencia Episcopal de Chile.

3.1.1.1. Sistema Directorio Virtual de la Iglesia Catolica en Chile

El directorio virtual es un sistema desarrollado en la Conferencia Episcopal

de Chile, el cual permite la administracion de datos de las entidades, personas

y cargos de la iglesia local, formando una completa guıa a nivel nacional de las

personas y entidades, que debido a la gran movilidad en cuanto a los cargos y lu-

gares fısicos de desempeno de estos, serıa imposible tenerla actualizada, ademas el

sistema permite obtener estadısticas estratificadas por grupos etereos de personas

e instituciones, ademas cuenta con la capacidad de entregar archivos en forma-

to Excel para su facil y rapido analisis con otros productos de software como es

el SPSS1. El sistema se encuentra alojado en un servidor Mandrake Linux en el

subdominio http://estadisticas.iglesia.cl/, el cual fue creado en lenguaje PHP en

1

SPSS software de analisis estadıstico



42

Figura 3.2: Modelo de Datos Directorio Virtual

combinacion con la base de datos Mysql, y se han creado perfiles de usuarios pa-

ra las diferentes diocesis y estructuras institucionales, lo que provee una rica y

contante actualizacion de los datos locales. La descentralizacion de los suminis-tradores de informacion ayudan a una dinamica simple y co-responsable de los

datos.

3.1.1.2. Modelo de Datos Nativo

El modelo de datos nativo (ver figura 3.2) del sistema de administracion del

directorio virtual consta de 53 tablas relacionales, las que han sido creadas pen-

sando en la facilidad de modificacion estructural del sistema, y facil consulta a los

datos, formando una estructura tipo piramidal de instituciones, en las cuales loscargos de las personas se van entrelazando. Este modelo de datos es uno de los

mas grandes y complejos que cuenta la CECH, en el cual existen datos publicos

y privados, es por ello que a este modelo de datos se deben aplicar las polıti-

cas de seguridad y privacidad de datos, para ası proteger la informacion sensible

existente.



43

Figura 3.3: Pagina Principal del Sistema SAC

3.1.2. Oficina de Comunicaciones de la CECH

La Oficina de Comunicaciones y Prensa de la Conferencia Episcopal de Chile

inicio sus actividades el 3 de junio de 2002. Responde a una de las prioridades

analizadas por los obispos en la 83a Asamblea Plenaria, en cuanto a la necesidad

de satisfacer las multiples demandas de contenidos y de fuentes por parte de los

medios de comunicacion, cuya mision en la sociedad la Iglesia valora grandemente.

3.1.2.1. Sistema de Administracion de Contenidos (SAC)

Sistema de administracion de contenidos vıa Web, en el que se permite la

administracion de noticias, recortes de prensa, documentos relacionados con la

iglesia, cuenta a su vez, con la administracion de perfiles de usuarios de privilegios

personalizados en el cual los distintos corresponsales de las diocesis de Chile van

agregando diariamente a su acontecer local. Ademas esta provista de herramien-

tas personalizadas que permiten compartir la informacion con otras entidades por

medio de seleccion de noticias especificas. La informacion que va siendo agregada

cuenta con dos fases de aceptacion, en el cual los contenidos antes de ser incluidos

en el portal son revisados y editados por el equipo de comunicaciones del episco-

pado. El sistema se encuentra en el subdominio http://sac.iglesia.cl/ y su servidor

es un Mac Os X.



44

Figura 3.4: Modelo de datos SAC

3.1.2.2. Modelo de Datos Nativo

El modelo de datos nativo (ver figura 3.4) para el SAC, consta de 10 tablas,

las cuales han sido modificadas y adaptadas en varias ocasiones por ampliaci on

y diversificacion de los datos del sistema. Los principales datos del sistema son

extraıdos desde la tabla noticias, recortes de prensa y documentos, pero en este

modelo se integro una nueva tabla [SANTIAGO NOTICIAS], la que es utilizada

por un mini sistema administrado por el portal del Arzobispado de Santiago, que

recurre a la base de datos de las noticias del portal iglesia.cl.



45

Figura 3.5: Pagina Principal Porta Web Iglesia.cl

3.1.3. Portal Web Iglesia.cl

Iglesia.cl es el portal de la Conferencia Episcopal de Chile (CECH), como tam-

bien es un proveedor de hosting a las diocesis y otros organismos de Iglesia. La

mision de Iglesia.cl es brindar informacion actualizada de la Iglesia, y particular-

mente de los hechos y temas relacionados al vınculo iglesia-paıs; abrir espacios

de opinion y reflexion sobre distintos temas de la vida eclesial y nacional; ofrecer

servicios formativos, recursos para la evangelizacion, y acompanamiento espiritual.

3.1.3.1. Bases de Datos Iglesia.cl

El portal iglesia.cl recurre actualmente a los datos ofrecidos por el sistema de

administracion SAC. Cuenta con una serie de datos, los cuales han sido almace-

nados en bases de datos que se van actualizando de forma esporadica o a medida

que van surgiendo cambios. Estos cambios son avisados por los miembros de las

diocesis o por la curia. Las bases de datos existentes contemplan datos en tablas

no relacionales (ver figura 3.6), las cuales van llenando la informacion del portal.

Ademas el portal Iglesia.cl entrega servicio de Hosting para mas de 80 institucio-

nes de la Iglesia en Chile, a los cuales tambien provee de un servicio de banner en

javascript que alimenta de noticias a las paginas que lo requieran. Actualmente se

encuentra alojado en un Servidor Mac OS X, bajo el dominio de iglesia.cl, el que

se aloja en las dependencias de la Pontificia Universidad Catolica de Chile.



46

Figura 3.6: Modelo de Datos Portal Iglesia.cl



47

Figura 3.7: Modelo de datos Documental

3.1.4. Sistema de Archivo Historico de Documentos

El sistema de Archivo Historico de documentos fue creado con el fin de re-

emplazar al antiguo sistema de administracion de documentos del SAC, de formaque este fuera mucho mas completo, ya que existen clasificaciones, categorıas y

nuevos datos que no contemplaba el antiguo sistema, ası tambien, los documentos

se complementaron con fotografıas de las portadas de cada documento, ademas la

informacion para este nuevo sistema (ver figura 3.7), fue trabajado en este mismo

proyecto por una Historiadora con doctorado en Historia de Chile.



48

Figura 3.8: Modelo de datos Fotografıas

3.1.5. Sistema de Archivo Historico de Fotografıas

El sistema de Archivo historico es complementario al sistema de documentos,

ya que no existıa ningun tipo de registro historico de los sucesos importantes de

la vida de la iglesia catolica, en este nuevo sistema se recolecto una gran cantidad

de fotografıas de las distintas instituciones y diocesis de Chile (ver figura 3.8), las

que fueron seleccionadas y trabajadas por una periodista especialista en imagen,

hecho que comprometio el trabajo en conjunto del portal iglesia.cl y el area de

comunicaciones del Episcopado.



49

3.2. Despues de la Integracion de los Sistemas

Despues de la integracion de los sistemas comprometidos, los datos pueden ser

compartidos por dichas entidades de forma transparente y simple, utilizando un

componente nuevo que se agrega. Este nuevo componente, permite la interaccion

segura entre las entidades; a su vez, se logra que una pagina central sea la puerta

de acceso a toda la informacion contenida en los distintos sistemas, es decir, des-

pues de la integracion se cuenta con informacion mas completa y mejor vinculada.

Por ejemplo, se tiene la informacion de los plesbıteros junto a la informacion de

su entidad fısica, la que a su vez se complementa con los accesos a la informa-

cion de su arbol de jerarquıa de entidades, lo que significa la posibilidad de una

navegacion a traves de todo el arbol de entidades e instituciones de las distintas

diocesis, sumando a ello las noticias, recortes de prensa, documentos, fotografıas,

informacion de tipo territorial, etc. Esta informacion se obtiene en tiempo real de

las fuentes originales, la cual no estaba antes disponible, ni tampoco existıa la po-

sibilidad de que estos sistemas fueran modificados y ampliados estructuralmente

para contar con la informacion complementaria,debido en parte a la escasez de

recursos humanos disponibles para reunir y mantener constantemente actualizada

la informacion de todas las entidades de la iglesia de Chile.

Tambien se agregan dentro de los aportes del sistema integrador la implemen-

tacion de dos modulos de sistemas nuevos que son necesarios para la integridad

de los datos; estos son: el sistema documental y el archivo fotografico, los cuales

contribuyen y complementan la informacion existente en los sistemas anteriores a

la integracion.Otra de las caracterısticas importantes que se adquieren despues de la inte-

gracion, es la capacidad de agregar mas cantidad de sistemas, ya que el creciente

volumen de datos existentes no hace posibles mantenerlos en un solo sistema; con

esto se puede recoger una mayor cantidad de informacion.

Por ello, la creacion de un sistema integrador de los sistemas ya existentes, a su

vez que permite integrarse a los modulos de de nuevos sistemas que se construyan,

entrega las herramientas, estandares y buenas practicas resultantes de la imple-

mentacion de la interoperabilidad a nivel de la Conferencia Episcopal de Chile,

que se traduce ademas a un esquema de integracion a nivel nacional.



50

3.3. Problematica

El escenario antes del proyecto se presenta como un conjunto de cuatro siste-

mas informaticos con distintos tipos de informacion de valor incalculable, en los

que se han invertido importantes recursos para su creacion, ademas de contar con

una cantidad importante de usuarios a nivel nacional, quienes contribuyen en la

constante actualizacion de los datos de cada uno de los sistemas, existiendo dife-

rentes plataformas para cada uno y con algun grado importante de redundancia

de datos entre ellos.

El problema entonces presentado, es que cada vez que un usuario requiere de

algun tipo de informacion, este debe referirse a los distintos sistemas, y al ser

estos administrados por distintas personas, pueden que no esten con la informa-

cion actualizada o exista disparidad de dicha informacion. A su vez, los sistemas

cuentan con algunos datos que son complementarios entre sı, y la riqueza que ello

representa se ve perdida porque los datos se encuentran dispersos en distintos ser-

vidores, con distintas plataformas y con distintos tipos de usuarios que ingresan

o consultan su informacion.

Esta problematica se requiere resolver haciendo posible que los distintos datos

existentes formen uno solo; ademas, que estos datos puedan ser utilizados comple-

mentarios entre si, es decir, que si el sistema A cuenta con un tipo de dato que sea

complementario con los datos del sistema B , este pueda contar con dicha informa-

cion de forma transparente, simple y rapida. Se requiere tambien de la creacion de

una plataforma de consulta comun para el usuario final, en el cual pueda obtener

la informacion del conjuntos de sistemas, como si se tratase de uno solo, con losbeneficios de la transparencia, rapidez y robustez necesarias para un portal que es

altamente consultado por usuarios que requieren de una informacion mucho mas

completa y lo mas actualizada posible para su utilizacion en trabajos pastorales,

recursos para la prensa escrita y grafica, usuarios del directorio de obispados de

chile, usuarios comunes en busqueda de textos historicos digitalizados, etc.

3.4. Analisis de Alternativas de Solucion

A continuacion se realizara un estudio de diferentes alternativas que puedan

de forma alguna satisfacer la problematica, cumpliendo con la mayor cantidad de

requerimientos. Se veran tambien detalles tecnicos que implican cada una de ellas,

sus beneficios y desventajas en la implementacion final.



51

3.4.1. Creacion de un Nuevo Sistema

La alternativa de creacion de un nuevo sistema, es la primera opci on que se

piensa cuando se tiene un requerimiento importante, sobre todo cuando se cuenta

con un sistema anteriormente creado y principalmente no documentado (situacion

que suele suceder en sistemas pequenos). En el caso especıfico presentado, es muy

tentador realizar un programa que contemple diferentes perfiles de usuarios, loscuales acceden a un solo sistema que cuenta con los sistemas de estadısticas,

directorio virtual, administracion de contenidos, etc.

Las ventajas y las desventajas mas son relevantes:

Beneficios Desventajas

El principal beneficio que pre-

senta crear un nuevo sistema,

es la simplicidad de estandari-

zar procesos entre las entidades.

Este beneficio se traduce en un

nuevo relevamiento de informa-

cion en todas las entidades, dan-

do origen a una tabla de reque-

rimientos de cada entidad. En

cuanto al sistema, este podrıacontar con interfaces comunes

para las entidades.

Las entidades no se encuentran

en lugares fısicos cercanos, ni su

dependencia jerarquica institu-

cional facilita la union de tareas

especificas en el sistema.

Los sistemas actuales, cuentan

con servidores Web independien-

tes, lo que permite una respuesta

mas rapida de los sistemas.

Los usuarios directos de los siste-

mas no pertenecen a una misma

entidad.

No existen recursos suficientes

para la construccion de un nuevo

sistema con todas las funciones

existentes en los sistemas origi-nales, ademas el tiempo contem-

plado para la dicha solucion su-

pera los dos anos contando con

un solo programador.



52

3.4.2. Integracion de Plataformas

La alternativa de crear un sistema integrado a partir de modulos Webservices

insertos en cada sistema, es una alternativa resultante de la revisi on de soluciones

implementadas en Europa.

Esta solucion contempla la utilizacıon del concepto de bases de datos federadas

como concepto base y la arquitectura orientada a servicios, la cual permite estruc-turar correctamente los distintos servicios que entrega cada sistema por separado.

La revision de los sistemas por separado permite obtener una idea general

de la riqueza de los datos de cada sistema, y como esta se multiplica al reunir

la informacion en un solo portal y que ademas los sistemas puedan recurrir a

recursos de otros sistemas.


No es necesario crear nuevos sis-

temas para las entidades, sino

que se utiliza la misma informa-

cion y estructura existentes.

La integracion se lleva a cabo por

medio de un modulo integrador

facil de modificar y mantener.

Se cuenta con la experticia y co-

nocimiento a fondo de los siste-

mas (tres de los sistemas a in-

tegrar fueron implementados por

el autor de este proyecto).

Se necesita conocer cada siste-

ma, sus modelos de datos y la

logica de obtencion de datos de

cada sistema por separado.

Es necesario establecer estanda-

res para que otros sistemas pue-

dan comunicarse con los siste-mas ya integrados.



53

3.4.3. Compra de un Software Comercial

La existencia de software comercial es una alternativa importante, sobre

todo si hablamos de soluciones rapidas y robustas. Las alternativas comerciales

revisadas son: SAP NetWeaver2 y Oracle SOA Suite3. Las ventajas y desventajas

de implementar un sistema integrado con un software especıfico, son las siguientes:


Cuenta con la experiencia de la

empresa creadora del software y

de quienes ya lo han implemen-

tado.

Permite desarrollar rapidamente

contenidos para los portales que

cuenten con la herramienta.

Posibilidad de extensibilidad y

robustes propias de las empresas

creadoras.

Se cuenta con las buenas practi-

cas entregadas por los proveedo-

res del software.

En necesario mucho entrena-

miento para la adaptacion a la

nueva plataforma a nivel de ad-

ministradores.

Es necesario contar con expertos

en el software.

No permite el nivel de persona-

lizacion de las salidas de datos

requeridas.

Se encuentra sobredimensionado

para el impacto de la integracion

requerida.

No se cuenta con los recursos su-

ficientes para adquirir el produc-

to.

2Mas informacion http://www.sap.com/andeancarib/solutions/netweaver/3Mas informacion http://www.oracle.com/technologies/soa/soa-suite.html



54

Figura 3.9: Esquema de Integracion

3.4.4. Eleccion de la Solucion

Una vez estudiadas las ventajas y desventajas de las distintas alternativas

de solucion, se resuelve que la segunda alternativa de “integracion de las plata-

formas”, es la mas viable, ya que resuelve la mayor cantidad de problemas, se

ajusta a los recursos existentes y ademas, como valor agregado, da la posibilidad

de integrar mas fuentes de datos en el futuro, como tambien la posibilidad de

compartir la informacion de los miembros de los sistemas a integrar con otros sis-

temas externos, con herramientas de facil utilizacion, siendo el principal y unico

requerimiento extra el contar con un servidor con PHP, sin requerir de motores

de bases de datos, ni estructuras especiales para realizar la conexion diferentes a

una conexion HTTP por el puerto 80.



Capıtulo 4

SOLUCION PROPUESTA

Dado el creciente desarrollo tecnologico y el auge que ha experimentado el

uso de Internet en el area comunicaciones a nivel mundial, y sumado a esto la

mayor cantidad de personas con conectividad a la red, es que la Iglesia Catolica

de Chile ha querido dar respuesta a los nuevos tiempos con herramientas TI’s

(tecnologıas de la informacion), en un inicio con sencillas paginas Web donde las

distintas organizaciones utilizaban para darse a conocer e informar de su ubica-

cion o subir un par de documentos y/o noticias. Las organizaciones con el tiempo

fueron necesitando administrar datos, lo que se tradujo en sistemas informaticos

que actualmente administran informacion de personas y organizaciones. Estos sis-

temas fueron creados en forma independiente y sin ningun tipo de integracion,

ni estandar entre ellos, lo que provoco redundancia de datos y en otros casos, un

aislamiento medio o total de cada modulo. Dado los antecedentes anteriores, es

que hoy se requiere la complementacion de datos de los distintos obispados, los

registros sacramentales, documentos de la conferencia episcopal de Chile, regis-

tros de noticias y recortes de prensa, registros graficos, informacion de parroquias,

sacerdotes, diaconos, etc. Como solucion, se propone la construccion de un mo-

delo de bases de datos federada (base de datos ınter-operativas e integradas) y

su implementacion, en el cual se integrara informacion seleccionada de los distin-

tos sistemas existentes por medio de WEBSERVICES y XML, cuyas tecnologıas

estan actualmente implementandose en distintos paıses, buscando dar solucion

a la fragmentacion de datos y la complejidad que significarıa el generar un solo

sistema que diera respuesta a todos los requerimientos.

Como complemento al proyecto, tambien se implementaran dos subsistemas:

banco documental y banco fotografico. Estos sistemas ya contaran desde un co-

mienzo con la idea de sistemas complementarios para la base de datos federada

que se implementara en el proyecto macro.

55



56

Figura 4.1: Estructura de Integracion a Nivel de Servidores

4.1. Propuesta

Se propone obtener interoperabilidad e integracion de los sistemas existentes

de la CECH, mediante la implementacion de un sistema integrador basado en

las nuevas formas de almacenamiento con bajo grado de acoplamiento como loson las bases de datos federadas, buscando ası que se logre una capa de software,

con modulos capaces de servir y consumir recursos de las bases de datos de los

otros sistemas, de tal forma que los sistemas actuales logren la cooperacion como

entidades independientes pero con acceso integrado a multiples bases de datos

autonomas por medio de Webservices.

El esquema (ver figura 4.1) presenta la forma de interaccion esperada entre los

sistemas existentes por medio de Webservices.

4.2. Objetivos

4.2.1. Objetivo general

Desarrollar un sistema integrador que permita a los sistemas informaticos de

la Iglesia Catolica de Chile, la interaccion e integracion de sus datos mediante la

tecnologıa de Webservices y XML.



57

4.2.2. Objetivos especıficos

1. Busqueda y revision bibliografica sobre nuevos metodos de almacenamiento

en bases de datos distribuidas e interoperabilidad.

2. Desarrollar prototipos de comunicacion entre servidores y clientes Webser-

vices para compartir datos entre sistemas.

3. Desarrollar un prototipo de una base de datos federada, para la evaluacion

de su comportamiento en un entorno Web.

4. Integrar y relacionar los sistemas informaticos mediante un sistema integra-

dor que permita la interaccion e integracion de los sistemas componentes sin

que estos pierdan su autonomıa, ni se requiera modificaciones en su estruc-

tura de bases de datos ni en su parte l ogica. La integracion se basara en la

teorıa de bases de datos federadas y Webservices, con la construccion de un

modelo de datos por capas de integracion que en su capa uno se encuentranlos sistemas originales y en la capa dos se muestra el conjunto de sistemas y

sus relaciones, y en la capa tres los datos estan mezclados y no se diferencian

los sistemas, sino que se ven como una sola gran base de datos de la cual se

puede consultar por metodos predefinidos.

5. Desarrollar un nuevo sistema administracion de contenidos para el portal de

noticias y recursos pastorales www.iglesia.cl, que contendra distintos perfiles

de usuarios, con los cuales se podra administrar las publicaciones de cada

diocesis por un equipo de redaccion centralizado.

6. Desarrollar un nuevo sistema administracion de informacion para la ofici-

na de estadısticas pastorales de la CECH, que sera el directorio virtual de

la iglesia Catolica Chilena. Este sistema permitira la administracion de la

informacion de personas e instituciones ligadas a la iglesia con una adminis-

tracion por niveles de acceso.

4.3. MetodologıaPara la construccion del sistema integrador se ha pensado en las siguientes

etapas siguiendo la aplicacion metodologica de la ingenierıa del software:

1. Busqueda y revision bibliografica sobre “nuevos metodos de almacenamiento

en bases de datos distribuidas e interoperabilidad”.

a ) Recopilacion bibliografica de temas relacionados.

b) Documentacion sobre las tecnologıas y protocolos a utilizar (Webser-

vices, XML, XML-Soap)



58

2. Desarrollar prototipos de comunicacion entre servidores y clientes Webser-

vices para compartir datos entre sistemas.

a ) Implementacion de prototipos servidor y cliente Webservices para la

integracion de datos simples.

b) Implementacion de prototipos servidor y cliente Webservices para la

integracion de datos complejos.

c) Eleccion del prototipo adecuado para la solucion requerida.

3. Desarrollar un prototipo de una base de datos federada, para la evaluacion

de su comportamiento en un entorno Web.

a ) Implementacion de un prototipo de base de datos federada.

b) Pruebas de compatibilidad y rendimiento del prototipo en un entorno

Web con Lenguaje PHP y Motor de Base de Datos MySql Server.

4. Estructuracion de tabla de requerimientos e implementacion de los nuevos

sistemas (estadısticas y portal Web).

a ) Relevamiento de informacion para ambos sistemas.

b) Recopilacion de antecedentes y creacion de tabla de requerimientos.

c) Diagramacion del modelo de datos.

d ) Implementacion de plataforma para ambos sistemas, creacion de perfi-

les de usuarios, pantallas generales.

e) Implementacion los modulos necesarios para cada sistema.

f ) Revision final y aplicacion de respaldos automaticos.

5. Modelacion de una base de datos federada con los modelos de datos exis-

tentes.

a ) Se disenara un modelo de bases de datos federadas basado en el es-

quema de BLOOM99 (el modelo BLOOM presenta la integracion por

capas de los esquemas nativos de bases de datos los cuales se van inte-

grando hasta llegar a un esquema federado e integrado de las bases dedatos)

6. Implementacion del sistema integrador

a ) Definicion de datos a compartir entre sistemas.

b) Creacion de estructuras XML para las consultas entre los sistemas.

c) Implementacion de modulos para cada sistema, que permitan el paso

de preguntas y respuestas entre ellos.

d ) Documentacion de metodos existentes y requerimientos para el consu-mo de recursos de la base de datos federada de la CECH.



59

e) Implementacion del sistema que permita la consulta integrada de datos

al sistema federado.

7. Analisis y documentacion de los actuales sistemas y estructuras de bases de

datos existentes de la CECH.

a ) Recopilacion de documentacion existente de los sistemas.

b) Analisis de logica y funcionamiento.



60

4.4. Resultados Esperados

El producto final esperado, es un “sistema integrador”‘, que permita la in-

teraccion e integracion entre sistemas, de tal forma que estos no tengan que ser

modificados en su estructura ni en su logica, sino que solo se les adiciona un

modulo de integracion con el cual sigan funcionando con total autonomıa y fun-

cionalidad. Este sistema de integracion tendra una interfaz para el usuario final,

con la cual se podran hacer consultas complejas a los distintos motores de bases

de datos y servidores, como si estos fueran uno solo.

Ademas, otro producto esperado, son los dos nuevos sistemas propuestos, estos

son:

- Sistema de administracion de contenidos(SAC): Este sistema permi-

tira la administracion de noticias, recortes de prensa, y documentos

eclesiales, los cuales son suministrados por corresponsales de las distintas

diocesis de Chile y editados por un equipo de comunicaciones de la CECH.

- Directorio Virtual de la iglesia catolica de Chile: Este sistema permi-

tira la administracion de los datos relacionados con las entidades y personas

de la Iglesia Catolica en Chile, en donde contara con perfiles de usuarios, con

distintos contenidos del directorio, administrados remotamente vıa Web.



61

4.5. Alcances y Limitaciones

El proyecto de integracion de sistemas cuenta con el respaldo del portal igle-

sia.cl, la Conferencia Episcopal de Chile con sus departamentos de estadısticas

para la pastoral y el area de comunicaciones. Para la realizacion del mismo, las

entidades relacionadas han presentado un proyecto para conseguir financiamiento

para el desarrollo y el mantenimiento de este.

Dentro de las limitaciones a nivel tecnico, se puede mencionar la escasa do-

cumentacion existente sobre bases de datos federadas, interoperabilidad, webser-

vices, y arquitecturas orientadas a servicios, situacion que dificulto el proceso de

recopilacion de informacion en el comienzo del proyecto. Tambien cabe mencionar

que dicha informacion fue obtenida finalmente de investigaciones realizadas en

universidades, las que en la fecha de comienzo del proyecto, se encontraban en

panales y que fueron robusteciendose a traves del tiempo.

El proyecto pretende ser fuente de motivacion en la implementacion de tecno-

logıas de ultima generacion dentro de la institucion, lo que conlleva a la publica-

cion de las recomendaciones para la creacion de sistemas informaticos dentro de

la CECH, siendo este ultimo un gran desafıo como futuro titulado de ingenierıa

en informatica.

Los modulos de interoperabilidad y los Webservices que se implementaran,

estaran bajo el lenguaje de programacion PHP (Pre-Procesador de Hipertexto),

servidor de bases de datos MySql, la clase NuSoap, que permite el trabajo con

el protocolo SOAP (Simple Objeto Access Protocolo) y XML (eXensible Markup

Languaje) como formato estandar de paso de mensajes entre los sistemas, todoscon licencia GNU1 disponibles para distintas plataformas.

1GNU: Conjunto de programas desarrollados p or miembros de la Free Software Founda-tion (Fundacion por el Software Libre); son de uso gratuito. Estos programas se conocen comofreeware.



Capıtulo 5

El SISTEMA

La construccion del sistema contempla la utilizacion de tecnicas de ingenierıa

de software, seguridad informatica, comunicacion de computadores, integracion de

sistemas, etc. y las tecnologıas a utilizar son XML, Webservices, SOAP, Lenguaje

PHP, SQL y SOAP. La union de estas tecnicas y tecnologıas haran posible el

modelado e implementacion de la integracion de los sistemas.

Para la implementacion cuenta con todo el conocimiento y acceso total a los

sistemas ya existentes, ademas la solucion final sera probada directamente por

los administradores de cada sistema participe de la integracion, para ası lograr el

producto esperado por cada uno de ellos.

5.1. Analisis de Recursos

Para la implementacion del sistema integrador, se dispone de los recursos de la

Conferencia Episcopal de Chile. Los recursos disponibles para la implementaci on

son los siguientes:

5.1.1. Recursos de Hardware

El principal recurso necesitado es el acceso a Internet, el cual esta siendo en-

tregado por el centro de computo de la Pontifıcia Universidad Catolica de Chile,

quien dispone de un ancho de banda de 100 Megas nacional y 25 Megas interna-

cional, la cual esta protegida por un Firewall1 fısico, y un IDS2. Los servidores

disponibles para el proyecto son:

1Firewall (Cortafuegos): Es un computador o un programa que conecta una red a Internetpero impide el acceso no autorizado desde Internet. Mecanismo que permite que las comunica-ciones entre una red local e Internet se realicen conforme a las polıticas de seguridad de quienlos instala.

2IDS: Sistema de Deteccion de Intrusos. Busca detectar anomalıas que inician un riesgopotencial y ademas puede tomar medidas protectoras.

62



63

- Servidor Iglesia.cl: MAC XServe G5, Sistema Operativo Mac OX Server

10.3.9, con 1GB en RAM y dos discos duros de 80 MB. El equipo ha sido confi-

gurado con PHP, y no se ha configurado MySQL para no ralentizar los procesos

internos del servidor. Se cuenta con acceso SSH y FTP.

- Servidor Jesus.cl: Powermac G4, Sistema Operativo Mac OX Server 10.3.9,

con 512MB en RAM, disco duro de 60GB. El equipo ha sido configurado con PHPy Mysql SQL. Este servidor tambien es utilizado por el servidor iglesia.cl como

administrador de bases de datos. Se cuenta con acceso SSH y FTP.

- Servidor Estadisticas.iglesia.cl (Servidor Emmanuel): Sistema Linux

Mandrake, 512MB en RAM, disco duro de 36GB. El equipo ha sido configurado

con PHP y Mysql SQL. Se cuenta con acceso SSH y FTP.

- Servidor Marıa.cl: Powermac G4, Sistema Operativo Mac OX Server

10.4.8, con 512MB en RAM y disco de 80GB. El equipo ha sido configurado

con PHP y Mysql SQL para pruebas locales y pruebas de rendimiento. Se cuenta

con acceso SSH y FTP.

5.1.2. Recursos de Software

A nivel de software se ha decidido trabajar con el lenguaje PHP y el servidor

de bases de datos MySql, todo ello bajo las plataformas Unix (sistemas Mac Os

X), y Linux (servidor con Mandrake). A continuaci on de describen brevemente

las caracterısticas de PHP y MySql.

5.1.2.1. PHP (PHP: Pre-procesador de Hipertexto)

PHP es un lenguaje de scripting3 embebido4 en HTML (Mas informacion

http://es.php.net/manual/es/). Gran cantidad de su sintaxis ha sido tomada de

C, Java y Perl con un par de caracterısticas adicionales unicas y especıficas de

PHP. El proposito del lenguaje es permitir que los desarrolladores Web escriban

paginas generadas dinamicamente con rapidez.

Para el proyecto se ha optado por la utilizacion de PHP, pensando en la faci-

lidad de comprender y modificar el codigo por parte de los disenadores y demas

encargados (usuarios finales) del sitio, todo ello gracias a su caracterıstica de scriptembebido. Tambien se puede comentar que gran parte de los sistemas de la Iglesia

Catolica han sido construidos en este lenguaje, sobre todo los sistemas que ser an

integrados.

3Scripting: Lenguaje interpretado (o lenguajes de script) forma parte de los lenguajes deprogramacion, que incluye a aquellos lenguajes cuyos programas son habitualmente ejecutadosen un interprete en vez de compilados.

4Embebido: Quiere decir que forma parte esencial del mismo sistema. El software embebidoes conocido en ingles como firmware o embedded software.



64

5.1.2.2. Motor de Bases de Datos MySql

MySql5 es un motor de bases de datos multiusuario y multihilos, que se distri-

buye bajo la licencia GNU GPL6. Entre las bondades de MySql se puede encontrar

la rapida respuesta que ofrece frente a consultas simples (situacion recurrente en

las paginas y servicios Web), y aunque no se comporta de igual forma en consultas

complejas, este motor de bases de datos es uno de los mas utilizados. Otra carac-terıstica que lo hace tan utilizado, es su simplicidad de instalacion, su estabilidad

en las diferentes plataformas compatibles y la disponibilidad de APIs disponibles,

entre las que se puede mencionar APIs para C, C++, Eiffel, Java, Perl, PHP,

Python, Ruby, y Tcl.

En este proyecto se ha optado por utilizar MySql por sus bondades ya presen-

tadas, ademas los sistemas a integrar estan creados en base a MySql, y son estas

las que se utilizaran en la interoperabilidad.

5Mas informacion disponible en http://dev.mysql.com/doc/refman/5.0/es/index.html6GNU GPL (General Public License o licencia publica general): Tiene como proposito decla-

rar que el software cubierto por esta licencia es software libre, y es protegido contra intentos deapropiacion que restrinjan esas libertades a los usuarios.



65

Figura 5.1: Esquema de Arquitectura por Capas

5.2. Diseno de la Arquitectura

El diseno de la arquitectura de integracion se basa en un conjunto de capas,

las que van estructurando la integracion final. Estas capas distribuidas segun

la figura 5.1, Se aprecia un nivel 0 o esquemas nativos de datos el cual contiene

todos los esquemas y modelos de datos de las distintas tablas de los sistemas, estas

tablas son recuperadas de la documentacion de los sistemas o realizando ingenierıa

inversa al conjunto de tablas existentes para obtener el modelo de datos gr afico. En

el nivel 1 s tiene la aplicacion de las polıticas de seguridad y restricciones de acceso,

las cuales estan basadas en las buenas practicas adquiridas y recomendaciones

especıficas para el lenguaje PHP, ademas de las restricciones de acceso dadas

para los perfiles de clientes especıficos de la integracion. El nivel 2 muestra los

esquemas XML definidos y todo lo relacionado con el transporte de datos entre los

Webservices. En el nivel 3 se tienen las estructuras todos los datos para integrar,

aquı tambien se muestra un esquema bloom99 . El nivel 4 de integracion, se tienen

las p´ aginas de muestras finales para los usuarios o vistas de usuario; en esta capa

se muestran todas las paginas que consumen los recursos de los servicios Web, y

que ademas estan dispuestas de tal forma que pueda obtenerse el mayor beneficio

a la informacion obtenida de la integracion.

5.2.1. Esquema de Servidores

A nivel de servidores, se cuenta inicialmente con tres servidores heterogeneos

y ubicados en distintos lugares fısicos, dotados de un buen enlace de banda ancha

entre ellos para asegurar la continua conectividad. En cada servidor se aloja un

sistema diferente, y cada uno de ellos con su respectivo modulo de integracion ba-

sado en la aplicacion de un Servicio Web especıfico. Cada modulo de integracionpuede ser consumido desde Internet por cualquier usuario autorizado utilizando



66

Figura 5.2: Esquema Comunicacion Entre Servidores

a SOAP como protocolo de paso de datos. El paso de mensajes entre Servicios

Web se realiza por medio de XML. Los Servicios Web cuentan con la posibilidad

de comunicarse y obtener recursos de los sistemas que componen la integraci on.

Existe un Portal Web (Iglesia.cl) quien obtiene y combina adecuadamente la in-

formacion de los distintos sistemas integrados, para lograr un portal mas nutrido

y con informacion mucho mas completa y actualizada. El servidor que contiene

el portal Web, es el principal cliente de la integracion, pero los recursos estan

pensados para que nuevos clientes puedan obtener los recursos ofrecidos por la

CECH.

5.2.2. Paso de mensajes Cliente Proveedor

El paso de mensajes entre los clientes y los proveedores se puede ver en la

figura 5.3, en donde se aprecia el interactuar de los modulos de integracion, la

interfaz cliente y su respectivo sistema nativo.

La interfaz cliente realiza una peticion al modulo integrador que se encuentra

en el lado del cliente, el que sabe donde se encuentran los recursos disponibles,

y con ellos tiene asociado cada servidor de recursos por medio de su URL. Al

realizar la peticion el modulo integracion, se esta comunicando con otro modulo

integrador que se encuentra en el lado de proveedor, quien recibe el mensajeen formato SOAP-XML, analizandolo y verificando autenticidad y en el caso de



67

Figura 5.3: Paso de mensajes entre clientes y proveedores

servidores restringidos verificando las polıticas de seguridad asociadas, el que se

comunica con la estructura del proceso de negocio y ejecuta las acciones pedidas

por el cliente. Una vez que se ha completado el proceso, este devuelve un mensaje

al cliente en SOAP-XML para que sea paseado por el cliente quien entrega a la

interfaz cliente los datos en forma de array de datos, para que este procese y

muestre los resultados en un formato adecuado.

Otra funcion importante del proceso es la parcelacion de las listas de datos

entregadas, ya que por medio de un parametro de registro inicial pedido y la

cantidad de registros a utilizar, se optimiza la transferencia de datos.



68

5.2.3. Aplicacion de Bloom99

Para esquematizar las capas se ha utilizado el modelo Bloom99 (ver figura

5.4), modelo que muestra en forma sencilla los distintos modelos resultantes del

proceso de integracion. En el nivel mas bajo se tienen los esquemas nativos (ver

figuras 3.2, 3.4, 3.7, 3.8); luego, subiendo en el esquema de integracion se tienen los

esquemas componentes, los cuales son modificaciones de cada uno de los modelosde datos nativos, pero se ha restringido el acceso a los datos privados, es decir, en

el esquema de componentes se tienen los datos a compartir. En el nivel superior se

ubica el esquema de exportaci´ on ; dicho esquema permite establecer una dinamica

de acceso a los datos (en las bases de datos federadas se hablarıa de un esquema

para las consultas SQL, pero en este proyecto no se necesita de el). Despues de

haber restringido los modelos de datos, se encuentra con el esquema federado

(modelo de datos integrado), y se muestra a todas las bases de datos como si

fueran una sola, estableciendo relaciones entre sus tablas y componentes. Sobre el

esquema federado se encuentra el esquema de autorizaci´ on el cual cumple la tarea

de restringir los accesos a los datos del esquema federado. Finalmente se tiene el

esquema externo, que es el esquema que consulta el usuario y de el se desprenden

las vistas a los datos en el esquema externo de usuario.



69

Figura 5.4: Esquema Bloom99 Para los Sistemas Integrados



70

Figura 5.5: Esquema Interno de un Sistema Integrado

5.3. Implementacion

La implementacion del sistema integrado se realizo en base a modulos cons-

truidos en lenguaje PHP, estos modulos constituyen la base de las comunicaciones

entre los sistemas, estableciendo ası una capa de integracion. Los mensajes de soli-

citud de servicios se enviaran en formato XML, para ser procesado por el proveedor

de servicios Web, quien revisa los privilegios del cliente y segun los parametros

enviados establece a que servidor debe recurrir para obtener los servicios. El pro-

cesamiento del mensaje recibido en XML se realiza por la clase NuSoap Ampliada,

la que actualmente es un estandar para servicios Web, y ha sido modificada para

simplificar la parametrizacion en los nuevos proyectos que podrıan ser integrados

en el futuro.

5.3.1. Construccion Modulo Integracion

La capa 0 de la figura 5.1 representa a los esquemas nativos (modelos de datos

originales de los proyectos), estos esquemas no requieren ser modificados, pero si

entendidos en cuanto a su logica interna y sus polıticas de integracion, en estenivel es posible que por medidas de seguridad algunos datos deban ser omitidos.

Luego en el Nivel 2 nos se encuentra el transporte en XML, en donde todas tareas

son realizadas por la librerıa NuSoap7 de Dietrich Ayala, esta librerıa ha sido

adaptada y ampliada segun las necesidades especıficas del proyecto. En el 3er

nivel se tiene la estructura de paquetes de datos a compartir, estos paquetes estan

formados en arreglos de datos, que han sido obtenidos de los XML parseados por

la clase NuSoap. Los datos en el 3er nivel pueden ser procesados como informacion

o ser utilizados para realizar vistas de datos en cualquier sistema perteneciente a

7NuSoap: Librerıa GPL para la creacion de Webservices mas informacionhttp://dietrich.ganx4.com/nusoap/



71

Figura 5.6: Esquema SOAP

la integracion. Finalmente se encuentra el nivel 4, que es una capa de presentaci on

de datos, y ha sido implementado un portal Web, que en sı cuenta con acceso a

los recursos de los demas sistemas, el cual es de acceso libre, y se puede acceder a

todos los datos disponibles de los sistemas pertenecientes a la integracion. A nivel

practico, la comunicacion se hara por el protocolo SOAP (Ver Capıtulo 2.3.3),

el cual encapsula la peticion en formato XML desde el cliente, y luego la envıa

a el proveedor quien la recibe, y pasa una primera etapa desencapsulacion y de

analisis de la peticion (ver figura 5.6), se hacen las verificaciones de parametros

y de que tipo de recusos requiere (se realiza la verificacion de disponibilidad del

recurso).

El segundo paso o fase dentro de la verificacion SOAP es la etapa de aplicacion

de las polıticas de seguridad, esto es muy importante, ya que aquı se analiza si

el recurso pedido es de acceso publico o privado (en la mayorıa de los casos es

publico, y para el proyecto se establecio que los datos privados se restringirıan

desde la consulta SQL a la base de datos), otras verificaciones en esta etapa son

las de verificar la autenticidad del cliente, ya que algunas funciones solo pueden ser

solicitadas por clientes conocidos y validamente autenticados. La tercera fase es

la consulta a la base de datos, realizando todas las consultas al sistema correspon-

diente, y finalmente la respuesta es enviada al cliente en forma encapsulada para

su utilizacion. Como se cuenta con distintos servidores que estan relacionados con

los distintos sistemas, la clase nuSoap se ha modificado para resolver la facilidad

de configuracion de los clientes. La solucion para la distribucion de peticiones se

representa en la figura 5.7, en donde el modulo integrador creado, es el encargadode dirigir la peticion al servidor correspondiente. Esta situacion facilita las posi-

bles modificaciones y el crecimiento de la integracion con otros posibles sistemas

que en un futuro cercano quieran ser parte del sistema integrado.

5.3.1.1. Clase NuSoap

En la capa de transporte se trabajo con la ayuda de la Clase NuSOAP (Ver

Capıtulo 2.3.6), la que fue modificada para hacerla mas facil de parametrizar por

los usuarios finales. La principal modificacion realizada a la clase, es para quepueda conocer a cual servidor debe ir a recoger la informacion, de modo que se



72

Figura 5.7: Esquema de peticion de recursos del Cliente a los Proveedores deservicios.

pueda reutilizar el codigo para otros clientes.

5.3.1.2. Parametrizacion de clase

La clase NuSoap fue modificada en beneficio de los futuros usuarios de la inte-

gracion. Se han omitido funciones que para el proyecto no eran necesarias, en don-

de solo confundirıan o provocarıan error por incompatibilidades; los parametros

base de la clase han sido incluidos dentro de un archivo (config.interop.conf.php)

, el cual es editado para apuntar correctamente a los proveedores de servicios.

5.3.1.3. Implementacion de Servidores

Para la implementacion de los servicios Web (servidores de contenido), se

penso en las Arquitecturas Orientadas a Servicios (Ver capıtulo 2.4). Las apli-

caciones estan distribuidas en distintos servidores, en donde su codigo fuente fue

construido de forma simple y clara (Ver Figura 5.9). El codigo fuente que construye

los archivos WSDL automaticamente fue sub-dividido por archivos que constitu-

yen cada uno de ellos una entidad, por ejemplo una parroquia, una zona o un

documento.

El resultado de los servidores de contenido entregan una lista de funciones (Ver

Figura 5.11) que ayudan a los desarrolladores encargados de la implementacion

de futuros webservices clientes.

Los archivos WSDL (Ver Figura 5.10) que sirven a los sistemas UDDI y a los

clientes Webservices estan estructurados en XML.

Los servidores pueden encontrarse en la siguiente estructura:

- Proveedor de Servicios Estadısticas: El Sistema de Directorio

Virtual se encuentra en la URL http://estadisticas.iglesia.cl,

y el proveedor de servicios se ubica en la direccion



73

Figura 5.8: Modificacion clase NuSoap cliente.



74

Figura 5.9: Codigo Fuente Implementacion de Servidor.



75

Figura 5.10: WSDL estadısticas.

http://estadisticas.iglesia.cl/webservices/lista.php?wsdl (Ver Figura

5.10).

- Proveedor de Servicios SAC: El sistema de Administraci´ on de Contenido

(SAC) esta alojado en la direccion http://sac.iglesia.cl; y el archivo WSDL

en la direccion http://sac.iglesia.cl/webservices/lista.php?wsdl.

- Proveedor de Servicios Documental: El nuevo sistema de Ad-

ministracion de Documentos esta alo jado en la direccion

http://www.jesus.cl/webservices.

5.3.1.4. Implementacion de Clientes

Para la implementacion de los clientes se penso en la modularizacion del sitio

o de los sitios clientes, de forma que al agregar el contenido obtenido sea lo m as

facil posible.

Los parametros basicos que se requiere para realizar la peticion de los recursos

a la integracion, son:

$cliente_soap->parametros("id",1);

En la lınea 70 de la figura 5.8, se puede ver la instruccion de parametrizacion

de consulta, en donde se realiza el ingreso de un parametro especifico o un arre-

glo de datos, con los que se parametriza la consulta. En este ejemplo basico, se

parametriza el ID de una noticia con el valor 1.

$cliente_soap -> funcion = "fnoticia";



76

Figura 5.11: Funciones estadısticas.

En la lınea 71 de la figura 5.8, se encuentra la llamada a una funcion especıfica,

en este caso se llama a la funcion ”fnoticia”, que entrega la noticia completa, es

decir; tıtulo, fecha, epıgrafe, bajada, cuerpo, autor, etc.

$cliente_soap -> servidor = "iglesiaweb";

En la lınea 72 de la figura 5.8, se asigna el tipo de servidor que contiene el

recurso, en este caso es el servidor de ”iglesiaweb”, que administra la informacion

del sistema SAC (http://sac.iglesia.cl).

5.3.2. Modulo de Integracion y su Implementacion

Para la implementacion de los modulos de integracion a los portales Web clien-

tes y a los sistemas creados en PHP, se debe como primera condici on contar con

el conjunto de archivos que componen a NuSoap (mas informacion 2.3.6), y lue-

go anexar el archivo ”wsclasscliente.php” (ver codigo simplificado de ejemplo en

figura 5.9 ); luego de ello, es necesario incluir los archivos de par ametros ”[enti-

dad].config.interop.php” y el archivo de vista de usuario [entidad].ficha.php ( estos

archivos seran entregados ya parametrizados dependiendo de la peticion al area

informatica de la CECH ).



77

Figura 5.12: Pagina Principal Sistema Integrado

5.3.3. Implementacion de Pagina Central de Datos

La implementacion del sistema integrado da como resultado visible a los usua-

rios un portal Web con la informacion compartida por los sistemas que han sido

participe de la integracion, en donde se puede acceder publicamente al portal

Web en la direccion http : //www.jesus.cl/proyecto sini/, la que finalmente se

encontrara en http://www.iglesia.cl (ver figura 5.12) con todas las funcionalidadesrequeridas.

La pagina inicial del portal, muestra las diferentes opciones con las que cuenta

despues de la integracion, estas son:

- A nivel de Instituciones de la Iglesia: Congregaciones Religiosas Femeni-

nas, Congregaciones Religiosas Masculinas, Institutos Seculares, Seminarios,

Movimientos, Casas de Retiro, Colegios, Catolicos, Educacion Superior.

- A nivel de la Conferencia Episcopal de Chile: Vicarıas, Zonas, Decana-tos, Parroquias, Capillas, Santuarios, Comunidades de Base.



78

- A Nivel de Contenidos: Documentos, Recortes de Prensa, Noticias, Foto-

grafıas.

Todos estos contenidos vienen de diferentes servidores como lo muestra la

figura 5.2, aquı visualizamos la distribucion de los distintos sistemas y como estos

interactuan y tambien concentran la informacion de cada uno de ellos en un solo

punto.

5.3.4. Paginas de Resultado

Uno de los grandes requerimientos del proyecto, es contar con toda la infor-

macion disponible en los distintos sistemas, en una misma pagina, para que los

usuarios finales puedan contar con toda la potencialidad de los sistemas que han

sido integrados, esto se ha logrado con una interfaz simple (Ver capıtulo 5.13), que

permite a los usuarios ver el conjunto de datos obtenidos basando en un patronentregado .



79

Figura 5.13: Interfaz Portal Iglesia.cl (Resultado de la consulta integrada)



Conclusiones

Segun lo expuesto, se concluye en este trabajo que:

1. De la revision bibliografica se destaca la dificultad de acceso a las tematicas

de integracion de sistemas e interoperabilidad, ya que estas se encuentra

aun en fase de investigacion a nivel de doctorados, lo que tambien se tradu-

ce en una continua evolucion del tema, lo que para el proyecto resulto mascomplicado, ya que la base del proyecto y las teorıas que en el comienzo

del desarrollo del proyecto se daban como fundamento, al terminar el pro-

yecto y revisar los nuevos resultados de las investigaciones, se encontr o que

las orientaciones, buenas practicas y la forma de manipular los datos eran

diferentes. Durante el desarrollo del proyecto, y por recomendaciones exter-

nas, se integraron mas conceptos importantes que no habıan sido tomados en

cuenta, como lo es la Arquitectura Orientada a Servicios, la que actualmente

es presentada por las grandes empresas de software como parte fundamental

de sus soluciones comerciales basadas en la integracion. Tambien en la eta-pa de revision bibliografica se recopilo una cantidad importante de libros,

pero al comprobar que mucha de esa documentacion estaba considerable-

mente desactualizada, se recurrio a fuentes de Internet, las cuales han sido

revisadas con mucha cautela, y solo ha sido presentadas y referenciadas las

documentaciones de los autores originales de cada libro, paper, entrevistas

y manuales relacionados con el proyecto.

2. Sobre Los prototipos de comunicaciones entre servidores y clientes webser-

vices desarrollados se concluye que estos dieron buenos resultados en cuan-to a tiempos de respuesta y compatibilidad, en base a estos prototipos se

realizo la demostracion de funcionalidad y seleccion de la tecnologıa a utili-

zar, tambien se demostro que el lenguaje de programacion PHP y el Motor

de bases de datos MySql eran la opcion mas certera.

3. Referente al desarrollo del sistema, se concluye que los sistemas autonomos

existentes, se integraron de la forma esperada en el proyecto, continuando

su trabajo habitual sin ningun inconveniente. La integracion de los modu-

los de integracion incluidos funcionan de forma correcta, sin problemas de

compatibilidad ni de acceso.

80



81

4. La arquitectura para realizar la integracion formalizada en capas, se ajusto

correctamente al implementar la solucion, y ademas permitio la division de

los modulos, simplificando la calendarizacion de actividades y la comuni-

cacion de los avances del proyecto a los coordinadores informaticos de la

CECH.

5. Sobre la implementacion del nuevo sistema de administracion de contenidos

creado para los recursos existentes en iglesia.cl, se concluye que se mejoro la

administracion de los datos, reemplazando el sistema existente, tambien se

rescata que el nuevo sistema de administracion de contenidos, mediante la

ampliacion del modelo de datos, logro contar con mas informacion que la

que originalmente contaba.

6. En cuanto al desarrollo del nuevo sistema de administracion de informa-

cion para la oficina de estadısticas pastorales de la CECH, se construyo de

acuerdo a los requerimientos especificados. La integracion de los datos delsistema se logro de forma correcta, dando beneficios importantes a la oficina

de estadısticas.

7. Al analizar el diseno propuesto, prototipo y la solucion final construida, se

ve que cumplen los requerimientos generales esperados:

a ) Seguridad y disponibilidad: El requerimiento de seguridad apunta a la

confiabilidad general de un sistema, lo que se logro correctamente en

el desarrollo de este proyecto. Al trabajarse con sistemas distribuidos,

se evitan los puntos unicos de falla, lo cual permite incrementar la

confiabilidad y disponibilidad de los contenidos.

b) Mantenibilidad y flexibilidad: El prototipo y la solucion final estan ba-

sados en NuSoap, el cual es un estandar de SOAP para PHP, el cual

actualmente esta ampliamente difundido, ademas esta siendo entregado

con las distribuciones de PHP. Ademas, el codigo fuente ha sido cons-

truido siguiendo las buenas practicas de programacion, logrando ası un

codigo limpio y facilmente administrable por otros desarrolladores.

c) Modularidad y capacidad de evolucion: El diseno propuesto permiteconstruir sistemas como conjuntos distribuidos de objetos. Los modu-

los se forman a partir de agrupamientos de objetos relacionados fun-

cionalmente entre sı.

De igual forma, la solucion final mejora la capacidad de evolucion de

una aplicacion, ya que los objetos que forman cada modulo pueden

ser actualizados con relativa facilidad. Estos tambien pueden ser reem-

plazados por otros modulos que implementen las mismas interfaces e

inclusive, incorporar nuevas interfaces adicionales.



82

d ) Interoperabilidad e integracion: Dos aspectos del diseno propuesto que

permiten compartir recursos y contenidos entre sistemas gracias al uso

de protocolos estandar (SOAP, XML, Webservices, etc.).

e) Mejor rendimiento a menores costos: En principio, el uso de Webser-

vices reduce la cantidad de conexiones necesarias para intercambio de

datos, a diferencia de otras soluciones. Despues de la implementacionde la solucion, se obtuvo un notable aumento de visitas, ya que el portal

que contiene la implementacion final, cuenta con muchos mas recursos

valiosos para los usuarios finales.

8. Finalmente, se concluye que se cumplieron con todos los objetivos presen-

tados, y la solucion implementada cumplio con todas las expectativas de la

contraparte del proyecto y las personales.



Trabajo Futuro

La creciente necesidad de contar con informacion a la mano de los distintos

sistemas, y las constantes contribuciones de los investigadores, los que dıa a dıa

realizan nuevos aportes a los temas de integracion de sistemas e interoperabilidad,

y mas aun a las grandes empresas del software, que han expuesto a la integracion

de sistemas como la gran solucion a la mayorıa de los problemas de compati-

bilidad entre sistemas y conectividad y reutilizacion de sus antiguos, pero aunmuy funcionales sistemas, hacen de esta tecnologıa una fuente inmensa de nuevas

posibilidades y desafıos.

Como trabajo futuro se listan una serie de ıtems con los cuales serıa deseable

contar y se podran desarrollar fuera del alcance del presente trabajo.

1. Implementar una plataforma Web, que permita a las distintas diocesis y

organismos eclesiales administrar datos propios como noticias, documentos,

etc. y que cuenten ademas con la posibilidad de anexarse como servidor de

recursos al conjunto de servidores de servicios existentes de forma automati-

ca, como ası tambien, permita consumir recursos en forma automatica de los

servidores ya existentes, integrandolos de forma transparente a su conjunto

de datos presentados.

2. Obtener estadısticas del rendimiento de la solucion de integracion presentada

versus soluciones comerciales existentes.

3. Implementar un panel de administracion vıa Web, de los parametros inclui-

dos en en el servidor de servicios y en los clientes, de tal forma que se permitaadministrar los modulos que se van integrando o eliminando de la integra-

cion. Tambien se propone que el panel de administracion permita a usuarios

validamente registrados, la creacion de nuevos modulos compatibles con el

sistema actual.

4. Implementar una nueva interfaz grafica al producto final desarrollado en

el presente proyecto, dandole mayor importancia a las tematicas de acce-

sibilidad Web. A su vez, se propone realizar un nuevo diseno generalizado

al portal Web, de forma que los datos actualmente presentados puedan ser

aprovechados de mejor forma.

83



84

5. Difundir la integracion de sistemas entre las entidades eclesiales, como

ası tambien promover los recursos compartidos que se generaron del pre-

sente proyecto.

6. Implementar un modulo de integracion SOAP al software Office eclesial,

el que aun no esta en construccion y no se conto con el acceso al codigo

fuente, ni acceso a la base de datos para obtener los datos y levantarlos

como servidor de servicios Web.

7. Proponer y desarrollar un estandar de integracion continental a Nivel de

la Conferencia Episcopal Latinoamericana (CELAM) a partir del presente

proyecto, con las modificaciones necesarias para obtener la integracion de

las distintas fuentes de informacion de los paıses a nivel de las conferencias

nacionales.

8. Implementar una nueva solucion informatica, para obtener una fuente do-cumental a nivel del CELAM de todos los bautizados catolicos, de forma de

contar con la informacion constantemente actualizada de cada paıs.

9. Implementar un datawarehouse a nivel continental que permita recoger la

historia de la iglesia universal, con estadısticas, registros de sacramentos,

informacion historica de los movimientos entre las diocesis, informacion de

festividades y personas por paıs.



Bibliografıa

[1] Com (2005) comunicaci´ on de la comisi´ on al consejo, al parlamento europeo,

al comite econ omico y social y al comite de las regiones. eeurope 2005: Una

sociedad de la informaci´ on para todos, p.12 , 2005.

[2] Dr. Jorge Ramio Aguirre, Curso de seguridad inform´ atica, disponible en:

http://www.lpsi.eui.upm.es/sinformatica/diapositivas.htm , Universidad Po-litecnica de Madrid.

[3] M. Elena Rodrguez Alberto Abello, Marta Oliva and Felix Saltor, The syntax

of bloom99 schemas, disponible en:

www.udl.es/usuaris/n7807592/papers/lsi-99-34-r.ps.gz .

[4] Barry and Associates, Service-oriented architecture (soa) definition, disponi-

ble en:

http://www.service-architecture.com/web-services/articles/service-

oriented architecture soa definition.html .

[5] Juan Carlos Casamayor, Sistemas de gesti´ on de bases de datos, Escuela Uni-

versitaria de Informatica UPV, disponible en:

http://www.dsic.upv.es/ jcarlos/docente/bda/tema4.pdf.

[6] World Wide Web Consortium, Extensible markup language (xml) 1.0 (fourth

edition), W3C Recommendation 16 August 2006, edited in place 29 Septem-

ber 2006, disponible en:

http://www.w3.org/TR/REC-xml/.

[7] World Wide Web Consortium(W3C), Guıa breve de tecnologıas xml, dispo-

nible en:

http://www.w3c.es/divulgacion/guiasbreves/tecnologiasxml , W3C Recom-

mendation.

[8] editores. 8 de mayo de 2000 D. Box, et al, Simple object access protocol (soap)

1.1, disponible en:

http://www.w3.org/tr/2000/note-soap-20000508/ , World Wide Web Consor-

tium.

85



86

[9] Grupo de Investigacion en Sistemas de Gestion de Bases de Datos Federadas

y Almacenes de Datos, Gesti´ on de bases de datos federadas,5 de junio de

2006, disponible en:

http://lsi.ugr.es/ bdf/ .

[10] Oficina Espanola del W3C, European w3c symposium on egovernment: Aviso

nov 2006, disponible en:

www.w3c.es/noticias/2006/ .

[11] Dr.XML, Porque xml? , Gamarod, Disponible en:

http://www.gamarod.com.ar/articulos/por que xml.asp.

[12] Jose Echague Burgos, Xml (extensible markup language), Harvested, dispo-

nible en:

http://eprints.rclis.org/archive/00000222/01/apuntes xml.PDF.

[13] E. Christensen et al. marzo de 2001, Web services description language (wsdl)1.1, disponible en:

http://www.w3.org/tr/2001/note-wsdl-20010315 , World Wide Web Consor-

tium.

[14] Araque F., Definici´ on del modelo y esquema del almacen de datos en funci´ on

de las caracterısticas temporales de los sistemas operacionales componentes,

Universidad de Jaen.

[15] International Organization for Standardization, International organiza-

tion for standardization, iso 8879: Information processing—text and offi-

ce systems—standard generalized markup language (sgml), ([geneva]: Iso,

1986)., disponible en

http://www.isgmlug.org/sgmlhelp/g-sg.htm .

[16] Pedro A. GRACIA, Construyendo la administraci´ on electr´ onica con software

libre,gnuine una aplicaci´ on libre para la administraci´ on local. 2002, p. 8.,

2002.

[17] IBM, Arquitectura orientada a servicios (soa), disponible en:http://www-306.ibm.com/software/ar/info/topic/openenvironment/soa/ ,

IBM.

[18] Elsa Martınez Usero, Jose Angel; Palacios Ramos, Xml: un medio para

fomentar la interoperabilidad, explotaci´ on y difusion de contenidos en la

administraci´ on electr´ onica , Universidad Carlos III, Universitat Oberta de

Catalunya, disponible en:

http://eprints.rclis.org/archive/00000499/01/musero epalacios xml.pdf,

2003.



87

[19] David Megginson’s, This is the official website for sax, disponible en:

http://www.saxproject.org/ .

[20] MINISTERIO DE ADMINISTRACIONES PUBLICAS, Criterios de seguri-

dad, normalizaci´ on y conservaci´ on , Catalogo general de publicaciones oficia-

les, NIPO 326-04-044-9.

[21] Arturo Dıaz Perez, Arquitectura de bases de datos distribuidas, disponible en

http://www.cs.cinvestav.mx/sc/prof personal/adiaz/disdb/cap 2.html .

[22] Tonahtiu A. Ramirez, Sistemas federados de bases de datos, disponible en:

http://www.tonahtiu.com/notas/bd/bdf.htm .

[23] Larson J.A Sheth, A.P., Federated database systems for managing distributed,

heterogeneous and autonomous databases, acm computing surveys, 22, pp.

183-235., 1990.

[24] IDABC stands for Interoperable Delivery of European eGovernment Services,

European interoperability framework for pan-european egovernment services.

[25] W3C, Guıa breve de servicios web, World Wide Web Consortium, oficina

espanola, disponible en:

http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb.

[26] World Wide Web Consortium (W3C), Document object model (dom), dispo-

nible en:

http://www.w3.org/dom , W3C DOM Working Group.

[27] Carmen Wolff, Implementando un datawarehouse, disponible en:

http://www.inf.udec.cl/ revista/ediciones/edicion5/datawh.pdf , Revista in-

formatica 5 (2000), 3–5.

[28] Weld D Flerescu D Friedman M. Zachary A., Levy A, Adaptive query proces-

sing for internet applications, disponible en:

http://www.ieee.org , IEEE Data Engineerin Bulletin, Junio.



ANEXOS

5.4. Organizacion del Codigo Fuente

5.4.1. Directorio de Servidores

Directorio ./webservices/


config.inc.php Archivo de configuracion, que cuenta con los

parametros base del sistema autonomo local. Por

ejemplo los datos como password de acceso a las

bases de datos.

db.dabits.php Archivo que contiene las clases que permiten la

conectividad a distintos motores de bases de da-

tos. Tambien cuenta con funciones especıficas para

cada sistema.

util.dabits.php Archivo de clases que cuenta con utilidades para

administracion de listas y conversion de formato

de fechas.

server.php Modulo de implementacion de funciones webser-

vices.

server lista.php Este modulo implementa practicamente todo el

servidor, y mediante clases permite construir los

servidores, aquı se listan las funciones que han

sido implementadas.

88



89

Directorio ./webservices/funciones


capillas.php Implementacion de funciones especificas de in-

formacion de capillas.

cargos.php Implementacion de funciones especificas de in-formacion de cargos vs personas.

casas retiros.php Implementacion de funciones especificas de in-

formacion de casas de retiros.

colegio.php Implementacion de funciones especificas de in-

formacion de colegios catolicos.

comunidad base.php Implementacion de funciones especificas de in-

formacion de comunidades de base.

decanato.php Implementacion de funciones especificas de in-

formacion de los decanatos.

diocesis.php Implementacion de funciones especificas de las

diocesis.

educacion superior.php Implementacion de funciones especificas sobre

entidades de educacion superior.

flistar.php funciones para pruebas

institucion.php funciones relacionadas con institucionesmatriz diocesis.php funciones para pruebas para datos de las dioce-

sis.

movimiento.php listas de informacion referente a movimientos

religiosos.

obispos.php funciones relacionadas a la informacion de los

obispos

parroquias.php funciones relacionadas a las parroquias.

persona cargo.php Lista parametrizada para personas con sus car-

gos.

personas.php Listas con la informacion de las personas.

vicaria.php Informacion sobre las vicarıas.

zona.php Informacion de las zonas territoriales.



90

Directorio ./webservices/lib


class.nusoap base.php version del esquema de las cargas y arsenal del

namespace

class.soap fault.php trabaja con los faults a nivel de servidor.class.soap server.php Permite la implementacion de un servidor

SOAPXML

class.soap paser.php Analiza los mensajes de XML SOAP

class.soap transport

http.php

Permite el envıo y recepcion de datos por medio

del protocolo HTTP

class.soap val.php Permite crear abstracciones serializables

class.soapclient.php Es una clase de alto nivel para facil utilizacion

por parte del desarrollador.

class.wsdl.php Analiza los archivos WSDL, y permite acceder

a sus datos.

class.wsdlcache.php archivo para el cache de wsdl

class.xmlschema.php Permite el analisis de los bloques XML

nusoap.php clase que administra la estructura general

nusoapmime.php clase general de administracion de datos por

mime



91

5.4.2. Directorio de Cliente Generico

Directorio ./modulo/


index.php Archivo base que contiene los vınculos y descrip-

cion de los recursos ofrecidos.

config.interop.php Archivo con la configuracion base, parametros y

urls para establecer las conexiones con el servidor

de recursos.

lista.php Lista generica de los recursos disponibles, utiliza

parametros para el acceso a los distintos datos.

lista all.php lista generica que permite el acceso a listas para-

metrizadas.

lista tematica.php lista especial para algunas estructuras de datos

complejas.

resultados all.php entrega el resultado de datos, esquematizandolos

segun el archivo de configuracion establecido para

alguna entidad.

ver ficha.php permite mostrar una ficha de informacion de algu-

na entidad especifica, el cual esta parametrizado

por el formato especifico.

busqueda.php crea una interfaz personalizada para las busquedas

simples y especıficas de cada entidad.



92

Directorio ./modulo/MODULOSOAP


bbcode.php conjunto de funciones que permiten la transforma-

cion desde formato BBCODE a HTML normal.

wsclasscliente.php Clase que permite la administracion personalizadade la librerıa NuSoap. Tambien contiene todas las

especificaciones de los servidores activos.

config.inc.php Archivo de configuracion, que cuenta con los

parametros base del sistema autonomo local. Por

ejemplo los datos como password de acceso a las

bases de datos.

db.dabits.php Archivo que contiene las clases que permiten la

conectividad a distintos motores de bases de da-

tos. Tambien cuenta con funciones especıficas para

cada sistema.

util.dabits.php Archivo de clases que cuenta con utilidades para

administracion de listas y conversion de formato

de fechas.

Directorio ./modulo/MODULOSOAP/mail class


class.phpmailer.php Clase que permite parametrizar el envıo de mails.

class.smtp.php Clase que permite el envıo de mails mediante

SMTP.

class.mail.php Clase general que permite el envıo de mails.



93

Directorio ./modulo/conf


blank.banner.jpg Imagen generica para las entidades que no tie-

nen imagen personalizada.

capilla.config.interop.php Archivo de configuracion para personalizar lainformacion capillas

capilla.pre ficha .inter-

op.php

Vista personalizada de la pre-ficha especifica de

capilla.

capilla.banner.jpg Imagen personalizada de la entidad capilla.



94

5.5. XML (eXtensible Markup Languaje)

5.5.1. ¿Que es XML?

Como lo dice la W3C en sus artıculos “XML es un Lenguaje de Etiquetado

Extensible muy simple, pero estricto que juega un papel fundamental en el inter-cambio de una gran variedad de datos”[7]. Cuando hablamos de XML estamos

frente a un lenguaje similar a HTML, pero su funci on principal es la descripcion

de datos y no su visualizacion como lo hace el lenguaje HTML. La tecnologıa

XML es un estandar que permite la lectura de datos por medio de distintas apli-

caciones, siendo muy versatil en gran variedad de aplicaciones y requerimientos

de usuarios, sobre todo para estructurar, almacenar e intercambiar informacion.

XML fue desarrollado en 1996 por el originalmente llamado “SGML Editorial

Review board”, que luego paso a ser el XML Working Group, formandose bajo

el auspicio de World Wide Web Consortium (W3C). El equipo de trabajo delgrupo de especialistas que lo desarrollaron fue dirigido por Jon Bosak de Sun

Microsystems [6], Pero los inicios de XML vienen de los anos setenta, tiempo

donde en IBM se creo el lenguaje general de marcas (General Markup Language),

el cual buscaba soluciones para almacenar grandes volumenes de informacion de

forma estructurada, el que en 1986 se normalizo bajo la norma ISO (ISO 8879)

formandose el SGML (Standard General Markup Language) [15] logrando con ello

la adaptacion a una gran variedad de problemas que a esa fecha se hacıan difıciles

de resolver.

5.5.2. Funcionalidades de XML

Dentro de los usos de XML se considero que sus procesos fueran identicos a la

hora de enviar, recibir y procesar la informacion; que fuera normalizado y conciso

del punto de vista de los datos a almacenar [12]; se considero tambien, que fuera

extensible y pudiera ser utilizado en todos los campos del conocimiento; ademas

que fuese facil de leer, editar e implementar en los distintos sistemas. Para ello,

XML consta de un conjunto de tecnologıas XML de las que se pueden destacar:

- Lenguaje Extensible de Hojas de Estilo (XSL): Su objetivo principal es

mostrar como deberıa estar estructurado el contenido del documento, como

deberıa ser disenado el contenido de origen y su paginacion en una ventana de

un navegador Web o cualquier otro formato, como por ejemplo un conjunto

de paginas de un catalogo, informe o libro.

- Lenguaje de Rutas XML (XPath): Es un lenguaje para acceder a partes

de un documento XML.

- Lenguaje de Enlace XML (XLink) : Es un lenguaje que permite insertarelementos en documentos XML para crear enlaces entre recursos XML.



95

- Lenguaje de Direccionamiento XML (XPointer ): Es un lenguaje que

permite el acceso a la estructura interna de un documento XML, esto es, a

sus elementos, atributos y contenido.

- Lenguaje de Consulta XML (XQL) : Es un lenguaje que facilita la extrac-

cion de datos desde documentos XML. Ofrece la posibilidad de realizar con-

sultas flexibles para extraer datos de documentos XML en la Web.

5.5.3. Ventajas del XML

El lenguaje XML entrega mucha potencia y flexibilidad a las aplicaciones basa-

das en Internet, proporcionando numerosas ventajas a los programadores y usua-

rios, entre las ventajas mas significativas estan:

- Busquedas con mas significado: Los datos pueden ser etiquetados de forma

exclusiva con XML, lo que significa que se puede especificar mucho mas

sobre las relaciones entre los campos que la componen. Esta amplitud de

datos permite una mejor clasificacion cuando estamos creando o utilizando

la informacion que almacenamos en formato XML.

- Integracion de datos procedentes de fuentes dispares: Antes de XML la

capacidad de busqueda en varias bases de datos no compatibles entre sı, se

hacia casi imposible, pero en XML se hace muy sencillo ya que se pueden

combinar los datos estructurados de distintas fuentes y unido a algun agente

de software se pueden integrar y relacionar con otros sistemas incompati-bles. En XML al tener la capacidad de ampliacion y flexibilidad, se pueden

describir los datos contenidos en la gran mayorıa de aplicaciones existentes.

- Computacion y manipulacion local de los datos: XML permite ser ana-

lizado, editado, y manipulado en forma local, lo que permite que las apli-

caciones clientes realicen los calculos, ademas dan la libertad de presentar

los datos en cualquier formato que el sistema cliente necesite. El Modelo de

Objetos de Documento (DOM) de XML tambien permite manipular datos

con secuencias de comandos u otros lenguajes de programacion, de esta for-ma se pueden hacer los calculos relativos sobre los datos sin la necesidad de

volver al servidor.

- Permite varias vistas de los datos: XML al describir los datos estructura-

dos en forma simple, abierta y extensible, es ideal como complemento para

HTML, el cual se utiliza ampliamente para describir las interfaces de usuario,

es decir, HTML describe el aspecto de los datos y XML describe los propios

datos. Los datos pueden presentarse en forma dinamica y determinada por

la configuracion del cliente, preferencias de usuarios u otros criterios. En



96

tanto CSS8 y XSL9 proporcionan mecanismos declarativos para describir

una vista de datos en particular.

- Actualizaciones granulares: Los datos pueden ser actualizados de forma gra-

nular (en forma separada o por pequenos trozos), por lo que no es necesario

volver a enviar un conjunto de datos estructurados cada vez que cambia

parte de dichos datos, pero en la actualidad en las interfaces Web es necesa-

rio volver a construir toda la pagina por motivos de implementacion de los

navegadores.

5.5.4. Utilizacion de XML mediante APIs

La utilizacion del XML se ha facilitado mediante la utilizacion de APIs10,

que son partes de codigo ya escritas, que implementan las funcionalidades basicas

necesarias, para ası permitir al desarrollador de sistemas concentrarse en funcio-nalidades mas avanzadas. De esta forma el tratamiento de documentos con XML

no parte de cero, sino que ya estan disponibles en una serie de APIs aplicables a

XML.

DOM (Modelo de Objetos del Documento): DOM (Document Object

Model, recomendacion de W3C) [26] proporciona una representacion de un do-

cumento XML en forma de arbol, el que se puede recorrer y transformar. Su

principal inconveniente es que solo se accede a los datos una vez que se han leıdo

todos ellos, y que el arbol es un objeto cargado en memoria, lo que es problematico

para documentos grandes y de estructura compleja.SAX (Simple API for XML): Sax funciona por eventos y metodos asocia-

dos [19]. A medida que el analizador va leyendo el documento XML y encuentra

los componentes (eventos) del documento (elementos, atributos, valores, etc) o

detecta errores, va invocando a las funciones que ha asociado el programador.

Ambas APIs cargan el documento en un formato determinado, por otra par-

te, el paso de documentos XML a HTML (transformacion de etiquetas XML en

etiquetas HTML) se realiza mediante el estandar XSL.

8CSS: Las hojas de estilo en cascada (Cascading Style Sheets) son un lenguaje formal usadopara definir la presentacion de un documento estructurado escrito en HTML o XML (y porextension en XHTML).

9XSL (Extensible Scripting Language): Lenguaje descriptivo para formacion de documentosen XML.

10API, Aplication Programming Interface. Una API proporciona metodos y mecanismos parala manipulacion de datos.



97

5.5.5. XML y la Interoperabilidad

El lenguaje XML es una herramienta muy valiosa a la hora de hablar de

interoperabilidad, ya que como lo senalan los doctores Martınez y Palacios [18]

“XML un medio para fomentar la interoperabilidad, explotacion y difusion de

contenidos en la administracion electronica”, en Espana y en el resto del mundo se

estan analizando los metodos implementados por los administradores de sistemas yse esta promoviendo a XML como la gran solucion para la prestacion de servicios

vıa interoperabilidad. Y para ello se presenta a XML como el estandar idoneo

para la estructuracion de la informacion de caracter publico, aunque tambien se

senala que para que exista una real capacidad de crear sistemas interoperables, es

necesario crear esquemas comunes y publicos.

La utilizacion de XML, se propone para la interoperabilidad entre sistemas,

datos y procesos, donde se muestra como la forma de facilitar el acceso compar-

tido a la informacion, reutilizacion de recursos, la interactividad y ensamblaje de

procesos administrativos centrados en el usuario.

La importancia del tema se pudo ver en el reporte eEurope2005 [1] el cual

proponıa “una sociedad de informacion para todos”, en la que se hace referencia

a la necesidad de hacer publico un marco de interoperabilidad concertado para

facilitar la prestacion de servicios de administracion electronica a las personas y

empresas, en el cual se abordo los contenidos de informacion de los sistemas de

informacion publica de toda la Union Europea.

“La construccion de la administracion electronica necesita elevar el nivel de

estandarizacion de forma que sea mas facil y sencilla la interconexion e interaccion

de los recursos que se implementen” [16] La tendencia actual es la adopcion de

estandares de codigo abierto para la implementacion de servicios, y en el caso de

los lenguajes de marcado, la utilizacion de formatos XML para el intercambio de

informacion se ha mostrado como la mas efectiva y ademas ha sido aceptada por

todo el mercado, pero tambien se debe saber que XML no es una solucion en si

misma, sino que esta directamente relacionado con los esquemas y definiciones,

los cuales se proponen que sean comunes para los sistemas que desean conseguir

la interoperabilidad.

Sobre la necesidad de creacion de estandares, los doctores Martınez y Palacios

[18] proponen que “La falta de estandares mınimos en los servicios de la adminis-

tracion hacen difıcil el uso de estos por parte de los ciudadanos, las empresas y los

propios funcionarios. Actualmente, se considera que con la utilizacion de estanda-

res basados en XML se favorece el intercambio de informacion, sindicacion de

contenidos y el desarrollo de servicios que funcionen en diferentes plataformas.

Todo ello contribuye a la gestion eficiente de todo tipo de recursos, humanos,

tecnicos, informativos y economicos”.



98

5.5.6. Futuro XML

El futuro de XML es bastante alentador, ya que este ofrece muchas ventajas a

las organizaciones, desarrolladores de software, sitios Web y usuarios finales [11],

y cuando los sitios ofrezcan datos, en lugar de solo entregar las vistas a estos, las

oportunidades seran aun mayores.

Se propicia como un mercado vital y aun por descubrir, el de la creacion deherramientas de desarrollo que simplifiquen a los usuarios finales la creacion de

sus propios sitios Web cooperativos, ademas se piensa la masificacion de esquemas

comunes para sistemas y por otro lado el crecimiento de los recursos compartidos

en XML haran de esta la mas poderosa de las herramientas en la integracion

global.

XML va a necesitar herramientas nuevas y mucho mas potentes para la presen-

tacion de datos XML ricos y complejos dentro de un documento, lo que se puede

conseguir creando una capa de presentacion mas facil de usar.

Documents

TESIS, Integración e Interoperabilidad de Sistemas Informáticos (2007)