habilitar - como funciona silverlight
Notificaciones de Silverlight y push (8)
Alternativamente,
si quieres una API nativa de Silverlight sin proxies, puentes o servidores web implicados, puedes usar Nirvana de mis canales como tu middleware de mensajería. Echa un vistazo a Nirvana desde my-Channels y su sitio de exhibición. (Lo siento, soy un nuevo usuario y no puedo enviar enlaces):
Alex
Estoy creando una interfaz de usuario Silverlight 2 para un instrumento remoto. Hay dos usuarios concurrentes en diferentes sitios que interactúan con el instrumento (operador en el instrumento y científico remoto) y cualquier número de usuarios observadores que no interactúan con él, simplemente observando. Sin embargo, cada vez que uno de los dos usuarios activos cambia algo, estos cambios deben reflejarse inmediatamente en las IU de todos los usuarios, por ejemplo, al alternar o ampliar una imagen o al anotar o seleccionar parte de una imagen, agregar elementos a una colección mostrada en un cuadro de lista. Dentro del cliente utilizo colecciones observables que reflejan fácilmente los cambios realizados por ese usuario, pero es más difícil ver los cambios realizados por otro usuario. Puedo sondear los cambios de cada cliente, pero algo así como notificaciones push sería mejor. He buscado extensamente en Google ejemplos pero no encontré nada que sea todo lo que necesito. Hay todo tipo de problemas de seguridad con Silverlight que interactúa con los servicios de WCF, lo que significa que muchos ejemplos potenciales simplemente no funcionan. En esencia, me he quedado sin tiempo en este proyecto y necesito ayuda rápidamente. ¿Alguien tiene alguna sugerencia de un ejemplo simple adecuado que ilustra cómo hacer esto? Soy un desarrollador experimentado, pero he tenido que enseñarme a mí mismo los servicios de Silverlight y WCF y no hay nadie en mi área que sepa nada al respecto. Incluso aunque he trabajado bastante en ASP.NET, no soy un gurú de web / Javascript. Gracias.
EDITAR: en realidad está funcionando bien. Me picaron mucho las "variables ocultas" en un cierre :(
Utilicé el PollingDuplex para SL2 y creo que aún no está listo para la producción.
Mi problema principal es el hecho de que no discrimina a los clientes en la misma máquina. Si ejecuto 2 clientes, uno de ellos ya no podrá sondear el servidor y morirá de tiempo de espera. Hay un SessionId que es diferente para los 2 clientes pero solo se ignora en el lado del cliente.
Del mismo modo, si mato a un cliente y luego creo uno nuevo, el nuevo cliente recibirá las actualizaciones de inserción del cliente anterior por un tiempo.
¿Alguien se encontró con los mismos problemas o están resueltos en SL3?
De hecho, ejecuté algunos códigos de demostración más y me di cuenta de que, por alguna razón, debe especificar InstanceContextMode y InstanceMode para que el servicio esté basado en sesiones y no en un singleton (hasta donde yo sé). Hay problemas claros de rendimiento en el código de demostración simple que sacó.
Es bastante desafortunado que este comportamiento no haya sido documentado.
El PollingDuplexHttpBinding es probablemente la forma más elegante de hacerlo.
Una alternativa menos complicada es usar un socket TCP de su cliente de Silverlight. Cada vez que uno de los clientes de Silverlight necesita tener una actualización presionada, puede enviarle un mensaje TCP que contenga el nombre del servicio WCF al que necesita llamar o alguna otra información liviana.
Utilizo este enfoque para una aplicación y funciona bien.
La notificación push es compatible con Silverlight 2 utilizando el nuevo soporte WCF PollingDuplexHttpBinding. Hay dos ensamblados instalados con Silverlight SDK ( uno para la aplicación Silverlight uno para el servidor WCF ).
Tengo algunas publicaciones en el blog y una aplicación de muestra completa que demuestra cómo "impulsar" las actualizaciones de stock desde un servidor de aplicación de consola que aloja un servicio WCF a clientes conectados. También muestra cómo cada cliente puede agregar notas contra una acción y tener esas notas sincronizadas (enviadas desde el servidor) a todos los demás clientes conectados.
La última versión de la muestra (Parte 4) muestra cómo sincronizar las actualizaciones enviadas entre los clientes de Silverlight y WPF utilizando dos puntos finales del servidor de la siguiente manera:
using System;
using System.ServiceModel;
using System.ServiceModel.Description;
namespace StockServer
{
public class StockServiceHost : ServiceHost
{
public StockServiceHost(object singletonInstance, params Uri[] baseAddresses)
: base(singletonInstance, baseAddresses)
{
}
public StockServiceHost(Type serviceType, params Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
}
protected override void InitializeRuntime()
{
this.AddServiceEndpoint(
typeof(IPolicyProvider),
new WebHttpBinding(),
new Uri("http://localhost:10201/")).Behaviors.Add(new WebHttpBehavior());
this.AddServiceEndpoint(
typeof(IStockService),
new PollingDuplexHttpBinding(),
new Uri("http://localhost:10201/SilverlightStockService"));
this.AddServiceEndpoint(
typeof(IStockService),
new WSDualHttpBinding(WSDualHttpSecurityMode.None),
new Uri("http://localhost:10201/WpfStockService"));
base.InitializeRuntime();
}
}
}
Los clientes WPF se conectan al extremo WSDualHttpBinding y los clientes de Silverlight se conectan al punto final PollingDuplexHttpBinding del mismo servicio WCF. La aplicación también muestra cómo manejar los requisitos de la política de acceso del cliente de Silverlight.
Los clientes (Silverlight o WPF) pueden agregar notas a un Stock en su UI y estas notas se propagan de vuelta al servidor para ser enviadas a todos los demás clientes. Esto demuestra la comunicación en cualquier dirección y con optimismo realiza todas las comunicaciones necesarias para su aplicación.
Puede ver una captura de pantalla de la aplicación de demostración que se ejecuta aquí .
Mi organización descubrió que la implementación de inserción de Silverlight 2.0 / WCF era un poco "no lista para el horario de máxima audiencia", al menos para lo que planeábamos usar.
Terminamos yendo con XMPP / Jabber, porque es una bestia más bien formada, y puedes implementarlo bastante fácilmente en Silverlight, simplemente obteniendo algunos recursos de Internet.
Creo que Silverlight 3.0 implementará una implementación push más nueva / mejor formada, según lo que puedo decir de la información disponible públicamente.
No es que empuje a Flex en la moda de los fan boys, pero de hecho este es el tipo de arquitectura que construimos en todas nuestras aplicaciones basadas en Flex de manera rutinaria. Esto es lo que hacemos en Flex: sin dudas, podría traducirse adecuadamente a Silverlight:
Tomamos tres ingredientes e integramos juntos para lograr esta capacidad:
- Patrón de Comet (una forma compatible con HTTP para hacer notificaciones push del servidor - mira en Wikipedia para más información)
- Temas de mensajes JMS (colas de publicación / suscriptor)
- El servlet de Adobe BlazeDS
El último elemento implementa el patrón Comet, admite la clasificación de objetos AMF (formato de serialización binaria de Adobe para objetos ActionScript3) y crea puentes a una cola o tema JMS. Al crear un puente sobre un tema, múltiples clientes Flex que se ejecutan en un navegador pueden ser proxies como suscriptores de un tema JMS. Entonces, si algún cliente publica un mensaje (o el código del lado del servidor lo publica en el tema), todos los suscriptores del cliente recibirán el mensaje a través de BlazeDS y la implementación del Comet Pattern.
De hecho, necesita ubicar o escribir un componente que logre lo que hace BlazeDS. Es posible que también necesite implementar algún código de cliente que interactúe con el patrón Comet de este componente del servidor.
¿WCF es compatible con el Comet Pattern y la mensajería bidireccional? Especialmente cuando cumple con HTTP y el puerto 80 o el puerto 443 para SSL. Parece que ya lo investigó y no encontró nada para la mensajería bidireccional. Por lo tanto, es posible que deba subirse las mangas y hacer algo de codificación.
Algunas cosas que debe tener en cuenta acerca de hacer push de servidor a una aplicación web:
BlazeDS admite dos modos principales de implementar el patrón Comet (en realidad hay una tercera opción de votación, pero la ignoro):
- sondeo largo
- Transmisión HTTP
La encuesta larga que debería encontrar es más compatible universalmente para la mayoría de los navegadores web. Por lo tanto, es posible que optimice para solo apoyar eso inicialmente. O bien, podría dedicar un tiempo a que el código de su cliente pruebe la transmisión HTTP primero y cambiar a una encuesta larga si es necesario.
En cuanto a un intermediario de mensajes que puede proporcionar capacidad de publicación / suscripción, puede considerar utilizar ActiveMQ JMS. Es de código abierto y gratuito con soporte activo de la comunidad (también puedes comprar soporte). Además, puede usar NMS para integrarse como un cliente .NET.
Tener un intermediario de mensajes sentado en el nivel intermedio es realmente importante porque será un lugar para que los mensajes se coloquen de manera segura. Si sus clientes realizan encuestas largas, no querrá que pierdan ningún mensaje nuevo durante un intervalo en el que no estén realmente conectados.
Otra cosa a tener en cuenta en los escenarios de alto volumen de tráfico (cientos o miles de clientes, como un sitio web en Internet), es necesario tener un enfoque para el Comet Pattern que sea escalable.
En el mundo Flex / Java, el servlet BlazeDS (que es de código abierto) se ha modificado para funcionar con el modelo asincrónico. En Java, se puede construir un detector de socket para usar los canales de NIO y los grupos de subprocesos de Java Concurrency Executor. El servidor web Tomcat tiene un detector de NIO y soporte para eventos asíncronos de Servlet 3.0. Sin embargo, BlazeDS en particular se ha modificado para funcionar con el servidor web Jetty. La conclusión es que la escalabilidad de este enfoque asíncrono significa que se puede mejorar un solo servidor web físico para admitir hasta 20,000 conexiones concurrentes de estilo Comet.
Ha pasado un tiempo desde que hice una programación .NET seria pero las capacidades de io se parecían mucho a Java 1.1 excepto con una capacidad de controlador de resultados asíncrono. Sin embargo, esto no es lo mismo que crear oyentes de socket asincrónicos a través de los canales de Java NIO. Una implementación de canal NIO puede admitir cientos o miles de conexiones de socket con un grupo de subprocesos relativamente pequeño. Pero C # y .NET han tenido dos o tres revoluciones significativas; quizás se hayan agregado nuevas capacidades io que sean comparables a los canales NIO.
Solo quería aclarar que PollingDuplexHttpBinding no implementa notificaciones push ''verdaderas'', ya que revela su nombre (sondeo). De la documentación de msdn :
Cuando se configura con este enlace, el cliente de Silverlight sondea periódicamente el servicio en la capa de red y verifica si hay nuevos mensajes que el servicio desea enviar en el canal de devolución de llamada. El servicio pone en cola todos los mensajes enviados en el canal de devolución de llamada del cliente y los entrega al cliente cuando el cliente sondea el servicio.
Sin embargo, es más eficiente que la forma tradicional de sondear un servicio web, ya que después de cada encuesta, el servidor mantendrá el canal abierto durante un cierto tiempo (digamos 1 minuto), y si llega un mensaje en ese momento, directamente ''empujará ''el mensaje para el cliente. El cliente debe renovar su conexión repetidamente, es decir, sondear el servicio.
Si desea implementar notificaciones push reales con Silverlight, creo que necesita trabajar con sockets, y recomiendo leer algunas de las publicaciones de blog de Dan Wahlin sobre el tema.
Una solución mucho más simple y poderosa en el sitio http://www.udaparts.com/document/Tutorial/slpush.htm