CardSpace y SharePoint?

Se puede usar CardSpace y SharePoint? Sí, porque no. Alguien lo ha hecho? No que yo sepa. Me parece improbable que se pueda integrar si se usa AD como medio de autenticación en SharePoint, pero como en MOSS ahora podemos usar otros proveedores, como Windows Forms, me parece que no sea ni siquiera difícil… aunque mi ignorancia es más grande que mi falta de conocimientos…


CardSpace es otra de esas cosas nuevas que Microsoft nos envía para que nos divirtamos (a ratos) y nos desesperemos (en los otros ratos). Más conocido hace algún tiempo como InfoCards, es más o menos la respuesta a una de las más grandes metidas de patas de Microsoft: Passport. Todo empezó, como los buenos cuentos, tratando de solucionar el problema de que cada persona tenia (tiene) para mantener las cientos de claves necesarias para hacer de todo, desde abrir la puerta del baño hasta visitar un sitio web, pasando por el código del banco, la alarma de la casa, encender el computador, bueno, hasta hay por ahí un refrigerador con código anti-glotones para abrir la puerta. Y la idea era: un sitio central en donde estén todas las claves guardadas, y que sea accesible con una sola clave. Brillante. El único problema es que el sitio central era (es) un servidor de Microsoft, la compañía menos confiada en el mundo…


Por supuesto Passport fue (y es) un fiasco de aquí al otro lado, aunque todavía se ve por ahí (han intentado postear algo en los Foros de Microsoft o usar HotMail? Pues necesita usar Passport). Después de 1,35 milisegundos del anuncio de Microsoft en el 2001, algunos (un montón) de sus enemigos (aun mas) se unieron en la «Liberty Alliance» (IBM, Oracle, y una lista interminable) para crear un mejor sistema de autenticación, que, aunque me llamen pesimista, tampoco fue el éxito que los fundadores esperaban. O, puesto con otras palabras, Passport por lo menos de vez en cuando se ve por aquí y por allá, pero alguien ha visto algo asegurado por la «Liberty Alliance» alguna vez? No yo, por lo menos.


