none
WCF, eficiencia y su filosofía. (c#) RRS feed

  • Pregunta

  • WCF, eficiencia y su filosofía. (c#)

    Hola, espero no dispersarme mucho al explicar mi duda/lo que quiero hacer y la relación con WCF.

    Sé que WCF se orienta mucho a las aplicaciones de servicios, imagino que siendo utilizado más habitualmente que nada en web services, ahora, ¿para qué lo quiero utilizar yo?

    Mi idea es utilizarlo al estilo sockets para la comunicación entre aplicaciones, especialmente pasando objetos.

    ¿Qué ventaja le veo? Pues todo el tema de los [ServiceContract],     [OperationContract] y   [DataContract], básicamente cada [OperationContract] enviara o recibirá un [DataContract], con lo que me ahorro todo el tema de serialización, o de “transformaciones” (supongo que internamente también te serializa objetos complejos con listas y referencias cíclicas)

     

    Básicamente, a nivel de sockets, sería tener establecidas las tramas con sus cabeceras y diferentes bodys.

     

    Ahora, ¿cómo querría enviar y recibir todas estas comunicaciones normalmente? Mediante conexión TCP (y obviamente enviando en binario, y cuando digo binario me refiero que si un atributo de un objeto que voy a mandar es un int “845” lo envié como un único binario de 4 bytes, no como 3 binarios que cada uno corresponde a un char).

    ¿Por qué TCP? En principio por la eficiencia, aunque claro, luego me pongo a leer la documentación oficial y veo cosas del estilo NetHttpBinding (con sus WebSockets) con los que en teoría envías en binario, luego cosas como NetTcpBinding , aunque ya solo vale para .NET y demás cosas http://msdn.microsoft.com/es-es/library/ms730879.aspx y cada vez me va liando más y no viendo las diferencias entre uno y otro.

    Con lo que, al final, no me queda claro si estoy eligiendo bien WCF (intento usar siempre las cosas más estándar que se pueden, y WCF lo parece) teniendo en cuenta que no quiero usar SOAP con sus XML y el envió de información en UTF-8 (aunque los WSD para que cada extremo sabe lo que le llegaría sí que me gustaría).

    Por poner un ejemplo, imaginemos que quiero enviar lo que sería un objeto compuesto de unos cuantos datos primitivos y por ejemplo 10 imágenes de tamaño diferente. Por sockets, crearía una  la trama con la cabecera y el cuerpo donde iría el resto y lo enviaría en un chorro de bytes, pero con WCF me saltaría toda esa parte… pero claro, está el tema de la eficiencia, el por donde lo envía, que las opciones de     maxBufferPoolSize="524288" maxReceivedMessageSize="24288" igual me lo hacen caer porque el tamaño es demasiado (¿No puede cortar el mensaje y enviarlo por trozos automaticamente?), etc.

    En fin, que no sé si voy por el buen camino y/o me ajusto a su filosifa de uso, así pues; si alguien tiene algún comentario que hacer se lo agradezco.

    jueves, 16 de mayo de 2013 9:31

Respuestas

  • Opiniones:

    a) Si usas el NetTcpBinding, efectivamente toda la comunicación se realiza en binario, de forma compacta. Y efectivamente, sólo es compatible con .Net, pero es que si envías los datos en binario a un socket pasa lo mismo: sólo es compatible con un programa que hayas escrito tú mismo y que entienda el mismo formato binario que has establecido como norma "propietaria" para tu programa.

    b) Para enviar datos grandes, como por ejemplo fotografías de gran tamaño: Con WCF puedes usar la funcionalidad de Streaming, donde el programa de origen va escribiendo en un Stream y el de destino va leyendo de otro Stream. Los datos fluyen "poco a poco" de un programa al otro, sin que tengan que cargarse completos en memoria en ningún momento. No es transparente; tienes que habilitar expresamente esta opción y manejar los Streams en tu programa, pero es lo mejor que hay para enviar informaciones de gran tamaño sin tenerlas que cargar en memoria o construir paquetes de datos muy grandes.

    jueves, 16 de mayo de 2013 9:49