Sistema de intercambio de archivos y catálogos sobre ...bibing.us.es/proyectos/abreproy/11342/fichero...Sistema de intercambio de archivos y catálogos sobre plataforma peer-to-peer

Sistema de intercambio de archivos y catálogos sobre

plataforma peer-to-peer

Departamento de Ingeniería de Sistemas y Automática, Área de Ingeniería Telemática

Escuela Superior de Ingenieros, Universidad de Sevilla

PROYECTO FIN DE CARRERA Realizado por D. José Laffitte Redondo Dirigido por Dña. Teresa Ariza Gómez Sevilla, Diciembre 2006

A la memoria de mi padre,

a mi madre y a mis hermanos.

El texto que el lector tiene en sus manos constituye la memoria del proyecto fin de carrera “Sistema de intercambio de archivos y catálogos sobre plataforma peer-to-peer”, realizado por José Laffitte Redondo y tutelado por M ª Teresa Ariza Gómez, de la Escuela Superior de Ingenieros de Sevilla. En esta memoria se realiza una descripción del trabajo que ha supuesto la realización de este proyecto. Para una completa comprensión de la aplicación, se aconseja la lectura del anexo ”Manual de usuario de la aplicación”. Además, se incluye en el anexo “Código de la aplicación” el código de la aplicación desarrollada. Ambos anexos se pueden encontrar en el cd adjunto a esta documentación, además de los diagramas de clases de la aplicación, la documentación del código javadoc y la propia aplicación lista para ejecutarse.

Índice de contenidos CAPÍTULO 0: Motivación, objetivos y planificación ................................................... 1

1 Motivación y objetivos.......................................................................................... 1 2 Planificación temporal........................................................................................... 2 3 Organización de la documentación ........................................................................ 3

CAPÍTULO 1: Peer to Peer .......................................................................................... 5 1 Introducción.......................................................................................................... 5

2 Objetivos del P2P.................................................................................................. 6 3 Características de los sistemas P2P........................................................................ 6 4 Conceptos P2P ....................................................................................................... 7

4.1 Comunicación punto a punto ........................................................................... 7 4.2 Comunicación por difusión.............................................................................. 7 4.3 Comunicación multipunto................................................................................ 8 4.4 Las barreras de Internet: NAT, Firewall y servidores Proxy............................. 8

5 Aplicaciones P2P ................................................................................................ 11 5.1 Mensajería instantánea ................................................................................. 12 5.2 Telefonía P2P............................................................................................... 12 5.3 Aplicaciones colaborativas ........................................................................... 13 5.4 Juegos .......................................................................................................... 13 5.5 Televisión P2P ............................................................................................. 13 5.6 Compartición de ficheros.............................................................................. 14 5.7 Distribución de contenido............................................................................. 16 5.8 Sincronización.............................................................................................. 16 5.9 Computación distribuida............................................................................... 17 5.10 Incluso una red diferente: Freenet ................................................................ 17

6 Clasificación P2P ................................................................................................. 18 7 Ventajas del P2P .................................................................................................. 19

8 Problemas del P2P ............................................................................................... 20 9 Desafío y futuro del P2P...................................................................................... 20

CAPÍTULO 2: JXTA .................................................................................................. 22 1 Introducción......................................................................................................... 22 2 Historia de JXTA ................................................................................................. 24 3 Objetivos de JXTA............................................................................................... 25 4 Conceptos de JXTA ............................................................................................. 26 5 Seguridad en JXTA.............................................................................................. 39 6 Protocolos de JXTA ............................................................................................. 39

6.1 Protocolos del núcleo de JXTA...................................................................... 40 6.1.1 Peer Resolver Protocol (PRP) ................................................................... 41

Mensaje de petición..................................................................................... 41 Mensaje de respuesta ................................................................................... 42 Mensaje SRDI ............................................................................................. 43

6.1.2 Endpoint Routing Protocol (ERP) ........................................................... 43 Información de ruta ..................................................................................... 44 Mensaje de petición de rutado...................................................................... 45 Mensaje de respuesta de guiado ................................................................... 45

6.2 Protocolos estándares de JXTA ................................................................... 45

6.2.1 Peer Discovery Protocol (PDP)............................................................... 46 Mensaje de petición de descubrimiento........................................................ 46 Mensaje de respuesta del descubrimiento..................................................... 47

6.2.2 Protocolo Rendezvous (RVP) ................................................................. 48 Anuncio de rendezvous................................................................................ 49 Protocolo de control de la Vista de Pares ..................................................... 49 Protocolo de Arrendamiento (Lease) de Rendezvous ................................... 51 Mensaje de petición de arrendamiento (Lease)............................................. 51 Mensaje de Arrendamiento (Lease) otorgado............................................... 52 Mensaje de Cancelación de Arrendamiento (Lease) ..................................... 52

Protocolo del Mensaje de Propagación ........................................................ 52 Protocolo de control de la propagación ........................................................ 52

6.2.3 Peer Information Protocol (PIP).................................................................. 53 Obteniendo respuestas PIP........................................................................... 53 Mensaje de petición PIP .............................................................................. 54 Mensaje de respuesta PIP ............................................................................ 54

6.2.4 Pipe Binding Protocol (PBP) ..................................................................... 56 Anuncio de la tubería................................................................................... 56 Mensaje de Resolución de tubería................................................................ 57 Cabecera del mensaje por la tubería de propagación .................................... 58

7 JXTA y Java ............................................................................................................ 58 8 La configuración de JXTA ....................................................................................... 59 9 La caché de JXTA.................................................................................................... 60 CAPÍTULO 3: XML y tecnologías relacionadas......................................................... 61

1 Introducción......................................................................................................... 61 2 Historia ................................................................................................................ 62 3 Descripción XML ............................................................................................... 63 3.1 Documentos XML......................................................................................... 63 3.2 Descripción del meta lenguaje XML.............................................................. 64 3.3 Sintaxis de un documento XML .................................................................... 67

4 Procesamiento de documentos XML desde Java....................................................... 69 4.1 DOM (Document Object Model) ................................................................... 71 4.2 SAX (Simple Api X Java) ............................................................................. 71 4.3 JDOM ("Java optimized" document object model) ........................................ 72

5 Tecnologías relacionadas con XML ......................................................................... 73 5.1 XSL............................................................................................................... 74

5.1.1 XSLT ..................................................................................................... 75 5.1.1.1 Sintaxis XSLT ................................................................................. 75 5.1.1.2 Procesadores de texto XSLT ............................................................ 76

5.1.2 XPath ..................................................................................................... 76 Sintaxis XPath............................................................................................. 77

5.1.3 XSL-FO.................................................................................................. 79 CAPÍTULO 4: CXML................................................................................................. 80 1 Introducción............................................................................................................. 80 2 Aplicaciones que utilizan cXML .............................................................................. 82

2.1 Validación respecto DTD .................................................................................. 83 2.2 Especificación del estándar cXML .................................................................... 84

2.2.1 Modelo de petición-respuesta ..................................................................... 84

2.2.1.1 Convenciones de cXML....................................................................... 85 2.2.1.2 EL sobre principal de cXML................................................................ 85 2.2.1.3 Niveles de ajuste .................................................................................. 86 2.2.1.4 Elementos ............................................................................................ 86 2.2.1.5 Petición cXML .................................................................................... 88 2.2.1.6 Respuesta cXML ................................................................................. 88

2.2.2 Modelo Sentido único (asíncrono) .............................................................. 89 2.2.2.1 Elementos ............................................................................................ 90

2.3 Transacciones cXML ...................................................................................... 92 2.3.1 Transacción de perfil .................................................................................. 92

2.3.1.1 ProfileRequest ..................................................................................... 92 2.3.1.2 ProfileResponse................................................................................... 92

2.3.2 Definición de pedidos ................................................................................. 93 2.3.2.1 OrderRequest....................................................................................... 93 2.3.2.2 Respuesta a una OrderRequest ............................................................. 93

2.3.3 Transacción de punchout ............................................................................ 93 2.3.4 Catálogos.................................................................................................... 94

2.3.4.1 Elementos básicos................................................................................ 94 2.3.4.2 Gestión de suscripciones...................................................................... 95

CAPÍTULO 5: Aplicación desarrollada...................................................................... 96

1 Entorno de trabajo y de pruebas....................................................................... 96 2 Introducción a la aplicación............................................................................. 97 2.1 Tecnologías utilizadas ................................................................................... 97

JDIC................................................................................................................ 97 2.2 Problemas surgidos....................................................................................... 98 2.3 Aspectos básicos ........................................................................................... 98 2.4 Resumen de la aplicación .............................................................................. 99 2.5 Modelo de la aplicación............................................................................... 100 2.6 Diagramas de flujo de la aplicación ............................................................. 102 2.7 Conexión y desconexión del par .................................................................. 104 2.8 Comunicación entre pares en la búsqueda y descarga de archivos y catálogos............................................................................................................................. 105 2.9 Archivos de la aplicación............................................................................. 109 3 Organización de la aplicación............................................................................ 112 3.1 Paquete aplicacionFs .................................................................................. 113

3.1.1 Clase PincipalFrame ............................................................................. 113 3.1.2 Clase ConfiguraNodoFrame.................................................................. 113 3.1.3 Clase ConexionFrame........................................................................... 114 3.1.4 Clase DesconexionFrame...................................................................... 114

3.2 Paquete aplicaciones.catalogos .................................................................... 114 3.2.1 Clase BusquedaCatalogoFrame............................................................. 114 3.2.2 Clase EditarCatalogoFrame .................................................................. 114 3.2.3 Clase ModificarProductoFrame ............................................................ 114 3.2.4 Clase VisualizarCatalogoDescargado.................................................... 115 3.2.5 Clase VisualizarCatalogoFrame ............................................................ 115

3.3 Paquete com.eventos ................................................................................... 115 3.3.1 Clase GestorEventosAñadirACatalogo.................................................. 115 3.3.2 Clase GestorEventosBorrarCatalogo ..................................................... 115 3.3.3 Clase GestorEventosConectarNodos ..................................................... 115

3.3.4 Clase GestorEventosConfigurarNodos .................................................. 115 3.4 Paquete com.jxta ......................................................................................... 116

3.4.1 Clase ConfiguraPlataforma ................................................................... 116 3.4.2 Clase Nodo ........................................................................................... 116

3.5 Paquete com.jxta.anuncios........................................................................... 116 3.5.1 Clase AnuncioFichero........................................................................... 116 3.5.2 Clase PublicaAnunciosFicheros ............................................................ 116

3.6 Paquete com.jxta.anuncios.catalogos ........................................................... 116 3.6.1 Clase AnuncioCatalogo ........................................................................ 117 3.6.2 Clase PublicaAnunciosCatalogos.......................................................... 117

3.7 Paquete com.jxta.comunicaciones................................................................ 117 3.7.1 Clase GestorBusquedaPropagacion....................................................... 117 3.7.2 Clase GestorBusquedaRdv.................................................................... 118 3.7.3 Clase GestorTransaccion ...................................................................... 118

3.8 Paquete com.jxta.comunicaciones.catalogos ................................................ 119 3.8.1 Clase GestorBusquedaCatalogoRdv...................................................... 119 3.8.2 Clase GestorTransaccionCatalogoRdv .................................................. 119

3.9 Paquete com.utilidades ................................................................................ 120 3.9.1 Clase AlmacenCatalogos ...................................................................... 120 3.9.2 Clase AlmacenDescargas...................................................................... 120 3.9.3 Clase AlmacenPropiedades................................................................... 120 3.9.4 Clase Base64Codificador...................................................................... 121 3.9.5 Clase CheckSum................................................................................... 121 3.9.6 Clase FicheroLog.................................................................................. 121 3.9.7 Clase FiltroFichero ............................................................................... 122 3.9.8 Clase Semáforo..................................................................................... 122 3.9.9 Clase UtilesDirectorio........................................................................... 122

3.10 Paquete com.utilidades.entidad.................................................................. 122 3.10.1 Clase Catalogo.................................................................................... 122 3.10.2 Clase Descarga ................................................................................... 123

3.11 Paquete com.utilidades.excepciones .......................................................... 123 3.11.1 Clase FaltaPropiedadExcepcion .......................................................... 123

3.12 Paquete com.utilidades.transformaciones................................................... 123 3.12.1 Clase TransformarXML...................................................................... 123

4. Diagrama de clases de la aplicación ...................................................................... 123 CAPÍTULO 6: Conclusiones y líneas de trabajo futuro ........................................... 127 Bibliografía .............................................................................................................. 130 Glosario de términos................................................................................................. 131

CAPÍTULO 0: Motivación, objetivos y planificación

1 Motivación y objetivos En este proyecto se ha llevado a cabo el estudio en profundidad del conjunto de protocolos JXTA, implementado por Sun Microsystems, y se ha realizado una aplicación que permite el intercambio de ficheros y catálogos de una forma distribuida sin la acción de ningún servidor intermedio. Para llevar a cabo esto, se hace uso de los mecanismos provistos por JXTA para la creación y mantenimiento de redes peer-to-peer. Entre los objetivos que se marcaron al inicio del proyecto, cabe destacar:

• Estudio de la tecnología peer-to-peer y del conjunto de protocolos JXTA, con clara orientación práctica, de cara al desarrollo de aplicaciones sobre esta plataforma.

• Estudio de la tecnología peer-to-peer con vistas al comercio electrónico.

Entre las características que debe satisfacer la aplicación se encuentran las siguientes:

• Ser portable a cualquier plataforma y S.O. • Abstraer de la complejidad de la red al usuario y ofrecerle un interfaz de manejo

sencillo. • Ser capaz de adaptarse a distintos entornos de red (existencia de cortafuegos,

servidores proxy…). • Utilizar algún estándar existente para el comercio electrónico.

Así, la aplicación final provee al usuario de un interfaz desde el cual éste puede:

• Realizar búsquedas de ficheros y catálogos. • Realizar transferencias de ficheros. • Visualizar catálogos encontrados. • Editar catálogos propios.

Los catálogos, implementados mediante el estándar Cxml, son creados por el propio usuario y publicados en la red de forma que otros usuarios puedan acceder a ellos.

Capítulo 0: Motivación y objetivos Memoria

2

Figura 1 Aplicación desarrollada

2 Planificación temporal La duración efectiva del proyecto ha sido de unos seis meses, aproximadamente desde Junio de 2006 hasta Diciembre del mismo año y tuvo una distribución temporal según el diagrama de Gantt siguiente:

Figura 2 Diagrama de Gantt del proyecto Este diagrama se ha obtenido mediante la herramienta Microsoft Project, en su versión de prueba, a partir de los siguientes datos introducidos:

Figura 3 Fases del proyecto


3

A continuación se describen las acciones realizadas en cada fase del proyecto:

1. Búsqueda y estudio de información acerca de JXTA. Análisis de los protocolos. Aprendizaje de la shell de JXTA. 2. Primeros pasos en la programación JXTA. Estudios de varios entornos de programación, seleccionando aquel que permitía una programación sencilla de interfaces gráficos. Primeras aplicaciones java con JXTA. 3. Análisis de la aplicación de intercambio. Creación de diagramas de flujo y de secuencia. Programación de la aplicación. 4. Pruebas de la parte de intercambio de archivos en distintos entornos de pruebas (explicados en apartado posterior). Depuración del código. 5. Búsqueda y estudio de información acerca de Cxml. 6. Programación y pruebas sobre la parte de intercambio de catálogos. 7. Simplificación y depuración del código. Pruebas del sistema completo. 8. Documentación del proyecto. Recopilación de información.

Dentro de las distintas tareas que se han llevado a cabo no se incluye el estudio de tecnologías como Java, XML o XSL, por ser del conocimiento del autor del proyecto antes de la iniciación de éste.

3 Organización de la documentación La documentación se divide en la memoria y en un anexo que constituye el manual de usuario. Además, se incluye en el cd anexo a la documentación, el javadoc de la aplicación.

Por otra parte, la memoria se divide a su vez en los siguientes capítulos:

0. Introducción.

El capítulo actual, en el que se describen los objetivos del proyecto y su planificación temporal.

1. Peer to Peer. En este capítulo se explica en qué consiste la tecnología P2P, así como el grado de desarrollo en el que se encuentra actualmente. Se describen las características que esta tecnología aporta a una aplicación y los problemas que debe resolver. Además, se enumeran algunas de las aplicaciones más importantes basadas en P2P.

2. JXTA. Se enumeran las razones por las que este conjunto de protocolos se implementa y se describen sus aspectos más importantes.

3. XML. Repasa la tecnología XML y otras que han surgido a su alrededor como DOM y XSL. Realiza especial hincapié en la relación de Java y XML.

4. CXML.


4

Aborda el estándar de comercio electrónico cXML, que es el empleado en la realización de este proyecto, repasando la estructura y elementos básicos.

5. Aplicación desarrollada. En este capítulo se detallan el aspecto interno de la aplicación, sin entrar en detalles de código. Hace uso de esquemas que describen el comportamiento de los pares antes los eventos provocados por el usuario o por la interacción con otros pares.

6. Conclusiones y líneas de trabajo futuro. Finalmente en este capítulo se explican las conclusiones obtenidas tras la realización del proyecto. Así mismo, se apuntan posibles direcciones de investigación y aplicación a partir de este proyecto.

CAPÍTULO 1: Peer to Peer

1 Introducción La computación P2P no es un concepto nuevo. Aunque es en estos últimos años cuando está adquiriendo popularidad, es posible encontrar algunas aplicaciones de esta filosofía en la historia de Internet. De esta forma, la red Internet originalmente concebida (llamada Arpanet) en la década de 1960 era un sistema P2P que permitía el cálculo distribuido en cualquier lugar de Estados Unidos. El desafío consistía en integrar diferentes tipos de redes existentes así como permitir la integración de aquellas que pudieran surgir en un futuro. Por otra parte, el sistema de nombres de dominio (DNS) puede considerarse, en ciertos aspectos, un sistema P2P, pues la resolución de nombres es llevada a cabo de una manera distribuida por un número de máquinas cooperantes, resultando una fiabilidad y eficacia altas. En general, una red informática entre pares (P2P) se refiere a una red que no tiene clientes y servidores fijos, sino una serie de nodos que se comportan a la vez como clientes y servidores de los demás nodos de la red, en contraste con el modelo de red cliente-servidor. Cualquier nodo o par puede iniciar o completar una transacción compatible con la red. Los nodos pueden diferir en configuración local, velocidad de proceso, ancho de banda de la red y capacidad de almacenamiento, dando lugar a una red con integrantes muy heterogéneos. No es una única tecnología, aplicación o modelo de negocio. Y no debe ser caracterizado como una diferenciación estricta entre la centralización y la descentralización. De hecho, y como veremos en las aplicaciones explicadas, es posible encontrar servidores es un sistema P2P. Así, la centralización en una red P2P puede consistir en un catálogo central, como ocurre en Napster, donde actúa existe un servidor tradicional en el que los usuarios buscan música actuando como una red P2P cuando estos proceden a una descarga. En cambio, Gnutella es una red P2P completamente descentralizada. Ningún nodo es diferente de otros, excepto por el contenido que comparte La arquitectura P2P provoca que las interacciones en la red sean simétricas, pues en general no existen servicios centralizados y el usuario-nodo final de cualquier proceso tiene un papel significante en la aplicación. Como veremos más adelante, esta arquitectura es menos susceptible a problemas derivados de la red. Aunque P2P como se ha dicho no es un concepto nuevo, muchos factores hacen al P2P muy práctico para una gran cantidad de aplicaciones. Entre estos factores se incluye el incremento de dispositivos conectados a la red, el rápido incremento del ancho de banda, velocidad y potencia de las computadoras y el aumento de la capacidad de almacenamiento, sin olvidar por supuesto el incremento de la información disponible en la red.

Capítulo 1: Peer to Peer Memoria

6

Algunas de las aplicaciones que utilizan P2P son:

• Compartición de archivos – Gnutella, FastTrack, Napster, Kazaa, Emule. • Computación distribuida – SETI@Home, Avaki, Entropía. • Redes de distribución de contenidos – OpenCola, Blue Falcon Networks,

Konitiki. • Comunicaciones P2P – MSN Messenger, Yahoo! Messenger, ICQ, Jabber. • Aplicaciones de colaboración –Hive, Groove o myJXTA. • Telefonía – Skype.

P2P ofrece una alternativa a la arquitectura tradicional de Internet, el modelo cliente-servidor. Este modelo basa su efectividad en la existencia de un servidor que ofrece “servicios” a posibles clientes. Sin embargo, ambos modelos se complementan y no suponen una alternativa entre ellos. La red del presente y del futuro tomará características de ambas arquitecturas y su evolución irá de la mano de la evolución de ambos modelos.

2 Objetivos del P2P Entre los objetivos que persigue conseguir el P2P, es preciso comentar los siguientes:

• Reducir el coste, pues se comparte entre los nodos. � Mejorar la escalabilidad y la fiabilidad. � Cada nodo puede añade sus propios recursos � Es preciso dar especial atención al hecho de que pueda no existir

un servidor central. • Aumentar la autonomía.

� Las actividades son ejecutadas localmente por los nodos � Mejorar la privacidad y asegurar el anonimato � Los usuarios no deben dar información de progreso.

• Facilitar el dinamismo. � Los recursos pueden entrar y salir continuamente.

• Permitir las comunicaciones y la colaboración AdHoc (Sistema que permite la comunicación entre lugares en los que no existe una infraestructura preliminar).

3 Características de los sistemas P2P El número de usuarios de comunicaciones P2P y compartición de archivos es hoy en día de cientos de millones y se espera que esta cifra siga aumentando. Algunas de las características comunes típicas de los sistemas P2P son:

• Cada nodo es consciente del resto de nodos.


7

• Los nodos crean una red virtual que permite la abstracción de la complejidad de la interconexión, tal como cortafuegos, subredes…

• Cada nodo puede actuar tanto como cliente como servidor y contribuye a la red con sus propios recursos como CPU, espacio en disco…

• Los nodos conforman comunidades de trabajo de datos y aplicaciones que pueden ser descritos por grupos de nodos.

• La red es dinámica: los nodos entran y salen de ella frecuentemente. El rendimiento global de la aplicación P2P suele incrementarse cuanto mayor es el número de nodos conectados, al contrario de lo que ocurre en la arquitectura cliente-servidor, en el que cuando muchos clientes se conectan al servidor, el rendimiento se degrada. De hecho, en la llamada filosofía P2P encontramos un sistema enteramente meritocrático en el que "el que más comparte, más privilegios tiene y más acceso dispone de manera más rápida a más contenido". Con este sistema se pretende asegurar la disponibilidad del contenido compartido, de forma que sea posible la subsistencia de la red. El rendimiento es así mismo, dependiente de la aplicación, del protocolo P2P y de la topología de la red, que es organizada según los pares, su ancho de banda y su capacidad de computación. Puede darse el caso en el que la red P2P se sature debido a una gran cantidad de mensajes. Esto podría ocurrir en una aplicación de búsqueda, en la que si un mensaje de búsqueda se propaga (se copia de un par a otro), el mensaje podría ser enviado a un mismo par varias veces. Si la mayoría de los pares que redirigen mensajes de búsqueda y propagación contribuyen ellos mismos al envío de otros nuevos, el ancho de banda disponible podría disminuir enormemente con graves consecuencias. Para prevenir esta saturación del ancho de banda, los protocolos deberían incluir cierto control de los

mensajes, de forma que se reduzcan los mensajes duplicados e incluso se almacenase de alguna forma aquella información que es comúnmente requerida.

4 Conceptos P2P Una equivocación habitual suele ser pensar que P2P consiste en un único protocolo. Para aclarar y adaptarnos a la terminología, se procede a explicar ciertos conceptos.

4.1 Comunicación punto a punto El punto a punto es la manera más obvia de establecer una comunicación entre pares. No consiste más que en abrir un puerto de comunicación entre ellos. Esta forma de comunicación es útil para el intercambio de mensajes que necesiten directamente ser dirigidos a un par. Es usado, además, como parte de otros modelos discutidos en los apartados siguientes.

4.2 Comunicación por difusión


8

La transmisión por difusión, (broadcast) es normalmente llevada a cabo en una subred, en la que exista un emisor y uno o varios receptores, sin necesidad de reproducir la misma transmisión nodo por nodo. Se envía un mensaje a toda la red de forma indiscriminada. El mensaje es enviado a través de la red por un par y el resto escucha por un puerto específico. Es muy útil a la hora de realizar descubrimientos. Por ejemplo, se puede utilizar cuando un nuevo par se conecta a la red y emite un mensaje por difusión en el que anuncia que se acaba de conectar, además de una dirección por la que otros pares se pueden comunicar con él. La difusión es a menudo utilizada para entregar video, puesto que sólo una copia es enviada pero la pueden visualizar todos los pares.

4.3 Comunicación multipunto El multipunto (multicast) es a menudo asociado con la difusión. Sin embargo, la diferencia es que en el multipunto, la fuente de tránsito envía una única copia de los paquetes hacia una dirección de grupo. La infraestructura de red replica estos paquetes de forma inteligente, encaminando los datos de acuerdo con la topología de receptores interesados en esa información y aportando inteligencia a la difusión del mensaje. El multipunto puede ser utilizado de varias formas para crear mensajes de transporte. Algunos pares, pueden especializarse como enrutadores, puertas de enlace, o incluso caché de mensajes. Los problemas que su aplicación puede encontrar son, sobretodo, derivados del hecho de que los mensajes no tienen garantía de ser recibidos simultáneamente. Es posible que el retraso entre la transmisión y la recepción pudiera ser inadmisible debido al tratamiento que darían al mensaje los pares “retransmisores”, o por falta de ancho de banda. A pesar de estos problemas, las redes multipunto son muy útiles y razonablemente fiables y eficientes.

4.4 Las barreras de Internet: NAT, Firewall y servidores Proxy Uno de los problemas más comunes que el P2P encuentra en Internet es la existencia de barreras que impiden la comunicación directa entre varios pares. La barrera más común es el cortafuegos (firewall), cuya labor consiste en filtrar ciertos puertos de comunicación, limitar el acceso a determinados computadores y filtrar específicos patrones de mensajes. Prácticamente un cortafuegos sólo permite el paso de mensajes Http. Otra barrera para la comunicación directa es NAT (siglas en inglés de Traducción de dirección de red), que es un estándar de Internet que le permite a una LAN (siglas en inglés de Red de Área Local) usar un grupo de direcciones IP para el tráfico interno y otro grupo de direcciones IP para el tráfico externo. La NAT posee tres propósitos principales:

• Proveer un tipo de cortafuegos al ocultar las direcciones IP internas.


9

• Permitirle a una empresa usar más direcciones IP internas. Dado que son internas, no hay posibilidad de conflicto con IP’s usadas por otras empresas u organizaciones.

• Permitirle a una empresa combinar múltiples conexiones ISDN dentro de una misma conexión a Internet.

Por último, un servidor Proxy permite el acceso a Internet a todos los equipos de una organización cuando sólo se puede disponer de un único equipo conectado, esto es, una única dirección IP. Provee servicios como el filtrado, cacheado y monitorización de tráfico. Estas barreras han sido salvadas mediante el uso del protocolo Http. Mediante el uso de Http en una aplicación, conocida como túnel Http, se puede incrementar la posibilidad de atravesar las distintas barreras. La técnica de tunneling consiste en encapsular un protocolo de red sobre otro creando un túnel dentro de una red de comunicaciones (o red de computadoras). Http tunneling Mediante un protocolo de comunicación dos o más entidades de sistemas diferentes se comunican mediante esta figura:

Figura 4 protocolo genérico En este caso el protocolo P es propio al tipo de las entidades A y B. El tunneling consiste en encapsular un protocolo dentro de otro:

Figura 5 Tunneling

En circunstancias normales, como se ha dicho, cuando un cliente Web visita una página, se establecen una o más conexiones Tcp en el puerto 80 del servidor web, usando el protocolo Http.


10

Figura 6 Aplicación web Si como ejemplo se toman dos aplicaciones Ay B que se comunican mediante el protocolo P que usa Tcp para transporte, en el primer paso, los datos de la aplicación son enviados al cliente tunelizador, que encapsula esos datos dentro del protocolo. La aplicación y el cliente tunelizador no tienen porqué estar en la misma máquina, basta con que sea accesible. En el segundo paso, el cliente tunelizador envía una petición estándar Http al falso servidor WEB, este ultimo, la desencapsula y envía los datos a la aplicación destino, que como en el primer paso, no es necesario que sea la misma maquina la que corra la aplicación y el falso servidor Web. Por sencillez, CT representará al cliente tunelizador y SDT al servidor destunelizador, valga la redundancia. Si por ejemplo, se pretendiera tunelizar el protocolo SSH (Secure SHell), se tendría el esquema siguiente:

Figura 7 Tunneling aplicado a SSH Nota:

Bastaría con sólo 2 hosts A y B, pero podrían participar hasta 4. Se configuraría el cliente SSH para que se conectase con el mismo, al puerto Tcp en el que hayamos configurado el CT. El CT enviaría los datos al SDT usando el protocolo Http, para ello podría utilizar si es necesario un Proxy Web. El Host B, SDT, enviaría los datos desencapsulados al Host C, servidor de SSH. De esta forma, el host A y el host C establecerían una comunicación SSH a través del túnel virtual sobre Http, siendo este túnel 100 % transparente para la aplicación en cuestión, salvo en lo que a direcciones se refiere, puesto que el cliente del host A ha conectado consigo mismo y no directamente con C.


11

La razón de todo este embrollo radica en que aunque el protocolo Http use al Tcp para el transporte, en muchas ocasiones no es posible una comunicación directa por Tcp entre dos máquinas. Es el caso por ejemplo de una red interna de una empresa o universidad en la que la salida hacia Internet está limitada a un Proxy WEB únicamente. En este caso, en teoría, no es posible una conexión Tcp desde la LAN interna hacia el exterior, la única salida es vía Http. Las aplicaciones de las técnicas de encapsulado por Http Tunneling son diversas, y varían desde una simple evasión para descargar un fichero desde eMule, hasta conectar MSN Messenger, realizar videoconferencias y todo lo que se tenga bloqueado encapsulando en el puerto 80. Los administradores de seguridad o de los dispositivos perimetrales suelen restringir el tráfico entrante y, para evitarse problemas, no lo hacen con el saliente, pero esto puede ser un problema más que grave. Siempre se sugiere hacer una configuración de doble bastión, donde, generalmente, un pilar es un firewall, y el otro, un proxy dando salida y permisos a la LAN. De esta forma, el proxy se puede manejar, de manera más fácil, restricciones para aplicaciones, todo desde la capa de aplicación, y dejarle la función de filtrado de paquetes al firewall de front-end. Además, esto nos protege del ataque común que veremos a continuación. El problema con la aplicación túnel Http es que la comunicación se ve desplazada. Una respuesta puede ser enlazada con su petición, pero el contexto entre cada ciclo de petición/respuesta se vería relacionado con aquellos posteriores o anteriores. Debido a ello, algunos tipos de identificador deben ser pasados desde el cliente al servidor de forma que se consiga mantener el contexto. Estos identificadores serían las cookies. Para adecuar esta solución al P2P se debe hacer uso de pares “relay”, que actúen de servidores Http. Si estos servidores disponen de una capacidad suficiente, y si existen grupos de “relays” a lo largo de la red estratégicamente colocados, el tunneling llega a adquirir una eficiencia mayor. Este uso de relays no parece un concepto muy P2P, pero realmente cualquier par podría ser uno de ellos. Lo podemos pensar como un simple intermediario en una transacción.

5 Aplicaciones P2P La mayoría de las aplicaciones P2P más populares en la actualidad poseen cierto grado de centralización en su arquitectura. Así, algunas de estas aplicaciones pueden llegar a ser correctamente empleadas mediante una arquitectura cliente/servidor.


12

Figura 8 Aplicaciones P2P

5.1 Mensajería instantánea Las aplicaciones de Chat son comúnmente consideradas como P2P, porque cada nodo interactúa directamente con otro. Las implementaciones que se pueden encontrar varían considerablemente, según el modelo de negocio que tengan asociado. Las más populares son MSN Messenger, Yahoo!Messenger, ICQ y AOL Instant Messenger. Hoy en día, los chats son utilizados tanto por consumidores como por profesionales y provee una comunicación en tiempo real que a menudo es más apropiada que el correo electrónico, las llamadas de teléfono… Las soluciones más conocidas de chat hacen uso de una implementación centralizada. Todas las interacciones son dirigidas hacia uno o más servidores centrales que proveen un directorio actualizado de todos los miembros y dirige adecuadamente los mensajes. Estas implementaciones no son muy escalables y requieren de centros de datos muy grandes para soportar un gran número de usuarios.

5.2 Telefonía P2P Skype: es una red de telefonía entre pares por Internet, fundada por los creadores de Kazaa. El código y protocolo de Skype permanecen cerrados y propietarios, pero los

Aplicaciones P2P

En paralelo Gestión de ficheros y contenidos

Colaborativas

Componentes

Cálculo Intensivo

Intercambio de contenidos

Sistemas de ficheros

Juegos

Mensajería instantánea

Aplicaciones compartidas

Telefonía

Televisión P2P


13

usuarios interesados pueden descargar gratuitamente la aplicación del sitio oficial. Los usuarios de Skype pueden hablar entre ellos gratuitamente. La aplicación también incluye una característica denominada SkypeOut que permite a los usuarios llamar a teléfonos convencionales, cobrándoseles diversas tarifas según el país de destino. Otra opción que te brinda Skype es SkypeIn, gracias al cual te otorgan un número de teléfono para que desde un aparato telefónico en cualquier parte del mundo puedan contactarte a tu ordenador. La interfaz de Skype es muy parecida a otros software de mensajería instantánea tales como MSN Messenger o Yahoo! Messenger, y de igual forma que en éstos es posible entablar una conversación de mensajes instantáneos con los usuarios del mismo software. Skype utiliza, como se ha comentando, un protocolo propietario cuyo éxito reside en la gran compresión que realiza sin afectar prácticamente a la calidad de la transmisión de voz. Skype ha logrado aprovechar exitosamente todos los recursos disponibles en una red; lo que ha permitido elevar el porcentaje de concreción de llamadas y la calidad de la red de Skype a niveles que superan los alcanzados por el sistema telefónico básico (POTS, por su sigla en inglés). Todo esto se logró sin la necesidad de costosos recursos centralizados.

5.3 Aplicaciones colaborativas Otra aplicación típica P2P es la utilizada, por ejemplo, en el desarrollo de proyectos en los que uno o más colaboradores estuvieran trabajando sobre los mismos ficheros al mismo tiempo en distintas localizaciones. Debería existir un servidor en el que se almacenase la última versión de cada fichero, y donde los distintos clientes (programadores) pudieran obtener esta última versión y subir modificaciones de estos ficheros (una vez que las modificaciones fuesen definitivas), de forma que otros programadores puedan obtener la nueva versión.

5.4 Juegos Resulta un área muy atractiva para el P2P, debido entre otros aspectos a que:

• El tráfico de mensajes generado por los juegos es normalmente bien gestionado por las redes P2P.

• P2P permite para un mayor control del juego la existencia de un servidor central que soporte a todos los jugadores.

• Los diseñadores de juegos tienden en menor medida a hacer que un gran número de jugadores dependan de un servidor centralizado.

5.5 Televisión P2P

El planteamiento de la televisión P2P es muy parecido al de programas como Bittorrent. Un emisor inicial distribuye un canal a través de internet y a su vez las personas que conectan con él para verlo lo redistribuyen entre otros nodos de la red. Existen varias aplicaciones que difunden televisión a través de este sistema, como, por ejemplo,


14

Coolstreaming que es ampliamente difundido entre los internautas, a pesar de encontrarse en un estado beta. Al contrario que otros sistemas de retransmisión de video a través de Internet, Coolstreaming funciona mejor cuanta más gente intente ver el mismo canal, ya que cada una de estas personas aumenta el caudal de transmisión con su línea, y además no se sobrecargan los servidores. Como ocurre en Bittorrent, Coolstreaming funciona mejor cuanto más tiempo lleve el usuario conectado.

5.6 Compartición de ficheros Las aplicaciones de compartición de archivos generan una gran controversia en el mundo P2P. Las aplicaciones como Emule, Kazaa y anteriormente Napster, son muy utilizadas para el intercambio de ficheros. En caso de material con copyright, la legitimidad del material divulgado está en entredicho por algunas personas. Una característica del P2P es que la información tiende a ser distribuida de una manera orgánica, provocando que su control sea difícil. En el caso del material con derechos de autor, esto aumenta el problema pues el material puede ser copiado de una forma rápida. Por otra parte, este fenómeno tiene la ventaja de que el contenido poco a poco llega a tener mayor disponibilidad. Varios proyectos, como el OceanStore(UCB) y LOCKSS( Lots of Copies Keeps Staff Safe-Stanford) poseen la ventaja precisamente en esta característica a la hora de crear una red de gran disponibilidad, como un almacén persistente de datos. Las aplicaciones actuales de compartición de archivos varían en sus implementaciones: Edonkey 2000: es una red basada en el protocolo del mismo nombre y ha sido una de las redes más populares. Su nombre viene del primer cliente, actualmente muy poco usado. Dejó de prestar servicio en Septiembre de 2005. Para su funcionamiento utilizaba una serie de servidores para interconectar clientes. Además, dividía los ficheros en partes para aquellos ficheros cuyo tamaño sobrepasara los 9,28 .Cada parte tenía su propio hash (MD4). Se identificaba cada fichero por su código hash del fichero completo, para identificarlo de forma única independientemente del nombre que tenga. Hacía uso de enlaces, que conducen a un único archivo gracias al hash (MD4) que lo tiene identificado sin ambigüedad, lo que evita el problema de archivos falsos. La división de archivos en partes permitía a su vez compartir el fichero antes de que estuviera completo. BitTorrent: Es una red para compartir ficheros de gran tamaño optimizando el uso del ancho de banda. Fue creado por Bram Cohen y estrenado en 2002. La aplicación fue escrita en Python y publicada bajo la licencia MIT. Pretendía crear un mecanismo eficiente para distribuir un mismo fichero a un gran número de personas. Su funcionamiento es similar a eDonkey2000, aunque éste hace un uso más ineficiente del ancho de banda ya que los usuarios eDonkey comparten y descargan mayor cantidad de ficheros y eDonkey no premia a los que comparten mayor ancho de banda Más concretamente, divide ficheros en fragmentos de 256KB. Para iniciar una transferencia se crea un fichero .torrent y se abre en el cliente. El fichero contiene:

• nombre del fichero a transferir.


15

• Tamaño. • código hash de cada fragmento. • dirección de un rastreador (tracker), que es un servidor que sigue las huellas de

qué semillas y clientes hay en el enjambre. Los clientes aportan información al rastreador periódicamente y a cambio reciben información de otros clientes a los que pueden conectarse. El rastreador no está relacionado con ningún movimiento de datos y no tiene ninguna copia del archivo.

• Información para el usuario. Nota:

Existe un par que tiene una copia completa del fichero a transferir y hace de semilla (seed) cuyo papel termina cuando ha distribuido todos los fragmentos. Así, los pares que quieren descargar un mismo archivo forman un enjambre (swarm) y reciben algún fragmento enviado por la semilla y luego intercambian entre ellos las piezas que les faltan. Con objeto de mejorar la eficacia: • Se elige el peer con el que existe mejor conexión. • Se empieza descargando los fragmentos más raros (disponibles en menor

número de pares) de este modo se evitan cuellos de botella. • Los fragmentos no se descargan secuencialmente. • Cada peer empieza a servir fragmentos desde que ha descargado el primer

fragmento completo. Napster: fue la primera aplicación P2P que alcanzó popularidad. Surgió en 1999. Las transferencias de los archivos tenían lugar directamente entre dos equipos, pero Napster utilizaba servidores centrales donde se almacena la lista de equipos y los archivos que proporcionaba cada uno, con lo que no era una aplicación completamente P2P. Kazaa: es una aplicación para el intercambio de archivos entre pares que utiliza el protocolo FastTrack. Kazaa es comúnmente utilizado para intercambiar música (principalmente en formato mp3) y películas (en formato DivX). Su versión oficial puede ser descargada gratuitamente y su sustento económico es el spyware (software espía) y adware (software publicitario) instalado en forma predeterminada con el producto. El protocolo FastTrack no implementa un sistema completamente descentralizado, pues existe la figura del supernodo que permite el guiado de mensajes y el descubrimiento de contenido. Actualmente existen programas derivados de él, que permiten usar la red de Kazaa, sin necesidad de instalar los spyware y adware, como es el Kazaa Lite Resurrection o el Kazaa Lite K++. A pesar de todo, Kazaa y sus programas derivados están decayendo, y muchos de sus usuarios han pasado a programas P2P más modernos, como eMule o BitTorrent. Gnutella: es un protocolo más que un programa. Fue inventado por Nullsoft. Permite la transferencia de archivos sin la acción de un servidor central, sino de una forma totalmente distribuida. A principios del 2001, algunas variaciones del protocolo (liberadas al principio como clientes de código cerrado) mejoraron en alguna medida la escalabilidad del protocolo. En vez de tratar cada usuario como cliente y servidor, algunos usuarios pasaron a ser tratados como supernodos guiando peticiones de búsquedas y respuestas para los usuarios conectados a ellos. Existe multitud de clientes Gnutella, como Oasis, Gnucleus, Aimster, Bodetella y Cooltella.


16

eMule: es un programa para intercambio de archivos utilizando el protocolo eDonkey 2000 y la red Kademlia, publicado como software libre para sistemas Microsoft Windows. Actualmente, eMule dispone de dos redes: la red clásica basada en servidores eD2k y una red descentralizada (Kad) que no hace uso de servidores y está basada en Kademlia.

1. Red de servidores: para conectarse a esta red hay que conocer la dirección IP del servidor. Una vez conectados a un servidor, éste puede informarnos de la existencia de otros servidores. Con el fin de mantener actualizada esta lista, los servidores están conectados entre sí. Cuando un nodo se conecta a un servidor le comunica los archivos que quiere compartir. Para buscar un archivo se envía la consulta a uno o más servidores. Cada servidor responde con la lista de archivos de los que dispone. Para conocer las fuentes de un determinado archivo, se le pide esta información a uno o más servidores. Cada servidor responde con una lista de nodos que comparten el archivo solicitado. La lista de servidores que presenta eMule, puede ser actualizada, permitiendo búsquedas más precisas y extensas, encontrar servidores más rápidos, entre otras cosas.

2. La red descentralizada Kad: es una red totalmente descentralizada donde todos los nodos son iguales. Ha sido diseñada para que eMule pueda sobrevivir a una posible caída de la red de servidores. Para conectarse a esta red hay que conocer la dirección IP de otro nodo, pero es posible conectarse a partir de los nodos obtenidos de la red de servidores. Cada nodo conoce una pequeña parte de la red, de manera que el tamaño de la red puede crecer tanto como haga falta sin afectar al rendimiento. Cuando un nodo se conecta, almacena los identificadores de los archivos que quiere compartir dentro de otros nodos, escogidos en función del identificador del archivo. Cuando se quiere bajar un archivo, se localizan los nodos que lo indexan y estos nodos devuelven la lista de fuentes para este archivo concreto. La búsqueda por nombre funciona de una manera parecida, guardando el nombre del archivo dentro de otros nodos escogidos en función de cada palabra del nombre. Una búsqueda en Kad se ejecuta siempre en toda la red.

5.7 Distribución de contenido Se diferencia respecto a la compartición de archivos en que estos no son replicados por los pares. El contenido es distribuido desde un par a otro. Si se toma como ejemplo la distribución de un periódico, se observa que el beneficio clave a la solución P2P es que sólo la primera copia de un artículo necesita ser almacenado por el par. Tras ello, los pares replican el artículo entre los distintos pares. Un periódico que distribuya datos de esta forma necesita únicamente un ordenador personal de tamaño medio.

5.8 Sincronización


17

La sincronización P2P es muy similar a la distribución de contenidos, con la diferencia de que opera a un nivel más granular. Los usuarios domésticos y empresariales están acostumbramos a sincronizar datos entre distintos dispositivos, como, por ejemplo, la agenda de contactos entre el terminal móvil y el ordenador, pero la sincronización también podría emplearse para, como ejemplo, que los fabricantes de software distribuyesen los parches de aplicaciones entre sus clientes, o para que los teletrabajadores actualizasen documentos entre su ordenador doméstico y los servidores de almacenamiento de la empresa. El P2P también puede emplear la sincronización para la realización de copias de seguridad automática de datos críticos. Esto es ya ofrecido, por ejemplo, por PeerioData (http:\\www.peerio.com), que permite crear redes de almacenamiento robustas y seguras sin servidores dedicados, reduciendo así los costes de infraestructura y mantenimiento. Este tipo de aplicaciones ya está en el punto de mira de los fabricantes de software. Así, Microsoft incorporará la tecnología P2P para la distribución de contenidos y la sincronización de datos en la versión de Windows Vista.

5.9 Computación distribuida Es un modelo que permite resolver problemas de computación masiva utilizando un gran número de ordenadores organizados en racimos incrustados en la red. La aplicación más representativa y conocida de las que se llevan a cabo es el Proyecto SETI (Search for ExtraTerrestrial Intelligence, o Búsqueda de Inteligencia Extraterrestre). El proyecto SETI, trata de encontrar vida extraterrestre ya sea por medio del análisis de señales electromagnéticas capturadas en distintos radiotelescopios, o bien enviando mensajes de distintas naturalezas al espacio con la esperanza de que alguno de ellos sea contestado. Los primeros proyectos SETI surgieron bajo el patrocinio de la NASA durante los años 1970. Uno de los proyectos más famosos, SETI@Home, está siendo apoyado por millones de personas de todo el mundo mediante el uso de sus computadoras personales, que procesan la información capturada por el radiotelescopio de Arecibo, durante el período de inactividad por sus usuarios regulares. El proyecto SETI ha trascendido su carácter de computación distribuida, al diseñar y llevar a cabo un nuevo programa que se ejecuta en el ordenador del usuario, mediante el cual es posible participar en otros proyectos que requieren grandes cantidades de proceso. Este programa tomó el nombre de BOINC (Berkeley Open Infrastructure for Network Computing ), que actuando como cliente de proyectos, utiliza al proyecto SETI como uno de ellos.

5.10 Incluso una red diferente: Freenet La principal diferencia entre Freenet y la World Wide Web es que carece de cualquier estructura jerárquica u organización. Mientras que la WWW descansa sobre una espina dorsal de ordenadores controlados por lo general por gobiernos, empresas y organismos oficiales, en Freenet todos los servidores están al mismo nivel, configurando un esquema que se puede definir como de una anarquía perfecta. De la misma manera, mientras que en la Web se asigna a cada servidor un número de identificación que permite conocer en todo momento quienes son sus usuarios, los servidores de Freenet


18

son completamente anónimos. No existe ninguna manera de identificar a sus propietarios ni a sus visitantes, por lo que no se pueden recopilar datos que amenacen a nuestra intimidad. La innovación más radical de Freenet consiste en que su diseño garantiza el fracaso de cualquier intento de censura de sus contenidos. Cuando un usuario sube a un servidor de la red un documento, éste se clona y aparece simultáneamente en multitud de servidores distintos. Cualquier intento de borrar un archivo hace que el proceso de clonación se repita. El sistema fue diseñado de manera que la información almacenada en el sistema fuera encriptada y replicada a través de un gran número de computadoras anónimas cambiantes alrededor del mundo. Es muy difícil para un atacante saber qué participantes poseen un determinado archivo, ya que los contenidos de cada archivo son encriptados y también pueden ser cortados en pequeñas secciones distribuidas en diferentes computadoras. Incluso los participantes desconocen qué alojan. Además, el hecho de que los documentos se encuentren en múltiples servidores convierte a su creación en un sistema de distribución de información mucho más eficiente que la World Wide Web. El objetivo de Freenet es almacenar documentos y permitir su posterior acceso por medio de una clave asociada, como resulta hoy posible con protocolos como Http. La red es implementada utilizando un número de nodos que se intercambian mensajes entre ellos. Típicamente, una computadora huésped en la red ejecuta el software que actúa de nodo y se comunica con otros huéspedes que ejecutan el mismo software para formar una gran red distribuida de nodos entre pares. Algunos nodos serán nodos de usuarios finales, desde donde los documentos serán solicitados y presentados al usuario humano. Estos nodos se comunican entre sí y con nodos intermediarios de enrutamiento de forma idéntica.

6 Clasificación P2P

1. Si se lleva a cabo una clasificación según el grado de centralización:

• Redes P2P centralizadas: Este tipo de red P2P se basa en una arquitectura monolítica donde todas las transacciones se hacen a través de un único servidor que sirve de punto de enlace entre dos nodos, y que a la vez almacena y distribuye los nodos donde se almacenan los contenidos. Poseen una administración muy dinámica y una disposición más permanente de contenido, sin embargo, está muy limitada en la privacidad de los usuarios y en la falta de escalabilidad de un sólo servidor, además de ofrecer problemas en puntos únicos de fallo, situaciones legales y enormes costos en el mantenimiento así como el consumo de ancho de banda. Una red de este tipo reúne las siguientes características:

1. Se rige bajo un único servidor que sirve como punto de enlace entre nodos y como servidor de acceso al contenido, el cual distribuye la petición de los nodos.

2. Todas las comunicaciones (como las peticiones y encaminamientos entre nodos) dependen exclusivamente de la existencia del servidor.


19

Como ejemplo de este tipo de redes encontramos la red Napster.

• Redes P2P "puras" o totalmente descentralizadas: Las redes P2P de este tipo son las más comunes, siendo las más versátiles al no requerir de una gestión central de ningún tipo por lo que los propios usuarios actúan como nodos de esas conexiones y también como almacenes de esa información. En otras palabras, todas las comunicaciones son directamente de usuario a usuario con ayuda de un nodo (que es otro usuario) quien permite enlazar esas comunicaciones. Las redes de este tipo tienen las siguientes características:

1. Los nodos actúan como cliente y servidor. 2. No existe un servidor central que maneje las conexiones de red. 3. No hay un enrutador central que sirva como nodo y administre direcciones.

Algunos ejemplos de una red P2P "pura" son, Gnutella y Freenet. • Redes P2P híbridas, semi-centralizadas o mixtas: En este tipo de red, se produce la interacción entre un servidor central que administra los recursos de banda ancha, enrutamientos y comunicación entre nodos pero sin saber la identidad de cada nodo y sin almacenar información alguna. Puede incorporar más de un servidor que gestione los recursos compartidos, pero en caso de que el o los servidores que gestionan el servicio fallen, el grupo de nodos puede seguir en contacto a través de una conexión directa entre ellos mismos por lo que es posible seguir compartiendo y descargando más información en ausencia de estos servidores. Este tipo de P2P posee las siguientes características:

1. Tiene, al menos, un servidor central que almacena información y responde a peticiones.

2. Los nodos son responsables de hospedar la información (pues el servidor central no almacena la información), lo cual permite al servidor central reconocer los recursos que se desean compartir.

3. Las terminales de enrutamiento son direcciones usadas por el servidor, que son administradas por un sistema de índices para obtener una dirección absoluta.

Algunos ejemplos de una red P2P híbrida son Bittorrent, eDonkey2000 y Direct Connect.

7 Ventajas del P2P Las aplicaciones P2P tienen una serie de características distintivas inherentes a su naturaleza descentralizada, que hacen atractivas a los usuarios domésticos y empresariales. A modo de resumen presentamos las ventajas que toma el P2P respecto otras arquitecturas de redes:

• Mejora de la escalabilidad: reduciendo las ineficiencias, cuellos de botella y recursos desperdiciados, típicos de los sistemas centralizados. Una red P2P


20

puede contener desde 2 máquinas conectadas hasta millones, pudiendo además agruparse en comunidades interconectadas entre sí.

• Mejora de la capacidad de proceso y almacenamiento: agregando ancho de banda, capacidad de almacenamiento y ciclos de computación de los dispositivos diseminados por una red. En vez de disponer de un servidor con una limitada capacidad de proceso y almacenamiento, se pueden tener millones de usuarios, cuyas capacidades exceden miles o millones de veces la de un único servidor.

• Mayor tolerancia a fallos: permitiendo que el servicio ofrecido no se pierda debido a fallos asociados a desconexiones de nodos, caídas en la red…Si un par que presta un servicio se cae de la red, existen otros muchos que también pueden prestarlo, por lo que el servicio sigue disponible. Aumenta, por la misma razón, la redundancia de datos, puesto que puede haber varios pares que poseen dicho dato.

• Anonimato: permitiendo a los usuarios usar un servicio sin preocuparse de cuestiones legales o de otro tipo, como ataques a su intimidad o censura de la información publicada.

• No existe limitación geográfica: pares situados en zonas geográficas distantes pueden estar próximos en la red P2P.

• Fácil administración: debido a que los pares se autoadministran. • Propiedad compartida: reduciendo el coste de la posesión de los sistemas y

contenidos, así como el coste de su mantenimiento.

8 Problemas del P2P

• Diferentes redes P2P no pueden comunicarse entre sí (no es posible descarar un archivo desde un cliente Kazaa y utilizar en la misma red el MSN Messenger).

• No es posible la reconexión automática. Si una conexión cae, se debe recomenzar la descarga.

• La red está dividida: si un nodo cae, puede darse el caso de que una subred se desconecte.

• Los protocolos son muy específicos de cada aplicación.

9 Desafío y futuro del P2P Los principales problemas de la arquitectura P2P están ligados a aspectos no maduros de la tecnología. El avance del P2P dependerá del avance de los siguientes aspectos:

• Diseño y organización de los sistemas y mecanismos distribuidos de forma que sean eficientes para la obtención de datos.

• Mecanismos de localización y guiado distribuidos que permitan el acceso uniforme y disponible de los recursos correspondientes.

• Mecanismos de gestión distribuida que añadan a los recursos a los múltiples pares y satisfagan un grado de calidad de servicio extremo a extremo, y peticiones de respuesta en tiempo real.


21

• Proveer mecanismos de seguridad y confidencialidad eficientes, como la autenticación, la encriptación…

El potencial del P2P ha sido demostrado ya, y el interés mostrado por la industria es muy elevado, pero aún existen lagunas y problemas a resolver, especialmente aquellos derivados de la interoperabilidad entre sistemas. Las aplicaciones P2P, como ya se ha dicho, no pueden comunicarse fácilmente con otras aplicaciones P2P, ya que cada una de ellas posee su propio conjunto de servicios El problema se resolverá cuando la industria colabore conjuntamente en el desarrollo de estándares de interoperabilidad entre aplicaciones P2P. Se puede interpretar este conjunto básico de servicios interoperables como una capa software intermedia, llamada middleware. Con esta capa, las aplicaciones que utilicen diferentes lenguajes de programación y sean ejecutadas sobre diferentes plataformas podrían comunicarse entre sí sin obstáculos, y los desarrolladores podrían dedicarse a la creación de nuevos servicios, o en mejorar los ya existentes, en lugar de preocuparse de aspectos técnicos del P2P.

Figura 9 Estructura de capas de una aplicación P2P Precisamente esta última problemática es resuelta por el conjunto de protocolos JXTA, desarrollado por la compañía Sun Microsystems, y que ofrece al desarrollador la liberación de tareas relacionadas con la red. El protocolo JXTA será estudiado con detenimiento en un próximo apartado. Podemos predecir un gran futuro para el P2P, aunque aún haya problemas a resolver. Es importante no considerar el P2P como la solución a todos los problemas: es solamente una tecnología más, que provee de una visión no excluyente de las redes distribuidas, y su verdadero potencial se manifestará cuando las tecnologías converjan de una forma más eficiente.

CAPÍTULO 2: JXTA

1 Introducción

Como se ha comentado anteriormente, la mayoría de las soluciones P2P se solapan: ICQ provee un servicio de mensajería instantánea, y además otro de compartición de archivos. Gnutella provee compartición de archivos y permite a su vez la computación distribuida, debido a la forma en que los pares intervienen en el guiado de los mensajes a través de la red. Desgraciadamente, las aplicaciones actuales de P2P tienden a usar protocolos que son propietarios e incompatibles entre ellos, reduciendo la ventaja ofrecida por los dispositivos. Cada red forma una comunidad cerrada, completamente independiente de las otras redes e incapaz de sacar provecho de servicios de otras redes. Hasta ahora la excitación por la exploración de la tecnología P2P restó durante largo tiempo importancia a la interoperabilidad o reutilización del software. Para conseguir una rápida evolución del P2P y convertirlo en una solución madura, los desarrolladores necesitaban centrar sus esfuerzos en mejorar las aplicaciones existentes o crear otras nuevas, pero no en aspectos relativos a la red P2P. Dándose cuenta de la necesidad de una estandarización del P2P, Sun Microsystems inició el proyecto JXTA (pronunciado juxtapose o juxta) con un pequeño equipo de desarrollo bajo la guía de Hill Joy y Mike Clary, para diseñar una solución que sirviese para todo tipo de aplicaciones P2P. Seguidamente, se van a exponer los conceptos claves de JXTA y los protocolos que utiliza. Según la especificación de protocolos de JXTA,

“JXTA es un conjunto de protocolos P2P abiertos y generales que permiten a cualquier dispositivo en la red - desde un teléfono móvil a una PDA, desde un PC a un servidor- comunicarse y colaborar como pares de la misma red. Los protocolos de la red JXTA son independientes del lenguaje de programación y actualmente existen múltiples implementaciones. Los pares JXTA crean una red virtual en la que cualquier par puede interactuar con otros pares y recursos directamente incluso cuando alguno de los pares o los recursos se encuentran detrás de un cortafuegos o NAT’s o tienen diferentes métodos de transporte en red.” Es decir, JXTA consiste en un conjunto de estándares que soportan aplicaciones P2P. JXTA no es una aplicación y no define el tipo de aplicaciones que se puedan realizar. Los protocolos definidos en el estándar no están definidos rígidamente, y su funcionalidad puede extenderse para obtener necesidades específicas. La estructura lógica del proyecto se encuentra dividida en tres capas:

• Plataforma. (Platform): Equivale al núcleo del Sistema Operativo. Esta capa ofrece los servicios básicos a la capa posterior y encapsula las primitivas mínimas y esenciales comunes en toda red P2P, incluyendo pares, grupo de

Capítulo 2: JXTA Memoria

23

pares, descubrimiento, comunicación, monitorización y seguridad. Idealmente, es compartida por todos los dispositivos P2P, por lo que en teoría la interoperabilidad puede ser posible.

• Servicios (Services): Lleva a cabo las funciones de librería del Sistema

Operativo e incluye los servicios de red que no tienen porqué ser absolutamente necesarios para la red P2P, pero que sí son deseables. Encontramos servicios de indexado, búsquedas, Compartición de archivos, sistemas de almacenamiento, traducción de protocolos autenticación…

• Aplicaciones (Applications): Esta capa es equivalente al nivel de usuario en un

sistema operativo y es aquí donde se crean las aplicaciones de usuario como mensajería instantánea, control de contenidos,…

Figura 10 Arquitectura software del Proyecto JXTA Esta división en capas resulta familiar, pues es idéntica al sistema operativo estándar, que se divide en tres capas: el núcleo del sistema operativo, los servicios y las aplicaciones. Mezcla la centralización y la descentralización, buscando el término medio. JXTA acepta que ciertos servicios son mejor realizados por ciertos nodos. Aunque no sea una analogía perfecta, los servidores y clientes de correo pueden servir de ejemplo. Los servidores almacenan temporalmente los mensajes de correo y dirigen estos mensajes entre otros servidores. JXTA podría implementar la misma función, excepto por el hecho de que los correos serían distribuidos durante todo su camino de nodo en nodo usando una conjunto de nodos dedicados. JXTA añade por otra parte varios conceptos nuevos, tales como el par, el grupo de pares, la tubería y los extremos de tuberías. Así mismo, utiliza un nuevo concepto en la comunicación P2P y en el descubrimiento de anuncios, que consistirán en documentos XML que describen servicios e información disponible en la red JXTA. Además, procura prevenir la saturación del ancho de banda, incluyendo cierto control sobre los mensajes:


24

• Algunos tipos de mensajes son sólo dirigidos un número de veces. Esto impide que un mensaje alcance todos los pares. La mayoría de aplicaciones P2P trabaja sin necesidad de que todos los pares participen.

• Los datos que un par descubre son almacenados en una caché local que posibilita que no haya que repetir peticiones.

• Los datos en la red, dependiendo de su tipo, tienen un tiempo de vida que previene de la acumulación innecesaria de datos. Cuando el tiempo de vida expira, el dato es borrado.

• Los nodos de gran capacidad son usados para reducir la sobrecarga de otros nodos que tengan un bajo ancho de banda o una potencia de procesamiento inadecuada. Esto previene a los pares “débiles” con pequeño ancho de banda disponible de ser saturados por la llegada de mensajes.

• El guiado de mensajes es planeado por cada nodo para asegurar que el mejor camino es tomado para alcanzar el destino.

• El protocolo base es seleccionado según la eficiencia en la parte de la red en la que es usado. La difusión por IP es usada en redes locales para el envío de mensajes a todos los nodos con el ancho de banda de un par único, mientras que Tcp y Http son usados entre redes LAN y para la comunicación directa entre pares.

JXTA es independiente del lenguaje de programación, pues es un framework no una API. De hecho, podemos encontrar librerías en los siguientes lenguajes: C/C++, Java, Perl, Pithon, Ruby, Smalltalk…

2 Historia de JXTA El Proyecto JXTA fue ideado por los desarrolladores de Sun Microsystems, Inc. Bill Joy y Mike Clary. En el año 2001 apareció la primera versión estable de JXTA. El proyecto se encuentra en continuo desarrollo y actualmente la versión disponible en la web del proyecto (http://www.jxta.org) es la 2.4. La evolución de JXTA más espectacular se produjo desde JXTA 1 (aquellas versiones 1.*), cuya primera versión data del año 2001, a la JXTA 2 (versiones 2.*). del año 2004. JXTA 2.0 permite la implementación de nuevas funcionalidades y aumenta la escalabilidad y el rendimiento de la red JXTA. Concretamente, las mejoras más significativas de JXTA 2.0 sobre JXTA 1.0 fueron:

• Soporta Http 1.1, además del 1.0. • Permite el uso de conexiones TCP/IP bidireccionales que permiten limitar el

número de éstas. • Separa funcionalidad de transmisión y transporte. En JXTA 1.0 todos los pares

se veían involucrados en la resolución, el descubrimiento y propagación de mensajes en el grupo. En JXTA 2.0 la resolución y la propagación son llevadas a cabo mediante dos nuevos conceptos:

o Supernodo Rendezvous y servicio del caminante errante o SRDI

• Permite el descubrimiento dinámico de rendezvous y relays.


25

• Mejora sistemas de almacenamiento y distribución de índices. En JXTA 1.0 los anuncios eran almacenados en ficheros. En JXTA 2.0 se utiliza una base de datos Apache Xindice.

• Soporta conexión asíncrona entre extremos de un pipe. • Mejora asignación de recursos para disminuir consumo de memoria. • Soporta retransmisión de errores para mejorar la fiabilidad de la red.

La topología de la red a lo largo del tiempo ha sufrido una evolución, influenciada por la infraestructura externa y factores económicos que no están bajo el control directo de los diseñadores de software .JXTA 1 tomó una aproximación pura y más bien teórica de la topología de la red. En cambio, JXTA 2 tomó una aproximación significativamente más pragmática a la hora de diseñar el recubrimiento de la red, que trabajara con un rendimiento adecuado y de una manera escalable encima de la mayoría de los tipos de red que nos podemos encontrar. JXTA 2 introduce el concepto de supernodo rendezvous: máquinas que permiten manejar comunicaciones distribuidas. Una máquina JXTA debe conectarse a un par rendezvous antes de comenzar la transmisión de mensajes. La plataforma JXTA ofrece mecanismos de descubrimiento para localizar automáticamente los rendezvous. Cualquier par puede llegar a ser un rendezvous en cualquier momento. De hecho, bajo JXTA 2, un par puede llegar a ser un rendezvous automáticamente si falla al localizar un rendezvous disponible después de un tiempo configurado.

3 Objetivos de JXTA Los objetivos de JXTA son otorgar a la aplicación P2P:

1. Independencia del sistema operativo. 2. Independencia de la plataforma: uso de diferentes lenguajes, dispositivos… 3. Una infraestructura completa y servicios a aplicaciones P2P.

En esencia los objetivos de JXTA son proveer un soporte a la programación P2P en cualquier tipo de dispositivo, desde un ordenador de escritorio a una PDA. Existen a su vez varios objetivos conceptuales, entre los que se encuentran los siguientes:

1. Uso de grupos para organizar pares y dar un contexto de acción a los servicios y aplicaciones.

2. Los grupos usarán autenticación y credenciales para controlar el acceso y permitir la seguridad a nivel de grupo.

3. Distribuir información sobre los pares y los recursos de la red a través de la red. 4. Conseguir que las peticiones sean distribuidas a lo largo del sistema. 5. Proveer una infraestructura para el guiado y las comunicaciones entre los pares.

La comunicación con los pares detrás de cortafuegos y otras barreras son un concepto clave de este objetivo.

6. Proveer mecanismos que permitan a los pares monitorizar otros pares y recursos. 7. Crear un sistema que permitiese a cualquier objetivo ser añadido a la red JXTA. 8. Crear un sistema que permitiese el control centralizado de pares en ISP’s

(Proveedor de Servicios de Internet) y redes corporativas.


26

9. Crear un sistema que soportara el control de derechos digitales. Esto incentivaría el uso de JXTA para la compra de productos digitales, tales como software, música y películas. Las aplicaciones P2P de intercambio de archivos que no contaran con soporte para el manejo de derechos de autor podrían ser consideradas como conflictivas y bloqueadas por los ISP’s.

10. Encapsular y abstraer la funcionalidad específica del núcleo para aumentar la facilidad de creación de nuevas aplicaciones.

Además de estos objetivos, existen otros, tales como la encriptación, soporte para varios protocolos de comunicaciones, estabilidad y rendimiento. Todos estos fueron considerados al dar los primeros pasos los desarrolladores de JXTA. La anterior lista posee dos conceptos claves. En primer lugar, las compañías deben ser capaces de “sentir” que tienen el control: la mayoría de los sistemas P2P no tienen un control centralizado y no son bienvenidos en la mayoría de las situaciones corporativas. En segundo lugar, el sistema JXTA necesita producir ingresos para poder mantener el sistema de desarrolladores. Es preciso que además de software se creen combinaciones de software/hardware que puedan ser vendidas. Y ya que Sun Microsystems participa de igual forma en negocios de hardware, se consigue un objetivo muy importante. Dados estos objetivos, JXTA es diseñado en vistas a una futura aceptación de la industria, robustez y que pudiera ser usado para permitir prácticamente cualquier concepto imaginable en P2P. Esto le da inevitablemente una complejidad grande al sistema, de forma que la especificación se encuentra en continuo desarrollo y modificación para permitir alcanzar estas metas. La mayoría de los protocolos JXTA utilizan de una u otra forma XML. Esto es debido a la amplia aceptación que tiene XML entre los desarrolladores sin obviar por supuesto los detalles característicos de XML. La creación de un protocolo que usara un formato binario sería mucho más difícil de comprender y los posibles analizadores (parseadores) deberían ser realizados a partir de cero. Con XML, existe multitud de analizadores que pueden ser usados de forma gratuita. XML poco a poco ha llegado a ser un estándar muy utilizado en diferentes campos de la industria para la representación de datos. XML no es simplemente una forma compacta de expresar datos. Los mensajes escritos en XML son mucho más largos que el equivalente binario. Aún así existen técnicas tales como la sustitución de etiquetas por elementos binarios o datos compactos que aligeran la carga de los datos. A pesar de estas poderosas técnicas, los desarrolladores de JXTA han creado un transporte simple de mensajes binarios y han usado un conciso lenguaje de acrónimos para los nombres de las etiquetas. Desafortunadamente, esto significa que el XML usado en JXTA resulta de una difícil comprensión y lectura para el ser humano.

4 Conceptos de JXTA El concepto de P2P hace uso de una abundante terminología, por lo que se procede a explicar alguno de los conceptos claves que son críticos en la comprensión específica de JXTA.


27

Par (Peer) Un par es un punto virtual de comunicación. Es posible tener varios pares en un ordenador o dispositivo. Un par no es lo mismo que un usuario porque un usuario puede llegar a tener varios pares en su teléfono, ordenador u otro dispositivo. Por ello, es necesario que las aplicaciones permitan la idea de la existencia de un usuario en varios pares. Los pares se asocian con un servicio de red especial que proveen ellos mismos. En la referencia de la implementación, los pares pueden ofrecer servicios básicos al resto de la red, tales como el servicio de rendezvous, enrutador, puerta de enlace o una combinación de los anteriores. En general estos servicios no deben ser implementados por todos los pares, pero un porcentaje de ellos son requeridos para asegurar al resto de pares el acceso y utilización a los servicios nombrados. Nota:

Una de las razones para tener varios pares en un mismo dispositivo es para proveer servicios de Proxy a aquellos pares que son demasiado “pequeños” y no pueden llegar a ser un cliente JXTA completo (por ejemplo un teléfono móvil o cualquier otro dispositivo portátil). En cualquier caso, con el rápido avance de la tecnología móvil, estos dispositivos cada vez más desempeñan labores y ofrecen servicios antes incapaces de ello.

En la práctica se usan 4 tipos de pares:

• Par mínimo: puede enviar y recibir mensajes, pero no almacena ningún anuncio descubierto ni encamina hacia otros pares. Son pares con limitados recursos, como una PDA o teléfono móvil.

• Par completo: puede enviar y recibir mensajes, almacenar los anuncios descubiertos en una memoria caché y responder a peticiones de descubrimiento con la información almacenada. Sin embargo, no propaga ninguna petición. La mayoría de los pares que aparecen en una red JXTA son de este tipo.

• Par rendezvous: almacena índices a recursos disponibles en la red. Es explicado en detalle más adelante.

• Par relay: Permite determinar la información de encaminamiento de forma dinámica en la red. Es explicado en detalle más adelante.

Un par puede actuar como rendezvous, relay o incluso los dos a la vez. Grupo de pares (Peer Group) Un grupo de pares consiste en una agrupación de pares que permite el anuncio de

servicios específicos disponibles para los miembros del grupo. Es posible crear grupos, unirse a ellos y renovar la membresía en un grupo. Las razones por las que regular la membresía de los pares son:

• Asegurar la comunicación entre los miembros. • Otorgar de privacidad a las comunicaciones. • Se necesite cierta información de un usuario antes de aceptarlo como miembro.


28

Existe un protocolo de autenticación específico diseñado para recoger información y permitir a un grupo determinar si la información cumple los requerimientos de membresía. El grupo de pares provee un contexto para la utilización de aplicaciones y el uso de aplicaciones con otros pares del grupo. La membresía a un grupo de pares puede tomar varias formas. Si se trata de una membresía local, el servicio corre únicamente en el par que quiere ser miembro. Los recursos disponibles por la validación del par reside en el propio par. Así, este tipo de servicios permiten la unión al grupo sin conectar a ningún otro par. Los servicios de membresía ofrecidos remotamente requieren el acceso a uno o más pares del grupo al que se accede. La idea es que los pares que se encuentren en el grupo validen la inclusión de un nuevo miembro. Otra forma de entender el concepto de grupo de pares es mediante la analogía con una VPN (Red Privada Virtual). Una VPN permite a varios ordenadores la comunicación entre ellos sin permitir al resto de Internet la participación. Las VPN’s encriptan, de igual forma, las comunicaciones por lo que no es posible su comprensión. Los grupos de pares también pueden encriptar la comunicación interna y limitar el acceso a otros pares. Extremo de comunicación (Endpoint) Un extremo de la comunicación es el concepto básico para comprender el método de

direccionamiento del protocolo. Consiste en una dirección de un par que implementa un protocolo específico de comunicación. Un par puede tener múltiples extremos , por lo que puede comunicarse utilizando distintos protocolos. Nota:

La dirección a la que se hace referencia aquí no es necesariamente una dirección física, pues los extremos permiten que la dirección física cambie. Por ejemplo, utilizando DHCP la dirección IP de un dispositivo que se conecte será una dirección aleatoria cada vez.

Un ejemplo simple de un extremo es una dirección IP y un puerto. Usando estos valores un flujo podría ser abierto para comunicar el par. Sin embargo, JXTA utiliza una capa por encima de los flujos llamada tubería (pipe). En vez de conectar un flujo a una dirección (representada por el extremo), se conecta la tubería al extremo. Evidentemente se consigue así un gran beneficio pues el desarrollador no se debe preocupar de cual es la dirección real o cual sería el mejor protocolo utilizable en un determinado par. Además, existen otros servicios que encaminan o remiten el mensaje. Usando una tubería y la abstracción extremo, se provee de una gran potencia y se reduce la complejidad en la construcción de una aplicación P2P. Ya que las tuberías se conectan a través de un protocolo de comunicaciones, el extremo describe el protocolo y la información específica usada para conectarse a dicha tubería. Por tanto, el extremo puede describir como protocolo de comunicaciones cualquiera, como por ejemplo Http, Tcp o Beep. Un par puede tener uno o más extremos, y por ello, al soportar varios protocolos, puede usar el método más efectivo para cada caso específico. En otras palabras, si dos pares están tras un cortafuegos, ellos pueden comunicarse utilizando sus extremos Http. Si en


29

cambio el cortafuegos los separa, el protocolo elegido debería ser el Http ver apartado 1.2.4). Tubería (Pipe) Una tubería consiste en una conexión virtual entre pares. Normalmente, se podría pensar en establecer una comunicación P2P mediante una única conexión, pero esto no es siempre posible, pues muchos pares no pueden ser conectados directamente a causa de barreras en la red como los cortafuegos. Las tuberías se han ideado como una capa sobre los múltiples protocolos de comunicación, que permite soportar comunicaciones a través de pares que actúen como puertas de enlace. Es por ello que constituyen un componente básico de JXTA. Implementan un importante paradigma que permite a los pares la comunicación en la mayoría de las situaciones posibles en la red. Incluso si no se sabe nada acerca del par o donde se encuentra, el mecanismo de comunicación a través de la tubería es muy efectivo. La implementación Java de JXTA ofrece varios tipos de tuberías:

• Unidireccionales asíncronas: Utilizadas en comunicaciones unidireccionales. La tubería es asíncrona y los mensajes podrían llegar en desorden.

• Sincronía de petición/respuesta: Todos los mensajes enviados reciben un mensaje de reconocimiento (ACK) y son recibidos en el orden en el que fueron enviados.

• Transferencia de volumen (bulk transfer): Utilizadas para la transmisión de grandes volúmenes de datos.

• Flujo: Utilizadas para la transmisión de datos de manera eficiente en un flujo similar al del audio, video u otros flujos de datos.

• Bidireccional: Una combinación de dos tuberías asíncronas unidireccionales. • Unidireccional síncrona: Todos los mensajes enviados reciben un mensaje de

reconocimiento (ACK) y son recibidos en el orden en el que fueron enviados. • Unicast segura y fiable: Todos los mensajes reciben un mensaje de

reconocimiento y los datos son encriptados.

Existen, a su vez, dos formas distintas de direccionar una tubería:

• Punto a punto: La tubería conecta 2 pares distintos (aunque puede que en la comunicación actúen otros pares como puertas de enlace…)

• Propagación: La tubería conecta un par con múltiples pares. En la actualidad, en la implementación del protocolo se pueden encontrar la tubería unidireccional asíncrona, la tubería unicast segura y fiable y tubería bidireccional. Anuncios (Advertisement) Un anuncio es un documento XML que describe un recurso JXTA. Los anuncios cumplen los estándares para la codificación de etiquetas y contenidos y son usados para la obtención de información sobre los recursos de la red. Por ejemplo, si un par crea un grupo publicará el anuncio localmente en la red, lo que es realizado mediante multicast,


30

y en consecuencia cualquier par de su subred recibiría una copia del anuncio, además del par configurado como rendezvous si lo hubiera. JXTA estandariza anuncios para los siguientes recursos: Peer, Peer Group, Pipe, Services, Metering, Route, Content, Rendezvous, Peer endpoint, Transport. Siempre que se publica un anuncio, se hace con un tiempo de vida, de forma que al sobrepasar este tiempo es borrado del sistema. Además, el desarrollador puede crear sus propios anuncios. Nota:

La mayoría de los anuncios JXTA son codificados mediante UTF-8, que es una codificación de caracteres de longitud variable más reducida que el conjunto ofrecido por Unicode. Ya que UTF-8 es de 8 bits y Unicode utiliza 16 bits, la reducción a la mitad de bits implica un anuncio de menor tamaño. El único lugar en el que se podría pensar necesario el uso de Unicode por completo es en el cuerpo de los mensajes, y es por ello que es configurable y se pueden elegir varios métodos de codificación.

Mensajes (Messages) Los mensajes en JXTA se pueden implementar de dos formas. Se podría utilizar XML, de forma que los mensajes formarían paquetes de información que seguirían el estándar XML. Además, se podrían usar mensajes binarios más económicos en cuanto a tratamiento recibido. En la práctica, el intercambio de mensajes en JXTA es muy alto, por lo que la cantidad de mensajes intercambiados puede llegar a provocar la ineficiencia del sistema. Identificadores JXTA provee de una gran cantidad de tipos de identificadores. Todos los recursos tienen asociados un identificador. Estos identificadores “identifican” unívocamente grupos de pares, pares, tuberías, contenidos, servicios y módulos. Se presentan normalmente como URN’s (siglas en inglés de Nombre de Recurso Uniforme), que consisten en una forma de URL (siglas en inglés de Localizador Uniforme de Recurso) creada para ser persistente, independiente de la localización y que identifique un recurso. Están diseñadas para facilitar el mapeo otros espacios de nombres (que compartan las propiedades de las URN’s) al espacio URN. Son usados, entre otras cosas, como punteros a referencias, para la indexación y búsqueda de recursos. Par Rendezvous Un rendezvous es un par que procesa peticiones realizadas por otros pares. Los rendezvous disponen normalmente de más recursos que el resto de pares de la red y pueden almacenar grandes cantidades de información sobre los pares que le rodean.


31

El propósito principal en la utilización de un rendezvous es facilitar la búsqueda de

anuncios traspasando la red local del par e implementar la propagación de mensajes. En la figura siguiente se muestra la resolución de búsqueda de un anuncio.

Figura 11 Búsqueda de un anuncio Cuando un par realiza la búsqueda de un anuncio, pregunta en primer lugar a sus vecinos (aquellos que se encuentren en la misma red local).Si estos pares no poseen el recurso especificado, se demanda a un par rendezvous. Si este último no posee referencia al recurso, se demanda a los sucesivos pares rendezvous. Los pares rendezvous buscan en su caché de recursos indexados una referencia al anuncio buscado y si encuentran esta referencia, responden con un mensaje en el que especifican el par que posee este anuncio. En la figura 10 se muestra el proceso que se produce cuando un par busca cierto anuncio. La búsqueda remota comienza cuando el Par 1 demanda a sus pares vecinos (2 y 3) mediante un mensaje IP por Multicast. Se pueden producir dos situaciones:

1. El par 2 le responde mediante un mensaje Tcp que posee dicho anuncio. Se detiene la búsqueda.

2. Si los pares vecinos no poseen el anuncio, se demanda al rendezvous asociado. Como es preciso atravesar un cortafuegos, se envía mediante un mensaje Http. El par rendezvous 4 tampoco posee referencia a dicho anuncio, por lo que transmite la demanda al par rendezvous 5, que encuentra el anuncio y responde a la demanda. Esta respuesta viaja a través de la ruta que utilizó la demanda, pero en sentido contrario. Se utilizan mensajes Tcp mientras no sea preciso atravesar un cortafuegos y un mensaje Http cuando sí lo es. El mensaje de respuesta posee un campo en el que se especifica el par que posee el anuncio.


32

En esta figura se han incluido, por simplicidad las dos situaciones anteriores. Nota:

IP Multicast es un protocolo uno a varios. Es usado para enviar una copia de ciertos datos a un grupo de direcciones, alcanzando todos los extremos del grupo. Ofrece dos beneficios a las aplicaciones P2P:

1. Ya que multicast utiliza un grupo de direcciones en lugar de direcciones IP, cuando un par envía un mensaje lo puede hacer sin conocer las direcciones de los pares receptores. Así, posteriormente todos los pares de la red pueden responder al par emisor con información requerida en la petición e incluso con sus direcciones IP para una comunicación directa posterior.

2. Se reduce notablemente el ancho de banda consumido. Todos los pares son capaces de ver el mensaje enviado, sin necesidad de enviar una copia del mensaje a cada uno de ellos. Esto es muy importante al enviar grandes cantidades de datos a un grupo de pares.

Como impedimento al uso del multicast en JXTA, es preciso comentar que algunos encaminadores y cortafuegos bloquean el paso de mensajes enviados por multicast. Para estos casos, JXTA provee de otras herramientas como las que ya se han visto o se verán posteriormente (uso de otros protocolos de transporte, diferentes a Tcp). Cualquier par puede publicar un anuncio de un recurso. Esta publicación puede llevarse a cabo localmente, de forma que sólo tenga conocimiento de la publicación del anuncio el propio par y su par rendezvous asociado, o remotamente con lo que todos los pares del grupo tendrán conocimiento de la existencia del anuncio. JXTA 2.0 aporta un mecanismo de búsquedas de anuncios por el que no es necesario publicar los anuncios remotamente para que pares distintos a los mencionados puedan obtener información del anuncio publicado localmente. Para ello, al publicar un anuncio, el par utiliza SRDI (Índice de Recursos Compartidos Distribuidos), método que permite al rendezvous asociado al par que lo publica obtener un índice del anuncio, de forma que sepa en qué par se aloja. De esta forma, los índices pueden ser almacenados en el rendezvous síncronamente al publicar un nuevo anuncio o asíncronamente por el servicio SRDI cada ciertos intervalos. Además, el índice de información es redundantemente replicado a rendezvous adicionales adyacentes al RPV (Vista de Pares Rendezvous, consiste en una lista ordenada según el identificador JXTA de cada par, de todos los pares rendezvous conocidos por él, ver más adelante) en las posiciones +1 y –1 en la RPV. Esto asegura que si el rendezvous cae, la probabilidad de éxito de resolver satisfactoriamente el hash del índice durante una petición sea alto. El hecho de que los pares rendezvous cacheen un índice al recurso en lugar del propio recurso otorga a la red más fidelidad, de forma que el recurso encontrado sea con total seguridad el de última versión. Por otra parte, en una red cambiante, es difícil mantener una vista consistente de todos los pares de un grupo sin asumir grupos más pequeños o algún tipo de estructura


33

centralizada que mantenga la lista de los pares presentes. Mantener una vista consistente llega a ser incluso mas difícil si el tamaño del grupo y el número de pares aumenta (imaginemos por ejemplo una red de 100000000 pares). Mientras que la figura del par rendezvous en una empresa P2P pudiera aportar una mayor escalabilidad, en una red P2P (en la que los pares pueden llegar a ser PDA o un teléfono móvil) puede disminuir la estabilidad y aumentar la tasa de errores. Al desarrollar una red P2P no todas las entidades podrán soportar los costes extras del desarrollo de pares dedicados (superpares) para soportar la red. El factor económico así como la necesidad de un soporte propio de las redes nos conduce a una estructura completamente ad hoc permitiendo potencialmente a los pares llegar a ser un superpar. Por supuesto, ésta es la política oficial, pero cada desarrollador puede introducir variantes o amoldar la red a sus propias necesidades. En un entorno fluctuante e impredecible, el coste de mantener un índice distribuido consistente es grande: pasaríamos más tiempo actualizando los índices que cualquier otra cosa. Así, la red de pares rendezvous del grupo conforma una “red de consistencia relajada”: cada uno de ellos posee una RPV (Vista de Pares Rendezvous), que consiste, como se ha dicho anteriormente, en una lista ordenada según el identificador JXTA de cada par, de todos los pares rendezvous conocidos por él. Un rendezvous puede ser inservible si es borrado de la RPV de un par o pueden darse valores inconsistentes en la vista RPV. Para no permitir esto, cada rendezvous en la red envía periódicamente un subconjunto de sus propios pares rendezvous conocidos a un conjunto también aleatorio de rendezvous de su RPV. Así aseguramos la eventual convergencia de las distintas RPV de cada rendezvous. Cuando reciben una petición de búsqueda de cierto anuncio, utilizan una función DHT (Data Hash Table, Tabla hash de datos) que acepta como entrada el anuncio buscado y se obtiene el índice en la RPV. Con este índice se puede conocer el identificador JXTA del par rendezvous que tiene información acerca del anuncio, con lo que se puede demandar la información a éste. En caso de que ante cierta búsqueda de un anuncio no se obtengan resultados, se utiliza el llamado Algoritmo del Caminante Errante (limited-range walker): el caminante es usado para dirigir el rendezvous desde el índice dado por la DHT inicial. El caminante redirige en ambas direcciones, y mira si en la vecindad existe algún rendezvous que tenga el índice requerido. Puesto que los índices fueron repetidos en la proximidad del rendezvous original, el caminante toma ventaja por la alta probabilidad de encontrar el índice en la región vecina. Se utiliza un contador para especificar el número máximo de veces que puede redirigirse la petición. En caso de que un par se conecte, procederá a buscar algún par rendezvous: inicialmente el par chequea en su caché local si existe algún anuncio rendezvous que apunte a un rendezvous alcanzable. Cada par toma 5 anuncios de pares rendezvous e intenta establecer una conexión con ellos, hasta que uno de ellos responde. Si no se llega a establecer ninguna conexión tras un periodo (30 segundos), el par realiza una búsqueda, propagando una petición utilizando el protocolo de transporte adecuado (Tcp, Http…). Los pares rendezvous estarán escuchando y contestaran a la petición. En caso de no recibir respuesta en los 30 segundos, el par preguntará a los pares rendezvous semillas (seeding). Finalmente si ninguno es alcanzado tras 5 minutos, el par pasará a ser un par rendezvous (si tiene la credencial correcta). En cambio, si encontrase un par


34

rendezvous el par podría convertirse de nuevo en un par normal (y continuaría la búsqueda en background).

Cada grupo tiene la habilidad de definir su propio conjunto de rendezvous semilla (seeding), los cuales permiten acelerar la convergencia de la RPV, estando todos los rendezvous configurados inicialmente con una lista de estos. Los pares rendezvous semillas son usados como el último recurso cuando un par rendezvous no encuentra otros pares rendezvous para iniciar la RPV. Una vez que el par rendezvous tenga información suficiente de otros de su entorno, el par semilla es tratado como un par rendezvous normal. Si la red rendezvous es estable, la vista RPV rápidamente converge en todos los pares rendezvous permitiendo un índice de distribución consistente. Se comentan, en lo siguiente, cuatro posibles situaciones descritas en la figura siguiente para comprender mejor el funcionamiento:

Situación A: P1 publica un anuncio en su rendezvous R2 a través del servicio SDRI. Cada anuncio es indexado por SRDI usando un número predefinido de claves como el nombre del anuncio o su ID. R2 usa la función DHT para mapear el índice de un rendezvous en su vista RPV local. La vista RPV de R2 contiene los pares rendezvous del R1 al R6. Supongamos que la función DHT devuelve R5. R2 colocará el índice en R5. Para aumentar la probabilidad de encontrar el índice en la periferia de R5 (+1 -1 en la lista), y regular la potencial desaparición de R5, el índice puede también ser replicado a las listas vecinas de R5 (R4 y R6). Replicar el índice conlleva que creemos una región lógica en la vista RPV donde cada índice estará localizado. Situación B: Asumiendo que P2 busca un anuncio Anuncio1: P2 emite una petición de resolución a R3. El servicio SRDI en R3 computara la función (H(Anuncio1) ) usando la vista local de rendezvous. Si la vista RPV en R2 y R3 es la misma, la función DHT devolverá el mismo R ->R5.


35

R3 puede ahora redirigir la petición a R5 que redirigirá a su vez a P1 para responder a P2. Situación C: Imaginemos que R5 se cae, y R3 actualiza su vista para reflejar este hecho. R3 averiguará que R5 esta caído al actualizar su lista o intentar enviar un mensaje a R5. En este escenario, R3 tiene una nueva lista que contiene los pares rendezvous R1…R5. R5 ahora apunta a R6 de nuestra vista previa. Un rendezvous que falte implica un cambio en una nueva posición. Una vez recibida la demanda desde P2, R3 computara la función DHT que devolverá el nuevo R5. Como también publicamos el índice en R6 como parte de nuestra estrategia de índices replicados, también encontraremos el nuevo R5.-->Incluso con una vista RPV inconsistente somos capaces satisfactoriamente de usar el DHT. Replicar el índice en la vecindad de nuestro rendezvous inicial aumenta la habilidad de encontrar el índice incluso con un cambio en la vista. La distancia de replicación puede ser aumentada para mapas de vistas mayores. Situación D: Se observa ahora un escenario más caótico en el que la RPV sufre varios cambios consecutivos que la desestabilizan. La RPV de R3 se compone ahora de 8 rendezvous. Cuando R3 recibe la petición de P2, computa la función DHT que mapea el índice de R5. Ya que la RPV ha cambiado drásticamente, el índice no se encuentra en R5.Por ello se utiliza un mecanismo alternativo para seguir buscando el anuncio, el llamado Algoritmo del caminante errante: En el ejemplo, R5 redirige la petición hacia R4 y R6. Si R4 no tiene el índice, la redirige al siguiente par rendezvous R3. Similarmente, R6 la redirige hacia R7. Cuando el índice es encontrado en R7, la petición se redirige a P1, y el caminante detiene su actividad y pregunta a P2 si debe continuar. P2 debe entonces decidir si detenerlo o no, dependiendo de si ha recibido una respuesta o no. Par Relay Actúa como un distribuidor de mensajes entre pares, es decir, establece un puente de comunicación entre dos pares separados físicamente por un cortafuegos o un dispositivo NAT o un proxy de red. Para ello, tienen varias características:

• Soportan transferencia de mensajes multisalto. • Los mensajes JXTA contienen información de auto-enrutamiento (enrutamiento

basado en el origen). • Los relays mantienen información dinámica de enrutamiento. • Cualquier peer puede convertirse en un relay. • Permiten el descubrimiento dinámico de rutas.

En cierta forma se asemeja a un repetidor de radio. Mediante la utilización de un par relay podemos comunicar entre sí pares que utilicen distintos protocolos de transporte, o como se ha dicho, que estén separados por una “barrera” (NAT, cortafuegos, servidor Proxy). Servicios


36

Los pares cooperan, se comunican, llevan a cabo descubrimientos e invocan servicios de la red de forma que otros pares puedan utilizar esta funcionalidad ofrecida por el par. Un par puede publicar tantos servicios como pueda gestionar y los descubren a través del protocolo de descubrimiento. Los protocolos JXTA reconocen dos niveles de servicios de red:

• Servicios de pares • Servicios de grupos de pares.

Un servicio de un par es accesible sólo en el par en el que se publicó. Si el par cae, también lo hará el servicio. Múltiples instancias de un servicio pueden ejecutarse en diferentes pares, pero cada instancia publica su propio anuncio. Un servicio de un grupo está compuesto por una colección de instancias (potencialmente cooperando entre ellas) del servicio que se está ejecutando en varios miembros del grupo. Si uno de los pares cae, el servicio del grupo no se ve afectado. Este tipo de servicio es publicado como parte del anuncio del grupo. Los servicios pueden incluso estar preinstalados en un par o ser cargados desde la red. El proceso de búsqueda, descarga e instalación del servicio desde la red es similar a efectuar una búsqueda en Internet de una página web, encontrando la página y posteriormente instalando el plug-in requerido. A la hora de comenzar la ejecución del servicio, un par podría necesitar localizar una implementación apropiada para el entorno en tiempo de ejecución del par. El conjunto de protocolos JXTA definen un framework genérico para publicar y descubrir anuncios que puedan describir servicios, y estos anuncios suelen contener toda la información necesaria para invocar o instanciar el servicio. Este framework está diseñado de forma que se favorezca la interoperabilidad y sea compatible con cualquier servicio Web estándar, como WSDL (Web Services Description Language, formato XML que se utiliza para describir la interfaz pública de los servicios Web), RMI (Java Remote Method Invocation) es un mecanismo ofrecido en Java para invocar un método remotamente.)... Los servicios del núcleo de JXTA se relacionan de la siguiente manera:


37

Figura 13 Servicios del núcleo de JXTA

JXTA posee una arquitectura con características muy evidentes orientadas al servicio, pues provee de transparencia en la localización y la implementación de los servicios. De esta forma, los servicios JXTA se manifiestan en la red virtual JXTA por medio de anuncios, que todo cliente de estos anuncios puede descubrir de manera dinámica. Cuando un cliente ha descubierto un servicio en particular, puede entonces comunicarse con él a través de su tubería: se establece una comunicación bidireccional y se produce el intercambio de documentos XML, en función del protocolo definido del servicio. Por otra parte, el cliente no tiene ninguna idea de la manera en la que la implementación del servicio se ha realizado. En su actividad, una arquitectura orientada al servicio debe cumplir tres aspectos fundamentales:

• La publicación: un servicio puede ser publicado por medio de un servicio particular, una especie de repertorio, que permitirá a los clientes potenciales de encontrarlo y utilizarlo. En el caso de arquitectura de servicios Webs, el servicio UDDI(Universal Description, Discovery and Integration) es este servicio de repertorio. Para JXTA y su arquitectura sin servidor, en la que los pares son prácticamente iguales entre ellos, el servicio que implementa el protocolo de descubrimiento permite la publicación de otros servicios.

• El descubrimiento: si un cliente desea invocar un servicio en particular, debe

primero descubrirlo. Ya que el proceso es dinámico, el cliente no está ligado directamente al servicio y este último puede encontrarse en cualquier máquina: es preciso entonces utilizar el mecanismo de descubrimiento de servicios en el


38

servicio de repertorio. En el caso de servicios Web, el servicio UDDI ofrece este medio, y en JXTA se utiliza como ya se ha dicho el protocolo de descubrimiento. La selección del servicio “objetivo” puede darse por criterios como el nombre, versión, interfaces soportadas…

• Una vez que el servicio ha sido descubierto por el cliente, ambos pueden

comenzar la interacción. El cliente invoca entonces el servicio según el protocolo definido por el propio servicio. En el caso de servicios Web, esta interacción se produce mediante el intercambio de mensajes SOAP (Simple Object Access Protocol, define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML) sobre el protocolo Http, y el cliente invoca las operaciones expuestas por el servicio. EN JXTA, la interacción cliente/servicio se produce mediante el intercambio de mensajes XML bien definidos.

Por otra parte existe un conjunto de servicios puestos a disposición por JXTA, que son los publicados por ModuleSpecAdvertisement. Un ejemplo de este tipo de anuncios es una publicación de una tubería que puede ser utilizada para crear extremos de salida (output pipe) para invocar el servicio. Cada servicio JXTA es identificado de manera única por un ModuleSpecID. Módulos JXTA se ideó de forma que especificara mecanismos, y no imposiciones en la construcción de aplicaciones P2P. Para ello existe la figura del módulo: trozo de código que puede ser cargado dinámicamente e instanciado en un par para implementar un nuevo comportamiento. Las aplicaciones, los servicios y las normas de un grupo de pares son ejemplos de comportamientos que pueden ser instanciados en un par representados por un módulo. La implementación JXTA no impone o especifica qué representación de código es, de forma que pueda que sea una clase java, una librería dinámica (dll) o un script. De hecho, pueden existir múltiples implementaciones de un módulo para soportar distintos entornos de ejecución. Por tanto, los módulos proveen una abstracción que permite a los pares cargar e instanciar nuevos comportamientos (servicios de par y de grupo y aplicaciones). Como todo recurso en JXTA se representa mediante anuncios, es posible utilizar un módulo para:

• Identificar la existencia de un servicio: se utiliza el anuncio ModuleClassAdvertisement, que define la clase del servicio e informa de su existencia. La identificación es única gracias a un ModuleClassID.

• Identificar la existencia de la especificación del servicio, mediante el anuncio ModuleSpecAdvertisement que define una especificación del servicio. La identificación es única análogamente gracias al ModuleSpecID. Provee referencias a la documentación necesaria para la creación de implementaciones conformes a la especificación.

• Identificar la implementación del servicio mediante el anuncio ModuleImplAdvertisement que define una implementación de cierta especificación de un servicio dado.


39

Pueden existir múltiples especificaciones de un módulo dado, y alguna de ellas puede ser incompatible con otra. Sin embargo, todas las implementaciones de una especificación dada debe ser compatible y poder comunicarse usando el mismo protocolo.

5 Seguridad en JXTA La seguridad en las redes P2P presenta ciertas características especiales debidas al carácter distribuido del entorno, la vulnerabilidad de los enlaces (debido al multisalto), la naturaleza dinámica de los pares y la ausencia de autoridad centralizada. Los requerimientos de seguridad de JXTA son muy similares a los de los sistemas tradicionales, pero la naturaleza descentralizada de JXTA le confiere una mayor dificultad a la hora de otorgar confidencialidad, autenticación, irrefutabilidad, integridad y autorización a las transacciones. Los requerimientos de seguridad de JXTA se ven afectados por ciertas características únicas:

• JXTA da importancia al mecanismo y no a la norma. • JXTA es neutral a la criptografía o algoritmos de seguridad, de forma que no

se especifica ninguna solución, sino que se ofrece al desarrollador la posibilidad de utilizar las herramientas implementadas en el propio framework.

• JXTA puede satisfacer los requerimientos de seguridad a distintos niveles del sistema, para permitir la flexibilidad y la redundancia.

En general, JXTA será independiente de la solución adoptada para cumplir estos objetivos de seguridad, aunque el framework otorga herramientas que el desarrollador puede utilizar (credenciales, certificados, claves públicas, herramientas de encriptación, de redundancia…).

6 Protocolos de JXTA Los protocolos JXTA son un conjunto de seis protocolos que han sido específicamente diseñados para redes ad-hoc multisalto. Mediante el uso de estos protocolos los pares pueden cooperar, autoorganizarse y autoconfigurarse como grupos y todo esto independientemente de sus posiciones en la red (pares normales, cortafuegos, traductores de direcciones de red, espacios públicos o privados de direcciones…) sin la necesidad del control que ofrecería una infraestructura centralizada. Están diseñados para permitir a los pares anunciar sus propios recursos (servicios, tuberías…) y descubrir otros disponibles en la red por otros pares. Los pares conforman grupos y de esta forma establecen relaciones de “amistad” especiales entre ellos y cooperan , y guían los mensajes permitiendo la conectividad de cualquier par. De igual forma, permiten a los pares comunicarse entre ellos sin la necesidad de comprender la complejidad y el dinamismo de la topología de la red, lo que es cada vez más usual. Permiten a los pares dirigir dinámicamente mensajes a lo largo de múltiples saltos en la red hacia cualquier destino. Cada uno de estos mensajes lleva incluso una lista completa o parcial de los pares que han sido intermediarios a lo largo del camino hasta el destino. Las rutas


40

empleadas en este guiado de los mensajes son escogidas por ser especialmente cortas o por optimizar el traslado del mensaje. Los protocolos JXTA son asíncronos y están basados en el modelo petición/respuesta. Un par JXTA usa un protocolo para enviar una petición a uno o más pares de su grupo, y puede recibir cero, una o más respuestas a su petición. Por otra parte, no es obligatorio que un par implemente todos los protocolos. Son los siguientes:

• Peer Resolver Protocol (PRP) es el mecanismo por el cual un par puede enviar una petición a uno o más pares, y recibir una o varias respuestas a esta petición. Se controla que el mensaje respuesta sea el correspondiente al de petición mediante el uso de un identificador único incluido en el cuerpo del mensaje. Las peticiones pueden ser dirigidas al grupo completo o a pares específicos de éste.

• Endpoint Routing Protocol (ERP) es el mecanismo por el cual un par puede

descubrir una ruta (secuencia de saltos) usada para enviar un mensaje a otro par. Si un par “A” quiere enviar un mensaje al par “C”, “A” necesita encontrar los pares intermedios que guiarán el mensaje hasta “C”. ERP es usado para determinar la información de la ruta. Si la topología de la red se ve modificada, provoca una ruta no disponible, por lo que los pares deben utilizar ERP para encontrar una ruta alternativa.

• Peer Discovery Protocol (PDP) es el mecanismo por el cual un par puede

anunciar sus propios recursos y descubrir otros recursos de otros pares (grupos, Servicios, tuberías, pares…). Cada recurso del par es descrito y publicado usando un anuncio, cada uno de los cuales consistirá en un documento XML.

• Rendezvous Protocol (RVP) es el mecanismo por el cual los pares se suscriben

o al servicio de propagación. En un grupo de pares, los pares pueden ser rendezvous o no serlo. El RVP permite a un par enviar mensajes para buscar instancias del servicio. Es utilizado por el PRP y por el PBP para propagar mensajes.

• Peer Information Protocol (PIP) es el mecanismo por el cual un par puede

obtener información de estado de otros pares. Esto incluye, entre otra información, estado, carga de tráfico y capacidades.

• Pipe Binding Protocol (PBP) es el mecanismo por el cual un par puede

establecer un canal virtual de comunicación o tubería con uno o más pares, mediante el enlace de dos o más extremos de la conexión (pipe endpoints).

PRP y ERP están definidos como protocolos del núcleo de JXTA. Los restantes son protocolos estándar.

6.1 Protocolos del núcleo de JXTA


41

6.1.1 Peer Resolver Protocol (PRP)

El PRP provee un interfaz genérico de petición/respuesta que servicios y aplicaciones pueden utilizar. De esta forma provee la habilidad de realizar peticiones en un grupo de pares y más tarde comprobar si la respuesta es la correspondiente a la petición. Cada petición o respuesta es direccionada a un manejador específico. El servicio Resolver de cada grupo coopera con el manejador para proveer las estrategias de guiado y otras políticas. El manejador provee la semántica específica para conocer cómo la petición es distribuida y resuelta en el grupo y cómo las respuestas a la petición son manejadas. En la mayoría de situaciones el servicio o aplicación tiene el conocimiento exacto de la topología del grupo y de cómo la petición debe ser guiada. Una petición podría ser recibida y procesada por cualquier número de pares (potencialmente todos) y es procesada según el requerimiento del manejador si éste está registrado en el par. Los pares pueden también participar en el Índice de Recursos Distribuidos (SRDI), concepto que ya se vio en el apartado 2 y que provee un mecanismo genérico que las aplicaciones y servicios JXTA pueden utilizar para indexar recursos y otros. Estos índices pueden ser usados para dirigir peticiones en la dirección apropiada y para propagar mensajes a los pares interesados en estos mensajes. El PRP no garantiza que los pares que definan un nombre de manejador de petición recibirá esa petición ni que la petición a una demanda sea realizada. Así mismo, un mensaje SRDI tampoco tiene por qué ser respondido por un par que reciba la petición. La tarea de propagar una petición al siguiente conjunto de pares es delegada al protocolo Rendevous (RVP), de forma que este servicio es responsable de determinar el conjunto de pares que deben recibir el mensaje que se ha propagado, pero nunca de repropagar automáticamente los mensajes de un mensaje entrante de propagación. La política de PRP es al siguiente: si el manejador de la petición no especifica a PRP que descarte la petición, y si el par local es un rendezvous, la petición es propagada (considerando los límites de bucle y, que se verán posteriormente). Además, si se instruyó de tal forma al manejador de la petición, una petición idéntica será emitida con el par local como en el original. Básicamente, este protocolo da las reglas para el envío de una petición genérica a un manejador (handler, equivalente a un oyente) existente, que tratará las peticiones y enviará las respuestas. Los mensajes utilizados por este protocolo son automáticamente encapsulados en mensajes de protocolos precedentes.

Mensaje de petición

El mensaje de la petición es usado para enviar una petición al manejador de peticiones de uno o más pares miembros del grupo. La petición del resolvedor es enviada como una cadena de texto al manejador específico. Esta cadena puede ser cualquier cadena que sea interpretada por el manejador elegido. Cada petición tiene un identificador único.

El esquema de la petición es el siguiente:

<xs:element name="ResolverQuery" type="jxta:ResolverQuery"/> <xs:complexType name="ResolverQuery"> <xs:sequence> <xs:element ref="jxta:Cred" minOccurs="0" />


42

<xs:element name="SrcPeerID" type="jxta:JXTAID" /> <!—Esto pudo ser extendido con una restricción del patrón --> <xs:element name="HandlerName" type="xs:string" /> <xs:element name="QueryID" type="xs:string" /> <xs:element name="HC" type="xs:unsignedInt" /> <xs:element name="Query" type="xs:anyType" /> </xs:sequence> </xs:complexType>

<jxta:Cred>

La credencial del emisor. <HandlerName>

Una cadena que especifica el destinatario de la petición. <SrcPeerID>

El identificador del par emisor (como una URN). <QueryID>

Un identificador opaco para ser usado por el emisor de la petición para comprobar las respuestas. El <QueryID> debería ser incluido en las respuestas a esta petición.

<HC> Especifica el número de saltos que la petición ha realizado. Debe incrementarse cada vez que un par redirige la petición.

<Query> Contiene la petición.

Mensaje de respuesta

Mensaje utilizado para enviar una respuesta a un mensaje de petición. Se esquema es el siguiente: <xs:element name="ResolverResponse" type="ResolverResponse"/> <xs:complexType name="ResolverResponse"> <xs:sequence> <xs:element ref="jxta:Cred" minOccurs="0"/> <xs:element name="ResPeerID" type="jxta:JXTAID" minOccurs="0" /> <xs:element name="HandlerName" type="xs:string"/> <xs:element name="QueryID" type="xs:string"/> <xs:element name="Response" type="xs:anyType"/> </xs:sequence> </xs:complexType>

<jxta:Cred>

La credencial del que responde. <HandlerName>

Especifica como manejar la respuesta. <ResPeerID>

El identificador del par que emite la respuesta (URN). <QueryID>

El identificador de la petición de la cual la actual es respuesta. <Response>

La respuesta.


43

Mensaje SRDI

Este mensaje es empleado para actualizar los índices a recursos. Se envía al manejador de uno o más pares miembros del grupo. La información útil puede ser cualquier cadena de texto interpretable por el manejador. Su esquema es el siguiente: <xs:element name="ResolverSRDI" type="jxta:ResolverSRDI"/> <xs:complexType name="ResolverSRDI"> <xs:all> <xs:element name="HandlerName" type="xs:string"/> <xs:element ref="jxta:Cred" minOccurs="0"/> <xs:element name="Payload" type="xs:anyType"/> </xs:all> </xs:complexType>

<HandlerName>

Cadena que especifica el destino del mensaje. <jxta:Cred>

Credencial del emisor. <Payload>

Contiene la información útil.

6.1.2 Endpoint Routing Protocol (ERP)

La red JXTA es ad hoc, multisalto y adaptativa por naturaleza. Las conexiones en la red pueden ser transitorias y el guiado de los mensajes no es determinista. Los pares pueden conectarse y desconectarse rápidamente, y un par sujeto a la acción de un cortafuegos puede enviar un mensaje a otro par fuera de esa acción. ERP define un conjunto de mensajes petición/respuesta que son procesados por un servicio de guiado para ayudar a los pares a guiar los mensajes hasta su destino. Cuando un par es requerido para que envíe un mensaje a un extremo determinado, mira en su caché local si conoce la ruta hasta ese par. Si la encuentra, envía una petición de resolución de la ruta a sus pares relay demandando información del rutado (un par puede tener tantos pares relays como pueda encontrar o estén configurados). Un par relay provee una infraestructura a bajo nivel para el guiado de mensajes entre dos pares. Cualquier número de pares de un grupo puede convertirse en un par relay, y ofrecer así la habilidad de cachear información de ruta, así como establecer puentes entre distintas redes físicas o lógicas. Cuando un par relay recibe una petición de rutado, si conoce la ruta demandada responde a la petición devolviendo la información requerida como una enumeración de saltos. En caso de que un par se percate de que la información de ruta que posee se encuentre obsoleta, procedería a una nueva demanda de información de ruta. El extremo del par añade información extra al mensaje enviado. Cuando un mensaje se dirige a un par, el extremo de ese par deja su traza en el mensaje. Esta traza puede ser utilizada en caso de que se detecte un bucle en la propagación, y descartar así los mensajes recurrentes. Además, esta traza es utilizada por los pares relays para almacenar información de ruta. Cualquier par puede convertirse en un par relay. Es


44

posible la implementación de guiados más inteligentes de forma que tracen rutas más óptimas que las que provee este protocolo.

Información de ruta

Es representada mediante el esquema siguiente: <xs:element name="APA" type="jxta:APA"/> <xs:complexType name ="jxta:APA"> <xs:sequence> <xs:element name="PID" minOccurs="0" type="jxta:JXTAID"/> <xs:element name="EA" type="jxta:JXTAID" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="RA" type="jxta:RA"/> <xs:complexType name ="jxta:RA"> <xs:sequence> <xs:element name="DstPID" minOccurs="0" type="jxta:JXTAID"/> <xs:element name="Dst"> <xs:sequence> <xs:element ref="jxta:APA" maxOccurs="1"/> </xs:sequence> </xs:element> <xs:element name="Hops" minOccurs="0"> <xs:sequence> <xs:element ref="jxta:APA" maxOccurs="unbounded"/> </xs:sequence> </xs:element> </xs:sequence> </xs:complexType>

<PID>

El identificador del par poseedor de este anuncio. Si en el contexto del anuncio se conoce ya este identificador, no se incluye este campo.

<EA> Dirección del extremo del par.

<DstPID>

El identificador del par de destino descrito por el anuncio. Si en el contexto del anuncio se conoce ya este identificador, no se incluye este campo.

<Dst> Contiene un anuncio del punto de acceso conteniendo una lista de las direcciones de los extremos asociados con el identificador del par de destino.

<Hops> Una colección semi-ordenada de anuncios de puntos de acceso en la que se describe la ruta al par indicado <DstPID>. Los pasos individuales de la ruta son mezclados con alternativas a la ruta.

El parámetro TTL (Time To Live) es medido en saltos del mensaje entre pares y especifica los saltos que se han de dar hasta completar la ruta. Las puertas de enlace son definidas como una secuencia de identificadores de pares que definen la ruta desde el par emisor al par destino. La secuencia puede no estar completa, pero al menos la


45

primera puerta de enlace debe estar presente, pues es suficiente para guiar adecuadamente los mensajes. Son los pares configurados como relay quienes cachean la información de guiado.

Mensaje de petición de rutado

Este mensaje es enviado por los pares para pedir información de cierta ruta a otro par. El esquema de una petición de rutado hasta un extremo es el siguiente: <xs:element name="ERQ" type="jxta:ERQ"/> <xs:complexType name ="jxta:ERQ"> <xs:sequence> <xs:element name="Dst" type="jxta:JXTAID"/> <xs:element name="Src"> <xs:element ref="jxta:RA"/> </xs:element> </xs:sequence> </xs:complexType>

<Dst>

EL identificador del par del par cuya ruta se demanda. <Src>

EL anuncio de la ruta del par que peticiona la ruta. Es necesario para comprobar que la respuesta se corresponde a la petición realizada.

Mensaje de respuesta de guiado

Es enviado por los pares en respuesta a una petición de guiado. Contiene un anuncio de ruta para el par de destino. El esquema que utiliza es el siguiente: <xs:element name="ERR" type="jxta:ERR"/> <xs:complexType name ="jxta:ERR"> <xs:sequence> <xs:element name="Dst"> <xs:element ref="jxta:RA"/> </xs:element> <xs:element name="Src"> <xs:element ref="jxta:RA"/> </xs:element> </xs:sequence> </xs:complexType>

<Dst>

El anuncio de la ruta para el par que peticionó la información. <Src>

El anuncio de la ruta para el par de destino.

6.2 Protocolos estándares de JXTA


46

6.2.1 Peer Discovery Protocol (PDP)

El PDP ofrece las reglas de comunicación para el descubrimiento de pares distantes y para la respuesta de tales demandas. Es utilizado para descubrir cualquier recurso publicado (cada uno de ellos representado por un anuncio). Es el protocolo por defecto de todos los grupos definidos por usuarios y por el grupo principal de JXTA (World Peergroup). PDP se usa para proveer una infraestructura básica de descubrimiento para los servicios JXTA y a aplicaciones de mayor nivel, de forma que estos niveles más altos, incluido el nivel de aplicación, puedan participar directamente en el proceso de búsqueda. Los servicios JXTA deberían añadir mejoras al servicio básico, como por ejemplo escoger qué anuncios son susceptibles de ser almacenados en la caché. Funciona como una instancia del PRP. El PDP no garantiza que los pares que reciban la petición responderán a ésta ni que el número de anuncios que recibirá será el indicado. El responder a una demanda de descubrimiento es opcional. Y también es opcional el uso de un transporte fiable en PDP. Además, un par podría recibir mensajes de respuesta a la petición que no estén asociados a ninguna petición anterior. La tarea de propagación y repropagación de una petición al siguiente conjunto de pares es delegada al servicio Resolver.

Mensaje de petición de descubrimiento

Este mensaje es utilizado para enviar peticiones de descubrimientos durante la búsqueda de anuncios. Su esquema es el siguiente: <xs:element name="DiscoveryQuery" type="jxta:DiscoveryQuery"/> <xsd:simpleType name="DiscoveryQueryType"> <xsd:restriction base="xsd:string">  <xsd:enumeration value="0"/>  <xsd:enumeration value="1"/>  <xsd:enumeration value="2"/> </xsd:restriction> </xsd:simpleType> <xs:complexType name="DiscoveryQuery"> <xs:sequence> <xs:element name="Type" type="jxta:DiscoveryQueryType"/> <xs:element name="Threshold" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="Attr" type="xs:string" minOccurs="0"/> <xs:element name="Value" type="xs:string" minOccurs="0"/> <!—- El siguiente debería referirse a un anuncio de un par, pero en cambio es un documento completo por razones históricas. --> <xs:element name="PeerAdv" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType>

<Type>

Sólo los anuncios de cierto tipo requerido serán aceptados. Los valores posibles son:


47

0 � Anuncio de par 1 � Anuncio de grupo 2 � Cualquier anuncio

<Threshold> Especifica el número máximo de anuncios que aquel par que responda a la petición debe proveer. En número total dependerá del número de pares que respondan y de los anuncios que posean. Si <Type> es 0 y <Threshold> es 0, entonces la petición tiene un significado especial: su objetivo es obtener los anuncios de par de aquellos que respondan. Por tanto, todos los pares que reciban la petición deberían en tal caso responder, aunque no se incluyan resultados en la respuesta.

<PeerAdv> Si está presente, el anuncio del demandante.

<Attribute>, <Value> Pueden estar ambos presentes o no. Si no lo están, cada par que responda debe proveer un conjunto aleatorio de anuncios del tipo apropiado y considerando el valor de <Threshold>. Sólo los anuncios que contengan un elemento cuyo valor se corresponda al de <Attribute> y que sea igual el valor de <Value> serán enviados en la respuesta. <Value> puede comenzar y/o finalizar con "*". En tal caso, <Value> comprobará todos los valores que contengan el resto de la cadena (exceptuando "*").

Mensaje de respuesta del descubrimiento

Es utilizado para responder a una petición de descubrimiento. Su esquema es el siguiente: <xs:element name="DiscoveryResponse" type="jxta:DiscoveryResponse"/> <xs:complexType name="DiscoveryResponse"> <xs:sequence> <xs:element name="Type" type="jxta:DiscoveryQueryType"/> <xs:element name="Count" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="Attr" type="xs:string" minOccurs="0"/> <xs:element name="Value" type="xs:string" minOccurs="0"/> <!—- El siguiente debería referirse a un anuncio de un par, pero en cambio es un documento completo por razones históricas. --> <xs:element name="PeerAdv" minOccurs="0"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string">

<xs:attribute name="Expiration" type="xs:unsignedLong"/>

</xs:extension> </xs:simpleContent> </xs:complexType> </xs:entry> <xs:element name="Response" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="Expiration" type="xs:unsignedLong"/> </xs:extension> </xs:simpleContent>


48

</xs:complexType> </xs:entry> </xs:sequence> </xs:complexType>

<Type>

El tipo de todos los anuncios devueltos en el elemento <Response>. <Count>

Si está presente, indica el número de elementos <Response> incluidos en esta respuesta.

<PeerAdv> Si está presente, es el anuncio del par que responde. El atributo <Expiration> está asociado al tiempo relativo de expiración en milisegundos.

<Attribute>, <Value> Si está presente, refleja la petición de descubrimiento de la que es respuesta.

<Response> Un anuncio de respuesta. El atributo <Expiration> está asociado al tiempo relativo de expiración en milisegundos.

6.2.2 Protocolo Rendezvous (RVP)

Se encarga de la propagación de mensajes en un grupo de una forma optimizada y controlada. Para ello, deben existir ciertos pares que acepten soportar una carga de trabajo extra, los llamados pares rendezvous, explicados en el apartado 4 de este mismo capítulo. Como se vio anteriormente, estos pares trabajan conjuntamente para formar una Vista de Pares Rendezvous (RPV), que es una lista de los pares rendezvous conocidos actualmente por éste. Esta lista se estructura de tal forma que los pares rendezvous serán capaces de dirigir mensajes en el grupo de una manera consistente sin la necesidad de una coordinación centralizada. El protocolo Rendezvous se divide, a su vez, en tres protocolos:

- Un protocolo de control (Vista de pares). - Un protocolo de registro de la conexión. - Un protocolo usado para la propagación de mensajes transmitidos.

El protocolo de control de la vista de pares es opcional y se utiliza para verificar la integridad de la vista de pares. Cada par rendezvous mantiene su propia lista local e intercambia mensajes con otros rendezvous manteniendo una lista más o menos consistente (apartado 2.4). El protocolo Rendezvous Lease es, además, opcional y permite a los pares no rendezvous suscribirse a la recepción de mensajes propagados. Durante la actividad del protocolo, el par rendezvous aceptará mensajes del par suscriptor para facilitar la propagación y distribuirá otros procedentes del rendezvous. Este protocolo es el único protocolo requerido por aquellos pares que utilicen el servicio rendezvous. Permite determinar la fuente de los mensajes propagados, los pares por los que el mensaje ha pasado, el nombre del oyente al que está dirigido el mensaje y la distancia que falta hasta que el mensaje expire. Se base en el protocolo ERP.


49

Anuncio de rendezvous

Un anuncio de un par rendezvous describe el hecho de que dicho par actúe como rendezvous en un determinado grupo. Estos anuncios son publicados de forma que otros pares puedan encontrarlos. Su esquema es el siguiente: <xs:element name="RdvAdvertisement" type="jxta:RdvAdvertisement"/> <xs:complexType name="RdvAdvertisement"> <xs:sequence> <xs:element name="RdvGroupId" type="jxta:JXTAID"/> <xs:element name="RdvPeerId" type="jxta:JXTAID"/> <xs:element name="RdvServiceName" type="xs:string"/> <xs:element name="Name" type="xs:string" minoccurs="0"/> <xs:element name="RdvRoute" type="xs:anyType" minOccurs="0"/> </xs:sequence> </xs:complexType>

<RdvGroupId>

Elemento requerido que contiene el identificador del grupo para el cual este par es rendezvous.

<RdvPeerId> Elemento requerido que contiene el identificador del par que es rendezvous.

<RdvServiceName> Elemento requerido que identifica la vista de pares (RPV) que el par rendezvous posee.

<Name> Elemento opcional asociado con el par rendezvous y suele ser el mismo que el nombre del par.

<RdvRoute> Ruta opcional al par rendezvous. Se incluye un anuncio de ruta.

Protocolo de control de la Vista de Pares

Es utilizado para organizar ordenadamente las interacciones entre ellos mismos. La Vista de Pares es una colección de los pares participantes. Cada par rendezvous posee una versión local de la Vista de Pares y no es mantenida por ningún otro par. Cada versión local de cada par es débilmente consistente, lo que implica que no tienen por qué coincidir dos vistas de dos pares distintos. El objetivo de este protocolo es conseguir que las vistas de los pares se parezcan lo máximo posible. Los participantes intercambian mensajes entre ellos, y contendrán anuncios rendezvous de forma que se comprueben los anuncios locales con los que se han recibido y a su vez se envían los anuncios de rendezvous que se contengan. De esta forma se consigue un estado de vistas uniformes entre todos los pares rendezvous. El mensaje de Vista de Rendezvous sigue el esquema siguiente:

Elemento bandera par normal (opcional)

Espacio de nombres del elemento jxta

Nombre del elemento del mensaje PeerView.EdgePeer

Tipo Mime Media text/plain; charset=UTF-8

Contenido del elemento true


50

Elemento bandera cacheado (opcional)


Nombre del elemento del mensaje PeerView.Cached



Fallo notificación elemento bandera (opcional)


Nombre del elemento del mensaje PeerView.Failure



Elemento de prueba (opcional)


Nombre del elemento del mensaje PeerView.PeerAdv

Tipo Mime Media text/XML; charset=UTF-8

Contenido del elemento Anuncio Rdv del par que envíe el mensaje de prueba.

Elemento de respuesta (opcional)


Nombre del elemento del mensaje PeerView.PeerAdv.Response

Tipo Mime Media text/XML; charset=UTF-8

Contenido del elemento Anuncio Rdv del par que responde.

El mismo mensaje de control de Vista de Rendezvous es usado en todas las envíos, tanto de respuesta como de petición (prueba). Los posibles escenarios que se pueden encontrar son los siguientes:

Prueba par normal

Propósito

Un mensaje de prueba de un par que no es participante de la Vista de pares para conocer cuales son los participantes de la Vista de pares. El anuncio de Rdv incluido es provisto para permitir al receptor responder. La respuesta debe ser un mensaje de Vista de pares conteniendo el anuncio de Rdv de un participante aleatorio de la Vista.

Elementos EDGE, PROBE

Vía de envío

Tubería

Prueba participante

Propósito

Un mensaje de prueba de un participante en la vista a otro participante. La respuesta debe ser un mensaje de Vista de pares conteniendo el anuncio del Rdv del par correspondiente. Adicionalmente, se responde otro mensaje un anuncio Rdv aleatorio de la Vista del par que responde.

Elementos PROBE


51

Prueba participante

Vía de envío

Oyente del extremo

Respuesta participante

Propósito Un mensaje respuesta de un par participante a otro participante. El anuncio Rdv de la respuesta contiene aquel del par que responde.

Elementos RESPONSE

Respuesta referida al participante

Propósito Un mensaje respuesta de un par participante a otro participante proveyendo una referencia a otro participante. El anuncio Rdv de la respuesta no debe ser el del participante que responde ni del que solicita.

Elementos CACHED, RESPONSE

Vía de envío

Oyente del extremo

Notificación de cierre

Propósito

Un mensaje de respuesta del participante que provee la notificación de que el par que responde se está cerrando y no estará más disponible. Es un mensaje de cortesía que permite a los otros participantes actualizar más rápidamente sus vistas.

Elementos FAILURE, RESPONSE

Vía de envío

Tubería

Failure Notification

Propósito

Un mensaje de respuesta de otro participante que provee una notificación de que el par identificado ha fallado y no estará más tiempo disponible. Es un mensaje de cortesía que permite a los otros participantes actualizar más rápidamente sus vistas.

Elementos CACHED, FAILURE, RESPONSE

Vía de envío

Tubería

Protocolo de Arrendamiento (Lease) de Rendezvous

Es un protocolo especial que permite a los pares no rendezvous suscribirse a la recepción de mensajes de propagación- El suscriptor realiza una petición de arrendamiento de un par rendezvous y podría recibir un arrendamiento en respuesta (estos son de duración limitada). Durante el arrendamiento, el par rendezvous aceptará mensajes desde el suscriptor para la propagación al grupo y enviará al par rendezvous mensajes recibidos desde el grupo.

Mensaje de petición de arrendamiento (Lease)

Cuando un par quiere conectarse a un par rendezvous, envía un mensaje con un elemento llamado jxta:Connect que contendrá su anuncio de par.


52

Mensaje de Arrendamiento (Lease) otorgado

Cuando un par rendezvous otorga un arrendamiento, envía un mensaje al par que realizó la petición, conteniendo los siguientes elementos: jxta:ConnectedLease

Contiene (como cadena de texto) el tiempo en milisegundos en los que el arrendamiento tendrá lugar. Su inclusión en el mensaje es forzosa.

jxta:ConnectedPeer Contiene el identificador de par del par rendezvous que otorga el arrendamiento. Su inclusión en el mensaje es forzosa.

jxta:RdvAdvReply Contiene el anuncio del par rendezvous que otorga el arrendamiento. Su inclusión es opcional.

Mensaje de Cancelación de Arrendamiento (Lease)

Cuando un par decide cancelar un arrendamiento, envía un mensaje con el siguiente elemento:

"jxta:Disconnect": Contiene el anuncio del par que realiza la petición de cancelación. Inclusión forzosa en el mensaje.

Protocolo del Mensaje de Propagación

Los pares rendezvous propagan los mensajes que reciben. Un par puede dinámicamente llegar a ser un par rendezvous y/o dinámicamente conectarse a un rendezvous. La conexión entre un par y un rendezvous se consigue mediante una conexión explícita al par rendezvous. Esta conexión es conseguida mediante el envío de mensajes utilizando el protocolo Endpoint. Cada par rendezvous está continuamente escuchando por su dirección Endpoint mediante el servicio JxtaPropagate y el parámetro del servicio PeerGroup ID. Un conjunto de peticiones y respuestas son definidos por el protocolo rendezvous para establecer conexiones:

• LeaseRequest Esta petición es enviada por el par que desea conectarse a un par Rdv dado. No se indica la duración del arrendamiento, por lo que el rendezvous le dará aquel que estime oportuno. Una vez que el par rendezvous lo otorgue, envía LeaseGranted.

• LeaseGranted Enviado por un rendezvous al otorgar un arrendamiento. El tiempo se especifica en este mensaje.

• LeaseCancelRequest Enviado a un par rendezvous cuando el cliente desea cancelar un arrendamiento. El rendezvous debe enviar un LeaseCancelled.

Nota:

El protocolo PRP no es usado para el envío de estos mensajes, sino el ERP. La razón es que el PRP descansa sobre el propio protocolo Rendezvous.

Protocolo de control de la propagación

Este protocolo es responsable del control en la propagación de mensajes. Para ello, el par rendezvous tiene en cuenta los siguientes parámetros:


53

• Loop: Si un mensaje propagado ha sido ya procesado por el par, es descartado. • TTL: Los mensajes de propagación están asociados con un parámetro Time To

Live (TTL). Cada par que recibe un mensaje de propagación, decrementa el TTL en uno, de forma que cuando este llega a cero, el mensaje es descartado.

• Duplicate: Cada mensaje de propagación tiene asociado un valor único, de forma que si se duplica uno, y ha sido ya recibido por un par, el duplicado se descarta.

El control en la propagación se consigue mediante el uso del siguiente elemento incluido en cada mensaje: <xs:element name="RendezVousPropagateMessage" type="jxta:RendezVousPropagateMessage"/> <xs:complexType name="RendezVousPropagateMessage"> <xs:element name="MessageId" type="xs:string"/> <!—Este debería ser un subtipo obligado --> <xs:element name="DestSName" type="xs:string"/> <xs:element name="DestSParam" type="xs:string"/> <xs:element name="TTL" type="xs:unsignedInt"/> <xs:element name="Path" type="xs:anyURI" maxOccurs="unbounded"/> </xs:complexType>

6.2.3 Peer Information Protocol (PIP)

Una vez que un par esté localizado, puede ser útil obtener sus capacidades y estado. El protocolo PIP proporciona un conjunto de mensajes para obtener información de un par concreto, aunque no es obligatorio que el par responda a peticiones PIP, ya que PIP es un protocolo JXTA opcional. Está montado sobre el protocolo PRP. El mensaje de petición de PIP se envía para comprobar si un par está conectado y para obtener información sobre el par. El mensaje especifica si se desea recibir una respuesta completa (un anuncio de par) o asentimiento simple (si está conectado y el tiempo transcurrido). Es opcional el uso de un transporte fiable para los mensajes intercambiados mediante este protocolo. Es útil para la obtención de información sobre tareas de administración y monitorización de pares, servicios comerciales (destinados a facturar por tiempo de conexión por ejemplo), etc. El PIP se sitúa por encima del PRP. El elemento <QueryID> es usado para comprobar si cierta respuesta recibida es una respuesta a la petición realizada.

Obteniendo respuestas PIP

El mensaje de petición PIP provee un campo petición que puede ser usado para codificar la petición específica. PIP no obliga al formato de este campo y deja al consumidor del servicio la decisión de éste. Los servicios de alto nivel pueden utilizar este campo para ofrecer capacidades adicionales.


54

Mensaje de petición PIP

Es enviado a un par para demandar su estado actual y obtener información relevante sobre él. Una petición sin un campo definido de petición devolverá una información por defecto del par. Su esquema es el siguiente: <xs:element name="PeerInfoQueryMessage" type="jxta:PeerInfoQueryMessage"/> <xs:complexType name="PeerInfoQueryMessage"> <xs:sequence> <xs:element name="sourcePid" type="jxta:JXTAID"/> <xs:element name="targetPid" type="jxta:JXTAID"/>  <xs:element name="request" type="xs:anyType" minOccurs="0"/> </xs:sequence> </xs:complexType>

<sourcePid>

El identificador del par que realiza la petición. <targetPid>

El identificador del par al que se demanda la información. <request>

Estructura opcional de la petición.

Mensaje de respuesta PIP

El mensaje de respuesta provee información específica sobre el estado actual del par, como el tiempo de funcionamiento, mensajes entrantes y salientes, tiempo desde el último mensaje recibido, y tiempo del último mensaje enviado. Su esquema es el siguiente: <xs:element name="PeerInfoResponse" type="jxta:PeerInfoResponse"/> <xs:complexType name="PeerInfoResponseMessage"> <xs:sequence> <xs:element name="sourcePid" type="jxta:JXTAID"/> <xs:element name="targetPid" type="jxta:JXTAID"/> <xs:element name="uptime" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="timestamp" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="response" type="xs:anyType" minOccurs="0"/> <xs:element name="traffic" type="jxta:piptraffic" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="piptraffic"> <xs:sequence> <xs:element name="lastIncomingMessageAt" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="lastOutgoingMessageAt" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="in" type="jxta:piptrafficinfo" minOccurs="0"/> <xs:element name="out" type="jxta:piptrafficinfo" minOccurs="0"/> </xs:sequence> </xs:complexType>


55

<xs:complexType name="piptrafficinfo"> <xs:sequence> <xs:element name="transport" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:unsignedLong"> <xs:attribute name="Expiration" type="xs:anyURI"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:entry> </xs:sequence> </xs:complexType>

<sourcePid>

El identificador del par que realiza la petición. <targetPid>

El identificador del par al que se demanda la información. <uptime>

Tiempo relativo en milisegundos desde que el servicio de información del par comienza su ejecución. Los pares deben proveer esta etiqueta en todas sus respuestas, en caso de que la información se encuentre disponible y no existan problemas de seguridad.

<timestamp> Tiempo absoluto en milisegundos en el que se generó la respuesta, desde el 1 de Enero de 1970, 00:00:00 GMT. Los pares deben proveer esta etiqueta en todas sus respuestas, en caso de que la información se encuentre disponible y no existan problemas de seguridad.

<response> Potencialmente contiene una respuesta a una petición anterior de una petición PIP. Puede albergar cualquier contenido.

<traffic> Contiene información sobre el tráfico de la red obtenida desde el par demandado. <lastIncomingMessageAt> Tiempo absoluto en milisegundos en el que el par recibió un mensaje válido JXTA, desde el 1 de Enero de 1970, 00:00:00 GMT. Los pares deben proveer esta etiqueta en todas sus respuestas, en caso de que la información se encuentre disponible y no existan problemas de seguridad. <lastOutgoingMessageAt> Tiempo absoluto en milisegundos en el que el par envió un mensaje válido JXTA, desde el 1 de Enero de 1970, 00:00:00 GMT. Los pares deben proveer esta etiqueta en todas sus respuestas, en caso de que la información se encuentre disponible y no existan problemas de seguridad. <in>

Si está presente describe el tráfico entrante desde varios extremos endpoints. <transport> Provee el número de bytes recibidos por la dirección del extremo <out>

Contiene elementos que describen el tráfico de salida desde varios extremos de comunicación. <transport>


56

Provee el número de bytes transmitidos a través de los extremos de la comnicación.

6.2.4 Pipe Binding Protocol (PBP)

El protocolo PBP es utilizado por servicios y aplicaciones para comunicarse con los pares a través de una tubería. Se encuentra sobre el protocolo Endpoint, y utiliza varios protocolos de transporte de mensajes como Http, Tcp o TLS (Transporte Seguro de Mensajes). Cada extremo de la tubería tiene la tarea de mantener y restablecer el enlace virtual, e incluso si es necesario, buscar y enlazar con el actual punto extremo de la tubería. Una tubería puede ser considerada como una cola de mensajes abstracta referenciada por un nombre, que implementa operaciones de creación, enlace, cierre, eliminación de la tubería, y envío y recepción de mensajes a través de ella. Las tuberías implementadas pueden ser muy distintas, pero todas usan PBP para enlazar la tubería al punto extremo.

Anuncio de la tubería

El anuncio de una tubería es usado por el servicio de la tubería para crear un punto de entrada asociado y un punto de salida. Cada anuncio de tubería incluye un identificador de ésta, que es su nombre canónico. Incluye, así mismo, uno de los posible tipos de tuberías existentes:

• JxtaUnicast: Unicast, no segura y no fiable. Envío de mensajes uno a uno. Los mensajes pueden no llegar a su destino, llegar más de una vez o llegar en orden distinto al que fueron enviados.

• JxtaUnicastSecure Unicast, unicast, segura (utiliza TLS) y no fiable. Los datos son protegidos mediante una conexión virtual TLS entre los puntos extremos. Los mensajes pueden no llegar a su destino, llegar más de una vez o llegar en orden distinto al que fueron enviados, pero son encriptados mediante TLS.

• JxtaPropagate Tubería de difusión. Envío de mensajes uno a muchos. Cualquier par que tenga un punto de entrada disponible recibe el mensaje enviado.

El esquema de un anuncio de tubería es el siguiente: <xs:element name="PipeAdvertisment" type="jxta:PipeAdvertisment"/> <xs:complexType name="PipeAdvertisement"> <xs:sequence> <xs:element name="Id" type="jxta:JXTAID"/> <xs:element name="Type" type="xs:string"/> <xs:element name="Name" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType>

<Id>

Elemento que identifica unívocamente la tubería. Obligatorio. <Type>

