Articulo de referencia

Protocolo de federación de Google Wave

El Protocolo de Federación Wave (anteriormente Protocolo de Federación Google Wave ) es un protocolo abierto , una extensión del Protocolo de Mensajería y Presencia Extensible (...

El Protocolo de Federación Wave (anteriormente Protocolo de Federación Google Wave ) es un protocolo abierto , una extensión del Protocolo de Mensajería y Presencia Extensible (XMPP) que se utiliza en Apache Wave . Está diseñado para la comunicación casi en tiempo real entre los servidores Wave de trabajo cooperativo asistido por computadora .

Descripción general

El Protocolo de Federación de Ondas, que aún se encuentra en desarrollo, es un protocolo abierto que pretende ser similar en apertura al protocolo de correo electrónico, de modo que las ondas puedan suceder al correo electrónico como la forma dominante de comunicación en Internet. [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]

Disponibilidad

Dado que el protocolo es abierto, cualquiera puede convertirse en proveedor de Wave y compartir Waves con otros. Al igual que con el correo electrónico , la comunicación es posible independientemente del proveedor. Por ejemplo, las organizaciones pueden operar como proveedores de Wave para sus miembros, un individuo puede administrar un servidor privado de Wave para un solo usuario o miembros de su familia, y un proveedor de servicios de Internet puede administrar un servicio de Wave como un servicio de Internet adicional para sus usuarios, como complemento del correo electrónico, la mensajería instantánea , FTP , etc. En este modelo, Google Wave es uno de los muchos proveedores de Wave. [ 4 ] [ 5 ]

El código fuente Java del "Servidor prototipo de federación de Google Wave" se publicó en un repositorio Mercurial en julio de 2009 bajo la licencia Apache 2.0. [ 6 ] [ 7 ]

Estructura

Algunas características del Protocolo de Mensajería y Presencia Extensible (XMPP) heredadas por el protocolo de federación de ondas son el descubrimiento de direcciones IP y números de puerto, mediante registros SRV del Sistema de Nombres de Dominio (DNS) , y la autenticación TLS y el cifrado de conexiones. El transporte XMPP cifra las operaciones a nivel de transporte. Por lo tanto, solo proporciona seguridad criptográfica entre servidores conectados directamente entre sí. Una capa adicional de criptografía proporciona autenticación de extremo a extremo entre proveedores de ondas mediante firmas y certificados criptográficos, lo que permite a todos los proveedores de wavelets verificar las propiedades de la operación. Por consiguiente, un proveedor de ondas descendente puede verificar que el proveedor de ondas no está suplantando operaciones de wavelet. No debería poder afirmar falsamente que una operación de wavelet se originó en un usuario de otro proveedor de ondas o que se originó en un contexto diferente. Esto resuelve la situación en la que dos usuarios de diferentes proveedores de ondas confiables participan en una wavelet alojada en un proveedor malicioso. El protocolo requiere que cada participante firme las operaciones de su usuario con su propio certificado. Las firmas de todas las operaciones reenviadas por el host serán evaluadas por los participantes. Esto sirve para evitar que hosts maliciosos alteren o falsifiquen el contenido de los mensajes de los usuarios de otros servicios. Todas las firmas y verificaciones las realizan los proveedores de Wave, no el software cliente de los usuarios finales. [ 4 ] [ 5 ]

Todas las ondas y wavelets (ondas hijas) se identifican mediante un ID de onda único global, que consiste en un nombre de dominio y una cadena de identificación. El nombre de dominio identifica al proveedor de ondas donde se originó la onda. Las ondas y wavelets son alojadas por el proveedor de ondas del creador. Las wavelets de una misma onda pueden ser alojadas por diferentes proveedores de ondas. Sin embargo, los datos de usuario no se federan; es decir, no se comparten con otros proveedores de ondas. También son posibles las wavelets de respuesta privadas, de las que otros participantes no tienen conocimiento ni acceso. Si se envía una wavelet privada entre usuarios del mismo proveedor de ondas, no se federa independientemente de dónde se aloje la onda principal. [ 4 ] [ 5 ]

Federación concurrente

Un proveedor de ondas opera un servicio de ondas en uno o más servidores en red. Los componentes centrales del servicio de ondas son el almacén de ondas, que almacena las operaciones de ondículas, y el servidor de ondas, que resuelve las operaciones de ondículas mediante transformación operacional y escribe y lee operaciones de ondículas desde y hacia el almacén de ondas. Normalmente, el servicio de ondas proporciona ondas a los usuarios del proveedor de ondas que se conectan a la interfaz del servicio de ondas. Para fines de federación, el servicio de ondas comparte ondas con participantes de otros proveedores comunicándose con los servidores de estos proveedores. Se distribuyen copias de ondículas a todos los proveedores de ondas que tienen participantes en una ondícula determinada. Las copias de una ondícula en un proveedor particular pueden ser locales o remotas. Usamos el término para referirnos a estos dos tipos de copias de ondículas (en ambos casos, nos referimos a la copia de la ondícula, y no a la ondícula en sí). Una vista de ondas puede contener copias de ondículas locales y remotas simultáneamente. [ 4 ] [ 5 ]

El servidor de ondas de origen es responsable del alojamiento y el procesamiento de las operaciones de ondículas enviadas por participantes locales y por participantes remotos de otros proveedores de ondas. El servidor de ondas realiza el control de concurrencia ordenando las operaciones de ondículas enviadas entre sí mediante una transformación operacional. También valida las operaciones antes de aplicarlas a una ondícula local. [ 4 ] [ 5 ]

Las wavelets remotas son alojadas por otros proveedores, almacenadas en caché y actualizadas con operaciones wavelet que el proveedor local recibe del host remoto. Cuando un participante local envía una operación wavelet a una wavelet remota, el servidor wave reenvía la operación al servidor wave del proveedor anfitrión. Luego, la operación transformada y aplicada se devuelve y se aplica a la copia almacenada en caché. [ 4 ] [ 5 ]

Los servicios de ondas utilizan pasarelas de federación y componentes de proxy de federación para comunicarse y compartir ondas con otros proveedores de ondas. Las pasarelas de federación comunican las operaciones de ondículas locales, envían nuevas operaciones de ondículas locales a los proveedores de ondas remotos de cualquier otro participante, satisfacen las solicitudes de operaciones de ondículas antiguas y procesan las solicitudes de envío de operaciones de ondículas. Un proxy de federación comunica las operaciones de ondículas remotas y es el componente de un proveedor de ondas que se comunica con la pasarela de federación de los proveedores remotos. Recibe nuevas operaciones de ondículas enviadas por otros proveedores, solicita operaciones de ondículas antiguas y envía operaciones de ondículas a otros proveedores. [ 4 ] [ 5 ]

Véase también

Referencias

  1. Vídeo en YouTube
  2. "Protocolo de federación de Google Wave" . Archivado del original el 30 de mayo de 2009. Consultado el 29 de mayo de 2009 .
  3. Hachman, Mark (28 de mayo de 2009). "Google reinventa el correo electrónico y los documentos con Google Wave" . www.pcmag.com . Consultado el 2 de junio de 2009 .
  4. 1 2 3 4 5 6 7 8 "Arquitectura de federación de Google Wave - Protocolo de federación de Google Wave" . Archivado del original el 30 de marzo de 2013. Recuperado el 5 de junio de 2009 .
  5. 1 2 3 4 5 6 7 8 "Protocolo cliente-servidor de Google Wave - Protocolo de federación de Google Wave" . Archivado del original el 30-03-2013 . Recuperado el 05-06-2009 .
  6. "Protocolo de federación Google Wave y actualizaciones de código abierto" .
  7. "Archivo de Google Code: almacenamiento a largo plazo para el alojamiento de proyectos de Google Code" .
  • Página principal del protocolo de federación de Google Wave
  • Especificación del protocolo preliminar
  • Documentos técnicos del protocolo archivados el 31 de mayo de 2009 en la Wayback Machine.