Mes: enero 2008

Uno de los mitos más arraigados sobre las metodologías ágiles de desarrollo de software es que el planeamiento y la estimación no son realizadas con el suficiente rigor. Este es un ataque interesado de sus detractores que no llegan a comprender que otra forma de planear y estimar que la que tradicionalmente se ha realizado, basada en la descomposición en tareas del problema, es posible.

Mike Cohn en este excepcional libro desgrana los entresijos del planeamiento y la estimación ágiles. El libro está plagado de historias y ejemplos de como un equipo ágil puede abordar el difícil problema de la estimación y la planificación de proyecto. Mike Cohn no nos da recetas sino que nos plantea las posibles alternativas con la que, siempre dentro de una visión ágil, podemos abordar estos problemas.

La estimación, base de toda planificación, es uno de los problemas relacionados con el desarrollo que más me apasionan y al que ya he dedicado numerosas entradas en este blog.

El libro que hoy comento me ha encantado: bien escrito, claro, muy descriptivo, poco prescriptivo y fundamentando todas y cada una de las diferentes aproximaciones que propone. En definitiva un libro que todo jefe de proyecto ágil o no debe leer.

Sin duda la estimación y la planificación plantean un montón de problemas arduos, tan arduos que muchos equipos ni siquiera se plantean el tratar de resolverlos. Sin duda, la solución que tradicionalmente se ha dado, tan pesada que hacia que muchos proyectos muriesen en la fase de planificación, tampoco ayudaba a que los equipos de desarrollo se lanzasen a realizar una planificación basada en estimaciones. Y los equipos que se atrevían a menudo sucumbían ante el coste que una planificación detallada basada en descomposición de tareas y la identificación de hitos requiere. En este libro encontraremos la descripción de las técnicas concretas que muchos equipos de desarrollo están utilizando para lograr estimaciones con un rango de confianza suficiente para realizar planificaciones realistas sobre las que basar la gestión del proyecto.

El libro describe por qué es importante planificar, los problemas que encontramos habitualmente y la aproximación que desde las metodologías ágiles se propone. Después pasa a describirnos uno de los pilares fundamentales de la planificación: las estimaciones de tamaño y duración se deben mantener separadas y como la velocidad del equipo de desarrollo es el factor que las une. El libro no se olvida de los principios de las metodologías ágiles y dedica toda una parte a describir técnicas orientadas a asegurar que la planificación está guiada por el valor que el cliente recibe. No olvida los aspectos más mundanos de la planificación como la necesidad de comunicar nuestras estimaciones y de comprender que las estimaciones solo son eso, estimaciones. Por último el libro culmina en un caso de estudio bastante amplio que describe con bastante detalle como llevar a cabo las técnicas descritas basándose en un ‘caso real’.

Un gran libro sin duda, el mejor que he leído este año. Si estáis interesados en la gestión de proyectos no dudéis en comprar este libro que debe estar en toda bibliografía sobre gestión de proyectos que se precie.

Este pasado viernes tuve el placer de participar en el primer aniversario de NavarraDotNet, el grupo de usuarios de .Net de Navarra, como los lectores más avispados ya habrían deducido ;).

El viaje Bilbao Pamplona estuvo plagado de pequeños problemas. Para empezar tuve que alquilar un coche, la gente de los talleres no cumple lo que promete, lo que me sirvió de utilidad para descubrir que es imposible que haga lo que haga un tío de mi tamaño (1,97 y 110 kilos) viaje cómodo en un Fiat Punto. Pero eso no es lo peor, tuve que sufrir las consecuencias de lo que un administrador concienzudo en lo que a la seguridad se refiere puede hacer sobre tu PDA. Y es que Iván, había distribuido una política de seguridad hasta mi PDA, haciendo uso de sus todopoderosos privilegios de administrador, que bloquea mi PDA cada n minutos, para mejorar la seguridad de Plain Concepts… y de paso hacer mi vida mucho más difícil. La consecuencia fue que cada vez que esos n minutos pasaban la PDA se bloqueaba y me quedaba si GPS (gran pifia de Microsoft o de los de TomTom no lo tengo muy claro). Desconozco el valor de n, pero si se que era exactamente igual a lo que yo tardaba en desplazarme en el diminuto Fiat Punto de cruce a cruce.

