.NET 3.0: Sí o No?

 Como  arquitectos que somos, esto nos pasa seguido y nos va a seguir pasando: siempre que quieras seguir el tren de la tecnología tenés que invertir un montón de tiempo -que finalmente termina siendo personal, no laboral- en entender los nuevos avances para tomar la decisión de si realmente la adopción implica una ganancia efectiva para alinear mejor la tecnología al negocio, o no, de modo de poder descartarla

Y cuando invertiste ese tiempo tuyo y creías que ya de nuevo estabas en la línea de combate, los principales vendors, o incluso nuevos jugadores, pegan un patadón a la mesa, hacen volar todas las fichas y vos -como buen gil a cuadros- estás al final de la cola de nuevo (que lo parió…)

Lógico, innovar es necesario siempre que sirva para encontrar nuevas maneras de hacer lo mismo con menos costos o, incluso, poder hacer más. Por esa razón no se le puede pedir a la industria tecnológica "loco, paren de sacar cosas nuevas a cada rato". Del mismo modo, plantarse uno en la postura de "ma sí, dejalos que innoven tranquilos que acá va a ser como si pasara un tren" y no dedicar un tiempo en entender los por qués de los avances, no sólo es a la larga perjudicial para la organización en la que uno trabaja, sino para uno mismo que va así bajándose del ring (y perdiendo la pelea por puntos). Conviene acá hacer una aclaración: el arquitecto no es un technical decision maker (un TDM, un tomador de decisiones sobre rumbos tecnológicos) pero sí un technical decision influencer (TDI), un referente confiable del TDM (que normalmente es el jefe o gerente de tecnología) dada su posición privilegiada de visagra entre los que toman las decisiones (CTO, CIO, etc) y los que las ejecutan (desarrolladores, operadores, etc)

Me atrevería a decir que la principal frustración del arquitecto pasa por no poder dejar atrás su perfil techie de desarrollador e insistir en querer entender no sólo los qués de la cuestión sino también sus cómos. Mala cosa, ésa. Como decía Mike Platt unos posts más atrás, un arquitecto tiene que saber lo necesario para ir directo al fondo del asunto, y nada más. Dicho en forma más explícita y con ejemplos, sabete los pros y cons de usar colas asíncronas por sobre comunicación sincrónica, bases de datos sobre XML, cliente enriquecido vs cliente web, alternativas de manejo de estado en sesiones web, etc, pero sin necesariamente conocer cómo se echa mano a cada una de esas -si no los desarrolladores qué, no?-

Obvio que conocerlas va a ser un plus, pero cuesta caro llegar a ese estado y además te va a poner un techo en tu carrera. Los arquitectos que compiten por saber más que el más senior de los desarrolladores se van a tener que quedar hasta cualquier hora a encontrar qué es lo que está afectando el rendimiento o la escalabilidad de las aplicaciones core de las organizaciones, y por ende van a ser menos elegibles para una promoción a un rol de liderazgo dado que lo van a necesitar al pié del cañón en el próximo tsunami

Me atrevería a decir que es ese cambio de piel de ya "no tocar más código" es lo que más preocupa a los arquitectos: el temor a perder gravedad y que en cualquier momento el desarrollador más senior termine de adquirir los perfiles necesarios para ser arquitecto de software -de la misma manera que uno los ganó, tiempo ha- y nos termine pasando como a gordo en maratón

En realidad, lejos de estar preocupándose en cómo crecen los de abajo, el arquitecto inteligente debería estar planeando su carrera "hacia arriba". Esto es, como gerente de tecnología o incluso director

Todo este preámbulo para introducir al tema que me ocupa: a finales del año 2005 y con mucha pompa Microsoft había lanzado Visual Studio 2005 junto al framework .NET 2.0, SQL Server 2005 y otras tecnologías y productos que le siguieron meses después, lo que implicaba un cambio sustantivo en la forma de desarrollar y distribuir aplicaciones, que el mercado afortunadamente recibió en forma positiva

