Qu son los WebSockets ?

Los WebSockets representan una esperadsima evolucin de la tecnologa web cliente / servidor. Permiten una conexin de socket TCP que se establece entre el cliente y el servidor que permite bidireccionamiento full dplex , los mensajes se distribuyen instantneamente con poca sobrecarga lo que resulta en una conexin de muy baja latencia. Tanto la API de WebSocket y el protocolo WebSocket estn estandarizados que significa la web ahora tiene una norma acordada para la comunicacin en tiempo real entre los clientes y servidores de Internet . Originalmente considerada una tecnologa de navegador , WebSockets est llegando mucho ms all de los navegadores web y se estn convirtiendo en un estndar multiplataforma para la comunicacin en tiempo real entre el cliente y el servidor. Adems del soporte nativo de WebSocket en navegadores como Google Chrome , Firefox , Opera y un prototipo de la aplicacin de Silverlight para JavaScript Bridge para Internet Explorer, en la actualidad hay implementaciones de la librera WebSocket en Objective- C, . NET , Ruby , Java, Node.js , ActionScript y muchos otros lenguajes.

Por qu son los WebSockets un cambio de juego?

Finalmente, los WebSockets representan un estndar para la comunicacin en tiempo real bidireccional entre servidores y clientes. En primer lugar en los navegadores web , pero ultimadamente entre cualquier servidor y cualquier cliente. El primer enfoque de estos estndares significa que, como desarrolladores, medida que por fin podremos crear funcionalidades que siempre trabajen a travs de mltiples plataformas. Las limitaciones de conexin ya no son un problema, ya que WebSockets representan una sola conexin de socket TCP . La comunicacin entre dominios se ha considerado desde el primer da y es tratado en el protocolo de enlace de conexin (handshake). Esto significa que los servicios como Pusher pueden utilizarlos fcilmente pues ofrecen una plataforma en tiempo real masivamente escalable que pueda ser utilizada por cualquier aplicacin de sitio web, web , de escritorio o mvil .

WebSockets vs AJAX
Los WebSockets no hacen a AJAX obsoleto pero sustituyen a Comet (HTTP Long-polling/HTTP Streaming) como la solucin predilecta para funcionalidad en tiempo real . AJAX todava debe utilizarse para realizar llamadas de servicio web de corta duracin, y si al final vemos una buena captacin en CORS apoyo a los servicios web , que ser an ms til. Los WebSockets deben ser ahora el estndar para ir a la funcionalidad en tiempo real , ya que ofrecen una baja latencia de comunicacin bi -direccional con una nica conexin . Incluso si un navegador no soporta de forma

nativa el objeto WebSocket hay opciones como el polyfill que prcticamente garantizan que cualquier navegador web pueda establecer una conexin WebSocket .

SOAP (Simple Object Access Protocol)

SOAP es un protocolo simple basado en XML para permitir que las aplicaciones de intercambio de informacin a travs de HTTP. O ms simplemente: SOAP es un protocolo para acceder a un servicio Web (webservice)

Qu es SOAP?
SOAP por sus siglas en ingls: Simple Object Access Protocol SOAP es un protocolo de comunicacin SOAP es utilizado para la comunicacin entre aplicaciones SOAP es un formato para el envo de mensajes SOAP se comunica a travs de Internet SOAP es independiente de la plataforma SOAP es independiente del lenguaje SOAP se basa en XML SOAP es sencillo y extensible SOAP puede desplazarse a travs de firewalls

Por qu SOAP?
Es importante para el desarrollo de aplicaciones para permitir la comunicacin por internet entre los programas Las aplicaciones actuales se comunican mediante llamadas a procedimiento remoto (RPC) entre objetos como DCOM y CORBA, pero HTTP no fue diseado para esto. Las RPC representan un problema de seguridad y compatibilidad, los firewalls y servidores proxy normalmente bloquean este tipo de trfico. Una mejor manera de comunicarse entre aplicaciones es a travs de HTTP, porque es compatible con todos los navegadores y servidores de Internet. SOAP fue creado para lograr esto. SOAP proporciona una manera de comunicarse entre las aplicaciones que se ejecutan en sistemas operativos diferentes, con diferentes tecnologas y lenguajes de programacin.

