Comparación de las Tecnologías Java para XML

El procesamiento XML consume muchos recursos. Los documentos XML son documentos de texto que necesitan ser analizados antes de que se pueda realizar cualquier procesamiento. El an�lisis de un documento XML podr�a resultar en un stream de eventos si se usa el API SAX, o en un modelo del documento en memoria si se usa el API DOM. Durante el an�lisis, un analizador con validaci�n podr�a realizar algunos chequeos de validaci�n del documento contra un esquema predefinido (una Document Type Definition o un XML Schema).

Procesar un documento XML significa reconocer, extraer y procesar directamente los contenidos de los elementos y los valores de los atributos o mapearlos a otros objetos de negocio que posteriormente ser�n procesados. Antes de que una aplicaci�n pueda aplicar cualquier l�gica de negocio, deben tener lugar los siguientes pasos.

  • An�lisis.
  • Opcionalmente, validaci�n (lo que implica primero analizar el esquema).
  • Reconocimiento.
  • Extracci�n
  • Opcionalmente, mapeo.

Analizar documentos XML implica mucha codificaci�n y decodificaci�n de caracteres y procesamiento de strings. Luego, dependiendo del API elegido, el reconocimiento y la extracci�n del contenido podr�a corresponder a pasar a trav�s de una estructura de datos en forma de �rbol,o a capturar los eventos generados por el analizador y procesarlos de acuerdo a alg�n contexto. Si una aplicaci�n usa XSLT para preprocesar un documento XML, se a�ade incluso m�s procesamiento antes de que pueda empezar a funcionar la l�gica de negocio real.

Usar el API DOM implica la creaci�n en memoria de una representaci�n del documento como un �rbol DOM. Si el documento es muy grande, as� de grande ser� el �rbol DOM y el consumo de memoria.

Las estructuras f�sica y l�gica de un documento XML podr�an ser diferentes. Un documento XML podr�a contener referencias a entidades externas que son sustituidas en el contenido del documento durante el an�lisis y anteriormente a la validaci�n. Estas entidades externas y el propio esquema (como un DTD) podr�an estar localizados en sistemas remotos, especialmente si el propio documento es originario de otro sistema. Para proceder con el an�lisis y la validaci�n, primero deben cargarse (descargarse) las entidades externas. Los documentos con una compleja estructura f�sica podr�an, por lo tanto, consumir mucha I/O de red.

En esta p�gina, daremos algunos trucos para mejorar el rendimiento cuando se procesan documentos XML, articulados en torno al consumo de CPU. memoria e I/O o red.

.�Usar el API m�s Apropiado: Elegir entre SAX y DOM

Tanto DOM como SAX tiene caracter�sticas que los hacen mejores para ciertos tipos de tareas:

Tabla 1: Caracter�sticas de SAX y DOM

SAX DOM
Modelo basado en eventos Estructura de datos tipo �rbol
Acceso serie (flujo de enventos) Acceso aleatorio (estructura de datos en memoria)
Bajo uso de memoria
(s�lo se generan los eventos)
Alto uso de memoria (el documento est� localizado en memoria)
Para procesar partes del documento
(capturar los eventos relevantes)
Para editar el documento
(procesar la estructura de datos en memoria)
Para procesar el documento s�lo una vez
(flujo temporal de eventos)
Para procesar el documento m�ltiples veces
(documento cargado en memoria)

Omitiendo el impacto del consumo de memoria en el rendimiento general del sistema, el procesamiento usando el API DOM normalmente es m�s lento que usando el API SAX, principalmente porque el API DOM podr�a tener primero que cargar todo el documento en memoria para permitir que sea editado o que los datos sean recuperados facilmente, mientras que el API SAX permite un procesamiento inmediato mientras el documento es analizado. Por lo tanto, DOM deber�a utilizarse cuando el documento fuente va a ser editado o procesado varias veces.

SAX es muy conveniente cuando queremos extraer informaci�n de un documento XML (el contenido de un elemento o el valor de un atributo) sin importar el contexto general -- su posici�n en el �rbol del documento XML, o si la estructura del documento se mapea exactamente con la extructura de objetos de l�gica de negocio. De otra forma, seguir la pista de los elmentos anidados podr�a ser muy tedioso y podr�a hacerse mejor usando DOM. A pesar de todo, cuando un documento fuente va a ser mapeado a objetos de negocio que no son representados principalmene como un �rbol DOM, se recomienda usar SAX para mapear directamente a los objetos de negocio, evitando una representaci�n intermedia consumidora de recursos. Por supuesto, si los objetos de negocio tienen una representaci�n directa en Java, se pueden usar las tecnolog�as como XML Data Binding (JAXB).

Como las tecnolog�as de alto nivel como XSLT tratan con tecnolog�as de nivel m�s bajo como SAX y DOM, el rendimiento cuando usamos estas tecnolog�as podr�a verse impactado por el uso de SAX o DOM. JAXP proporciona soporte para implementaciones de XSLT que aceptan una fuente de entrada y un resultado de salida en la forma de eventos SAX. Cuando construyamos complejas tuber�as de procesamiento XML, podemos usar SAXTransformerFactory de JAXP para procesar el resultado de otra hoja de estilo de transformaci�n con otra hoja de estilo. Trabajar con eventos SAX hasta el �ltimo estadio de una tuber�a optimizar� el rendimiento evitando la creacci�n de estructuras de datos en memoria como �rboles DOM.

.�Considerar APIs Alternativos

JDOM no es una envoltura alrededor de DOM, aunque comparte el mismo prop�sito que DOM con respecto a XML. Se ha hecho lo suficientemente gen�rico para dirigirse a cualquier modelo de documento. JDOM ha sido optimizado para Java y adem�s, para el uso del API Java Collection. Los documentos JDOM pueden construirse y convertirse directamente a eventos SAX o �rboles DOM, permitiendo que JDOM sea integrado en las tuber�as de procesamiento XML y en particular con fuentes o resultados de transformaciones XSLT.

dom4j es otro API alternativo muy similar a JDOM. Adem�s viene con una integraci�n a XPath: el interface org.dom4j.Node por ejemplo define m�todos para seleccionar nodos de acuerdo a una expresi�n XPath. dom4j tambi�n implementa el modelo de procesamiento basado en eventos lo que le permite un procesamiento eficiente de grandes documentos XML. Los manejadores pueden registrarse para ser llamados durante el �nalisis cuando se encuentran las expresiones XPath, permiti�ndonos procesar inmediatametne y disponer de las partes del documento sin tener que esperar a que todo el documento sea analizado y cargado en memoria.

Si un modelo de documento se ajusta a la estructura de datos principal de una aplicaci�n, deber�amos considerar seriamente el uso de JDOM y dom4j. Adem�s, al contrario que DOM, los documentos JDOM o dom4j son serializables, lo que les da m�s opciones cuando las arquitecturas complejas se comunican entre aplicaciones.