Pero claro, para decidir si adoptar o esperar, los arquitectos -estén ya aplicando .NET o no!- debían conocer que ahora ASP.NET 2.0 incorporaba master pages (y más allá de entender cómo se hacían, había que entender en qué beneficiaría eso a la organización de uno), distribución de aplicaciones de escritorio mediante ClickOnce (y de nuevo, no importa cómo sino qué se gana), Multiple Active Result Set (MARS) en ADO.NET 2.0 y tantas otras innovaciones. La idea no era entender esto para migrar todo lo que se llevaba haciendo además de lo ya hecho, sino considerar a .NET 2.0 -en el caso de que trajese beneficios sustantivos- como una tecnología ya sea a aplicar en el mediano y largo plazo, ya a aplicar aún más de lo que se estuviera haciendo

Inclusive para decir "no, acá .NET 2.0 no entra" concienzudamente -o con la conciencia limpia :-D- era necesario conocer los beneficios para llegar a la conclusión de que a esa organización no le revestían mayor importancia. Por ejemplo, ClickOnce se ve lindo pero si la organización, por cuestiones coyunturales, maneja mayormente interfaces web, 0 (cero) o poca ganancia por adoptar .NET en lo que a ClickOnce respecta

Obviamente esto, sumado a otros avances paralelos del lado Java EE como la liberación de la versión 5, iniciativas independientes como Spring o, más allá del bien y del mal, el stack de tecnologías LAMP, es una presión sobre el arquitecto difícil de barajar

Y como si todo eso no hubiera sido nada, ahora Microsoft libera la versión 3.0 de .NET. Aunque parezca que lo hizo muy rápido, en realidad es al revés: la mayoría de las APIs que trae .NET 3.0 originalmente se hubieran querido incluir en .NET 2.0, que a la vez se deseaba lanzar junto a Windows Vista o al menos próximo. Inclusive, un mapeador entre objetos y registros de tablas relacionales llamado ObjectSpaces, así como cierta API para acceso al sistema de archivos llamada WinFS, quedaron en el camino

Aún así, no todas fueron podas, Windows Workflow Foundation (WF, un motor de workflows súper práctico del que ahora voy a hablar), así como Windows CardSpace (un mecanismo potentisimo de identificación que también voy a describir en un rato) se anotaron a última hora al delivery demorado

Pero al arquitecto le da lo mismo si salió demorado o apurado: la cosa es que ahora salió, está ahí, y tarde o temprano no digo que vaya a haber que adoptarlo, sino al menos entender qué es lo que trae, si eso realmente representaría una ganancia en términos de alineamiento tecnológico a las necesidades de negocios de la organización -ya sea por acortar los tiempos de desarrollo, por lograr mejor integración de los sistemas de la organización o incluso de terceros habilitando nuevas capacidades, etc-

Cuáles son los pasos que un arquitecto podría tomar para poder tener más elementos a la hora de emitir un juicio sobre esta nueva versión de la plataforma?

 
  • Conocer los avances que la nueva tecnología aporta al desarrollo de aplicaciones y/o a su proceso (por ejemplo, las master pages de ASP.NET 2.0 aportaban al desarrollo de aplicaciones web, en tanto que Visual Studio 2005 Team System aportaba al proceso de desarrollo, se entiende?), entendiendo asimismo cómo la organización monetizaría este avance ("monetizar": ahorraría plata en cada ciclo de desarrollo? ganaría tiempo? lograría mejores resultados? Esas son las preguntas que responden "qué significa monetizar")
     
  • Con la lista en la mano de estos avances, el arquitecto pasa a estar en una posición inicial de hacer un dictamen go/no go de la plataforma. Si dice "no go" al TDM, es directamente no (claro, justificando los por qués). Ahora sí dice "go", es en realidad un "tal vez". Porque todavía queda evaluar la factibilidad de la adopción -aunque se la vaya a adoptar para proyectos acotados-
     
  • Evaluar la factibilidad es en otras palabras estimar los costos de adoptar, más allá de los beneficios que se cuantificaron en el paso anterior. Preguntas tales como "las APIs son sencillas de aprender?", "son sencillas de dominar?", "las van a entender nuestros desarrolladores o vamos a tener que salir a buscar nuevos al mercado?", "si hay que salir a buscar… el mercado tendrá ya desarrolladores duchos en esta plataforma?", "convendrá eventualmente encapsular la API dentro de un componente más sencillo de aprender y asimilar por parte de la mayoría de nuestros desarrolladores, de manera de que la terminen aprovechando sin tener que pagar el costo de su aprendizaje?" (atención con ésto último porque de todas formas no sale gratis: la API simplificadora va a haber que desarrollarla y después mantenerla, y los desarrolladores mediopelo van a tener que aprendarla también, aunque sea más simple)
     
  • Es en esta etapa que el arquitecto se puede asociar con el o los desarrolladores más senior, en lugar de estar haciéndoles la vida imposible para que no progresen, para responder a esas y a otras preguntas en forma práctica. Entonces la cosa pasa por seleccionar un elenco acotado de casos testigo, un 20% de situaciones que se presentan el 80% de los casos (Paretto suena tan lindo, siempre me hace quedar bien :-D) de manera de realizar Pruebas de Concepto (Proof of Concepts, o PoC’s)
     
  • El arquitecto idea los tests que considera necesarios realizar para confirmar la viabilidad de adopción de la plataforma, en términos de aquellos beneficios de su lista que realmente atañen a la organización. El o los desarrolladores senior los ponen en práctica
     
  • Elementos medibles pueden ser: reducción de las líneas de código, ganancia en un ciclo de desarrollo, rendimiento de la nueva plataforma (mediante una prueba de stress), y otros. Me quiero detener acá un segundo en comentar acerca de la curva de aprendizaje, porque hay al menos dos cosas que se deben considerar de ella:
     
    • Hay plataformas que son muy difíciles de aprender, en tanto que una vez que se aprenden, los beneficios pagan el costo inicial. Afortunadamente el duro aprendizaje inicial es un costo de única vez. Después la curva se ameseta, por lo que los plazos para incorporar expertise son más breves (ver figura 1)

Figura 1 – Se avanza lento al principio, pero una vez
que se llega a cierto nivel, los plazos son más breves

 

    • En cambio, puede ocurrir que aún habiendo aprendido lo básico para comenzar, estas plataformas siguen siendo luego difíciles de dominar. Quiero decir, escribir código básico sale como chorizo. Pero luego el tuning para que funciones en términos aceptables de rendimiento, escalabilidad -en términos del usuario- o incluso fácil de cambiar en el futuro -en términos de el propio equipo de desarrollo- puede ser otra la historia. La figura 2 ilustra este caso

Figura 2 – Valor de la entrada algo más barato que
el caso anterior (igual caro en este ejemplo), pero
una vez alcanzado cierto nivel igual sigue siendo
costoso avanzar

 

    • Haciendo un balance, incepción inicial y perfeccionamiento posterior son las dos pendientes que hacen a una curva de aprendizaje, y que deberían estimarse antes de adoptar una tecnología o API

De esta manera, y éste era entonces el objetivo de este post, quiero destacar lo que trae de nuevo .NET 3.0 y ofrecer, tanto al arquitecto como al desarrollador de software, elementos como para que puedan evaluarlos en un período relativamente razonable, y decidir así la conveniencia o no de su adopción
 
En términos generales, .NET 3.0 agrega cuatro APIs nuevas a la versión previa de la plataforma, por lo que hay que ser concientes, si no se venía aplicando .NET 2.0, que adoptar .NET 3.0 implica revisar todo el stack, no sólo las cuatro novedades


Figura 3 – .NET 3.0: cómo se compone la nueva versión

Esto querría decir que habría que entender qué lenguajes de programación ofrece la plataforma, si estos son fáciles de asimilar por los desarrolladores de la organización, si el mercado laboral ofrece recursos humanos, si las APIs básicas de la plataforma (ASP.NET 2.0, ADO.NET 2.0, System.Xml 2.0, etc) son potentes y fáciles de usar, si los servicios de código administrado que la plataforma ofrece (chequeo de tipos, recolección de memoria liberada, etc) no impactan seriamente en el rendimiendo, etc. Y finalmente, Visual Studio 2005. Siendo que es la principal herramienta disponible (no la única pero sí kilómetros de distancia por adelante de las otras en lo que respecta a proyectos en equipos), también se deberían revisar sus capacidades y asistencia al desarrollador y/u otros miembros del equipo antes de seguir hablando
 