REST (Representational State Transfer)

REST es una arquitectura simple carente de estado que se ejecuta por lo general a travs de HTTP. REST involucra la lectura de pgina Webs designadas que contenga un archivo XML. El archivo XML describe e incluye el contenido deseado. REST se utiliza a menudo en las aplicaciones mviles, sitios web de redes sociales, herramientas de mashup y procesos de negocio automatizados. El estilo de REST hace hincapi en que las interacciones entre los clientes y servicios se ve reforzada por tener un nmero limitado de operaciones (verbos). La Flexibilidad es proporcionada a travs del asignamiento de recursos (nombres)por medio de sus propios indicadores de recursos nicos universales (URI). Debido a que cada verbo tiene un significado especfico (GET, POST, PUT y DELETE), REST evita la ambigedad. Como se describe en la tesis de Roy Fielding, REST es una "arquitectura" que, bsicamente, explota la tecnologa y protocolos de la Web existentes, incluyendo HTTP (Hypertext Transfer Protocol) y XML. REST es ms sencillo de usar que el conocido enfoque de SOAP(Simple Object Access Protocol), el cual requiere escribir o utilizar un programa de servidor suministrado (para servir datos) y un programa cliente (para solicitar datos).

MVC (Modelo Vista Controlador)

Introduccin
El patrn de arquitectura MVC (Modelo Vista Controlador) es un patrn que define la organizacin independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u otro sistema) y el Controlador (controlador del workflow de la aplicacin). De esta forma, dividimos el sistema en tres capas donde, como explicaremos ms adelante, tenemos la encapsulacin de los datos, la interfaz o vista por otro y por ltimo la lgica interna o controlador. El patrn de arquitectura "modelo vista controlador", es una filosofa de diseo de aplicaciones, compuesta por: Modelo Contiene el ncleo de la funcionalidad (dominio) de la aplicacin. Encapsula el estado de la aplicacin. No sabe nada / independiente del Controlador y la Vista.

 Vista Es la presentacin del Modelo. Puede acceder al Modelo pero nunca cambiar su estado. Puede ser notificada cuando hay un cambio de estado en el Modelo. Controlador Reacciona a la peticin del Cliente, ejecutando la accin adecuada y creando el modelo pertinente

Para entender cmo funciona nuestro patrn Modelo vista controlador, se debe entender la divisin a travs del conjunto de estos tres elementos y como estos componentes se comunican unos con los otros y con otras vistas y controladores externos a el modelo principal. Para ello, es importante saber que el controlador interpreta las entradas del usuario (tanto teclado como el ratn), enviado el mensaje de accin al modelo y a la vista para que se proceda con los cambios que se consideren adecuados

Comunicacin
El modelo, la vista y el controlador deben comunicarse de una manera estable los unos con los otros, de manera que sea coherente con las iteraciones que el usuario realizara. Como es lgico la comunicacin entre la vista y el controlador es bastante bsica pues estn diseados para operar juntos, pero los modelos se comunican de una manera diferente, un poco ms sutil

Modelo pasivo
No es necesario para el modelo hacer ninguna tener alguna disposicin a l, simplemente basta con tener en cuenta su existencia. El modelo no tiene ninguna responsabilidad para comunicar los cambios a la vista porque ocurren solo por orden del usuario, por lo que esta funcin la llevara a cabo el controlador porque ser el que interprete las ordenes de este usuario debido a que solo debe comunicar que algo ha cambiado. Por esto, el modelo es se encuentra en modo inconsciente y su participacin en este caso es irrisoria.

Unin del modelo con la vista y el controlador

Como no todos los modelos pueden ser pasivos, necesitamos algo que comunique al controlador y a la vista, por lo que en este caso, si que necesitamos el modelo, ya que solo este puede llevar a cabo los cambios necesarios al estado actual en el que estos se encuentran. Al contrario que el modelo, que puede ser asociado a mltiples asociaciones con otras vistas y controladores, cada vista solo puede ser asociada a un nico controlador , por lo que han de tener una variable de tipo controler que notificara a la vista cual es su controlador o modelo asignado. De igual manera, el controlador tiene una variable llamada View que apunta a la vista. De esta manera, pueden enviarse mensajes directos el uno al otro y al mismo tiempo, a su modelo. Al final, la vista es quien lleva la responsabilidad de establecer la comunicacin entre los elementos de nuestro patrn MVC. Cuando la vista recibe un mensaje que concierne al modelo o al controlador, lo deja registrado como el modelo con el cual se comunicara y apunta con la variable controller al controlador asignado, envindole al mismo su identificacin para que el controlador establezca en su variable view el identificador de la vista y as puedan operar conjuntamente. El responsable de deshacer estas conexiones, seguir siendo la vista, quitndose a si misma como dependiente del modelo y liberando al controlador.

Implementacin del Modelo Vista Controlador: Structs

Para mejorar la reutilizacin, extensibilidad, flexibilidad y el resto de elementos de las aplicaciones, proponemos el uso que puede usar el siguiente patrn de diseo, entendiendo que este es un descriptor de objetos y clases adaptadas para resolver un problema. Una aplicacin basada en Struts, tiene un componente bsico llamado ActionServlet. Este es un servlet, que tramita las peticiones de los clientes delegando a un componente definido por el usuario por cada peticin. Este Servlet es el punto central del framework, aunque no es necesario que toda la actividad fluya a travs de l. En una aplicacin basada en Struts se pueden hacer peticiones a una JSP que contengan o no "tag libraries" de Struts, sin pasar por el Servlet ActionServlet. El ActionServlet (controlador) de Struts captura y encamina las peticiones HTTP que llegan a la aplicacin (toma la decisin de a dnde enviar la peticin HTTP), a otros componentes de aplicacin. Estos componentes pueden ser pginas JSP o instancias de una subclase de la clase

org.apache.struts.action.Actionque el propio framework suministra. Cuando se inicia el Servlet ActionServlet, carga y analiza la informacin de un fichero que contiene la configuracin de la aplicacin para aplicar las caractersticas de Struts. Entre otras cosas, el fichero de configuracin define las correspondencias que existen entre las peticiones HTTP que captura el Servlet controlador y las acciones que van a tratar esa peticin. Estas correspondencias son manipuladas como instancias de la clase org.apache.struts.action.ActionMapping

El navegador lanza una peticin HTTP a la aplicacin, evento que es capturado por el servidor de aplicaciones y encaminado al componente correspondiente del modelo vista controlador para su tratamiento. A la hora de aplicarlo al patrn modelo vista controlador, las funcionalidades y el encapsulamiento, serian los siguientes:

Modelo Representa al estado de la aplicacin. Puede haber dos opciones esencialmente: Struts proporciona una clase base org.apache.struts.action.ActionForm que se debe extender cuando se desea obtener la entrada de datos proporcionada por el usuario en la peticin HTTP. El modelo puede ser un Bean o clase ordinaria sin necesidad extender ActionForm. Vista La vista es una pgina JSP que no debe contener lgica de negocio, ni flujo de la aplicacin e informacin del modelo, slo tags. Utiliza el modelo generado para obtener la informacin y presentarla Controlador El Servlet ActionServlet acta de controlador, recibe la peticin del navegador y decide qu subclase de Action va tratar la peticin en funcin de lo que se ha declarado en el fichero de configuracin struts-config.xml. Subclase de Action. Actualiza el estado del modelo, y, controla el flujo de la aplicacin y tratamiento de errores. Una instancia de una subclase de Action puede tratar la peticin y responder al cliente o indicar al Servlet controlador a qu componente del sistema debe delegar el control (esta es la opcin la que se lleve a cabo). Las instancias de las subclases de Action tienen acceso al contexto del Servlet controlador y dems objetos que actan con el contenedor Web.