A pesar de las vicisitudes pude llegar a Biko2, una de las empresas patrocinadores del evento, que participaba con varios ponentes y sobre todo, lo más importante, ponía la merienda. Allí durante la mañana tuve la oportunidad de charlar con ellos sobre su proceso de desarrollo, su camino hacia CMMI y lo que Team System les podría aportar… Me sorprendió encontrar una empresa preocupada por la metodología, algo no tan habitual en este pais, con profesionales que comprenden la importancia de este tema, que dedica recursos y que cuenta con amplios conocimientos sobre CMMI y sobre todo con una visión moderna de la gestión de proyectos, que no suele ser habitual cuando CMMI está de por medio.

Después de picotear unos pinchos para comer, una pena que la premura no nos dejase poder disfrutar de la grastronomia Navarra, comenzaba el ajetreo del evento. Unai finalmente no pudo asistir, pero yo no me quejo, así tuve más tiempo yo. Todo sobre ruedas: buena asistencia, gente interesada, organizadores entregados y sobre todo… merienda!!! A ver si aprendemos en Artalde.net jejeje… nuestros vecinos ya no solo nos superan en los carteles… vale que los navarros (con el permiso de Titin) barran a pelota, pero que sus eventos molen más (insisto: con merienda!!!) es algo a lo que tenemos que poner remedio…

Especialmente bonito fue que mi amigo Carlos Segura, un autentico crack y uno de los padres fundadores del grupo fuese quien me presento. Agradecer desde aquí el que me invitasen a participar en tan magno evento, el que me escuchasen la ‘chapa’ sobre Scrum y Team System con tanto interés y sobre todo que me diesen la oportunidad de compartir el entusiasmo por el desarrollo de software que se respira en ese grupo. Procuraré acudir a la llamada de este grupo siempre que consideren interesante invitarme.

