“Me encanta que los planes salgan bien” John “Hannibal” Smith
Me gustaría expresar mi gratitud hacia todas aquellas personas que de alguna manera u otra me han ayudado y han hecho posible la realización de este proyecto. Primero a mis padres, Paco y Paloma, que siempre han estado a mi lado, apoyándome, dándome todo su cariño y riendo conmigo: OS QUIERO MUCHO. Segundo a mis abuelos, Carlos y Pilar, que son los mejores abuelos del mundo y siempre me he sentido muy querido por ellos: GRACIAS POR TODO. Tercero a mi abuela, Felisa, que siempre me recibe con una sonrisa y me da ánimos para luchar y trabajar en todo lo que hago: GRACIAS. A Julio: Cheival, eres el MEJOR AMIGO que he tenido y voy a tener en mi vida y como bien me dijiste una vez: que nunca nos falten nuestros ratos de cachondeo. A toda mi familia por lo maravillosa que es y el cariño que me dan constantemente. A Luis, mi director, por toda su ayuda durante todo el proyecto. Estoy seguro de que me dejo a muchos sin nombrar, pero no me olvido de la persona MÁS ESPECIAL de todas: Fuen. Gracias por estar en mi vida, haces que cada día sea especial y eres LO MEJOR QUE ME HA PASADO EN MI VIDA: ¡GRACIAS!
Fuen, te dedico este proyecto y te doy las gracias por todo lo que me haces sentir, que es maravilloso.
RESUMEN
La tecnología XML está convirtiéndose poco a poco en el método más utilizado por las empresas para el intercambio de datos puesto que centra toda su potencia en estructurar, almacenar y facilitar el intercambio de datos.
El objetivo de este proyecto es permitir a todo usuario de la aplicación organizar la información en una base de datos en la que pueden incluirse fotos, textos y ficheros con información XML.
Una de las ventajas que ofrece esta tecnología es la lectura de datos XML y su presentación y posible modificación. Los datos en formato XML ahorran tiempo de proceso, columnas en la base de datos y, al estar compuestos de etiquetas que describen la información que contienen, permiten estructurar esta información de manera que facilitan su acceso y modificación.
Para realizar todo ello, primero hay que analizar el estado del arte, realizar un estudio sobre la tecnología XML (cuyo verdadero potencial está siendo descubierto por los desarrolladores), y preparar un interfaz de usuario así como un sistema de intercambio de información entre la base de datos y la aplicación principal.
Existirá una base de datos que será la encargada de contener toda la información con la que se va a trabajar. Los datos relacionales serán procesados de la manera tradicional, con sentencias SQL mientras que los datos XML serán gestionados de manera nativa y haciendo uso de órdenes XQuery.
El reto del proyecto consiste en la integración de las dos tecnologías (SQL y XML) ya que, en ocasiones, se deberán mezclar comandos de ambas para obtener los resultados deseados.
La aplicación final permitirá al usuario disponer de la información pedida si saber en qué momento se está accediendo a información XML y cuándo se está accediendo a información de tipo relacional. Además, si se requiere realizar alguna modificación de los datos, el usuario trabajará directamente sobre el documento XML escribiendo la información que desee en la aplicación, que será la encargada de reflejar esos cambios en el fichero XML.
El programa es muy intuitivo y está diseñado para que cualquier usuario que lo utilice no tenga ninguna dificultad ni duda a la hora de desplazarse por los diferentes menús de los que dispone.
ABSTRACT
XML technology is becoming, little by little, the mostly used method for the data exchange because it focuses all its power in structuring, storing and making that exchange be an easy one.
The main target of this project is to allow every user of the application to organise their information in a database in which they can insert photographs, texts and XML files.
One of the advantages that this technology offers is the reading of XML data and its presentation and possible modification. Data in XML format saves processing time, database column creation and, as it is made up of different tags that describe the information, permits the structuring of the information to make it easier to access and modify.
To develop all this, there has to be, previously, a state of the art analysis in terms of XML applications (whose power is starting to be discovered by developers) and prepare a user interface as well as a data exchange mechanism between the database and de main application.
There will be a database that will be in charge of the data storage with which users are going to work with. Relational data will be processed the traditional way, with SQL orders, whilst the XML data will be manipulated in a native form using XQuery orders.
The challenge of this project consists in the integration of these two technologies (SQL and XML) because, sometimes, it will be necessary to merge commands of both techniques to obtain the desired results.
The final application will allow the user to have all the information in hand. He will never know if the application is accessing XML data or relational data. Furthermore, if any modification is to be made, the user ill work directly with de XML document, rewriting all the information he needs in the interface. The application will then be the one who updates the information and reflect the changes in the XML file.
The application is very intuitive and it is designed to be easily used and navigated through.
1. INTRODUCCIÓN ______________________________________________________ 2 1.1 METODOLOGÍA DEL PROYECTO _________________________________________ 3 2. IDENTIFICACIÓN DE NECESIDADES ___________________________________ 8 2.1 DESCRIPCIÓN DEL PROYECTO___________________________________________ 8 2.1.1 INTRODUCCIÓN A XML ______________________________________________________ 8 2.1.2 ESTADO DEL ARTE__________________________________________________________ 41 2.1.3 CONCEPTOS DEL SISTEMA __________________________________________________ 59 2.2 ALCANCE DEL SISTEMA ________________________________________________ 69 2.3 DIAGRAMA DE CONTEXTO ______________________________________________ 71 2.4 DIAGRAMA CONCEPTUAL ______________________________________________ 73 2.5 TIPOLOGÍA DE USUARIOS ______________________________________________ 77 2.6 RESTRICCIONES _______________________________________________________ 80 2.7 ORGANIZACIÓN DE LA EMPRESA _______________________________________ 80 2.8 ANTECEDENTES DEL SISTEMA _________________________________________ 83 2.9 ESTIMACIÓN DE TIEMPOS Y RECURSOS_________________________________ 93 3. ANÁLISIS DE REQUISITOS __________________________________________ 100 3.1 INTRODUCCIÓN _______________________________________________________ 100 3.2 LISTA DE REQUISITOS _________________________________________________ 105 3.3 MODELO DE PROCESOS _______________________________________________ 129 3.3.1 DIAGRAMAS DE CONCEPTO Y CONTEXTUAL ________________________________ 130 3.4 MODELO FÍSICO DEL SISTEMA _________________________________________ 132
3.5 MODELO CONCEPTUAL DE DATOS_____________________________________ 132 4. ESTUDIO DE ARQUITECTURA _______________________________________ 140 4.1 ESPECIFICACIÓN DE LAS ALTERNATIVAS ______________________________ 141 4.2 MATRIZ DE EVALUACIÓN DE ALTERNATIVAS ___________________________ 145 4.2.1 EVALUACIÓN ORGANIZATIVA, OPERATIVA Y TÉCNICA_______________________ 146 4.2.2 EVALUACIÓN ECONÓMICA _________________________________________________ 153 4.3 SELECCIÓN DE UNA ALTERNATIVA ____________________________________ 156 4.4 EVALUACIÓN ECONÓMICA DEL PROYECTO ____________________________ 156 4.4.1 ESTUDIO DE VIABILIDAD ECONÓMICA ______________________________________ 159
5. DISEÑO ____________________________________________________________ 161 5.1 MODELO FÍSICO DE PROCESOS________________________________________ 161 5.2 REVISIÓN DEL MODELO LÓGICO DE DATOS ____________________________ 166 5.3 DISEÑO DE ENTRADAS Y SALIDAS _____________________________________ 182 6. PROGRAMACIÓN ___________________________________________________ 194 6.1 ASPECTOS IMPORTANTES DE LA PROGRAMACIÓN _____________________ 194 7. MANUAL DE USUARIO ______________________________________________ 203 7.1 LOGIN Y AUTENTICACIÓN DE USUARIO ________________________________ 203 7.2 MENÚ PRINCIPAL _____________________________________________________ 204 7.3 AUTOR________________________________________________________________ 205 7.4 MENÚ AVIÓN __________________________________________________________ 206 7.5 ALTA DE AVIÓN _______________________________________________________ 207
7.6 BAJA DE AVIÓN _______________________________________________________ 209 7.7 CONSULTA DE AVIÓN _________________________________________________ 210 7.8 MODIFICACIÓN DE AVIÓN______________________________________________ 212 7.9 MENÚ AEROPUERTO __________________________________________________ 214 7.10 ALTA DE AEROPUERTO ______________________________________________ 216 7.11 BAJA DE AEROPUERTO ______________________________________________ 217 7.12 CONSULTA DE AEROPUERTO ________________________________________ 219 7.13 MODIFICACIÓN DE AEROPUERTO _____________________________________ 221 7.14 MENÚ COMPAÑÍA ____________________________________________________ 223 7.15 ALTA DE COMPAÑÍA _________________________________________________ 225 7.16 BAJA DE COMPAÑÍA _________________________________________________ 226 7.17 CONSULTA DE COMPAÑÍA ____________________________________________ 227 7.18 MODIFICACIÓN DE COMPAÑÍA ________________________________________ 229 8. CONCLUSIONES ____________________________________________________ 232 9. BIBLIOGRAFÍA _____________________________________________________ 236 9.1 LIBROS CONSULTADOS _______________________________________________ 236 9.2 PÁGINAS WEB CONSULTADAS_________________________________________ 236
1.
Introducción
1. INTRODUCCIÓN
Este proyecto está dedicado principalmente a la gestión de datos XML y relacionales. La temática específica del mismo estará dedicada al mundo de la aviación y girará en torno a tres grandes áreas dentro de ella:
- Aviones - Aeropuertos
- Compañías aéreas
La aplicación desarrollada permitirá manejar información mediante la tecnología XML (haciendo uso de métodos especiales) y mediante SQL (para el manejo de datos multimedia como fotos o textos).
Para el desarrollo de este proyecto se utilizará como metodología de trabajo el Análisis Estructurado de Sistemas descrito en el libro “Metodología del Análisis Estructurado de Sistemas” de Jesús Barranco. También se ha utilizado puntualmente “Ingeniería del Software. Un enfoque práctico” de Roger S. Pressman.
En definitiva, según los textos citados en el párrafo anterior, se empleará el siguiente Ciclo de Vida:
1.1 METODOLOGÍA DEL PROYECTO
La metodología de trabajo a emplear en el proyecto será la del Análisis Estructurado de Sistemas. Adicionalmente a las fases incluidas en dicha metodología, se realizan dos actividades complementarias para conocer el Estado del Arte en cuanto al uso de XML, así como para seleccionar el más adecuado para el presente proyecto.
Se hará uso de los diagramas de clases UML y las bases de datos serán diseñadas con la ayuda de los diagramas entidad-relación.
El Ciclo de Vida del Proyecto será el siguiente:
(1): DEFINICIÓN CONCEPTUAL
En esta etapa de la metodología de trabajo, se deben definir los requisitos que desea incluir el Cliente en el sistema informático que se va a desarrollar.
El resultado de esta etapa es el Plan de Proyecto en el que a partir de los requisitos acordados con el Cliente, se define el alcance, planificación, recursos necesarios, organización y coste de los trabajos a realizar en el proyecto y la documentación que hay que realizar del mismo.
(2): ESTADO DEL ARTE
En esta etapa se hará un análisis en profundidad del estado en el que se encuentra el mercado en cuanto a bases de datos con contenido XML y relacional así como el uso que se lleva haciendo y se hace de ese formato de intercambio.
(3): ESPECIFICACIÓN FUNCIONAL
La especificación funcional desarrolla en detalle los requisitos del software a partir de las necesidades y objetivos establecidos por el cliente.
El documento resultante de esta etapa está destinado a definir “qué” hay que hacer y no “cómo” hay que hacerlo.
(4): ANÁLISIS DE REQUISITOS
Se recogen y describen los requisitos del cliente para saber qué pide y qué se va a realizar e incluir en el proyecto.
(5): ESTUDIO DE ARQUITECTURA
En estaparte del ciclo de vida del proyecto se analiza el hardware, software de base (sistemas operativo, gestor de bases de datos, software adicional y otras herramientas) que deben utilizarse como entorno en el que se implantará el sistema desarrollado.
(6) y (7): DISEÑO EXTERNO E INTERNO
En la fase de diseño se determina la arquitectura general del sistema y su comportamiento dinámico, adaptando la especificación realizada en la etapa anterior. En esta fase, se decide qué tecnología se utilizará en el sistema.
(8): PROGRAMACIÓN
Es en esta etapa cuando se implementan los algoritmos necesarios para llevar a cabo la aplicación del proyecto. El lenguaje utilizado debe ser fácil de entender, portable y no depender del sistema operativo que se utilice.
(9): PRUEBAS
Aquí se realizan las pruebas pertinentes para comprobar que la aplicación desarrollada funciona. Las pruebas se dividen en unitarias y de validación.
(10): MANUAL DE USUARIO
Donde se recogen las instrucciones para ejecutar y sacar el máximo partido posible a la aplicación que se ha desarrollado.
La aplicación final, se implanta en la empresa y se hace la puesta a punto para que comience a ser utilizada.
2.
Identificación de
2. IDENTIFICACIÓN DE NECESIDADES
2.1 DESCRIPCIÓN DEL PROYECTO
2.1.1 INTRODUCCIÓN A XML
XML es un meta-lenguaje que permite definir lenguajes de marcado adecuados a usos determinados. El HTML (HyperText Markup Language) se ha convertido en el lenguaje estándar del World Wide Web. En sus casi diez años de andadura se ha confirmado como un estándar aceptado y aprobado por la industria. HTML se puede considerar una aplicación de SGML (Standard Generalised Markup Language). Hay que desterrar ideas del tipo "XML es HTML mejorado" o "XML es HTML ampliable y personalizable".
A continuación se explican, a modo de introducción y para situar de una manera global el marco en el que se centra el proyecto, los fundamentos básicos del XML:
ESTRUCTURA DE UN DOCUMENTO XML
A primera vista, un documento XML puede parecer similar a HTML, hay una diferencia principal. Un documento XML contiene datos que se autodefinen exclusivamente. Un documento HTML contiene datos mal definidos, mezclados con elementos de formato. En XML se separa el contenido de la presentación de forma total.
Una forma de entender rápidamente la estructura de un documento XML, es viendo un pequeño ejemplo:
Este mismo documento puede ser visto de forma gráfica, para comprender mejor la estructura de un documento XML.
DOCUMENTOS XML BIEN-FORMADOS
Existen un número de diferencias entre la sintaxis de HTML y XML. Es útil, para aquellos que saben HTML y quieren usar XML, conocerlas perfectamente, para poder crear documentos XML bien-formados.
Estructura jerárquica de elementos
Los documentos XML deben seguir una estructura estrictamente jerárquica con lo que respecta a las etiquetas que delimitan sus elementos. Una etiqueta debe estar correctamente "incluida" en otra. Además, los elementos con contenido deben estar correctamente "cerrados". En el siguiente ejemplo, la primera línea sería incorrecta en XML, no así la segunda:
<?XML version="1.0"?>
<!DOCTYPE MENSAJE SYSTEM "mensaje.dtd"> <mensaje>
<remite>
<nombre>Alfredo Reino</nombre> <email>[email protected]</email>
</remite> <destinatario> <nombre>Bill Clinton</nombre> <email>[email protected]</email> </destinatario> <asunto>Hola Bill</asunto> <texto>
<parrafo>¿Hola qué tal? Hace <enfasis>mucho</enfasis> que no escribes. A ver si llamas y quedamos para tomar algo.</parrafo> </texto>
</mensaje>
<LI>HTML <B>permite <I>esto</B></I>.
Etiquetas vacías
HTML permite elementos sin contenido. Como se verá más adelante, XML también, pero la etiqueta debe ser de la siguiente forma: <elemento-sin-contenido/>.
Un solo elemento raíz
Los documentos XML sólo permiten un elemento raíz, del que todos los demás sean parte. Es decir, la jerarquía de elementos de un documento XML bien-formado sólo puede tener un elemento inicial.
Valores de atributos
Los valores de atributos en XML, al contrario de HTML, siempre deben estar encerradas en comillas simples ( ' ) o dobles ( " ).
Tipo de letra, espacios en blanco
El XML es sensible al tipo de letra utilizado, es decir, trata las mayúsculas y minúsculas como caracteres diferentes. Si un elemento de XML está definido como "ELEMENTO", no se puede usar "elemento", ni "Elemento", ni "eleMENto" para referirnos a él.
Existe un conjunto de caracteres denominados "espacios en blanco" que los procesadores XML tratan de forma diferente en el marcado XML. Estos caracteres son los "espacios" (Unicode/ASCII 32), tabuladores (Unicode/ASCII 9), retornos de carro (Unicode/ASCII 13) y los saltos de línea (Unicode/ASCII 10).
La especificación XML 1.0 permite el uso de esos "espacios en blanco" para hacer más legible el código, y en general son ignorados por los procesadores XML.
En otros casos, sin embargo, los "espacios en blanco" resultan muy significativos, por ejemplo, para separar las palabras en un texto o separar líneas de párrafos diferentes.
Nombrando cosas
Al utilizar XML, es necesario asignar nombres a las estructuras, tipos de elementos, entidades, elementos particulares, etc. En XML los nombres tienen algunas características en común.
<LI>En XML la <B>estructura <I>es</I> jerárquica</B>.</LI> <LI>Esto es HTML<BR>en el que casi todo está permitido</LI> <LI>En XML, somos<BR/> más restrictivos.</LI>
<A HREF=http://www.disney.com/> <A HREF="http://www.developer.com/">
Un nombre empieza con una letra o uno o más signos de puntuación, y continúa con letras, dígitos, guiones, rayas, dos puntos o puntos, denominados de forma global como caracteres de nombre. Los nombres que empiezan con la cadena "XML", se reservan para la estandarización de ésta o de futuras versiones de esta especificación.
Resumiendo, no se pueden crear nombres que empiecen con la cadena "XML" o cualquier otra variante. Las letras y rayas se pueden usar en cualquier parte del nombre. También se pueden incluir dígitos, guiones y caracteres de punto, pero no
se puede empezar por ninguno de ellos. El resto de caracteres, como algunos símbolos, y espacios en blanco, no se pueden usar.
Marcado y datos
Las construcciones como etiquetas, referencias de entidad y declaraciones se denominan "marcas". Éstas son las partes del documento que el procesador XML espera entender. El resto del documento que se encuentra entre las marcas, son los datos que resultan entendibles por las personas.
Es sencillo reconocer las marcas en un documento XML. Son aquellas porciones que empiezan con "<" y acaban con ">", o bien, en el caso de las referencias de entidad, empiezan por "&" y acaban con ";".
EL PRÓLOGO
Aunque no es obligatorio, los documentos XML pueden empezar con unas líneas que describen la versión de XML, el tipo de documento, etc.
La primera, o "declaración XML", define la versión de XML usada. Hasta ahora sólo hay una, la "1.0" Además, en la "declaración XML" se especifican la codificación del documento, que puede ser, por ejemplo, US-ASCII (7 bits) o UTF-8 (código Unicode del que el ASCII es un subconjunto), UCS-2, EUC-JP, Shift_JIS, Big5, ISO-8859-1 hasta ISO- 8859-7. En general, y para uso con
lenguajes europeos (incluyendo el juego de caracteres especiales del español, se usa UTF-7 o ISO-8859-1.
Además, se puede incluir una declaración de documento autónomo (standalone), que controla qué componentes de la DTD son necesarios para completar el procesamiento del documento.
La segunda, o "declaración de tipo de documento", define qué tipo de documento se está creando para ser procesado correctamente. Es decir, se define la Declaración de Tipo de Documento (DTD – Document Type Definition) valida y define los datos que contiene el documento XML.
En ella se define el tipo de documento y dónde encontrar la información sobre su Definición de Tipo de Documento, mediante un identificador público (PUBLIC) que hace referencia a dicha DTD o mediante un Identificador Universal de Recursos (URI) precedido por la palabra SYSTEM.
ELEMENTOS
Los elementos XML pueden tener contenido (más elementos, caracteres o ambos a la vez), o bien ser elementos vacíos.
<?XML version="1.0" encoding="UTF-7" standalone="yes"?> <!DOCTYPE MENSAJE SYSTEM "mensaje.dtd">
<!DOCTYPE HTML PUBLIC "-/ /W3C/ /DTD HTML 3.2 Final/ /EN"> <!DOCTYPE LABEL SYSTEM "http://www.empresa.com/dtds/label.dtd">
Siempre empieza con una <etiqueta> que puede contener atributos o no, y termina con una </etiqueta> que debe tener el mismo nombre. Al contrario que HTML, en XML siempre se debe "cerrar" un elemento.
Hay que tener en cuenta que el símbolo "<" siempre se interpreta como inicio de una etiqueta XML. Si no es el caso, el documento no estará bien-formado. Para usar ciertos símbolos se usan las entidades predefinidas, que se explicarán más adelante.
Un elemento vacío, es el que no tiene contenido (claro). Al no tener una etiqueta de "cierre" que delimite un contenido, se utiliza la forma <etiqueta/>, que puede contener atributos o no. La sintaxis de HTML permite etiquetas vacías tipo <hr> o <img src="...">. En HTML reformulado para que sea un documento XML bien-formado, se debería usar <hr/> o <img src="..."/>.
ATRIBUTOS
Como se ha mencionado antes, los elementos pueden tener atributos, que son una manera de incorporar características o propiedades a los elementos de un
documento. Por ejemplo, un elemento "chiste" puede tener un atributo "tipo" y un atributo "calidad", con valores "vascos" y "bueno" respectivamente.
En una Definición de Tipo de Documento, se especifican los atributos que puede tener cada tipo de elemento, así como sus valores y tipos de valor posible.
Al igual que en otras cadenas literales de XML, los atributos pueden estar marcados entre comillas verticales ( ' ) o dobles ( " ). Cuando se usa uno para delimitar el valor del atributo, el otro tipo se puede usar dentro.
A veces, un elemento con contenido, puede modelarse como un elemento vacío con atributos. Un concepto se puede representar de muy diversas formas pero, una vez elegida una, es aconsejable fijarla en el DTD y usar siempre la misma consistentemente dentro de un documento XML:
<nombre>Fulano Mengánez</nombre>
<aviso tipo="emergencia" gravedad="mortal">Que no cunda el pánico</aviso> <identificador DNI="23123244"/>
<linea-horizontal/>
<chiste tipo="vascos" calidad="bueno">Esto es un dia que Patxi y Josu van paseando…
</chiste>
<cita texto="'Hola buenos dias', dijo él">
<gato><nombre>Micifú</nombre><raza>Persa</raza></gato> <gato raza="Persa">Micifú</gato>
ENTIDADES PREDEFINIDAS
En XML 1.0, se definen cinco entidades para representar caracteres especiales y que no se interpreten como marcado por el procesador XML. Es decir, que así se puede usar el carácter "<" sin que se interprete como el comienzo de una etiqueta XML, por ejemplo.
SECCIONES CDATA
Existe otra construcción en XML que permite especificar datos, utilizando cualquier carácter, especial o no, sin que se interprete como marcado XML. La razón de esta construcción llamada CDATA (Character Data) es que a veces es necesario para los autores de documentos XML, poder leerlo fácilmente sin tener que descifrar los códigos de entidades, especialmente cuando son muchas.
Como se ha visto, dentro de una sección CDATA se puede poner cualquier cosa, que no será interpretada como algo que no es. Existe una excepción, y es la cadena "]] >" con la que termina el bloque CDATA. Esta cadena no puede utilizarse dentro de una sección CDATA.
COMENTARIOS
A veces es conveniente insertar comentarios en el documento XML, que sean ignorados por el procesado de la información y las reproducciones del documento. Los comentarios tienen el mismo formato que los comentarios de HTML. Es decir, comienzan por la cadena "<!--" y terminan con "-->".
Entidad Caracter & & < < > > ' ' " "
<gato raza="Persa" nombre="Micifú"/>
<parrafo>Lo siguiente es un ejemplo de HTML.</html> <ejemplo>
<HTML>
<HEAD><TITLE>Rock & Roll</TITLE></HEAD> </ejemplo>
<ejemplo> <![CDATA[ <HTML>
<HEAD><TITLE>Rock & Roll</TITLE></HEAD> ]]>
<?XML version="1.0"?>
<!-- Aquí va el tipo de documento --> <!DOCTYPE EJEMPLO [
<!-- Esto es un comentario -->
Se pueden introducir comentarios en cualquier lugar de la instancia o del prólogo, pero nunca dentro de las declaraciones, etiquetas u otros comentarios.
DOCUMENT TYPE DEFINITIONS (DTDs)
Crear una definición del tipo de documento (DTD) es como crear un lenguaje de marcado propio, para una aplicación específica. Por ejemplo, se puede crear un DTD que defina una tarjeta de visita. A partir de ese DTD, se tendría una serie de elementos XML que permitirían definir tarjetas de visita.
La DTD define los tipos de elementos, atributos y entidades permitidas, y puede expresar algunas limitaciones para combinarlos.
Los documentos XML que se ajustan a su DTD, se denominan "válidos". El concepto de "validez" no tiene nada que ver con el de estar "bien-formado". Un documento "bien-formado" simplemente respeta la estructura y sintaxis definidas por la especificación de XML. Un documento "bien-formado" puede además ser "válido" si cumple las reglas de una DTD determinada. También existen documentos XML sin una DTD asociada y, en ese caso, no son "válidos", pero
tampoco "inválidos” sino simplemente "bien-formados”. La DTD puede residir en un fichero externo, y quizá compartido por varios documentos. O bien, puede estar contenida en el propio documento XML, como parte de su declaración de tipo de documento.
La declaración del tipo de documento comienza en la primera línea y termina con "]>". Las declaraciones DTD son las líneas que empiezan con "<!ELEMENT" y se denominan declaraciones de tipo elemento. También se pueden declarar atributos, entidades y anotaciones para una DTD.
En el ejemplo anterior, todas las declaraciones DTD que definen "etiqueta" residen dentro del documento. Sin embargo, la DTD se puede definir parcial o completamente en otro lugar. Por ejemplo:
<!ELEMENTO EJEMPLO (#PCDATA)> <!-- ¡Eso es todo por ahora! -->
]>
<EJEMPLO>texto texto texto bla bla bla <!-- Otro comentario -->
</EJEMPLO>
<!-- Ya acabamos --> <!DOCTYPE etiqueta[
<!ELEMENT nombre (#PCDATA)> <!ELEMENT calle (#PCDATA)> <!ELEMENT ciudad (#PCDATA)> <!ELEMENT pais (#PCDATA)> <!ELEMENT codigo (#PCDATA)> ]>
<etiqueta>
<nombre>Fulano Mengánez</nombre> <calle>c/ Mayor, 27</calle>
<ciudad>Valderredible</ciudad> <pais>España</pais>
<codigo>39343</codigo> </etiqueta>
DECLARACIONES TIPO ELEMENTO
Los elementos son la base de las marcas XML y deben ajustarse a un tipo de documento declarado en una DTD para que el documento XML sea considerado válido.
Las declaraciones de tipo de elemento deben empezar con "<!ELEMENT" seguidas por el identificador genérico del elemento que se declara. A continuación tienen una especificación de contenido.
En un ejemplo de recetas de cocina por ejemplo, el elemento <receta> puede contener dentro elementos <titulo>, <ingredientes> y <procedimiento> que, a su vez, estarán definidos también en la DTD y podrán contener más elementos.
La especificación de contenido puede ser de cuatro tipos:
Empty
Puede no tener contenido. Suele usarse para los atributos.
Any
Puede tener cualquier contenido. No se suele utilizar, ya que es conveniente estructurar adecuadamente los documentos XML.
<?XML version="1.0"?>
<!DOCTYPE coche SYSTEM "http://www.sitio.com/dtd/coche.dtd"> <coche>
<modelo>...</modelo> ...
</coche>
<!ELEMENT receta (titulo, ingredientes, procedimiento)> <receta>
<titulo>...</titulo>
<procedimiento>...</procedimiento> </receta> <receta> <parrafo>Esto es un párrafo</parrafo> <titulo>...</titulo> <ingredientes>...</ingredientes> <procedimiento>...</procedimiento> </receta>
<!ELEMENT salto-de-pagina EMPTY> <!ELEMENT batiburrillo ANY>
Mixed
Puede tener caracteres de tipo datos o una mezcla de caracteres y sub-elementos especificados en la especificación de contenido mixto.
Por ejemplo, el primer elemento definido en el ejemplo (<enfasis>) puede contener datos de carácter (#PCDATA). Y el segundo (<parrafo>) puede contener tanto datos de carácter (#PCDATA) como sub-elementos de tipo <enfasis>.
Element
Sólo puede contener sub-elementos especificados en la especificación de contenido.
Para declarar que un tipo de elemento tenga contenido de elementos se especifica un modelo de contenido en lugar de una especificación de contenido mixto o una de las claves ya descritas.
DECLARACIONES DE LISTA DE ATRIBUTOS
Los atributos permiten añadir información adicional a los elementos de un documento. La principal diferencia entre los elementos y los atributos, es que los atributos no pueden contener sub-atributos. Se usan para añadir información corta, sencilla y desestructurada.
Otra diferencia entre los atributos y los elementos, es que cada uno de los atributos sólo se puede especificar una vez y en cualquier orden.
Las declaraciones de los atributos empiezan con "<!ATTLIST", y a continuación del espacio en blanco viene el identificador del elemento al que se aplica el atributo. Después viene el nombre del atributo, su tipo y su valor por defecto.
A menudo interesa que se pueda omitir un atributo, sin que se adopte automáticamente un valor por defecto. Para esto se usa la condición "#IMPLIED". Por ejemplo, en una supuesta DTD que defina la etiqueta <IMG> de HTML:
Indicadores de frecuencia ? Opcional (0 ó 1 vez)
veces)
+ Necesario y repetible (1 o más veces)
<!ELEMENT aviso (titulo?, (parrafo+, grafico)*)> <mensaje prioridad="urgente">
<de>Alfredo Reino</de> <a>Hans van Parijs</a> <texto idioma="holandés"> Hallo Hans, hoe gaat het? ...
</texto> </mensaje>
<!ELEMENT mensaje (de, a, texto)>
<!ATTLIST mensaje prioridad (normal | urgente) normal> <!ELEMENT texto(#PCDATA)>
<!ATTLIST texto idioma CDATA #REQUIRED> <!ATTLIST IMG URL CDATA #REQUIRED
Es decir, el atributo "URL" es obligatorio, mientras que el "ALT" es opcional (y si se omite, no toma ningún valor por defecto).
TIPOS DE ATRIBUTOS
Los atributos CDATA (character data) son los más sencillos y pueden contener casi cualquier cosa. Los atributos NMTOKEN (name token) son parecidos, pero sólo aceptan los caracteres válidos para nombrar cosas (letras, números, puntos, guiones, subrayados y los dos puntos).
Atributos enumerados y notaciones
Los atributos enumerados son aquellos que sólo pueden contener un valor de entre un número reducido de opciones.
Existe otro tipo de atributo parecido, llamado de notación (NOTATION). Este tipo de atributo permite al autor declarar que su valor se ajusta a una notación declarada.
Para declarar las notaciones, se utiliza "<!NOTATION", con una definición externa de la notación. La definición externa puede ser pública o un identificador del sistema para la documentación de la notación, una especificación formal o un asistente de la aplicación que contenga objetos representados en la notación.
<!NOTATION HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Atributos ID e IDREF
El tipo ID permite que un atributo determinado tenga un nombre único que podrá ser referenciado por un atributo de otro elemento que sea de tipo IDREF.
Por ejemplo, para implementar un sencillo sistema de hipervínculos en un documento:
En este caso, una etiqueta <enlace destino="seccion-3"> haría referencia a un <capitulo referencia="seccion-3">, de forma que el procesador XML lo podría convertir en un hipervínculo u otra cosa.
ALT CDATE #IMPLIED>
<!ATTLIST mensaje fecha CDATA #REQUIRED> <mensaje fecha="15 de Julio de 1999">
<!ATTLIST mensaje fecha NMTOKEN #REQUIRED> <mensaje fecha="15-7-1999">
<!ATTLIST mensaje prioridad (normal | urgente) normal>
<!ATTLIST mensaje fecha NOTATION (ISO-DATE | EUROPEAN-DATE) #REQUIRED>
<!NOTATION HTML SYSTEM "http://www.w3.org/Markup"> <!ELEMENT enlace EMPTY>
<!ATTLIST enlace destino IDREF #REQUIRED> <!ELEMENT capitulo (parrafo)*>
<!ATTLIST capitulo referencia ID #IMPLIED>
XML hace referencia a objetos (ficheros, páginas web, imágenes, cualquier cosa) que no deben ser analizados sintácticamente según las reglas de XML, mediante el uso de entidades. Se declaran en la DTD mediante el uso de "<!ENTITY".
Una entidad puede no ser más que una abreviatura que se utiliza como una forma corta de algunos textos. Al usar una referencia a esta entidad, el analizador sintáctico reemplaza la referencia con su contenido. En otras ocasiones es una referencia a un objeto externo o local.
Las entidades pueden ser:
Entidades generales internas
Son las más sencillas. Son básicamente abreviaturas definidas en la sección de la DTD del documento XML. Son siempre entidades analizadas, es decir, una vez reemplazada la referencia a la entidad por su contenido, pasa a ser parte del documento XML y como tal, es analizada por el procesador XML.
Entidades generales externas analizadas
Las entidades externas obtienen su contenido en cualquier otro sitio del sistema, ya sea otro fichero del disco duro, una página web o un objeto de una base de datos. Se hace referencia al contenido de una entidad así mediante la palabra SYSTEM seguida de un URI (Universal Resource Identifier)
Entidades no analizadas
Evidentemente, si el contenido de la entidad es un fichero MPG o una imagen GIF o un fichero ejecutable EXE, el procesador XML no debería intentar interpretarlo como si fuera texto XML. Este tipo de entidades siempre son generales y externas.
Entidades parámetro internas y externas
Se denominan entidades parámetro a aquellas que sólo pueden usarse en la DTD, y no en el documento XML. Se pueden utilizar para agrupar ciertos elementos del DTD que se repitan mucho. Se diferencian las entidades parámetro de las generales, en que para hacer referencia a ellas, se usa el símbolo "%" en lugar de "&" tanto como para declararlas como para usarlas.
EJEMPLO DE DTD
Un ejemplo de DTD que puede servir para resumir todo lo visto hasta ahora podría ser un DTD que defina un lenguaje de marcado para una base de datos de personas con direcciones e-mail.
El fichero LISTIN.DTD podría ser algo así:
Basándose en este DTD, se podría escribir este primer listín en XML de la siguiente manera:
XML SCHEMAS
Un "schema XML" es algo similar a un DTD, es decir, que define qué elementos puede contener un documento XML, cómo están organizados, qué atributos y de qué tipo pueden tener sus elementos.
...
%elemento-alf; ]>
<!DOCTYPE texto[
<!ENTITY % elemento-alf SYSTEM "alf.ent"> ...
%elemento-alf; ]>
<?XML encoding="UTF-8"?> <!ELEMENT listin (persona)+>
<!ELEMENT persona (nombre, email*, relacion?)> <!ATTLIST persona id ID #REQUIRED>
<!ATTLIST persona sexo (hombre | mujer) #IMPLIED> <!ELEMENT nombre (#PCDATA)>
<!ELEMENT email (#PCDATA)> <!ELEMENT relacion EMPTY>
<!ATTLIST relacion amigo-de IDREFS #IMPLIED enemigo-de IDREFS #IMPLIED>
<!DOCTYPE listin SYSTEM "LISTIN.DTD"> <listin>
<persona sexo="hombre" id="ricky"> <nombre>Ricky Martin</nombre> <email>[email protected]</email> <relacion amigo-de="laetitia">
</persona>
<persona sexo="mujer" id="laetitia"> <nombre>Laetitia Casta</nombre> <email>[email protected]</email> </persona>
</listin>
La ventaja de los schemas con respecto a los DTDs son:
Usan sintaxis de XML, al contrario que los DTDs. Permiten especificar los tipos de datos.
Son extensibles.
Por ejemplo, un schema permite definir el tipo del contenido de un elemento o de un atributo, y especificar si debe ser un número entero, una cadena de texto, una fecha, etc. Los DTDs no permiten hacer estas operaciones.
A continuación se muestra un ejemplo de un documento XML y su schema correspondiente:
Como se podía ver en el documento XML anterior, se hace referencia a un espacio de nombres (namespace) llamado "x-schema:personaSchema.XML". Es decir, se le está diciendo al analizador sintáctico XML (parser) que valide el documento contra el schema "personaSchema.XML".
El primer elemento del schema define dos espacios de nombre. El primero "XML-data" le dice al analizador que esto es un schema y no otro documento XML cualquiera. El segundo "datatypes" permite definir el tipo de elementos y atributos utilizando el prefijo "dt".
Tal como se ha visto, es necesario empezar el schema definiendo los elementos más profundamente anidados dentro de la estructura jerárquica de elementos del documento XML. Es decir, hay que trabajar "de dentro hacia fuera".
El schema sería algo parecido a esto:
<documento XMLns="x-schema:personaSchema.XML"> <persona id="fulano">
<nombre>Fulano Mengánez</nombre> </persona>
<Schema XMLns="urn:schemas-microsoft-com:XML-data" XMLns:dt="urn:schemas-microsoft-com:datatypes">
<AttributeType name='id' dt:type='string' required='yes'/> <ElementType name='nombre' content='textOnly'/> <ElementType name='persona' content='mixed'> <attribute type='id'/>
<element type='nombre'/> </ElementType>
<ElementType name='documento' content='eltOnly'> <element type='persona'/>
</ElementType> </Schema>
ElementType
Define el tipo y contenido de un elemento, incluyendo los sub-elementos que pueda contener.
AttributeType
Asigna un tipo y condiciones a un atributo.
Attribute
Declara que un atributo previamente definido por AttributeType puede aparecer como atributo de un elemento determinado.
Element
Declara que un elemento previamente definido por ElementType puede aparecer como contenido de otro elemento.
Visto de otra manera, las declaraciones de tipo ElementType y AttributeType deben preceder a las declaraciones de contenido element y attribute correspondientes.
EXTENDED STYLE LANGUAGE (XSL)
El XSL es un lenguaje que permite definir una presentación o formato para un documento XML. Un mismo documento XML puede tener varias hojas de estilo XSL que lo muestren en diferentes formatos (HTML, PDF, RTF, VRML, PostScript, sonido, etc.).
La aplicación de una hoja de estilo XSL a un documento XML puede ocurrir tanto en el origen (por ejemplo, un servlet que convierta de XML a HTML para que sea mostrado a un navegador conectado a un servidor de web), o en el mismo navegador (como es el caso del MS IE5, y en breve, Netscape 5).
Básicamente, XSL es un lenguaje que define una transformación entre un documento XML de entrada y otro documento XML de salida.
Una hoja de estilo XSL es una serie de reglas que determinan cómo va a ocurrir la transformación. Cada regla se compone de un patrón (pattern) y una acción o plantilla (template).
De este modo, cada regla afecta a uno o varios elementos del documento XML. El efecto de las reglas es recursivo, para que un elemento situado dentro de otro elemento pueda ser también transformado. La hoja de estilo tiene una regla raíz que, además de ser procesada, llama a las reglas adecuadas para los elementos hijos.
Puede verse un ejemplo de todo esto:
Se quiere convertir este documento XML en HTML bien-formado. La hoja de estilo XSL necesaria sería algo parecido a lo siguiente:
<libro>
<titulo>Un título cualquiera</titulo> <capitulos> <capitulo> <titulo>Capítulo 1</titulo> <parrafo>....</parrafo> <parrafo>....</parrafo> </capitulo> <capitulo> <titulo>Capítulo 2</titulo> ...
</capitulo> </capitulos> </libro> <HTML> <HEAD>
<TITLE>Un título cualquiera</TITLE> </HEAD>
<BODY>
<H1>Un título cualquiera</H1>
XML DOCUMENT OBJECT MODEL Y JAVA
Como ya se ha visto, el empleo de tecnología XML, al ser un estándar internacional y público, no se limita a una plataforma o sistema de desarrollo concreto. Lo mismo se puede usar Perl bajo UNIX para generar documentos XML a partir de una base de datos, como usar Python en Windows NT para servir documentos HTML4 a navegadores web a partir de un documento XML.
Dicho esto, hay que decir que JAVA se posiciona como una opción interesante a la hora de desarrollar aplicaciones usando XML.
Por ejemplo, a partir de fuentes de datos en XML, se puede escribir un servlet que analice sintácticamente el XML y que genere un árbol DOM (Document Object Model). Una vez generado el árbol DOM, se va extrayendo la información que
contiene y se va generando un documento HTML de acuerdo con ciertas reglas de formato, de modo que pueda ser visualizado por un navegador web.
Supóngase que el servlet carga ese fichero XML en un objeto string de Java, que va a ser analizado. Lo primero que habría que hacer es crear un analizador sintáctico XML usando el objeto com.ibm.XML.Parser para ello. El fichero "xslparse.err" será el registro de cualquier error que ocurra mientras se procesa el documento XML, que debe ser convertido a un InputStream.
Public Sub MuestraNodos(ByRef Nodos As MSXML.IXMLDOMNodeList) Dim oNodo As MSXML.IXMLDOMNode
For Each oNodo In Nodos
If oNodo.nodeType = NODE_TEXT Then
Debug.Print oNodo.parentNode.nodeName & "=" & oNodo.nodeValue End If If oNodo.hasChildNodes Then MuestraNodos oNodo.childNodes End If Next oNodo End Sub <?XML version="1.0"?> <documento>
<fecha><dia>1</dia><mes>12</mes><año>1999</año></fecha> </documento>
titulo=Un documento cualquiera dia=1
mes=12 año=1999
Parser parser = new Parser("xslparse.err");
Se le dice al parser que ignore las declaraciones de tipo de documento, los comentarios, etc.
Se analiza el documento y se cierra el InputStream.
Ahora se mete el árbol DOM en el objeto "doc" y se recorre el árbol DOM sacando los datos que contiene.
A continuación se describen los métodos para navegar el DOM (definidos en org.w3c.dom.Node).
LENGUAJE DE ENLACE XML (XLINK)
XLink es una aplicación XML que intenta superar las limitaciones que tienen los enlaces de hipertexto en HTML. Es una especificación que todavía está en desarrollo y que todavía no tiene "rodaje" en el mundo real.
Los enlaces en HTML tienen una serie de limitaciones que los hacen bastante pobres. Por ejemplo, sólo tienen dos extremos, la terminación origen y la destino, y son unidireccionales.
Si se crea un enlace en una página web personal que lleve hasta la página principal de Coca-Cola, se está creando un "vínculo" entre esta página y la de origen. Este vínculo es unidireccional, porque un visitante cualquiera que entre en la página de Coca-Cola, no tiene forma de saber que la página origen (así como otros cientos de miles) enlaza con ella.
El objetivo de XLink es crear enlaces entre recursos, de una forma de la que HTML no es capaz. Por ejemplo, un estudiante podría hacer anotaciones a los apuntes que un profesor tiene disponibles en la red, por el método de insertar un enlace desde los apuntes (a los que no tiene acceso de escritura o modificación) y su propia página de anotaciones y comentarios.
También es posible vincular dos páginas cualesquiera, por ejemplo enlazando el texto de una noticia en un diario on-line, con el texto de la noticia equivalente en el diario competidor.
Existen también los enlaces extendidos que permiten mucho más que eso. Actualmente, la tecnología para poder mantener una base de datos de enlaces mundial, no está desarrollada, pero se puede hacer a nivel local.
Por ejemplo, una empresa quiere comprar ciertos productos de un suministrador. Los trabajadores de la empresa podrán visitar la página web del proveedor y hacer enlaces externos a comentarios sobre las especificaciones de tal producto. Cuando otro compañero de la empresa visite la página, el servidor de enlaces de la empresa le mostrará dicha página junto con los enlaces externos creados y mostrar los comentarios como si fueran parte del documento original.
Ejemplo de código:
ByteArrayInputStream bais = new ByteArrayInputStream(XMLString.getBytes()); parser.setWarningNoXMLDecl(false); parser.setWarningNoDoctypeDecl(false); parser.setKeepComment(false); parser.setProcessNamespace(false); doc = parser.readStream; bais.close();
getDocumentElement() Devuelve el elemento raiz getFirstChild()
Devuelve el nodo que es el primer "hijo" de este nodo. getNextSibling()
Devuelve el nodo que es el siguiente "hermano" de este nodo. getLastChild()
Devuelve el nodo que es el último "hijo" de este nodo. getPreviousSibling()
Devuelve el nodo que es el último "hermano" de este nodo. getAttribute(java.lang.String attrName)
Devuelve un objeto string que representa el valor de un atributo.
2.1.2 ESTADO DEL ARTE
Desde que en Junio de 1996, el W3C (World Wide Web Consortium) lanzó su propuesta de XML como un nuevo estándar para la comunidad Web internacional, este lenguaje se ha asentado definitivamente como nuevo estándar de la industria.
Muchos síntomas lo confirman como por ejemplo la intervención de Bill Gates en el pasado COMDEX de Las Vegas (Noviembre 2000). Bill Gates apostó claramente por XML: “vale que tanto Microsoft como el resto del sector deben apostar por el XML para el futuro”, y es más insistió “ creo que XML como lenguaje
universal para el intercambio de datos es la clave para la interconexión total, gracias al cual los usuarios recibirán información de diferentes fuentes a través del ordenador o el televisor y podrán conectarse mediante un teléfono móvil o un ordenador de bolsillo” y fue más allá en sus predicciones “... de aquí a tres años, todos estaremos usando los servicios de Internet como si nunca hubiésemos hecho otra cosa y XML será uno de los responsables”. Microsoft no ha sido la única compañía; infinidad de consultoras, compañías de las más variopintas actividades, han asumido XML como estrategia clave de sus negocios.
La relativa facilidad con la que se pueden iniciar en el aprendizaje y formación en XML y su sencillez para implantarse son otros motivos de afianzamiento. En este apartado se comentarán la situación actual, la integración en la infraestructura de las tecnologías de la información existentes, su uso y cómo puede reemplazar o convivir con otras tecnologías y aplicaciones ya existentes.
SITUACIÓN ACTUAL
La situación actual del XML es tan fácil que ya han empezado a proliferar los dialectos. La Web de la organización estadounidense OASIS (Organization for the Advancement of Structured Information Standards, www.oasis-open.org) enumera más de 200 variantes del XML, concebidas y diseñadas para una variada gama de usos concretos, desde el sistema de archivos de las instituciones hasta el intercambio de información bancaria, meteorológica, etc. pasando por la
descripción de monumentos turísticos, representación de fórmulas matemáticas, presentaciones multimedia, etc.
Por otraparte la cantidad de tecnologías que han surgido en relación a XML es numerosísima. Existen decenas de especificaciones de lenguajes que se han creado basadas en XML (3DML, DHTML, DOM por ejemplo). La virtud no reside únicamente en las especificaciones de lenguajes, sino en las herramientas desarrolladas para su gestión. Este es el caso de CRM, SCM, ERP, EAI, ... y muchas empresas start-up que están surgiendo y ofreciendo únicamente soluciones para este lenguaje.
Las nuevas propuestas de especificaciones de XML y XHTML como puente a HTML, junto con las consideraciones anteriores vaticinan un futuro prometedor para estas tecnologías.
El estado del arte en XML se podría resumir como un estándar con un gran impacto en la transformación de las organizaciones hacia el comercio electrónico.
¿Por qué usar XML? La respuesta más entusiasta la suelen dar aquellos que señalan que “XML viene a resolver los grandes problemas de la Web”. ¿Cuáles eran los problemas? Internet es una red a la velocidad de la luz que a veces se mueve a la velocidad de una tortuga; y aunque casi todo tipo de información está disponible en línea, puede ser desesperadamente difícil encontrar la pieza que se
necesita (y eso pese a los excelentes buscadores aparecidos últimamente, como, por ejemplo, Google, o metabuscadores como Copernic).
Ambos problemas surgen como consecuencia de la naturaleza del principal lenguaje de la red HTML (aunque Java ha solucionado gran cantidad de esas deficiencias). El uso de XML está poco a poco ayudando a resolver esos problemas y otros no asociados con la velocidad de las redes, que constituyen otros problemas.
Existe una gran cantidad de retos centrados alrededor de XML y de su uso. El principal puede ser ayudar a resolver las necesidades diarias de las personas en una organización. Tecnológicamente hablando, las aplicaciones en torno al e-business, la gestión documental, gestión de aplicaciones heredadas, etc.
Para saber cómo la industria está comenzando a aceptar XML como estándar para comunicación e integración de datos, la pregunta que cabe hacerse es: ¿Cuáles son los beneficios para el mundo real de XML? XML es una herramienta poderosa para almacenamiento y recuperación de información estructurada rica en contenidos en la Web.
Las bases de datos relacionales y orientadas a objetos se están utilizando para soportar la entrega de datos en la Web y a través de WML basado en XML se esta permitiendo la entrega de contenidos a teléfonos móviles y otros dispositivos inalámbricos. XML juega unos de los roles más importantes que hoy se requieren en el desarrollo para la Web: integrador de aplicaciones.
La combinación de XML y las bases de datos permite la gestión y entrega de información adecuada dinámicamente al usuario según los perfiles de su aplicación. Aunque XML tiene sus orígenes como un estándar para describir documentos, se ha adaptado fácilmente para aplicaciones de mensajería y puede influenciar considerablemente el área de mensajería. Al ser un estándar de datos independiente de la plataforma permite a las organizaciones comunicar sus diferentes sistemas de software.
Otro campo vital donde XML tendrá una gran influencia es en la construcción de portales, por lo que está emergiendo como el lenguaje ideal para transacciones críticas de negocios. Antes de XML el flujo de información entre empresas con sistemas de software dispares era controlado por los estándares EDI.
La estructura de estas transacciones estaba definida rígidamente en los protocolos, de modo que las transacciones sencillas se convertían en complejas y caras. Por otra parte, las implementaciones EDI eran propietarias y caras de desplegar y mantener, de modo que sólo atraían a las grandes corporaciones y crearon una carga para sus proveedores. XML está ayudando y reemplazando estos proyectos.
INTEGRACIÓN DE XML EN LA INFRAESTRUCTURA DE TECNOLOGÍAS DE LA INFORMACIÓNI EXISTENTE EN LAS ORGANIZACIONES
Las actuales organizaciones se enfrentan a dos retos fundamentales: - Afrontar el comercio electrónico
- Integración de aplicaciones empresariales nuevas (para la Web) y heredadas (legacy).
El primer reto supone considerar, entre otras, la gestión de la cadena de suministros como vital en la lista de prioridades corporativas. Las viejas prácticas de negocios tales como los pedidos “a mano”, seguimiento telefónico del pedido y del cliente, inventarios enormes, etc. son ineficientes y caros de mantener en el mercado competitivo actual.
Existe un problema y es la “no estandarización de servidores”; por ejemplo, la empresa está estandarizada con servidores Unix, pero sus proveedores son Windows NT o 2000. No existían estándares para intercambio de datos y la mayoría de las soluciones que se han considerado han pasado por la compra de nuevos sistemas que en realidad, y con frecuencia, están orientados a lotes (batch) y carecen de la interactividad directa que se requiere.
El mundo del tiempo real requiere colaboración distribuida. Un sistema puede invocar directamente otra aplicación con una llamada a un procedimiento remoto (RPC, remote procedure call) o dos sistemas pueden colaborar intercambiando
datos a través de mecanismos de brokering que se suelen conocer como MOM (message-oriented middleware).
Los mecanismos RPC incluyen soluciones de gran escala como DCE (Distributed Computing Environment). Luego aparecieron arquitecturas RPC orientadas a objetos tales como DCOM, CORBA o las API de RMI (Remote Method Invocation) de Java.
Otro gran reto de estas tecnologías, son los cortafuegos (firewalls) y los servidores proxy. HTTP se ha convertido rápidamente en la lengua franca de Internet y naturalmente es un candidato natural a servir como un protocolo de transporte RPC, sobre todo desde que coexiste con medidas de seguridad y no es dependiente de ninguna plataforma o implementación de procesador.
Se necesita un puente entre ambos estándares (XML y HTTP). Así ha surgido SOAP que ya está adoptado por otros grandes como IBM y está realizando esta tarea.
SOAP (Simple Object Access Protocol) es un lenguaje de implementación XML con un esquema específico. SOAP utiliza este estándar para permitir el acceso a objetos distribuidos a través de Internet así como a través de diferentes modelos de objetos. Puede servir como una nueva solución de interoperabilidad entre
tecnologías middleware incompatibles tales como COM y CORBA. SOAP es un protocolo de Internet que se encarga de la ejecución de objetos remotos.
El punto fuerte de SOAP es tal vez que toda su mecánica es capaz de integrarse con el popular protocolo HTTP de Internet. Así los modelos de aplicaciones I*Net (Internet/Intranet/Extranet) son su cliente natural y se puede convertir SOAP en el puente, por excelencia, hacia las tecnologías orientadas a objetos como son COM+ de Microsoft y CORBA como estándar universal.
El otro gran reto al que se enfrentan las organizaciones es la necesidad de la integración de aplicaciones empresariales (EAI, Enterprise Appplication Integration). Con mucha frecuencia, equipos de programadores escriben millares de líneas de código para hacer la integración dinámica o interactiva. Por suerte, en estos últimos años han surgido una serie de tecnologías adaptadas para EAI: orientación a objetos, servidores de aplicaciones y recientemente LDAP (Lightweight Directory Access Protocol) y el lenguaje XML. Así se está consiguiendo resolver problemas tan importantes como la estandarización en el intercambio de datos, verificación de la seguridad y compartición del código de aplicaciones.
ADMINISTRACION DEL ALMACENAMIENTO DE DATOS XML
Demandas de Almacenamiento XML
XML se está convirtiendo en el formato de datos de elección para una amplia variedad de soluciones de sistemas de información. Aplicaciones comunes que usan XML incluyen: transmisión de documentos en sistemas B2B, construcción de formatos de mensajes para integración de aplicaciones Internet con sistemas legados, asociación de datos XML con controles visuales y no visuales, almacenamiento y obtención de datos, y varias actividades de manipulación de datos dentro de aplicaciones.
Los beneficios que a menudo se asocian con la utilización de XML incluyen independencia de la plataforma, bajo coste de entrada, y la habilidad de compartir datos de manera transparente. XML puede además acomodar una variedad de datos incluyendo texto, imágenes y sonido.
Sin embargo, XML no viene sin desafíos, provenientes de estándares emergentes y conflictivos, nuevos requerimientos de habilidades y problemas administrativos causados por la creciente cantidad de datos XML que deben ser administrados.
La mayoría de las aplicaciones tradicionales de negocio y de las aplicaciones basadas en Internet dependen de bases de datos. Existen diversos modelos diferentes de bases de datos, sin embargo, la mayoría son relacionales. Para
mantener datos en una base de datos, éstos deben ser obtenidos y almacenados de una manera consistente, confiable y eficiente.
El uso de la infraestructura existente de bases de datos para la administración de demandas de datos XML parece ser lógico. Sin embargo, nuevos productos nativos XML están construidos para manejar las demandas de datos XML en forma nativa sin el bagaje de conversiones a otras estructuras de bases de datos como la relacional. Adicionalmente, existe una diversidad de estrategias de almacenamiento XML, procesos de conversión y niveles de soporte para XML con los productos líderes de bases de datos.
Requerimientos de Almacenamiento XML
Los documentos y los requerimientos de almacenamiento de datos XML pueden ser pensados a menudo en dos categorías generales: centrados en los datos y centrados en los documentos. Las demandas centradas en los datos suelen incluir documentos de facturación típicos, órdenes de compra y documentos menos estructurados, y es apropiada para ítems como contenidos de periódicos, artículos y publicidad. Si el documento XML tiene una estructura bien definida y contiene datos actualizables usados en maneras diversas, el documento es típicamente centrado en los datos. Los datos centrados en el documento tienden a ser más impredecibles en tamaño y contenido que los centrados en los
datos los cuales son altamente estructurados, con tipos de datos de tamaño limitado y reglas menos flexibles para campos opcionales y contenido.
Los sistemas de almacenamiento XML deben acomodarse eficientemente con ambos tipos de requerimientos de datos, dado que XML está siendo ampliamente usado en sistemas que administran ambos tipos de datos. La mayoría de los productos se enfocan en servir uno de esos formatos de datos mejor que el otro. Las bases de datos relacionales tradicionales son típicamente mejores al tratar con requerimientos centrados en los datos, mientras que los sistemas de administración de contenido y de documentos son típicamente mejores para almacenar datos centrados en el documento.
En los sistemas que encuentran XML, es común tener ambas categorías de datos dentro de la misma aplicación. Los documentos centrados en los datos se pueden originar en bases de datos relacionales o como un documento XML que puede haber sido transmitido como parte de un sistema B2B. Los sistemas de bases de datos deben ser capaces de exponer los datos relacionales como XML y almacenar el XML recibido como datos relacionales para transferir, obtener y almacenar transparentemente los datos requeridos por la aplicación.
Si bien es posible almacenar datos centrados en el documento en bases de datos relacionales u orientadas al objeto, esto resultará típicamente en duplicar el trabajo de un sistema administrador de contenido. Similarmente, dado que un sistema de administración de contenido está usualmente construido sobre una base de datos
orientada al objeto o jerárquica, tratar de usarlo como base de datos probablemente será complicado.
La diferencia entre los datos centrados en los datos y los centrados en el documento no siempre es fácil de identificar. Por ejemplo, una orden de compra puede contener datos tales como comentarios o notas. Adicionalmente, los datos centrados en los documentos, tales como artículos de revistas, pueden tener datos estructurados como el nombre del autor y la fecha. Típicamente los requerimientos que manejan los datos se inclinan con mayor peso en una dirección o la otra. Entender si los datos están más centrados en el documento o en los datos será ventajoso cuando se elija la estrategia de almacenamiento.
Estrategias para el Almacenamiento de Datos XML
Con el objeto de mover datos entre un documento XML y una base de datos y viceversa, los datos en la base de datos deben ser mapeados a la estructura del documento XML. De la manera simple, el documento XML completo es mapeado a una columna única en la base de datos. Estrategias más complejas incluyen el mapeo de cada elemento a una columna correspondiente en la base de datos o el mapeo de la estructura del documento XML a la base de datos.
1. Almacenar el documento completo en forma de texto, como un gran objeto binario (BLOB) en una base de datos relacional.
Esta es una buena estrategia si el documento XML contiene contenido estático que sólo será modificado cuando el documento completo es reemplazado. Esta estrategia es común para datos centrados en el documento conforme estos datos son obtenidos y almacenados típicamente como una unidad. Los tres vendedores líderes de bases de datos relacionales (Microsoft SQL Server, Oracle Oracle10g, IBM DB2) soportan este método. Almacenar el documento completo en formato de texto es fácil de implementar dado que no se necesita mapeo o traducción, pero puede limitar también la búsqueda, indexación y granularidad de la obtención de documentos XML. Por otro lado, el documento XML se mantiene como era antes de ser almacenado, lo que minimiza el trabajo de rearmarlo después de su obtención.
2. Almacenar una forma modificada del documento completo en el sistema de ficheros.
Este método es popular cuando el número de documentos es pequeño y los documentos XML son infrecuentemente actualizados y transferidos entre sistemas de ficheros. Nuevamente, los vendedores líderes de bases de datos soportan este método, pero tiene limitaciones que incluyen escalabilidad, flexibilidad en almacenamiento y recuperación, y seguridad dado que los datos descansan fuera de la base de datos. Almacenar una forma modificada del documento completo en
el sistema de ficheros es bastante limitado dado que el sistema de ficheros no hace una base de datos muy buena. Este método funciona para un número menor de documentos XML y típicamente puede ser incluido solamente en el diseño dado que el documento XML se está moviendo por el sistema de ficheros. Eventualmente, los contenidos de un documento XML podrían terminar en una base de datos.
3. Mapear la estructura de los datos en el documento en la base de datos.
Por ejemplo, mapear un documento XML que contiene una orden de ventas con tablas como Ordenes, Items, Partes, y Clientes u objetos como Orden, Item, Parte, y Cliente. Si la estructura del documento XML no es compatible con la estructura de la base de datos, el documento debe ser transformado para ajustarlo a la estructura de la base de datos antes de almacenarlo. Mapear la estructura de los datos en el documento a la base de datos es una opción muy popular y es el foco de muchas características habilitadoras de XML en los productos principales de bases de datos y es el tema de muchos artículos y libros en el último par de años.
¿QUÉ TECNOLOGÍAS O APLICACIONES SERÁN SUSTITUIDAS POR XML?
HTML no es lo bastante robusto para extraer datos de bases de datos; CGI es complicado y puede ser lento; EDI es demasiado exigente en mano de obra y tiene que ser rehecho para cada socio. XML ofrece la oportunidad de intercambiar datos en el navegador personalizado del modo “plug and play”.
En realidad se considera que más que sustituciones de tecnologías se irán produciendo acoplamientos y sustitución paulatina de aplicaciones como sucedió al comienzo de los 90 con la expansión de las tecnologías orientadas a objetos.
Los previsibles usos producirán desplazamiento en las estrategias de los centros de decisión en las organizaciones que afectarán considerablemente a las tomas de decisiones en tecnologías de la información. Estándares asociados a XML como SOAP, BizTalk, VoiceXML,etc. irán sustituyendo poco a poco las aplicaciones ya citadas y muchas otras relacionadas.
LOS ESTÁNDARES
Ya se ha comentado la gran cantidad de estándares existentes de XML. En realidad existe una auténtica Torre de Babel de dialectos del XML. Tal vez sea éste el gran peligro que amenaza a XML, la definición de un estándar dentro de los estándares. Existe una esperanza y es que al contrario de lo que sucede con los idiomas normales, las variaciones de XML se pueden traducir mecánicamente sin errores ni ambigüedades.
Algunos ejemplos que confirman lo anterior son RSS y el consorcio RosettaNet. RSS (Rich Site Summary) desarrollado por los inventores de Netscape que, entre otras cosas, permite ofrecer titulares en dialecto RSS (la CNN.com es un ejemplo).
RosettaNet desarrolla dialectos XML y estándares para la automatización de pedidos y el suministro de componentes en la industria informática, es decir, la cadena de gestión de suministros SCM.
EL FUTURO
Uno de los grandes inconvenientes que a su vez es una ventaja si se logran vencer es que sólo son económicamente viables cuando están respaldados por el mayor número posible de protagonistas del sector, aunque la obligada formación de comités disminuye la capacidad de reacción, sobre todo cuando tienen que tomar decisiones por consenso. El futuro vendrá marcado si los grandes fabricantes de ordenadores, automóviles, la biogenética, etc. confirman las
