¿Puede un servicio web devolver una transmisión?

Sí, es posible con Metro. Vea el ejemplo Archivos adjuntos grandes, que parece que hace lo que desea.

JAX-WS RI proporciona soporte para enviar y recibir archivos adjuntos de gran tamaño en streaming.

• Utilice MTOM y DataHandler en el modelo de programación.
• Envía el DataHandler a StreamingDataHandler y usa sus métodos.
• Asegúrese de llamar a StreamingDataHandler.cerrar () y también cerrar el StreamingDataHandler.readOnce() flujo.
• Habilita el chunking HTTP en el lado del cliente.

Cuando se utiliza un servicio web estandarizado, el remitente y el receptor confían en la integridad de los datos XML enviados de uno a otro. Esto significa que una solicitud de servicio web y una respuesta solo se completan cuando se envió la última etiqueta. Teniendo esto en cuenta, un servicio web no puede ser tratado como una transmisión.

Esto es lógico porque los servicios web estandarizados dependen del protocolo http. Que uno es "sin estado", dirá que funciona como " conexión abierta ... enviar solicitud ... recibir datos ... close request"(en inglés). La conexión se cerrará al final, de todos modos. Así que algo como streaming no está destinado a ser utilizado aquí. O capas por encima de http (como los servicios web).

Lo siento, pero por lo que puedo ver no hay posibilidad de streaming en los servicios web. Peor aún: dependiendo de la implementación / configuración de un servicio web, los bytes[] - data pueden ser traducidos a Base64 y no a la etiqueta CDATA y la solicitud puede ser aún más hinchada.

P.d.: Sí, como otros escribieron, "chuinking" es posible. Pero esto no es streaming como tal; -) - de todos modos, puede ayudarle.

Odio decirselo a aquellos de ustedes que piensan que un servicio web de streaming no es posible, pero en realidad, todas las solicitudes http se basan en stream. Cada navegador que hace un LLEGAR a un sitio web se basa en flujo. Cada llamada a un servicio web está basada en stream. Sí, todos. No nos damos cuenta de esto en el nivel donde estamos implementando servicios o páginas porque los niveles más bajos de la arquitectura se ocupan de esto para usted, pero se está haciendo.

¿Alguna vez has notado en un navegador que a veces se puede tomar un tiempo para obtener una página-el navegador solo mantiene arranque de distancia mostrando el reloj de arena? Esto se debe a que el navegador está esperando en una transmisión.

Los flujos son la razón por la que los tipos/mime deben enviarse antes que los datos reales: todo es solo un flujo de bytes al navegador, no podría identificar una foto si no le dijera lo que fue primero. También es por eso que tienes que pasar el tamaño de un binario antes de enviar-el navegador no será capaz de decir dónde se detiene la imagen y la página recoge de nuevo.

Todo es solo un flujo de bytes para el cliente. Si quieres probar esto por ti mismo, simplemente consigue un control del flujo de salida en cualquier punto del procesamiento de una solicitud y ciérralo (). Volarás todo. El navegador dejará de mostrar inmediatamente el reloj de arena, y mostrará un "no se puede encontrar" o "restablecimiento de conexión en el servidor" o algún otro mensaje similar.

Que mucha gente no sepa que todo esto está basado en stream muestra cuánto las cosas han sido superpuestas. Algunos dirían demasiadas cosas-yo soy uno de esos.

Buena suerte y feliz desarrollo relajar los hombros!

Para WCF creo que es posible definir un miembro en un mensaje como flujo y establecer el enlace apropiadamente - He visto este trabajo con wcf hablando con Java web service.

Necesita establecer TransferMode="StreamedResponse" en la configuración httpTransport y usar mtomMessageEncoding (necesita usar una sección de enlace personalizada en la configuración).

Creo que una limitación es que solo puede tener un solo miembro del cuerpo del mensaje si desea transmitir (lo que tiene sentido).

Apache CXF soporta el envío y recepción de flujos.

Una forma de hacerlo es agregar un método uploadFileChunk(byte[] chunkData, int size, int offset, int totalSize) (o algo así) que carga partes del archivo y los servidores lo escriben en el disco.

Tenga en cuenta que una solicitud de servicio web básicamente se reduce a una sola publicación HTTP.

Si nos fijamos en la salida de a .Archivo ASMX en. NET, le muestra exactamente cómo se verá la solicitud y la respuesta POST.

Chunking, como se menciona por @Guvante, va a ser lo más parecido a lo que quieres.

Supongo que podría implementar su propio código de cliente web para manejar el TCP / IP y transmitir cosas en su aplicación, pero eso sería complejo decir que el menos.

Creo que usar un simple servlet para esta tarea sería un enfoque mucho más fácil, o hay alguna razón por la que no puede usar un servlet?

Por ejemplo, podría usar la biblioteca de código abierto Commons.

La biblioteca RMIIO para Java proporciona un RemoteInputStream a través de RMI - solo necesitábamos RMI, aunque debería ser capaz de adaptar el código para que funcione sobre otros tipos de RMI . Esto puede ser de ayuda para usted, especialmente si puede tener una pequeña aplicación en el lado del usuario. La biblioteca se desarrolló con el propósito expreso de poder limitar el tamaño de los datos enviados al servidor para evitar exactamente el tipo de situación que describe, efectivamente un ataque DOS al llenar subir ram o disco.

Con la biblioteca RMIIO, el lado del servidor decide cuántos datos está dispuesto a extraer, donde con HTTP PUT y POSTs, el cliente toma esa decisión, incluida la velocidad a la que envía.

Sí, un servicio web puede hacer streaming. Creé un servicio web utilizando Apache Axis2 y MTOM para soportar la representación de documentos PDF desde XML. Dado que los archivos resultantes podían ser bastante grandes, la transmisión era importante porque no queríamos mantenerlo todo en memoria. Eche un vistazo a la documentación de Oracle sobre transmisión de archivos adjuntos SOAP.

Alternativamente, puede hacerlo usted mismo, y tomcat creará los encabezados fragmentados. Este es un ejemplo de una función de controlador de resorte que flujo.

 @RequestMapping(value = "/stream")
        public void hellostreamer(HttpServletRequest request, HttpServletResponse response) throws CopyStreamException, IOException  
{

            response.setContentType("text/xml");
            OutputStreamWriter writer = new OutputStreamWriter (response.getOutputStream());
            writer.write("this is streaming");
            writer.close();

    }

En realidad no es tan difícil "manejar el TCP/IP y transmitir cosas en su aplicación". Prueba esto...

class MyServlet extends HttpServlet
{
    public void doGet(HttpServletRequest request, HttpServletResponse response)
    {
        response.getOutputStream().println("Hello World!");
    }
}

Y eso es todo lo que hay. En el código anterior, respondió a una solicitud HTTP GET enviada desde un navegador, y devolvió a ese navegador el texto "Hello World!".

Tenga en cuenta que "Hello World!"no es HTML válido, por lo que puede terminar con un error en el navegador, pero eso es todo lo que hay.

Buena suerte en tu desarrollo!

Rodney