La serialización es algo bastante aburrido y que, además, en muchas aplicaciones no tiene demasiada importancia. Es algo que damos por hecho, en todo lenguaje que se precie tendremos al menos una forma de serializar información para poder almacenarla o transmitirla.
En .NET existen varias formas de serializar desde las primeras versiones del framework. Seguramente las más conocidas sea la serialización a XML con XmlSerializer o su primo el DataContractSerializer y la serialización binaria con BinaryFormatter. También existen otras alternativas más modernas como el DataContractJsonSerializer.
Sin embargo, hay veces en que no nos queda más remedio que preocuparnos por la serialización. Normalmente, por uno de estos dos motivos:
- Necesitamos que la operación de serializar/deserializar sea más rápida.
- Necesitamos reducir el tamaño de los datos serializados.
Donde se dan estos requerimientos con mayor frecuencia es en el caso de aplicaciones móviles basadas en .NET Compact Framework.
Por una parte, se ejecutan sobre dispositivos menos potentes por lo que la velocidad de ejecución es menor. Si a eso le unimos que el Compact Framework no permite usar generación de código (ni Reflection.Emit ni CodeDOM), toda la serialización/deserialización se hace por reflection, lo que implica aún una mayor penalización en el rendimiento.
Además, los dispositivos móviles suelen tener menos capacidad de almacenamiento, menos memoria y conexiones con menos ancho de banda, por lo que el tamaño de los datos serializados, ya sea para almacenarlos en memoria flash o para trasmitirlos por la red, importa y mucho.
De hecho, hay ocasiones en que estas limitaciones hacen inviables soluciones propias de otros entornos, como el uso de servicios web (SOAP) o WCF para comunicaciones en tiempo real entre dispositivos con Compact Framework y servidores.
En situaciones como esa, mejorar la capa de serialización puede ser vital. Si unimos una mejora en el rendimiento al serializar/deserializar, con un menor volumen de datos a transmitir, la ganancia final de velocidad puede ser la diferencia entre que la aplicación sea viable o no.
Para estos casos, el mejor protocolo de serialización que se puede encontrar hoy en día es Protocol Buffers, desarrollado por Google y que cuenta con varias implementaciones para .NET.
En el próximo post veremos cómo funciona este protocolo y cómo podemos usarlo fácilmente en nuestras aplicaciones.
Pingback: Serialización ultra-rápida con Protobuf-net « Koalite's blog
Hola,
tenemos una aplicación para pda (Microsoft Windows CE 5.1.478) basada en .Net Compact Framework 2.0 y nos hemos encontrado con un problema que no sabemos resolver. Dicha aplicación llama a web services de SAP. Desde la pda dichos servicios unos funcionan bien pero otros no. En cambio, los mismos servicios en la misma aplicación pero basada en .Net Framework 2.0 o 3.5 funcionan perfectamente. Después de mucho buscar qué está ocurriendo, necesitamos pregunta si alguien sabe que puede estar pasando. Gracias
No das muchas pistas… ¿Qué mensajes de error dan los servicios que fallan?
Hola Juanma,
son varios los problemas. Un de ellos es que al llamar a uno de los servicios, se genera el siguiente error de definición cuando en realidad si se está enviando dicho parámetro.
CX_ST_MATCH_ELEMENT:XSLT exception in offset 442 and XPath soapenv:Envelope(1)soapenv:Body(2)urn:sapService(1).System expected element ‘Items’
Otro problema es que se llama el servicio y si este responde con n registros, la aplicación en la pda actúa como si no hubiera recibido ninguno.
Como he dicho, el mísmo código fuente pero basado en .Net Framework 2.0 o 3.5 funciona sin problemas. Pensamos que el problema podría estar en la serialización de la información por las limitaciones de la pda tal y como comenta Koalite ya que tanto los datos que se envían a los servicios que fallan como los datos que estos devuelven son muy complejos(arrays multidimensionales).
Pues la verdad es que no tengo ni idea de qué puede ser.
Lo único que se me ocurre es meter un sniffer (WireShark o similar) para ver las tramas de red e intentar depurar a un nivel más bajo, pero si dices que con una aplicación de escritorio funciona bien…
Hola Juanma,
gracias por tu atención. Por fin, hemos dado con el problema. Las aplicaciones basadas en .Net Framework generan automáticamente el cliente proxy teniendo en cuenta el orden en que se envían los datos a los servicios web pero las aplicaciones basadas en .Net Compact Framework (para móviles, pdas ) dicho cliente se genera sin tener en cuenta esto y es el problema que se ha estado dando. Sap requería dicho orden. Hasta que no hemos serializado/deserializado manualmente la información que se enviaba a los servicios desde la pda no lo hemos podido ver ni saber. Por este motivo las llamadas desde la aplicación funcionaban sin problemas si se ejecutaba desde el PC y no funcionaban si las llamadas se hacían desde la PDA. Según Microsoft, por las limitaciones del .Net CF hay que forzar al generador del cliente proxy para que tenga en cuenta esto ya que por defecto no lo hace.
Os adjunto la web que nos ha servido de mucha ayuda:
http://blogs.msdn.com/b/netcfteam/archive/2007/02/01/why-your-netcf-apps-fail-to-call-some-web-services.aspx
Un saludo y gracias.
La verdad es que ahora que lo mencionas me suena haber tenido alguna vez ese problema.
Me alegro de que lo hayas resuelto y muchas gracias por compartir la solución.