Durante el último PDC Microsoft mostró el camino que iba a seguir la plataforma Azure respecto a SDS (SQL Data Services). El camino a seguir, que creemos el más adecuado, es el de exponer el protocolo actual de SQL Server, el TDS, dentro de la plataforma. De esta forma será posible hacer un uso de SDS mucho más amplio que actualmente. El acceso actualmente se realiza mediante un interfaz REST que para los que no lo conozcan es un estilo, un tipo de arquitectura, que nos permite acceder a recursos mediante transferencia de estados (REST à REpresentational State Transfer). ¿Cuál es el motivo para utilizar REST en vez de los más extendidos WebServices? Pues su sencillez de integración. Para obtener un recurso mediante REST podemos hacerlo directamente con una petición HTTP a una URL como si de un recurso más dentro de la web se tratara. Por ejemplo si dispusiéramos de SDS con REST en nuestros servidores podríamos configurar que http://www.solidq.com/mentors/rgarrigos nos devolviera un documento XML como respuesta con la entidad correspondiente con mis datos.

Microsoft ha comunicado que, debido a que ha recibido muchas peticiones de acceso relacional a SDS, implementará TDS para permitir lanzar queries, tener procedimientos almacenados, etc. en la nube. Lo que nos preocupa es que va a dificultar el acceso mediante REST en cuanto publique el interfaz TDS. Esto tendrá un grandísimo impacto en los early adopters de esta tecnología. Creemos que en este punto Microsoft no está actuando muy éticamente pues, aunque añadir TDS estaba en los planes de evolución del producto, no lo estaba cambiar las reglas de un día para otro. Debemos tener en cuenta que el uso de REST facilita mucho el acceso a datos en la nube a plataformas web “no Microsoft” como LAMP (Linux + Apache + MySQL + PHP/Perl/Python). Con el uso de un protocolo TDS complicas bastante la vida en entornos donde un cliente TDS no se encuentra fácilmente y menos seguramente adaptados para SDS y la nube (probablemente el encapsulado del protocolo será diferente, no creemos que sean tramas TDS a pelo sobre TCP/IP, etc.). ¿Qué solución propone Microsoft a quienes quieran seguir utilizando REST? Pues nada más y nada menos que se monten sus servicios personalizados, a mano, con ADO.NET Data Services que por detrás accedan vía TDS.

En conclusión, Microsoft avanza hacia un uso flexible de los servicios de datos en la nube aunque ello implique nuevas inversiones a los early adopters para seguir utilizando esta tecnología. Creemos que debería haberse flexibilizado la situación congelando el estado actual del interfaz REST de forma que los actuales clientes no tuvieran acceso a las nuevas funcionalidades mediante éste, pero tampoco se les imposibilitara seguir haciendo el uso actual de la plataforma de forma tan tajante mediante su actual interfaz. En todo caso, la versión oficial de SDS con TDS aún no está publicada, quizás para entonces las coses cambien a mejor

0 Shares:
Deja una respuesta

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

You May Also Like
Leer más

Azure Stream Analytics serie. Parte 1: Uso e implementación de funciones en JavaScript en un job de ASA

En esta serie de posts vamos a comentar diferentes aspectos de Azure Stream Analytics (ASA de ahora en adelante), que pueden resultarnos útiles en nuestros desarrollos del día a día. Sino conoces Azure Stream Analytics puedes ver una introducción en este enlace. Parte 1: Uso e implementación de funciones en JavaScript en un job de ASA