Servicios de datos de WCF

WCF Data Services (anteriormente ADO.NET Data Services , ^{[ 1 ]} nombre en clave "Astoria" ^{[ 2 ]} ) es una plataforma para lo que Microsoft llama Data Services . En realidad, es una combinación del entorno de ejecución y un servicio web a través del cual se exponen los servicios. También incluye Data Services Toolkit , que permite crear Astoria Data Services desde dentro del propio ASP.NET . El proyecto Astoria se anunció en MIX 2007, y la primera vista previa para desarrolladores estuvo disponible el 30 de abril de 2007. La primera CTP estuvo disponible como parte de ASP.NET 3.5 Extensions Preview. La versión final se lanzó como parte del Service Pack 1 de .NET Framework 3.5 el 11 de agosto de 2008. El cambio de nombre de ADO.NET Data Services a WCF Data Services se anunció en la PDC 2009 .

WCF Data Services expone datos, representados como objetos del Modelo de Datos de Entidad (EDM), a través de servicios web accesibles mediante HTTP . Los datos se pueden direccionar utilizando una URI similar a REST . Al acceder al servicio de datos mediante el método HTTP GET con dicha URI, se devolverán los datos. El servicio web se puede configurar para devolver los datos en XML simple , JSON o RDF+XML . En la versión inicial, no se admiten formatos como RSS y ATOM , aunque podrían admitirse en el futuro. Además, mediante otros métodos HTTP como PUT, POST o DELETE, también se pueden actualizar los datos. POST se puede usar para crear nuevas entidades, PUT para actualizar una entidad y DELETE para eliminar una entidad.

Windows Communication Foundation (WCF) nos ofrece la solución cuando no podemos lograr nuestros objetivos mediante servicios web, como la compatibilidad con otros protocolos e incluso la comunicación bidireccional. Con WCF, podemos definir nuestro servicio una sola vez y configurarlo para que se pueda usar a través de HTTP, TCP, IPC e incluso colas de mensajes. Podemos consumir servicios web mediante scripts del lado del servidor (ASP.NET), JSON (JavaScript Object Notation) e incluso REST (Representational State Transfer).

Comprender los conceptos básicos

Cuando decimos que un servicio WCF puede usarse para comunicarse mediante diferentes protocolos y desde diferentes tipos de aplicaciones, necesitamos comprender cómo podemos lograrlo. Si queremos usar un servicio WCF desde una aplicación, entonces tenemos tres preguntas principales:

1. ¿ Dónde se ubica el servicio WCF desde la perspectiva del cliente? 2. ¿Cómo puede un cliente acceder al servicio, es decir, qué protocolos y formatos de mensajes utiliza? 3. ¿Qué funcionalidades ofrece el servicio a los clientes?

Una vez que tengamos la respuesta a estas tres preguntas, crear y consumir el servicio WCF será mucho más fácil. El servicio WCF se basa en el concepto de puntos finales. Un servicio WCF proporciona puntos finales que las aplicaciones cliente pueden usar para comunicarse con él. La respuesta a estas preguntas constituye lo que se conoce como el ABC de los servicios WCF y, de hecho, son los componentes principales de un servicio WCF. Así que abordemos cada pregunta una por una.

Dirección: Al igual que un servicio web, un servicio WCF también proporciona una URI que los clientes pueden usar para acceder a él. Esta URI se denomina dirección del servicio WCF. Esto nos resuelve el primer problema: "¿Dónde se encuentra el servicio WCF?".

Enlace: Una vez localizado el servicio WCF, debemos considerar cómo comunicarnos con él (en términos de protocolo). El enlace define cómo el servicio WCF gestiona la comunicación. También puede definir otros parámetros de comunicación, como la codificación de mensajes, etc. Esto resolverá el segundo problema: "¿Cómo comunicarnos con el servicio WCF?".

Contrato: Ahora la única pregunta que queda es sobre las funcionalidades que proporciona un servicio WCF. El contrato define los datos públicos y las interfaces que el servicio WCF ofrece a los clientes.

Las URI que representan los datos contendrán la ubicación física del servicio, así como el nombre del servicio. También deberá especificar un EDM Entity-Set o una instancia de entidad específica, como en respectivamente

http://dataserver/service.svc/MusicCollection

o

http://dataserver/service.svc/MusicCollection[SomeArtist]

La primera listará todas las entidades del conjunto Collection , mientras que la segunda listará solo la entidad indexada por SomeArtist .

Las URI también pueden especificar un recorrido de una relación en el modelo de datos de entidad. Por ejemplo,

http://dataserver/service.svc/MusicCollection[SomeSong]/Genre

recorre la relación Género (en la jerga SQL, se une con la tabla Género ) y recupera todas las instancias de Género que están asociadas con la entidad AlgunaCanción . También se pueden especificar predicados simples en la URI, como

http://dataserver/service.svc/MusicCollection[SomeArtist]/ReleaseDate[Year eq 2006]

recuperará los elementos que están indexados por SomeArtist y que fueron lanzados en 2006. La información de filtrado y partición también se puede codificar en la URL como

http://dataserver/service.svc/MusicCollection?$orderby=ReleaseDate&$skip=100&$top=50

Aunque la presencia de las palabras clave skip y top indica compatibilidad con paginación, en Data Services versión 1 no existe un método para determinar el número de registros disponibles y, por lo tanto, es imposible determinar cuántas páginas puede haber. La especificación OData 2.0 añade compatibilidad con el segmento de ruta $count (para devolver solo un recuento de entidades) y $inlineCount (para recuperar una página de entidades y un recuento total sin un viaje de ida y vuelta separado...). ^{[ 3 ]}

• Marco de servicios de datos ADO.NET (anteriormente "Proyecto Astoria")
• Uso de los servicios de datos ADO.NET de Microsoft
• Vista previa de las extensiones de ASP.NET 3.5
• Blog del equipo de ADO.NET Data Services (Proyecto Astoria)
• Acceda a los datos en la nube con Astoria: Noticias de otorrinolaringología en línea