MSN MESSENGER EN JAVA
JUAN DIEGO NOCUA GUALDRON
UNIVERSIDAD AUTONOMA DE BUCARAMANGA FACULTAD DE INGENIERIA DE SISTEMAS
SISTEMAS DE INFORMACIÓN E INGENIERÍA DE SOFTWARE BUCARAMANGA
MSN MESSENGER EN JAVA
JUAN DIEGO NOCUA GUALDRON
Proyecto de Grado para Optar al Título de Ingeniero de Sistemas
Director: Mcc. Freddy Méndez
UNIVERSIDAD AUTONOMA DE BUCARAMANGA FACULTAD DE INGENIERIA DE SISTEMAS
SISTEMAS DE INFORMACIÓN E INGENIERÍA DE SOFTWARE BUCARAMANGA
Nota De Aceptación: _____________________ _____________________ _____________________ _____________________ _____________________ _____________________ _____________________ Freddy Mendez ______________________ Juan Carlos Martinez
______________________ Cesar Dario Guerrero
A mis padres, a mis verdaderos amigos, y a los profesores que no se limitaron al salón de clases.
AGRADECIMIENTOS
El autor expresa su agradecimiento a:
Freddy Mendez, Ing de Sistemas y director de este proyecto por su comprensión y orientación durante todo el proceso.
CONTENIDO pág. INTRODUCCIÓN 16 1. MARCO TEORICO 18 1.1 MENSAJERIA INSTANTÁNEA 18 1.1.1 ¿Qué es el MSN Messenger? 18
1.1.2 ¿Qué es la red del MSN Messenger? 19
1.1.3 ¿Qué pueden hacen los programas en la red del MSN Messenger? 19
1.1.4 ¿Qué es el MSN Messenger protocol? 20
1.1.5 ¿Qué es el MSN Client protocol? 20
1.1.6 ¿Cómo trabaja el protocolo? 21
1.1.7 Servidores de notificación (NS). 21
1.1.9 Conexiones del MSN Messenger. 22
1.1.9.1 Conexiones HTTP. 22
1.1.9.1.1 Descripción del protocolo 23
2. JAVA 24
2.1 SOCKETS 26
2.1.1 Sockets Stream. 27
2.1.2 Sockets Datagrama. 28
2.1.3 Sockets Raw. 28
2.1.4 Diferencias entre Sockets Stream y Datagrama. 28
3. PATRONES DE DISEÑO DE CREACIÓN 30
3.1 FABRICA ABSTRACTA 30
4. PATRONES DE DISEÑO DE ESTRUCTURA 31
4.2 FACHADA 31
5. PATRONES DE ARQUITECTURA 33
5.1 ARQUITECTURA MODELO-VISTA-CONTROLADOR 33
5.2 NIVELES O CAPAS 34
6. CREACIÓN DE LA APLICACION 36
6.1 INVESTIGACIÓN DE LOS PROTOCOLOS 36
6.2 CASOS DE USO 39 6.2.1 Versión 1.0. 39 6.2.2 Versión 1.1. 41 6.2.3 Versión 1.2. 42 6.2.4 Versión 1.3 44 6.3 DIAGRAMAS DE SECUENCIA 46 6.3.1 Iniciar Sesión 46
6.3.2 Cerrar Sesión. 48
6.3.3 Iniciar conversación 48
6.3.4 Recibir mensaje de contacto. 49
6.3.6 Se Conecta/Desconecta un contacto 51
6.3.7 Recibir Lista de Contactos 52
6.3.8 Modificar Estado 53 6.3.9 Cambiar Nick 54 6.4 IMÁGENES DE LA APLICACIÓN 55 7. CONCLUSIONES 61 BIBLIOGRAFIA 62 ANEXOS 64
LISTA DE FIGURAS
pág.
Figura 1. Caso de Uso Versión 1.0 40
Figura 2. Caso de Uso Versión 1.1 42
Figura 3. Caso de Uso Versión 1.2 44
Figura 4. Caso De Uso Versión 1.3 46
Figura 5. Diagrama de secuencia “Iniciar Sesión” 47
Figura 6. Diagrama de secuencia “Cerrar Sesión” 48
Figura 7. Diagrama de Secuencia “Iniciar Conversación” 49 Figura 8. Diagrama de Secuencia “Recibir mensaje de contacto” 50
Figura 9. Diagrama de Secuencia “Enviar mensaje a contacto” 51 Figura 10. Diagrama de Secuencia “Se conecta / desconecta un contacto” 52 Figura 11. Diagrama de Secuencia “Recibir Lista de Contactos” 53 Figura 12. Diagrama de Secuencia “Modificar Estado” 54
Figura 13. Diagrama de Secuencia “Cambiar nick” 54
Figura 14. Ventana Presentación Mensajero 55
Figura 16. Ventana de iniciar sesión 56
Figura 17. Mensajero Conectando al servidor. 57
Figura 18. Lista de contactos cargando. 58
Figura 19. Conversación Activa. 59
LISTA DE ANEXOS
pág.
Anexo A. Diagrama de Arquitectura de Comunicación MSN Messenger de 65 Anexo B. Diagrama de Arquitectura de Comunicación MSN Messenger 66 Anexo C. Diagrama de Arquitecturas de Mensajeria Instantánea 67
Anexo D. Entorno típico en Java. 69
Anexo E. Peticion de conexión del cliente 70
Anexo H. Modelo de aplicación de tres niveles. 71
Anexo I. Conexión del cliente con los servidores MSN. 72 Anexo J. Errores recibidos de los servidores de MSN. 73 Anexo K. Comandos recibidos del servidor sobre cambios en la cuenta 73 Anexo L. Apertura de ventana de conversación con un contacto. 74
Anexo M. Conversación de dos contactos 75
Anexo N. EL Cliente conectándose 76
Anexo O. Cargando la lista de contactos. 77
Anexo P. Comandos del protocolo MSN 78
GLOSARIO
API: (del ingles Application Programming Interfase - Interfase de Programación de Aplicaciones, interfaz de programación de la aplicación) es un conjunto de especificaciones de comunicación entre componentes software.
ADDON: extensión de un programa hecha no necesariamente por el creador original del programa, para hacer este mas sencillo de manejar o modificar.
BOT: código creado para dar respuestas automáticas a ciertos impulsos dados.
CHAT: conversación por dos o mas personas a través del Internet.
FIREWALL: programa orientado a la seguridad que evita el acceso no autorizado de peticiones maliciosas a una red o computador conectado a Internet.
HTML: (Hiper Text Markup Language) lenguaje de marcado de hipertexto.
J2EE: Java 2 Enterprise Edition.
JAVA VIRTUAL MACHINE: maquina virtual de Java, interprete de Java.
JAVAC: Compilador de java para correr las aplicaciones creadas en este lenguaje.
JDBC: (Java Data Base Conector), asistente de conectividad de Java a bases de datos.
MVC: Modelo-vista-controlador, tipo de patrón de arquitectura.
NICK: es el alias que las personas usan para identificarse en Internet.
PRINCIPALS: aquellos usuarios conectados a la red MSN.
PROXY: El servidor Proxy se utiliza para almacenar la información que es consultada con mayor frecuencia en páginas de Internet, por un período de tiempo, con el fin de aumentar la velocidad de acceso. Al mismo tiempo libera la carga de los enlaces hacia Internet.
SCOPE: es el alcance que tiene una variable o método de una clase.
THREADS (HILOS): son los hilos de comunicación que se establecen cuando se hace una petición al servidor.
TWEENER: Comando TWN, es la forma por la cual el cliente MSN se autentica a sus servidores.
UML: (Unified Model Language) lenguaje de modelamiento unificado, se usa para el desarrollo de software.
XHTML: XHTML es una familia de módulos y tipos de documentos que reproduce, engloba y extiende HTML 4.0. Los tipos de documentos de la familia XHTML están basados en XML, y diseñados fundamentalmente para trabajar en conjunto con agentes de usuario basados en XML.
RESUMEN
En estos días modernos las grandes empresas del mundo exigen soluciones de la más alta tecnología al más bajo costo. Pero muy pocas alternativas de ese tipo existen en realidad, a la hora de comunicarnos, la mayoría de las opciones presentadas a las compañías son costosas y además consumen recursos valiosos de los computadores que pueden ser mejor dosificados en otras funciones de igual o mayor importancia.
Este proyecto se presenta como una solución más a este problema o necesidad que se presenta en la vida actual, pero más que una alternativa es una opción diferente a las utilizadas hoy en día y en el pasado, ya que se presenta una modalidad de comunicación dentro de la misma empresa y por qué no, con sus clientes a través de la red de redes, el Internet, de una manera segura, muy económica y con un consumo de recursos informáticos mínimo.
Un mensajero instantáneo que trabaja bajo la red de MSN cuyo uso de recursos del computador es muy mínimo, hace que esta opción se convierta en un buen candidato a ser utilizado como elemento de comunicación interna y/o externa en las empresas.
Concebido con la tecnología JAVA, este documento se centra en las diferentes opciones que pueden ser abordadas para llevar a cabo dicha aplicación y llegar así, a la conclusión de cual de estas es la más apropiada para la situación.
Palabras Claves: Java, Comunicaciones, Software Libre, Mensajería Instantánea.
INTRODUCCIÓN
Este proyecto es presentado con el ánimo de minimizar los costos de la comunicación en el mundo actual, así como la estabilidad de la disponibilidad de ésta, consumiendo el mínimo de recursos del computador en el que se utilice la aplicación, gracias a la tecnología desarrollada por Sun Microsystems y el buen uso de esta tecnología dando paso a la aplicación final entregada al concluir este proceso.
Los programas de comunicación instantánea usados con mayor fuerza en la actualidad, como el ICQ, AOL, MSN, o Yahoo Messenger, son cada vez más populares entre nosotros. MSN es el programa más utilizado en el momento, con más de 200 millones de usuarios a nivel mundial.
Uno de los problemas que presenta el MSN es su actualización constante que cada vez exige más y más poder en la máquina instalada sin que sus funciones básicas sean modificadas, solamente se crean nuevas funcionalidades, las cuales no son más que para ocio.
Sin embargo, el protocolo que se utiliza en el MSN es de dominio público y puede ser implementado en Java para que sea ejecutado y usado como una opción más, fuera del cliente oficial. Es decir, que sería posible acceder al MSN sin necesidad del cliente ofrecido por Microsoft.
Todo lo que se necesitaría sería un equipo con el JVM (Java Virtual Machina) instalado. Esto permitiría acceder al servicio de mensajería de MSN.
Se busca en realidad que la persona por medio de Internet acceda al servicio con un mínimo de consumo computacional, ya que al pasar de los años este programa ha dejado de ser solamente un programa de Chat para convertirse en una solución de comunicación para las empresas, de gran eficacia y obviamente de un costo muy bajo.
Así, cualquier persona puede estar en una constante comunicación con sus contactos de MSN Messenger y en la mayoría de ocasiones hacer de esta herramienta una necesidad inmediata.
La versión del MSN Messenger que se trabajará en este proyecto, pretende tener las mismas funcionalidades básicas de la versión oficial ofrecida por Microsoft, como:
• Enviar mensajes. • Recibir mensajes.
• Visualizar los contactos conectados y desconectados. • Visualizar los cambios de estado de los contactos. • Tener la habilidad de modificar el estado.
• Iniciar y cerrar sesión con el servidor MSN.
Basado en otros proyectos de alta aceptación como una alternativa para los usuarios de conectarse a su MSN a un nivel básico de funcionalidad descrito anteriormente, sin publicidad ni las ventanas de promociones o de recopilación de información anónima, se plantea este proyecto.
1. MARCO TEORICO
1.1 MENSAJERIA INSTANTÁNEA
Teniendo en cuenta algunos conceptos de autores y definiciones que pueden ser encontradas en la Web podemos establecer concretamente que la Mensajería Instantánea es vista como un punto intermedio entre los sistemas de Chat basados en Web o en clientes de escritorio y los mensajes enviados a través del correo electrónico, así como las herramientas utilizadas en la mensajería instantánea, son programas regularmente gratuitos y requieren de la instalación en el PC.
El servicio de mensajería instantánea ofrece una ventana donde se escribe el mensaje, en texto plano o acompañado de iconos o emoticons, y se envían a uno o varios destinatarios quienes reciben los mensajes en tiempo real, el receptor tiene la posibilidad de leerlo y contestar en el acto.
En los últimos años se ha innovado dichos clientes añadiéndoles una serie de aplicaciones extra como la posibilidad de entablar conversaciones telefónicas, utilizando la infraestructura de Internet, lo mismo que contar con sistemas de información financiera en tiempo real, el compartir diferentes tipos de archivos y programas, incluidos juegos en línea, claro que estas mejoras generan costo en recursos del computador así como mayor espacio en el disco.
1.1.1 ¿Qué es el MSN Messenger? El termino “MSN Messenger” es bastante ambiguo, ya que Microsoft usa el término para referirse a diferentes partes de su solución de mensajería instantánea. Se chatea sobre la “red del MSN Messenger”. El programa más popular para conectarse a la red del MSN Messenger es el
"MSN Messenger", y el lenguaje que los programas hablan en la red del MSN Messenger es el "MSN Messenger protocol".
1.1.2 ¿Qué es la red del MSN Messenger? La red del MSN Messenger es una presencia y la red de mensajeria instantánea de Microsoft. Esta se conectó por primera vez en julio de 1999, y no es ni la primera ni la última red de mensajeria instantánea. MSN está entre el TOP 4 de las redes de mensajería instantánea propietaria. (Un ejemplo de la red MSN hecha por CISCO SYSTEMS lo podemos observar en el Anexo A, también en el Anexo B encontramos un diagrama de red MSN hecha por Microsoft).
1.1.3 ¿Qué pueden hacen los programas en la red del MSN Messenger? El programa en un PC se llama “cliente” de MSN Messenger. Este se conecta a un “servidor” del MSN Messenger a través del Internet. El cliente luego, envía y recibe información con otros clientes a través del servidor. La mayoría del tiempo, el cliente conversará con el servidor del MSN Messenger, que procesa la información y se la envía a las demás personas. Sin embargo, alguna información es simplemente pasada a través del servidor sin ser procesada. Por ejemplo, cuando se envía un mensaje instantáneo, el comando “aquí hay un mensaje, llévelo al destino” es procesado por el servidor, pero el mensaje solamente es pasado a través del servidor y procesador por el cliente.
Microsoft nunca ha hecho público su servidor de MSN Messenger, y el cliente oficial no permite conectarse a cualquier otro servidor que el operado por Microsoft. Aún así, alguna gente ha escrito y conectado otros servidores lo que nos lleva a la arquitectura de mensajería instantánea, donde podemos interconectar equipos hoy en día a través de diferentes tipos de mensajería (Ver Anexo C).
Las reglas para los mensajes enviados entre los clientes del MSN Messenger y los servidores tiene como nombre "MSN Messenger protocol".
Las reglas para los mensajes enviados desde un cliente a otro a través del servidor se le da el nombre de "MSN Client protocol".
1.1.4 ¿Qué es el MSN Messenger protocol? El MSN Messenger protocol consiste en una serie de comandos enviados entre el cliente y el servidor. Por ejemplo, cuando alguien en su lista de contactos se desconecta, los servidores envían un mensaje a su cliente como el siguiente: FLN [email protected]. Al recibir esto, el cliente debe quitar ese usuario fuera de la lista de usuarios conectados y ponerlo en la lista de usuarios desconectados.
El MSN Messenger protocol ha experimentado bastantes revisiones a través de los años. Al momento de escribirse, los servidores de Microsoft permitían a los clientes usar las versiones 8, 9, y 10 del protocolo. Versiones individuales del protocolo son a menudo escritas como "MSNP8", "MSNP9" y "MSNP10".
1.1.5 ¿Qué es el MSN Client protocol? El MSN Client protocol consiste en los mensajes enviados entre los clientes. Por ejemplo, cuando se dice “hola” a un amigo, su cliente envía un mensaje al cliente de su amigo con “hola” en el cuerpo del mensaje.
Hasta hace relativamente poco, el MSN client protocol crecía casi orgánicamente, una versión del cliente oficial se comportaba diferente a la de otro, y se tendría que adivinar, que comportamiento era esperado por quien. Recientemente, intentos se han hecho para imponer un sistema de numeración de versiones. En
Noviembre de 2003, tres versiones del MSN Messenger client protocol han sido observadas, las cuales son referidas como "MSNC0", "MSNC1", y "MSNC2".
1.1.6 ¿Cómo trabaja el protocolo? El MSN Messenger es una presencia y un sistema de mensajería instantánea. Usuarios de la presencia y del sistema de ingeniería instantánea (gente, bots, etc.) son referidos como ”principals".
Una sesión de MSN Messenger session envuelve una conexión a un "servidor de notificación" (NS), que provee un servicio a la presencia. El NS permite conectarse a los "switchboard servers" (SB) que proveen el servicio de mensajeria instantánea.
1.1.7 Servidores de notificación (NS). La conexión a un NS es la base de una sesión de MSN Messenger, ya que maneja la información de su presencia: si se está desconectado del NS, UD ya no se encuentra conectado para sus contactos. El propósito principal del NS es manejar la información de la presencia sobre UD y de los “principals” quienes lo tienen en su lista de contactos.
El NS también realiza otros servicios como notificar cuándo llega correo Nuevo y ayudar a crear nuevas sesiones o unirse a sesiones ya existentes. Cuando se es dirigido a unirse a una sesión, se debe abrir una nueva conexión al switchboard, y mantener el NS abierto.
1.1.8 Switchboard (SB). El switchboard maneja las sesiones de mensajería instantánea entre “principals”. En otras palabras, cada persona en un Chat de MSN corresponde a una conexión de una sesión compartida con el switchboard. Estar en dos conversaciones al mismo tiempo significa conectarse a dos SB al mismo tiempo. Conversaciones directamente conectadas entre principals no son
usadas en el MSN Messenger, y el SB actúa como un Proxy entre UD y aquellos con los que chatea.
Una sesión SB puede tener tantas personas como se quieran. Esto puede ser complicado por algunos de los usos que tiene la sesión SB como iniciar una transferencia de archivos.
El SB y el NS no están estrechamente integrados. Por ejemplo, cuando un principal en una session SB cambia su nick, el SB todavía envía mensajes y otros comandos con el nick antiguo. En adición, cuando un principal se desconecta del NS, todas las sesiones SB aún se mantienen abiertas hasta que el cliente explícitamente las cierre.
1.1.9 Conexiones del MSN Messenger. Todas las conexiones a los servidores MSN son hechas a través de los protocolos TCP/IP, el puerto oficial usado para dichas conexiones es el 1863.
La conexión al servidor debe ser considerada asincrónica, es decir, se pueden enviar varias peticiones al servidos sin esperar una respuesta y el servidor no responde a las peticiones en el mismo orden que fueron enviadas, pero en algunas ocasiones, caso concreto, al conectarse al servidor, el protocolo requiere que la conexión si sea sincrónica (el cliente envía un comando y el servidor responde a ese comando sucesivamente).
1.1.9.1 Conexiones HTTP. Microsoft usa la dirección gateway.messenger.hotmail.com, puerto 80, como su servidor para conexiones http, pero a diferencia de la dirección messenger.hotmail.com , este servidor jamás transfiere los clientes a otro servidor de notificación. Para tal fin en el método HTTP de MSN existe una función que logra tal objeto.
Aunque HTTP es capaz de enviar y recibir cualquier tipo de datos, no existe posibilidad alguna de que el servidor envíe un mensaje al cliente sin que el cliente lo haya pedido con anterioridad. Los clientes envían comandos en el “body” de una petición HTTP y el servidor envía la respuesta de la misma manera. Cuando el cliente no envía comandos por algunos segundos, debe pedir al servidor por nuevos mensajes por recibir.
1.1.9.1.1 Descripción del protocolo. En una conexión HTTP, los comandos enviados al servidor con una petición “POST” a un Script CGI. La primera petición hecha abre una nueva sesión en el servidor ya sea el Switchboard o el de notificaciones, para el servidor de notificaciones dicha petición debe ser enviada a gateway.messenger.hotmail.com o para el SwitchBoard a la dirección IP dada en el XFR recibido del servidor.
El cliente oficial trata de mantener siempre una conexión sencilla abierta a través de una sesión, aunque el ID de la sesión se incluye siempre durante la conexión por si en algún momento un error inesperado cierra la conexión. Asumiendo que el servidor no termina la sesión cuando se cierra la conexión, el cliente debe enviar el comando OUT para cerrar totalmente la conexión o simplemente esperar que el servidor la cierre por un “time-out”. (Para ilustrar más el protocolo en los anexos vemos un ejemplo de una petición y su respectiva respuesta al servidor de notificación).
2. JAVA
Java es un lenguaje de programación creado en parte para proliferar su uso en el Internet. Fue diseñado para “lucir y tener la sensación” del lenguaje C++, pero es mucho más simple de usar que C++, además de implementar el modelo programación orientada a objetos. Java puede ser usado para crear aplicaciones completas que puedan ser usadas en un solo computador o ser distribuidas entre servidores y clientes en una red. También puede ser usada para construir un pequeño módulo de aplicación o applet para ser usado como parte de una página Web.
Las principales características de Java son:
Los programas que se crean son portables en una red. El código fuente es compilado en lo que Java llama un bytecode, que puede ser ejecutado en cualquier lugar en una red, en un servidor o cliente que tenga instalado la máquina virtual de Java.
La máquina virtual de Java interpreta el Bytecode convirtiéndolo en código que se ejecuta en el hardware del computador. Esto quiere decir que las diferencias de las plataformas computacionales individuales como la longitud de una instrucción pueden ser reconocidas y acomodadas localmente mientras la aplicación se ejecuta.
El código es robusto, esto significa que, a diferencia de programas escritos en C++ y tal vez otros lenguajes, los objetos Java pueden no contener referencias a datos externos a ellos mismos u otros objetos conocidos. Esto asegura que una instrucción no puede contener la dirección en disco de algún dato en otra aplicación o en el sistema operativo, de lo contrario podría causar que el programa
o tal vez el sistema operativo sean terminados o “bloqueados”. La maquina virtual de Java hace cierto número de pruebas en cada objeto para asegurar la integridad.
Java es orientado a objetos, que significa que, entre otras características, un objeto tiene la ventaja de ser parte de una clase y herede código que es común en esa clase. Un método, puede ser visto como una capacidad o comportamiento de los objetos.
Relativamente respecto a C++, Java es un lenguaje más sencillo de aprender (aunque no es algo que se aprenda de la noche a la mañana).
JavaScript no debe ser confundido con Java. JavaScript, que fue creado por Netscape, es interpretado a un nivel mayor, mucho más fácil de aprender que Java, pero le falta la portabilidad de Java y la velocidad del Bytecode.
Por lo general, los programas en Java pasan a través de 5 fases para poder ejecutarse (Ver Anexo D). Estas fases son: edición, compilación, carga, verificación y ejecución.
El compilador de java (javac) traduce un programa en Java a códigos de bytes (Bytecode): el lenguaje que el intérprete de java puede entender. Si un programa se compila correctamente, el compilador produce un archivo con la extensión .class. Este es el archivo que contiene los códigos de bytes que se interpretarán durante la fase de ejecución.
Un programa en java debe colocarse en memoria antes de que pueda ejecutarse. De esto se encarga al cargador de clases que toma el archivo (o archivos) .class que contiene los códigos de bytes y lo transfiere a la memoria principal. El archivo .class puede cargarse desde un disco en su sistema o a través de una red.
Una aplicación es un programa que generalmente se guarda y se ejecuta en el equipo local del usuario. Las aplicaciones se cargan en memoria y después se ejecutan mediante el intérprete java.
Java ha sido escogido para este proyecto por las ventajas que tiene desde su creación, es un lenguaje que es portable, esto hace que la aplicación pueda ser transportada fácilmente debido a que son de bajo tamaño. Además, dado a su diferente compilación puede ser ejecutado en casi cualquier sistema operativo que tenga la JVM (máquina virtual de Java) haciendo que su compatibilidad sea bastante amplia y así es más abierta la implementación de la aplicación en cualquier computador. Por las dos razones anteriormente descritas lo hacen virtualmente ejecutable en cualquier computador hoy en día.
También al ser un lenguaje orientado a objetos hace que su programación sea mucho más ordenada, exacta y los errores existentes sean más fáciles de detectar y corregir.
2.1 SOCKETS
Las URLs y las conexiones URL proveen relativamente un mecanismo de alto nivel para acceder recursos en el Internet. Algunas veces los programas requieren comunicación con las redes de bajo nivel, por ejemplo cuando se crea una aplicación cliente/servidor.
En las aplicaciones cliente/servidor, el servidor da algunos servicios, como el procesamiento de peticiones a la base de datos. El cliente hace uso de los servicios ofrecidos por el servidor. Esta comunicación que ocurre entre el cliente y el servidor debe ser confiable, esto quiere decir, que ningún dato puede ser perdido y debe llegar al cliente en el mismo orden en el que fue enviado.
Los sockets son los puntos finales en los enlaces de comunicación entre un programa cliente y un programa servidor. El paquete de java.net provee dos clases Socket y ServerSocket que son implementadas en el lado del cliente de la conexión y en el lado de la conexión del servidor respectivamente.
El tipo de sockets describe la forma en la que se transfiere información a través de ese socket.
Normalmente, un servidor corre en un computador y tiene un socket que está comprometido a un Puerto específico. El servidor simplemente espera que un cliente haga una petición de conexión (Ver Anexo E).
Si todo va bien, el servidor acepta la conexión. Luego de aceptar, el servidor inicia otro socket con otro puerto diferente. Él necesita un nuevo socket y por consiguiente un puerto diferente para que así pueda seguir a la espera del socket original por peticiones de conexión mientras atiende las necesidades del cliente conectado (Ver Anexo F).
En el lado del cliente, si la conexión es aceptada, un socket creado correctamente puede ser usado para que el cliente se comunique con el servidor.
2.1.1 Sockets Stream. Es un servicio orientado a conexión donde los datos se transfieren sin encuadrarlos en registros o bloques. Si se rompe la conexión entre los procesos, éstos serán informados.
El protocolo de comunicaciones con streams es un protocolo orientado a conexión, ya que para establecer una comunicación utilizando el protocolo TCP, hay que establecer en primer lugar una conexión entre un par de sockets. Mientras uno de los sockets atiende peticiones de conexión (servidor), el otro solicita una conexión
(cliente). Una vez que los dos sockets estén conectados, se pueden utilizar para transmitir datos en ambas direcciones.
2.1.2 Sockets Datagrama. Es un servicio de transporte sin conexión. Más eficientes que TCP, pero no está garantizada la fiabilidad. Los datos se envían y reciben en paquetes, cuya entrega no está garantizada. Los paquetes pueden ser duplicados, perdidos o llegar en un orden diferente al que se envió.
El protocolo de comunicaciones con datagramas es un protocolo sin conexión, es decir, cada vez que se envíen datagramas es necesario enviar el descriptor del socket local y la dirección del socket que debe recibir el datagrama. Como se puede ver, hay que enviar datos adicionales cada vez que se realice una comunicación.
2.1.3 Sockets Raw. Son sockets que dan acceso directo a la capa de software de red subyacente o a protocolos de más bajo nivel. Se utilizan sobre todo para la depuración del código de los protocolos.
2.1.4 Diferencias entre Sockets Stream y Datagrama. En UDP, cada vez que se envía un datagrama, hay que enviar también el descriptor del socket local y la dirección del socket que va a recibir el datagrama, luego éstos son más grandes que los TCP.
Como el protocolo TCP está orientado a conexión, tenemos que establecer esta conexión entre los dos sockets antes que nada, lo que implica un cierto tiempo empleado en el establecimiento de la conexión, que no existe en UDP.
En UDP hay un límite de tamaño de los datagramas, establecido en 64 kilobytes, que se pueden enviar a una localización determinada, mientras que TCP no tiene
límite; una vez que se ha establecido la conexión, el par de sockets funciona como los streams: todos los datos se leen inmediatamente, en el mismo orden en que se van recibiendo.
UDP es un protocolo desordenado, que no garantiza que los datagramas que se hayan enviado sean recibidos en el mismo orden por el socket de recepción. Al contrario, TCP es un protocolo ordenado, que garantiza que todos los paquetes que se envíen sean recibidos en el socket destino y en el mismo orden en que fueron enviado.
Los datagramas son bloques de información del tipo lanzar y olvidar. Para la mayoría de los programas que utilicen la red, el usar un flujo TCP en vez de un datagrama UDP es más sencillo y hay menos posibilidades de tener problemas. Sin embargo, cuando se requiere un rendimiento óptimo, y está justificado el tiempo adicional que supone realizar la verificación de los datos, los datagramas son un mecanismo realmente útil.
En resumen, TCP parece más indicado para la implementación de servicios de red como un control remoto (rlogin, telnet) y transmisión de ficheros (ftp); que necesitan transmitir datos de longitud indefinida. UDP es menos complejo y tiene una menor sobrecarga sobre la conexión; esto hace que sea el indicado en la implementación de aplicaciones cliente/servidor en sistemas distribuidos montados sobre redes de área local.
3. PATRONES DE DISEÑO DE CREACIÓN
3.1 FABRICA ABSTRACTA
El patrón de diseño fábrica abstracta permite a un sistema determinar la subclase a partir de la cual se va a instancia un objeto en tiempo de ejecución. A menudo, esta subclase es desconocida durante el desarrollo. Sin embargo, el patrón de diseño fábrica abstracta utiliza un objeto conocido como “fábrica”, que utiliza una interfaz para instanciar objetos. Una fábrica crea un producto; en este caso, ese producto es un objeto de una subclase que se determina en tiempo de ejecución.
4. PATRONES DE DISEÑO DE ESTRUCTURA
4.1 DECORADOR
El patrón de diseño decorador permite a un objeto obtener una funcionalidad adicional en forma dinámica. Mediante el uso de este patrón, los diseñadores no tienen que crear clases separadas innecesarias para añadir responsabilidades a los objetos de una clase dada.
4.2 FACHADA
Al conducir un auto, usted sabe que si oprime el pedal del acelerador su auto aumenta de velocidad, pero no sabe exactamente por qué el pedal del acelerador hace que su auto acelere. Este principio es la base del patrón de diseño Fachada, el cual permite a un objeto (al que se le conoce como objeto fachada) proporcionar una interfaz simple para los comportamientos de un subsistema (un agregado de objetos que conforman colectivamente una responsabilidad importante del sistema). Por ejemplo, el pedal del acelerador es el objeto fachada para el subsistema de aceleración del auto, el volante de dirección es el objeto fachada para el subsistema de desaceleración del auto. Un objeto cliente utiliza el objeto fachada para acceder a los objetos que están detrás de la fachada. El cliente permanece sin saber como los objetos detrás de la fachada cumplen con sus responsabilidades, por lo que la complejidad del sistema está oculta para el cliente. Cuando usted oprime el pedal del acelerador, actúa como un objeto cliente. El patrón de diseño Fachada reduce la complejidad del sistema, ya que un cliente interactúa solamente con un objeto (la fachada) para acceder a los comportamientos del subsistema que está representado por esa fachada. Este patrón protege a los desarrolladores de aplicaciones contra las complejidades de
los subsistemas. Los desarrolladores necesitan estar familiarizados solamente con las operaciones del objeto fachada, en vez de tener que conocer las operaciones más detalladas de todo el subsistema completo. La implementación detrás de la fachada puede modificarse sin necesidad de realizar cambios en los clientes.
5. PATRONES DE ARQUITECTURA
Los patrones de diseño permiten a los desarrolladores diseñar partes específicas de subsistemas, como el abstraer los instanciamientos de objetos o el agregar clases a estructuras más grandes. Los patrones de diseño también promueven el poco acoplamiento entre los objetos. Lo patrones de arquitectura promueven el poco acoplamiento entre los subsistemas. Estos patrones especifican como deben interactuar los sistemas entre sí.
5.1 ARQUITECTURA MODELO-VISTA-CONTROLADOR
Consideremos el diseño de un editor de texto simple. En este programa, el usuario introduce texto desde el teclado y da formato a este texto mediante el ratón. Nuestro programa almacena este texto y la información del formato en una serie de estructura de datos, y después muestra esta información en pantalla para que el usuario pueda leer lo que ha introducido.
El controlador implementa la lógica para procesar la entrada del usuario. El modelo contiene los datos de la aplicación y la vista presenta los datos almacenados en el modelo. Cuando un usuario proporciona datos de entrada, el controlador modifica el modelo en base a la entrada recibida. El modelo contiene los datos de la aplicación.
Con respecto al ejemplo del editor de texto, el modelo podría contener solamente los caracteres que conforma el documento. Cuando el modelo cambia, notifica a la vista acerca del cambio, para que ésta pueda actualizar su presentación con los datos modificados. La vista en un procesador de palabras podría mostrar los
caracteres utilizando un tipo de letra específico, con un tamaño especifico, etcétera.
El MVC no restringe a una aplicación a una sola vista o a un solo controlador. En un programa más sofisticado (como un procesador de palabras), podría haber dos vistas de un modelo de documento completo. El procesador de palabras podría también implementar varios controladores: uno para manejar la entrada del teclado y otro para manejar las selecciones del ratón. Si cualquiera de los controladores realiza un cambio en el modelo, tanto la vista del bosquejo como la ventana de vista previa de impresión mostrarán el cambio inmediatamente, cuando el modelo notifique los cambios a todas las vistas.
Otro beneficio del MVC es que los desarrolladores pueden modificar cada componente de manera individual, sin tener que modificar los demás componentes. Por ejemplo, los desarrolladores podrían modificar la vista que muestra el documento en línea, y no tendrían que modificar ni el modelo ni las demás vistas o controladores. (Ver Anexo G).
5.2 NIVELES O CAPAS
El nivel de información, también conocido como el nivel inferior, mantiene los datos para la aplicación, guardando generalmente los datos en una base de datos. El nivel de información para una tienda en línea puede tener información sobre los productos, como las descripciones, precios, cantidades en almacén y la información del cliente, como los nombres de usuarios, direcciones de facturación y números de tarjetas de crédito.
El nivel medio actúa como un intermediario entre el nivel de infamación y el nivel cliente. El nivel medio procesa las peticiones del nivel cliente, y lee los datos de (escribe los datos hacia) la base de datos. El nivel medio entonces procesa los
datos del nivel de información y presenta el contenido al nivel cliente. Este procesamiento es la lógica de negocios de la aplicación, la cual se encarga de las tareas como recuperar los datos del nivel de información, asegurar que los datos sean confiables antes de actualizar la base de datos y presentar los datos al nivel cliente. Por ejemplo, la lógica de negocios podría entonces almacenar (o recuperar) la información de crédito en la base de datos y notificar al nivel cliente que la verificación tuvo éxito.
El nivel cliente (también conocido como el nivel superior) es la interfaz del usuario de la aplicación, como un navegador Web estándar. Los usuarios interactúan directamente con la aplicación a través de la interfaz de usuario. El nivel cliente interactúa con el nivel medio para hacer peticiones y recuperar datos del nivel de información. El nivel cliente entonces muestra los datos recuperados del nivel medio.
6. CREACIÓN DE LA APLICACION
6.1 INVESTIGACIÓN DE LOS PROTOCOLOS
Para tener una certeza de cómo los protocolos trabajan, además de cómo envían la información y qué tipos de comandos se usan, como están distribuidos en los paquetes, en qué momento usar qué comandos y demás caracterizaciones de la comunicación, se dio a la tarea de grabar el tráfico de la red con un programa especializado para el caso.
Antes que nada había que normalizar la red, hacer una búsqueda de puertos abiertos, en escucha, ocupado sin si quiera tener el cliente oficial abierto quien fuese el usado para la investigación. Luego de esto se cerraron todos los programas que pedían acceso a Internet para tener la red totalmente libre de cualquier información que no necesitara en el momento. Al tener totalmente “silenciosa” la red, se podía dar inicio a la investigación.
Al ejecutar el programa usado para examinar en la red, se provee de ciertos campos a usar en el mismo como por ejemplo: Dirección IP de la fuente, dirección IP del destino, el protocolo que se está usando y la información enviada de un destino a otro. Así cada uno de estos campos da respuestas inmediatas a algunas de las preguntas más grandes que se tienen al momento, las direcciones de los servidores a los cuales se conecta el cliente, además de la forma en la que se envían los paquetes, los comandos a usar y la información que constantemente le pide el servidor al usuario y que en algunos casos no es necesario responder.
En la información que se recopila se aprecian ciertos comandos como USR, CAL, JOI, MSG, entre otros, dichos comandos son para actualizar la ventana de la lista de contactos (conexiones, desconexiones), también los cambios de estado
(conectado, ausente, no disponible) hasta cuando se abre una ventana de conversación con algún contacto aún sin enviar ningún mensaje de texto.
Todo esto comienza a crear un bosquejo de cómo la aplicación debe ser programada, creando clases que manejen los tres diferentes servidores a los cuales se accede y los numerosos comandos que se hallan en la comunicación que se usan durante toda la vida de la conexión, dando lugar a una versión primitiva de la aplicación enviando, recibiendo y respondiendo a los comandos, interactuando con los servidores y corroborando lo aprendido en la investigación de la comunicación y del protocolo del MSN.
En el Anexo I se pueden ver las primeras comunicaciones que ocurren entre el cliente y el servidor, también las direcciones de los diferentes servidores con los que se comunica el cliente para lograr una conexión satisfactoria.
Como nada es perfecto de vez en cuando se encontraron paquetes que por error de comunicación, el programa los enmarcó como paquetes mal formados sin explicación del error (como puede ser visto en el Anexo J) así que se asume que por algún problema de comunicación hubo lugar al error y la comunicación no fue exitosa, hubo que crear una clase que manejara este tipo de excepciones, cuyas pruebas tuvieron lugar a varios días, los cuales se dieron a la reestructuración de la misma clase para aumentar el rango de alcance de los errores captados y evitar un bloqueo de la aplicación.
Al concretarse la conexión, los primeros comandos que se reciben del servidor, son los cambios que toman lugar entre la última conexión realizada y la que se está llevando a cabo, cambios como nuevos correos en la bandeja de entrada, nuevos contactos que han agregado la cuenta entre otros (Véase Anexo K). Cabe mencionar que la mayoría de los comandos recibidos por el MSN no requieren respuesta por parte del cliente es decisión del programador enviar una respuesta o
tomar una acción por los comandos así como también de hacer caso omiso de este, uno de los comandos que requieren una respuesta es el CHALLENGE cuyo comando es CHL, es un comando que el servidor envía a todos los clientes conectados de manera aleatoria para saber si aún siguen conectados. En dado caso que el cliente no lo responda, el servidor dará por terminada la sesión que está activa, así que es prioridad del programador responder cada CHL que sea recibido del servidor.
Una de las curiosidades del protocolo del MSN es que maneja ciertos comandos que no se usan en su totalidad en el cliente oficial. El más común encontrado en la comunicación es el comando JOI que aluce al ingles join en nuestro idioma unirse, en el caso de una conversación uno a uno (el cliente con un solo contacto) este comando se obvia en el cliente oficial por razones desconocidas, el comando tiene lugar cuando el cliente abre una ventana de conversación con un contacto sin enviar algún mensaje previamente. Por lo tanto, si en el cliente implementara el uso de este comando, cualquier usuario conectado al MSN, podría ver quien abre una ventana para hablar pero se arrepiente de hacerlo y la cierra nuevamente. Este comando tiene su uso cuando un cliente comienza una conversación con más de un contacto, al agregar otro contacto a una conversación ya existente, el comando JOI alerta a los dos primeros usuarios de la conversación de la llegada del tercero y así sucesivamente.
En el Anexo L encontramos que el cliente ([email protected]) abre una ventana de conversación con uno de sus contactos ([email protected]) pero aun no envía ningún mensaje.
El envío de los mensajes, en este protocolo también tiene una codificación la cual podemos ver de una manera gráfica en el Anexo M. En ésta conversación tenemos a dos contactos, el cliente ([email protected]) y el contacto ([email protected]), que en la comunicación no podemos observar con
claridad los mensajes que se envían de un contacto a otro, todo esto por el principio básico de seguridad, la privacidad, la cual es uno de los grandes fuertes de este protocolo desde su versión 7.
Luego de obtener esta información durante la investigación, aún se estaba en un estado muy primitivo en el que por codificaciones no se veía con exactitud cómo los comandos eran enviados y para qué servían la mayoría, por eso otra aplicación fue usada como apoyo para dar más exactitud y claridad al protocolo.
En el Anexo N. Se observa con más facilidad la forma como se conecta el mensajero a los servidores de MSN, los comandos más fáciles de diferenciar, además de la sintaxis con la que los comandos son enviados.
En los Anexos O, P Y Q se observa los diferentes comandos usados en el protocolo MSN, para el cliente.
Con toda esta información recopilada, ya se tiene un bosquejo del manejo del cliente con los servidores y se procede a modelar la aplicación.
6.2 CASOS DE USO
6.2.1 Versión 1.0. En el caso de uso versión 1.0 es la primera revisión que hubo de la aplicación como tal, cómo debería ser, sus actores y la interacción con los casos que podrían realizar, un bosquejo para comenzar a darle dirección a la aplicación, crear algo sólido, con cuerpo para dar más revisiones y correcciones mejorando desde el diseño y evitando así correcciones de código que son mucho más complicadas.
• Usuario • Servidor MSN
Además, tenemos los siguientes casos:
• Iniciar sesión • Cerrar sesión • Enviar mensaje • Modificar estado • Recibir notificaciones • Obtener lista de contactos
Al analizar este caso de uso, encontramos que aún se encuentra en un estado incompleto, que falta por especializar y mejorar y acercarnos más a la realidad que la aplicación debe tener. Por estas razones se dio a la tarea de mejorar tal caso de uso para llegar al siguiente. A continuación:
6.2.2 Versión 1.1. En la versión 1.1 se tienen cambios que hacen ver el diseño mucho mejor para una visión más clara de lo que la aplicación debe realizar, cambios de la versión anterior que bosquejan más a la realidad de la aplicación. Dichas modificaciones que tomaron lugar por las modificaciones que se necesitaban hacer, para un mejor funcionamiento del modelo, no se había implementado un nuevo actor que es el Switchboard (SB), para diferenciar dos tipos de servidores que se presentan en el uso del protocolo MSN.
Tenemos los actores:
• Usuario
• Servidor de notificación • Switchboard
Con los diferentes casos que son:
• Cerrar sesión • Iniciar sesión
• Obtener lista de contactos • Recibir notificaciones • Modificar estado • Enviar mensaje
En esta nueva versión de los casos de uso, el cambio de mayor grado es, que el servidor MSN, se crean dos, es decir, el Swicthboard y el servidor de notificación, que son a los cuales el cliente se conecta cuando inicia sesión al MSN, por tanto los casos que interactúan con el usuario toman destinos diferentes, a cada servidor a los que corresponden. Aun así los casos de uso, necesitan de más acercamiento, de mayor precisión por eso al analizar este caso de uso, se creó
Figura 2. Caso de Uso Versión 1.1
6.2.3 Versión 1.2. La versión 1.2 es la mas aplicada al funcionamiento de los servidores MSN con el cliente por lo tanto se acerca mas a lo que la aplicación debe funcionar como tal. Los cambios mostrados entre la versión 1.1 y la versión 1.2 no son grandes pero si corrigen ciertos errores, que de de existir la necesidad de corregirlos en código podría complicarse de una manera bastante grave. Estos errores vistos en el modelo fueron encontrados gracias a la investigación realizada por un programa (sniffer) que rastrea el tráfico del MSN.
Los actores que intervienen en esta versión son:
• Usuario • Switchboard
Los casos de uso:
• Introducir login y contraseña • Iniciar sesión • Cerrar sesión • Modificar estado • Cambiar nick • Enviar/Recibir mensaje • Se conecta/Desconecta un contacto • Recibir lista de contactos
• Recibir notificaciones
Dado a los cambios realizados en los casos de uso, al crear unos nuevos, modificar algunos y arreglar los destinos (servidores) de otros se especializan mas los casos de uso llegando a un punto donde la aplicación puede comenzar a ser programada con una disminución de errores gratificante. Aun así, con el objetivo de mayor seguridad de programación y aumentar la disminución de errores en el código se analiza una ves mas, para puntualizar mejor la aplicación llegando a una nueva versión de los casos de uso a continuación.
Figura 3. Caso de Uso Versión 1.2
6.2.4 Versión 1.3 La nueva versión 1.3 mejora a la 1.2 en ciertos aspectos mucho mas notorios que los cambios ocurridos de 1.1 a 1.2, como la creación de un nuevo actor (ventana de comunicación) y la especialización de los casos de uso en este actor, ya que a estudiar mas a fondo los servidores se encontró con que ciertos casos de uso no llegan hasta el usuario sino se quedan en un actor que se dio por nombre ventana de comunicación.
Los actores que aparecen en esta versión:
• Switchboard
• Servidor de notificación • Ventana de comunicación
Y los casos de uso que se mantienen son:
• Introducir login y clave • Iniciar sesión • Cerrar sesión • Modificar estado • Cambiar nick • Enviar/Recibir mensaje • Se conecta/Desconecta un contacto • Recibir lista de contactos
• Recibir notificaciones
Podemos observar en la aplicación, que los casos de uso se mantienen pero la creación de un nuevo actor nos hace rediseñar esta versión y plantear la interacción de los casos con los actores de tal manera que sea mucho mas claro para la programación y el envío de información en la red.
Al programar la aplicación y generar una conexión directa con los servidores MSN todo debería dar un buen resultado, gracias al modelado.
Figura 4. Caso De Uso Versión 1.3
6.3 DIAGRAMAS DE SECUENCIA
Los diagramas de secuencia modelan la interacción entre los objetos del sistema, en este caso mostramos la interacción de los casos de uso, anteriormente vistos, los nueve de ellos, que observamos a continuación.
6.3.1 Iniciar Sesión. El primero de ellos “iniciar sesión” es el que se relaciona a continuación. (Figura 5)
Acá vemos la interacción del actor Usuario para hacer la petición de iniciar sesión en los servidores MSN y la manera como se hace, el envía un comando al los servidores a través de la pantalla de inicio de sesión.
Este comando esta compuesto de la manera adecuada llevando en si el login del usuario y su respectiva contraseña, este comando es enviado al servidor que realiza un control.
Primero, se revisa que existe el login en la base de datos, luego se corrobora que la contraseña corresponda al login suministrado cuando estos dos datos han sido verificados y la prueba ha sido exitosa, este comando finalmente llega al MSN para su inicio de sesión en el servidor e intercambio de información necesaria para la continuidad en el servicio.
Figura 5. Diagrama de secuencia “Iniciar Sesión”
6.3.2 Cerrar Sesión. El diagrama “Cerrar sesión” (Figura 6) tiene ciertas características parecidas al iniciar sesión, con la única diferencia, que el comando se envía sin ninguna otra información más que la petición de cerrar la sesión. El usuario envía el comando de cerrar sesión al servidor, que hace un control de que la sesión aun esta abierta y no es un ataque contra los servidores tratando de desconectarlos, al corroborar que la sesión aun esta activa, el servidor MSN, la cierra y envía la respuesta al cliente para que el cliente tome la acciones localmente dándole aviso a la persona dueña del usuario de conexión.
Figura 6. Diagrama de secuencia “Cerrar Sesión”
6.3.3 Iniciar conversación. (Figura 7) un diagrama importante ya que es el crea la comunicación real entre contactos. Antes que nada el cliente tiene la restricción de que si un contacto esta desconectado no puede enviar mensaje por eso, no hay necesidad de hacer tal comprobación a nivel de servidores, una vez el usuario
abre la ventana de comunicación con un contacto, se envían ciertos comandos para establecer una sesión con el switchboard (esta conexión es totalmente invisible por los contactos) una vez hecha, el mensaje es enviado y recibido por el contacto iniciando la conversación (para los contactos) que continua hasta que se cierra la ventana de conversación.
Figura 7. Diagrama de Secuencia “Iniciar Conversación”
6.3.4 Recibir mensaje de contacto. (Figura 8) es un diagrama que complementa a Iniciar conversación, ya que este comprueba que la conexión hecha con el switchboard ya se encuentra hecha, en caso contrario el cliente pide una conexión con el SB y lleva a cabo las comprobaciones enviando los comandos y el mensaje a su destino.
Figura 8. Diagrama de Secuencia “Recibir mensaje de contacto”
6.3.5 Enviar mensaje a contacto (Figura 9) un diagrama que así como recibir mensaje, hace uso de iniciar conversación, revisando si la conexión con el SB se encuentra hecha, en caso contrario, se solicita una nueva sesión en el SB entre el usuario y el contacto con quien se lleva a cabo la conversación, manteniéndola hasta el cierre de la ventana.
Figura 9. Diagrama de Secuencia “Enviar mensaje a contacto”
6.3.6 Se Conecta/Desconecta un contacto. Un evento grande que se da a nivel del cliente, pero que en realidad son comandos sencillos a nivel de conexión de red, cuando el contacto se conecta, envía un comando al servidor de conexión al lograr esta conexión, el servidor envía un comando a todos los de la lista de contactos que se encuentran en sesión, diciendo que se ha conectado, así que el cliente hace la modificación en su lista local y lo muestra como conectado con el estado que el contacto haya hecho efectivo(ver figura 10).
Figura 10. Diagrama de Secuencia “Se conecta / desconecta un contacto”
6.3.7 Recibir Lista de Contactos. El cliente al hacer una conexión al servidor MSN uno de los primeros comandos que debe enviar es recibir la lista de contactos (Figura 11), cabe mencionar que existen tres tipos de lista de contactos que se pueden recibir del servidor, la lista de contactos agregados a la lista, la lista de contactos no admitidos y la lista de contactos que contienen al usuario en lista. Así que es cuestión de la construcción de la aplicación, que listas cargar, como es debido y esta hecho en el cliente oficial, esta aplicación carga la lista de contactos admitidos y la lista de no admitidos.
Figura 11. Diagrama de Secuencia “Recibir Lista de Contactos”
6.3.8 Modificar Estado. El diagrama de modificar estado (Figura 12), como vemos a continuación lleva el proceso de verificación de conexión al NS (Notification Server) y enviar el comando de nuevo estado haciendo la modificación para el cliente y la lista de contactos que han agregado a su lista el usuario. Actualizando por completo el estado.
Figura 12. Diagrama de Secuencia “Modificar Estado”
6.3.9 Cambiar Nick El estado cambiar nick, no difiere mucho del cambiar estado, ya que en síntesis lleva el mismo comportamiento, verifica conexión con el NS, luego envía comando de petición de cambio de nick, al lograr esto, el servidor se encarga de actualizarlo en el cliente y los contactos que se tengan.
6.4 IMÁGENES DE LA APLICACIÓN
Figura 14. Ventana Presentación Mensajero
Presentación principal de la aplicación para cargar todo lo necesario para correr correctamente en una ventana mucho mas completa.
Figura 15. Ventana principal del mensajero
En la Figura 15. Podemos observar la ventana principal del mensajero que contiene los botones principales para el manejo además de un menú en la parte
superior izquierda en el cual se encuentran las diferentes acciones que se pueden escoger para la conexión, también vemos la ventana auxiliar donde el usuario ingresa su nombre de usuario en el patrón [email protected], tomando en cuenta que puede ingresar cualquier correo que tenga registrado en www.passport.com
el programa revisa que el correo sea escrito
nombre_de_usuario@servidor_de_correo.com para evitar algún error en este paso de la conexión; Luego de esto tiene que ingresar su clave de correo que se guarda en una variable solo con el propósito de enviarla al servidor MSN para autenticación cuya información es revelada en la vista de los comandos en la ventana pero en ningún momento con la intención de exponerla o divulgarla públicamente (ver Figura 16).
Figura 17. Mensajero Conectando al servidor.
En la figura 17 vemos que el programa se encuentra enviando y recibiendo comandos interactuando con el servidor para lograr la conexión al servicio de MSN, por motivos educativos estos comandos son visibles en esta versión de la aplicación en el caso donde fuera comercial los comando y sus atributos no deben ser revelados ya que pueden ser explotados de manera maliciosa para obtener información de algún contacto como su clave o la lista de contactos. En la imagen podemos observar tres tipos de datos los datos o comandos enviados por el cliente y los recibidos por parte del servidor, en este punto la comunicación es sincrónica ya que se necesita que por cada comando enviado por el cliente debe haber uno recibido por el servidor, y un tercer dato que son los comentarios que el
cliente imprime en pantalla para que el usuario pueda comprender con mas facilidad lo que esta sucediendo durante la conexión al servidor.
Una vez la conexión se ha establecido el servidor comienza a enviar la lista de contactos que el usuario tiene cargándolos en la ventana al lado derecho de la aplicación creando una sesión al servidor estable abierta para cualquier evento que se desee realizar (ver figura 18).
Figura 19. Conversación Activa.
En la figura 19 se puede ver, como el cliente se conecta a un contacto recibiendo un mensaje y entablando una conversación a través de una sesión con el SB, enviando y recibiendo mensajes, también visto en la figura 20.
7. CONCLUSIONES
Como en la programación la escritura de código no lo es todo, también interviene el proceso de diseño de la aplicación y aquí es donde se usa el UML que es totalmente necesario en la actualidad para desarrollar software orientado a objetos o por lo menos lo fue para este proyecto, ya que permitió evitar errores que en la construcción del código seria mucho mas complicado de corregir, en las fases de análisis y de diseño por sus métodos, además de lo visto en las diferentes materias de que orientaron a la buena practica del desarrollo del software como es llevar a cabo el análisis, diseño, implementación y prueba de la aplicación.
Aunque UML evito en gran parte los problemas, en los casos de uso, evitando de esta manera cualquier contrariedad con las actualizaciones hechas, teniendo como consecuencia un mejor manejo de la aplicación, más rapidez en petición y respuesta, además de estar al tanto con la tecnología de punta usada por Microsoft.
Al punto donde se tiene la aplicación los conocimientos obtenidos son de gran ayuda ya que la aplicabilidad que tienen a cualquier tipo de desarrollo laboral son amplias tales conocimientos como el afianzamiento en la programación orientada a objetos en JAVA, la profundización en la programación de aplicaciones cliente/servidor, manejo de redes, recursos de desarrollo como el UML, manejo de sockets, conocimientos en el manejo de Proxies en la programación, cifrado MD5 para la autenticación de usuarios en Microsoft, conocimientos avanzados en los servidores de Microsoft además de su manejo de seguridad para envío y recepción de mensajes como autenticación.
BIBLIOGRAFIA
C.A. Sabino. Cómo hacer una tesis y elaborar todo tipo de escritos, Pearson Prentice Hall, Santa fe de Bogotá, 2004.
H.M. Deitel y P.J. Deitel. Como programar en Java. Pearson educación, 2004.
Instituto Colombiano De Normas Técnicas. Normas Colombianas para la presentación de trabajos de investigación. Segunda actualización. Santa fe de Bogota D.C.: ICONTEC, 1996.
J. Jaworski. Seguridad en Java. Prentice Hall, Madrid, 2001
M. Pawlan. Essentials of the Java programming language hands-on guide Reading Addison-Wesley, 2000
P.S. Wang. Java con programación orientada a objetos y aplicaciones en la WWW, International Thomson Editores, México, 1999.
BIBLIOGRAFÍA COMPLEMENTARIA
M. Mintz. MSN Messenger. http://www.hypothetic.org/docs/msn/ , Agosto de 2006
Programación en Castellano, S.L. Java En Castellano. http://www.programacion.com/java/ , Julio de 2006
Sun Microsystems, Inc. Reference Documentation, http://java.sun.com/docs/ , Septiembre de 2006
Anexo A. Diagrama de Arquitectura de Comunicación MSN Messenger de CISCO.
Anexo B. Diagrama de Arquitectura de Comunicación MSN Messenger Internet/Wireless
Ejemplo De Una Petición Y Respuesta Al Servidor De Notificación POST http://gateway.messenger.hotmail.com/gateway/gateway. dll?Action=open&Server=NS&IP=messenger.hotmail.com HTTP/1.1\r\n Accept: */*\r\n Accept-Language: en-us\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: MSMSGS\r\n Host: gateway.messenger.hotmail.com\r\n Proxy-Connection: Keep-Alive\r\n Connection: Keep-Alive\r\n Pragma: no-cache\r\n Content-Type: application/x-msn-messenger\r\n Content-Length: 18\r\n \r\n VER 5 MSNP8 CVR0\r\n HTTP/1.0 200 OK\r\n Server: Microsoft-IIS/5.0\r\n
Date: Tue, 18 Mar 2003 07:39:53 GMT\r\n
X-MSN-Messenger: SessionID=954547325.13160;
GW-IP=207.46.110.18\r\n
Content-Length: 18\r\n
Content-Type: application/x-msn-messenger\r\n
Age: 0\r\n
Via: HTTP/1.1 ntl_site (Traffic-Server/5.2.0-R [c sSf
])\r\n
X-Cache: MISS from nautilus.localdomain\r\n
X-Cache-Lookup: MISS from nautilus.localdomain:80\r\n
Proxy-Connection: keep-alive\r\n
\r\n
Anexo E. Peticion de conexión del cliente
http://java.sun.com/docs/books/tutorial/networking/sockets/definition.html, Sept 2005
Anexo F. Respuesta de conexión del servidor.
http://java.sun.com/docs/books/tutorial/networking/sockets/definition.html, Sept, 2005
Anexo G. Arquitectura Modelo-Vista-Controlador.
Controlador Modifica Notifica Vista
Anexo H. Modelo de aplicación de tres niveles. Nivel cliente (Nivel superior) Nivel Medio Aplicación Nivel de información (Nivel inferior) Base de datos
Anexo J. Errores recibidos de los servidores de MSN.
Anexo L. Apertura de ventana de conversación con un contacto.
Anexo O. Cargando la lista de contactos.
