2012-10-08 29 views
12

Necesito ayuda para encontrar lo que estoy buscando. Básicamente, necesito un servicio en el que Server vuelca un montón de XML en una secuencia (durante un período de tiempo) y cada vez que ocurre el volcado N número de clientes lee el volcado.WCF REST Push Stream Service

Ejemplo: Cada vez que una de las acciones a 1000 sube por 5 centavos, el servicio de vertederos alguna XML en un arroyo. Las aplicaciones de conexión toman la información de la transmisión.

No creo que la conexión se cierre alguna vez, ya que tiene que haber algo que lea la secuencia para nuevos datos.

Esto debe cumplir con los estándares de WCF REST, ¿hay algo por ahí que estoy buscando?
Al final, es solo una secuencia continua de datos.

Actualización: Parece que el servicio debe ser un tipo de contenido mixto o de varias partes.

+0

¿Usted está buscando algo así como la API de streaming de Twitter. https://stream.twitter.com/1/statuses/sample.json –

+0

Sí, es lo que estoy buscando.Pero desde un punto de vista WCF/REST. – Dave

Respuesta

6

Una aplicación en la que estoy trabajando tiene una arquitectura similar, y estoy planeando usar SignalR para enviar actualizaciones a los clientes, usando técnicas de larga duración. No lo he implementado todavía, así que no puedo jurar que funcionará para usted, pero su documentación parece prometedora: Actualización: Lo he implementado ahora, y funciona muy bien.

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 a good blog sobre el tema y hay un artículo útil (que implica WCF, descanso y SignalR) aquí: http://www.codeproject.com/Articles/324841/EventBroker

3

En lugar de usar WCF, ¿has mirado en ASP.NET MVC WebAPI?

Para obtener más información sobre el uso de PushStreamContent en WebAPI, Henrik tiene un buen blog con el ejemplo (bajo el encabezado 'Contenido push').

2

¿Has considerado archived Atom feeds? Son 100% RESTful (hypermedia controls and all) y lo más importante, son muy escalables.

Específicamente, los documentos de archivo nunca cambian, por lo que puede establecer un caché de caducidad de 1 año o más. El documento de suscripción es donde van todos los eventos más recientes y cambia constantemente, pero con los encabezados de almacenamiento en caché HTTP adecuados, puede hacer que devuelva 304 Not Modified si nada ha cambiado entre cada solicitud del cliente. Además, si su servicio tiene una resolución de tiempo natural, puede configurar el max-age para aprovecharlo. Por ejemplo, si los datos tiene una resolución de 20 minutos, se podría incluir el siguiente encabezado en la respuesta documento suscrito:

Cache-Control: max-age=1200 

esa manera se puede dejar que las memorias caché hace la mayor parte del trabajo agitado y los clientes puede sondear la suscripción documente con la frecuencia que desee, sin llevar su servicio a sus rodillas.