Usando un API alternativo como JDOM y dom4j, un desarrollador podr�a evitar alguna p�rdida de rendimiento como las descritas en la p�gina anterior, cuando se accede a los elementos por sus nombres de etiqueta, ya que el API a trav�s del soporte del API Java Collection es m�s correcto. Como es de peso ligero y optimizado para Java, podr�amos esperar una sensible mejora del rendimiento.

.�Cuidado con las Diferencias entre Implementaciones

Como presentamos en la p�gina anterior, las implementaciones son diferentes. Algunas enfatizan la funcionalidad, y otras el rendimiento. La futura conectividad de JAXP permite a los desarrolladores cambiar entre implementaciones y seleccionar la mas apropiada para conseguir los requerimientos de la aplicaci�n.

Como ejemplo, cuando usamos DOM, una complicaci�n com�n es la p�rdida de soporte de la serializaci�n en el propio API (es decir, la transformaci�n de un �rbol DOM en un documento XML). Por lo tanto, es una tentaci�n saltarse el API est�ndard y llamar a caracter�sticas de serializaci�n dependientes de la implementaci�n con el coste de la p�rdida de los beneficios de la conectividad de JAXP. Abajo hay ejemplos de c�digo para serializar un �rbol DOM a un stream XML con Xerces y Crimson.

C�digo de ejemplo 1: serializaci�n con Xerces que trata con un API separado que es empaquetado junto con la implementaci�n DOM:

import org.w3c.dom.*;
import org.apache.xerces.dom.*;
import org.apache.xml.serialize.*;

Document document = ...
OutputFormat format = new 
OutputFormat(document);
format.setDoctype(null, 
"../samples/dtd/Chessboard.dtd");
XMLSerializer serializer = new 
XMLSerializer(new
    PrintWriter(System.out),format);
serializer.asDOMSerializer();
serializer.serialize(document.getDocumentElement());

C�digo de ejemplo 2: Serializaci�n con Crimson que trata con m�todos especificos de la implementaci�n DOM:

import org.apache.crimson.tree.XmlDocument;
Document document = ...
((XmlDocument) 
document).setDoctype(null,
    "../samples/dtd/Chessboard.dtd", null);
((XmlDocument) document).write(System.out);

JAXP dirige la serializaci�n de un �rbol DOM a trav�s del uso del Identity Transformer como se presenta en el ejemplo de abajo. El transformador de indentidad s�lo cop�a el �rbol fuente en el �rbol resultante y le aplica el m�todo de salida especificado. Para sacarlo en XML, el m�todo de salida s�lo necesita seleccionarse a xml. Resuelve el problema de una forma f�cil e independiente de la implementaci�n.

C�digo de ejemplo 3: Serializaci�n independiente de la implementaci�n con el Identity Transformer (no se pasan argumentos al m�todo TransformerFactory.newInstance):


import javax.xml.transform.*;
import javax.xml.transform.stream.*;
import javax.xml.transform.dom.*;

Document document = ...
TransformerFactory transformerFactory =
    TransformerFactory.newInstance();
Transformer transformer = 
    transformerFactory.newTransformer();
transformer.setOutputProperty(OutputKeys.METHOD, "xml");
transformer.setOutputProperty(OutputKeys.DOCTYPE_SYSTEM,
    "../samples/dtd/Chessboard.dtd");
transformer.transform(new DOMSource(document),
new StreamResult(System.out));

JAXP, con su soporte para muchos analizadores y motores de hojas de estilo, es un punto fuerte de nuestra aplicaci�n. Merece la pena capitalizarlo, para que posteriormente, las implementaciones de los analizadores subyacentes puedan intercambiarse f�cilmente sin necesitar realizar ning�n cambio en el c�digo de la aplicaci�n.

.�Ajustar las Implementaciones Subyacentes

El API JAXP define m�todos para seleccionar/obtener caracter�sticas y propiedades para poder configurar las implementaciones subyacentes. a parte de las propiedades y caracter�sticas est�ndards como http://xml.org/sax/features/validation usada para desactivar la validaci�n, una implementaci�n de un analizador, de un constructor de documento, o de un transformador particular podr�a definir caracter�sticas y propiedades espec�ficas para activar o desactivar comportamientos espec�ficos dedicados a mejorar el rendimiento. Por ejemplo, Xerces define la caracter�stica http://apache.org/xml/features/dom/defer-node-expansion, que permite activar o desacticar un modo DOM "lazy" difuso (activado por defecto); en este modo, los nodos del �rbol DOM son evaludados difusamente: su creaci�n es relegada, s�lo se crean cuando son accedidos. La construcci�n de un �rbol DOM desde un documento XML se vuelve m�s r�pida y s�lo se expanden los nodos accedidos. Esta caracter�stica es particularmente �til cuando s�lo se procesan partes del �rbol DOM.

Seleccionar una caracter�stica o propiedad especifica deber�a hacerse con cuidado para preservar la intercambiabilidad de la implementaci�n subyacente. Cuando una caracter�stica o propiedad no est� soportada o no es reconocida por la implementaci�n subyacente, el SAXParserFactory, el XMLReader o el DocumentBuilderFactory podr�an lanzar una SAXNotRecognizedException, una SAXNotSupportedException o una IllegalArgumentException. Debemos evitar el agrupamiento de caracter�sticas y propiedades, especialmente las est�ndards con las espec�ficas, en un s�lo bloque try/catch; menejar las excepciones de forma independiente para que las caracter�sticas o propiedades opcionales espec�ficas no nos dejen intercambiar a una implementaci�n diferente. Podr�amos dise�ar nuestra aplicaci�n de forma que las caracter�sticas y propiedades que son espec�ficas de implementaciones subyacentes tambi�n podr�an ser definidas externamente a la aplicaci�n, en un fichero de configuraci�n por ejemplo.

.�Reutilizar y Almacenar Analizadores

Una aplicaci�n XML podr�a tener que procesar diferentes tipos de documentos (como documentos conformes a diferentes esquemas), y esos documentos pueden ser accedidos desde diferentes fuentes. Se podr�a usar un s�lo analizador (por thread de ejecuci�n) para manejar los documentos de diferentes tipos sucesivamente s�lo reasignando los manejadores de acuerdo al documento fuente a ser procesado. Como son objetos complejos, los analizadores podr�as ser almacenados para que puedan se reutilizados por otros threads de ejecuci�n, reduciendo el trabajo de la asignaci�n de memoria y el recolector de basura. Adicionalmente si el n�mero de tipos diferentes de documentos es muy grande y si los manejadores son muy costosos de crear, tambi�n se podr�an almacenar estos. Las mismas consideraciones se aplican a las hojas de estilo y los transformadores.

.�An�lisis Parcial con SAX