Define el tipo de la tubería, según los vistos anteriormente. Obligatorio.


57

<Name> Nombre opcional que puede asociarse a la tubería. El nombre no tiene por qué ser único, si no es obtenido a partir de un servicio centralizado que garantice su unicidad.

Mensaje de Resolución de tubería

Para algunos tipos de tuberías (JxtaUnicast y JxtaUnicastSecure) es necesario localizar aquel par que esté escuchando en la tubería para crear un punto extremo de salida. Para estas tuberías es usado este servicio de tubería. El mismo esquema es utilizado en la petición y en la respuesta. Su esquema es el siguiente: <xs:element name="PipeResolver" type="jxta:PipeResolver"/> <xs:simpleType name="PipeResolverMsgType"> <xs:restriction base="xs:string">  <xs:enumeration value="Query"/>  <xs:enumeration value="Answer"/> </xs:restriction> </xs:simpleType> <xs:complexType name="PipeResolver"> <xs:sequence> <xs:element name="MsgType" type="jxta:PipeResolverMsgType"/> <xs:element name="PipeId" type="jxta:JXTAID"/> <xs:element name="Type" type="xs:string"/> <!—usado en la petición --> <xs:element name="Cached" minOccurs="0" default="true" type="xs:boolean"/> <xs:element name="Peer" minOccurs="0" maxOccurs="unbounded" type="jxta:JXTAID" /> <!—usado en la respuesta --> <xs:element name="Found" minOccurs="0" type="xs:boolean"/>  <xs:element name="PeerAdv" minOccurs="0" type="xs:string"/> </xs:sequence> </xs:complexType>

<MsgType>

Indica si es un mensaje de petición o de respuesta. <PipeId>

Identificiador de la tubería que se está resolviendo. <Type>

Tipo de la tubería. Debe coincidir con el valor <Type> del anuncio de la tubería. <Cached>

Si false, los pares que no tengan un punto de entrada de la tubería no deben responder, sino redirigir la petición a aquellos que piensen que tienen este extremo. Su comportamiento está obsoleto y las implementaciones deben especificarlo siempre como false.

<Peer>


58

Si el mensaje es de petición, especifica el identificador del par del único par del que se esperan respuestas (aunque la respuesta es opcional), de forma que respuestas de otros pares serán ignoradas. En mensajes de respuesta, todos los pares cuyo punto de entrada es conocido.

<Found> Indica si el punto de entrada fue encontrado en el par especificado.

<PeerAdv> El anuncio del par que resolvió el punto de entrada. Este par puede aparecer en la lista de pares <Peer>, pero no debe ser asumido.

Cabecera del mensaje por la tubería de propagación

Cada mensaje enviado por la tubería de propagación incluye un elemento que es utilizado para controlar la propagación. Este elemento es almacenado en el espacio de nombres de jxta y se llama JxtaWireHeader. Su estructura es la siguiente:

<xs:element name="JxtaWire" type="jxta:JxtaWire"/>

<xs:complexType name="jxta:JxtaWire"> <xs:sequence> <xs:element name="SrcPeer" minOccurs="0" type="jxta:JXTAID" /> <xs:element name="PipeId" type="jxta:JXTAID" /> <xs:element name="MsgId" type="xs:string" /> <xs:element name="TTL" type="xs:unsignedInt" /> <xs:element name="VisitedPeer" type="jxta:JXTAID" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType>

<SrcPeer>

El par que envió el mensaje. <PipeId>

Identificador de la tubería por la que se envió el mensaje. <MsgId>

Cada mensaje tiene un objeto asociado utilizado para la duplicación de caminos. Es generado de forma seudo-aleatoria para reducir la posibilidad de colisión.

<TTL> Cada par que reciba el mensaje decrementa en una unidad el TTL. Si llega a valer cero, entonces el mensaje no se reenvía a más pares.

<VisitedPeer> Conjunto de pares por los que ha pasado el mensaje. Los pares que redirijan el mensaje deben añadirse ellos mismos a la lista antes de propagarlo. Además, se deben preocupar de no reenviarlo a ningún par que se encuentre ya en la lista en la lista.

7 JXTA y Java JXTA es un protocolo implementado en múltiples lenguajes de programación, pero fue concebido para que lo fuera especialmente en Java. De esta forma, para que código Java pueda ejecutarse en una computadora es preciso que dicha computadora posea una máquina virtual de java (JVM) que le de el soporte necesario para ello.


59

Cada par en la implementación Java está asociado con una JVM y el escenario normal es aquel en el que existe un único par en el dispositivo. Sería posible arrancar varias JVM’s y crear así varios pares en un mismo PC, por ejemplo, pero esto es sólo viable en caso de experimentación o corrección de errores. En la práctica, para conseguir esto, es preciso arrancar las aplicaciones que instancien los pares en distintos directorios y que usen diferentes puertos de comunicación de forma que no se produzcan conflictos. La razón clave por la que es preciso utilizar distintos directorios es la existencia de una caché en el directorio de la aplicación.

8 La configuración de JXTA El desarrollador de una aplicación JXTA puede elegir utilizar una de las dos posibles formas de configuración:

• Utilizar la interfaz por defecto de JXTA. Aparece automáticamente al intentar unirse al grupo de pares por defecto (es lo primero que se debe hacer al crear una aplicación JXTA). Su aspecto es el siguiente:

Figura 14 Configurador de un par JXTA

• Otra opción es que el desarrollador cree su propia interfaz gráfica mediante la cual configure la plataforma JXTA.


60

En ambos casos, se creará un directorio llamado “.jxta” en el que se almacenará la información de la plataforma, así como posteriormente la caché originada en la aplicación. La configuración de la plataforma se almacena en un fichero llamado PlatformConfig, con formato XML y en él se guardará información acerca de la configuración de red elegida en la conexión como el tipo de par (par normal, rendezvous, relay), su nombre y contraseña…

9 La caché de JXTA El sistema de gestión de la caché es usado para almacenar información sobre la red P2P, e indexar esta información. Esta información consistirá en anuncios creados por el par o encontrados en la red durante algún descubrimiento. Este componente permite el almacenamiento, indexado y recuperación eficiente de anuncios. Obviamente, la posible existencia de cientos de pares interactuando entre ellos hace forzosa la aparición de una base de datos, pues en caso contrario los pares deberían estar constantemente reclamando información, lo cual podría sobrecargar la red. La implementación JXTA 2.0 utiliza una versión a pequeña escala del proyecto Xindice de Apache, en la que el indexado Xpath no es utilizado. Está implementado de tal forma que sea posible especificar qué campos de un anuncio deben ser indexados. A su vez, permite la persistencia de la información almacenada entre dos comienzos de la aplicación. El gestor de la caché implementa un mecanismo eficiente de recuperación de mensajes optimizando el tiempo empleado. Controla, así mismo, el deterioro de los anuncios, utilizando para ello el parámetro TTL (Time To Live) asociado a cada uno de ellos, de forma que al expirar este tiempo el anuncio es borrado de la caché. La caché se organiza en el fichero cm (cache managemenet), por debajo de la cual se encuentra un directorio por cada grupo al que el par se une. Existen dos subdirectorios de cm que son creados siempre, ya que todos los pares pertenecen a los grupos WorldPeerGroup y NetPeerGroup. Cada uno de los subdirectorios de cm almacena información sobre los anuncios descubiertos en el grupo y sobre credenciales y propiedades de pertenencia. Otro directorio que podemos encontrar por debajo de cm es el directorio HttpTransport, en el caso de que nuestro par sea una puerta de enlace Http. Se utiliza para gestionar mensajes de otros pares que usen este par como puerta. Por último, otro subdirectorio que se puede encontrar es el pse, que contendrá certificados, contraseñas de archivos y, en general, información relativa a la seguridad del par. Nota:

Xindice es un software que forma parte del proyecto ApacheXML y de la iniciativa DBXML. Permite gestionar una base de datos compuesta por documentos XML. Para efectuar las peticiones utiliza el lenguaje XPath.

CAPÍTULO 3: XML y tecnologías relacionadas

1 Introducción XML, acrónimo en inglés de eXtensible Markup Language (Lenguaje de Marcas eXtensible), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML (ver Nota). No es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Se ideó como un estándar que posibilitase el intercambio de información estructurada entre distintas plataformas. Es similar a HTML pero su función principal es describir datos y no mostrarlos como es el caso de HTML. Constituye realmente una familia de tecnologías, pues alrededor de XML 1.0 hay una creciente serie de módulos opcionales que ofrecen colecciones de etiquetas y atributos, o pautas para especificar tareas. XML es utilizado por multitud de aplicaciones, que van desde el ámbito de Internet a editores de texto, bases de datos… Actualmente, la versión más reciente de XML es la 1.0, y se encuentra en la cuarta edición de su publicación con fecha de Agosto de 2006. Nota:

SGML son las siglas de "Standard Generalized Markup Language" o "Lenguaje de Marcación Generalizado". Consiste en un sistema para la organización y etiquetado de documentos. La Organización Internacional de Estándares (ISO) normalizó este lenguaje en 1986, mediante la norma ISO 8879.El lenguaje SGML sirve para especificar las reglas de etiquetado de documentos y no impone en sí ningún conjunto de etiquetas en especial.

Las ventajas que otorga XML son las siguientes:

• Separa la semántica de los datos del modo de presentación de estos. Así mismo, permite definir el modo en el que se estructuran los datos en un documento XML por medio de las Definiciones de Tipo de Documento (DTD).

• Comunicación de datos. Si la información se transfiere en XML cualquier aplicación podría escribir un documento de texto plano con los datos que estaba

Capítulo 3: XML y tecnologías relacionadas Memoria

62

manejando en formato XML y otra aplicación podría recibir esta información y trabajar con ella.

• Migración de datos. Si se trabaja en formato XML sería muy sencillo mover datos de una base de datos a otra.

• Aplicaciones Web. Con XML existe una sola aplicación que maneja los datos y para cada navegador podemos tener una hoja de estilo o similar para aplicarle el estilo adecuado.

• Su formato (texto plano) permite la lectura del hombre bajo cualquier plataforma o herramienta.

Así pues, el XML juega un papel fundamental en la Ciencia de la Información, pues se hace necesaria una norma que permita el intercambio de información entre distintos sistemas.

2 Historia XML proviene de un lenguaje inventado por IBM en los años setenta, llamado GML (General Markup Language), que surgió por la necesidad que tenía la empresa de almacenar grandes cantidades de información. Este lenguaje fue del agrado de la ISO, por lo que en 1986 se normalizó, creando SGML (Standard General Markup Language), lenguaje capaz de adaptarse a un gran abanico de problemas. En el año 1989 se creó el lenguaje HTML que fue utilizado para la World Wide Web. HTML ha ido creciendo de una manera descontrolada, no cumpliendo todos los requisitos que pedía la sociedad global de Internet, a pesar de los esfuerzos del W3C de poner orden y establecer reglas y etiquetas para su estandarización. Esta entidad empezó en 1998 el desarrollo de XML, proceso que aún continúa. XML como sucesor de HTML HTML es simplemente un lenguaje, mientras que XML es un metalenguaje, esto es, un lenguaje para definir lenguajes. Y esa es la diferencia fundamental, de la que derivan todas las demás. HTML especifica muy poco sobre la estructura del documento y combina tipografía y contenido al mismo tiempo. Es difícil de mantener y ha sido mal utilizado, de forma que no se ha conseguido una uniformidad en su utilización. XML trata de solucionar estos problemas. XML como alternativa a SGML El XML no es ningún tipo de documento SGML, sino que es una versión abreviada de SGML optimizada para su utilización en Internet. Esto significa que con él es posible definir nuestros propios tipos de documentos (nuestras propias etiquetas). Los diseñadores de XML intentaron dejar fuera aquellas partes que raramente se utilizan, de forma que esta reducción resultó ser muy importante: la especificación XML ocupa aproximadamente 30 páginas, frente a las 500 del SGML.

Cuando XML se diseño, se decidió que:

• Debía ser fácilmente utilizable en Internet.


63

• Debía soportar una amplia variedad de aplicaciones • Debía ser compatible con SGML. • Debía ser fácil escribir programas para procesar documentos en XML. • El número de características opcionales de XML debía ser mínimo, idealmente

0. • Los documentos en XML debían ser fáciles de leer. • El diseño de XML debía ser formal y conciso. • Debía ser fácil crear documentos en XML.

3 Descripción XML Los documentos XML se componen de unidades de almacenamiento llamadas objetos o entidades (entities), que contienen datos analizados (parsed) o datos sin analizar (unparsed). Los datos analizados se componen de caracteres, algunos de los cuales forman los datos del documento (data) y el resto forman las etiquetas (markups) o marcas. Las etiquetas codifican la descripción de la estructura lógica y de almacenamiento del documento. XML proporciona un mecanismo para imponer limitaciones en la estructura lógica y de almacenamiento. Para leer los documentos XML y acceder a su contenido y estructura, se utiliza un software o programa procesador de XML. Cualquier aplicación que trabaje sobre XML necesita ese módulo o procesador XML (parser). Dicho módulo lee los documentos y proporciona acceso a su contenido y estructura.

3.1 Documentos XML Dentro de los documentos XML distinguimos dos tipos de documentos:

• Documentos bien formados: un documento XML es un documento bien formado si tiene una estructura física que cumple las normas recogidas en la especificación XML v1.0.

• Documentos válidos: un documento XML es un documento válido cuando además de ser un documento bien formado esta sujeto a un DTD.

Por otra parte, un documento aislado es aquel en el que no existen declaraciones de marcas externas al documento (DTD por ejemplo). Este valor será válido para el analizador, ya que sabe que este documento no está sujeto a marcas. Si indicamos que el documento no es aislado, estamos diciendo que ese documento puede tener declaraciones de marcas externas. Para indicar que un documento es aislado

<?XML version="1.0"standalone= ’yes’?>, y un documento no aislado

<?XML version="1.0"standalone=’no’?>


64

3.2 Descripción del meta lenguaje XML Aunque no es obligatorio los documentos XML pueden, y deberían, comenzar con una línea que describa la versión de XML, el tipo de documento y otras cosas. La primera línea del prólogo o "declaración" permite especificar la versión de XML usada, hasta el momento, sólo existe la "1.0" y la codificación de carácter (US-ASCII, UTF-8, BIG5, ISO-8850-7, etc.). En general, para el castellano, usamos UTF-7 (código Unicode del que ASCII es un subconjunto) o ISO-8859-1. Por ejemplo:

<?XML version="1.0" encoding="UTF-7" ?> <nada> Ejemplo </nada>

La segunda línea, o "declaración de tipo de documento XML", define el tipo de documento que se está creando, es decir, se define qué Declaración de Tipo de Documento (DTD - Document Type Definition) cumple y define los datos que contiene el documento XML. Por ejemplo:

� <?XML version="1.0" encoding="UTF-7" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> <html> <body bgcolor="yellow "> <p> Ejemplo </p> </body> </html>

� <?XML version="1.0" encoding="UTF-7" ?>

<!DOCTYPE ejemplo SYSTEM "http://www.ejemplos.XML/ejemplo.dtd"> <nada> Ejemplo </nada>

Un documento XML es válido si tiene asociado una DTD y el documento cumple las restricciones que la DTD expresa. Sólo puede haber un elemento raíz, en el que están contenidos todos los demás, es decir, la jerarquía de elementos XML sólo puede tener un elemento inicial. Elementos XML Los elementos XML pueden tener contenido (más elementos, caracteres o ambos a la vez), o bien ser elementos vacíos. Un elemento con contenido es, por ejemplo:

... <nombre>Jose</nombre> ...

Siempre empieza con <etiqueta> que puede contener atributos o no, y termina con </etiqueta> que debe tener el mismo nombre. Al contrario que en 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 usarán las entidades predefinidas. Por ejemplo:


65

... <nombre>Fulanito</nombre> <aviso tipo="emergencia" gravedad="mortal">Que no cunda el pánico</aviso> ...

XML, al igual que HTML permite elementos sin contenido, pero aquel elemento debe ser de la siguiente forma:

<elemento-sin-contenido/> En el siguiente ejemplo se puede apreciar lo anterior:

... <identificador DNI="23123244"/> ... <?XML version="1.0" encoding="UTF-7" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> <html> <body bgcolor="yellow "> <hr/> <p> Entre lineas </p> <hr/> </body> </html>

Atributos XML Los elementos pueden tener atributos, que son una manera de incorporar características o propiedades a los elementos de un documento. Así,

... <alumno nota="5 pelón" asistencia="Nula">Richalson</alumno> ...

En una DTD, se especifica los atributos que puede tener cada tipo de elemento, así como sus valores y tipos de valor posible. Los atributos deben estar delimitados indistintamente por comillas dobles (“) o comilla simple (‘). Por ejemplo:

... <noticia titulo="Richal O'Donnel gana el pulitzer" autor='Pepe "Porras"'> .... </noticia> ...

A veces, un elemento con contenido puede modelarse como un elemento vacío con atributos:

... <gato><nombre>Micifú</nombre><raza>Persa</raza></gato> .... <gato raza="Persa">Micifú</gato> .... <gato raza="Persa" nombre="Micifú"/> ....


66

Comentarios en XML Los comentarios pueden aparecer en cualquier punto del documento. Tienen el mismo formato que los comentarios de HTML, por lo que comienzan con "". La cadena "--" no puede aparecer dentro de un comentario. Así,

…  <gato raza="Persa" nombre="Micifú"/> ....

Entidades predefinidas En XML 1.0 se definen cinco entidades para representar caracteres especiales y que no se interpretan como marcas por el parser XML. Es decir, así podemos utilizar, por ejemplo, el carácter "<" sin que se interprete como comienzo de una etiqueta XML. Por ejemplo:

<?XML version="1.0" encoding="UTF-7" standalone='yes'?> <ejemplos> <descripcion>Lo siguiente es un ejemplo de HTML.</descripcion> <ejemplo> <HTML> <HEAD> <TITLE>Rock & Roll</TITLE> </HEAD> </ejemplo> </ejemplos>

Secciones CDATA Las secciones CDATA también permiten especificar datos, utilizando cualquier carácter, especial o no, sin que se interprete como una marca XML. La razón es que así se puede leer más fácilmente el documento XML sin tener que descifrar los códigos de las entidades. Las secciones CDATA empiezan por la cadena "<![CDATA[" y terminan con la cadena "]]>" y sólo ésta última se reconoce como marca. No se pueden anidar secciones CDATA. Así,

<?XML version="1.0" encoding="UTF-7" standalone='yes'?> <ejemplos> <descripcion>Lo siguiente es un ejemplo de HTML.</descripcion> <ejemplo> <![CDATA[ <HTML> <HEAD> <TITLE>Rock & Roll</TITLE> </HEAD> ]]> </ejemplo> </ejemplos>

ENTIDAD CARACTER

& &

< <

> >

' '

" "


67

Instrucciones de procesamiento Las instrucciones de procesamiento permiten a los documentos XML contener instrucciones para las aplicaciones, van entre <? y ?> . De esta forma: …

<?XML version="1.0"?> <?cocoon-process type="xslt"?> ....

No son parte del documento, pero deben ser pasadas a la aplicación. En el ejemplo, se le dice a Cocoon (entorno de publicación web basado en XML y en XSL) que la página XML es un XSLT (que más adelante se verá lo que es).

3.3 Sintaxis de un documento XML En un documento XML se distinguen tres aspectos claramente diferenciados:

1. Contenido. 2. Estructura. 3. Tratamiento.

En XML la estructura es fija, de igual manera que en el resto de lenguajes de marcado, mediante una sintaxis de etiquetas, con sus correspondientes cierres. Para definir la sintaxis que utiliza un documento XML existen dos métodos:

1. DTD (Document Type Definition) es un estándar que permite definir una gramática que deben cumplir nuestros documentos XML para considerarlos válidos. Una definición DTD para un documento XML específica qué elementos pueden existir en un documento XML, qué atributos pueden tener éstos, qué elementos pueden o deben aparecer contenidos en otros elementos y en qué orden. Los parsers de XML que son capaces de validar documentos con DTD leen esos documentos y el DTD asociado.

En caso de que el documento XML no cumpla los requerimientos que le impone el DTD, advertirán del error y no validarán el documento. A pesar de que DTD es un estándar que será sustituido definitivamente por XML Schema, sigue siendo muy usado, pues es más simple y compacto que XML Schema. A eso hay que añadir que las mejoras que aporta XML Schema no son necesarias para la mayoría de los usos. Con DTD se han definido multitud de dialectos de XML que son usados ampliamente en Internet, como RDF para la web semántica, MathML para documentos matemáticos, XML/EDI para intercambio de datos electrónicamente para negocio, VoiceXML para aplicaciones que se utilicen mediante voz o que hagan uso de ésta, WML para representar documentos para los navegadores de dispositivos móviles como teléfonos, etc. Los elementos de una DTD son los siguientes:

� Elementos con “contenido ELEMENT”: Un elemento tiene contenido ELEMENT, si sólo puede contener a otros elementos, opcionalmente separados por espacios en blanco.


68

� Elementos con “contenido TEXT”: Un elemento tiene contenido TEXT, si sólo puede contener texto (PCDATA = printable character data).

� Elementos con “contenido MIXED”: Un elemento tiene contenido MIXED, si puede contener texto u otros elementos.

� Elementos con “contenido EMPTY”: Un elemento tiene contenido EMPTY, si no puede contener otros elementos.

Y los atributos son los siguientes:

� CDATA: texto � NMTOKEN: “abc...z0123..9-_:.” (tipo de lista) � NMTOKENS: NMTOKEN + espacios � ID: empezar con letra � IDREF: ser un ID

Así pues, la DTD especifica la clase de documento XML. Una DTD indica sólo qué elementos, atributos, etc… tiene un documento y cómo se anidan, pero no dice nada acerca de tipos de dato. El único tipo de dato que conoce es CDATA (texto plano), por tanto, las DTDs se quedan algo cortas y cuando se necesita algo más potente y rígido, se usa un esquema XML.

2. De igual forma que las DTDs, los Schemas describen el contenido y la

