IEEE LATIN AMERICA TRANSACTIONS, VOL. 6, NO. 6, OCTOBER 2008 535 IWPAAMS2007-08: Multiagent System For Information Integration And Consulting In XML Format R. Berjón, A. Fermoso, E. Beato, M. Mateos, M.A. Sánchez, M.I. Manzano, M.J. Gil Abstract— Nowadays, organizations need to work with large amounts of information from different sources. Therefore it becomes necessary tools and formats such as XML, which serve as integrators to this heterogeneity. This paper describes XDS, a tool designed with agents, which integrates data from multiple sources: relational databases, native XML databases and XML documents, obtaining the results in XML format. Besides its usefulness is demonstrated with a case study applied to the environment of libraries, consisting of bibliographic consults, where the result obtained are formatted in MODS. Keywords— Information heterogeneous data, MODS. Integration, XML, sistema multiagente que se ejecuta en un ambiente colaborativo. Para demostrar la valía de la herramienta se ha aplicado a un caso práctico: se ha utilizado XDS para consultar fuentes de datos con información sobre recursos bibliográficos obtenido el resultado de las consultas en el formato MODS[8]. En los siguientes apartados primero se describirá la herramienta XDS y a continuación su aplicación al caso práctico de integración de información al formato bibliográfico MODS. databases, I. INTRODUCCIÓN H OY en día las organizaciones tienen que trabajar con gran cantidad de información, con formatos dispares y además distribuida en distintas fuentes. Por otro lado se hace necesario intercambiar esta información y/o acceder a los datos que ponen a nuestra disposición otros sistemas. Dada esta situación, resulta imprescindible herramientas y formatos que sirvan como integradores ante esta heterogeneidad de contenidos. Dentro de los formatos, hoy en día XML se considera el estándar para el intercambio y presentación de información. En este trabajo se describe la herramienta software XDS que da solución a la problemática descrita. XDS es un sistema que integra en XML datos procedentes de los tipos de fuentes más habitualmente utilizadas en las organizaciones: bases de datos relacionales, bases de datos nativas XML y documentos XML. Este sistema se presenta, además, como una alternativa a los sistemas tradicionales basados en servidor en los que todo el trabajo se realizaba de forma centralizada. XDS, es un Este trabajo ha sido financiado por la Junta de Castilla y León a través del proyecto de investigación «Estudio sobre integración y acceso único a recursos documentales informatizados» (PON06B06). . R. Berjón, A. Fermoso, E. Beato, M. Mateos y M.A. Sánchez trabajan en la Escuela Universitaria de Informática de la Universidad Pontificia de Salamanca. Compañía 5, 37002, Salamanca. España (e-mail: rberjonga@upsa.es, afermosoga@upsa.es, ebeatogu@upsa.es, mmateossa@upsa.es, masanchezvi@upsa.es). M.I. Manzano trabaja en el servicio de Biblioteca de la Universidad Pontificia de Salamanca. Compañía 5, 37002, Salamanca. España (e-mail: mmanzanoga@upsa.es). M.J. Gil trabaja en E.S.I.D.E. Universidad de Deusto. Avda. de las Universidades 24, 48007 Bilbao. España (e-mail: marijose@eside.deusto.es). II. HERRAMIENTA XDS De los estudios sobre las fuentes heterogéneas de datos realizados en [1] [2] y [3] se puede deducir cuáles son los requisitos necesarios para integrar con XML información procedente de distintas fuentes: a) La información puede proceder simultáneamente de distintas fuentes de información. b) Estas fuentes pueden ser de los siguientes tipos: documentos XML, bases de datos relacionales, bases de datos relacionales habilitadas para XML y bases de datos nativas XML. c) Cada fuente debe ser consultada empleando su propio lenguaje nativo. d) Con el fin de que no sean necesarias posteriores transformaciones XSL, el usuario debe poder especificar cuál es la estructura en que desea obtener el resultado XML. e) Para aquellas fuentes de datos que no sean XML, se tiene que: · soportar vistas NF2 (Non First Normal Form). · facilitar la anidación de la información. · parametrizar las consultas. · especificar cómo se desea transformar a XML la información consultada. f) Las peticiones (o consultas) que los usuarios realicen a la herramienta, a su vez deben ser XML, a fin de poder crearlas o modificarlas empleando métodos estándar. En base a estos requisitos se ha desarrollado la herramienta XDS (eXtensible Data Sources) que soporta los siguientes tipos de fuentes: documentos XML, base de datos Tamino, base de datos Oracle y cualquier otro RDBMS que pueda ser 536 IEEE LATIN AMERICA TRANSACTIONS, VOL. 6, NO. 6, OCTOBER 2008 accesible a través de ODBC. El esquema general se describe en la Figura 1. Figura 1. Esquema de XDS La herramienta es un sistema multiagente, implementado en Jade, que posee dos módulos principales: XDSConnections y XDSQueryParser. El primero (XDSConnections) se encarga de consultar las fuentes de datos empleando el lenguaje nativo propio de cada una. Independientemente de cuál sea el tipo de fuente, el resultado que obtendría de este módulo siempre sería XML. Requiere de un fichero de configuración (connections.xml), que en sí es un documento XML, donde se describe: los parámetros necesarios para acceder a cada fuente de datos (tipo de la fuente, ubicación de la misma, nombre de usuario y contraseña con la que acceder a ella), las consultas nativas que potencialmente emplearán los usuarios para recuperar la información (en las peticiones a la herramienta, el usuario identificará la fuente y la consulta nativa con la que obtener la información), los posibles parámetros que puedan tener dichas consultas, las reglas que permitirán, si así se desea, anidar la información relacional consultada, así como también las que permiten especificar cómo se desea transformar este mismo tipo de información a una representación XML. Este módulo se ejecuta en un ambiente de trabajo colaborativo distribuido: las peticiones que recibe agente manager identifican la fuente y la consulta con la que se desea obtener la información requerida. A través de estos identificadores se localiza el agente de computación vinculado con la fuente de datos. Éstos poseen distintos comportamientos, con una creencia por cada uno de ellos, asociados con cada una de las consultas descritas en connections.xml. Además también poseen distintos componentes que permitirán: fijar el valor de los posibles parámetros definidos en la consulta, realizar la operación de anidamiento si así se especificó en el documento de configuración, así como también realizar la transformación de la información relacional a formato XML. El otro módulo, XDSQueryParser, se construye por medio de un agente que actúa como interface entre el usuario y el resto del sistema multiagente. Es al que los usuarios dirigen sus peticiones, en las que se identifican las fuentes y consultas que debe emplear el sistema para obtener la información, así como la estructura con la que se desea obtener la respuesta. Estas peticiones están expresadas en el lenguaje XDSQuery que también se ha definido. XDSQueryParser interactúa con XDSConnections para obtener, a través de los identificadores de la fuente y la consulta, la información requerida, integrándola posteriormente y generando la respuesta XML que finalmente se le devolverá al usuario. A continuación se analiza con más detalle las características de XDSConnections y XDSQueryParser A. XDSConnections Mediante XDSConnections se accede a las distintas fuentes de datos mediante consultas nativas. La descripción de estas fuentes y consultas se realiza en el fichero connections.xml cuyo esquema se representa en la Figura 2. En dicho documento y por cada fuente de información, se incluye un elemento <connection> que define: por una parte los parámetros necesarios para establecer una conexión a dicha fuente (elementos <property>) y, por otra, las distintas consultas nativas que pueden ser ejecutadas (elementos <query>). Puesto que se puede describir distintas fuentes, a cada una se le asigna un nombre para poder identificarlas (atributo name de cada elemento <conection>). Además y también para cada uno de estos elementos, se especifica, a través de su atributo type, el tipo de la fuente. Los tipos soportados son: file para documentos XML, sql para bases de datos relacionales y aquéllas que también estén habilitadas para XML y finalmente tamino para la base de datos Tamino (de momento es la base de datos nativa XML que está soportada). BERJÓN et al.: IWPAAMS2007-08: MULTIAGENT SYSTEM 537 Figura 2 Esquema de connections.xml Cada elemento <query> también posee atributos name y type que, de forma análoga a los anteriores, describen respectivamente el nombre o identificador de la consulta y el tipo de la misma. El tipo de la consulta describe el lenguaje nativo empleado para consultar la fuente, ya que como se analizó en [1], una misma fuente de datos puede soportar distintos lenguajes de consulta (por ejemplo en Tamino las consultas pueden realizarse a través del lenguaje XQuery y también empleando X-Query que es una versión extendida de XPath). Todo elemento <query> incluye a su vez los siguientes elementos: <statement>, <parameters>, <nesting> y <rowSchema>. En el elemento <statement> se describe la consulta nativa, en <parameters> se incluirá la definición de los posibles parámetros que puedan haber sido incluidos en dicha consulta. Los elementos <nesting> y <rowSchema> describen respectivamente el anidamiento (operador NEST) que puede realizarse sobre datos relacionales, así como la transformación de este tipo de información a XML. Estos dos elementos se analizan a continuación con más detalle. Anidamiento. Según se indica en [4] [5] [6] y [7] «En NF2 las tuplas siguen una estructura jerárquica, lo que resulta útil para representar objetos que por su naturaleza están estructurados jerárquicamente». Teniendo en cuenta esta afirmación, se puede concluir que la mejor alternativa para transformar datos relacionales a XML es que el modelo de éstos sea el relacional anidado NF2 (este modelo permite datos multivaluados y/o compuestos). En XDS hemos incorporado la operación NEST en cualquier consulta que pertenezca a una fuente de datos de tipo SQL. El elemento <query> posee un elemento <nesting> donde, si fuese requerido, se describe el anidamiento. Éste puede incluir tantos niveles como se desee, definiéndolos a través de elementos <nested> anidados. Cada uno define, a través de subelementos <field>, el campo o campos sobre los que se realizará el anidamiento (o agrupamiento). Además, el elemento <nested> define en su atributo name el nombre del nuevo campo compuesto que contendrá como subcampos el resto de los no designados en elementos <field>. Esquemas. Para XDS, la información extraída por XDSConnections de toda fuente de datos es de tipo XML. Por tanto, para aquellas fuentes que no lo sean, será necesario realizar una transformación a este formato. XDS proporciona dos formas diferentes de transformar a XML cada uno de los registros devueltos por una consulta: incluyendo en la misma al menos un XDSSchema que defina, mediante reglas, la estructura que tendrá dicha representación XML, o siguiendo un modelo de transformación canónica (éste es el valor por defecto, no requiere ninguna definición adicional en connections.xml). Para definir un XDSSchema, se añade un elemento <rowSchema> al elemento <rowSchemas> de la consulta (su esquema se muestra en la Figura 3). Los elementos de XDSSchema (<element>, <complexType>, <sequence>, <group>, <attribute>,<attributeGroup>,<extension>,<any>y <simpleContent>) se corresponden con un subconjunto extendido del estándar XMLSchema. 538 IEEE LATIN AMERICA TRANSACTIONS, VOL. 6, NO. 6, OCTOBER 2008 Figura 3 Esquema de XDSSchema Además de los atributos que para estos elementos define XMLSchema, XDSSchema incluye otros nuevos que permiten identificar el origen de la información. Estos atributos son: field, newNF2 y occursField. El atributo field definido en <element>, <attribute> y <any> identifica el campo del registro que contiene la información que finalmente incluirán dichos nodos. Este atributo debe ir complementado con el atributo newNF2 si la información a incluir fuese la de un subcampo de uno compuesto (al estar soportadas las estructuras NF2 este atributo referencia a un campo compuesto que contiene el campo descrito por field). Para transformar un campo multivaluado, en el esquema XDSSchema necesariamente habrá una estructura repetitiva en la que el atributo maxOccurs tome el valor unbounded. En este caso el atributo occursField indica el nombre de dicho campo multivaluado. Por último, el elemento <rowSchemas> puede contener tantos elementos <rowSchema> como diferentes transformaciones se quiera plantear. Cuando en una consulta XDSQuery, el usuario desee procesar el resultado de una consulta SQL, sólo tendrá que indicar el nombre de la transformación a realizar (valor del atributo name del elemento <rowSchema>) y el nombre del elemento que en dicho XDSSchema actuará como root element. B. XDSQueryParser XDSQuery es el lenguaje que se ha diseñado para que los usuarios de XDS consulten las fuentes de datos. Es un subconjunto extendido de XQuery descrito en XML. Su gramática se muestra en la Tabla 1 y su esquema XML en la Figura 4. Permite aprovechar la potencia de las expresiones FLWOR de XQuery para realizar consultas, pero con el valor añadido de que éstas puedan realizarse a fuentes de datos no necesariamente XML. Para especificar en XDSQuery una consulta a una fuente de datos, se utiliza el elemento <datasource>. Sus atributos connection y query identifican respectivamente los nombres de la conexión a la fuente de datos y el de la consulta nativa. Opcionalmente, y sólo en el caso de que la fuente de datos fuese una base de datos relacional, este elemento dispone de los atributos schema y root que indican respectivamente el nombre del XDSSchema y el del elemento que, en dicho XDSSchema, actuará como root element (si se omitiesen estos atributos, la transformación a XML seguiría el modelo canónico). Por otra parte, si la consulta referenciada por <datasource> incluyera parámetros, este elemento contendría un elemento <parameter> por cada uno indicando su valor. Tabla 1. Gramática XDSQuery Query Expr ExprSingle FLWORExpr FORClause ::= ::= ::= ::= ::= Expr ExprSingle("," ExprSingle)* FLWORExpr | IfExpr | Constructor | EnclosedExpr (ForClause | LetClause)+ WhereClause? OrderByClause? "return" Expr "for" "$" VarName PositionalVar? "in" Expr BERJÓN et al.: IWPAAMS2007-08: MULTIAGENT SYSTEM LETClause PositionalVar VarName WhereClause OrderByClause OrderSpecList OrderSpec OrderModifier IfExpr Constructor DirectConstructor DirElemConstructor DirAttributeList DirAttributeValue QuotAttrValueContent AposAttrValueContent QuotAttrContentChar AposAttrContentChar DirElemContent ElementContentChar CommonContent EnclosedExpr ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= 539 ("," "$" VarName PositionalVar? "in" Expr)* "let" "$" VarName ":=" Expr ("," "$" VarName ":=" Expr)* "at" "$" VarName QName "where" XPathExpr "order" "by" OrderSpecList OrderSpec ("," OrderSpec)* XPathExpr ("ascending" | "descending")? ("empty" "greatest" | "empty" "least")? "if" "(" XPathExpr ")" "then" Expr "else" Expr DirectConstructor DirElemConstructor "<" QName DirAttributeList ("/>" | (">" DirElemContent* "</" QName ">") ) (S (QName S? "=" S? DirAttributeValue)? )* (' " ' QuotAttrValueContent* ' " ') | (" ' " AposAttrValueContent* " ' ") QuotAttrContentChar | CommonContent AposAttrContentChar | CommonContent Char - [{}&] Char - [{}&] DirectConstructor | ElementContentChar | CommonContent Char - [{}&] EnclosedExpr "{" XPathExpr "}" Figura 4 Esquema de XDSQuery 540 IEEE LATIN AMERICA TRANSACTIONS, VOL. 6, NO. 6, OCTOBER 2008 <?xml version = '1.0' encoding = 'ISO-8859-1'?> <connections xsi:noNamespaceSchemaLocation="file:///C:/schemas/connection.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <connection name="Oracle" type="sql"> <properties> <property name="url">jdbc:oracle:thin:@localhost:1521:orcl</property> <property name="driver">oracle.jdbc.OracleDriver</property> <property name="user">MODS</property> <property name="password">MODS</property> </properties> <queries> <query name="ResourceByRecordIdentifier"> <statement>SELECT R.RECORD_IDENTIFIER, R.RECORD_CREATION_DATE, R.RECORD_CHANGE_DATE, R.RECORD_CONTENT_SOURCE, R.TITULO, R.LANGUAGE_AUTHORITY, R.LANGUAGE_CODE, R.LANGUAGE_VALUE, R.DATE_ISSUED, R.ABSTRACT, T.NOMBRE TYPE_OF_RESOURCE, G.TEXT GENRE_TEXT, G.CODE GENRE_CODE, G.AUTHORITY GENRE_AUTHORITY FROM RESOURCES R, TYPES_OF_RESOURCES T, GENRE G WHERE T.CODIGO = R.TYPEOFRESOURCE AND G.CODIGO = R.GENRE AND R.RECORD_IDENTIFIER = ? </statement> <parameters> <parameter name="$RECORD_ID" index="1" typeName="VARCHAR" sqlTypeName="VARCHAR2"/> </parameters> <nesting/> <rowSchemas> <rowSchema name="schema0"> <element name="resource"> <complexType> <sequence> <element name="titleInfo" type="titleInfo_TYPE"/> <element name="typeOfResource" field="TYPE_OF_RESOURCE"/> <element name="Genre" type="genre_TYPE"/> <element name="recordInfo" type="recordInfo_TYPE"/> <element name="language" type="language_TYPE"/> <element name="dateIssued" field="DATE_ISSUED"/> </sequence> </complexType> </element> <complexType name="titleInfo_TYPE"> <sequence> <element name="title" field="TITULO"/> </sequence> </complexType> <complexType name="genre_TYPE"> <sequence minOccurs="1" maxOccurs="1"> <element name="text" field="GENRE_TEXT" nillable="false" > <element name="code" minOccurs="0" nillable="false" field="GENRE_CODE" occursField="GENRE_CODE"/> <element name="authority" minOccurs="0" nillable="false" field="GENRE_AUTHORITY" occursField="GENRE_AUTHORITY"/> </sequence> </complexType> <complexType name="recordInfo_TYPE"> <sequence> <element name="recordIdentifier" field="RECORD_IDENTIFIER"/> <element name="recordChangeDate" field="RECORD_CHANGE_DATE"/> <element name="recordCreationDate" field="RECORD_CREATION_DATE"/> <element name="recordContentSource" minOccurs="0" nillable="false" occursField="RECORD_CONTENT_SOURCE" field="RECORD_CONTENT_SOURCE"/> </sequence> </complexType> <complexType name="language_TYPE"> <simpleContent> <extension field="LANGUAGE_VALUE"> <attribute name="authority" use="optional" field="LANGUAGE_AUTHORITY"/> <attribute name="type" use="optional" field="LANGUAGE_CODE"/> </extension> </simpleContent> </complexType> </rowSchema> </rowSchemas> </query> ::: </connections> Figura 5 Detalle parcial del fichero connections.xml III. CASO PRÁCTICO Para verificar la validez de la herramienta, se consultó el catálogo de una biblioteca para generar la descripción de un recurso en formato MODS. Para ello se creó una conexión a la base de datos (fichero connections.xml) que incluyera una serie de consultas SQL que se combinarían finalmente en una consulta XDSQuery con la que se obtendría el resultado final. Puesto que los datos procedían de una base de datos relacional, fue necesario indicar cómo se deseaba realizar la transformación a XML de los datos consultados. Por ello, por cada consulta SQL, se definió un XDSSchema que indicara las reglas a seguir. En la Figura 5 se muestra parte del fichero de configuración connections.xml en el que se describe la conexión a la base de datos así como una de las consultas SQL parciales junto con su XDSSchema correspondiente. Finalmente en la Figura 6 se muestra la consulta XDSQuery que envía el cliente a XDS y el resultado final generado. BERJÓN et al.: IWPAAMS2007-08: MULTIAGENT SYSTEM 541 Figura 6 Consulta XDSQuery y resultado MODS generado . IV. CONCLUSIONES La herramienta XDS que se propone permite, a través de un sistema multiagente colaborativo, obtener datos XML integrando información procedente de diversas fuentes: de tipo XML (documentos XML, bases de datos nativas XML y bases de datos relacionales habilitadas para XML) y/o de RDBMS. La herramienta permite consultar cada fuente empleando su propio lenguaje nativo: esto representa una ventaja notable, ya que se podrá hacer uso de todas las características y 542 IEEE LATIN AMERICA TRANSACTIONS, VOL. 6, NO. 6, OCTOBER 2008 extensiones que proporciona el lenguaje de cada fuente. También ofrece una gran flexibilidad a la hora de transformar los datos relacionales a una representación XML, ya que permite especificar al usuario, mediante XDSSchema, distintas estructuras XML para una misma consulta. Por otra parte, el lenguaje XDSQuery con el que el usuario realiza sus consultas, permite independizar éstas con respecto al tipo o tipos de fuente donde se encuentre la información: se podría migrar los datos entre fuentes, sin tener que modificar dichas consultas. Por último, al estar su sintaxis basada en XQuery, nuestro lenguaje XDSQuery también permite definir la estructura con la que se desea obtener la respuesta XML final, no siendo necesarias posteriores transformaciones XSL. REFERENCIAS [1] [2] [3] [4] [5] [6] [7] [8] R. Berjón, A. Fermoso, M.J. Gil, «Obtención de XML a partir de información residente en bases de datos. XDS, una nueva propuesta». Proc. 2005 Conferencia Ibero-Americana WWW/Internet 2005, pp. 577582. R. Berjón, A. Fermoso, M.J. Gil, «Obtaining database information in XML». Proc. 2005 Internacional Conference e-Society, pp. 656-660. A. Fermoso, R. Berjón, Business information integration from XML and relational databases sources. Adaptative Technologies and Business integration: Social, Managerial and Organizational Dimensions». Idea group reference. Hersey, 2007, pp. 282-307. M.A. Roth, H.F. Korth, A. Silberschatz, «Extended algebra and calculus for nested relational databases». ACM Trans. Database Syst., vol. 4, pp. 389-417 .1988. P.C. Fischer, D. Van Gucht, «Weak multivalued dependencies». Proc. 1984 of the 3rd ACM SIGACT-SIGMOD symposium on Principles of database systems. R. Elmasri, S. Navathe: Fundamentals of database systems. New York. Addison Wesley, 2002. A. Silberschatz, H. Korth, S. Sudarshan, Database System Concepts. New York. McGraw-Hill, 1998 MODS. Metadata Object Description Schema, The Library of Congress, http://www.loc.gov/standards/mods/ (2007) Roberto Berjón se licenció en Informática en la Universidad de Deusto donde también obtuvo el título de doctor. Desde 1994 trabaja como profesor en la Escuela de Informática de la Universidad Pontificia de Salamanca. Tiene varias publicaciones referentes al acceso e integración de datos con XML. Ana Fermoso se licenció en Informática en la Universidad de Deusto donde también obtendría el título de doctora. Desde 1994 trabaja como profesora en la Escuela de Informática de la Universidad Pontificia de Salamanca. Tiene varias publicaciones referentes al acceso e integración de datos con XML. Encarna Beato estudió Ingeniería Informática en la Universidad de Valladolid donde también se doctoró. Desde 1997 trabaja como profesora en la Escuela de Informática de la Universidad Pontificia de Salamanca. Actualmente está investigando en la integración y búsqueda de información dentro del mismo grupo de investigación que el resto de compañeros de este artículo. Montserrat Mateos estudió Ingeniería Informática en la Universidad de Salamanca, donde también se doctoró. Desde el año 2001 trabaja como profesora en la Escuela de Informática de la Universidad Pontificia de Salamanca. Tiene varias publicaciones sobre la búsqueda de información. Miguel Ángel Sánchez estudió Informática e Ingeniería Informática en la Universidad Pontificia de Salamanca. Obtuvo el título de doctor en la misma universidad. Desde 1992 trabaja como profesor en la Universidad Pontificia de Salamanca. Actualmente está investigando en la integración y búsqueda de información dentro del mismo grupo de investigación que el resto de compañeros de este artículo. María Isabel Manzano es estudiante de doctorado en Biblioteconomía y desarrolla su actividad profesional en la Biblioteca de la Universidad Pontificia de Salamanca. María José Gil se licenció en Informática en la Universidad de Deusto donde actualmente es catedrática. Ha dirigido varias tesis vinculadas al ámbito del acceso e integración de datos.