Si podemos usar SAX, y la informaci�n que queremos extraer del documento est� localizada el principio o al menos no muy al final del documento, podr�amos obtener un mejor rendimiento si podemos interrumpir el an�lisis tan pronto como hayamos extra�do la informaci�n. Podemos conseguir esto lanzando una excepci�n SAX. Esto podr�a ser especialmente �til cuando un documento est� envuelto en otro documento (el sobre) y necesitamos obtener m�s informaci�n sobre el recipiente al que poder enrutarlo. Podr�amos s�lo querer extraer informaci�n desde el sobre sin analizar el contenido del documento que podr�a ser mucho m�s grande.

C�digo de ejemplo 4: Cuando se ha extra�do la primera ocurrencia del elemento objetivo (variable target), se lanza una EndOfProcessingException y se para el analizador

private String target;

public class EndOfProcessingException
  extends SAXException {
 public EndOfProcessingException(String msg) {
 super(msg);
 }
} 

public class ChessboardHandler extends HandlerBase {

 private boolean acquired = false;

 public void startElement(String name,
     AttributeList attrs) {
  if (name.equals(target)) {
   acquired = true;
   ...
   // Start processing the targeted element
   ...
  }
  ...
  return;
 } 

 public void characters(char[] ch, int start,
      int length) {
  if (acquired) {
   ...
   // Process the targeted element content
   ...
  }
  ...
  return;
 } 

 public void endElement(String name,
     AttributeList attrs)
   throws SAXException {
  if (name.equals(target)) {
   if (acquired) {
    ...
    // Finish processing the targeted element
    ...
    throw new EndOfProcessingException("Done.");
   }
  }
  ...
  return;
 }
 ...
} 

Cuando se ejecuta contra los documentos fuentes XML usados para la comparaci�n para localizar la primera ocurrencia del elemento KING, como en el programa de ejemplo, siempre se ejecuta en el mismo tiempo sin importar el tama�o del documento.

.�Reducir el Coste de Validaci�n

La validaci�n es importante y podr�a ser requerida para garantizar la fiabilidad de una aplicaci�n XML. Una aplicaci�n podr�a tratar leg�timamente sobre la validaci�n por el analizador para evitar un doble chequeo de validaci�n de elementos anidados y valores de atributos. Un documento XML v�lido podr�a ser v�lido en el dominio de la aplicaci�n. Las capacidades de las Document Type Definitions son limitadas. Por ejemplo, en el aplicaci�n Chessboard, nada podr�a evitar que dos piezas compartieran los mismos valores de sus atributos fila y columna. La validaci�n XML no descarga a la aplicaci�n de otras restricciones de validaci�n no cubiertas que podr�an ser violadas sin invalidar un documento. No tratar con la validaci�n XML podr�a hacer m�s fr�gil la aplicaci�n; por otro lado, la validaci�n afecta al rendimiento.

En la siguiente explicaci�n, nos referimos principalmente a DTD pero los principios tambi�n pueden aplicarse a otros lenguajes de esquemas XML.

Nota:
Para las especificaciones XML, un analizador sin validaci�n no es necesario que lea las entidades externas (inlcuyendo el DTD externo); por lo tanto, las entidades externas referenciadas en el documento podr�an no ser expandidas y los atributos podr�an no ser sustituidos por sus valores por defecto. En dicho caso, la informaci�n pasada a la aplicaci�n llamante podr�a no ser la misma cuando se usa un analizador con o sin validaci�n. En el contexto de este tutorial, s�lo estamos considerando analizadores que, incluso aunque son sin validaci�n, hacen -- por defecto, o a trav�s de la configuraci�n apropiada -- la carga y an�lisis del DTD y las entidades referenciadas en el documento. Esto permite, por ejemplo, que las entidades sean sustituidas, los valores de atributos normalizados, y sus valores por defecto apropiadamente sustituidos, para que la aplicaci�n se pueda ejecutar sin modificar cuando cambia de validaci�n a no validaci�n del documento de entrada.

C�digo de ejemplo 5: Un d�cumento XML inv�lido. XML v�lido, pero el dominio de la aplicaci�n inv�lido: dos peones est�n en la misma posici�n; la validaci�n XML no descarga en la aplicaci�n el esfuerzo de algunas restricciones espec�ficas del dominio:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE CHESSBOARDS SYSTEM "dtd/Chessboards.dtd">
<CHESSBOARDS>
 <CHESSBOARD>
  <WHITEPIECES>
   <KING><POSITION COLUMN="G" ROW="1" /></KING>
   <BISHOP><POSITION COLUMN="D" ROW="6" /></BISHOP>
   <ROOK><POSITION COLUMN="E" ROW="1" /></ROOK>
   <PAWN><POSITION COLUMN="A" ROW="4" /></PAWN>
   <PAWN><POSITION COLUMN="A" ROW="4" /></PAWN>
   <PAWN><POSITION COLUMN="B" ROW="3" /></PAWN>
   <PAWN><POSITION COLUMN="C" ROW="2" /></PAWN>
   <PAWN><POSITION COLUMN="F" ROW="2" /></PAWN>
   <PAWN><POSITION COLUMN="G" ROW="2" /></PAWN>
   <PAWN><POSITION COLUMN="H" ROW="5" /></PAWN>
  </WHITEPIECES>
  <BLACKPIECES>
   <KING><POSITION COLUMN="B" ROW="6" /></KING>
   <QUEEN><POSITION COLUMN="A" ROW="7" /></QUEEN>
   <PAWN><POSITION COLUMN="A" ROW="5" /></PAWN>
   <PAWN><POSITION COLUMN="D" ROW="4" /></PAWN>
  </BLACKPIECES>
 </CHESSBOARD>
 <CHESSBOARD>
  ...
 </CHESSBOARD>
</CHESSBOARDS>

En un sistema con componentes que intercambian documentos, el coste de la validaci�n puede reducirse eficientemente teniendo en cuenta las siguientes observaciones (ver la Ilustraci�n 1):

  1. Los documentos intercambiados dentro de los componentes del sistema podr�an no requerir validaci�n.
  2. Los documentos que vienen de fuera del sistema deben validarse cuando entran.
  3. Los documentos que vienen de fuera del sistema, una vez validados, podr�an intercambiarse libremente entre los componentes sin ninguna otra validaci�n.

Por ejemplo, una aplicaci�n de negocios multi-capa que intercambia documentos con partners a trav�s de la red forzar� la validaci�n en la capa web (capa inicial) de cualquier documento entrante. No s�lo chequea la validaci�n del documento contra un esquema, tambi�n se asegurar� de que el tipo del documento es uno (o el �nico) que puede aceptarse. Entonces los documentos podr�an ser enrutados a otros servidores para ser manejados por los servicios apropiados. Como los documentos ya se han validado no requieren posteriores validaciones.

En otras palabras, cuando nosotros somos el productor y el consumidor de documentos XML podr�amos usar la validaci�n s�lo para depurar y desactivarla durante la producci�n.


