2012-10-12 181 views
7

tengo la siguiente configuraciónEl envío de datos a un sitio web de un servicio WCF

  • Un sitio web jQuery (página no exactamente sola, pero no muy lejos de ella), que utiliza un
  • Un ASP.NET MVC sitio web como backend, que se conecta (a través de net.tcp o net.pipe) a
  • Un servicio WCF alojado en el servidor que administra y conecta a
  • Una plétora de servicios externos de alta latencia.

De modo que cuando un cliente presiona un botón, se envía una solicitud al MVC, que lo enruta al WCF, que lo agrega de los servicios externos, y todo está bien y elegante.

El problema que no puedo entender es la comunicación por el otro lado, es decir, cuando uno de los servicios externos se desconecta, ¿cuál es la forma más fácil y elegante de informar al cliente (el navegador)?

Esto significa que el servicio de alguna manera debe informar al sitio de mvc que de alguna manera debe informar al cliente que un servicio externo está fuera de línea.

Además: El servicio externo tendrá alta disponibilidad, por lo que el escenario "se desconecta" rara vez se utilizará, y en consecuencia, estoy buscando una solución que no realice extensas sondeos del servidor.

+0

¿Cómo se define "fuera de línea"? ¿Temporalmente inalcanzable? ¿Apagar para mantenimiento por un administrador en el servicio externo? ¿Es esto estrictamente para hacer frente a interrupciones "planificadas" o está buscando manejar con elegancia cualquier incapacidad para contactar a los servicios remotos? –

+0

@RickLiddle "se apaga" podría ser una mejor palabra aquí. Básicamente, cuando el servicio externo (que está fuera de mi comando) no responde como debería. – SWeko

+0

Recomiendo encarecidamente la sugerencia de SignalR proporcionada por JcFx [a continuación] (http://stackoverflow.com/a/12863194/35241). –

Respuesta

4

Estoy trabajando en una arquitectura similar y estoy planeando usar SignalR para enviar actualizaciones de WCF (a veces directamente, a veces a través del bus de servicio de Azure) a una aplicación jQuery impulsada por una sola página. No he implementado esto todavía, por lo que puede haber algunos problemas que no he considerado.

Desde sus documentos:

avance de los datos desde el servidor al cliente (no sólo los clientes del explorador) siempre ha sido un problema difícil. SignalR hace que sea más fácil y se encarga de todo el trabajo pesado para usted.

de Scott Hansleman tiene un buen blog sobre el tema aquí: http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx

+0

Upvoted: una excelente solución que brinda una respuesta viable al problema e incluye grandes recursos. Esto es, IMO, el modelo de lo que debería ser una respuesta en StackOverflow. –

1

Puede usar fault exceptions para devolver datos de excepción al cliente.

Prefiero tener un indicador IsSuccessful en mis contratos devueltos y solo lanzar excepciones de error cuando hay un error crítico.

Aquí hay un ejemplo muy básico de un contrato de respuesta con una bandera IsSuccessful.

[DataContract] 
public class MyResponse 
{ 
    [DataMember] 
    public bool IsSuccessful { get { return Message == null || !Messages.Any(); } set { } } 
    [DataMember] 
    public List<string> Messages { get; set; } 
} 

Messages puede haber tipos complejos si es necesario para proporcionar información más detallada. Los atributos DataContract y DataMember pueden ser MessageContract y MessageBodyMember si le conviene mejor a su arquitectura.

+0

no es simple Json mucho más fácil? – lboshuizen

+0

Puede que no haya aclarado la pregunta, lo siento. No hay solicitud del cliente, el servidor debe iniciar la comunicación. – SWeko

0

El escenario típico con WCF y un navegador es un patrón de solicitud/respuesta. El navegador realiza una solicitud y el servicio responde.

Puede hacer que el buscador busque periódicamente el estado del servicio.

+0

El servicio externo tendrá alta disponibilidad, por lo que el escenario "se desconecta" rara vez se utilizará, y, en consecuencia, estoy buscando una solución que no realice extensas sondeos del servidor. – SWeko

+0

En ese caso, simplemente devuelve un error cuando el servicio externo está fuera de línea y el navegador realiza una solicitud que lo requiere. –

+0

Ya lo hago, pero ahora debo informar de manera proactiva :) – SWeko

1

Me parece que necesitará implementar algún tipo de servicio de sondeo para hacer ping a estos servicios externos para su disponibilidad.

+0

Eso ya está implementado en el nivel de servicio WCF, y previa solicitud disponible para el cliente. El problema es que ahora tengo que enviarlo al cliente de forma orientada a eventos. – SWeko

+0

¿Cuál es el cliente? ¿Está basado en la web? – mojo722

+0

Sí, lo describí en cuestión. – SWeko

0

En el Discovery Namespace hay una funcionalidad que permite que un servicio WCF envíe mensajes de descubrimiento. Si tiene una interrupción planificada, el AnnouncementClient class tiene métodos para que el servicio publique mensajes sobre cómo desconectarse o conectarse en línea.

Para establecer un mensaje personalizado para sus usuarios, debe escuchar estos mensajes de anuncio. La clase que implementa esto es AnnouncementService. Tiene eventos para manejar los mensajes Offline y Online.

Cuestiones relacionadas