Ask a questionAsk a question
 

AnswerWWSAPI service for Silverlight clients

  • Tuesday, October 27, 2009 5:22 AMCary Li Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi,

    To allow Silverlight clients to call into a self hosted WCF service cross domain, I implemented a custom IPolilcyRetriever interface that provides the "clientaccesspolicy.xml" file through a WebServiceHost.

            [OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")]
            Stream GetSilverlightPolicy();

    Now I'm trying to convert my self hosted WCF service into WWSAPI, however, I'm experiencing some problems in exposing this interface through web model.

    I'm just wondering, is there a way to do this in WWSAPI?

    Thanks a lot.

    Regards,
    Cary

Answers

  • Wednesday, October 28, 2009 5:15 PMHao Xu [MSFT]ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Cary,

    Thanks for explaining the scenario. WWSAPI does not provide first-class support for that. The scenario you described (serving one XML file through GET request) can actually be achieved using our metadata support (specifically, WS_METADATA_EXCHANGE_TYPE_HTTP_GET explained in http://msdn.microsoft.com/en-us/library/dd815331(VS.85).aspx), but I would not recommend you to go that direction unless you have exhausted all other options (e.g. staying with WCF on the server side).

    Also, thanks for reading my blog. I'd appreciate your comments.

    Hao

All Replies

  • Tuesday, October 27, 2009 4:19 PMHao Xu [MSFT]ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    It sounds like that you are trying to implement a REST-style web service, which the current WWSAPI release does not have much support for. If you can provide more details, we could see if there is a way to achieve that with the current feature set.

  • Wednesday, October 28, 2009 12:35 AMCary Li Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hao, your "Lost in history" blog is great.

    Yes, serving the "clientaccesspolicy.xml" is REST-style using HTTP GET. The whole purpose is to feed the policy to Silverlight client so it can consume my other SOAP services.

    On the client: a Silverlight XAP file is delivered as part of the product, when it's called up, it would try to consume to a web service on the server which sits in a different node. Because the XAP file is local, and the service is in another machine, the Silverlight runtime tries to download the security policy file with a name of "clientaccesspolicy.xml" at the root of the requested target domain using the HTTP protocol.

    On the server: IIS is NOT installed, and the service is self hosted in an EXE, written in native code.

    for example, if my service endpoint is
         "http://SERVER1:9394/IMyService"

    As soon as Silverlight client connects in, it would try to get the "clientaccesspolicy.xml" file using this address:
         "http://SERVER1:9394/clientaccesspolicy.xml"

    This could be done on the server using WCF, by implementing a custom IPolicyRetriever interface and use WebServiceHost class to add web programming model so it can feed the file when requested by HTTP GET.
            [OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")]
            Stream GetSilverlightPolicy();

    I'm currently exploring the possibility to replace WCF with WWSAPI, and seem to have a bit of trouble serving the policy file.

    Thanks for looking into this.

    Regards,
    Cary
  • Wednesday, October 28, 2009 5:15 PMHao Xu [MSFT]ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Cary,

    Thanks for explaining the scenario. WWSAPI does not provide first-class support for that. The scenario you described (serving one XML file through GET request) can actually be achieved using our metadata support (specifically, WS_METADATA_EXCHANGE_TYPE_HTTP_GET explained in http://msdn.microsoft.com/en-us/library/dd815331(VS.85).aspx), but I would not recommend you to go that direction unless you have exhausted all other options (e.g. staying with WCF on the server side).

    Also, thanks for reading my blog. I'd appreciate your comments.

    Hao