Ilustraci�n 1: La validaci�n se require cuando la fuente no puede se creible. Una vez en el sistema, la validaci�n podr�a considerarse opcional.

A�n, incluso sin validaci�n, las DTDs y las entidades referenciadas en los documentos necesitan ser cargadas y analizadas permitiendo a las entidades ser sustituidas, a los valores de atributos ser normalizados o sus valores por defecto apropiadamente sustituidos.

En este extremo, los documento sin DTDs no requieren validaci�n. Como no se refieren a ninguna DTD o entidad externa, no se carga o analiza nada y no se puede hacer la validaci�n. El rendimiento es por lo tanto mejor. Esta soluci�n extrema, como no es viable para intercambiar documentos XML entre aplicaciones, puede usarse entre los componentes de una aplicaci�n XML. En este caso particular, la declaraci�n de tipo de documento podria insertarse durante la depuraci�n para activar la validaci�n, y ser omitida en un entorno de producci�n.

A�n un documento conforme a una DTD, puede, despu�s de una validaci�n opcional, ser convertido en un documento equivalente que no requerir� validaci�n o sustituci�n de entidades externas usando el proceso de canonizalizaci�n XML. Este proceso, que se describe m�s abajo, no fue pensado originalmene para mejorar el rendimiento, pero podr�amos beneficiarnos de �l bajo ciertas situaciones y con ciertas limitaciones.

Cualquier documento puede ser convertido en un equivalente (con algunas limitaciones) a un documento sin DTD a trav�s de un proceso XML llamado Canonizalizaci�n. El documento generado se llama un documento XML Can�nico.

"Cualquier documento XML es parte de un conjunto de documentos XML que son equivalentes l�gicos dentro de un contexto de aplicaci�n, pero que podr�an variar en la representaci�n f�sica basada en los cambios de sintaxis permitidos por XML 1.0 y Namespaces en XML. Esta especificaci�n describe un m�todo para generar una representaci�n f�sica, la forma can�nica, de un documento XML que cuenta con los cambios permisibles. Excepto para las limitaciones de unos pocos casos inusuales, si dos documentos tienen la misma forma can�nica, los dos documentos son l�gicamente equivalentes dentro de un contexto de aplicaci�n dado. Observa que los dos documentos podr�an tener formas can�nicas diferentes y todav�a ser equivalentes en un contexto dado basado en las reglas de equivalencia espec�ficas de la aplicaci�n para las que la especificaci�n XML generalizada podr�a no tenerse en cuenta" -- Extra�do de Canonical XML Version 1.0 - W3C Recommendation 15 March 200.

El proceso de canonizalizaci�n resulta en algunos cambios en el documento original, entre otros:

  1. Codificaci�n del documento en UTF-8.
  2. Normalizaci�n de la ruptura de l�neas a #xA.
  3. Normalizaci�n de los valores de atributos.
  4. Sustituici�n de caracteres y entidades analizadas.
  5. Eliminaci�n de la declaraci�n XML.
  6. Eliminaci�n de la declaraci�n del tipo de documento.
  7. Adicci�n de los atributos por defecto.

Aunque la canonizalizaci�n no se ha pensado para este prop�sito, podemos usarlo para mejorar el rendimiento. El frontal de una aplicaci�n de negocios electr�nico desde nuestros ejemplos anteriores podr�a verse mejorado para validar el documento entrante y generar una forma can�nica de los documentos que son enrutados a los servicios apropiados. Los servicios finales est�n disponibles para analizar el documento mucho m�s r�pidametne ya que no se requiere validaci�n y el documento no se refiere a ninguna entidad externa. Los documentos can�nicos generados, aunque tienen la misma estructura l�gica, no comparten la misma estructura f�sica que los documentos originales. La aplicaci�n por lo tanto, podr�a requerir que la versi�n original sea archivada al principio del proceso de tuber�a.

Desafortunadamente, hasta ahora, no hay un m�todo de salida XSL est�ndard que pudiera ser utilizado con el identity transformer (presentado arriba) para generar una forma can�nica de un documento fuente. Para generar esta forma can�nica podr�amos tener que escribir un ContentHandler de SAX2 personalizado. La distribuci�n Xerces incluye programas de ejemplo (sax.SAX2Writer o sax.Writer por ejemplo) que generan XML can�nico.

El c�digo de ejemplo de abajo muestra la forma can�nica de un documento XML. Observa la ausencia de las declaraciones XML y DTD y el reemplazo de cada ruptura de l�nea por un #xA. Aunque siendo equivalente en la estrructura l�gica, no comparte la misma estructura f�sica y es bastante menos le�ble. Por lo tanto, si se tuviera que hacer alg�n archivado deber�a hacerse con el documento original.

C�digo de ejemplo 6: La forma can�nica de uno de los documentos Chessboards-[10-5000].xml (se han reintroducido rupturas de l�neas despu�s de alguno de los caracteres &#xA; para prop�sitos de lectura):

<CHESSBOARDS>&#xA; <CHESSBOARD>&#xA;  <WHITEPIECES>&#xA;
   <KING><POSITION COLUMN="G" ROW="1"></POSITION></KING>&#xA;
   <BISHOP><POSITION COLUMN="D" ROW="6"></POSITION></BISHOP>&#xA;
   <ROOK><POSITION COLUMN="E" ROW="1"></POSITION></ROOK>&#xA;
   <PAWN><POSITION COLUMN="A" ROW="4"></POSITION></PAWN>&#xA;
   <PAWN><POSITION COLUMN="B" ROW="3"></POSITION></PAWN>&#xA;
   <PAWN><POSITION COLUMN="C" ROW="2"></POSITION></PAWN>&#xA;
   <PAWN><POSITION COLUMN="F" ROW="2"></POSITION></PAWN>&#xA;
   <PAWN><POSITION COLUMN="G" ROW="2"></POSITION></PAWN>&#xA;
   <PAWN><POSITION COLUMN="H" ROW="5"></POSITION></PAWN>&#xA;
  </WHITEPIECES>&#xA;  <BLACKPIECES>&#xA;
   <KING><POSITION COLUMN="B" ROW="6"></POSITION></KING>&#xA;
   <QUEEN><POSITION COLUMN="A" ROW="7"></POSITION></QUEEN>&#xA;
   <PAWN><POSITION COLUMN="A" ROW="5"></POSITION></PAWN>&#xA;
   <PAWN><POSITION COLUMN="D" ROW="4"></POSITION></PAWN>&#xA;
  </BLACKPIECES>&#xA;</CHESSBOARD>&#xA;
...
</CHESSBOARDS>

El gr�fico de abajo meustra el tiempo relativo para procesar un documento XML en su forma original y en su forma can�nica. Dependiendo de la complejidad del esquema y del n�mero de entidades externas referidas, la diferencia de rendimienro podr�a ser incluso mayor:


Ilustraci�n 2: Tiempo para procesar un documento (conteniendo una configuraci�n de tablero de ajedrez procesada 1000 veces) y su forma can�nizada con SAX, usando Xerces sin validaci�n (JDK 1.2.2_06)

AL igual que la validaci�n, la canonizalizaci�n podr�a ser activada s�lo en un entorno de producci�n, cuando buscamos el mejor rendimiento. La canonizalizaci�n s�lo puede usarse si los documentos XML can�nicos y los documentos originales son equivalentes. Si la aplicaci�n trata, por ejemplo, sobre comentarios u otros eventos l�xicos generados por el anlizador, la canonizalizaci�n no puede ser utilizada. Cualquier variante de este proceso se puede aplicar siempre que �mbas formas del documento XML - el original y el refinado - sean equivalentes para la aplicaci�n.


Ilustraci�n 3: Como el documento (post-validaci�n) es can�nico, no incluye una Document Type Declaration y no se refiere a ninguna entidad externa.

.�Reducir el Coste de Referenciar Entidades Externas

Las entidades externas incluyendo subconjuntos de DTD externos, requieren que sean cargadas y analizadas, incluso cuando son sin validaci�n, para poder ofrecer la misma informaci�n a la aplicaci�n sin importar la validaci�n. Los documentos independientes no referencian ninguna entidad externa pero todav�a podr�an usar subconjuntos DTD internos. Por lo tanto, evitando la carga de entidades externas, se podr�a mejorar el rendimiento, especialmente comparado con los casos donde el DTD u otras entidades externas residen en un repositorio no local.

De cualquier forma, los documentos independientes podr�an no ser la soluci�n especialmente en el caso de los documentos de negocios intercambiables que tratan con esquemas XML p�blicos que est�n publicados en alg�nr registro com�n o repositorio.

C�digo de ejemplo 7: Un documento XML independiente, el DTD ha sido embebido como un subconjunto DTD interno. El rendimiento se podr�a mejorar especialmetne comparandolo con una situaci�n donde el DTD es un subconjunto DTD externo localizado en un repositorio remoto.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<!DOCTYPE CHESSBOARD [ 
 <!ELEMENT CHESSBOARD (WHITEPIECES, BLACKPIECES)>
 <!ENTITY % pieces
  "KING,
   QUEEN?,
   BISHOP?, BISHOP?, 
   ROOK?, ROOK?,
   KNIGHT?, KNIGHT?, 
   PAWN?, PAWN?, PAWN?, PAWN?,
   PAWN?, PAWN?, PAWN?, PAWN?"
 >
 <!ELEMENT WHITEPIECES (%pieces;)>
 <!ELEMENT BLACKPIECES (%pieces;)>
 <!ELEMENT POSITION EMPTY>
 <!ATTLIST POSITION
  COLUMN (A|B|C|D|E|F|G|H) #REQUIRED
  ROW (1|2|3|4|5|6|7|8) #REQUIRED
 >
 <!ELEMENT KING (POSITION)>
 <!ELEMENT QUEEN (POSITION)>
 <!ELEMENT BISHOP (POSITION)>
 <!ELEMENT ROOK (POSITION)>
 <!ELEMENT KNIGHT (POSITION)>
 <!ELEMENT PAWN (POSITION)>
]>

<CHESSBOARD>
 <WHITEPIECES>
  <KING><POSITION COLUMN="G" ROW="1"/></KING>
  <BISHOP><POSITION COLUMN="D" ROW="6"/></BISHOP>
  <ROOK><POSITION COLUMN="E" ROW="1"/></ROOK>
  <PAWN><POSITION COLUMN="A" ROW="4"/></PAWN>
  <PAWN><POSITION COLUMN="B" ROW="3"/></PAWN>
  <PAWN><POSITION COLUMN="C" ROW="2"/></PAWN>
  <PAWN><POSITION COLUMN="F" ROW="2"/></PAWN>
  <PAWN><POSITION COLUMN="G" ROW="2"/></PAWN>
  <PAWN><POSITION COLUMN="H" ROW="5"/></PAWN>
 </WHITEPIECES>
 <BLACKPIECES>
  <KING><POSITION COLUMN="B" ROW="6"/></KING>
  <QUEEN><POSITION COLUMN="A" ROW="7"/></QUEEN>
  <PAWN><POSITION COLUMN="A" ROW="5"/></PAWN>
  <PAWN><POSITION COLUMN="D" ROW="4"/></PAWN>
 </BLACKPIECES>
</CHESSBOARD>

.�Cachear Entidades Externas

Cachear usando un Proxy Cache

Las referencias a entidades externas localizadas en un repositorio remoto podr�an ser mejoradas seleccionando un proxy que almacene cualquier documento recuperado y especialmente las entidades externas -- proporcionando las referencias a las entidades externas en URLs cuyos protocolos son manejados por el proxy.


Ilustraci�n 4: Arquitectura de Cach�. Las entidades todav�a tienen que se resueltas.

Cachear con un EntityResolver Personalizado

Los analizadores SAX permiten a las aplicaciones XML manejar entidades externas de una forma personalizada. Dichas aplicaciones tienen que registrar su propia implementaci�n del interface org.xml.sax.EntityResolver con el analizador usando el m�todo setEntityResolver. Entonces las aplicaciones pueden interceptar cualquier entidad externa (incluyendo subconjuntos de DTD externos) antes de que sean analizadas.

Esta caracter�stica puede utilizarse para implementar:

  1. Un mecanismo de cach� en la propia aplicaci�n, o
  2. Un mecanismo de b�queda URI que podr�a redirigir el sistemas y las referencias p�blicas a un copia local de un repositorio p�blico.

Ambos mecanismos pueden usarse conjuntametne para asegurarnos incluso un mejor rendimiento. El primero podr�a usarse para entidades est�ticas que tienen un tiempo de vida mayor que el de la aplicaci�n. Este es especialmente el caso de los DTDs p�blicos que normalmente evolucionan a trav�s de sucesivas versiones, y que incluyen la versi�n en su identificador p�blico o de sistema. El segundo mecanismo podr�a primero mapear los identificadores p�blicos a identificadores del sistema y luego aplicar el mismo mecanismo que un cach� por proxy normal cuando se trata con identificadores de sistema en la forma de URL, especialmente chequeando las actualizaciones y evitando el cambio del contenido din�mico.

C�digo de ejemplo 8: Una simple implementaci�n de Cach� para entiades externas (esta implementaci�n esta incompleta: no libera las entradas no usadas en el mapeo de entidades).

import java.lang.ref.*;
import org.xml.sax.*;
import org.xml.sax.helpers.*;
import javax.xml.parsers.*; 

...

public class EntityCache {
 public static final int MAXCHUNCK = 5 * 1024 * 1024;
 private Map entities = new HashMap();
 private byte[] buf = new byte[MAXCHUNCK];

 public InputStream getEntity(String systemId) {
  byte[] entity = null;
  SoftReference reference 
    = (SoftReference) entities.get(systemId);
  if (reference != null) {
   // Got a soft reference to the entity,
   // let's get the actual entity.
   entity = (byte[]) reference.get();
  }
  if (entity == null) {
   // The entity has been reclaimed by the GC or was
   // never created, let's download it again!
   return cacheEntity(systemId);
  }
  return new ByteArrayInputStream(entity);
 }

 // Attempt to cache an entity - if it's too big 
 // just return an input stream to it
 private InputStream cacheEntity(String systemId) {
  try {
   BufferedInputStream stream
     = new BufferedInputStream(new 
   URL(systemId).openStream());
   int count = 0;
   for (int i = 0; count < buf.length; count += i) {
    if ((i = stream.read(buf, count, buf.length - 
  count)) < 0) {
     break;
    }
   }
   byte[] entity = new byte[count];
   System.arraycopy(buf, 0, entity, 0, count);
   if (count != buf.length) { // Not a too big entity
    // Cache the entity for future use, using a soft
    // reference so that the GC may reclaim it
    // if the memory is running low.
    entities.put(systemId, new SoftReference(entity));
    return new ByteArrayInputStream(entity);
   }
   // Entity too big to be cached
   return new SequenceInputStream(
     new ByteArrayInputStream(entity), stream);
  } catch (Exception exception) {
   // The default EntityResolver will try to get it...
   return null;
  }
 }
}

C�digo de ejemplo 9: Un simple programa que usa el API SAX e implementa el entity resolver para buscar entiades en un cach� de memoria:

import org.xml.sax.*;
import org.xml.sax.helpers.*;
import javax.xml.parsers.*;
...

public class ChessboardSAXPrinter {
 private SAXParser parser;
 private EntityCache entityCache;

 public class ChessboardHandler extends HandlerBase {

  public void startElement(String name, 
   AttributeList attrs) {
   // XML processing
   ...
  }

  public InputSource resolveEntity(String publicId,
    String systemId) {
   if (entityCache != null) {
    if (systemId != null) {
     InputStream stream = 
   entityCache.getEntity(systemId);
     if (stream != null) {
InputSource source = new InputSource(stream);
source.setPublicId(publicId);
source.setSystemId(systemId);
      return source;
     }
    }
   }
   // Let the default entity resolver resolve this one...
   return null;
  }
 }
  
 public ChessboardSAXPrinter(boolean validating, 
    boolean caching) throws Exception {
  this.entityCache = caching ? new EntityCache() : null;
  SAXParserFactory parserFactory 
    = SAXParserFactory.newInstance();
  parserFactory.setValidating(validating);
  parser = parserFactory.newSAXParser();
  return;
 }
}

La mejora de rendimiento es bastante significante, especialmente cuando las entidades externas est�n localizadas a trav�s de la red:


Ilustraci�n 5: Tiempo para procesar un documento XML (que contiene una configuraci�n de tablero de ajedrez y referencia su DTD a trav�s de una LAN) con SAX, usando Xerces con validaci�n (JDK 1.2.2_06)

Cuando se combinan las dos arquitecturas sugeridas para reducir el coste de la validaci�n y el coste de las referencias a entidades externas, la arquitectura resultante se podr�a parece a esta:


Ilustraci�n 6: Una arquitectura para reducir el coste de la validaci�n y la referencia a entidades externas; el cach� s�lo ocurre en el lado final ya que los documentos procesados por los servicios no se refieren a ninguna entidad externa.

.�Cachear el Contenido Generado y las Hojas de Estilo

El ejemplo eMobile de aplicaci�n presentado en la Conferencia JavaOne 2000 proporcionana un ejemplo de c�mo los servlets pueden generar contenido dirigido a diferentes dispositivos desde valores de objetos devueltos por una aplicaci�n EJB. Las hojas de estilo se aplicaci�n a los �rboles DOM construidos desde los valores de los objetos para poder transformarlos en el tipo de contenido objetivo.

Hay dos sitios donde se mejor� el rendimiento de la capa web de la aplicaci�n de ejemplo eMobile:

  1. La construcci�n de los �rboles DOM desde los valores de los objetos devueltos por la aplicaci�n EJB.
  2. La carga de las hojas de estilo desde ficheros.

Ilustraci�n 7: Los dos lugares donde se mejor� el rendimiento en la apliaci�n eMobile.

Cuando todo el contenido generado no pod�a entrar en el dispositivo (la pantalla WML o la p�gina HTML), el resultado fue dividio entre varias pantallas o p�ginas para permitir que el usuario nevegara por todo el resultado. Las pantallas o p�ginas fueron generadas una cada vez sobre la solicitud del usuario desde el �rbol DOM. Para evitar llamar de nuevo a la aplicaci�n EJB, el �rbol DOM fue almacenado en la sesi�n del usuario. Cuando se carg�, las hojas de estilo tambi�n fueron almacenadas (cacheadas) para evitar tener que recargarlas para cada generaci�n de contenido.

Cachear los resultados de un solicitud de usuario para servir m�s r�pidamente las siguientes peticiones relacionadas consume memoria. No debe hacerse en detremiento de otros usuarios: la aplicaci�n no debe fallar porque se acabe la memoria debid� al cach� de resultados. Las referencias blandas introducidas con Java 2 permiten interact�ar con el recolector de basura para implementar cach�s.

En el contexto de un contenedor web distribuido, la referencia al �rbol DOM almacenado en la sesi�n podr�a tener que ser declarada como transient, primero porque no todas las implementaciones de DOM son serializables (lo que es un requerimiento para cualquier objeto almacenado en una HttpSession) y segundo porque como veremos luego, la serializaci�n de un �rbol DOM podr�a ser muy costosa y por lo tanto podr�a afectar a los beneficios del cach�.

El siguiente ejemplo de c�digo muestra c�mo una consulta y su resultado son cacheados en la sesi�n asociada del cliente, y c�mo el resultado de una consulta realizada anteriormente podr�a ser recuperado de la sesi�n. Ese c�digo de ejemplo de la aplicaci�n eMobile ha sido actualizado para tener en cuenta los contenedores web distribuidos.

C�digo de ejemplo 10: Cachear una consulta y su resultado en la sesi�n asociada al cliente:

import java.ref.*;

private class CacheEntry implements Serializable 
{
 Object query;
  // If the entry is replicated through serialization
  // result will be reset to null
  transient SoftReference result = null;
  
 CacheEntry(Object query, Object result) {
  this.query = query;
  this.result = new SoftReference(result);
  
 Object getResult() {
  if (result != null) {
   return result.get();
   }
   return null;
 }
}

/**
 * Stores the query and its result in the client's 
 * associated session so that the response to the 
 * same query will be immediate.
 * A soft reference is used so that if the memory is 
 * running low the GC may reclaim the result objects.
 *
 * @param query the query, may be the HTTP request 
 * query string itself...
 * @param result the result to the query
 * @param session the HTTP session
 */

protected void cacheQueryResult(Object query, Object
    result, HttpSession session) 
{
 session.setAttribute(QUERY_ATTRIBUTE,
 new CacheEntry(query, result));
 return;
} 

/**
 * Gets the result of a previously executed query  
 * that has been cached in the session. 
 * The previously cached result may be returned only 
 * if the cached query and the requested query match.  
 * Since soft references are used a matching result 
 * may not be returned if the result has already been 
 * reclaimed by the GC due to a shortage of memory.
 *
 * @param query the query, may be the HTTP request query
 *   string itself...
 * @param session the HTTP session
 * @return the associated matching result if it could be
 *   retrieved or null
 */
protected Object getCachedQueryResult(Object query,
    HttpSession session) 
{
 CacheEntry entry = (CacheEntry) 
   session.getAttribute(QUERY_ATTRIBUTE);
 if (entry != null) { 
// A cached entry was retrieved
  
  Object cachedResult = entry.getResult();
  if (cachedResult != null) {
   // The referred cached result was not reclaimed by the GC
   Object cachedQuery = entry.query;
    if (cachedQuery.equals(query)){
	// The cached query and the requested query match
	if (TRACE) {
	   System.err.println("Query cache hit.");
	}
	return cachedResult;
  } else if (TRACE) {
    System.err.println("Query cache miss (mismatch).");
  }
  } else if (TRACE) {
   System.err.println("Query cache miss (GC).");
  }
  } else if (TRACE) {
    System.err.println("Query cache miss (session).");
  }

 // The queries didn't match or the cached result could not
 // be retrieved, let's just clean
 session.removeAttribute(QUERY_ATTRIBUTE);
 return null;
}

Cachear las hojas de estilo trata con el mismo principio que cachear los �rboles DOM resultantes. Cuando fueron cargadas, las hojas de estilo fueron almacenadas en un hashtable usando referencias blandas donde pueden ser compartidas por todos los servlets.

Junto con esta l�nea, JAXP 1.1 define el inteface javax.xml.transform.URIResolver que podr�a implementarse para recuperar recursos referenciados en la hoja de estilo con sentencias xsl:import o xsl:include. En el contexto de una aplicacion que usa un gran conjunto de hojas de estilo, esto podr�a usarse para implementar el cach� de la misma forma que EntityResolver arriba.

.�Usar Java 2 SE v 1.3 (y superiores)

El procesamiento XML consume mucha CPU y mucha memoria. Para una aplicaci�n del laldo del servidor, se obtiene mejor rendimiento usando el servidor de sistema HotSpot que puede ser activado pasando la opci�n -server cuando se lanza la m�quina virtual Java. Tambi�n hay disponibles algunas otras opciones para configurar el tama�o de la pila y el recolector de basura. La informaci�n importante se puede encontrar en Frequently Asked Questions - HotSpot.

.�Usar XML con Parsimonia

Los documentos XML son documentos de texto. Por lo tanto pueden intercambiarse f�cilmente entre sistemas heterog�neos. Pero requieren una fase de an�lisis que, como se menciono anteriormente, es muy costosa. Es el precio a pagar para permitir que los sistemas debilmente emparejados funcionen -- debilmente emparejados no s�lo t�cnicamente, sino tambi�n en el entorno empresarial. Cuando los componentes del sistema est�n fuertemente acoplados, t�cnicas no orientadas a documentos "normales" (usando RMI por ejemplo) hasta ahora son m�s eficientes no s�lo en t�rminos de rendimiento sino tambi�n en t�rminos de complejidad de c�digo. Con tecnolog�as como JAXB los dos mundos se pueden combinar eficientemente para desarrollar sistemas que sean internamente fuertemente acoplados, orientados a objetos y que interact�an junto de una forma orientada a documento debilmente acoplada.


Ilustraci�n 8: Una arquitectura mezclada, acoplamiento ligero orientado a documento en el exterior y, fuerte acoplamieto orientado a objeto en el interior.

Para ilustrar esta sentencia, comparemos el coste de serializar/deserilizar desde/hacia:

  1. Un documento XML, a trav�s de un �rbol DOM intermedio que representa los "objetos de negocio".
  2. Una forma serializada Java de los "objetos de negocio"
  3. Una forma serializada Java del �rbol DOM que representa los "objetos de negocio".

Cuando dise�amos las clases Java que implementan todas las piezas (clases (King, Queen, Bishop, Rook, Knight y Pawn) as� como las clases que implementan un tablero de ajedrez y un conjunto de tableros (clases Chessboard y Chessboards). Todas estas clases implementan m�todos para crear una representaci�n DOM equivalente. Tambi�n podr�an implementar el interface Serializable para que sus ejemplares puedan ser serializados o deserializados desde una forma Java serializada. La clase Chessboards implementa adicionalmente m�todo para serializar a XML y deserializar desde XML.

El fragmento de c�digo de abajo muestra los m�todos de la clase Chessboards para serializar a XML y deserializar desde XML, crear un ejemplar desde una representaci�n DOM, y crear una representaci�n DOM desde un ejemplar. Las otras clases (Chessboard, King, Queen...) implementan m�todos DOM equivalentes.

C�digo de ejemplo 11: Implementaci�n de los m�todos de Chessboards para serializar/deserializar desde/hacia XML y DOM: la serializaci�n/deserializaci�n desde/hacia un objeto Java serializado simplemente se activa implementando el interface Serializable:

public void toXML(OutputStream out, DocumentBuilder builder,
    Transformer transformer) throws Exception {
 transformer.transform(new DOMSource(toDOM(builder)),
    new StreamResult(out));
 return;
} 

public Document toDOM(DocumentBuilder builder)
  throws Exception {
 Document document = builder.newDocument();
 Element root 
   = (Element) document.createElement("CHESSBOARDS");
 for (Iterator j = chessboards.iterator(); j.hasNext();) { 
  Chessboard chessboard = (Chessboard) j.next();
  root.appendChild(chessboard.toDOM(document));
 }
 document.appendChild(root);
 return document;
} 

public static Chessboards fromXML(String sourceURI,
    DocumentBuilder builder)
   throws Exception {
 Document document = builder.parse(sourceURI);
 return fromDOM(document);
} 

public static Chessboards fromDOM(Document document)
   throws Exception {
 Element root = document.getDocumentElement();
 if (root.getTagName().equals("CHESSBOARDS")) {
  Node child = root.getFirstChild();
  Chessboards chessboards = new Chessboards();
  do {
   if (child.getNodeType() == Node.ELEMENT_NODE) {
    Element element = (Element) child;
    if (element.getTagName().equals("CHESSBOARD")) {
     chessboards.chessboards.add(Chessboard.fromDOM(element));
    }
   }
  } while ((child = child.getNextSibling()) != null);
  return chessboards;
 }
 throw new IllegalArgumentException(root.getTagName());
}

Para medir los rendimientos hemos implementado tres programas de prueba estructuralmente equivalentes. El primero cargaba el documento original XML describiendo un conjunto de configuraciones de tableros de ajedrez y, en un bucle, lo escrib�a en un fichero y lo le�a de nuevo como un documento XML o como objetos Java serializados. Ejecutamos estos programas de pruebas sobre un conjunto de 1000 configuraciones de tableros de ajedrez, cada uno procesado 10 veces durante 10 ejecuciones. El tiempo medido fue la suma de los tiempos de usuario y de sistema devueltos por el comando ptime, dividido por el n�mero total de serializaciones/deserializaciones.

C�digo de ejemplo 12: El prorama de ejemplo para serializar/deserializar hacia/desde XML a trav�s de un �rbol DOM intemedio.

DocumentBuilderFactory builderFactory
  = DocumentBuilderFactory.newInstance();
DocumentBuilder builder
  = builderFactory.newDocumentBuilder();
TransformerFactory transformerFactory
  = TransformerFactory.newInstance();
Transformer transformer;
transformer = transformerFactory.newTransformer();
transformer.setOutputProperty(OutputKeys.DOCTYPE_SYSTEM,
    "file:dtd/Chessboards.dtd");
transformer.setOutputProperty(OutputKeys.METHOD,
    "xml");
// Reading the original XML document
Chessboards chessboards
  = Chessboards.fromXML(args[1], builder);
for (int k = 0; k < r; k++) {
 for (int i = 0; i < n; i++) {
  PrintStream out = new PrintStream(
    new BufferedOutputStream(new 
        FileOutputStream(args[2])));
  // Serializing
  chessboards.toXML(out, builder, transformer);
  out.close();
  // Deserializing
  chessboards = Chessboards.fromXML(args[2], builder);
 }
}

C�digo de ejemplo 13: El programa de prueba para serializar/deserializar desde/hacia un objeto Java serializado:

// Reading the original XML document
Chessboards chessboards = Chessboards.fromXML(args[1]);
for (int k = 0; k < r; k++) {
 for (int i = 0; i < n; i++) {
  ObjectOutputStream out = new ObjectOutputStream(
    new BufferedOutputStream(new 
        FileOutputStream(args[2])));
  // Serializing
  out.writeObject(chessboards);
  out.close();
  ObjectInputStream in = new ObjectInputStream(
    new BufferedInputStream(new
        FileInputStream(args[2])));
  // Deserializing
  chessboards = (Chessboards) in.readObject();
  in.close();
 }
} 

C�digo de ejemplo 14: El programa de prueba para serializar/deserializar desde/hacia un �rgol DOM Java serializado:

DocumentBuilderFactory builderFactory
  = DocumentBuilderFactory.newInstance();
DocumentBuilder builder
  = builderFactory.newDocumentBuilder();
// Reading the original XML document
Chessboards chessboards 
 = Chessboards.fromXML(args[1], builder);
for (int k = 0; k < r; k++) {
 for (int i = 0; i < n; i++) {
  ObjectOutputStream out = new ObjectOutputStream(
    new BufferedOutputStream(new 
        FileOutputStream(args[2])));
  // Serializing
  out.writeObject(chessboards.toDOM(builder));
  out.close();
  ObjectInputStream in = new ObjectInputStream(
    new BufferedInputStream(new 
        FileInputStream(args[2])));
  // Deserializing
  chessboards
    = Chessboards.fromDOM((Document) in.readObject());
  in.close();
 }
} 

Los resultados de esto muestran que la serializaci�n directa de objetos de negocio Java no es s�lo m�s r�pida que la serializaci�n XML o la serializaci�n de �rboles DOM Java, sino que tambi�n el objeto serializado resultante es m�s peque�o que el documento XML serializado o el �rbol DOM serializado. La serializaci�n Java del �rbol DOM es la m�s costosa en tiempo de proceso as� como en consumo de memoria, por lo tanto deber�a usarse en casos extremos, especialmente en el contexto de Enterprise JavaBeans (EJB) donde la serializaci�n ocurre cuando se accede a EJBs remotos. Cuando se accede a EJBs locales, �rboles DOM o fragmentos de �rboles DOM se pueden pasar sin incurrir en el mismo problema.


Ilustraci�n 9: Tiempo medio para serializar/deserializar un conjunto de 1000 configuraciones de tableros de ajedrez en su forma XML (a trav�s de un �rbol DOM intemedio), en sus fomas de "Objetos de Negocio" Java serializados y en sus formas de �rboles DOM Java serializados; la implementaci�n DOM de Crimson no soporta la serializaci�n Java


Ilustraci�n 10: Tama�o del documento XML serializado, la forma de los "Objetos de Negocio" Java serializados y la forma del �rbol DOM Java serializado.

Las aplicaciones que est�n internamente orientadas a documento podr�a estar dise�adas para que s�lo la informaci�n m�s relevante y la m�s accedida sea extra�da desde el documento para ser procesada y mapeada en objetos de negocio. Estos objetos de negocio podr�an mantener una referencia al documento original (en su forma de texto origianl o en una representaci�n DOM cacheada) para que m�s informaci�n se pueda consultar cuando se necesite desde el documento original usando expresiones XPath o XQuery, por ejemplo.

.�Conclusi�n

En esta p�gina hemos presentado diferentes trucos para mejorar el rendimiento. La primera cuesti�n a realizarnos cuando desarrollamos aplicaciones basadas en XML es "�Deber�a estar basada en XML?" Si la respuesta es si, tenemos que dise�ar una arquitectura balanceada, una arquitectura que s�lo trate con XML para lo que sea bueno: comunicaciones abiertas entre aplicaciiones, descripciones de configuraciones, compartici�n de informaci�n, o cualquier dominio para que el que pueda existir un esquema XML. Podr�a no ser la elecci�n para interfaces no expuesto o para intercambio de componentes que de otra forma deber�an acoplarse fuertemente. Deber�a ser el procesamiento XML s�lo un estado de pre o post-procesamiento de la l�gica de negocio o deber�a tener sentido para la aplicaci�n tener su estructura de datos principal representada como documentos, el desarrollador tendr� que elegir entre los diferetes APIs e implementaciones considerando no s�lo sus funcionalidades y su facilidad de uso, sino tambi�n su rendimiento. Por �ltimo, las aplicaciones Java basadas en XAML se desarrollan en Java y por lo tanto tambi�n se les puede aplicar cualquier regla de mejora de rendimiento Java, especialmente, aquellas que tratan con el procesamiento de strings y la creaci�n de objetos.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR