Académique Documents
Professionnel Documents
Culture Documents
Net
SignalR 2.0
Jos Mara Aguilar Esteban
CREATIVIDAD
Diseo cubierta: Pablo Iglesias Francisco y Natalia Matesanz Urea
Fruta cubierta: El pltano tiene su origen en Asia meridional, siendo conocido en el
Mediterrneo desde el ao 650 d.C. La especie lleg a Canarias en el siglo XV y desde all fue
llevado a Amrica en el ao 1516. El cultivo comercial se inicia en Canarias a finales del siglo
XIX y principios del siglo XX. En lo que respecta a sus propiedades nutritivas, destaca su
contenido de hidratos de carbono, por lo que su valor calrico es elevado. Los nutrientes ms
representativos del pltano son el potasio, el magnesio, el cido flico y sustancias de accin
astringente; sin despreciar su elevado aporte de fibra, del tipo fruto-oligosacridos.
Agradecimientos
Aunque suene algo manido, un libro como este no sera posible sin la colaboracin de
muchas personas que han dedicado su tiempo y esfuerzo a hacerlo realidad, y es justo
dedicarles unas palabras de agradecimiento.
En particular, me gustara agradecer su implicacin a mi editor en CampusMVP.es,
Jos Manuel Alarcn (@jm_alarcon), por su habilidad en la gestin del proyecto,
coordinacin, revisiones y sabias recomendaciones que nos han conducido hasta este
punto.
Tambin ha resultado imprescindible la colaboracin de Javier Surez Ruz
(@jsuarezruiz) por sus aportaciones y ejemplos de implementacin de clientes SignalR
en entornos no web como Windows Phone o WinRT.
Por parte de Microsoft, debo agradecer a Devon Musgrave su inters en este proyecto
desde el primer momento, sin el cual el libro nunca hubiese visto la luz.
Contenido
AGRADECIMIENTOS ................................................................................................ V
CONTENIDO............................................................................................................ VII
vii
viii
Contenido ix
Contenido xi
Presentacin
SignalR, la ltima incorporacin al stack de tecnologas de desarrollo para la web de
Microsoft, es un marco de trabajo que facilita la creacin de asombrosas aplicaciones
en tiempo real, como pueden ser herramientas de colaboracin online, juegos
multiusuario, o servicios de informacin en vivo, cuyo desarrollo ha sido
tradicionalmente bastante complejo.
Este libro proporciona un recorrido completo sobre desarrollo con SignalR
partiendo desde cero, aunque tambin se tratarn temas relativamente avanzados. La
idea es que al finalizar su lectura el lector conozca las posibilidades de este marco de
trabajo y sea capaz de aplicarlo con xito en la creacin de sistemas realtime de
cualquier tamao. Tambin puede ser utilizado como manual de referencia pues,
aunque no de forma exhaustiva, en l se recoge la mayora de caractersticas de
aplicacin prctica durante el desarrollo de sistemas con SignalR, y se proporcionan las
bases para dominarlos en su totalidad.
necesario conocer los protocolos sobre los que se sustenta, as como tener un cierto
conocimiento de los lenguajes bsicos de estos entornos como HTML y, en particular,
JavaScript.
Aunque no es estrictamente necesario, s sera interesante disponer de algunos
conocimientos sobre desarrollo con jQuery, Windows Phone 8 o WinRT para los
captulos donde se desarrollan ejemplos y contenidos relativos a ellos, y tcnicas tales
como unit testing (pruebas unitarias), mocking o inyeccin de dependencias para los
contenidos finales.
Presentacin xv
Presentacin xvii
En el interior de cada una de estas carpetas se encuentra a su vez una subcarpeta por
cada proyecto de ejemplo incluido, numeradas siguiendo el orden en el que los
conceptos son tratados a lo largo del texto del libro:
Captulo 08 Escalado
o 1-AzureServiceBus
o 2-SqlServer
o
<script src=/scripts/jquery.signalR-2.0.0.min.js></script>
una vez instalada la versin 2.0.1 de SignalR, el cdigo debera cambiarse por:
<script src=/scripts/jquery.signalR-2.0.1.min.js></script>
CAPTULO
Introduccin
Introduccin 21
tiempo real, algunos de los cuales ya hemos adelantado en los prrafos anteriores.
Veremos rpidamente el funcionamiento de HTTP y las limitaciones que presenta para
soportar este tipo de sistemas, e introduciremos el concepto PUSH. Tambin
describiremos los estndares que estn siendo definidos por parte de W3C e IETF y
tcnicas que podemos usar en la actualidad para implementar Push sobre HTTP. Esto
nos permitir lograr un conocimiento profundo del escenario en el que nos
encontramos, y la problemtica existente en torno al desarrollo de aplicaciones que
hagan gala de esa inmediatez e interactividad a las que hemos hecho referencia. Esto,
adems, nos ser de mucha utilidad para comprender mejor cmo funciona SignalR y
las bases sobre las cuales se sustenta.
A continuacin introduciremos formalmente SignalR describiendo sus principales
caractersticas, su posicin en la pila de tecnologas de desarrollo para Internet de
Microsoft, y los distintos niveles de abstraccin que ofrece sobre los protocolos
subyacentes y que nos ayudarn a aislarnos de detalles de bajo nivel y a centrarnos en,
simplemente, crear funcionalidades espectaculares para nuestros usuarios.
Aprovecharemos la ocasin para hablar tambin de OWIN y Katana, dos nuevos
actores que estn tomando protagonismo en distintas tecnologas, entre ellas SignalR.
Estudiaremos muy en profundidad las distintas tcnicas y abstracciones que ofrece
este marco de trabajo para la creacin de aplicaciones interactivas multiusuario en
tiempo real, tanto desde el lado cliente como servidor, y aprenderemos a aprovechar su
potencia y flexibilidad. Para ello, por supuesto, nos apoyaremos en ejemplos de cdigo
que nos ayudarn a entender sus bases de forma prctica, y as ver cmo podemos
utilizar este framework en proyectos reales.
Tambin trataremos la independencia de SignalR respecto a los entornos web,
porque, aunque pueda parecer su entorno natural, este framework va bastante ms all
y permite la prestacin de servicios real-time desde cualquier tipo de aplicacin, y, de
la misma forma, su consumo desde, prcticamente, cualquier tipo de sistema. Veremos
varios ejemplos prcticos de ello.
Otro aspecto de gran importancia, al que dedicaremos un buen nmero de pginas,
es a revisar el despliegue y la capacidad de escalado de aplicaciones SignalR.
Estudiaremos las herramientas que acompaan de serie a esta plataforma, y
plantearemos otras posibles soluciones para cuando estemos ante algn escenario en
los que estas soluciones se nos quedan pequeas. Veremos tambin distintas tcnicas
destinadas a monitorizar el estado de nuestros servidores y a mejorar su rendimiento en
entornos de alta concurrencia.
Y ya por ltimo entraremos en aspectos avanzados de programacin con SignalR,
que permitirn tener una visin ms profunda del funcionamiento del framework, como
los aspectos de seguridad, la creacin de componentes desacoplados usando inyeccin
de dependencias, extensibilidad de SignalR, realizacin de pruebas unitarias y otros
aspectos de inters.
Bienvenido a las aplicaciones multiusuario, asncronas y en tiempo real.
Bienvenido a SignalR!
CAPTULO
HTTP: El cliente es el
que manda
Sin embargo, esto tiene un precio a veces excesivo. Las frecuentes conexiones y
desconexiones tienen un coste alto en trminos de ancho de banda y proceso en ambos
extremos de la comunicacin, y lo peor es que este coste aumenta de forma
proporcional a las necesidades de inmediatez en las actualizaciones y al nmero de
clientes que se encuentren, en un momento dato, utilizando el servicio. Es fcil
imaginar la carga que debe soportar un servidor con miles de usuarios conectados
solicitndole actualizaciones varias veces por segundo en una aplicacin que ofrezca
actualizaciones en tiempo real.
Existen tcnicas que mitigan en la medida de lo posible estos problemas. Una de
ellas es utilizar periodicidad adaptativa, de forma que el intervalo entre las consultas
vaya adaptndose a la carga actual del sistema o a las probabilidades de que se
produzcan actualizaciones. Es bastante sencilla de implementar y puede mejorar
considerablemente el consumo de recursos en determinados escenarios.
Otra variante del Polling bastante ms conservadora, aunque deriva en una
experiencia de usuario mucho ms pobre, es la tcnica denominada piggy backing,
consistente en no realizar consultas expresas desde el cliente, sino aprovechar cualquier
interaccin de ste con el sistema para actualizarle la informacin que necesite. Por
ejemplo, en un servicio de correo va web, en lugar de realizar una consulta peridica
para comprobar la llegada de nuevos mensajes, esto se comprobara cada vez que el
usuario accediera a una pgina, un mail o cualquier otra funcionalidad. Puede ser
interesante en escenarios en los que no se requiere mucha inmediatez y donde, por las
propias caractersticas del sistema, estemos totalmente seguros de que el usuario
interactuar con la aplicacin frecuentemente.
Por supuesto, estas variantes pueden ser combinadas entre s para lograr un uso ms
eficiente de los recursos y, al mismo tiempo, ofrecer una experiencia de uso razonable.
Por ejemplo, sera posible actualizar el estado de un cliente mediante piggy backing
cuando ste interacta con el servidor y, cuando esta interaccin no se produce, usar
Polling con o sin periodicidad adaptativa para obtener las actualizaciones.
En definitiva, a pesar de sus inconvenientes, Polling es una opcin razonable
cuando buscamos una solucin sencilla de implementar, utilizable de forma universal,
y en escenarios donde no se requiere una gran frecuencia de actualizacin.
Y de hecho, es muy utilizada en sistemas actuales. Un ejemplo real de aplicacin lo
encontramos en la versin web de Twitter, donde se utiliza Polling para actualizar el
timeline cada treinta segundos.
En ellas necesitamos que sea el servidor el que tome la iniciativa, siendo capaz
de enviar informacin al cliente justo cuando se produzca un evento del que debe ser
informado, y no esperar a que el cliente la solicite.
Y precisamente esta es la idea que est por detrs del concepto Push o Server
Push. Esta denominacin no hace referencia a un componente, tecnologa o protocolo:
se trata de un concepto, un modelo de comunicacin entre cliente y servidor donde ste
ltimo es el que toma la iniciativa en la comunicacin.
Tampoco se trata de algo novedoso. Hay protocolos conceptualmente Push como
IRC, el protocolo que rige el funcionamiento de los clsicos servicios de chat, o SMTP,
el encargado de coordinar los envos de correos electrnicos, que fueron creados antes
de acuarse el trmino para identificar este tipo de comunicacin.
Para conseguir que el servidor pueda notificar eventos en tiempo real a una serie de
clientes interesados en recibirlos, lo ideal sera poder iniciar desde aqul una conexin
directa punto a punto con ellos. Por ejemplo, un servidor de chat podra mantener una
lista con las direcciones IP de los clientes conectados, y abrir una conexin de tipo
socket hacia cada uno de ellos para notificarles la llegada de un nuevo mensaje.
Sin embargo, tcnicamente no es posible. Por razones de seguridad, normalmente
resulta imposible realizar una conexin directa a un equipo cliente debido a la
existencia de mltiples niveles intermedios que la rechazaran, como firewalls, routers
o proxies. Por esta razn la prctica habitual es que sea el cliente el que inicia la
conexin y no al contrario.
Para evitar este inconveniente y poder lograr un efecto parecido, hace tiempo
surgieron tcnicas basadas en elementos activos incrustados en las pginas web
(applets Java, Flash, aplicaciones Silverlight). Estos componentes utilizaban
normalmente sockets para abrir una conexin persistente con el servidor, es decir, una
conexin que permaneca abierta todo el tiempo que el cliente estuviera conectado al
servicio, mantenindose a la escucha por si el servidor tena algo que comunicar. Desde
el lado servidor, cuando se produca un evento de inters para el cliente conectado,
utilizaba ese canal abierto para notificar en tiempo real las novedades.
Este enfoque, aunque ha sido utilizado en multitud de soluciones Push, tiende a
desaparecer. Los componentes activos incrustados en las pginas estn siendo
eliminados de la web a velocidad vertiginosa y sustituidos por alternativas ms
modernas, fiables y universales como HTML5. Asimismo, el uso de conexiones
persistentes de larga duracin basadas en sockets puros son problemticas cuando
existen elementos intermediarios (firewalls, proxies) que pueden impedir estas
comunicaciones, o cerrar las conexiones tras detectar un periodo de inactividad, y
tambin podan suponer riesgos de seguridad para los servidores.
Dada la necesidad de soluciones fiables que dieran cobertura a este tipo de
escenarios, tanto W3C como IETF, los principales organismos que proponen y definen
los protocolos, lenguajes y estndares para internet, se pusieron a trabajar en dos
estndares que permitieran una comunicacin ms directa y fluida desde el servidor
hacia el cliente, conocidos como WebSockets y Server-Sent Events, ambos englobados
bajo el paraguas del nombre comercial HTML5.
3.1.- WebSockets
El estndar WebSockets consiste en una API de desarrollo, que est siendo definida por
la W3C (World Wide Web Consortium, http://www.w3.org), y un protocolo de
comunicaciones, en el que est trabajando el IETF (Internet Engineering Task Force,
http://www.ietf.org).
Bsicamente, permite establecer una conexin persistente que iniciar el cliente
cuando sea necesario y permanecer abierta de forma continua. Sobre esta conexin se
crea un canal bidireccional entre cliente y servidor donde cualquiera de ellos puede
enviar informacin al otro extremo en cualquier momento.
Aunque en la actualidad las especificaciones tanto del API como del protocolo se
encuentran bastante avanzadas, todava no podemos considerar que la aplicacin de
esta tecnologa sea universal.
Podemos encontrar implementacin de WebSockets en muchos de los navegadores
actuales como IE10/11, Chrome y Firefox, en otros slo encontramos
implementaciones parciales (Opera mini, navegador Android), y en otros simplemente
no est disponible3.
Adems del problema de los distintos niveles de implementacin que encontramos
en el lado cliente, el hecho de que el estndar incluya un protocolo de comunicaciones
independiente, aunque negociado inicialmente sobre HTTP, implica que tambin deben
realizarse cambios en determinados elementos infraestructurales e incluso servidores
para que sean aceptadas las conexiones que utilicen WebSockets.
Por ejemplo, no ha sido posible utilizar fcilmente WebSockets sobre tecnologas
Microsoft hasta la ltima oleada de novedades (Internet Explorer 10, ASP.NET 4.5,
WCF, IIS8), donde ya ha comenzado a soportarse de forma nativa.
Desde el punto de vista del desarrollador, WebSockets ofrece un API JavaScript
realmente sencillo e intuitivo para iniciar conexiones, enviar mensajes, y cerrar la
Fuente: http://caniuse.com/websockets
conexin cuando ya no sea necesaria, as como eventos para capturar los mensajes
recibidos:
var ws = new WebSocket("ws://localhost:9998/echo");
ws.onopen = function() {
// Web Socket is connected, send data using send()
ws.send("Message to send");
alert("Message is sent...");
};
ws.onmessage = function(evt) {
var received_msg = evt.data;
alert("Message is received...");
};
ws.onclose = function () {
// WebSocket is closed.
alert("Connection is closed...");
};
Esta conexin es utilizada exclusivamente para recibir datos del servidor, por lo que
si el cliente necesita enviar informacin en sentido ascendente abrir una conexin
HTTP paralela exclusivamente para ello.
respuesta HTTP, cada mensaje tendra que esperar mientras el servidor recibe el
mensaje previo de dicha secuencia, lo procesa, y vuelve a abrir el canal para atender
una nueva peticin.
Seguro que podramos citar bastantes ms, pero estos ejemplos ya son suficientes
como para ofrecer una idea de la complejidad que supone desarrollar aplicaciones de
este tipo.
Y es aqu donde SignalR entra en escena
www.krasispress.com