Una pena que no me pudiese quedar a la cena, la cosa prometia, pero tenia que devolver el infame Fiat Punto de alquiler… :(. A ver si alguien nos cuenta en los comentarios como se dio el tema…

Si me lees desde Pamplona o alrededores, te entusiasma el desarrollo de software, y aun no has participado en ninguno de los eventos de NavarraDotNet, no sabes lo que te pierdes.

Planteaba José M. Aguilar la interesante cuestión que da título a este post. Es también una pregunta que recibo a menudo en los cursos de Gestión de Proyecto que imparto. Asi que voy a dar mi opinión. Opinión que esta basada simple y llanamente en lo que yo valoro cuando trabajo con un desarrollador codo con codo.

Todas las cuestiones que se han planteado en los comentarios al post de José son relevantes, desde luego, pero en mi opinión hay tres factores claves a la hora de distinguir a un buen desarrollador:

La calidad de los artefactos que generan (código, diagramas, diseños, planes de proyecto, burndown charts, etc… según el perfil), algo facil de comprobar simplemente viendolos. Ver el código de un desarrollador, pantallazos del trabajo de un diseñador, o pedirle a un arquitecto que te explique algunos diagrámas de sus arquitectura es algo que sin duda nos va a dar idea de la calidad de su trabajo. En el desarrollo de software la calidad no es opcional. Esto nos da un vistazo ràpido de las capacidades técnicas con cierta independencia de la tecnología que emplee. Si un desarrallador no nos puede enseñar nada del producto de su trabajo es seguro una mala señal y esto ocurre a menudo. Por otro lado, aquel que nos enseñe su trabajo y hable de él con pasión tiene bastantes números, en mi opinión, para ser un buen desarrollador.

La cantidad de proyectos completados, puestos en producción y con usuarios usándolos en los que han participado. Esto nos da una idea rápida de la experiencia real y de las capacidades no técnicas. Es fácil preguntar por este punto en una entrevista, además da oportunidad al desarrollador de explayarse sobre lo que aporto en esos proyectos, las dificultades que encontro etc… Pero sobre todo esto nos da una idea de si es alguien que termina lo que empieza. Conozco algunos desarrolladores técnicamente excelentes incapaces de completar nigún proyecto. Un proyecto es un camino duro, lleno de momento mejores y peores, de cosas divertidas y cosas menos divertidas. Muchos desarrolladores pierden la ilusión por el proyecto una vez esta hecho lo que ellos consideran el ‘trabajo bonito’. Otros muchos carecen del pragmatismo necesario para completar los proyectos, y convierten los proyectos en los que participan en un continuo ejercicio de investigación. Hay que distinguir desarrollo de investigación. La cantidad de proyectos completados también es indicador de la capacidad para dominar tecnologías, en lugar de dejar que estas dominen el discurrir del proyecto. No quiero decir que las cuestiones técnicas no sean relevantes, pero si quiero decir que no son las más relevantes.

Las capacidades de comunicación tanto oral como escrita. Esto nos da idea de si podrá comunicarse con otros miembros del equipo. Las dificultades de comunicación es uno de los principales problemas que se encuntran los proyectos de software. Si los miembros del equipo no son capaces de transmitir información de manera fluida tendremos serios problema a la hora de conseguir que el equipo de desarrollo funcione como un autentico equipo. Además esta no es una cuestión relevante solo de puertas adentro del equipo. Los proyectos son un exito o un fracaso en función de lo que el cliente percibe. Un grupo de desarrolladores capaz de comunicarse con soltura con el cliente con seguridad va a obtener mejores resultados, resultados más alineados con las necesidades del cliente. Pero si este no fuese el caso y los resultados solo fuesen ‘normalitos’, las capacidades comunicativas siempre juegan a favor de que los resultados obtenidos, sean cuales sean, se ‘vendan’ mejor. Otro factor importante es que quien es un buen comunicador suele ser un gran lector, y para estar al día en esta industria hay que leer mucho… por mucho que a algunos no les gusten los libros. Y para terminar todo proyecto de software necesita generar algo de documentación por mucho que yo no sea muy amigo de la documentación por la documentación (1, 2 y 3), y es una tarea que los desarrolladores no disfrutamos por lo tanto cuanto mejores seamos escribiendo menos nos costará realizar la ardua labor. 

Estoy involucrado en un interesante proyecto que tiene por objetivo demostrar que VSTS for Tester es una plataforma interesante a la hora de testear arquitecturas no centradas en plataforma Microsoft, arquitecturas muy heterogéneas. Un primer post relacionado este proyecto fue: Pruebas web de Team System usando Firefox. Y seguro que habrá más.

Uno de los primeros pasos que tengo que dar es obtener de manera remota información del comportamiento, desde el punto de vista del rendimiento, de una máquina Unix/Linux. La familia de los Unix cuenta con una serie de comandos que nos permiten saber como se está comportando la máquina, el más relevante de ellos quizás sea vmstat que da información sobre varios aspectos relacionados con el rendimiento. El afán final es poder exponer información de máquinas Unix como contadores de rendimiento de Windows para poderlos recolectar desde pruebas de carga de VSTS, ya que esta es la única fuente de información sobre el rendimiento que Team System integra en las pruebas (aunque es probable que esto cambie con Rosario)… pero no llegaré tan lejos hoy, hoy solo voy a comentar como ejecutar comandos remotamente desde .Net (en concreto con C#) contra máquinas Unix.

La manera habitual de ejecutar comandos Unix de manera remota es utilizar ssh (Secure Shell). En la siguiente imagen podéis ver el resultado de ejecutar el comando vmstat utilizando PuTTY como cliente ssh contra una máquina Linux(corriendo Fedora) desde una máquina Windows:

Ahora la pregunta es obvia, ¿existe alguna manera de ejecutar un comando usando ssh desde código .net y recoger la salida del mismo? La respuesta es sí gracias a SharpSSH una librería de código abierto creada para este cometido. No cuenta con mucha documentación pero su uso es simple, a menos para lo que yo necesito. Basta poner una referencia a la libreria Tamir.SharpSSH.dll y utilizar la clase SshExec para ejecutar el comando. Os dejo el código comentado a continuación:

La salida de la ejecución del este programa es la siguiente:

Con lo que doy por cumplido mi objetivo, al menos de momento… os seguiré contando mis avances.

Me he visto recientemente involucrado en el proceso de selección de una herramienta para el testeo de aplicaciones web. Sobre todo para el análisis del rendimiento de la mismas. Evidentemente yo estaba presente en este proceso para comentar las excelencias de Visual Studio Team System for Testers en este campo, que son muchas.

Yo defendía claramente la superioridad y capacidad técnica de VSTS for Testers a la hora de dotar al equipo de desarrollo con un entorno integrado, completo y ágil a la hora de hacer pruebas. La parte ‘contraria’, representante de una de esas empresas que, tras competir con dudoso existo (a tenor de los resultados económicos) con Microsoft en el terreno del software privativo, se ha convertido al software libre con la vehemencia del nuevo creyente, no contaba con una solución, ni de lejos, comparable a las posibilidades de VSTS for Testers. La solución que proponian: una herramienta de stress más un profiler, solución a todas luces insuficiente, pero la única que podían ofrecer.

Supongo que debe ser alguna táctica comercial bien estudiada, el que ante la certeza de que estas en inferioridad, la mejor manear de capear situación es tratar de hacer ver que no son necesarias las capacidades que la solución de tu competidor te ofrece. Aunque en tu fuero interno sepas que no estás diciendo la verdad. Otra cosa curiosa es como en cierto momento la situación giro a que se usase lo que se usase, no fuese un producto de Microsoft. Como si usar productos que no sean de Microsoft (no ya que sean libres) fuese directamente bueno para el proyecto o te dotase incluso de superioridad moral. Y la verdad, eso es algo que me revienta. Si somos técnicos, somos técnicos y debemos admirar las grandes soluciones vengan de donde venga. Aunque vengan de Microsoft. Sobre todo cuando nuestro trabajo es el de expertos independientes.

Pero bueno, volvamos al grano, y a lo me que ha motivado ha escribir este post: por qué una herramienta de stress y un profiler, aunque herramientas imprescindibles, no son herramientas suficientes y menos aun optimas para hacer pruebas de carga y analizar los resultados, y por qué VSTS for Testers si es una solución completa y potente.

Cuando nos planteamos hacer pruebas de carga, evidentemente, necesitamos una aplicación que sea capaz de generar de manera simple, repetible, distribuida, suficiente, y controlada peticiones a la aplicación que queremos someter a estres. Además debe poder añadir esta carga incrementalmente o buscando ciertos objetivos de utilización recursos (tests guiados por objetivos, en plan, añade peticiones hasta que el procesador del servidor de bases de datos llegue al 80% y mantenla, imprescindibles para poder hacer capacity planning). Evidentemente esta aplicación debe ser capaz de hacer muchas otras cosas como utilizar diferentes juegos de datos, darnos información sobre los recursos que consume para generar el estrés (debemos saber si el cuello de botella está en el propio generador de carga o en la aplicación), los test que ejecuta en un tiempo dado y cuantos de ellos cumplen las postcondiciones que se hayan podido establecer y cuantos son erroneos por no cumplirlas. Además, lógicamente, debe ser capaz de generar peticiones según los protocolos usados en la arquítectura, pues por ejemplo, no todas la herramientas se comportan bien cuando hay Ajax de por medio. Evidentemente VSTS for Testers nos permite todo esto. Podéis en la imagen siguiente ver como es la definición de un test.

Pero esto no es suficiente para que las pruebas de carga sean significativas. Sería sufiente si simplemente quisiesemos poner fuerza bruta en la aplicación bajo testeo hasta que esta ‘cascase’ por algún lado. Pero ese es un objetivo poco ambicioso que a duras penas justifica el esfuerzo de montar un entorno de pruebas, crear pruebas y contar con un equipo de testers. Si hacemos pruebas de carga las tenemos que hacer con un proposito claro: mejorar el rendimiento de la aplicación y en consecuencia, su escalabilidad, no simplemente nos debe valer el saber los límites de nuestra aplicación. Y para esto debemos ser capaces de detectar cuellos de botella. Esto es lo realmente importante de las pruebas de carga: detectar cuellos de botella. Saber que recursos hacen que nuestra aplicación no se ejecute más rápido y sobre todo, saber donde debemos centrar nuestro esfuerzo económico, bien en forma de más hardware o bien en forma de esfuerzos de optimización.

Hoy en día las aplicaciones son cada vez más distribuidas y más orientadas a servicios. La consecuencia clara es que el rendimiento de nuestra aplicación depende de un gran número de factores, dispersos por un gran número de máquinas y por un gran número de aplicaciones, que proporcionan diferentes servicios. En esta situación pretender que un profiler junto con una aplicación que genere carga es una solución suficiente es cuando menos miope. Solo si tu entorno de pruebas es capaz de monitorizar como se comportan todos los sistemas implicados en la prueba podrás detectar los cuellos de botella que se producen en el sistema y una vez claramente identificados ajustar el hardware, la aplicación o el código (en este caso si, siempre usando la imprescindible ayuda de un profiler). Pero prenterde utilizar en un sistema distribuido un profiler como única herrmienta es absurdo ¿vas a ir ‘enchufando’ profilers a todos los componentes de tu aplicación? ¿Y que pasa si el cuello de botella está en la saturación de red, algo que nunca verías con un profiler? ¿Y si tua aplicación usa colas y este es el cuello de botella, algo que nunca verás tampoco con un profiler?. En la siguiente imagen podéis ver como VSTS recolecta la información que deseemos sobre el progreso de la prueba.

Conscientes de esto, Microsoft nos proporciona una solución completa con VSTS for Testers, que permite lanzar pruebas distribuidas desde un único PC y monitorizar desde este mismo, en tiempo real, como se comportan todos los elementos, a nivel de hardware o de software implicados en la prueba. De esta manera, el proceso de pruebas es completo, repetible y significativo.

La forma de actuar es la siguiente: defines la prueba, defines los parámetros relevantes desde el punto de vista del rendimiento que quieres monitorizar, lanzas la prueba, y durante la realización de la misma VSTS recolecta todos los parámetros relevantes, avisandono además cuando alguno se sale de magnitudes normales. Luego utilizando el conocimiento que tenemos del sistema y de su arquitectura analizaremos los datos recolectados sobre el conjunto del sistema bajo prueba para buscar aquellos cuellos de botella que merezcan nuestra atención. Si estos están en nuestros componentes, entonces usaremos un profiler para hilar fino y ver que problemas puede haber en nuestro código que esten dañando el desempeño del sistema en su conjunto.

Utilizar únicamente una herramienta de generación de carga y un profiler es como disparar al aire con la intención de cazar algo. Previo al uso de un profiler, es necesario hacer un análisis de más alto nivel, por simple economía de recursos.

Llevo un tiempo con ganas de meterle un poco de mano a PowerShell y por fin he encontrado la ocasión. Siempre he sido un gran amante de los scripts y siempre he sentido un poco de envidia de los poderosos interpretes de comandos del mundo Unix, pero se acabo. Habitualmente uso vbs para mis scripts, es bastante potente y muy simple de programar y además puedo acceder a cualquier objeto COM (lo que es tanto como decir que se puede hacer cualquier cosa).

El otro día, harto ya de purgar a mano las colas MSMQ de la aplicación en la que estoy trabajando, decidí hacer un script para automatizar esta tarea. El problema es que vbs no tiene manera de controlar colas MSMQ y aunque se supone que existe un API COM de administración MSMQ, no fui capaz de dar con la documentación de la misma.

Así que ya tenía la escusa perfecta para hacer mis primieros pinitos con PowerShell , ya conozco el API de MSMQ de .Net y por tanto hacer el script de PowerShell es coser y cantar.

Y tengo que decir que… estoy enamorado de PowerShell!!! Es impresionante el tener todo el API de .Net al alcance de un lenguaje de scripting contodas las facilidades de un lenguaje de scripting tipo shell (pipes, manejo de ficheros simple, orientación a la línea de comandos etc…).

A continuación os dejo el código del script en cuestión, que aunque es muy simple, da una idea de como manejar colas MSMQ desde PowerShell, lo único que hago es enumerar todas las colas públicas y luego purgar aquellas pertenecen a mi aplicación:

# Script que permite purgar todas las colas privadas de Captor
# Cargamos el assembly que nos permite trabajar con colas
[Reflection.Assembly]::LoadWithPartialName(«System.Messaging») | out-null

# Obtenemos las colas privadas
$queues = [System.Messaging.MessageQueue]::GetPrivateQueuesByMachine(«.»)

foreach ($queue in $queues)
{

    # Si la cola es de Captor la purgamos
    if ($queue.QueueName.Contains(«captor»))
    {
        $queueName = $queue.MachineName + «» + $queue.QueueName
        $q = new-object System.Messaging.MessageQueue($queueName)
        Write-Host «Purgando la cola» $queueName «que contenía» $q.GetAllMessages().Count «mensajes» -foregroundcolor Yellow
        $q = new-object System.Messaging.MessageQueue($queueName)
        $q.Purge()
    }

}

Write-Host «Se purgaron las colas MSMQ de Captor» -foregroundcolor Green

El resultado de la ejecución del script es el que sigue:

Prometo que habrá más entradas sobre PowerShell en este blog…

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…

Excelente manera de comenzar el año. Microsoft ha tenido a bien distinguirme en una ocasión más como MVP en la categoría de Team System. Es la quinta vez, tres veces en la categoria de C++ y dos más en la de Team System, y no por ser la quinta vez la ilusión es menor. Ilusión que nace de poder compartir un año más de eventos y buenos ratos con el resto de MVPs, que es lo que realmente hace importante este reconocimiento.

Quiero aprovechar para agrader a la comu nidad la excelente acogida que han dado a todos mis eventos, artículos, participaciones en grupos de usuarios, a mi blog y a Geeks.ms. Sin esta excelente acogida, el reconocimiento, el apoyo y el ánimo que la comunidad me brinda yo no sería MVP. En especial la gente de Artalde, dotNetMania y mis compañeros de Plain Concepts y de Sisteplant que incluso han comprado el famoso calendario.

También quiero agradecer todo lo que de la comunidad aprendo que es mucho más valioso que el reconocimiento como MVP, a pesar del valor que le doy.

Espero estar a la altura del reconocimiento que Microsoft me ha otorgado.