Cuando .Net conocio a JSON

WCF El propósito de este post es tratar de añadir un poco de luz sobre las opciones con que contamos a la hora de que nuestros servicios web orientados a AJAX usen JSON como protocolo de serialización de los objetos.

Hace ya un tiempo escribí en este mismo blog sobre JSON. En ese momento, hace ya unos cuantos meses, JSON no era tan popular. Pero desde entonces, gracias al peso que ha ganado AJAX y en consecuencia JavaScript, JSON es cada vez más y más popular. El motivo de esta popularidad es que es una manera muy cómoda y compacta de serializar ‘objetos’ entre un servidor y un navegador que soporte JavaScript. JSON es un mecanismo muy potente a la hora de conseguir que la parte cliente de una aplicación web pueda pedir información al servidor en segundo plano y sin provocar un postback y luego trabajar con esa información de manera orientada a objetos con gran simplicidad.

JSON es muy cómodo porque simplemente hemos de construir una cadena de texto para serializar el objeto y esta cadena, además resulta ser todo lo que necesitamos para que realizando un Eval en la parte cliente, el código JavaScript que ejecuta el navegador tengamos un objeto JavaScript completamente funcional y con sus propiedades debidamente establecidas.

Además JSON es muy eficiente, sobre todo comparativamente, por que la alternativa utilizada hasta ahora para ‘mover’ objetos desde el servidor al navegador, XML, es un formato de serialización mucho más pesado que JSON. Y sobre todo mucho más difícil de tratar desde JavaScript.

Si queréis más detalles sobre JSON, en las referencias que encontraréis en mi anterior post podéis encontrar toda la información que necesitéis.

La creciente popularidad de JSON y su demostrada utilidad en aplicaciones AJAX, ha llevado a Microsoft a dotar a su Framework de desarrollo de soporte para este protocolo. Pero como a menudo ocurre en Microsoft han surgido esfuerzos paralelos lo que ha dejado a los desarrolladores que desean utilizar las posibilidades de JSON un poco descolocados.

La primera alternativa es utilizar el soporte para JSON que proporcionan las ASP.Net AJAX Extensions. La otra, que llega de manera oficial con la liberación definitiva de la versión 3.5 del Framework de .Net, son las nuevas capacidades relacionadas con JSON que aporta WCF. Y es de esta de la que voy a hablar con un poco más de profundidad, pues parece que WCF es el camino que Microsoft ha trazado a la hora de construir todo tipo de aplicaciones distribuidas.

El soporte para JSON en WCF que aparece Framework 3.5, simplemente se ha construido sobre las excelente capacidades de extensibilidad que presenta WCF. Por lo tanto nada diferenciará la construcción de nuestro servicio JSON, tendremos que declarar una interfaz, decorarla con el atributo [ServiceContract] y decorar sus métodos con [OperationContract], como haríamos con cualquier otro servicio WCF. Luego tendremos que implementar esta interfaz en una clase que implemente la lógica del servicio.

A la hora de alojar el servicio JSON podemos optar por todas las posibilidades que WCF permite para alojar servicios, pero por la propia naturaleza orientada a la web y a su consumo desde el navegador de los servicios que expondremos por JSON , la opción habitual será utilizar un .svc alojado en IIS para exponer nuestro servicio.

Luego pasaremos a configurar nuestro servicio de manera declarativa. Para construir un servicio WCF que exponga sus resultados como JSON debemos utilizar como base un binding HTTP

<bindings>
  <webHttpBinding>
    <binding name=»JSONBinding»/>
  </webHttpBinding>
</bindings>

Otro aspecto clave es que hemos de añadir a nuestro endpoint el behavior enableWebScript, este behavior es parte de la nueva pila de comunicaciones de WCF 3.5 para exponer servicios a JavaScript utilizando JSON. Cuando añadimos este behavior a nuestro servicio, WCF expone un endpoint adicional que permite obtener un proxy JavaScript que nos permitirá invocar fácilmente al servicio desde nuestro código JavaScript de lado cliente. La dirección de este enpoint es la dirección del servicio más /js.

<behaviors>
  <endpointBehaviors>
    <behavior name=»JSONBehavior»>
      <enableWebScript/>
    </behavior>
  </endpointBehaviors>
</behaviors>

La configuración del servicio será algo como esto:

<services>
  <service name=»PlainConcepts.Samples.Services.JSONService»>
  <endpoint
                   address=»AjaxEndpoint»
                   behaviorConfiguration=»JSONBehavior»
                   binding=»webHttpBinding»
                   bindingConfiguration=»JSONBinding»
                   contract=»PlainConcepts.Samples.Services.IJSONService»/>
  </service>
</services>

Vemos como exponer el servicio mediante JSON solo es una cuestión de configuración. Solo es una capacidad añadida a WCF mediante su mecanismos estándar deextensibilidad.

Para consumir el servicio desde una aplicación ASP.Net usaremos el ya conocido control ScriptManager para referenciar el endpoint de nuestro servicio JSON. Esto generará una clase JavaScript que nos permitirá invocar nuestro servicio desde nuestro código JavaScript de cliente sin tener que pedir nosotros el proxy a el endpoint /js explicitamente.

<asp:ScriptManager ID=»scriptManager» EnablePartialRendering=»true» runat=»server» ScriptMode=»Release»>
  <Services>
    <asp:ServiceReference Path=»/ServiceHost/JSONService.svc/JSONEndPoint» />
  </Services>
</asp:ScriptManager>

Otra opción a la hora de consumir servicios JSON es usar las posibilidades de vinculación a servicios que presentan muchos de los controles se ASP.Net Ajax, pero eso es harina de otro costal…

4 comentarios sobre “Cuando .Net conocio a JSON”

  1. Podrias recomendarme un inicio para WCF?
    El libro que sugieres?
    Donde encuentro mas informacion sobre como poner en marcha una verdadera aplicacion SOA, demas esta pedir un «demo»

    Gracias Rodrigo

  2. Hola Rodrigo
    Soy un seguidor de tu blog, tengo unas preguntas para ti respecto a este post.
    Bajo ciertas condiciones he encontrado (http://forums.asp.net/p/1138793/1829770.aspx#1829770) que usando el serializador de ASP.NET Ajax me sale error de referencia circular, como viste es un error del serializador, este error persistira con la version 3.5? Y como decia alguien por ahi Microsoft parece que vive en un mundo de ensueño donde no cree que nos encontraremos con objetos anidados recursivamente.
    Saludos

  3. Enrique, en cierto modo comparto lo que dices, no en vano es un problema que mucha gente se encuentra y cuando todo el mundo tropieza en la misma piedra algo falla…

    Pero por otro lado no puedo evitar pensar que las referencias circulares siempre son peligrosas y a menudo (no siempre, cierto es) sintoma de mal diseño.

    De todos modos el problema es otro, no es que los ingenieros de Micro no lo quieran resolver es que no hay manera de resolverlo.

    Pensa en dos objetos A y B que se referencia mutuamente. ¿Cómo podría saber el serializador que eso es un ciclo? No hay manera… A referencia a B y B a A, pero A podría ser C… No hay manera de saberlo, luego es la pescadilla que se muerde la cola. Se podría hacer si el serializador supiese algo sobre el objeto en concreto, si cada objeto proporcionase algún tipo de identificador único pero… esto no es así.

    Saludos!

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *