Casi a punto ya de agotar las vacaciones de Semana Santa, he querido escribir este post que ya llevaba tiempo como Draft, espero que sea de utilidad.

  1. ¿Estas intentando trabajar con RIA Services?
  2. ¿Quieres exponer tu servicio RIA a través de un servico web?
  3. ¿SOAP o REST?
  4. ¿Quieres exponer tus datos SQL con EntityFramework  a través de un Servicio Web en cuestion de unos cuantos clicks?

Si estas interesado en conocer las respuestas a estas preguntas este es tu post:

Antes de comenzar asegura que las DLLs instaladas son las adecuadas. Para ello revisa que en la ruta “C:\Program Files (x86)\Microsoft SDKs\RIA Services\v1.0\Libraries\Server” se encuentra el siguiente conjunto de Dlls:

image

De no ser así, sigue lo siguientes pasos hasta conseguirlo. Esto es debido a que los distintos cambios de versiones instaladas sobreescriben a las anteriores y en la mayoria de los casos, verás que sólo existen la dlls “Microsoft.xxx” o las “System.xxx”. ¡Vaya complicación!, de no ser por mi compañero y amigo “David Gonzalez” todavía estaría instalando, ¡Muchas gracias!.

Para evitar todo esto:

Desinstala:

  1. Microsoft Silverlight
  2. Microsoft Silverlight Tools for Visual Studio 2010
  3. Microsoft Silverlight 4 SDK
  4. Microsoft F# Runtime for Silverlight 4
  5. WCF RIA Services v1.0 for Visual Studio 2010
  6. WCF RIA Services Toolkit

Instala en el siguiente orden. Importante tener muy en cuenta las versiones:

  1. Silverlight4_Tools.exe(en Ingles).
  2. RiaServices.msi(RIA Services v1.0 for Visual Studio 2010 – Mayo 2010).
  3. RiaServicesToolkit.msi (Aunque esta disponible la versión de Diciembre, instala la versión de Mayo 2010 con objeto de que sea compatible con RiaServices puesto que de este aun no está disponible una versión más actualizada.

Ahora el Visual Studio está listo para comenzar.

Importante: Desde Abril de 2011 ya está disponible la nueva versión de “WCF RIA Services ToolKit” que es compatible con la versión de Mayo de 2010 y por tanto podemos evitar la ardua tarea anterior, adicionalmente, tambien está disponible WCF RIA Services v1.0 SP1, con lo que tenemos todo al completo.

Ahora ya podemos comenzar a crear nuestro servico RIA:

Para exponer un servicio como RIA, añadiremos un nuevo item de tipo “Domain Service Class” a nuestro proyecto Web.

NOTA: No neceariamente tiene que ser un proyecto web, pero si pretendes sacarle partico al servicio y no solo para el acceso desde SilverLigth o LigthSwitch, entonces utiliza un servicio web como “Best Practice”:

image

Una vez incluido este nuevo item, veremos que en el “web.config” se ha añadido lo siguiente:

<domainServices>
  <endpoints>
    <add name="OData" type="System.ServiceModel.DomainServices.Hosting.ODataEndpointFactory, System.ServiceModel.DomainServices.Hosting.OData, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </endpoints>
</domainServices>

Ahora nuestro servicio (REST) ya está listo para ser consultado como si de un Atom, RSS, etc se tratara, eso sí, no existe ningún servicio “*.svc” físicamente, sin embargo se autogenera un “.svc” de la siguente manera:

Formato de la url dinámica: <a href="http://localhost:%5BPuerto%5D/-.svc/OData/”>-.svc/OData/”>http://localhost:%5BPuerto%5D/<namespace>-<DomainServiceName>.svc/OData/

Ejemplo:  <a href="http://localhost:/WcfService1-DomainService1.svc/ODATA/”>/WcfService1-DomainService1.svc/ODATA/”>http://localhost:<Puerto>/WcfService1-DomainService1.svc/ODATA/

Una vez que ya tenemos este servicio, ¿Porqué no utilizarlo como SOAP o incluso como JSON?, para ello bastará con incluir las siguientes dos líneas/endpoints  en la sección <domainServices> <endpoints>.

<add name="soap" type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /><add name="json" type="Microsoft.ServiceModel.DomainServices.Hosting.JsonEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

Ahora tendremos tres url distintas para el acceso a cada uno de estos distintos endpoints:

  1. ODATA: <a href="http://localhost:%5BPuerto%5D/-.svc/OData/”>-.svc/OData/”>http://localhost:%5BPuerto%5D/<namespace>-<DomainServiceName>.svc/OData/
  2. SOAP: <a href="http://localhost:%5BPuerto%5D/-.svc”>-.svc”>http://localhost:%5BPuerto%5D/<namespace>-<DomainServiceName>.svc
  3. JSON:<a href="http://localhost:%5BPuerto%5D/-.svc/json/GetProducts/”>-.svc/json/GetProducts/”&gt; http://localhost:%5BPuerto%5D/<namespace>-<DomainServiceName&gt;.svc/json/GetProducts/
  • Para probar el punto (1) podemos utilizar la herramienta “OData Explorer” o incluso con el Propio Exel (su extension PowerPivot Excel 2010)
  • Para el  punto (2) podemos añadir una referencia web a uno de nuestros proyectos y consumirlo desde .NET como cualquier otro endponit WCF, es decir, se generará el Proxy correspondiente.
  • Y, para el punto (3), podemos utilizar el “JSON Explorer”. Para ello accedemos a la url correspondiente sin el último backslash (“/”) desde Internet Explorer y abrimos el fichero generado con notepad.  Copiamos el contenido en el “Source” de esta pequeña herramienta y, aquí estan los datos:

image

Ahora sí, nuestros endpoints estarán listos para comenzar a ser usados.

Uso desde Ligthswitch.

Para que todos estos EndPoint funcionen correctamente es necesario que nuestra clase de Dominio contenga el atributo de clase “[EnableClientAccess()]”, sin embargo “VS Ligthswitch” recomienda el uso de este atributo y por tanto mostrará el siguiente mensaje: “This data source will be publicly accessible from outside your application.  It is recommended that EnableClientAccess is disabled on the WCF RIA Service.

image

En cualquier caso siempre podremos continuar.

Nada más por el momento, espero haber aclarado algunos temas.  Si quieres conocer más detalle y ver ejemplos sobre su consumo, echa un vistazo a este enlace: WCF RIA Services Part 10 – Exposing Domain Services To Other Clients.

Saludos @Higuera la Real
Juanlu