Y al fin caemos en el CardSpace, integrado en el DotNet 3.0 y Vista. La idea es la misma, la realización casi igual, con la diferencia que el sitio central para guardar las claves ahora puede ser distribuido entre varios «proveedores», y, lo más importante, proveedores que el usuario puede escoger. La implementación en Vista es bastante elegante: si va a un sitio que acepta CardSpace, Windows lo detecta y muestra una pantalla desde donde se puede escoger la tarjeta a utilizar, o crear una nueva (si tiene un minuto, vea esta demostración que es bastante simpática, y dura un minuto http://channel9.msdn.com/Showpost.aspx?postid=306082).


Y de regreso a SharePoint, es CardSpace un sistema interesante para MOOS? Mi primera impresión es no, no lo es. Simplemente porque SharePoint usado en intranets utiliza siempre (o casi siempre) un sistema empresarial de autenticación (Directorio Activo, Forms Autentication con SQL detrás), que es utilizado para otras muchas cosas al mismo tiempo (piense en Exchange, por ejemplo), así que los usuarios ya tienen un sistema único de identificación. Y además con las posibilidades de Single-Sign On de SharePoint, que permite convertirlo en un punto de entrada y de autenticación para otras aplicaciones, el valor de CardSpace se ve considerablemente reducido. Y para SharePoint como extranet, simplemente no hay necesidad de identificación. Así que yo no le veo muchas perspectivas al asunto, aunque me puedo equivocar…


Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

SharePoint y la LuzPlateada (Silverlight)

Los últimos días no se oye hablar más que de Microsoft Silverlight. Si no me cree, mire el numero de colegas en este sitio que ya han escrito algo al respecto. Si no tiene muchas ganas de buscar, en dos palabras se podría decir que Silverlight es una especie de animación a la Flash o de Ajax fácil de programar. La cuestión que me ocupa en este momento es en qué forma afecta Silverlight a SharePoint.


Desde que se empezó a hablar sobre Ajax, se ha estado experimentando para hacerlo trabajar con SharePoint (en ese entonces la versión 2003). Pero inclusive con MOSS, la implementación es más que difícil, a pesar de que existe un «Tool Kit» (http://www.codeplex.com/sharepointajax) para crear WebParts utilizando Ajax. Microsoft también ha asegurado que con el primer service pack de MOSS, hacia finales del año, algo de integración con Ajax será garantizada. Pero el hecho continúa: a pesar de que todos queremos usar menús más dinámicos en SharePoint, hacer funcionar a Ajax dentro de MOSS significa trabajar horas extras.


Por el otro lado, Flash, aunque es una manera de crear interfaces muy atractivas, tiene enormes problemas para hacerlo interactuar con «el mundo exterior», fuera de que utiliza un lenguaje de programación muy (demasiado) propio. La integración con SharePoint es relativamente fácil, pero por el problema de interacción con datos externos, en realidad nunca ha sido utilizado como una alternativa para la interface de SharePoint.


Por lo que regresamos a la Luz Plateada. Es completamente programable con CSharp (o, si no hay más remedio, con Visual Basic… ups, perdón, estoy creándome enemigos a pasos agigantados), y junto con la nueva moda del XAML y WPF, la separación entre diseño grafico y programación está garantizada. No tiene problemas para «conversar» con el mundo exterior, pues todo funciona bajo la lengua franca de DotNet. Así que, a primera vista, es un medio ideal para SharePoint. Quien se atreverá a hacer menús como en http://silverlight.net/mscom/? (use el menú de la esquina derecha superior), o librerías que utilicen documentos (o videos) como en http://msdn2.microsoft.com/en-us/default.aspx? (tiene que instalar el add-in de Silverlight para poder usar estos sitios).


El problema de Ajax es que es un matrimonio de conveniencia entre obsoleto DHTML, pesado JavaScript y Navegadores malfuncionantes. Lo malo de Flash es que habla su propio idioma, y ese idioma es mudo y sordo. Talvez Silverlight nos muestre la luz…


Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

La metida de pata continuada, o la saga del SDK de SharePoint

Un pajarito me ha traído un regalo la semana pasada: el nuevo SDK de SharePoint, que todavía no está disponible para los simples mortales (las malas lenguas dicen que aparecerá en junio). Así que, fuera de haberle dado una mirada superficial, esta mañana, para solucionar el primer problema de la semana, he sacado a relucir mi nuevo SDK para ver qué me aconseja… Mejor que no lo hubiera hecho…


Nota: para los que no lo han visto, en alguna oportunidad me encontré 8 errores en 15 líneas de código en un ejemplo del SDK)


Veamos: necesito encontrar el valor de un campo de la Base de Datos de Perfiles de MOSS, y quiero usar el WebService «UserProfileService» por aquello de que usar un impersonador nos lo ha hecho tan difícil en el nuevo SharePoint (gracias señores de Microsoft, mientras más difícil me lo hagan, más puedo pedir de aumento de sueldo). El SDK recomienda (véalo en la versión OnLine, si no me cree http://msdn2.microsoft.com/en-us/library/ms550407.aspx):


UserProfileWebService.localhost.PropertyData[] properties = myService.GetUserProfileByName(«domainname\username»);
for (int i = 0; i < properties.Length; i++)
{
    Console.WriteLine(properties[ i ].Name);
    Console.WriteLine(properties[ i ].Value);
}


En donde «UserProfileWebService» es la instancia local del WebService «UserProfileService».


Primero que todo, el WebService no tiene nada que se parezca a «localhost», pero si tiene un «PropertyData», asi que hay algo que sobra…


Luego, el «PropertyData[]» no posee una propiedad «Value»… Afortunadamente hay dos o tres programadores que hacen las cosas bien en Microsoft, y la Intellisense de Visual Studio me dice que la propiedad es «ValueS«, y no es una simple string, sino que es del tipo «ValueData[]».


En resumidas cuentas, el ejemplo debería ser:


UserProfileWebService.PropertyData[ ] properties = myService.GetUserProfileByName(«domainname\username»);
for (int i = 0; i < properties.Length; i++)
{
    Console.WriteLine(properties[ i ].Name);

    UserProfileWebService.ValueData[ ] myValues = properties[ i ].Values;
    for (int a = 0; a < myValues.Length; a++)
    {
        Console.WriteLine(» – » + myValues[ a ].Value);
    }
}


Y aquí se te ocurre la pregunta de paraqué usar un array de valores, si cada propiedad solamente tiene un valor?


Ya se va convirtiendo en costumbre: buscas algo en el SDK de SharePoint, miras con desconfianza, intentas reproducir el ejemplo, no funciona (por supuesto), lo tiras y lo intentas por tu cuenta… hasta que un día bote todo el SDK a un pozo sin fondo, solamente para disfrutar del gozo infinito proporcionado por la liberación de la esclavitud sdkiana (que exagerado…)


Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…