estructura de la información, pero de una forma más precisa. Los esquemas indican tipos de dato, número mínimo y máximo de ocurrencias y otras características más específicas. Según la Especificación del W3C XML Schema (http://www.w3.org/XML/Schema), los esquemas expresan vocabularios compartidos que permiten a las máquinas extraer las reglas hechas por las personas. Los esquemas proveen un significado para definir la estructura, contenido y semántica de los documentos XML.

Un esquema XML (XML schema) es algo similar a un DTD, es decir, define qué elementos puede contener un documento XML, cómo están organizados, y qué atributos y de qué tipo pueden tener sus elementos, pero la utilización de schemas ofrece nuevas posibilidades en el tratamiento de los documentos. La ventaja de utilizar los schemas con respecto a los DTDs es que utilizan sintaxis de XML, al contrario que los DTDs. Además, permiten especificar los tipos de datos y son extensibles (esto es, permite crear nuevos elementos). Los elementos de un esquema son:

� 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.

Comparativa entre DTD y XML Schema


69

Las limitaciones de la DTD son las siguientes:

� Posee un lenguaje propio de escritura lo que ocasiona problemas a la hora del aprendizaje, pues no sólo hay que aprender XML, sino también conocer el lenguaje de las DTDs.

� Para el procesado del documento, las herramientas y analizadores (parsers) empleados para tratar los documentos XML deben ser capaces de procesar también las DTDs.

� No permite el uso de namespaces y estos son muy útiles ya que permiten definir elementos con igual nombre dentro del mismo contexto, siempre y cuando se anteponga un prefijo al nombre del elemento.

� Tiene una tipología para los datos del documento extremadamente limitada, pues no permite definir el que un elemento pueda ser de un tipo número, fecha, etc. sino que sólo presenta variaciones limitadas sobre cadenas.

� El mecanismo de extensión es complejo y frágil ya que está basado en sustituciones sobre cadenas y no hace explicitas las relaciones, es decir, que dos elemento que tienen definido el mismo modelo de contenido no presentan ninguna relación.

Estos problemas son superados gracias a la especificación del esquema XML, ya que permiten un lenguaje mucho más expresivo y un intercambio de información mucho más robusto. Por otra parte, un esquema XML ofrece una serie de ventajas adicionales:

� Presenta una estructura de tipos mucho más rica. En la segunda parte de la especificación del esquema XML (XML Schema Part 2: Datatypes) se definen los tipos base que se pueden emplear dentro de un esquema XML, como ejemplo se puede destacar: byte, integer, boolean, string, date, sequence, etc. Este sistema de tipos es muy adecuado para importar y exportar sistemas de bases de datos y, sobre todo, distingue los requerimientos relacionados con la representación léxica de los datos y el conjunto de información dominante y subyacente.

� Permite tipos definidos por el usuario, llamados Arquetipos. Dando un nombre a estos arquetipos, se pueden usar en distintas partes dentro del Schema.

� Es posible agrupar atributos, haciendo más comprensible el uso de un grupo de aspectos de varios elementos distintos, pero con un denominador común, que deben ir juntos en cada uno de estos elementos.

� Es posible trabajar con espacios de nombres, según la especificación (XML Schema Part 0: Primer), permitiendo validar documentos con varios espacios de nombres.

� Permite extender Arquetipos de un modo específico, es decir, permite lo que en términos de orientación a objetos se llama herencia. Considérese un esquema que extiende otro previamente hecho, se permite refinar la especificación de algún tipo de elemento para, por ejemplo, indicar que puede contener algún nuevo elemento del tipo que sea; pero dejando el resto del esquema antiguo completamente intacto.

4 Procesamiento de documentos XML desde Java


70

Que una aplicación utilice XML implica que podrá consumir documentos XML, aplicar su lógica de negocio o recuperar información y generar documentos XML resultantes. Estas tres fases pueden describirse en más detalle como:

1. Procesamiento de entrada XML: o Analizar y validar el documento fuente. o Reconocer/buscar información importante basándose en su localización o

en su etiquetado en el documento fuente. o Extraer la información importante una vez que se ha localizado. o Opcionalmente, mapear/unir la información recuperada a objetos de

negocio. 2. Manejo de lógica de negocio:

o El procesamiento real de la información de entrada resultando opcionalmente en la generación de información de salida.

3. Procesamiento de salida XML: o Construir un modelo de documento para generar con DOM, JDOM, etc.

A día de hoy, seis extensiones de la Plataforma Java permiten al desarrollador Java construir aplicaciones basadas en XML:

• Java API for XML Processing (JAXP) • Java API for XML/Java Binding (JAXB) • Long Term JavaBeans Persistence • Java API for XML Messaging (JAXM) • Java API for XML RPC (JAX RPC) • Java API for XML Registry (JAXR)

El API de Java para procesar XML es JAXP. Las tecnologías que utiliza esta plataforma para el procesado de documentos XML son principalmente:

• SAX, Simple API for XML. • DOM, Document Object Model API de W3C. • XSLT, XML Style Sheet Language Transformations de W3C. • XPath, XML Path Language de W3C. • JDOM, "Java optimized" document object model API de jdom.org.

En Java, los modelos más comunes para el procesamiento de archivos XML son SAX, DOM y JDOM. Los principales paquetes de JAXP son:

� javax.XML.parsers: contiene las clases factoría indispensables para manejar XML:

1. SAXParserFactory: proporciona un objeto SAXParser, que implementa un procesador para XML.

2. DocumentBuilderFactory: proporciona un DocumentBuilder, que construye objetos Document que cumplen con el estándar DOM.

� org.w3c.dom: define la clase Document de DOM y las clases que representan los elementos de un DOM.

� org.XML.sax: define las APIs básicas de SAX.


71

� javax.XML.transform: proporciona la API para las transformaciones XSLT.

4.1 DOM (Document Object Model) El Document Object Model (en español ‘Modelo de Objetos de Documento’), frecuentemente abreviado DOM, es una forma de representar los elementos de un documento estructurado (tal como una página web HTML o un documento XML) como objetos que tienen sus propios métodos y propiedades. El responsable del DOM es el World Wide Web Consortium (W3C). En efecto, el DOM es una API para acceder, añadir y cambiar dinámicamente contenido estructurado en documentos con lenguajes como ECMAScript (Javascript). Como un analizador SAX genera un flujo temporal de eventos, se deben hacer en un sólo ciclo los cuatro pasos de procesamiento de entrada XML descritos con anterioridad (nombrado, análisis, reconocimiento, extracción y mapeo): cada evento capturado es manejado inmediatamente y la información importante es pasada junto con el evento. Cuando se utiliza DOM, el procesamiento de la entrada XML se hace al menos en dos ciclos:

1. El análisis, donde DOM crea una estructura de datos tipo árbol que modela el documento fuente XML (árbol DOM).

2. Recorrido del árbol DOM, buscando información relevante para extraerla y procesarla posteriormente. Este último ciclo se puede repetir tantas veces como sea necesario mientras el árbol DOM exista en memoria.

4.2 SAX (Simple Api X Java) SAX procesa el documento o información en XML de una manera muy diferente a DOM, SAX procesa la información por eventos. A diferencia de DOM que genera un árbol jerárquico en memoria, SAX procesa la información en XML conforme esta sea presentada (evento por evento), efectivamente manipulando cada elemento a un determinado tiempo, sin incurrir en uso excesivo de memoria. Por lo tanto se aprecian las siguientes características:

� SAX es un procesador ideal para manipular archivos de gran tamaño, ya que no ocupa espacio en memoria como es requerido en DOM.

� Es más rápido y sencillo que utilizar DOM. � La sencillez antes mencionada tiene su precio, debido a que SAX funciona por

eventos, no es posible manipular información una vez procesada. En DOM no existe esta limitación ya que se genera el árbol jerárquico en memoria y es posible modificar elementos procesados con anterioridad.

La especificación más reciente de SAX es 2.0, y como DOM 2.0, se incluye en casi todos los "Parsers" disponibles en el mercado. Los paquetes que integran SAX son:

� org.XML.sax: define los interfaces SAX de manejo de eventos. � org.XML.sax.helpers: para crear analizadores distintos a los proporcionados por

la implementación de Sun. � javax.XML.parsers: para crear el analizador de la implementación de Sun.


72

� com.sun.XML.parser: contiene los analizadores de la implementación, con y sin validación frente a un DTD.

SAX está dirigido por eventos, de forma que su funcionamiento es, en líneas generales:

1. Se crea un analizador SAXParser con la factoría SAXParserFactory. 2. Se registra el manejador usado por la aplicación con un analizador SAX. 3. El analizador procesa el XML secuencialmente, ya que SAX sólo

implementa acceso serie. 4. Cada vez que ocurre un determinado evento, el analizador invoca una

retrollamada al manejador, que tendrá implementado un determinado comportamiento ante dichos eventos. Las interfaces DocumentHandler, ErrorHandler, DTDHandler, y EntityResolver definen los métodos que son llamados ante la ocurrencia.

4.3 JDOM ("Java optimized" document object model) A pesar de existir diversos "Parsers" para ambientes Java, las metodologías SAX y DOM no fueron diseñadas con Java en mente, con la intención de proporcionar una metodología para procesar XML más acorde con el mundo Java surgió JDOM. Aunque JDOM se encuentra en las etapas iniciales de diseño (Versión 0.x y Beta) ha causado un gran interés debido a la sencillez de procesar XML con Java comparado con DOM o SAX. JDOM son las siglas en inglés de Java Document Object Model (Documento de Modelado de Objetos en Java) es una librería para manipulaciones de datos XML optimizados para Java. A pesar de su similitud con DOM, es una alternativa como documento para modelado de objetos que no está incluido en DOM. La principal diferencia es que mientras que DOM fue creado para ser un lenguaje neutral e inicialmente usado para manipulación de páginas HTML con JavaScript, JDOM se creó específicamente para usarse con Java y por lo tanto beneficiarse de las características de Java, incluyendo sobrecarga de métodos, colecciones, etc. Para los programadores de Java, JDOM es una extensión más natural y correcta. JDOM utiliza DOM para manipular los elementos de un modelo específico. Permite así pues, construir documentos, navegar por su estructura, y añadir, modificar o suprimir elementos. La librería JDOM consiste en seis paquetes:

� org.jdom: representa un documento XML y sus componentes: Attribute, CDATA, Comment, DocType, Document, Element, EntityRef, Namespace, ProcessingInstruction, y ext, los mismos componentes que posee XML.

� org.jdom.input: contiene clases para construir documentos JDOM. Las más importantes son SAXBuilder, que crea un JDOM usando SAX a partir de tecnologías XML de un archivo o un flujo XML, y DOMBuilder, que construye desde un árbol DOM.

� org.jdom.output: contiene clases para “imprimir” un documento JDOM en un flujo de bytes o un archivo. La más importante es XMLOutputter, que posee una


73

amplia variedad de opciones de configuración. También existen clases para “imprimir” en eventos SAX, en árboles DOM, o en árboles JTree.

� org.jdom.transform: contiene clases para realizar las transformaciones XSLT. � org.jdom.xpath: contiene clases que soportan XPath. � org.jdom.adapters: para propósitos de compatibilidad, los usuarios de JDOM

no lo deben usar.

5 Tecnologías relacionadas con XML Entre las tecnologías XML disponibles se pueden destacar: XSL: Lenguaje Extensible de Hojas de Estilo, cuyo objetivo principal es mostrar cómo debería estar estructurado el contenido, cómo debería ser diseñado el contenido de origen y cómo debería ser paginado en un medio de presentación como puede ser una ventana de un navegador Web o un dispositivo de mano, o un conjunto de páginas de un catálogo, informe o libro. XSL funciona como un lenguaje avanzado para crear hojas de estilos. Es capaz de transformar, ordenar y filtrar datos XML, y darles formato basándolo en sus valores. XLink: Lenguaje de Enlace XML, es un lenguaje que permite insertar elementos en documentos XML para crear enlaces entre recursos XML. Describe un camino estándar para añadir hipervínculos en un archivo XML. Es decir, es un mecanismo de vinculación a otros documentos XML. Funciona de forma similar a un enlace en una página Web, es decir, funciona como lo haría <a href="">, sólo que a href es un enlace unidireccional. Sin embargo, XLink permite crear vínculos bidireccionales, lo que implica la posibilidad de moverse en dos direcciones. Esto facilita la obtención de información remota como recursos en lugar de simplemente como páginas Web. XPointer: Lenguaje de Direccionamiento XML, es un lenguaje que permite el acceso a la estructura interna de un documento XML, esto es, a sus elementos, atributos y contenido. XPointer funciona como una sintaxis que apunta a ciertas partes de un documento XML, es como una extensión de XPath. Se utiliza para llegar a ciertas partes de un documento XML. Primero, XLink permite establece el enlace con el recurso XML y luego es XPointer el que va a un punto específico del documento. Su funcionamiento es muy similar al de los identificadores de fragmentos en un documento HTML ya que se añade al final de una URI y después lo que hace es encontrar el lugar especificado en el documento XML. Al ser XPointer una extensión de XPath, XPointer tiene todas las ventajas de XPath y además permite establecer un rango en un documento XML, es decir, con XPointer es posible establecer un punto final y un punto de inicio, lo que incluye todos los elementos XML dentro de esos dos puntos. XQL: Lenguaje de Consulta XML, es un lenguaje que facilita la extracción de datos desde documentos XML. Ofrece la posibilidad de realizar consultas flexibles para extraer datos de documentos XML en la Web. XQL, lenguaje de consultas, se basa en operadores de búsqueda de un modelo de datos para documentos XML que puede realizar consultas en infinidad de tipos de documentos como son documentos


74

estructurados, colecciones de documentos, bases de datos, estructuras DOM, catálogos, etc.

5.1 XSL Es un acrónimo en inglés de eXtensible Stylesheet Language (Lenguaje de hojas de estilo ampliable). XSL es para XML lo que CSS es para HTML. Es un lenguaje diseñado para definición de transformaciones y formas de presentar documentos XML mediante hojas de estilo. XSL consta realmente de dos partes:

� XSLT: un lenguaje para transformar documentos XML. � XPath: un lenguaje para navegar en documentos XML (que ya se ha visto

anteriormente). � XSL-FO (XSL Formatting Objects, Objetos de Formateo XSL): define un

vocabulario XML para especificar semánticas de formateo para formatos binarios.

XSLT transforma un documento XML en otro documento XML, HTML o en una salida XHTML o en texto sencillo. El uso de XSL es imprescindible, ya que las etiquetas XML suelen ser definidas por el usuario y, por tanto, los navegadores no saben cómo interpretarlas o representarlas. Su significado se ha diseñado para ser entendido por las personas, no por las máquinas. XSLT también puede realizar las siguientes operaciones en un árbol XML:

� añadir y eliminar elementos � añadir y eliminar atributos � reorganizar y ordenar elementos � ocultar o mostrar determinados elementos � encontrar o seleccionar elementos específicos

XSL posee las siguientes características:

• XSL ha sido diseñado para procesar documentos XML y para cumplir con la sintaxis XML. Por tanto, sólo debería usarlo con aplicaciones XML o con aplicaciones sensibles a XML. Las aplicaciones ideales para usar XML y XSL son: portales Web, agregadores de noticias, sitios Web de comunidades o cualquier otra aplicación Web que necesite enviar información a diversos dispositivos y a un gran número de clientes, de forma que se otorgue independencia del formato de los datos.

• XSLT es un lenguaje basado en la correspondencia de patrones. Busca nodos que coincidan con una determinada condición y les aplica las reglas correspondientes. Por tanto, XSLT carece de la versatilidad de la mayoría de los lenguajes de programación. Por ejemplo, XSL no puede cambiar los valores de las variables en tiempo de ejecución. No se debería usar para calcular valores de fuentes de datos dinámicos mediante fórmulas complicadas (como, por ejemplo, en una tienda en línea). Para este tipo de aplicaciones, los lenguajes de programación Web son una opción mejor.


75

• XSL no ha sido diseñado para sustituir o complementar CSS. No se debería usar (y, de hecho, no se puede) para aplicar estilos a HTML. No obstante, puede utilizarse en sitios Web que necesitan ser rediseñados con frecuencia, que cambian su diseño a menudo y que necesitan manipular datos en un formato flexible.

• XSL no es una herramienta de administración de contenido. No debería usarse (y, de hecho, no se puede) para cambiar el contenido de documentos XML o para editar información. Sin embargo, se puede utilizar XML y XSL en un sistema de administración de contenido que requiera manejar documentos de varias formas distintas.

5.1.1 XSLT

XSLT o XSL Transformaciones es un estándar de la organización W3C que presenta una forma de transformar documentos XML en otros e incluso a formatos que no son XML. Las hojas de estilo (aunque el término de hojas de estilo no se aplica sobre la función directa del XSLT) XSLT realizan la transformación del documento utilizando una o varias reglas de plantilla: unidas al documento fuente a transformar, esas reglas de plantilla alimentan a un procesador de XSLT, el cual realiza las transformaciones deseadas colocando el resultado en un archivo de salida o, como en el caso de una página web, directamente en un dispositivo de presentación, como el monitor de un usuario. Actualmente, XSLT es muy usado en la edición web, generando páginas HTML o XHTML. La unión de XML y XSLT permite separar contenido y presentación, aumentando así la productividad. La siguiente figura describe el proceso de transformación mediante XSLT:

Figura 15 Transformación con XSLT

5.1.1.1 Sintaxis XSLT

La sintaxis básica de XSLT consiste en:

� Elemento raíz: siempre debe ser el siguiente, especificando la versión y el espacio de nombres que se va a usar:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

� xsl:output: controla qué tipo de salida va a producir la hoja XSL. Lo normal es producir XML, aunque también se puede producir HTML o texto plano.


76

� xsl:template: define una transformación. Tiene un atributo "match" que dice a qué elementos se aplica la transformación.

� xsl:apply-templates: aplica los xsl:template asociados a cada elemento que haya en la parte del documento XML que se esté procesando.

� xsl:value-of: obtiene el valor de un nodo. � xsl:text: escribe texto de forma literal en la salida. � xsl:for-each: itera sobre un conjunto de elementos. � xsl:when, xsl:choose y xsl:otherwise : sirven para expresar condiciones

multiples. � xsl:if : se procesa si se cumple una condición.

5.1.1.2 Procesadores de texto XSLT

En muchos casos, lo que se necesita es aplicar hojas de estilo dentro de una aplicación, o usarlas desde línea de comandos a partir de otra aplicación u otro lenguaje de programación. En ese caso, lo más útil es usar un procesador de hojas de estilo, que habitualmente se encuentra en conjunción con un parser XML, con o sin validación. De estos, hay los siguientes:

� Xalan, la versión actual es la 2.6. Es una herramienta escrita en Java, y lo único que se necesita para hacerla funcionar es una máquina virtual Java (JVM), tal como la de Microsoft, Sun o IBM. Xalan necesita un parser XML para funcionar, tal como el Xerces, aunque el fichero correspondiente (xerces.jar) viene incluido en la distribución.

� Saxon, un procesador bastante rápido, también escrito en Java, con su propio parser incluido, aunque se puede usar uno externo. Hay una versión denominada Instant Saxon, un procesador rápido, y fácil de usar, sólo para Windows. Por lo pronto, es el único que implementa la versión 2.0 de XSLT.

� Hay otros muchos procesadores, tales como el XT de James Clark, xsltproc o el Sablotron. Todos ellos y muchos más se pueden encontrar en la página de procesadores XSLT de XMLSoftware.com. En Linux es recomendable el xsltproc, basado en la librería XML/XSL de gnome; es muy rápido, es un ejecutable y no hace falta instalar Java para usarlo.

� A su vez, los procesadores de hojas de estilo se pueden usar como librerías de clases, o desde otros lenguajes. Por ejemplo, el módulo XML:XSLT para Perl. Estos módulos se pueden usar para poder trabajar con XSLT fuera de entornos de publicación, como por ejemplo un servidor web normal. xalan es en realidad una librería que se puede usar también desde programas en Java.

� Algunos navegadores también lo implementan, o lo harán en el futuro. En concreto, el Mozilla lo incluyó a partir de la versión 0.9; desde la versión 0.7 se podía incluir un plugin llamado TransforMiiX, que teóricamente aplica XSLT. En realidad, casi todos los navegadores modernos, con mayor o menor fortuna, lo incluyen.

5.1.2 XPath

XPath (XML Path Language) es un lenguaje con una sintaxis fija que permite seleccionar subconjuntos de un documento XML. La idea es parecida a las expresiones


77

regulares para seleccionar partes de un texto sin atributos (plain text). XPath permite buscar y seleccionar teniendo en cuenta la estructura jerárquica de XML.

Sintaxis XPath

La sintaxis básica de las expresiones XPath son: // Representa el nodo raíz del documento. / Desciende un nivel en la jerarquía actual. * Representa todos los nodos. [i] Selecciona la ocurrencia i-ésima del elemento seleccionado. @atributo Selecciona todos los atributos llamados “atributo”. | Combina diferentes caminos. Algunas de las funciones que se utilizan son: normalize-space Elimina los espacios al principio y al final, así como también

reemplaza las secuencias de blancos por un único espacio. Count() Cuenta el número de elementos seleccionados. Name() Produce el nombre del elemento seleccionado. String-length() Produce el número de caracteres de su argumento. Se debe utilizar

< en reemplazo de < y > en reemplazo de >. Chile Contiene los hijos del documento. descendant Contiene a los descendientes del nodo de contexto; los

descendientes son los hijos del nodo y sus descendientes; El eje 'descendant' nunca contiene ni atributos ni nodos 'namespace'.

Parent Contiene si existe el padre del nodo del contexto. ancestor Contiene los ancestros del nodo del contexto, que son el padre del

nodo y sus ancestros; Se deduce entonces que el eje 'ancestor' de un patrón correspondiente a al menos un nodo contiene el elemento raíz salvo en el caso de que el contexto especifique únicamente la raíz misma.

Div Realiza divisiones en punto flotante. Mod Calcula el residuo entero de la división. Floor() Calcula el entero más grande que no es mayor que el argumento. Ceiling() Calcula el entero más pequeño que no es menor que el argumento. A modo de ejemplo, se muestra el resultado de varias expresiones XPath sobre una estructura XML imaginaria, representada a continuación:

<AAA> <XXX> <DDD> <BBB/> <BBB/> <EEE/> <FFF/> </DDD> </XXX> <CCC>


78

<DDD> <BBB/> <BBB/> <EEE/> <FFF/> </DDD> </CCC> <CCC> <BBB> <BBB> <BBB/> </BBB> </BBB> </CCC> </AAA>

En las dos tablas siguientes se muestra el resultado de aplicar la sentencia XPath de la columna de a izquierda sobre el XML anterior: /AAA/CCC/DDD/* <AAA>

<XXX> <DDD> <BBB/> <BBB/> <EEE/> <FFF/> </DDD> </XXX> <CCC> <DDD> <BBB/> <BBB/> <EEE/> <FFF/> </DDD> </CCC> <CCC> <BBB> <BBB> <BBB/> </BBB> </BBB> </CCC> </AAA>

/*/*/*/BBB <AAA> <XXX> <DDD> <BBB/> <BBB/> <EEE/>


79

<FFF/> </DDD> </XXX> <CCC> <DDD> <BBB/> <BBB/> <EEE/> <FFF/> </DDD> </CCC> <CCC> <BBB> <BBB> <BBB/> </BBB> </BBB> </CCC> </AAA>

5.1.3 XSL-FO

Un documento XSL-FO es un documento XML en el que se especifica cómo se van a formatear unos datos para presentarlos en pantalla, papel u otros medios. El significado de las siglas XSL-FO es eXtensible Stylesheet Language Formatting Objects. Hay que destacar que en el documento XSL-FO figuran tanto los datos como el formato que se les va a aplicar. La unidad básica de trabajo en un documento XSL-FO es el "Formating Object", unidad básica para presentar (formatear) la información. Estos objetos de formato se refieren a páginas, párrafos, tablas, etc. Para obtener el documento XSL-FO pueden seguirse dos vías:

1. Generarlo directamente a partir de los datos. El documento XSL-FO contiene las especificaciones de formato y los propios datos.

2. Transformar un documento XML que contenga los datos a presentar con una hoja de estilos XSLT. De esta forma los datos (XML) se independizan del formato que proporcionará la hoja de transformación XSLT.

Cuando se tiene el documento XSL-FO, puede ser procesado por un programa llamado "procesador de XSL-FO" para obtener el documento final en distintos formatos. El formato final más utilizado es el PDF.

CAPÍTULO 4: CXML

1 Introducción cXML (commerce eXtensible Markup Language) fue creado en 1999 por el consorcio NetCommerce (formado por compañías como Microsoft, VISA, Hewlett Packard…) con el objetivo de definir, implementar y adoptar un protocolo estándar especializado en la consistencia de las comunicaciones de documentos comerciales entre aplicaciones de adquisición, centros de comercio electrónico y proveedores. Se trata de una extensión de XML al comercio electrónico. cXML permite la comunicación entre compradores, proveedores, agrupadores de productos e intermediarios mediante un único lenguaje abierto y estándar. Los portales de comercio electrónico entre empresas (comercio electrónico B2B) de éxito dependen de un protocolo flexible y de uso generalizado. cXML constituye la clave para proporcionar el máximo acceso a sus productos y servicios, ya que se trata de un lenguaje eficaz bien definido, diseñado específicamente para el comercio electrónico B2B y elegido por proveedores y compradores de grandes volúmenes. Las transacciones cXML consisten en documentos, que son archivos de texto sencillos con formato y contenido bien definidos. La mayoría de los tipos de documentos cXML son análogos a los documentos impresos empleados tradicionalmente en las empresas. El hecho de que CXML defina exclusivamente el lenguaje le otorga de gran potencialidad, pues le permite ser portable a cualquier plataforma o sistema operativo, posibilitando la existencia de diferentes entornos de trabajo. Los principales tipos de documentos de cXML son:

� Catálogos Los catálogos son archivos que describen productos y servicios a compradores. Los proveedores crean catálogos para que las organizaciones que utilicen aplicaciones de adquisición puedan consultar y adquirir los productos y servicios que ofrece. Las aplicaciones de adquisición leen los catálogos y los almacenan internamente en sus bases de datos. Sobre cada artículo de un catálogo, existe información básica necesaria e información opcional que activa características avanzadas del catálogo, como descripciones en varios idiomas.

Capítulo 4: CXML Memoria

81

Figura 16 Catálogo

� Punchouts Los punchouts son una alternativa frente a los archivos de catálogo estáticos. Los sitios para punchouts son catálogos interactivos y actualizados que se ejecutan en el sitio Web y son mantenidos por el proveedor del catálogo. Un punchout consistirá en un aplicación web, escrita en un lenguaje como JSP, PHPo ASP, que gestionará sesiones interactivas de comercio. En los sitios para punchouts, las aplicaciones de adquisición muestran un botón en lugar de detalles sobre productos o precios. Cuando los usuarios hacen clic en este botón, el navegador Web empleado muestra páginas de su sitio Web local. Los usuarios podrán navegar por las opciones de productos, especificar configuraciones y seleccionar métodos de entrega.

Figura 17 Punchout

� Pedidos de compra Los compradores envían pedidos de compra a los proveedores para solicitar el cumplimiento de un contrato. Los pedidos se pueden transmitir a los proveedores mediante una plataforma de red de comercio electrónico.


82

Figura 18 Pedido

CXML constituye una solución posible a tener en cuenta a la hora de implementar sistemas de compra, ya que es flexible, su implementación es económica, admite una amplia variedad de datos y archivos adjuntos y los sistemas automatizados pueden utilizarlo.

2 Aplicaciones que utilizan cXML Cualquier aplicación de comercio electrónico puede utilizar cXML. Actualmente lo utilizan compradores, comunidades de compra verticales y horizontales, proveedores y distribuidores de aplicaciones.

� Aplicaciones de adquisición Estas aplicaciones permiten a las comunidades de usuarios adquirir productos y servicios según contrato a proveedores que han sido aprobados por sus administradores de compras. Los administradores de las comunidades aprueban primero las compras solicitadas y luego los pedidos de compra aprobados se transmiten a los proveedores mediante varios canales posibles, incluido cXML a través de Internet. � Plataforma de red de comercio electrónico Las plataformas de red de comercio son servicios basados en la Web para la conexión de compradores y proveedores. Estos servicios Web proporcionan características como la validación de catálogos y la administración de archivos, la publicación y la suscripción a catálogos, el direccionamiento automatizado de pedidos de compra y el historial de pedidos de compra. La comunicación entre estos servicios Web, las aplicaciones de los compradores y las aplicaciones de los proveedores se pueden realizar en su totalidad con cXML a través de Internet.

� Catálogos de punchout Son catálogos interactivos, disponibles en los sitios Web de los proveedores. Estos catálogos son aplicaciones de servidor Web creadas en un lenguaje de programación como ASP, JSP o PHP, que administran las sesiones de punchout de los compradores. Los catálogos de punchout aceptan solicitudes de punchout enviadas desde aplicaciones de adquisición, identifican al comprador y muestran los productos y los precios adecuados en formato HTML. Posteriormente, los usuarios pueden seleccionar artículos, configurarlos y seleccionar opciones, si corresponde.


83

Al final de la sesión de punchout, el sitio para punchouts envía descripciones de las selecciones de los usuarios, en formato cXML, a las aplicaciones de adquisición. � Sistemas de recepción de pedidos Aplicaciones incluidas en los sitios de los proveedores que aceptan y procesan los pedidos de compra enviados por los compradores. Estos sistemas pueden ser sistemas automatizados, como sistemas de control de existencias, de cumplimentación o de procesamiento de pedidos. Puesto que es sencillo extraer información de pedidos de compra cXML, resulta relativamente fácil crear los adaptadores que permiten que los sistemas de recepción de pedidos existentes los acepten.

2.1 Validación respecto DTD Puesto que cXML es un lenguaje XML, un conjunto de definiciones del tipo de documento (DTD) lo definen a fondo. Estos DTD son archivos de texto que describen la sintaxis y el orden precisos de los elementos de cXML. Los DTD permiten a las aplicaciones validar el cXML que leen o escriben. No se necesitan aplicaciones cXML para validar documentos cXML, aunque se recomienda. Hay disponibles DTD para todas las versiones de cXML en ubicaciones coherentes en cxml.org: http://XML.cXML.org/schemas/cXML/<versión>/cXML.dtd, donde <versión> es el número completo de versión de cXML, por ejemplo, 1.1.007. En cualquier caso, para un funcionamiento más eficiente, las aplicaciones que usen cXML deberían almacenar en caché local los DTDs. De esta manera, se conseguiría una validación mucho más rápida, puesto que el procesador no tendría ya que acceder a un recurso en la red y a su vez una menor dependencia en el sitio web cXML.org, ya que si fallase esta web, no podrían validarse los documentos enviados y recibidos, lo que provocaría graves errores en el sistema. Las aplicaciones pueden utilizar estos DTD para validar todos los documentos cXML entrantes y salientes. Para un funcionamiento más robusto, se deberían validar todos los documentos cXML recibidos, aunque en general no es obligatorio, sino recomendado. Sin embargo, todos los documentos cXML deben ser válidos y referirse a los DTD determinados por la versión. En la versión 1.2.009 se especifican 4 DTDs:

� Documento básico cXML: con los elementos básicos de cXML. Es el básico y más importante.

� Confirmaciones y anuncio de envío. � Facturas � Definiciones de tipo de catálogos.

Mediante esta división en cuatro DTDs se consigue aumentar la eficiencia de la validación en determinados procesadores XML y potenciar una mayor especialización en el desarrollo de distintos aspectos del comercio electrónico.


84

2.2 Especificación del estándar cXML Existen dos modelos de comunicación para las transacciones cXML: el de petición-respuesta y el de sentido único. Ambos constan de una sencilla implementación y ofrecen soluciones a problemáticas distintas. Se procede a explicar, en los siguientes apartados, ambos modelos.

2.2.1 Modelo de petición-respuesta

Las transacciones de petición-respuesta sólo se pueden realizar mediante una conexión Http. La siguiente imagen ilustra los pasos que se deben realizar en una interacción de petición-respuesta entre las partes A y B:

Figura 19 Petición-Respuesta Esta transacción consta de los siguientes pasos:

1. El cliente inicia una conexión Http/1.x con el proveedor en una URL predeterminada que representa la dirección del proveedor. 2. El cliente utiliza una operación POST para enviar el documento cXML mediante la conexión Http. 3. El cliente espera que se devuelva una respuesta a través de la conexión Http. 4. El proveedor tiene un servidor compatible con Http/1.x que remite la petición de Http al recurso especificado por la URL que se ha especificado en el paso 1. Este recurso puede ser cualquier ubicación conocida por el servidor Http del proveedor. 5. El recurso del proveedor, identificado en el paso 4, lee el contenido del documento cXML y asigna la petición al gestor adecuado. 6. El gestor del proveedor encargado de esa petición cXML realiza la tarea que la petición especifica y genera un documento cXML como respuesta. 7. EL proveedor envía la respuesta cXML al cliente mediante la conexión Http establecida en el paso 1. 8. El cliente lee la respuesta cXML y la devuelve al proceso que ha iniciado la petición. 9. El cliente cierra la conexión Http establecida en el paso 1.


85

Este proceso se repetirá en futuros ciclos de petición/respuesta. Para simplificar la tarea en los pasos anteriores, los documentos cXML se dividen en dos partes diferenciadas:

� Cabecera: Contiene la información sobre la verificación y la dirección. � Datos de la petición o la respuesta: Contienen una petición o respuesta

específica, así como la información que se debe transferir. La estructura de la respuesta no utiliza el elemento de cabecera porque la respuesta siempre viaja en la misma conexión Http que la petición.

2.2.1.1 Convenciones de cXML

cXML utiliza los elementos para describir los distintos artículos, que normalmente son propiedades en los documentos empresariales tradicionales. También la información que contiene claras subdivisiones y relaciones entre éstas, como por ejemplo una dirección, se describe utilizando estos elementos. cXML hace un amplio uso de los atributos. En cXML, todos los nombres de los elementos y los atributos utilizan palabras completas en mayúsculas (sin guiones) para separar las palabras. Los nombres de los elementos comienzan por una letra en mayúsculas y los nombres de los atributos por minúsculas. Por ejemplo:

Elementos: Sender, Credential, Payment, ItemDetail

Atributos: version, payloadID, lineNumber, domain

2.2.1.2 EL sobre principal de cXML

El elemento de sobre es la raíz de la estructura de los documentos cXML y contiene a los demás elementos. El elemento cXML está presente en todas las transacciones cXML. En el siguiente ejemplo se muestra un elemento cXML totalmente especificado:

<cXML version="1.1.007" XML:lang="en-US" [email protected] timestamp="1999-03-31T18:39:09-08:00">

cXML tiene los siguientes atributos: version

(opcional)

Especifica la versión del protocolo cXML. Un analizador XML de validación podría también determinar el atributo de la versión mediante las definiciones del tipo de documento (DTD) a las que hace referencia. Sin embargo, los documentos cXML deberían incluir la versión explícitamente para ayudar a las aplicaciones que no utilizan analizadores de validación.

XML:lang

(opcional)

Lugar utilizado para todos los textos libres que se han enviado en este documento. El receptor debe responder o mostrar la información en el mismo lugar o en uno similar. Por ejemplo, un cliente que especifique XML:lang="en-UK" en una petición debería recibir datos "en" de vuelta.


86

payloadID

Número único, en relación con el espacio y el tiempo, que se utiliza en las operaciones de conexión para identificar documentos que pueden haberse perdido o tener problemas. Este valor no debería cambiar en caso de que se vuelva a intentar. La implementación recomendada es la siguiente:

datetime.process id.random number@hostname

timestamp

Fecha y hora en que se envió el mensaje (con formato ISO 8601). Este valor no debería cambiar en caso de que se vuelva a intentar.

El formato es DD-MM-YYYYThh:mm:ss-hh:mm (por ejemplo,

16-07-1997T19:20:30+01:00).

2.2.1.3 Niveles de ajuste

El elemento cXML es el cuerpo de un documento XML normal. Los documentos deben comenzar del siguiente modo:

<?XML version="1.0" encoding="UTF-8"?> <!DOCTYPE cXML SYSTEM "http://XML.cxml.org/schemas/cXML/1.1.007/cXML.dtd"> <cXML version="1.1.007" XML:lang="en-US" payloadID="0c300508b7863dcclb_13550" timestamp="2000-01-09T01:36:05-08:00">

Este documento se transfiere normalmente a través de Http con un tipo de medio MIME de text/XML y un parámetro charset que coincide con la codificación del documento. Como Http es de ocho bits, cualquier codificación que admita el analizador de recepción se puede utilizar sin una codificación de transferencia de contenidos, como por ejemplo Base64 o quoted-printable. Todos los analizadores XML admiten la codificación UTF-8, en la que se incluyen todos los caracteres Unicode. Por este motivo, las aplicaciones deben utilizarla para transferir los documentos cXML.

2.2.1.4 Elementos

Cabecera El elemento Cabecera (Header) contiene información sobre la dirección y la verificación. Este elemento es el mismo, independientemente de la petición o respuesta específicas que se contengan en el cuerpo del mensaje cXML. Las aplicaciones necesitan la identidad del solicitante, pero no es necesario comprobar que la información sobre la identidad proporcionada es correcta. En el siguiente ejemplo se muestra el elemento Header:

<Header> <From>

<Credential domain="AribaNetworkUserId"> <Identity>[email protected]</Identity>


87

</Credential> </From> <To>

<Credential domain="DUNS"> <Identity>012345678</Identity>

</Credential> </To> <Sender>

<Credential domain="AribaNetworkUserId"> <Identity>[email protected]</Identity> <SharedSecret>abracadabra</SharedSecret>

</Credential> <UserAgent>Ariba Network 1.1</UserAgent>

</Sender> </Header>

Los elementos From y To son sinónimos de los elementos From y To (De y Para) de los mensajes de correo SMTP, que son la fuente lógica y el destino de los mensajes. Sender es la parte que inicia la conexión http y envía el documento cXML. Sender contiene el elemento Credential, mediante el cual la parte receptora puede verificar la parte emisora. Este elemento permite realizar verificaciones de gran envergadura sin necesidad de una infraestructura de certificado digital integral de clave pública. La parte receptora tan sólo debe proporcionar el nombre de usuario y la clave para que la parte emisora pueda realizar las peticiones. Inicialmente, los elementos Sender y From son idénticos. Sin embargo, si el documento cXML se transfiere a través de los concentradores de red de comercio electrónico, el elemento Sender se modifica para indicar cuál es la parte emisora actual. From Este elemento identifica al autor de la petición cXML. De manera opcional, puede contener más de un elemento Credential, que permite al solicitante identificarse utilizando varios métodos de identificación. Usar varias credenciales es igual que especificar las direcciones SMTP y X.400 en un mensaje de correo electrónico.

To Este elemento identifica el destino de la petición cXML. Puede contener más de una Credential para facilitar la identificación del objetivo.

Sender Este elemento permite a la parte receptora identificar y verificar la parte que ha iniciado la conexión Http. Contiene una Credential de verificación más exhaustiva que las de los elementos From o To, porque la parte receptora debe verificar qué persona solicita realizar una tarea.

Credencial Este elemento contiene valores de identificación y verificación utilizados en los mensajes cXML. Credential tiene los siguientes atributos: domain Especifica el tipo de credencial. Este atributo permite que los

documentos contengan varios tipos de credenciales para varios dominios de verificación. Para los mensajes enviados con Ariba Network, por


88

ejemplo, el dominio normalmente es AribaNetworkUserId o DUNS.

type

(opcional)

Las peticiones dirigidas o procedentes de un mercado identifican tanto al mercado como a la compañía en los elementos From o To Credential. En este caso, la credencial del mercado utiliza el atributoType, que se ha establecido con el valor "marketplace".

Credential contiene un elemento Identity y, de manera opcional, un elemento SharedSecret o DigitalSignature. El elemento Identity indica a quién representa la Credential, mientras que los elementos opcionales de verificación constatan la identidad de la parte. El elemento SharedSecret se utiliza cuando el Sender tiene una combinación de nombre de usuario/contraseña que reconoce el solicitante. El elemento DigitalSignature se puede emplear si las dos partes han acordado una autoridad y formato de certificado comunes. El atributo type de un elemento DigitalSignature especifica el tipo de certificado utilizado.

2.2.1.5 Petición cXML

Los clientes envían peticiones para solicitar operaciones. Sólo se permite un elemento Request por cada elemento de envoltura cXML, lo que repercute en la simplicidad de las implementaciones de los servidores, ya que no hay entonces que realizar demultiplexión a la hora de analizar y procesar los documentos cXML. El elemento Request puede contener virtualmente cualquier tipo de datos XML. Algunos ejemplos de elementos Request tipo son:

• OrderRequest • ProfileRequest • PunchOutSetupRequest • SubscriptionContentRequest • SupplierListRequest

2.2.1.6 Respuesta cXML

Los servidores envían respuestas para informar a los clientes de los resultados de las operaciones. Como puede ocurrir que los resultados de algunas peticiones no tengan datos, el elemento Response puede contener de manera opcional sólo un elemento Status. El elemento Response también puede contener datos de cualquier nivel de la aplicación. El elemento Status tiene la siguiente forma:

<Status code=”406” text=”Not Acceptable”>No se pudo validar!</Status> Donde,


89

• Code: código del estado de la petición. Sigue el modelo de códigos de estados Http. Por ejemplo, 200 representa una petición correcta.

• Text: Texto del mensaje de estado. Este texto facilita al usuario la lectura de los registros y está compuesto de cadenas canónicas en inglés.

Los atributos del elemento Status indican lo que le ha sucedido a la petición. Los datos del elemento Status pueden ser cualquier información que necesite el solicitante. Para el código de estado 200/OK, puede que no haya datos. Sin embargo, para el código de estado 500/Internal Server Error, se recomienda que se especifique el error de análisis XML o el error de aplicación. Este error permite realizar mejor la depuración unilateral y las pruebas de interoperabilidad. Los servidores no deberían incluir elementos de respuesta adicionales.

2.2.2 Modelo Sentido único (asíncrono)

A diferencia de las transacciones de petición-respuesta, los mensajes de sentido único no se limitan al transporte Http. Estos mensajes se emplean cuando no es adecuado utilizar un canal Http (una operación del tipo petición-respuesta sincrónico). La siguiente imagen muestra un ejemplo de cómo A y B se pueden comunicar con mensajes en lugar de hacerlo a través de una transacción de petición-respuesta.

Figura 20 Sentido único

En el modelo sentido único, el cliente y el proveedor no poseen un ciclo explícito de petición-respuesta. Pueden llegar mensajes procedentes de terceros y se pueden producir conversaciones con otros. Los mensajes de sentido único tienen una estructura similar a la del modelo petición-respuesta, pero tienen como cuerpo sólo un elemento Message: En este caso, se presenta el siguiente escenario:

1 El proveedor da formato y codifica un documento cXML con un transporte que resulte comprensible para el cliente. 2 El proveedor envía el documento utilizando el transporte conocido. El cliente no espera de manera activa (ya que no puede) una respuesta procedente del cliente. 3 El cliente recibe el documento cXML y lo descodifica fuera de la corriente de transporte. 4 El cliente procesa el documento.

En el modelo de sentido único, el cliente y el proveedor no comparten un ciclo explícito de petición-respuesta. Por ejemplo, entre mensajes de sentido único, pueden llegar mensajes procedentes de terceros y se pueden producir conversaciones con otras


90

personas. Para especificar completamente una transacción de sentido único, también se debe documentar el transporte utilizado para el mensaje. Para las transacciones cXML que utilizan una aproximación de sentido único, se especifican el transporte y la codificación. Un ejemplo habitual de transacción que hace uso de esta modalidad podría ser el PunchOutOrderMessage. Los mensajes de sentido único tienen una estructura similar a la del modelo de petición-respuesta:

<cXML> <Header>

Header information here… </Header> <Message>

Message information here… </Message>

</cXML>

El elemento Header recibe un tratamiento idéntico al del caso Petición-respuesta. El elemento cXML también es igual al descrito anteriormente. El modo más sencillo de apreciar la diferencia entre un mensaje de sentido único y uno de petición-respuesta es observar la presencia de un elemento Message (en lugar de un elemento Request o Response). En el siguiente apartado se estudia detenidamente el elemento Message.

2.2.2.1 Elementos

Message Este elemento provee de la información principal en un mensaje cXML. Puede contener un elemento Status opcional, idéntico al encontrado en un elemento Response. Se podría utilizar con mensajes que son respuestas lógicas a mensajes de solicitud. Message tiene los siguientes atributos: deploymentMode

(opcional)

Indica si la petición es de prueba o de producción.

Los valores permitidos son "production" (por defecto) o "test".

inReplyTo

(opcional)

Especifica a qué mensaje responde este mensaje. El contenido

del atributo inReplyTo podría ser el payloadID de un mensaje

recibido anteriormente. Se podría utilizar para construir

una conversación de dos direcciones con muchos mensajes.

El atributo inReplyTo también puede hacer referencia al payloadID de una petición anterior o de un documento de respuesta. Cuando una transacción de petición-respuesta inicia una "conversación" mediante varias interacciones de sentido único, el primer mensaje puede incluir el payloadID de la última petición importante o de una respuesta que iba en dirección contraria. Por ejemplo, un


91

mensaje que contiene un PunchOutOrderMessage puede incluir un atributo inReplyTo que contiene el payloadID de la PunchOutSetupRequest que ha iniciado la sesión punchout. (La BuyerCookie incluida en los documentos de punchout realiza una función parecida a la del atributo inReplyTo.)

Opciones de transporte Existen dos protocolos de transporte que se suelen utilizar con los mensajes de sentido único: Http y URL-Form-Encoding. Http Http se utiliza en la comunicación de sentido único para permitir que las aplicaciones de adquisición obtengan información. Uno de los tipos de transacción que utiliza la comunicación Http de sentido único es GetPendingRequest. URL-Form-Encoding Este transporte se comprende mejor examinando cómo se realiza la transacción PunchOutOrderMessage. URL-Form-Encoding permite la integración de un sitio Web remoto con las aplicaciones de adquisición. También se utiliza como medio para evitar la necesidad de un servidor de escucha en el sistema del comprador al que se puede acceder directamente a través de Internet. El mensaje cXML PunchOutOrderMessage no se envía directamente a la aplicación de adquisición a través del sitio Web remoto, sino que se codifica como campo oculto del formulario HTML y se envía a la URL que se ha especificado en el elemento BrowserFormPost de la PunchOutSetupRequest. Cuando el usuario hace clic en Check Out, el sitio Web envía los datos a la aplicación de adquisición como una emisión de formulario HTML. El siguiente diagrama ilustra lo que sucede:

Figura 21 Transportes


92

2.3 Transacciones cXML Las transacciones cXML consisten en documentos, que son archivos de texto sencillos con formato y contenido bien definidos. La mayoría de los tipos de documentos cXML son análogos a los documentos impresos empleados tradicionalmente en las empresas.

2.3.1 Transacción de perfil

Las implementaciones del servidor cXML desde la versión 1.1 en adelante deben admitir los documentos ProfileRequest y ProfileResponse. Esta transacción se utiliza para recuperar las capacidades del servidor, incluyendo la versión cXML admitida, las transacciones y las opciones de éstas. Es la única transacción cXML que debe ser implementada obligatoriamente en todo servidor cXML, y su propósito es proporcionar compatibilidad entre aplicaciones, de forma que el cliente tenga conocimiento de las capacidades soportadas por el servidor cXML con el que está conversando. La respuesta debe contener todas las peticiones admitidas por el servidor, no necesariamente todas las que admite la empresa. Los proveedores que pueden recibir documentos OrderRequest o iniciar transacciones de petición-respuesta describen su soporte respecto a OrderRequest en la transacción de perfil. La transacción de perfil se puede utilizar para realizar un ping al servidor dentro del protocolo cXML.

2.3.1.1 ProfileRequest

Este elemento no tiene contenido. Tan sólo se dirige al servidor cXML adecuado utilizando información contenido en el elemento Header. El servidor responde con una sola ProfileResponse. Las únicas partes dinámicas de esta respuesta son los atributos payloadId y timestamp del propio elemento cXML.

2.3.1.2 ProfileResponse

Este elemento contiene una lista de transacciones admitidas, sus ubicaciones y las opciones admitidas. El siguiente ejemplo es una posible ProfileResponse:

<ProfileResponse effectiveDate="2001-03-03T12:13:14-05:00"> <Transaction requestName="PunchOutSetupRequest">

<URL>http://www.workchairs.com/compra.jsp</URL> </Transaction>

</ProfileResponse>

El atributo effectiveDate indica la fecha y hora (en formato ISO 8601) desde la que esta transacción está disponible. El elemento Transaction da la descripción de la transacción soportada, en particular mediante el atributo requestName, que proporciona la información sobre el nombre de la transacción soportada, y el elemento URL, que indica la URL donde está disponible la transacción. Existen además otros elementos que proporcionan información adicional sobre las transacciones en los que no se entrará en más detalles.


93

2.3.2 Definición de pedidos

Los documentos de pedidos cXML son OrderRequest y una respuesta genérica cXML. OrderRequest es similar a un pedido de compra. La respuesta es una confirmación de que el proveedor ha recibido el pedido de compra. No es necesario ejecutar el pedido de compra, sino la confirmación de que se ha recibido correctamente.

2.3.2.1 OrderRequest

En el siguiente ejemplo se muestra la estructura del elemento OrderRequest: <OrderRequest>

<OrderRequestHeader … > Cabecera de la petición

</OrderRequestHeader> <ItemOut … >

Información de un producto pedido

</ItemOut> <ItemOut>

Información de un producto pedido

</ItemOut> </OrderRequest>

El elemento OrderRequest tiene, entre otros, dos atributos importantes: orderID, que identifica una petición de compra, y orderDate, que da la fecha de la orden (en formato ISO 8601, como todas las fechas en cXML).

2.3.2.2 Respuesta a una OrderRequest

Ésta es la parte de respuesta de la transacción de petición-respuesta sincrónica. En el siguiente ejemplo se muestra la respuesta de un documento OrderRequest:

<cXML version="1.1.007" payloadID="9949494" XML:lang="en" timestamp="1999-03-12T18:39:09-08:00">

<Response> <Status code="200" text="OK"/>

</Response> </cXML>

Como se mostraba anteriormente, esta respuesta es sencilla. En este caso, no existen elementos reales denominados "OrderResponse", porque el único dato que se debe devolver al solicitante es la parte Status de la respuesta. La respuesta comunica al solicitante que la parte remota de la conexión Http ha analizado y ha cumplido correctamente su OrderRequest. Sin embargo, no comunica la confirmación en el nivel de pedido, como por ejemplo qué artículos se pueden enviar o cuáles se deben reponer.

2.3.3 Transacción de punchout


94

Las definiciones de los mensajes de punchout son mensajes de petición-respuesta que están incluidos en los elementos Request y Response. Los proveedores deben implementar los siguientes mensajes para admitir el punchout. PunchOutSetupRequest y PunchOutSetupResponse son el par petición/respuesta utilizado para establecer una sesión de punchout con un sistema remoto. El cliente los utiliza para identificar la aplicación de adquisición, enviar la información de configuración y recibir una respuesta que indique dónde dirigirse para iniciar una sesión de exploración HTML en el sitio Web remoto. Un elemento PunchOutSetupRequest está incluido en el elemento Request. En el siguiente ejemplo se muestra una PunchOutSetupRequest.

<PunchOutSetupRequest operation="create"> <BuyerCookie>34234234ADFSDF234234</BuyerCookie>

<Extrinsic name="department">Marketing</Extrinsic> <BrowserFormPost> <URL>http://orms.acme.com:1616/punchoutexit</URL> <SelectedItem>

<ItemID> <SupplierPartID>54543</SupplierPartID>

</ItemID> </SelectedItem> <SupplierSetup>

<URL>http://workchairs.com/cxml</URL> </SupplierSetup>

</PunchOutSetupRequest> Una vez haya recibido el sitio Web una PunchOutSetupRequest, responde con una PunchOutSetupResponse, como se muestra a continuación:

<PunchOutSetupResponse> <StartPage>

<URL> http://premier.workchairs.com/store?23423SDFSDF23

</URL> </StartPage>

</PunchOutSetupResponse>

2.3.4 Catálogos

2.3.4.1 Elementos básicos

Las definiciones del catálogo cXML constan de dos elementos principales: Supplier, Index y Contract. Todos estos elementos describen los datos concebidos para uso permanente o temporal en el sistema de adquisición de un comprador o un concentrador.

� Supplier: Contiene datos básicos acerca del proveedor, como la información sobre la realización de pedidos, la dirección y el contacto.

� Index: Describe los datos acerca del inventario de productos del proveedor, como por ejemplo descripciones, números de pieza y códigos de clasificación.


95

Utiliza varios subelementos para describir los artículos de línea en los inventarios del proveedor.

� El elemento Supplier contiene 2 elementos fundamentales:

� Name: el nombre del proveedor. � SupplierID: contiene un identificador para el proveedor, con su respectivo

dominio de identidad. � SupplierLocation: contiene información relativa a la dirección física del

proveedor, así como a la dirección virtual, con datos como las direcciones de los sitios de compra y los métodos admitidos.

El elemento Index es el que gestiona la información de un catálogo. Se asocia generalmente a un solo proveedor. Contiene uno o más elementos IndexItem, que a su vez contienen uno o varios elementos que añaden o eliminan productos del catálogo que está en el caché de la organización que compra. Estos elementos pueden ser:

� IndexItemAdd: inserta o actualiza un producto. Contiene elementos con la identificación del producto, la descripción, e información para el catálogo.

� IndexItemDelete: borra un producto del catálogo dado su identificador de producto.

� IndexItemPunchout: especifica un producto para punchout.

2.3.4.2 Gestión de suscripciones

Los intermediarios pueden gestionar la información de catálogos y proveedores usada por las aplicaciones de adquisición. Estas transacciones son iniciadas por los sistemas de adquisición. Existen varios ciclos de petición/respuesta, entre los que destacan:

� Lista de Proveedores: Se compone de una petición con el elemento SupplierListRequest y una respuesta con el elemento SupplierListResponse. Se realiza un intercambio de información de la lista de proveedores con los que el comprador ha establecido relaciones comerciales.

� Datos de Proveedores: Se compone de una petición con el elemento SupplierDataRequest y una respuesta con el elemento SupplierDataResponse. Se realiza un intercambio de información del proveedor especificado por un identificador. La respuesta contiene el elemento Supplier, con datos como el nombre del proveedor, dirección, formas de ordenar pedidos, etc.

� Lista de Catálogos: Se compone de una petición con el elemento SubscriptionListRequest y una respuesta con el elemento SubscriptionListResponse. Se pide la lista de catálogos a los que el comprador está suscrito.

� Datos de Catálogo: Se compone de una petición con el elemento SubscriptionContentRequest y una respuesta con el elemento SubscriptionContentResponse. Se pide el contenido de un determinado catálogo de un proveedor también especificado. Se devuelve una respuesta.

CAPÍTULO 5: Aplicación desarrollada

1 Entorno de trabajo y de pruebas Para el desarrollo de la aplicación se ha utilizado un ordenador portátil con placa Intel Centrino a 1,6 Ghz y 512 MB de memoria RAM. El sistema operativo usado ha sido Windows XP Profesional, aunque la aplicación desarrollada es portable a otras plataformas como Linux por el hecho de haber sido desarrollados en Java y JXTA. El lenguaje de programación utilizado para la implementación de la aplicación ha sido Java. En concreto la versión de java utilizada es el kit de desarrollo java 1.6.0. Como entorno de programación se ha utilizado la herramienta Netbeans 5.5, pues provee de herramientas muy sencillas para la creación de ventanas, además de una interfaz de usuario. Se probaron inicialmente otras plataformas de programación como Eclipse, pero para el desarrollo de ventanas con la librería Swing, se comprobó que era mucho más intuitivo y fácil el manejo de Netbeans (la versión 5.5 de Netbeans tiene integrado un plugin específico para el desarrollo de entornos gráficos). Esta versión del JDK ha sido elegida debido a que es una de las más actuales, estables y compatibles con el resto de versiones de otros componentes utilizados (JXTA, JDIC, etc.). Se ha comprobado el buen funcionamiento de la aplicación en tres entornos de pruebas diferentes:

• Pruebas en el propio PC. Se han instanciado dos pares en el propio PC que se comunicaban a través de tuberías y “situados” en carpetas distintas, de forma que no hubiera problemas de caché.

• Pruebas en dos PC’s situados en la misma red de área local. Un par en el portátil de desarrollo y otro en un PC de sobremesa. Comunicación entre los dos pares a través de tuberías y sin la necesidad de atravesar ninguna barrera de Internet.

• Pruebas en dos PC’s situados en distintas redes locales. El mismo caso anterior, con la única diferencia de que era preciso atravesar dos routers y dos cortafuegos.

Todos los ordenadores que se han utilizado en estas pruebas, poseían el S.O. Windows XP Professional.

Capítulo 5: Aplicación desarrollada Memoria

97

2 Introducción a la aplicación En este apartado se aborda el análisis de la aplicación desde una perspectiva esquemática. Se muestran diagramas y esquemas de funcionamiento, y se evita en la medida de lo posible entrar en detalles sobre la programación de las clases, con vistas a dar una visión funcional del trabajo desarrollado y dejar los detalles de programación a la documentación del código fuente.

2.1 Tecnologías utilizadas Las tecnologías que se han elegido entre otras para la realización del proyecto son Java y XML. Ambas eran conocidas por el autor del proyecto y esto, unido a las siguientes que se enumeran, han sido las razones para su elección. El uso de Java y XML otorga a la aplicación ciertas características que se marcaron entre los objetivos del proyecto:

� Portabilidad a cualquier plataforma � Facilidad de desarrollo de aplicaciones � En general, al ser dos tecnologías muy utilizadas, existe una enorme información

en la red.

Respecto XML, Java da soporte mediante varias librerías (vistas anteriormente en el capítulo 3) para la utilización y desarrollo de aplicaciones con XML. Se podría haber utilizado otras implementaciones de los protocolos JXTA en otros lenguajes, como Perl y C++, pero es mucho más extendido en la red la implementación de aplicaciones con Java de JXTA, por lo que se decidió utilizar el lenguaje de Sun Microsystems. La versión que se ha utilizado de JXTA es la 2.4, disponible en la web oficial de JXTA (http:\\www.jxta.org).

JDIC

JDIC, siglas de JDesktop Integration Components, es una colección formada por paquetes Java (JDIC API) y la herramienta de empaquetación JNLP (JDIC packager). Permite que las aplicaciones basadas en tecnología Java estén más integradas al sistema operativo y su entorno de escritorio nativo. En otras palabras, se trata de un remedio eficaz para la integración GNU/Linux de las aplicaciones basadas en Java, y esto sin perder ni tener que hacer sacrificios estéticos y funcionales en cuanto a la plataforma o el gestor de ventanas. JDIC brinda una serie de mecanismos, mediante los cuales las aplicaciones Java pueden llegar a integrarse por completo en el entorno nativo. JDIC se ha utilizado en el desarrollo de la aplicación con objeto de integrar ésta en el S.O. Así, ha permitido añadir un icono en la bandeja de iconos de la aplicación cuando


98

ésta se encuentre en ejecución e incrustar una página HTML, resultante de la transformación de un catálogo CXML, en una ventana, cuando un usuario decide visualizar un catálogo encontrado.

2.2 Problemas surgidos El desarrollador ha encontrado varios problemas en la elaboración de la aplicación, sobre todo debido a la ausencia de una documentación definitiva del conjunto de protocolos JXTA. El hecho de que este protocolo se encuentre en constante evolución provoca que a pesar de que exista mucha información en la red, mucha de esta información sea obsoleta y por ejemplo, se refiera a JXTA 1.0 cuando se buscaba una solución para JXTA 2.0. Se echa en falta la creación por parte de la comunidad JXTA de ejemplos de código actuales y de una completa documentación. La ausencia de información definitiva ha provocado que el método “prueba/error” se haya utilizado en exceso. Por otra parte, durante el desarrollo de soluciones, se ha percibido que existen algunas clases que no realizan correctamente la funcionalidad pretendida o especificada: existen ciertos “bugs” (errores) en la implementación del protocolo que han sido comentados a los desarrolladores del proyecto JXTA, como por ejemplo el borrado de anuncios de la caché de un par. Por último, ya que sólo se tenía acceso a un número limitado de ordenadores, no se ha podido testear la aplicación a gran escala. Por ello, aunque supongamos que la aplicación se ha probado suficientemente, sería necesario un testeo exhaustivo a gran escala para garantizar su correcto funcionamiento. En general, el método empleado ha consistido en:

1) Análisis del problema. 2) Propuesta de soluciones. 3) Elaboración de diagramas de flujo y esquemas. 4) Implementación de la solución. 5) Fase de pruebas de la solución.

Además, la constante ayuda obtenida en los foros dedicados a esta tecnología ha sido muy importante para la obtención de soluciones a ciertos problemas que en un principio parecían irresolubles. Algunos de los foros donde se han resuelto estas dudas son:

- http://blog.gmane.org/gmane.comp.java.jxta.user/page=0 - http://forums.java.net/jive/forum.jspa?forumID=50

2.3 Aspectos básicos La aplicación desarrollada debía cumplir ciertos requisitos:

� Estar basada en P2P, utilizando los protocolos JXTA. � Ser portable: ejecutable sobre cualquier plataforma. � Ofrecer al usuario una interfaz gráfica simple.


99

� Otorgar de transparencia al usuario de toda la funcionalidad interna de la aplicación.

� Ser segura, tanto en los accesos a la red como respecto a posibles intrusos en el mismo PC donde se aloje la aplicación.

El resultado es una aplicación programada en lenguaje Java, que usa la implementación de JXTA para J2SE y cuya interfaz gráfica permite el intercambio de archivos y catálogos.

2.4 Resumen de la aplicación La aplicación desarrollada permite la búsqueda y el intercambio de archivos en la red. Además, permite llevar a cabo búsquedas de catálogos publicados en la red y la creación de nuevos catálogos. Se procede a explicar un poco más en detalle las posibles acciones que puede llevar a cabo un usuario. En cualquier caso, más adelante en la documentación se podrá encontrar información detallada de cada una de estas acciones y de cómo son resueltas. Edición de una configuración Un usuario puede disponer de varias configuraciones posibles para conectarse a la red. La diferencia entre cada una de estas configuraciones estribará en:

� Nombre de conexión. � Contraseña de conexión. � Carpeta compartida. � Puertos Http y Tcp utilizados.

El usuario puede crear cuantas configuraciones estime oportunas, así como modificarlas o borrarlas, si introduce la contraseña correcta. Conexión utilizando cierta configuración Si un usuario decide conectarse a la red, deberá hacerlo utilizando una de las configuraciones existentes. Además, al conectarse, deberá elegir el método de búsqueda que utilizará.

Búsqueda de archivos Se han implementado dos formas de búsqueda de archivos, de las que el usuario debe escoger una de ellas al conectarse:

1 Búsqueda por propagación: cuando el usuario decide realizar una búsqueda de un archivo, pregunta a todos los pares conectados si poseen un archivo cuyo nombre incluya la cadena que ha introducido como parámetro de la búsqueda. Si un par conectado detecta que posee un archivo que cumpla estas características, envía la información del archivo al solicitante.

2 Búsqueda por supernodos: se trata de una búsqueda más óptima en cuanto

a recursos de la red utilizados respecto a la primera. Existirán en la red ciertos supernodos que indexan información de los archivos poseídos por


100

los pares de la red. En este caso, cuando el usuario decide buscar un archivo, el par no pregunta a todos los nodos de la red, sino a estos supernodos. De esta forma, el número de solicitudes es mucho menor y no se producen colapsos en la red.

Transferencia de un archivo El archivo será recibido en paquetes de tamaño fijo, de forma que en caso de que la transferencia falle o se realice una desconexión de alguno de los pares involucrados, el sistema será capaz de recomenzar la transferencia por el lugar en el que se quedó. Una vez un archivo haya completado su transferencia, el usuario puede ejecutarlo desde el interfaz gráfica o borrarlo. Edición de catálogos La aplicación permite la creación, modificación, borrado y publicación en la red de catálogos. Cada uno de estos catálogos posee información del poseedor del catálogo, como la página web y el correo electrónico, e información de cada producto que conforma el catálogo, como:

� Nombre del producto. � Precio del producto. � Periodo de tiempo en venta del producto. � Descripción del producto.

Búsqueda de catálogos Permite realizar una búsqueda de catálogos en la red, atendiendo al nombre del catálogo. Visualización de un catálogo Una vez que se ha encontrado un catálogo, el usuario puede decidir si visualizarlo. En tal caso, aparecerá la información del catálogo embebida en una ventana, desde la que el usuario podrá acceder a la página web donde se supone que encontrará más información. Desconexión de la red/ Fin de la aplicación Un usuario puede decidir si desconectarse a la red para volver a conectarse con otra configuración o terminar la aplicación.

2.5 Modelo de la aplicación La aplicación implementa el Modelo Vista-Controlador (ver Nota), pues separa la presentación, el controlador y los datos.


101

Figura 22 Modelo de la aplicación El usuario realiza acciones y provoca eventos que pueden estar dirigidos a realizar tres acciones:

� Edición de datos (configurar nodo). � Acciones sobre el propio interfaz (ejecutar cierto archivo, borrar registro del

interfaz gráfico, abrir carpeta compartida). � Acciones de red (conexión, desconexión, búsqueda de archivo o catálogo,

publicación de un catálogo…). Nota:

Modelo Vista Controlador (MVC del inglés Model View Controller) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos:

� Modelo: Ésta es la representación específica del dominio de la información sobre la cual funciona la aplicación. El modelo es otra forma de llamar a la capa de dominio. La lógica de dominio añade significado a los datos; por ejemplo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o portes en un carrito de la compra.

� Vista: Éste presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.

� Controlador: Éste responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.

Figura 23 Modelo Vista Controlador

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: 1 El usuario interactúa con la interfaz de usuario de alguna forma (por

ejemplo, el usuario pulsa un botón).


102

INICIO

¿Conectar a cierta

configuración?

Crear Nueva Configuración

2 El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos.

3 El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario.

4 El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice.

5 La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

2.6 Diagramas de flujo de la aplicación Se muestran ahora varios diagramas de flujo en los que se aprecia el comportamiento de la aplicación según las acciones del usuario. Se utilizan varios diagramas de flujo en las que aparecerán figuras como las siguientes:

: Estado del par : Acción

: Elección o comprobación

1. El primer diagrama es el diagrama principal en el que se muestran las acciones básicas que puede realizar un usuario sobre el interfaz gráfico. El usuario puede crear una nueva configuración, modificarla o conectarse.


103

INICIO

¿Conectar a cierta

configuración?

Crear Nueva

Configuración

Modificar Configuración

NO

¿Contraseña correcta?

SI

NO SI ¿Busqueda por

supernodos? SI

NO

Dar funcionalidad

de catálogos

CONECTADO

Figura 24 Diagrama de inicio 2. El diagrama de flujo CONECTADO es el siguiente. EL usuario puede modificar

una configuración, crear una nueva, abrir la carpeta compartida, desconectarse, buscar un archivo o descargar otro.

CONECTADO

INICIO

¿Desconectarse?

SI

NO

Crear Nueva

Configuración

Modificar Configuración

Mostrar encontrados

Descargar archivo

Buscar archivo

Mostrar descargando

Abrir carpeta

compartida

Figura 25 Diagrama de conexión En el caso de que la conexión se haya configurado mediante supernodos, es preciso añadir al diagrama anterior el siguiente:


104

CONECTADO

Crear catálogo

Editar catálogo

Borrar catálogo

Buscar catálogo

Mostrar catálogosencontrados

Visualizar catálogo

Añadir producto Borrar

producto

Figura 26 Diagrama de conexión. Acciones sobre catálogos

En este diagrama se añade la funcionalidad de búsqueda, creación, modificación y visualización de catálogos.

2.7 Conexión y desconexión del par

Cuando un par se conecta o se desconecta a la red, debe llevar a cabo ciertas acciones que avisen al grupo de que está abandonando o añadiéndose al grupo. Cuando un nodo se conecta a la red de intercambio lo primero que hace es borrar la caché, si la hubiera, que alguna conexión anterior haya podido dejar residual. De esta forma nos aseguramos que no existan anuncios de ficheros o catálogos anteriores. Posteriormente, el par abandona el grupo de forma que sea posible una nueva conexión.

CONECTADO

Borrar caché

Abandonar grupo

INICIO

Figura 27 Diagrama de desconexión a la red


105

Las acciones que el par debe realizar cuando un usuario quiere conectarse con cierta configuración son las siguientes:

INICIO

Borrar caché

¿Existe Grupo?

SI

Ingresar

Crear y publicar

grupo

NO

¿Existe Par Rdv?

NO

SI

Convertirse en Rdv

¿Modo búsqueda por supernodos?

NO

SI

Configurar búsqueda

por propagación

Configurar búsqueda

por Rdv

Configurar propagación

Mostrar y descargar pendientes

CONECTADO

Figura 28 Diagrama de conexión a la red

2.8 Comunicación entre pares en la búsqueda y descarga de archivos y catálogos Cuando un usuario decide realizar una “acción de red” (por ejemplo la búsqueda de un archivo), internamente se implementa un protocolo que permite a los dos pares


106

conectados mediante ciertas tuberías comunicarse. Este protocolo se implementará mediante un intercambio de mensajes entre los dos pares en acción a través de estas tuberías, de una forma totalmente transparente para el usuario. Se van a describir tres protocolos distintos:

� Búsqueda de archivo mediante propagación del mensaje de búsqueda. � Transferencia de archivo. � Transferencia de catálogo.

En el caso en el que se escoja el modo de conexión por supernodos, a la hora de buscar un fichero o catálogo no se produciría una verdadera comunicación entre los pares, pues se produciría entre aquel par conectado como supernodo rendezvous y el par que solitica el fichero/catálogo. Esto es debido a que con este modo de búsqueda, por cada fichero y catálogo se crea un anuncio JXTA, del que el supernodo rendezvous tendrá información (ver apartados 4 y 6 del capítulo 2). En cualquier caso, este comportamiento será explicado con posterioridad. Búsqueda de archivo mediante propagación del mensaje de búsqueda En el siguiente diagrama se muestra como es resuelta una solicitud de búsqueda de un fichero, si la búsqueda se ha configurado como por propagación. Si el par que recibe la solicitud no posee un archivo con las características demandadas, simplemente no envía mensaje BÚSQUEDA_ACK, ahorrando así el uso de la red en casos de búsqueda infructuosa. Es importante resaltar que el envío del mensaje BÚSQUEDA se lleva a cabo por una tubería de propagación, de forma que en principio lo reciben todos los pares que tengan un extremo de entrada de esa tubería. El mensaje BÚSQUEDA_ACK es enviado a través de una tubería uno a uno, pues el emisor conoce en ese caso el identificador del receptor, ya que este se lo envió en el mensaje BÚSQUEDA.

BÚSQUEDABÚSQUEDA

BÚSQUEDA_ACKBÚSQUEDA_ACK

Fichero,Filtros,idNodo

Fichero encontrado, tamaño, Nodo,idNodo

Figura 29 Búsqueda de un fichero

Transferencia de archivo Un fichero se debe dividir en paquetes para su envío cuando su tamaño es mayor de 256 KB. En caso de que esto no suceda se mandaría únicamente un paquete. Realmente lo que se envía son los bytes correspondientes a un paquete del fichero, de forma que en el


107

receptor se añaden los paquetes que se van recibiendo correctamente al fichero final. Ambos mensajes son enviados a través de una tubería segura uno a uno. A continuación se muestra el diagrama de transferencia de un fichero dividido en paquetes en caso de que no se produzcan problemas en la recepción o envío (todos los paquetes llegan en orden y sin pérdida…).

COMENZAR_TRANSFERENCIACOMENZAR_TRANSFERENCIA

TRANSFERENCIATRANSFERENCIA

Fichero,NodoDemandante,HashFichero.PaqueteComienzo

Fichero, NúmeroPaquetesTotal,NumeroPaquete,

TamañoFichero,datos,Nodo,idNodo



Figura 30 Descarga de un fichero

Si ocurre un problema en la red y se pierde un paquete o llega a destiempo se produciría el diagrama de mensajes siguiente, en el que el receptor del fichero solicita la retransferencia de un paquete anterior, y continúa la transferencia como si no hubiera ocurrido ningún problema. Si se solicita una transferencia desde el primer paquete:


108

COMENZAR_TRANSFERENCIACOMENZAR_TRANSFERENCIA



Fichero,NodoDemandante,HashFichero.PaqueteComienzo

Fichero, NúmeroPaquetesTotal,NumeroPaquete,

TamañoFichero,datos,Nodo,idNodo

RETRANSFERENCIA_PAQUETERETRANSFERENCIA_PAQUETE

1

2

NodoDemandante,HashFichero,Fichero.Paquete


1


2

Figura 31 Descarga de un fichero con retransferencia

Transferencia de catálogo Los catálogos no poseen un tamaño mayor de 256 KB, que es el tamaño a partir del cual es preciso enviar por paquetes. Cuando se dice que se envía un catálogo, lo que se envía son los bytes correspondientes a un fichero cxml. Estos bytes son almacenados en la carpeta temporal de Windows, de forma que cuando se decide visualizar se transfoma este fichero y se obtiene un fichero html, que es el que se muestra al usuario. Ambos mensajes son enviados a través de la misma tubería.

COMENZARTRANSFERENCIA

CATALOGO

COMENZARTRANSFERENCIA

CATALOGOTRANSFERENCIA

CATALOGOTRANSFERENCIA

CATALOGO

Catalogo, idNodoDemandante

Catalogo,idNodoPoseedornombreNodoPoseedor

Figura 32 Búsqueda de catálogo


109

2.9 Archivos de la aplicación Es preciso destacar el uso de varios ficheros situados en el directorio de ejecución de la aplicación, cuyo uso es el siguiente:

� datos: este fichero es creado una vez se ha llevado a cabo la configuración del primer perfil y en él se almacenan la información de los distintos perfiles existentes. Permite almacenar varias configuraciones, modificarlas o borrarlas. Posee datos necesarios para la conexión. La estructura en el caso de que existan dos configuraciones “jose” y “luis” es la siguiente:

<?XML version="1.0" encoding="UTF-8"?> <Fs>

<Nodos> <Nodo>

<NombreNodo>jose</NombreNodo> <ContraseÃ±a>ag==</ContraseÃ±a> <CarpetaCompartida>C:\Documents and Settings\Jose Laffitte\Escritorio</CarpetaCompartida> <PuertoTcp>9701</PuertoTcp> <PuertoHttp>9700</PuertoHttp>

</Nodo> <Nodo>

<NombreNodo>luis</NombreNodo> <ContraseÃ±a>av==</ContraseÃ±a> <CarpetaCompartida>C:\ </CarpetaCompartida> <PuertoTcp>9711</PuertoTcp> <PuertoHttp>9710</PuertoHttp>

</Nodo> </Nodos>

</Fs>

� descargas: este fichero almacena información de cada descarga actualmente en proceso. Es creado cada vez que se inicia una descarga y se actualiza cada vez que se recibe un paquete. Por cada paquete recibido, se comprueba que el paquete recibido fuera el de orden esperado, de forma que en caso contrario la aplicación pidiera la retransmisión del paquete esperado. La llegada de paquetes muy cercanos en el tiempo provoca el acceso continuo a este fichero, lo que ha obligado al uso de un semáforo de forma que no se produzcan efectos colaterales en su actualización. En el caso de que tengamos dos ficheros actualmente en descarga, su estructura podría ser la siguiente:

<?XML version="1.0" encoding="UTF-8"?> <Descargando>

<jose> <fichero nombre="nombreFichero1.ext" Hash="2951472960" NodoDescarga="urn:jxta:uuid-59616261646162614E50472050325033F7700AA2BF21402084D89A8E262E62ED03" NumeroPaquetesTotal="58"


110

NumeroPaqueteDescargado="22" HoraUltimoPaquete="1163594431089" /> <fichero nombre=" nombreFichero2.ext " Hash="2177153969" NodoDescarga="urn:jxta:uuid-59616261646162614E50472050325033F7700AA2BF21402084D89A8E262E62ED03" NumeroPaquetesTotal="203" NumeroPaqueteDescargado="6" HoraUltimoPaquete="1163594430999" />

</jose> </Descargando> Existe un elemento por cada configuración que tiene ficheros en descarga, y un elemento por cada fichero. Cada elemento de descarga es borrado cada vez que se completa una descarga. Por otra parte, este fichero permite retomar descargas que se han visto interrumpidas en una conexión anterior (porque por ejemplo el usuario se desconectó) en cada nueva conexión.

� Registro de acontecimientos.log: este fichero funciona como un registro de acontecimientos de la aplicación. En el se reflejan aquellos hechos relevantes que se han ido produciendo, como la conexión/desconexión de un par, el comienzo de la bajada de un fichero, de subida, posibles errores… Con objeto de que no aumente indefinidamente, cada vez que el fichero alcanza una longitud máxima de 75 KB es borrado.

� Transformaciones\transformadorCXML-HTML.xslt: este fichero no es creado por la aplicación sino que viene incluida en ella. Transforma los documentos cxml que llegan a la aplicación al pretender un usuario visualizar cierto catálogo en un fichero html, listo para ser visualizado en el explorador. Su estructura es la siguiente:

<?XML version="1.0" encoding="ISO-8859-15"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="html" encoding="ISO-8859-15"/> <xsl:template match="/"> <html> <head/> <body> <br/> <h2 align="center"> Proveedor <table border="1"> <tr><td><span style="font-weight:bold; ">Proveedor:</span></td><td><xsl:value-of select="Index/Supplier/Name"/></td></tr> <tr><td><span style="font-weight:bold; ">Correo:</span></td><td><xsl:value-of select="Index/Supplier/SupplierLocation/Address/Email"/></td></tr> <tr><td><span style="font-weight:bold; ">Página web:</span></td><td><a><xsl:attribute name="href"><xsl:value-of select="Index/Supplier/SupplierLocation/Address/URL"/></xsl:attribute><xsl:


111

value-of select="Index/Supplier/SupplierLocation/Address/URL"/></a></td></tr> </table> </h2> <br /> <br /> <xsl:for-each select="Index/IndexItem/IndexItemAdd"> <h2 align="center"> Artículo <xsl:value-of select="ItemID/SupplierPartID"/> <table cellspacing="2" cellpadding="2" border="1"> <span style="font-weight:bold; "> <tr><td>Precio:</td> <td><xsl:value-of select="ItemDetail/UnitPrice"/> euros</td> </tr> <tr> <td>Descripción del producto:</td> <td><xsl:value-of select="ItemDetail/Description"/></td> </tr> <tr> <td>Características del producto:</td> <td><xsl:value-of select="ItemDetail/Classification"/></td> </tr> <tr> <td>Tiempo de validez de la venta: </td> <td>del <xsl:value-of select="substring-before(IndexItemDetail/ExpirationDate,'T')"/> al <xsl:value-of select="substring-before(IndexItemDetail/EffectiveDate,'T')"/></td> </tr> </span> </table> </h2> </xsl:for-each> <br /> </body>

� Configuracion.properties: Este fichero almacena valores de distintas propiedades. Puede ser modificado manualmente por el usuario o administrador, de forma que la aplicación cada vez que necesite conocer alguna propiedad obtendría el último valor referido. Por defecto, el fichero tiene el siguiente aspecto:

## # # Fichero de configuración #


112

## ARCHIVOLOG = Registro de acontecimientos.log FICCONFIG = datos DESCARGAS = descargas CATALOGOS = catalogos TRANSFORMADORXSLT = Transformaciones\\transformadorCXML-HTML.xslt

3 Organización de la aplicación Ahora se va a proceder a explicar las clases que se han utilizado de una forma detallada, una vez que se han explicado los conceptos claves de la aplicación. De esta forma, se adquirirá un conocimiento exhaustivo de su funcionamiento, pero si entrar en detalles de código. Los paquetes de la aplicación son los siguientes:

� aplicacionFs Aglutina las clases que representan la interfaz gráfica de la aplicación.

� aplicaciones.catalogos Aglutina las clases que representan la interfaz gráfica referida a catálogos.

� com.eventos Aglutina los eventos que permiten mostrar en la ventana principal los nodos y los catálogos existentes.

� com.jxta Aglutina las clases que permiten iniciar JXTA.

� com.jxta.anuncios Aglutina las clases que representan y publican el anuncio de cada fichero, utilizado cuando durante la conexión se selecciona el modo de búsqueda por supernodos.

� com.jxta.anuncios.catalogos Aglutina las clases que representan y publican el anuncio de cada catálogo, utilizado cuando durante la conexión se selecciona el modo de búsqueda por supernodos.

� com.jxta.comunicaciones Aglutina las clases que sirven de soporte de comunicaciones del par cuando el usuario decide buscar o descargar un archivo, o bien cuando un nodo demanda a este nodo información de búsqueda o que comience la transferencia.

� com.jxta.comunicaciones.catalogos Aglutina las clases que sirven de soporte de comunicaciones del par cuando el usuario decide buscar o visualizar un catálogo, o bien cuando un nodo demanda a este nodo información de búsqueda o visualización de un catálogo que posee este usuario.

� com.utilidades


113

Posee clases que aportan distinta funcionalidad, como las que permiten la escritura y lectura del fichero de descargas, del de propiedades, del de catálogos, que permiten la codificación 64 de un fichero o una cadena, que permiten la escritura del fichero de acontecimientos, implementan el semáforo necesario para gestionar el acceso al fichero de descargas o permiten el borrado de un fichero o directorio.

� com.utilidades.entidad Posee las clases que representan un objeto descarga o catálogo.

� com.utilidades.excepcion Posee las clases utilizadas como excepciones personalizadas de la aplicación.

� com.utilidades.transformaciones Posee la clase que permiten transformar los catálogos recibidos para su visualización como cxml en código html.

3.1 Paquete aplicacionFs Este paquete incorpora todas las clases que permiten la representación del interfaz gráfico de la aplicación. Para mostrar el icono correspondiente en la bandeja de iconos se utiliza la librería JDIC (Java Desktop Integration Component).

3.1.1 Clase PincipalFrame

Esta clase representa la ventana principal de la aplicación, donde se gestionan las peticiones del usuario, como la conexión, desconexión, búsqueda de un archivo/catálogo descarga de un archivo/catálogo, apertura de la carpeta compartida. Además se visualiza en ella también los acontecimientos que se van sucediendo y se van almacenando en el registro desde la conexión. Gestiona además los eventos que se producen cada vez que se recibe un paquete de un archivo. Ofrece así mismo acceso a las ventanas que permiten la edición y búsqueda de catálogos. Se actualiza cada vez que se crea un nuevo perfil o se crea y se publica un nuevo catálogo. Permite por otra parte realizar ciertas acciones sobre aquellos archivos que hayan sido completamente descargados, como la eliminación (imaginando el caso en el que el usuario se equivocó al descargarse cierto archivo) o la ejecución del archivo. Además, permite al usuario recomenzar una transferencia si este observa que se ha perdido.

3.1.2 Clase ConfiguraNodoFrame

Representa la ventana que permite crear un nuevo perfil (configurar un nuevo nodo). Este nuevo perfil constará de:

• Nombre. • Contraseña. • Carpeta compartida. • Puerto Http. • Puerto Tcp.


114

3.1.3 Clase ConexionFrame

Representa la ventana de confirmación de conexión. En ella el usuario debe introducir la contraseña adecuada y escoger entre uno de los dos posibles modos de búsqueda, mediante propagación o mediante supernodos.

3.1.4 Clase DesconexionFrame

Representa la ventana que aparece cuando el usuario decide terminar la aplicación o desconectarse. En esta ventana el usuario debe confirmar la desconexión.

3.2 Paquete aplicaciones.catalogos

Este paquete incorpora las clases que permiten buscar, editar, modificar y borrar un catálogo. Para mostrar el icono correspondiente en la bandeja de iconos se utiliza la librería JDIC (Java Desktop Integration Component).

3.2.1 Clase BusquedaCatalogoFrame

Ofrece al usuario el interfaz en el que poder introducir parámetros de búsqueda de un catálogo, y donde muestran los catálogos encontrados. De entre estos catálogos encontrados el usuario puede escoger y visualizar el catálogo que desee.

3.2.2 Clase EditarCatalogoFrame

Ofrece la ventana en la que un usuario puede crear un nuevo catálogo. En esta ventana sólo se puede incluir un producto en el catálogo, de forma que si se desean incluir más es preciso utilizar la ventana de visualización del catálogo, a la que se llega cuando un usuario quiere modificar un catálogo. De hecho, esta clase también es utilizada cuando se quiere añadir un producto al catálogo, aunque esta vez habrá ciertos parámetros que no serán configurables. Así, los parámetros que son configurables son:

• Correo de contacto. • Dirección web. • Catálogo, especifica el nombre del catálogo al que es debido darle un nombre

de más de cuatro letras. • Producto. • Precio. • Tipo de producto. • Descripción. • Tiempo en venta.

Los tres primeros parámetros no son configurables en caso de que se quiera añadir un producto al catálogo.

3.2.3 Clase ModificarProductoFrame

Ofrece la ventana que permite modificar el producto de un catálogo. Los parámetros que son modificables son:

• Producto.


115

• Precio. • Tipo de producto. • Descripción. • Tiempo en venta.

3.2.4 Clase VisualizarCatalogoDescargado

Ofrece la ventana en cuyo interior se muestra una página html resultante de la transformación del catálogo en formato html mediante un transformador xslt. En esta ventana se incrusta el explorador por defecto del sistema (si está configurado para que sea el Internet Explorer o el Mozilla Firefox) y es a través de este programa que se visualiza la página web. Para el usuario este método de representación es totalmente transparente, de forma que no se daría cuenta de que esta visualizando un explorador de Internet hasta que pinchase sobre el enlace que se incluye en la página web del catálogo. Para incrustar el explorador en la ventana se utiliza la librería JDIC (Java Desktop Integration Component).

3.2.5 Clase VisualizarCatalogoFrame

Ofrece la ventana en la que se observan todos los productos de un catálogo y que permite tanto la eliminación de productos como el acceso a ventanas para la modificación o creación de otros.

3.3 Paquete com.eventos

Este paquete declara ciertos eventos que se producen cuando un usuario pulsa sobre el nombre de un catálogo (para editarlo o para borrarlo) o sobre el nombre de un nodo (para conectarse a la red mediante este perfil o para modificarlo).

3.3.1 Clase GestorEventosAñadirACatalogo

Añade la funcionalidad por la que al cliquear sobre un catálogo aparece la ventana de visualización del mismo (VisualizarCatalogoFrame).

3.3.2 Clase GestorEventosBorrarCatalogo

Añade la funcionalidad a la aplicación por la que un usuario puede borrar un catálogo desde la ventana principal.

3.3.3 Clase GestorEventosConectarNodos

Añade la funcionalidad a la aplicación por la que cuando un usuario cliquea sobre un nodo pretendiendo conectarse por este perfil aparece la ventana de conexión, en la que es preciso introducir la contraseña correcta y escoger el modo de búsqueda que se utilizará (ConexionFrame).

3.3.4 Clase GestorEventosConfigurarNodos

Añade la funcionalidad por la que cuando un usuario quiere modificar cierto perfil aparece la ventana de modificación de nodo (ConfiguraNodoFrame).


116

3.4 Paquete com.jxta

Este paquete contiene dos clases que permiten configurar la plataforma, el par que se conecta y sirven de puente entre la interfaz gráfica y las clases que implementan el protocolo de comunicaciones.

3.4.1 Clase ConfiguraPlataforma

Esta clase establece la configuración de la plataforma: el nombre, la contraseña y los puertos Tcp y Http del par que se conecta. Así mismo, establece el par como edge-peer (par con plenas capacidades).

3.4.2 Clase Nodo

Esta clase llama a la clase anterior ConfiguraPlataforma y sigue el esquema de conexión anteriormente expuesto. Lo primero que hace es borrar la caché, de forma que los anuncios que encuentre en el futuro sean los existentes (al menos en el momento de la conexión). Además comprueba que exista el grupo, de forma que si no es así lo crea y lo publica. En caso de que si existe se adhiere a él. Posteriormente busca si existe algún par rendezvous y se adhiere a él, y en caso contrario él mismo se invierte en un par rendezvous. Después comprueba establece las clases que se dedicarán a la búsqueda, según el modo que se haya escogido. Y finalmente inicializa la clase que se dedicará a la transferencia de mensajes y muestra y comienza la descarga de aquellos ficheros que no se hayan terminado de descargar. Además, como se ha dicho esta clase sirve de puente entre el interfaz gráfica que el usuario utiliza para llevar a cabo acciones de la aplicación y las clases que propiamente se encargan de las funciones de red de ésta, como por ejemplo la búsqueda y la transferencia. Para ello ofrece métodos que serán invocados desde ciertas ventanas (PrincipalFrame y BusquedaCatalogoFrame).

3.5 Paquete com.jxta.anuncios

Este paquete contiene clases que permiten la publicación de anuncios de ficheros en la red.

3.5.1 Clase AnuncioFichero

Contiene la clase que representa un anuncio de un fichero. Este anuncio es publicado como un recurso de Jxta, y de esta forma puede ser descubierto por otros pares si es publicado remotamente y si es publicado localmente puede ser descubierto por el propio nodo o por un nodo rendezvous. La indexación de este anuncio (y por tanto también la búsqueda) se podrá realizar a partir del nombre del fichero que representa.

3.5.2 Clase PublicaAnunciosFicheros

Clase encargada de publicar los anuncios localmente de cada fichero presente en la carpeta compartida cuando este se conecta. La publicación se lleva a cabo localmente de forma que los únicos nodos capaces de descubrir el anuncio serían el propio nodo donde es publicado y aquellos nodos rendezvous a los que el nodo está adscrito.

3.6 Paquete com.jxta.anuncios.catalogos


117

Este paquete contiene clases que permiten la publicación de anuncios de catálogos en la red.

3.6.1 Clase AnuncioCatalogo

Clase que representa un anuncio de un fichero. Este anuncio es publicado como un recurso de jxta, y de esta forma puede ser descubierto por otros nodos si es publicado remotamente y si es publicado localmente puede ser descubierto por el propio nodo o por un nodo rendezvous. La indexación de este anuncio (y por tanto también la búsqueda) se podrá realizar a partir del nombre del catálogo que representa y por futuras mejoras de la aplicación a partir del nombre del proveedor.

3.6.2 Clase PublicaAnunciosCatalogos

Clase encargada de publicar los anuncios localmente de cada catálogo definido por el proveedor cuando este se conecta. La publicación se lleva a cabo localmente de forma que los únicos nodos capaces de descubrir el anuncio serían el propio nodo donde es publicado y aquellos nodos rendezvous a los que el nodo está adscrito.

3.7 Paquete com.jxta.comunicaciones

Este paquete contiene clases que se permiten la comunicación con otros pares para la búsqueda y descarga de archivos.

3.7.1 Clase GestorBusquedaPropagacion

Clase que permite realizar una búsqueda de un fichero mediante propagación. Esta búsqueda se lleva a cabo mediante Multicast en la red local y con la intervención de los rendezvous fuera de esta. Los rendezvous ayudan a transmitir las peticiones a través de las barreras de Internet (NAT, cortafuegos…). Este algoritmo sólo es capaz de buscar ficheros en otros nodos que hayan escogido el modo de búsqueda como propagación al conectarse. Existen dos tuberías utilizadas por esta clase.

• En primer lugar una tubería de propagación (uno a muchos) por la que se envían y se reciben solicitudes de búsqueda (BÚSQUEDA).

• En segundo lugar una tubería (uno a uno) por la que, en caso de que se tenga el fichero demandado, se envía un mensaje de búsqueda exitosa (BÚSQUEDAACK). Cuando se utiliza esta tubería, ya es conocido el identificador JXTA del par que posee el fichero.

Al instanciar esta clase se comprueba si las tuberías existen. Si no es así, las crea y las publica. Posteriormente declara un extremo de entrada para cada una, de forma que ya esté preparado para la recepción de mensajes. Posee varios métodos:

• Un método que envía un mensaje de búsqueda solicitando un fichero.


118

• El método pipeMsgEvent, asociado a un evento que se dispara cuando se recibe un mensaje por la tubería. En caso de que se tenga el fichero demandado este mismo método envía el mensaje por este mismo método.

• Un método que busca un fichero en la carpeta compartida.

3.7.2 Clase GestorBusquedaRdv

Clase que permite realizar una búsqueda de un fichero mediante supernodos rendezvous. En caso de que la conexión se haga por supernodos el nodo habrá publicado localmente un anuncio de cada fichero que comparte al conectarse. Cuando el usuario decide realizar una búsqueda, en primer lugar comprueba si existe un anuncio en su caché que contenga un anuncio con esas características y posteriormente le pregunta al nodo. Este nodo rendezvous mantiene una lista de anuncios indexados que le permiten saber donde se encuentra un anuncio, con lo cual comunica al nodo que esta buscando la localización del anuncio, de donde obtiene la información del fichero. Esta clase sólo es capaz de buscar ficheros en otros nodos que hayan escogido el modo de búsqueda como por supernodos al conectarse. Posee dos métodos,

• Un método que se ocupa de buscar el anuncio. • Un segundo método que está asociado al evento producido al descubrir algún

anuncio.

3.7.3 Clase GestorTransaccion

Clase que gestiona el envío y recepción de ficheros. Es independiente del método de búsqueda utilizado. Esta clase utiliza una única tubería para la transferencia de un archivo. Cuando se instancia un objeto de esta clase, se comprueba que exista la tubería que se utiliza para el intercambio de mensajes. En caso contrario la crea y la publica. Cuando se envía una petición de transferencia de un archivo se utiliza un mensaje en el que se incluye:

• El nombre del fichero. • El identificador del par solicitante. • El hash del fichero (en caso de que se solicite una retransferencia de cierto

paquete). • Y el paquete que se desea recibir.

El método pipeMsgEvent está asociado al evento producido cuando se recibe un mensaje, de forma que al recibir un mensaje comprueba si es un mensaje de petición (COMENZARTRANSFERENCIA) o un mensaje de recepción de un paquete (TRANSFERENCIA). Cuando se envía un paquete, éste va incorporado en un mensaje con los siguientes campos:

• Nombre del fichero. • Tamaño del fichero. • Hash del fichero. • Número de paquetes total. • Número de paquete actual. • Identificador jxta del par poseedor.


119

• Nombre del par poseedor. • Bytes del paquete.

El fichero será enviado en paquetes si su tamaño total supera los 256 KB. Este valor límite no proviene de ninguna especificación de JXTA, y se propuso al comprobar que para valores mayores la descarga podía tener problemas y no finalizaba correctamente. Por cada paquete recibido se actualiza el fichero descargas, de forma que al recibir el fichero completo se procede al borrado de la información relativa a ese fichero, ya inservible.

3.8 Paquete com.jxta.comunicaciones.catalogos

Este paquete contiene clases que se permiten la comunicación con otros pares para la búsqueda y visualización de catálogos provistos por otros usuarios.

3.8.1 Clase GestorBusquedaCatalogoRdv

Clase que permite realizar la búsqueda de un catálogo mediante supernodos. En caso de que la conexión se haga por supernodos el nodo publica localmente un anuncio de cada catálogo que previamente haya creado el proveedor. Cuando el usuario decide realizar una búsqueda, mira si en su caché local existe algún anuncio que cumpla tales características y pregunta al nodo. Este nodo rendezvous mantiene una lista de índices de anuncios indexados que le permiten saber donde se encuentra un anuncio, con lo cual comunica al nodo que esta buscando la localización del anuncio, de donde obtiene la información del catálogo. Posee dos métodos:

• Un método que se ocupa de buscar el anuncio. • Un segundo método que está asociado al evento producido al descubrir algún

anuncio.

3.8.2 Clase GestorTransaccionCatalogoRdv

Clase que gestiona el envío y recepción de catálogos. Utiliza una única tubería para la transferencia de catálogos. Cuando se instancia un objeto de esta clase, se comprueba que exista la tubería que se utiliza para el intercambio de mensajes. En caso contrario la crea y la publica. Cuando un usuario quiere visualizar un catálogo, se envía una petición de transferencia del catálogo al par proveedor y se utiliza un mensaje en el que se incluye:

• El nombre del catálogo. • El identificador del par solicitante.

El método pipeMsgEvent está asociado al evento producido cuando se recibe un mensaje, de forma que al recibir uno, comprueba si es un mensaje de petición (COMENZARTRANSFERENCIACATALOGO) o un mensaje de recepción de un paquete (TRANSFERENCIACATALOGO).


120

Cuando se envía un paquete, éste va incorporado en un mensaje con los siguientes campos:

• Nombre del catalogo. • Identificador jxta del par poseedor. • Nombre del par poseedor. • Bytes del catálogo.

Una vez es recibido el catálogo se almacena en la carpeta temporal con extensión cxml. Una vez almacenado es transformado mediante el archivo Transformaciones\transformadorCXML-HTML.xslt, que almacena, de igual forma, el HTML generado en la carpeta temporal. Este html es el mostrado posteriormente en una ventana que tiene incrustado el explorador por defecto.

3.9 Paquete com.utilidades

Este paquete contiene clases de funcionalidad muy diversa.

3.9.1 Clase AlmacenCatalogos

Clase que permite gestionar la creación, manipulación, visualización y borrado de catálogos. Cuando un usuario crea un catálogo lo que hace es crear un fichero cxml en la carpeta directorio de la aplicación/catalogos con nombre el que se ha dado al catálogo. Cuando un usuario decide modificar un catálogo de cualquier forma añadiendo, borrando o modificando productos lo que hace es modificar el fichero cxml que representa el catálogo. Esta clase provee a la aplicación métodos para la creación, modificación y extracción de información de un catálogo.

3.9.2 Clase AlmacenDescargas

Clase que se ocupa de gestionar el acceso al fichero de descargas (que consistirá en un "historial" de los archivos en proceso de descarga), de forma que la recuperación y actualización de información sea eficiente. Provee de métodos que permiten añadir, modificar, obtener y borrar descargas. Por cada aplicación existe un objeto de esta clase que gestionará el acceso al fichero. Debido a que pueden acceder a este objeto varios hilos (por ejemplo si se está produciendo la descarga de varios ficheros al mismo tiempo) en un espacio muy corto de tiempo se hizo necesario el uso de una variable semáforo en la clase, que permitiese dormir un hilo si intentaba acceder al fichero cuando este estaba siendo tratado por otro hilo. De esta forma, en caso de que un hilo intente acceder al fichero cuando éste está siendo accedido por otro anterior, se duerme. El semáforo se inicializa a uno en el contructor de la clase y cada vez que se intenta acceder al recurso se baja el semáforo, y se vuelve a subir cuando se terminó el acceso. Este semáforo se implementa mediante la clase Semáforo explicada más adelante.

3.9.3 Clase AlmacenPropiedades

Clase que ofrece al resto de clases el acceso al fichero de propiedades. Provee de métodos que permiten obtener valores almacenados en el fichero de propiedades. Estos valores son:


121

• ARCHIVOLOG

• FICCONFIG

• DESCARGAS

• CATALOGOS

• TRANSFORMADORXSLT

En caso de que se no se encuentre una propiedad con cierto nombre salta una excepción controlada.

3.9.4 Clase Base64Codificador

Clase que provee de métodos para la codificación y decodificación de cadenas de texto o arrays de bytes en formato base 64 como es descrito en la norma RFC 1521.

3.9.5 Clase CheckSum

Clase que permite la obtención la suma de control CRC32 de un flujo de datos o de una cadena de texto. Proporciona métodos que permiten obtener un código único de un fichero o de una cadena de texto, que es el que se envía como hash del fichero el poseedor del mismo en las descargas. Además, se utiliza en la creación de un anuncio de fichero o catálogo para obtener un código unívoco del mismo.

3.9.6 Clase FicheroLog

Clase que permite la escritura de acontecimientos en el archivo de acontecimientos. Posee dos métodos, que aceptan diferentes parámetros según sean éstos necesarios para la escritura. Los objetos que hacen uso de estos métodos deben especificar el tipo de información que se va a almacenar, según una variable de tipo entero que se le pasa como parámetro. Así, los valores posibles de esta variable y su significado son los siguientes:

� -1: Se ha producido un error y la información es el texto de la excepción. � 1: Se ha producido la conexión de un usuario y la información es el nodo de la

conexión. � 2: Se ha producido la desconexión de un usuario y la información es el nodo de

la desconexión. � 3: Se ha enviado una petición de búsqueda y la información es el nombre del

fichero. � 4: Se ha recibido una petición de búsqueda y la información es el fichero de

búsqueda y el nodo solicitante. � 5: Se ha encontrado un fichero solicitado y la información es el fichero de

búsqueda y el nodo poseedor. � 6: Se ha recibido una respuesta a una petición de búsqueda y la información es el

fichero de búsqueda y el nodo poseedor. � 7: Se ha enviado una petición de transferencia de cierto fichero y la información

es el fichero de búsqueda y el nodo solicitante.


122

� 8: Se comienza la transferencia de un fichero y la información es el fichero de búsqueda y el nodo poseedor.

� 9: Se comienza la transferencia de un fichero y la información es el fichero de búsqueda y el nodo poseedor.

� 10: Se finaliza la transferencia de un fichero y la información es el fichero de búsqueda y el nodo poseedor.

� 11: Se finaliza la recepción de un fichero y la información es el fichero de búsqueda y el nodo destino.

3.9.7 Clase FiltroFichero

Clase que permite implementar un filtro para ficheros según su extensión. Este filtro puede consistir en una única extensión o en un array de extensiones. Posee dos métodos que devolverán trae si el fichero que se le pasa como parámetro posee la/las extensiones requeridas.

3.9.8 Clase Semáforo

Clase que implementa un semáforo, permitiendo administrar el acceso a un recurso compartido y sincronizar varios procesos. Posee un método de bajada que duerme el proceso llamante si el semáforo vale cero o menos y un método de subida que, además de incrementar el semáforo en caso de que su valor fuera superior a cero, despierta a uno de los hilos durmientes.

3.9.9 Clase UtilesDirectorio

Clase abstracta que proporciona métodos de manejo de directorios y ficheros. Proporciona dos métodos muy simples que permiten borrar un fichero o un directorio con todos sus subdirectorios

3.10 Paquete com.utilidades.entidad

Este paquete ofrece clases que permiten manejar con más facilidad y de una manera más intuitiva las entidades que conforman un catálogo y una descarga.

3.10.1 Clase Catalogo

Clase que representa un producto de un catálogo. Facilita el manejo de información referente a los catálogos. Ofrece métodos que permiten abstraer el concepto de producto en un objeto, de forma que su manejo sea más sencillo. Las características son declaradas de forma privada pero contiene métodos que permiten la obtención y modificación de estas características (get y set). Estas características son las siguientes:

� Email: Correo electrónico del proveedor del catálogo. � DireccionWeb: Dirección web del proveedor del catálogo. � Producto: Nombre del producto. � Precio: Precio del producto. � TipoProducto: Tipo de producto. � DescripcionProducto: Descripción del producto. � TiempoEfectivo: Tiempo efectivo de la venta del producto. � TiempoExpiracion: Tiempo de expiración de la venta del producto.


123

3.10.2 Clase Descarga

Clase que representa una descarga de un fichero. Facilita el manejo de información referente a una descarga. Ofrece métodos que permiten abstraer el concepto de descarga, de forma que su manejo sea más sencillo. Esta clase posee características declaradas de forma privada pero contiene métodos que permiten la obtención y modificación de estas características (get y set). Estas características son las siguientes:

� FicheroOrigen: Nombre del fichero en el nodo original. � FicheroDescargando: Nombre del fichero descargando. � IdNodoOrigen: Identificador JXTA del nodo origen. � Hash: Código hash del fichero. � NumeroPaquetesTotal: Número de paquetes que conforman el fichero. � NumeroPaquetesDescargados: Número de paquetes descargados. � HoraUltimoPaquete : Hora de llegada del último paquete

3.11 Paquete com.utilidades.excepciones

Este paquete contiene las excepciones personalizadas para la aplicación.

3.11.1 Clase FaltaPropiedadExcepcion

Esta clase representa la excepción que se produce cuando se intenta obtener el valor de cierta propiedad no existente del fichero de propiedades Configuración.properties.

3.12 Paquete com.utilidades.transformaciones

Este paquete contiene clases que permiten obtener a partir de un fichero dado en un formato en otro fichero con otro formato.

3.12.1 Clase TransformarXML

Esta clase contiene un método que permite obtener un fichero html tomando como origen de datos un fichero XML a partir de un transformador xslt que se le pasa como parámetro.

4. Diagrama de clases de la aplicación A continuación se muestran varios diagramas de clases que en conjunto constituyen el diagrama de la aplicación completa. Con objeto de simplificar estos diagramas, se han omitido en ellos los atributos y los métodos que poseen. En cualquier caso, se adjunta en el cd del proyecto un conjunto de páginas Html en las que se puede visualizar el diagrama completo y navegar por él.


124

En el primer diagrama se muestra el primer grupo de clases y paquetes. Este grupo sirve de apoyo a las clases principales y llevan a cabo tareas secundarias, pero no por ello menos importantes.

Figura 33 Diagrama de clases I


125

En el siguiente diagrama se muestran las clases utilizadas en todo lo referente a edición y búsqueda de catálogos.

.


126

Figura 34 Diagrama de clases II En el siguiente diagrama se muestran las clases principales involucradas en la configuración de perfiles de conexión, en la conexión y en la búsqueda de archivos:

Figura 35 Diagrama de clases III

CAPÍTULO 6: Conclusiones y líneas de trabajo futuro

El objetivo de este proyecto era el estudio y consideración del conjunto de protocolos JXTA y su adecuación al comercio electrónico. Para ello, se realizó una aplicación de compartición de ficheros que sirviera de iniciación a las tecnologías que se iban a utilizar. Pero debido a la complejidad que fue adquiriendo esta aplicación, constituyó en sí misma la base del proyecto. La aplicación no utiliza ni mucho menos todas las posibilidades que ofrece JXTA, pues a medida que el proyecto ha ido avanzando se han ido descubriendo cada vez más nuevas características, pero aglutina mucha funcionalidad implementada por los protocolos. De hecho, es al final del proyecto cuando el desarrollador ha tomado consciencia de todas las posibilidades que ofrece JXTA. P2P ofrece una alternativa a la arquitectura tradicional de Internet (el modelo cliente-servidor) pero ambos modelos se complementan y no suponen una alternativa entre ellos. La red del presente y del futuro tomará características de ambas arquitecturas y la evolución de la red irá de la mano de la evolución de ambos modelos. JXTA sufre un continuo proceso de desarrollo en el que los desarrolladores del proyecto están dándole un gran impulso. De esta forma JXTA 2.0 aporta al desarrollador una cantidad innumerable de herramientas que abstraen de la complejidad de la red al desarrollador, de forma que éste se deba ocupar sólo del nuevo desarrollo o el perfeccionamiento de nuevas aplicaciones. Aunque no por ello deja de ser importante y esencial llegar a dominar los conceptos que los protocolos utilizan y los procesos que internamente son llevados a cabo. A pesar de todo, no constituye, como es habitual en el ámbito en el que versa este proyecto, la solución definitiva al P2P. cXML ha sido un lenguaje muy cómodo e intuitivo de implementar y proporciona ante todo sencillez. Se ha comprobado que la mayoría de los lenguajes de comercio electrónico proporcionan muchos modelos y filosofías de implantación, pero si se quiere implementar transacciones de forma sencilla y totalmente libre, la única opción que queda es cXML. Es posible que en ese campo resida su futuro, como lenguaje para relaciones comerciales sencillas. Finalmente, la aplicación desarrollada ofrece al usuario un interfaz de aspecto sencillo en el que es posible el intercambio de archivos de una manera sencilla y muy visual. Se han obtenido resultados satisfactorios de pruebas entre ordenadores situados a ambos extremos de ciertas barreras de la red, como cortafuegos y routers. Además, abstrae de la complejidad de la red al usuario y le ofrece, por otro lado, un servicio de edición de catálogos propios y de búsqueda de catálogos ajenos, constituyendo el primer paso hacia posibles aplicaciones de comercio electrónico más desarrolladas.

Capítulo 5: Conclusiones y líneas de trabajo futuro Memoria

128

En cuanto a posibles mejoras futuras, se proponen dos líneas a seguir:

• Mejoras de la aplicación de compartición de ficheros: o Como se explicó en el apartado 5.3.2 Problemas surgidos, sería

importante el testeo de la aplicación a gran escala, de forma que intervinieran multitud de ordenadores de múltiples sistemas operativos.

o Sería posible añadir más funcionalidad al interfaz gráfico de forma que el usuario dispusiese por ejemplo, de estadísticas de uso, de intercambio de mensajes mediante la aplicación, limitación de velocidades, bloqueo de descargas… en general, se podría aglutinar en una única aplicación los distintos aspectos del P2P tales como el intercambio de archivos, de mensajes, comunicación telefónica, algún tipo de programación distribuida…

• Mejoras de la aplicación de edición y búsqueda de catálogos:

o Como se ha comentado anteriormente, esta parte de la aplicación no desarrolla una línea de trabajo completa ni utiliza toda la funcionalidad aportada por CXML. Podría desarrollarse un sistema completo de búsqueda de catálogos y compra de productos utilizando este estándar y partiendo como base esta aplicación.

o Utilizar como estándar de comercio Ebxml en lugar de Cxml.

130

Bibliografía A continuación se citan la bibliografía y enlaces web más importantes utilizados en el desarrollo de la aplicación y de la documentación:

• P2P o Wikipedia: http://es.wikipedia.org/wiki/Peer-to-peer.

http://es.wikipedia.org/wiki/EMule o “Securing IM and P2P applications for the enterprise“, de Paul Piccard. o http://www.zonap2p.com/ o http://www.amule.org/wiki/index.php/FAQ_ed2k-es o http://www.indicare.org/tiki-read_article.php?articleId=26

• JXTA o “JXTA: Java P2P Programming”, Daniel Brookshier, D.Govoni, N.

Krishnan. o “JXTA in a Nutshell”, S. Oaks, B. Traversat, Li Gong. o http://www.jxta.org

� “JXTA programmers guide”

� “JXTA-Getting-Started” o http://www.ia.escet.urjc.es/grupo/docencia/as

o http://java.sun.com/developer/technicalArticles/Networking/jxta2.0/index.html

o http://wiki.java.net/bin/view/Jxta

• CXML o http://www.cxml.org: Guía del usuario de CXML

• XML o http://flanagan.ugr.es/XML/XML.htm

• XSL o http://geneura.ugr.es/~jmerelo/XSLT/XSLT-WML-2001.htm o http://www.zvon.org/xxl/XSLTutorial/Books/Book1/index.html

• JDIC o http://www.ciol.com/content/search/showarticle1.asp?artid=63396

131

Glosario de términos En este documento se han utilizado multitud de acrónimos informáticos. A continuación, se muestran ordenados alfabéticamente para una fácil consulta: API: Application Program Interface CPU: Central Processor Unit CSS: Cascading Style Sheets cXML: Commerce XML DHT: Distributed Hash Table DLL: Dynamic Link Library DNS: Domain Name System DOM: Document Object Model DTD: Document Type Definition FTP: File Transfer Protocol HTML: HyperText Markup Language HTTP: HyperText Transfer Protocol IIS: Internet Information Services IP: Internet Protocol ISO: International Organization for Standardization J2ME: Java 2 Micro Edition J2SE: Java 2 Standard Edition JAR: Java Archive JDIC : Java Desktop Integration Components JDK: Java Development Kit JDOM: Java DOM JRE: Java Runtime Environment JSP: Java Server Pages JXTA: Juxtapose JVM: Java Virtual Machine LAN: Local Area Network MVC: Model View Controller NAT: Network Address Translation P2P: Peer-to-Peer SAX: Simple API for XML SDK: Software Development Kit SGML: Standard Generalized Markup Language SMTP: Simple Mail Transfer Protocol S.O.: Sistema Operativo SOAP: Simple Object Access Protocol SQL: Structured Query Language SRDI: Shared Resource Distributed Index SSH: Secure Shell SW: software TCP: Transfer Control Protocol TTL: Time-To-Live UML: Unified Modeling Language UTF-8: 8-bit Unicode Transformation Format

132

URI: Uniform Resource Identifier URL: Uniform Resource Locator URN: Uniform Resource Name VPN: Virtual Private Net W3C: World Wide Web Consortium WWW: World Wide Web XLink: Lenguaje de Enlace XML XML: eXtensible Markup Language XPath: XML Path Language XPointer: XML Pointer Language XQL: XML Query Language XSL: eXtensible Stylesheet Language XSL-FO: XSL Formatting Objects XSLT: XSL Transformations