Como se sentiría SharePoint en el Astoria?

Y no me refiero al Hotel Waldorf-Astoria, sino al proyecto “Codename Astoria” de Microsoft.

Se puede decir mucho sobre Microsoft, pero no se puede decir que se duermen sobre sus laureles. Constantemente están investigando nuevas cosas, y buscando nuevas soluciones, a veces para problemas inexistentes, pero hay que admitir (y de pronto admirar) la capacidad que la empresa tiene para tirar pa’lante.

El proyecto “Astoria” no es nuevo (desde hace unos seis meses es públicamente conocido), pero si es innovativo. Se trata de (traducido de la información de Microsoft sin su permiso) “permitir que aplicaciones expongan datos como un servicio de datos que pueden ser consumidos por clientes Web dentro de una intranet y/o a través de internet. El servicio de datos utiliza consultas HTTP, y operaciones HTTP estándar como GET, POST, PUT y DELETE para hacer operaciones dentro del servicio.”

Para los interesados, todo el software necesario se puede bajar desde el sitio de Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyId=1B6F85BC-8933-4D0E-A639-934EF85ADCE1&displaylang=en) y hay un sitio con información y ejemplos en http://astoria.mslivelabs.com/Default.aspx.

Si se desean leer toda la información les deseo muy buena suerte. Si no lo desean, de lo que se trata es de los siguiente: programamos una aplicación Web que utiliza el FrameWork de Astoria; detrás de ella hay una Base de Datos (o cualquier otro proveer de datos) que le entrega dinámicamente lo que se necesita mostrar; cómo mostrar estos datos no tiene importancia para Astoria (Ajax, SilverLight, HTML, lo que se les ocurra), todo el asunto se trata de bajar y subir datos. Desde el URL de la aplicación, usando uno de los ejemplos de Microsoft, si se quieren ver los usuarios en la tabla “Customers”, se puede hacer una llamada directamente a la Base de Datos de la forma:

http://myserver/data.svc/Customers

La respuesta del servidor es en forma de XML, más o menos en la forma:

<DataService xml:base=http://myserver/data.svc>

<Customers>

<Customer uri=Customers[ALFKI]”>

…

</Custormers>

<DataService>

y si se quieren ver los datos de un solo usuario:

http://myserver/data.svc/Customer[ALFKI]

De la misma manera, para ver los pedidos del usuario, almacenados en otra tabla relacionada, el URL será:

http://myserver/data.svc/Customer[ALFKI]/Orders

Y si lo que se quiere es parametrizar la consulta para ver solo los pedidos activos, será:

http://myserver/data.svc/Customer[ALFKI]/Orders[Active eq true]

y para ordenar los resultados se puede hacer:

http://myserver/data.svc/Customer[ALFKI]/Orders[Active eq true]?$orderby=OrderDate

Ya van cogiendo la idea… Ahora imagínense que la aplicación Web crea una grilla con todos los usuarios, cada uno con un vínculo con su propio URL creado dinámicamente para hacer un Drill-Down, y la cosa va tomando forma. Y si piensan que Astoria no solo se puede utilizar para bajar datos, sino también para modificarlos, es asunto se va poniendo más interesante… y peligroso…

Hay que recalcar aquí que Astoria está en una fase muy inicial, así que hay que verlo por el momento como un experimento que tal vez en algún momento veremos aplicado en la realidad. Y, por supuesto, si alguien lo quiere utilizar para código de producción, buena suerte, y que todos los Dioses le acompañen…

Pero bueno, la cosa es cómo podríamos utilizar algo así con SharePoint… que les parece si tenemos una Librería de Documentos en un sitio de SharePoint. Librerías (y Listas) las podríamos considerar como una tabla de una Base de Datos (de una u otra forma lo es), así que podríamos ver traer todos los documentos por medio de un URL:

http://myserver/data.svc/mysitio/mylibreria

y ver los metadatos de un documento en particular con un URL de la forma:

http://myserver/data.svc/mysitio/mylibreria[mydocumento]

o los documentos que se subieron hoy:

http://myserver/data.svc/mysitio/mylibreria[Date eq DateTime.Today]

Nuestra aplicación Web se tiene que encargar de mostrar los datos de una forma consecuente (de nuevo, se trata de tráfico de datos, no de presentación de ellos) y de una forma similar se podrían editar o eliminar elementos de la Lista o Librería.

Que opinan? De una u otra forma, ya tenemos diferentes mecanismos para hacer lo mismo, desde el muy sencillo QueryString hasta el viejo y confiable sistema de SOAP WebServices. Ganamos algo? Mejoramos algo? Lo empeoramos? Que piensan al respecto…

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

5 comentarios sobre “Como se sentiría SharePoint en el Astoria?”

Abstracción

Esa palabra es la clave de todo esto. La abstracción es ignorancia selectiva y es lo que nos va a permitir acceder a N proveedores de datos diferentes de manera única (mediante URL, tal cual has indicado para BD relacional y para Sharepoint).

Saludos

Responder

Pienso que sería relativamente fácil implementarlo para Sharepoint de la forma que comenta Gustavo. Es cierto que sería otra manera más de hacer lo mismo que hacemos con los webservices de Sharepoint, pero sería interesante en la misma medida en la que se haga interesante Astoria.

Si algún grupo de aplicaciones empresariales nuestras del futuro comienzan a utilizar Astoria como capa de acceso a datos o como herramienta para la capa de acceso a datos, ya podrían contar entonces con acceso directo a Sharepoint sin prácticamente esfuerzo extra, sin añadir código para los webservices, ni código que acceda al modelo de objetos, algo que es un requerimiento en algunas soluciones.

Ahora bien, «exportar una base de datos por HTTP» es muy similar desde cierto punto de vista a exportarla mediante métodos básicos de webservices; y con esto me refiero a algo así como un webservice con un método «executeSQL». Esta forma de uso de un webservice es criticada por Paul Ballard en su artículo Top 5 Web Service Mistakes donde el cuarto es Using Web Services for Data Access, donde de hecho critica a Microsoft por la característica en SQL Server de publicar un procedimiento almacenado directamente por webservice. Esto está mejor conceptualizado en SQL Server 2005 que en 2000 (en 2000 era con unas extensiones) ya que existe nativamente el concepto de EndPoint, que sería HTTP End Points para los webservices pero no obstante Ballard menciona al respecto que «This makes for great demos but bad application design». Muy bonito es el ejemplo que pone de que el webservice de Google no exporta simplemente los datos de los millones de sitios que tiene indexado, sino que exporta la forma en que busca, la funcionalidad de su maquinaria de búsquedas. De todas formas es una de las tantas herramientas que tenemos a mano, aunque no sea ideal para todas las aplicaciones.

Sin embargo, el caso de Astoria no puede verse fuera de su contexto. Puedo estar equivocado pero, a pesar de la similitud con la exportación por webservices, Astoria puede ser enfocado como una apuesta por el acceso a datos desde «la nueva ola de aplicaciones construida sobre tecnologías como AJAX y Microsoft Silverlight». Acabo de enterarme de Astoria, así que hasta el momento lo veo como una posibilidad no establecida; eso sí parece ser bastante práctica, nuestra comunidad de Sharepoint podría muy bien disfrutarla, recuerden que la sencillez es amiga de las buenas soluciones.

Responder

Hola,

Soy Consultora de selección y actualmente llevo una busqueda de un PFE de SharePoint para Microsoft Ibérica, despues de varios dias de publicación me ha resultado muy complicado encontrar profesionales altamente cualificados, en vista de eso y tomando en cuenta el tema del foro me he permitido la libertad de escribir este mensaje a fin de que si algun profesional le parece interesante la oferta se comunique conmigo.

v-cadean@microsoft.com

Responder