Tecnologías Web 2.0 de doble uso (civil y militar)
Upcoming SlideShare
Loading in...5
×
 

Tecnologías Web 2.0 de doble uso (civil y militar)

on

  • 3,658 views

Estudio del Protocolo XMPP, de sus antecedentes,y de sus aplicaciones civiles y militares

Estudio del Protocolo XMPP, de sus antecedentes,y de sus aplicaciones civiles y militares

Statistics

Views

Total Views
3,658
Views on SlideShare
3,647
Embed Views
11

Actions

Likes
0
Downloads
44
Comments
0

2 Embeds 11

http://www.slideshare.net 10
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NoDerivs LicenseCC Attribution-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tecnologías Web 2.0 de doble uso (civil y militar) Tecnologías Web 2.0 de doble uso (civil y militar) Presentation Transcript

  • Universidad Politécnica de Madrid Facultad de Informática José Carlos Díaz Madrid, Septiembre de 2008
  •  
    • La MI es hoy uno de los medios de comunicación más importantes, con más de 500 millones de usuarios en el mundo
    • La MI es un fenómeno social y una herramienta de comunicación
    • Desplazando ya al e-mail en muchas organizaciones como consecuencia de su acentuado carácter generacional
    • Una de las claves es que maneja el concepto de Presencia
    • La Presencia es lo que permite comunicar a usuarios y servicios su estado de disponibilidad en una red MI
    • La MI es el canal de comunicación con el crecimiento más rápido nunca visto
    • Creciendo más rápido que el teléfono móvil y el e-mail
    • Convergencia Voz-Video-Texto a finales de 2011 en el mundo de la empresa
    • Más de 500 millones de usuarios individuales en todo el mundo
    • Sobre redes IP y entre dispositivos tanto fijos como móviles
    • Transmisión de voz, video y datos
    • Sobre estándares de seguridad
    • A través de servidores públicos , privados o P2P , según el protocolo de MI
    • Capacidad de encolamiento de mensajes en los servidores para ofrecer mensajería offline
    • Control de la presencia de sus usuarios
    • Distribución/Acceso de herramientas y servicios
    • Base de tecnología madura , con decenas de implementaciones abiertas y propietarias
    • Talkomatic y TermTalk fueron dos de la primeras aplicaciones de chat
    • Talkomatic y Termtalk fueron desarrolladas en la década de 1970 para la comunidad de usuarios del sistema operativo de tiempo compartido PLATO de Control Data Corporation
    • PLATO fue el primer sistema de teleformación y colaboración multiusuario
    • Sus terminales estaban dotados de modem de 1200 bps de ancho de banda y se podían conectar a Homelink , una red precursora de las BBS e Internet
    • P rogrammed L ogic for A utomated T eaching O perations
    • Talk , NTalk e YTalk fueron tres aplicaciones de MI creadas para el sistema operativo UNIX a comienzos de la década 1970
    • Talk utilizaba el protocolo UDP para negociar las conexiones entre los dos extremos para, luego, emplear un socket persistente TCP como canal de transmisión de los mensajes entre los participantes
    • IRC (Internet Relay Chat) es otro protocolo de comunicación en tiempo real basado en texto, que permite la conferencia de texto entre dos o más personas
    • Las conversaciones se desarrollan en los llamados canales de IRC , que pueden ser locales o no al servidor al que se conectan los clientes
    • Los servidores gestionan los canales y las conversaciones
    • Utiliza TCP así como opcionalmente SSL
    • Los servidores de IRC se interconectan formando un árbol
    • Cada servidor debe tener una copia de la información sobre el estado global, lo que limita el tamaño máximo de estas redes
    • Los servidores de IRC retransmiten las conversaciones de cada canal a cada uno de los usuarios conectados a dicho canal
    • Existen muchas implementaciones de clientes IRC así como de servidores
    • ICQ (Mirabilis,1996), primer protocolo de MI de nueva generación
    • Primer protocolo con mensajes offline , envío de SMS , conversaciones multiusuario y mensajes personales , transferencia de ficheros , P2P , etc
    • UIN (Universal Internet Number), cada usuario era registrado con un número único al cual se le podía asociar información complementaria
    • Microsoft Messenger lo copió hasta desplazarlo en el mercado
    • Transformado en protocolo OSCAR (Open System for Communications in Real-Time) cuando lo compra AOL en1998
    • múltiples servidores centrales BOS (Basic OSCAR Service) + otros servidores de servicios
    • paquetes binarios de longitud variable
    • basado en TCP, protocolo extensible , seguridad escasa , proxies
    • los servidores hacen relay de los mensajes
    • Permite conexiones P2P y transferencia de ficheros
  • FLAP Packet frame abstraction Canales (1 = login, 2 = messages, etc) Paquete de separación dentro de TCP Multiplexado SNAC Define comandos/acciones ~20 familias, >200 comandos Permite extensibilidad & compatibilidad TLV Tipo, Longitud, Valor Representa un registro simple de datos Family 0x0001: Generic Service Controls Family 0x0002: Location Services Family 0x0003: Buddy List Management Family 0x0004: Messaging Family 0x0005: Advertisments Family 0x0006: Invitation and Client-to-Client Family 0x0007: Administrative Family 0x0008: Popup Notices Family 0x0009: BOS-specific Family 0x000A: User Lookup Family 0x000B: Stats Family 0x000C: Translate Family 0x000D: Chat Navigation Family 0x000E: Chat Family 0x0045: Unknown (Client Something?)
  •  
    • XMPP ES UN PROTOCOLO DE MENSAJERÍA ASÍNCRONA
    • NO USA LA TÉCNICA DEL POLLING
    • CONSUMO EFICIENTE DE ANCHO DE BANDA
    • El HTTP es un protocolo síncrono
    • Para simular el tiempo real se deben emplear técnicas de polling Se producen latencias
    • Se malgasta ancho de banda con tráfico innecesario
    • 100% XML
    • Abierto
    • Extensible . Permite extensiones ( XEPs ) que añaden features tales como VoIP, transferencia de ficheros, P2P, PubSub, etc.
    • Descentralizado (cualquiera puede correr su propio servidor xmpp)
    • Seguro (soporte nativo de SASL y TLS , firma electrónica )
    • No necesariamente síncrono
    • Comunicación bidireccional
    • Protocolos de transporte: TCP , UDP , HTTP …
    • Permite federacionesXML
    • XMPP se basa en una serie de estándares de la IETF:
      • RFC 3920 : XMPP Core
      • RFC 3921 : Instant Messaging and Presence
      • RFC 3922 : Mapping XMPP to Common Instant Messaging and Presence
      • RFC 3923 : End to end signing and object encryption for XMPP
    • se suele implementar como cliente-servidor ...
    • ...aunque XMPP se puede usar para establecer transferencias P2P
    • TCP o HTTP (BOSH/HTTP Binding o HTTP Polling)
    • Direccionamiento por dominios y JIDs
    • Los servidores enrutan los mensajes
    • Gateways entre redes de MI
    • Cada entidad en una red XMPP se identifica por medio de un JID
      • Ejemplo 1: < user@somehost.example.com/resource >
      • Ejemplo 2: < [email_address] >
      • Ejemplo 3: < domain/resource >
    jid = [ node &quot;@&quot; ] domain [ &quot;/&quot; resource ] domain = fqdn / address-literal fqdn = (sub-domain 1*(&quot;.&quot; sub-domain)) sub-domain = (internationalized domain label) address-literal = IPv4address / IPv6address
    • toda comunicación se hace a través de contenedores XML streams ( <stream/> )
    • Los XML streams contienen toda la sesión , incluyendo cada mensaje enviado dentro de la sesión
    • Cada conexión XMPP tiene dos XML streams abiertos, uno en cada dirección
    • Los XML streams se emplean para enviar stanzas o comandos , de un host a otro.
    • Las stanzas son los elementos hijos de primer nivel de <stream/>
    • Tres tipos de stanzas: <message/> , <presence/> y <iq/>.
    <stream> ... <message to='somebody'> <body>Hello!</body> </message> ... </stream>
    • Cliente abre conexion TCP con el servidor de su dominio y autentica al usuario
    • Cliente usa conexion TCP anterior para enviar un paquetes IM hacia su servidor
    • El servidor consulta servicio DNS para hallar IP del servidor de destino a partir del dominio del JID del destinatario
    • Conexión TCP entre servidores XMPP y reenvío de paquete IM
    • Servidor destino utiliza conexión TCP para entregar paquete de IM
    • Conectarse con el puerto 5222 del servidor y enviar una etiqueta de sesión abierta <stream:stream>
    • Esperar la respuesta del servidor <stream:stream>
    • Negociación TLS
    • Autenticación mediante SASL
    • Enviar y recibir paquetes XMPP o stanzas
    • Enviar la etiqueta de cierre </stream:stream> para terminar la sesión.
    • Cerrar la conexión
    Cliente Servidor 1 3 2 4 5 7 6
    • La seguridad en el transporte la aporta el protocolo TLS - Transport Layer Security , definido en el RFC 2246
    • TLS es un protocolo para establecer una conexión segura C2S y S2S
    • Capaz de autenticar en ambos lados de la comunicación , y crea una conexión cifrada entre las dos.
    • Extensible con nuevos algoritmos
    • Cifrado de las comunicaciones C2S y S2S con el protocolo TLS
    • Autenticación de C2S y S2S con SASL
    • Una vez abierto el nuevo stream, y tras las negociaciones TLS y SASL 3
    • 3 tipos fundamentales de stanzas :
      • <message/> asynchronous communications
      • <iq/> synchronous communications
      • <presence/> presence and status data
    • Atributos opcionales comunes :
      • to - destinatario de la stanza.
      • from – JID del remitente de la stanza
      • id - ordenamiento/identificación de los mensajes.
      • type - tipo concreto de stanza (p.e. ‘error’)
      • xml:lang – idioma de la stanza
    • Un mensaje básico consiste en un elemento <message/> con los atributos from , to e id .
    • seis tipos diferentes: ‘ normal ’, ‘ chat ’, ‘ groupchat ’, ‘ headline ’, ‘ error ’ y ‘ jabber:x:oob ’
    • Los elementos <message/> se componen de varios subelementos:
      • <subject> pensado para indicar el título o asunto relativo al mensaje
      • <thread> para identificar la conversación a la que pertenece el mensaje
      • <body> para especificar el contenido del mensaje
      • <error> para especificar que ha ocurrido un error
    • <message
      • to ='romeo@montesco.net/huerto'
      • from ='julieta@capuleto.net/balcon'
      • type ='chat'
      • xml:lang ='es' >
      • <body>
      • ¡Romeo, Romeo! ¿Por qué eres tú Romeo? ¿Por qué no reniegas del nombre de tu padre y de
      • tu madre?...
      • </body>
      • <body xml:lang ='en' >
      • O Romeo, Romeo! wherefore art thou Romeo? Deny thy father and refuse thy name...
      • </body>
    • </message>
    • las listas de privacidad permiten bloquear mensajes dirigidos a un usuario
    • gestión en el servidor XMPP
    • modos de bloqueo: por JID , grupo o tipo de suscripción
    • se pueden definir tantas listas de privacidad como deseen
    • Una lista de privacidad consta de:
      • <list/> la lista de reglas, tiene un atributo ‘ name ’ para identificarla
      • <ítem/> la regla, que se define mediante los atributos ‘ type ’ (tipo), ‘ value ’ (valor) , ‘ action ’ (acción) y ‘ order ’ (orden).
    • Los posibles valores del atributo ‘ type ’ que representa al tipo de regla pueden ser ‘ group ’, ‘ jid ’ y ‘ suscription ’.
    • Los valores del atributo ‘action’ pueden ser: ‘ allow ’ o ‘ deny ’, que definen el comportamiento de la regla (permitir o denegar).
    • se distribuyen siempre dentro de una stanza <iq/>
    • <iq type ='result' id ='getlist4'
    • to =‘romeo@montesco.net/huerto’>
      • <query xmlns ='jabber:iq:privacy'>
        • <list name ='reglas de privacidad de Romeo'>
            • <item type ='jid' value =‘julieta@capuleto.net’ action ='allow‘ order ='6'/>
          • <item type ='jid' value ='benvolio@ montesco.net' action ='allow‘ order ='7'/>
          • <item type ='jid' value ='teobaldo@capuleto.net' action ='deny‘ order ='42'/>
          • <item action ='deny' order ='666'/>
        • </list>
      • </query>
    • </iq>
  • Presence 1.0 Identity 1.0 Event Stream Processing Event-Driven SOA
    • Presencia 1.0  disponibilidad de usuario
      • cúando está disponible (online/offline)
      • dónde está disponible (localización)
    • Basado en nociones tradicionales de la identidad del usuario
    • La presencia genera eventos
      • “ Romeo está conectado”
      • “ Julieta está ahora en el balcón”
    • Puede afectar a procesos de negocio orientados a servicios
      • servicios sensibles al contexto
      • workflows dinámicos basados en presencia
    • El concepto inicial de presencia está evolucionando
    • Presencia 2.0  más que disponibilidad
      • condicionada (“No estoy para Julieta”)
      • controlada por el usuario (“Quiero que mi localización sólo la pueda ver Julieta”)
      • colectivización de la presencia (“Romeo y Julieta están hablando”)
      • rica en información
        • múltiples puntos de presencia (dispositivos)
        • interoperabilidad semántica
    • User-Centric Identity  no hay estándares aún
    Presence 2.0 Identity 2.0 Complex Event Processing Event-Driven SOA Social Networking
    • Last.fm  Construye automáticamente listas de canciones de sus usuarios a partir de la música que escuchan con Windows Media Player, WinAmp, y otros reproductores  Aquí, la presencia del usuario incluye información del tag ID3 del MP3 que está siendo reproducido en ese momento por el usuario  la identidad digital del usuario es básicamente, un perfil psicomusical al que se le buscan afinidades
    • Twitter  Una aplicación web de publicación/suscripción de presencia muy sencilla que permite a los usuarios hacer broadcast de su presencia (extendida) a sus suscriptores (amigos), y viceversa.
    • Comunicaciones Unificadas  Microsoft, Cisco, Avaya... Los usuarios pueden comunicar a su red de contactos que están o no disponibles y de qué manera (para charla IM, llamada telefónica, videollamada, etc.), así como dónde se encuentran y qué hacen.
  • gestión del perfil gestión del contexto gestión de las relaciones sociales integración con aplicaciones GESTION DE IDENTIDAD Y ROLES GESTION DE PERFILES GESTION DE MEMBRESÍAS GESTION DE REGLAS GESTION DE SUSCRIPCIONES LIBRE / OCUPADO RUTINAS GESTION DE DATOS DE REDES SOCIALES EMAIL Y CALENDARIO GESTION DE LOCALIZACION SENSORES CONTEXTO AGENDA CONTACTOS BUDDY LISTS IM DIRECTORIO CORPORATIVO CRM & ERP RELACIONES REDES SOCIALES GRUPOS DE AFINIDAD integración con redes y servicios de datos
    • Funciona como un mecanismo pub/sub
    • Los clientes enviarán y recibirán mensajes de suscripción de presencia de dos tipos: ‘ subscribe ’ y ‘ unsubscribe ’
    • Los mensajes de presencia viajan en stanzas <presence/>
    • Cuando cambia el estado de presencia en un cliente , este lo publica en el servidor para que este último lo notifique a los suscriptores de esa presencia.
    • Nada más establecerse un sesión XMPP, lo primero de todo es enviar la presencia al servidor
    • El servidor aprovecha para enviar una prueba de disponibilidad a los contactos del cliente
    • los contactos del cliente se guardan en una infoestructura llamada roster , dentro del servidor
    • La presencia no es dirigida , se comunica siempre al servidor
    • Las suscripciones (y cancelaciones ) de presencia sí son dirigidas
    • <presence>
      • <status> Una descripción... </status>
      • <show> Disponibilidad </show>
    • </presence>
    • Tipos de disponibilidad:
      • ‘ chat ’ : el usuario está intentando hablar con alguien
      • ‘ away ’ : el usuario está fuera del cliente XMPP por un corto periodo de tiempo
      • ‘ xa ’ (extended away): el usuario está fuera por un periodo prolongado de tiempo
      • ‘ dnd ’ (do not disturb): el usuario no desea recibir mensajes
    • <presence from =‘julieta@capuleto.net/balcon'
      • to ='capuleto.net‘ type= ' available ' >
      • <status> Estoy aburrida, que alguien me hable… </status>
      • <priority> 10 </priority>
      • <show>chat</show>
    • </presence>
    • ‘ available ’ - listo para recibir mensajes
    • ‘ unavailable ’ - no disponible para recibir mensajes
    • ‘ subscribe ’ - petición de suscripción a la presencia del destinatario
    • ‘ unsubscribe ’ - cancelación de suscripción a la presencia del destinatario
    • ‘ subscribed ’ - respuesta de suscripción OK
    • ‘ unsubscribed ’ - respuesta de cancelación de suscripción OK
    • ‘ error ’ - mensaje estándar de error
    • ‘ probe ’ –envía toda la información de presencia de un servidor a otro
    • ROSTER : es la agenda de contactos de un usuario, que se almacenan en el servidor y que sirve para almacenar los JIDs , información de perfil y las suscripciones a la presencia desde y hacia dichos contactos
    • El protocolo roster es una extensión del protocolo IQ
    • Los tres tipos básicos de protocolos de gestión del roster son:
      • ‘ Roster get ’: usado por los clientes para obtener una copia del roster almacenado en el servidor.
      • ‘ Roster update ’: usado por los clientes para actualizar el roster almacenado en el servidor.
      • ‘ Roster push ’: actualizaciones asíncronas del roster que el servidor envía a los clientes.
    • Lo primero que hace un cliente XMPP al establecer sesión es solicitarle su roster al servidor
      • <iq from ='julieta@capuleto.net/balcon' type ='get' id ='roster_1'>
        • <query xmlns ='jabber:iq:roster'/>
      • </iq>
    • Y el servidor contestará con una copia completa del roster
      • <iq to ='julieta@capuleto.net/balcon' type ='result' id ='roster_1'>
      • <query xmlns ='jabber:iq:roster'>
      • <item jid ='romeo@montesco.net'
      • name ='Romeo'
      • subscription = TIPO >
      • <group> Amigos </group>
      • </item>
        • ...más items...
      • </query>
      • Este roster se podrá modificar posteriormente , haciendo inserciones y borrados (protocolo Roster Update )
    ‘ to ’ - envia su presencia ‘ from ’ - recibe su presencia ‘ both ’ - mutuo interés ‘ none ’ - ningún interés
    • XMPPdispone de más de 100 XEPs o extensiones al protocolo controladas por la XSF (XMPP Standards Foundation)
      • Descubrimiento automático de servicios
      • Publish & Subscribe : para las comunicaciones 1:N
      • Mensajes fiables: acuse de recibo
      • Colas de mensajes y caducidad de mensajes
      • Intercambio de datos estructurados y fuertemente tipados
      • Message archiving
      • Compresión de los streams
      • Transferencia de ficheros
      • Uso de certificados y firma digital
      • Cifrado
      • Trasnporte Peer-To-Peer
      • Transporte firewall-friendly por HTTP Binding / BOSH
      • ...y un largo ETCÉTERA
    • XEP-0004 : Data Forms
    • Formularios de datos para el intercambio de datos estructurados
    • Tipos de datos específicos de XMPP, menos complejos que XForms 1.0
    • Incluye semánticas ligeras para el procesamiento de los formularios (solicitud, respuesta, envío, cancelación)
    • Tal y como se definen los formularios en XHTML
    • <x xmlns='jabber:x:data' type ='{form-type}'>
      • < title />
      • < instructions />
      • < field var ='field-name' type ='{field-type}' label ='description'>
      • < desc />
      • < required />
      • < value > field-value </ value >
      • < option label ='option-label‘>< value > option-value </ value ></ option >
      • < option label ='option-label‘>< value > option-value </ value ></ option >
      • </ field >
    • </x>
    • XEP-0030 : Service Discovery
    • Permite el descubrimiento de información entre entidades XMPP
    • Funciona de un modo similar a los servicios de descubrimiento que define el protocolo SOAP.
    • Puede descubrir dos tipos de información:
    • la identidad básica (tipo y categoría) de una entidad
    • las capacidades de una entidad , incluyendo los protocolos y funcionalidades que soporta
    • los elementos asociados a la entidad, tales como la lista de salas en un servicio de chat multiusuario
    • XEP-0030 : Service Discovery
    < iq type ='get' from ='juliet@capulet.com/balcony' to ='romeo@montague.net/orchard' id ='info4'> < query xmlns ='http://jabber.org/protocol/disco#info'/> </ iq > < iq type ='result' from ='romeo@montague.net/orchard' to ='juliet@capulet.com/balcony' id ='info4'> < query xmlns ='http://jabber.org/protocol/disco#info'> < identity category ='client' type ='pc' name ='Gabber'/> < feature var ='jabber:iq:time'/> < feature var ='jabber:iq:version'/> </ query > </ iq >
    • XEP-0060 : Publish Subscribe
    • publicación-subscripción: una persona o aplicación ( publicador ) publica información ( nodo ), y un evento de notificación (con o sin datos asociados) se difunde a todos los suscriptores autorizados
    • El servidor XMPP recibe las peticiones de publicación , hace broadcast de los eventos de notificación a los suscriptores , y gestiona las ediciones y suscripciones.
    • Los nodos son una estructura de datos sobre la que los publicadores envían sus datos y en la que los suscriptores reciben las notificaciones.
    • Además, algunos nodos también pueden albergar un historial de eventos y prestar otros servicios que complementan el modelo puro PubSub .
    • Los nodos publicadores crean “ topics ” (por ejemplo, temperatura, localización, presión…) y publican “ samples ” (muestras) de estos tópicos
    • El bus PUBSUB entrega estos “ samples ” a todos los suscriptores que declaren su interés en el tópico en cuestión
    • XEP-0060 : Publish Subscribe
    • XEP-0060 : Publish Subscribe
    • < iq type ='set' from ='hamlet@denmark.lit/blogbot' to ='pubsub.shakespeare.lit' id = 'pub1'> < pubsub xmlns ='http://jabber.org/protocol/pubsub'> < publish node ='princely_musings'> < item > < entry xmlns ='http://www.w3.org/2005/Atom'> < title > Soliloquy </ title > < summary > To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? </ summary > < link rel ='alternate' type ='text/html' href='http://denmark.lit/2003/12/13/atom03'/> < id > tag:denmark.lit,2003:entry-32397 </ id > < published > 2003-12-13T18:30:02Z </ published > < updated > 2003-12-13T18:30:02Z </ updated > </ entry > </ item > </ publish > </ pubsub > </ iq >
    Un editor publica una nueva entrada en su blog...
    • XEP-0060 : Publish Subscribe
    • < message from ='pubsub.shakespeare.lit' to ='francisco@denmark.lit' id ='foo'> < event xmlns ='http://jabber.org/protocol/pubsub#event'> < items node ='princely_musings'> < item id ='ae890ac52d0df67ed7cfdf51b644e901'> [ ... ENTRY ... ] </ item > </ items > </ event > </ message >
    • < message from ='pubsub.shakespeare.lit' to ='bernardo@denmark.lit' id ='bar'> < event xmlns ='http://jabber.org/protocol/pubsub#event'> < items node ='princely_musings'> < item id ='ae890ac52d0df67ed7cfdf51b644e901'> [ ... ENTRY ... ] </ item > </ items > </ event > </ message >
    El Servicio PubSub lo notifica a los Suscriptores...
    • Y ADEMÁS...
    • XEP-0045 : Multi-User Chat (MUC)
    • XEP-0080 : Geolocalización de Usuarios
    • XEP-0138 : Compresión de Streams
    • XEP-0116 : Cifrado de Sesiones
    • XEP-0009 : Jabber-RPC
    • XEP-0072 : SOAP sobre XMPP
    • XEP-0171 : Traducción de Idiomas
    • ...
    • ¡¡Y 100 extensiones más!!
  • A-Talk Adium aMSN AOL Instant Messenger (AIM) Ayttm BigAnt Instant Messenger BitlBee BitWise IM Centericq climm Coccinella Cspace Digsby Ebuddy emesene EQO Exodus Fire Fring Gabtastik Gadu-Gadu Gajim GCN GOIM Goofey Google Talk Gyachi IBM Lotus Sametime iChat ICQ IMVU Instantbird Interaction Chat Jabbin Kadu Konnekt Kopete Licq Mail.ru Agent MCabber MECA Messenger meebo Meetro Mercury Messenger Microsoft Messenger for Mac MindSpring Miranda IM MySpaceIM Naim Ometheus OpenWengo Paltalk Pandion Pidgin pork Proteus Psi psyced QIP Qnext QIP infium RealTimeQuery SIM Skype Solixa talk Tencent QQ Trillian Trillian Astra Trillian Pro Windows Messenger Xfire Yahoo! Messenger Zephyr Windows Live Messenger Gaim
    • Las implementaciones más importantes son:
    Nombre del Software Version Plataforma /OS djabberd 0.83 UNIX, GNU/Linux ejabberd 2.0.1 GNU/Linux, Mac OS X, Windows, AIX, BSD, HP-UX, Solaris Isode M-Link R14.2 Linux, Solaris, Windows Jabber XCP 5.2 Windows, Solaris, GNU/Linux jabberd 2.1.24.1 UNIX, GNU/Linux jabberd14 1.6.1.1 UNIX, GNU/Linux jabberd2 2.1.17 UNIX, GNU/Linux Openfire 3.4.5 GNU/Linux, Mac OS X, Windows, AIX, BSD, HP-UX, Java, Solaris psyced 20080116 UNIX, GNU/Linux, Windows, Mac OS X Tigase 3.3.2 GNU/Linux, Mac OS X, Windows, AIX, BSD, Java, Mac OS 9, Solaris
    • Para lenguaje C:
    • iksemel
    • libstrophe
    • Loudmouth (software)
    • Microsoft .NET
    • C#
    • agsXMPP
    • Jabber-NET
    • goodwarejabber (library, client, server)
    • Para C++:
    • gloox
    • IP*Works
    • Iris (software)
    • jabberoo
    • oajabber
    • Como componentes COM:
    • JabberCOM
    •  
    • Para Erlang:
    • Jabberlang
    • Existen más de 50 librerías para desarrollo XMPP en múltiples lenguajes
    Lenguaje C: iksemel libstrophe Loudmouth (software) Microsoft .NET: C# agsXMPP Jabber-NET goodwarejabber (library, client, server) lenguaje C++: gloox IP*Works Iris (software) jabberoo oajabber COM/COM+: JabberCOM JAVA: Echomine Feridian Echomine Muse JabberWookie JSO (software) micro-Jabber Smack (librería) Tweeze (software) Yaja (software) HTA: JSJaC xmpp4moz Perl: Net::Jabber::Loudmouth Net::XMPP2 Net:XMPP XML::Stream Jabber::Lite POE::Component::Jabber PHP: Class.Jabber.PHP jabberclass Python: jabber.py PyXMPP sleekxmpp Twisted Words xmpppy Ruby: Action Messenger Jabber4R Jabber::Simple XMPP4R Otros: Tcl (JabberLib) Framework XPCOM (JabXPCOM) LPC (psyced) Macromedia Flash (XIFF) Lisp (cl-xmpp) Haskell (hsxmpp) Erlang (Jabberlang) Para PHP: Class.Jabber.PHP jabberclass En Python: jabber.py PyXMPP sleekxmpp Twisted Words (software) xmpppy En Ruby: Action Messenger Jabber4R Jabber::Simple XMPP4R Otros lenguajes/entornos: Tcl (JabberLib) Framework XPCOM (JabXPCOM) LPC (psyced) Macromedia Flash (XIFF) Lisp (cl-xmpp) Haskell (hsxmpp) Para la plataforma Java: Echomine Feridian Echomine Muse JabberWookie JSO (software) micro-Jabber Smack (librería) Tweeze (software) Yaja (software) Para aplicaciones HTA: JSJaC xmpp4moz En lenguaje Perl : <Net::Jabber::Loudmouth Net::XMPP2 Net:XMPP XML::Stream Jabber::Lite POE::Component::Jabber
  •  
    • XMPP puede servir como middleware de comunicaciones en redes de área corporal ( BANs ) para la monitorización remota mediante Bio-Sensores (ECG, ECC, BP...)
    • ¿Qué aporta XMPP?
      • Federación a escala Internet, BOSH , Router-Friendly, Publicación-Suscripción , descubrimiento de servicios
    La Inteligencia Ambiental ( AmI ) se alcanza cuando un entorno “ electrónico ”, compuesto por toda clase de dispositivos electrónicos, software y comunicaciones, es sensible y responde a la presencia de las personas, colaborando de manera transparente para el usuario
    • XMPP puede servir como middleware de mensajería en tiempo real para la distribución de información y datos estructurados relativos a transacciones TR
    • Mediante PubSub, se pueden distribuir datos de mercado en “casi” Tiempo Real, de manera fiable y a escala Internet (p.e. Reuters, Bloomberg, InfoBolsa, etc)
    “ Todavía hoy, en el sector de seguros, especialmente las medianas y pequeñas compañías, se procesan en lotes ficheros TXT con altas, bajas y modificaciones de pólizas” “ La banca todavía no se ha dado cuenta del potencial que tiene asimilar y manejar la presencia de sus clientes y adaptar su arquitectura de servicios financieros para ofrecer servicios más avanzados”
    • En las catástrofes y grandes situaciones de emergencia, se debe formar una célula de crisis en la que se encuentran los máximos responsables de las fuerzas y cuerpos de seguridad, ejército, protección civil, servicios sanitarios, gabinete de medios, etc... Y además, el poder político.
    • Este tipo de células se deben de poder desplegar con los mínimos medios , en cualquier lugar .
    • Es un hecho que los cargos políticos, para tomar una decisión, necesitan reunir el máximo de información (aunque no sean capaces de interpretarla), en cualquier formato disponible, y en tiempo real
    • Los políticos y los altos funcionarios que toman las decisiones relevantes en una gestión de crisis usan predominantemente el teléfono para recibir los reportes de situación y para dar a su vez órdenes
    • Cada vez son más frecuentes los modernos terminales como el iPhone de Apple o los SmartPhones y PDAs , que, unido a la amplia cobertura de bancha ancha y 3G , los hacen muy atractivos para este colectivo
    • XMPP puede servir como fundación de un sistema distribuido y móvil de seguimiento de eventos y gestión de crisis , aprovechando el potencial que nos da controlar la presencia de los usuarios y el descubrimiento automático de servicios
    • Complejidad del escenario de una crisis humanitaria
    • Hay que coordinar a múltiples entidades : ejército, guardia civil, policia nacional, policia local, bomberos, protección civil, agencias del gobierno e internacionales, ONGs, voluntarios de la sociedad civil… y por supuesto hay atender a las víctimas de manera urgente y eficaz
    • La tecnología IM y los protocolos XMPP ayudan a coordinar equipos de trabajo aasí como a enrutar por Internet mensajes entre las plataformas de las diferentes unidades operativas
    • Se usa actualmente en varias de las plataformas tecnológicas de gestión y coordinación de desastres: SIFP-ShareInfoForPeople (US DoD) y Sahana Project (Free Software Foundation)
    • Modelo CapWIN: software de Multichat Cifrado XMPP creado tras el 11-S y que se emplea por las unidades de emergencias de Washington DC
    • Ventajas:
      • compartir información sobre la escena del incidente
      • presencia y service discovery  mejor planificación en tiempo real de los efectivos
      • búsqueda en bases de datos mediante bots
      • fácil despliegue y movilidad
      • evita los silos de información que se producen cuando intervienen diferentes unidades
      • Facilita seguimiento en tiempo real y filtrado en el escalón de mando
      • extensibilidad con otros estándares como NIEM, GJXDM, IEE 1512, OASIS/CAP, EDXL, etc.
    • Las fuerzas armadas se enfrentan a una gran transformación debido que la naturaleza de los conflictos ha cambiado mucho en este nuevo siglo
    • Las fuerzas armadas se enfrentan a una gran transformación debido que la naturaleza de los conflictos ha cambiado mucho en este nuevo siglo
    • La victoria depende del principio de Superioridad de la Información , asegurando que el enemigo tenga el menor control posible sobre la situación ( Situation Awareness - SA )
    • Alcanzar la Superioridad de la Información supone tener capacidad propia para:
      • obtener, procesar y distribuir la información precisa para satisfacer las necesidades de los diferentes escalones de mando
      • prever los cambios en las necesidades de información del enemigo
      • negar al enemigo estas mismas capacidades
    • Múltiples programas como la iniciativa NNEC de la OTAN persiguen que antes de 2020 , todos los sistemas de armas, sistemas de combate, sensores, sistemas C4ISR... permitan dicha superioridad
    • Tecnologías de mejora: INFOSEC, Comms (SDRs, RRC, RBA, Redes OTM, etc), Protocolos, Arquitecuras CIS, Contramedidas EW, Interoperabilidad, Redes de Sensores ISR, Blue Force Tracking, FFT, COMFUT...
  • Sensores de Tierra EO ISR ISR Gateway LAN Táctica OTM Avion de Reconocimiento y Guerra Electrónica Satélite de Comunicaciones Radar SAR SAT LINK Red Radio de Combate IP ISR UAV Relay UAV Estación Móvil WIMAX/HCDR Escuadrilla de ataque Enlace LOS Enlace LOS Enlace LOS Fuerzas enemigas Estación Móvil WIMAX/HCDR Puesto de Mando LINK 16 LINK 16 FFT FFT Operaciones Centradas en Red
  • Situational Awareness Force Readiness Force Sustainment Infra-structure GCSS Coalition C2 Gale Lite GCCS-A GCCS-M IAS JSTARS NATO ICC TBMCS TCAIMS II ADAMS ALOG AMP DARWIN DCAPES GCCS-A GTN ICIS JFAST MAGTF II MAT SMS TAG LOGCAT/BCAT WHQ COMPASS FOCUS JRAMS AFSATCOM/TIBS GDSS ETMS FNMOC EPLRS Lateral Tell Link 11/16 NNSOC NRTD QTRACS ADSI TDDS SBMCS NATO JOIIS TBMCS ASAS MIDB NGA 5D NGA IPL UAV GCS AF Weather AFIWC WinJMEM Raindrop DMDC CFAST DRRS FEDB FEDMTC GCCS-A JADE JRAMS READI AFSORT DET ASORTS GOMERS TRMS DMS GTN SDDC - TEA DMS AMHS GPS USN Observatory Intelligence Force Planning GRIS I3 COP SORTS GSORTS C2 JOPES DVT JFRG II ACOA CFAST C2PC DNS DCTS E-Mail Print Services Dw F D,plk Dwf Empire Alerts WebCOP Grenadier Brat JFAST La realidad abruma... DARWIN CAMPS Poca Interoperabilidad - Islas de información Es difícil hasta mantenerlos todos al día
    • IM con redes IP sobre infraestructura de redes de comunicaciones de banda ancha y estrecha
    • soporte de la Logística
    • en Planificación de Misiones
    • como enlace de comunicaciones y vehículo de la sincronización de los cambios sobre la COP en Sistemas C2
    • como bus de comunicaciones para Redes de Sensores ISR
    • Distributed Interactive Simulation (transporte de paquetes DIS-XML)
    • Remote Biomonitoring (Telemedicina Militar, Programa COMFUT)
    • Operational Medical Support – Asistencia Médica Telemática en situaciones de combate
    • Blue Force Tracking
    • Distribución de Datos de Inteligencia para programa Combatiente del Futuro
  •  
    • Sobran motivos para usar XMPP:
      • el core del protocolo es un estándar IETF
      • “ mandatory standard” DoD
      • es un protocolo abierto, multiplataforma, extensible, gratuito , con una comunidad bastante amplia de contribuyentes
      • admite federación con otras plataformas de IM
      • maneja mensajería y presencia
      • funciona como pubsub
      • maneja descubrimiento de servicios
      • permite implementar VoIP mediante JINGLE
      • probada en condiciones extremas en el campo de batalla
    • XMPP se está convirtiendo en un estándar asequible y respetado para su utilización como el protocolo de transporte de los “cloud services” , por encima de HTTP y de SOAP  crece a la par que los servicios de la Web 2.0
  •  
  • José Carlos Díaz