En lo que sigue, me voy a focalizar en los avances aportados por .NET 3.0 y cómo y dónde probarlos. Los cuatro componentes nuevos son:
 

  • Windows Presentation Foundation (WPF): habilita la creación de interfaces de usuario más potentes en plazos más breves, permitiendo combinar adecuadamente formularios, gráficos vectoriales, documentos e incluso multimedia (el modelo de programación es indistinto). Aunque disponible para Windows XP y Windows Server 2003, esta API se pensó para trabajar directamente con Aero, la nueva interfaz gráfica de Windows Vista, que a su vez aprovecha las capacidades adicionales de video disponibles por hardware. Otra de las características de WPF es que puede hostearse indistintamente en una aplicación de escritorio o en un navegador web, aunque para esto último hay que instalar el framework .NET 3.0 en el puesto cliente -y no considerar que la aplicación es web sólo porque el host es un browser-. WPF presenta varios otros beneficios como por ejemplo un sistema de navegación configurable entre pantallas de ingreso de datos y muestra de resultados
    Para cualquier arquitecto interesado en conocerlo más a fondo, hay una clínica de dos horas -a la fecha de escribir esto no tenía costo- disponible acá: https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=109342
    A su vez, si luego de seguir esa clínica, el arquitecto se encuentra motivado como para tener alguna experiencia personal con el uso de WPF, hay un par de laboratorios virtuales -tanto en C# como en VB.NET- de unos 90 minutos cada uno, disponibles acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx. Mi recomendación con los labos, yo estoy haciendo algunos y creo que esto que te voy a decir te puede servir, es que te bajes el manual primero, lo leas bien para entender qué es lo que vas a hacer, y después entres a hacer el labo con la cosa masticada: al principio a mí me preocupaba que se cumplan los 90 minutos y se me cierre la máquina virtual -los labos se hacen con Virtual Server con lo cual en el browser se te abre una sesión remota en un servidor por 90 minutos-. Por esta razón le metía pata a seguir las instrucciones del manual y no estaba dando demasiada bola a lo que iba haciendo (o sea, 90 minutos perdidos, no ganados)
    Para mayores referencias conviene visitar la página de WPF en MSDN: http://msdn2.microsoft.com/en-us/netframework/aa663326.aspx
    También hay algunos webcasts tanto introductorios como más avanzados acá: http://www.microsoft.com/events/series/msdnvista.mspx#WindowsPresentationFoundation
     
  • Windows CardSpace: en la figura 3 aparece como InfoCard dado que ese fue el código interno hasta que se anunció oficialmente que también iba a formar parte de .NET 3.0. CardSpace bien pudo haberse llamado Windows Identity Foundation, para continuar la saga de fundaciones. Esta API, me atrevo a decir, va a dar mucho que hablar, porque va a permitir desacoplar definitivamente el mecanismo de identificación de los usuarios de la aplicación misma (sea ésta web o de escritorio). A ver, hasta donde yo conozco siempre venía ocurriendo que lo deseable era manejar las identidades a través de mecanismo robustos basados en servidores de directorio como IBM Tivoli, Active Directory, u otros. Pero la complejidad de las APIs, cuando disponibles, era tal que finalmente se debía apelar al clásico mecanismo de la "tablita" con usuario y contraseña -y quizás otros datos- para manejar las identificaciones. Esto no solamente duplica esfuerzos sino que, hablando seriamente, estos mecanismos no suelen ser codificados por expertos reconocidos en seguridad, sino por alguien idóneo del equipo de desarrollo. Por esta razón, los riesgos de metidas de pata -cuando no fraudes cometidos ex profeso, atención- son posibles y reales
    Pero encima ahora vamos a un mundo digitalmente integrado donde las aplicaciones consumen servicios de terceros, y nos encontramos con que el usuario no puede estar logueandose de cinco maneras distintas en un mismo caso de uso. Por esta razón han surgido estándares de identidad federada a lo largo de diversas aplicaciones. Qué credencial hay que usar en cada momento? Sirve la contraseña de Windows para identificarme en la web de Blockbuster y alquilar una peli? Y el carnet de Boca para hacer un trámite en la web del consulado de Estados Unidos? (que lleguen a decir que no y les mandamos a Di Zeo) Sirve la tarjeta de crédito para demostrar que uno tiene más de 21 años? Como se puede ver, hay diferentes credenciales para mostrar en diferentes contextos, pero todo para un mundo donde los diferentes contextos se van cruzando y amalgamando
    Windows CardSpace nos va a permitir delegar en el sistema operativo el manejo de esas credenciales en una forma agnóstica del tipo de credencial que estemos usando -incluso si finalmente deseamos darle para adelante con nuestra "tablita"-
    Un labo virtual para conocer Windows CardSpace en acción esta disponible acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx
    Artículos acá: http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx
    Un webcast interesante acá: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032303077&EventCategory=4&culture=en-US&CountryCode=US
     
  • Windows Communication Foundation (WCF): a veces mal llamada "la nueva generación de web services de Microsoft", WCF es muchísimo más que servicios web. En realidad más adecuado sería hablar de "la nueva generación de comunicaciones" porque todo lo que tenga que ver con comunicación en aplicaciones distribuidas, sea mediante servicios web o no, pasa por WCF. La API nos permite fielmente separar la lógica de lo que nuestros componentes distribuidos ofrecen, de los mecanismos para consumirlos. De esta forma sin necesidad de recompilar nada, podemos hacer que un servicio sincrónico pasa a comportarse en forma asíncrona, o bien para algunos consumidores síncrono y para otros asíncrono; podemos también elegir si queremos manejar una instancia única del componente (que por ende no debería manejar estado por sesión), o bien uno por cada sesión, uno por cada requerimiento, e incluso controlar la cantidad de instancias simultáneas acotándola a cierto tope; también manejar las dinámicas conversacionales (one way, full duplex, etc); mecanismos de transporte de los mensajes hacia el servicio (si HTTP, si colas MSMQ, si TCP pelado, si otros… inclusive no necesariamente atado a un único mecanismo); políticas de encriptación (si a nivel de canal con SSL, si a nivel de mensaje con -por ejemplo- WS-*); políticas de distribución de los mensajes (transaccional, una única vez, respetando el orden de emisión de los mismos, etc); estilos de serialización de los mensajes (serialización binaria, POX -plain old XML-, SOAP, etc, incluso más de una según el consumidor). Y, como te contaba, aunque no todas, casi todas estas diferentes conformaciones de tus componentes distribuidos se manejan a nivel de configuración, no a nivel de código -algunas pocas implican tocar los atributos del componente, aunque no su lógica-
    Estos mecanismos son extensibles de modo que puedas agregar los tuyos propios, a la vez que te permiten generar eventos monitoreables o mensajes de excepción (para que se entienda bien: no dije "arrojan alguna clase derivada de System.Exception", dije que entre los mensajes que te podés esperar de un componente, podés recibir un MessageFault, es decir, un modelo similar al de excepciones que lleva el Common Language Runtime, pero llevado al nivel de los servicios y los mensajes
    Finalmente, así como las interfaces de usuario en WPF se podían hostear tanto en una aplicación de escritorio como en un browser, un servicio WCF se puede hostear donde quieras: en un servidor IIS, en un puesto de trabajo, en una aplicación de escritorio, …, donde quieras: WCF viene preparado para dejar los servicios up and running donde vos le pidas (el tema es que pidas donde haya que pedir, claro: no que pidas porque pedir es gratis)
    Hay, nuevamente igual que en el caso de WPF, una clínica para conocer en mejor detalle WCF con demos, preguntas multiple choice de evaluación, etc, acá: https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=109346
    Labos de WCF acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx
    Artículos acá: http://msdn2.microsoft.com/en-us/netframework/aa663324.aspx
    Y finalmente webcasts acá: http://www.microsoft.com/events/series/msdnvista.mspx#WindowsCommunicationFoundation
     
  • Windows Workflow Foundation (WF): los procesos, tanto de negocio como también tecnológicos, siempre han sido modelados de diversas formas. Diagramas de flujo, diagramas de estado, árboles de decisión, y muchos otros. Sin embargo, a la hora de llevar esas ideas a código, amen de alguna que otra herramienta CASE, había que terminar codificando completamente el modelo representado mediante uno o más grafos. WF nos habilita a modelar estos grafos con Visual Studio 2005, generando así una representación XML del mismo donde cada nodo pasa a ser una actividad ejecutada por un proceso (externo o local) y los ejes representan acciones dentro del motor de orquestación
    Esto nos permite pensar nuestras aplicaciones ya desde otro nivel: llevar a la práctica flujos humanos (por ejemplo un esquema de autorizaciones según monto y jerarquía del autorizador, o bien un sistema de administración de contenido, de órdenes de compra, etc); procesos sistémicos (como una transacción que involucre una entidad financiera autorizadora de crédito, un proveedor al que se le está comprando cierta mercadería, un transportista que se va a encargar de llevarla a destino y a la vez sistemas internos de contabilidad que deberan generar los respectivos asientos correspondientes a la transacción); eventualmente máquinas de estado relacionadas con cambios en alguna entidad del modelo de dominio, etc
    La ejecución del workflow para una instancia dada se puede persistir y retomar luego. Por ejemplo, supongamos que el workflow modela la aprobación de una operación por un usuario autorizado, y este usuario no está en línea. Es necesario en ese caso quedarse aguantando el workflow hasta que en algún momento finalmente se conecte? WF se encarga de persistir el estado y recuperarlo más tarde para poder continuar con esa instancia en particular
    Estos workflows también pueden ser encapsulados como unidades transaccionales, habilitando la posibilidad de disparar automaticamente compensaciones en aquellas actividades no preparadas para participar de transacciones, que se habían completado exitosamente
    Los workflows, asimismo, se pueden exponer hacia afuera como servicios web mediante la integración entre WF y WCF. También, al igual que las otras dos fundaciones, los workflows se pueden hostear donde se necesite sin tener que escribir código adicional para habilitar eso
    Una clínica interesante de 2 horas está disponible en https://www.microsoftelearning.com/elearning/offerdetail.aspx?offerpriceid=109340
    Labos acá: http://msdn.microsoft.com/virtuallabs/netframe/default.aspx
    Artículos y otros recursos en esta página: http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx
    Y para terminar, webcasts acá: http://www.microsoft.com/events/series/msdnvista.mspx#WindowsWorkflowFoundation

Como podrás observar, con los recursos que te he dado no necesitás instalar nada en tu equipo para conocer hasta cierto nivel qué es lo que te ofrece .NET 3.0 y cómo se podría monetizar ahí adentro. Un unos posts más adelante te voy a estar contando cómo tenés que hacer para armarte un entorno con Visual Studio 2005 extendido para .NET 3.0 de manera que puedas hacer algunas pruebas de concepto

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

4 respuestas a .NET 3.0: Sí o No?

  1. Juan Pablo dijo:

    Hola, de los 4 componentes de dotnet 3.0 no me cierra InfoCard.
    Creo que WCF + WF es muy útil.
    WPF, será muy popular dentro de poco.
     
    Pero InfoCard……

  2. Diego dijo:

    Qué tal, Jotapé. Gracias por el comment
     
    Mirá, el tiempo dirá. Es válida tu postura aunque yo no me atrevo a decir si va a andar o no. Mirá lo que me pasó: había salido CORBA como un formato neutral de mensajería para objetos distribuidos y dije "uh, esto va a ser un golazo". Y si lo fue, habrá sido gol en contra en todo caso
     
    Después salieron los servicios web y les bajé el pulgar de entrada porque dije "ja! Me quieren hacer comer otro CORBAZO? A papá…!". Pero esta vez, aunque no vamos a exagerar diciendo que son súper masivos, los servicios web son bastante más conocidos, mejor soportados y más disponibles que CORBA
     
    Windows CardSpace? Qué decirte… al que tenga el problema que Windows CardSpace viene a resolver (cómo administrar y usar múltiples mecanismos de identificación según diferentes contextos y basándonos en diferentes autoridades identificatorias) le va a venir al pelo o no según que en la práctica sea fácil de usar, esté bien soportado, etc
     
    Es una apuesta como Windows Vista la es, el formato OpenXML, el Zune y tantas otras jugadas   ;-D

  3. Damian dijo:

    Eso no es nada… jeje, en teoria en diciembre sale Orcas a la calle con el Framework 3.5
    Saludos!
     

  4. Diego dijo:

    Buenas, amigos (especialmente Jotapé que andaba medio escéptico)
     
    Está por salir en MSDN Magazine de Abril un artículo sobre cómo asegurar aplicaciones web ASP.NET y servicios WCF (no necesariamente web, eso está más que claro) poniendo en práctica Windows CardSpace
     
    Helo aquí: http://msdn.microsoft.com/msdnmag/issues/07/04/Identity/default.aspx

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s