(X) Hide this
    • Login
    • Join
      • Say No Bots Generate New Image
        By clicking 'Register' you accept the terms of use .

WCF RIA Services Part 10 - Exposing Domain Services To Other Clients

(8 votes)
Brian Noyes
>
Brian Noyes
Joined Jun 10, 2010
Articles:   19
Comments:   117
More Articles
29 comments   /   posted on Jan 03, 2011
Categories:   Data Access , Line-of-Business

This article is the tenth and final part of the series WCF RIA Services.

Introduction

As mentioned in Part 1 of this article series, WCF RIA Services only supports code generating the client proxy code in Silverlight projects. However, that does not mean you cannot call your domain services from other clients. If I were not going to have a Silverlight client application as my primary client application, I would not bother defining my services as domain services. I would instead define normal WCF services or possibly WCF Data Services. To me, most of the benefit of WCF RIA Services is in the code generated client proxy code and client side framework. The validation support, the security model, the service error handling, and the deferred query execution are the things I think are most compelling about using RIA Services.

But If I do have a Silverlight client and use RIA Services, I probably don't want to have to implement a separate set of services for my non-Silverlight clients. The good news is, you don't have to. It is easy to expose additional endpoints from your domain services that can be consumed by other clients. In this article, I'll show you how to enable those endpoints, and will show what is involved in consuming your RIA domain services from non-Silverlight clients. Your options include exposing a read-only OData service endpoint, a full functionality SOAP endpoint compatible with the basicHttpBinding in WCF, or a full functionality REST JSON encoded endpoint.

You can download the source code for this article here.

Exposing an OData Endpoint From Your Domain Service

OData is short for the Open Data Protocol. It is a REST-based web service protocol for exposing data for querying via web services, and optionally allowing updates via that web service as well. You can read up on OData at http://www.odata.org/. OData uses the ATOM protocol for encoding the data in the HTTP body of the REST messages that flow from and to your service. OData allows you to express a complex query through parameters in the URL that is used to address the service. OData supports a subset of the common LINQ query operations such as filtering (the Where operation in LINQ), projection (the Select operation in LINQ), and paging (Take and Skip operations in LINQ). Additionally, the OData protocol allows you to send inserts, updates, and deletes for an exposed entity collection if the service allows it.

RIA Services allows you to expose a query-only OData endpoint (no updates) from your domain services. The exposed feed only allows you to retrieve the entire collection exposed by a query method. You cannot pass query filters or paging operations down to the service through the OData protocol, so the functionality is fairly limited at the current time. In a future release of WCF RIA Services they will probably support updates and more complex query operations, but for now you can basically just call your domain service query methods and return the collection that the server method returns without being able to filter from the client side.

This capability is part of the core WCF RIA Services libraries. All you need to do is remember to check the box when you first create your domain service as shown in the following figure.

Add Domain Service

If you forgot to do that when you created the domain service, don’t fret. You can always add a new domain service to the project and check the box for that domain service, and then delete that domain service. Checking the box adds a sectionGroup to your config file, adds a new domainServices section to the system.serviceModel part of your config file, and adds another reference to the project to the System.ServiceModel.DomainServices.Hosting.OData.dll library. Additionally, the [Query] attribute is added to each of the entity query methods added by the wizard. If you forget to check the box, you will need to add those attributes yourself as well.

 [Query(IsDefault=true)]
 public IQueryable<Task> GetTasks()
 { ... }
  
 [Query(IsDefault = true)]
 public IQueryable<TimeEntry> GetTimeEntries()
 { ... }
  
 [Query(IsDefault = true)]
 public IQueryable<Customer> GetCustomers()
 { ... }

The sectionGroup it adds to the config file looks like this:

 <system.serviceModel>
   <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>
   ...
 </system.serviceModel>

This endpoint does have metadata turned on, so clients can easily generate client proxy code from the endpoint like they would from any other WCF service. The address that this endpoint is exposed on is just the base domain service address (hosted server address + fully qualified domain service class name with dots replaced by dashes + .svc) with /odata appended to it.

Consuming the OData Endpoint From a .NET Client

What if you want to consume that OData feed? There are a variety of tools out there that can consume OData feeds, including the OData Explorer, a plug in for Excel, and other tools. If you want to consume that data by querying it via services from another .NET client, it is very easy because Visual Studio can generate a client proxy for you in any .NET project. There is also a command line tool called DataSvcUtil.exe that can do the same client code generation, making it easy to consume the feed.

To demonstrate this, I can add a WPF Application project to the solution. I then select Add Service Reference from that project and enter the address to the odata feed:

http://localhost:11557/TaskManager-Web-TasksDomainService.svc/odata

You should see that the service is found, and you will see a collection set for each of your entities that you have the [Query(IsDefault=true)] attribute on:

Add Service Ref OData

After you click OK, a client proxy will be generated. The generated OData proxy is quite different than a normal WCF service proxy. Instead of exposing methods that you call on the service, it exposes the entity sets. With normal OData services, you can form LINQ queries on those entity sets, and when you iterate over that expression (or call ToList or Count or other LINQ operators that do not defer execution), they will actually execute on the server side. The OData proxy sends the query expression tree to the server in a similar way to how WCF RIA Services does, by forming a query string from the expression tree of the LINQ expression as I explained in Part 3.

Unfortunately, the RIA Services implementation only allows you to ask for the entire entity set via OData. If you try to use other LINQ expressions such as Where or Take, you will get an error back that says “Query options are not allowed.” However, you can use the OData feed to retrieve all the entities exposed by a domain service query method.

For example, I could execute the following code in the WPF client:

 Uri serviceUri = new Uri("http://localhost:58041/TaskManager-Web-TasksDomainService.svc/odata");
 TasksDomainService proxy = new TasksDomainService(serviceUri);
 List<Task> tasksBefore2Jun = proxy.TaskSet.ToList();

This would return the whole list of Tasks from the server, and then the client could present that data. However, if it allowed the user to edit the data, there would be no way to send the changes back to the server via the OData endpoint. Notice that the way the proxy works is by exposing entity sets as a property on the proxy itself. Also notice that the proxy requires a URL to the service on construction. There is no contract or binding associated with an OData proxy and you pass the address in through the constructor, so there is no need for client configuration of the proxy either.

Exposing a SOAP Endpoint From Your Domain Service

If you want to be able to execute your query and update methods from other clients, then you can use the SOAP or JSON endpoints that can also be enabled on your domain service. These require that you download and install the RIA Services Toolkit in addition to having the core RIA Services functionality that you get through the Silverlight 4 Tools for Visual Studio 2010.

The SOAP endpoint is a WCF basicHttpBinding compatible endpoint that can be easily consumed by just about any platform that speaks SOAP. To add the SOAP endpoint, you just add another endpoint in the domainServices section in your config, in the same place as the OData endpoint shown earlier. It looks like this:

 <system.serviceModel>
   <domainServices>
     <endpoints>
       <add name="soap"
            type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory, 
                  Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, 
                  Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
       ...
     </endpoints>
   </domainServices>
   ...
 </system.serviceModel>

You will also need to add a reference in the web host to Microsoft.ServiceModel.DomainServices.Host, which is where the SoapXmlEndpointFactory type is defined as you can see from the config code above.

That endpoint does have metadata turned on, so clients can easily generate client proxy code from the endpoint like they would from any other WCF service. The address that this endpoint is exposed on is just the base domain service address with /soap appended to it.

Consuming the SOAP Endpoint From a .NET Client

To consume the SOAP Endpoint, you just do a normal Add Service Reference in the client project, or use svcutil.exe, or hand-code a proxy class using the ClientBase<T> base class. Using Add Service Reference is the easiest if you are new to WCF Services.

To add a service reference to the SOAP endpoint, just point Add Service Reference or svcutil.exe to the default address of your domain service, http://localhost:58041/TaskManager-Web-TasksDomainService.svc for the sample application. That will generate the compatible proxy and configuration code for the client.

Then you could write client code like the following to retrieve the Tasks collection and make an update to one of the tasks and send it back to the service to persist the change:

 TasksDomainServicesoapClient proxy = new TasksDomainServicesoapClient();
 // Retrieve the full collection, 
 // no ability to filter server side unless additional methods exposed
 QueryResultOfTask result = proxy.GetTasks();
 Task[] tasks = result.RootResults; // Extract the real collection from the wrapper
  
 // Make a modification
 tasks[0].TaskName = "Modified by SOAP Client";
  
 // Wrap it in ChangeSetEntry
 ChangeSetEntry changeEntry = new ChangeSetEntry();
 changeEntry.Entity = tasks[0];
 changeEntry.Operation = DomainOperation.Update;
   
 // Send the changes back to the server as an array of ChangeSetEntries
 proxy.SubmitChanges(new ChangeSetEntry[] { changeEntry });
 Task[] newFetchTasks = proxy.GetTasks().RootResults;
   
 proxy.Close();

Most of the complexity in dealing with the SOAP endpoint is in wrapping up changes in the ChangeSetEntries. That type supports sending the original entity and the modified entry back as well for optimistic concurrency checking or so that the server side can optimize the query by knowing which properties have actually changed on the object. Other than the wrapping of the entities, this is just normal WCF proxy-based service calls.

In the sample code for this article, I turned off security to keep things focused on the basic mechanisms of exposing the endpoints and calling them. To secure the endpoints, you would again just leave the [RequiresAuthentication] attribute on the domain service and add an AuthenticationDomainService as discussed in Part 7. On the client side, you would need to make a call to the authentication domain service first to establish a login session. You would also need to enable a cookie container on the proxy for both the authentication domain service endpoint and the other domain services you want to call. Finally, you would need to copy the cookie container from the authentication service proxy to the other proxies after logging in. For a great walkthrough on this in the context of a Windows Phone 7 client, see this blog post by Marcel de Vries.

Exposing a REST/JSON Endpoint

Exposing a REST/JSON style endpoint from your domain service that functions just like the SOAP one just described, it is just another endpoint declaration in your configuration file.

 <add name="JSON"
      type="Microsoft.ServiceModel.DomainServices.Hosting.JsonEndpointFactory, 

 Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, 
 Culture=neutral, PublicKeyToken=31bf3856ad364e35"
 />

You can then use your favorite approach such as a WebClient or HttpWebRequest in .NET to issue the HTTP request to the REST endpoint, and can use something like the WCF DataContractJsonSerializer to decode and encode the JSON payload in the HTTP body of the message. The address scheme is based on the addressing scheme of WCF service methods that you expose via REST. For example, to call the GetTasks method, you would just address http://localhost:58041/TaskManager-Web-TasksDomainService.svc/json/GetTasks.

Summary

As you can see, it is a fairly simple matter to expose the additional endpoints for OData, SOAP, and REST/JSON from your domain services. Because of the limitations on the OData endpoint in the current release, I find that one to be the least useful. However, the SOAP and REST endpoints do make it fairly easy to consume your domain services from other platforms. If I needed to provide CRUD services for a set of entities and needed to write client applications on multiple platforms with the full set of functionality, and wanted to make it as easy as possible for others to write clients for my services, I would not use WCF Data Services for that. I would use either WCF Data Services to expose a fully functional OData endpoint, or I would write normal WCF Services where I was not constrained by the server side model of WCF Data Services. However, if I was writing a complex Silverlight application that was the primary client application, and just wanted to be able to expose some of the same entity CRUD functionality to other clients without needing to write separate services for them or give up the client side benefits of WCF RIA Services for my Silverlight client, then these additional endpoints are just what is needed.

So that brings me to the end of this series on WCF Data Services. And I happen to be writing this on New Years Eve (day) of 2010, so it happens to also be the end of a year and end of a decade as well. Keep an eye on my blog at http://briannoyes.net/ for additional posts about WCF RIA Services, and I will probably write some other articles on this and other topics here on The SilverlightShow as well. Thanks for reading, and please let me know any feedback you have through the comments.

You can download the source code for this article here.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Connected System MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, DevTeach, and others. He is the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on twitter @briannoyes.


Subscribe

Comments

  • hngdoan

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by hngdoan on Jan 04, 2011 07:00

    Very good article!

    There is a duplicate of heading "Consuming the SOAP Endpoint From a .NET Client". It's "Consuming the OData Endpoint from .NET Client".

    And how to consuming service from not .NET client?

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by David Rousset on Jan 04, 2011 14:05

    Hi,

     Very good article indeed!

     @hngdoan: I've posted an article on how to consume the JSON endpoint from a non .NET client (HTML5/jQuery) here : http://blogs.msdn.com/b/davrous/archive/2010/12/14/how-to-open-a-wcf-ria-services-application-to-other-type-of-clients-the-json-endpoint-4-5.aspx 

     It's part of my 5 articles series on how to open RIA Services to other type of clients.

    Bye,

    David Rousset

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by David Rousset on Jan 04, 2011 14:06
  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Brian Noyes on Jan 05, 2011 01:15

    @ hngdoan - Thanks, will look into getting that fixed.

    David - How on earth did I miss your articles when I was putting mine together? I would have definitely linked to it. Your part on consuming in HTML 5 rocks.

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by angelika on Jan 07, 2011 06:16

    I think it is not good to expose some of the domain services to your clients.

    Regards,

    Lean Blog

  • hngdoan

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by hngdoan on Jan 07, 2011 06:39
    @David: thank you so much!
  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Stijn Liesenborghs on Jan 08, 2011 11:20

    Hi Brian,

    Nice Series, I was in you WPF master class in Belgium last year.

    Currently I am struggling with a project where I want to reuse the Ria Services of a silverlight app in a WP7 app.

    Since Consuming an OData service is the only built in support for WP7 at this moment, I exposed my Ria Service as an OData endpoint. All works fine except. When consuming a plain old WCF Data Service the entity references are created into the model I generated with the DataSvcUtil. But this is not the case when I consume a WCF Ria Service that was exposed as a OData Endpoint.

    Any Ideas? Or suggestions on Reusing existing WCF Ria Services on a WP7 app without losing entity references.

    Thx in advance.

     

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Thanigainathan on Jan 09, 2011 17:41

    Hi,

     

    This is very nice article . I hope to use the OData end points in my applications.

     Thanks,

    Thani

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by PerH on Jan 14, 2011 00:32

     The most comprehensive article I've found on the subject so far, though I had to find out the hard way what the limitations are (and they indeed make RIA Services OData almost useless).

    One thing I missed though was this, which I quote from Brad Abrams:

    The format of the URL is the namespace+typename for the domainservice with dots replaced by dashs followed by “.svc/Odata/”.  So if the DomainService class is MyApp.Web.DishViewDomainService then the URL would be http://localhost:30045/myapp-web-DishViewDomainService.svc/OData/

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Cleyton on Feb 04, 2011 02:11

    Hi Brian,

    Your first webcast was. Thanks very much for that.

    I am also starting to read your 10 articles on Silverlight and RIA Services.

    One thing that I cannot figure out is how to build a Silverlight + RIA Services + PRISM app. I would like to build a composite application using PRISM but I also would like to take advantage of RIA services features like proxy generation (client context), DomainService, etc..

    To learn Prism I used a VS 2010 template provided by David Hill (Microsoft). It starts with a simple application with only two modules. However, the data is hard coded (DataItem, DataItems classes).
     
    1 - I was wondering if you could show us how to use RIA Services instead of using the hard code data?

    2 - Could you also please show us how to work with many to many relations with RIA  Services and EF?
     
    Cheers

    Cleyton

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Brian Noyes on Feb 04, 2011 15:18
    Hi Cleyton, that is not something I can cover decently here in the comments. All I can do is promise to address it in a future webcast, article, or webcast. Take a look at Part 9 and my discussion about breaking up the RIA services libraries on the client side. That is where most of the overlap exists - in how you factor your Prism modules to set up the RIA Services linkages. Prism features include modularity, regions, commands, events, and navigation. None of which have any direct impact on the way RIA Services works or vice versa. The two complement each other nicely. RIA Services provides a great way to get data into your Prism application and facilitate displaying and editing data in the views. Prism provides the way to structure your libraries that support the application, plug their views into the main application, navigate between views, and communicate between them. Really no directly overlap in functionality other than RIA Service links to the server projects influences how you factor your assemblies, which again I discussed in general in Part 9, and which really has to be thought through on an application by application basis to decide what the right factoring is based on the deployment scenarios and use cases.
  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Jason Wang on Apr 26, 2011 06:10

    I am sorry that I can not expose this interface into IIS in order to make other client invoke. Those likes WPF or Winform.

    I would list the warning as shown below:

     

    Warning 2 The element 'system.serviceModel' has invalid child element 'domainServices'. List of possible elements expected: 'behaviors, bindings, client, comContracts, commonBehaviors, diagnostics, serviceHostingEnvironment, extensions, protocolMapping, services, standardEndpoints, tracking, routing'. F:\Sample\WcfRiaServicesWPF\CSWcfRiaServicesWPF\TaskManager.Web\Web.config 35 6 TaskManager.Web

  • -_-

    RE: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Brian Noyes on Apr 26, 2011 15:01

    Jason, you are probably missing a reference to the RIA Services Toolkit server libraries in the web host.

  • prathibha

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by prathibha on Nov 07, 2011 17:21

    Very nice article.

    Thanks a lottt.

  • RynoB

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by RynoB on Nov 14, 2011 15:07

    Hi,

    I hope someone is still paying attention to the comments because I really need some clarity on a issue. I have taken the approach Brain showed and is currently consuming my Domain Service from a ASP.NET client.

    I'm running into issues as soon as I'm trying to submit the changeset back to the service using the following:

    var paymentInstruction = proxy.GetPaymentInstructionsById(paymentInstructionId).RootResults.SingleOrDefault();
     
                        paymentInstruction.TLPaymentStatusId = (int) PaymentStatus.Processed;
     
                        var changeEntry = new ChangeSetEntry
                                              {
                                                  Entity = paymentInstruction,
                                                  Operation = DomainOperation.Update
                                              };
     
                        proxy.SubmitChanges(new ChangeSetEntry[] {changeEntry}); //This line here causing the System.Runtime.Serialization.SerializationException exception message
     

                        proxy.Close();

     

    As soon as I hit:

    proxy.SubmitChanges(new ChangeSetEntry[] {changeEntry}); 

    the I get the following exception:

    Type 'Proj.Web.CDSDomainService.PaymentInstruction' with data contract name 'PaymentInstruction:http://schemas.datacontract.org/2004/07/Proj.Domain.Entities' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.

    I've taken pretty much exactly every exact same step in this post and did nothing different.

    One thing I did noticed was that my generated proxy code did not have any QueryResultOfXXX objects as shown in the example code using SOAP.

    I would really appreciate any help.

    Thanks

  • RynoB

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by RynoB on Nov 15, 2011 06:46

    Hi,

    I hope someone is still paying attention to the comments because I really need some clarity on a issue. I have taken the approach Brain showed and is currently consuming my Domain Service from a ASP.NET client.

    I'm running into issues as soon as I'm trying to submit the changeset back to the service using the following:

    var paymentInstruction = proxy.GetPaymentInstructionsById(paymentInstructionId).RootResults.SingleOrDefault();
     
                        paymentInstruction.TLPaymentStatusId = (int) PaymentStatus.Processed;
     
                        var changeEntry = new ChangeSetEntry
                                              {
                                                  Entity = paymentInstruction,
                                                  Operation = DomainOperation.Update
                                              };
     
                        proxy.SubmitChanges(new ChangeSetEntry[] {changeEntry}); //This line here causing the System.Runtime.Serialization.SerializationException exception message
     

                        proxy.Close();

     

    As soon as I hit:

    proxy.SubmitChanges(new ChangeSetEntry[] {changeEntry}); 

    the I get the following exception:

    Type 'Proj.Web.CDSDomainService.PaymentInstruction' with data contract name 'PaymentInstruction:http://schemas.datacontract.org/2004/07/Proj.Domain.Entities' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.

    I've taken pretty much exactly every exact same step in this post and did nothing different.

    One thing I did noticed was that my generated proxy code did not have any QueryResultOfXXX objects as shown in the example code using SOAP.

    I would really appreciate any help.

    Thanks

  • brian.noyes

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by brian.noyes on Nov 15, 2011 16:04

    Hi RynoB,

    Could you clarify - Are you using the SOAP endpoint or the JSON one?

  • RynoB

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by RynoB on Nov 15, 2011 16:34

    Hi Brain,

    I'm using the SOAP endpoint

  • brian.noyes

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by brian.noyes on Nov 16, 2011 15:45

    RynoB,

    Sorry, but I can't think what it would be off the top of my head, looks like you are doing the exact same thing as I have done but for some reason it is not recognizing that type for the changeset. The only thing I can think is to really inspect the type being returned from your first line of code - the problem with the var keyword is you don't really know what you are working with. See if it matches the type it is complaining about, and if not, try to figure out what you are really getting back.

    Otherwise, I'd say you would have to take it up on the forums at http://forums.silverlight.net/53.aspx

  • rohmansah

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by rohmansah on Mar 04, 2012 08:48
    thanks for your information ,,, karanganyar online
  • markaarnold

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by markaarnold on Mar 07, 2012 16:49

    Hi Brian - thanks for the article.  I've secured my Silverlight app by setting deny users=? in the hosting site's web.config.   Not surprisingly I can see in Fiddler that calling the new soap endpoint sends the login page back to the caller (WPF app).  I have two questions about this:

    First - how can I modify web.config to easily allow anonymous access just for testing?  I tried excluding the domainservice.cs file as well as the project-web-service.svc file but no luck.

    Second - how do you recommend the client authenticate to the service?  My WPF client will have already to the same aspnetdb used behind the Silverlight app and soap service - I'm hoping I can tap into a cookie etc and pass it along with the service call.

    Thanks as always!
    Mark

  • brian.noyes

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by brian.noyes on Mar 07, 2012 17:43

    Hi Mark,

    For debugging you can just remove the Deny users=? and leave off the RequiresAuthentication attribute. But it depends on what other dependencies on identity you have in your service and client side to say whether that will really work for you.

    I'm not clear on your second part - are you saying you also have a WPF client that will be consuming the domain service? To do that you would want to set up the ASP.NET Authentication Service that is part of the framework (see links for "Client Application Services"). It uses the same ASP.NET cookies for auth that RIA Services does, so should be able to hit that, establish the secure session and then hit the domain service as long as they are on the same site. Haven't tried this, you would have to lift the cookie that gets returned somehow and then associate it with the domain service call. Not sure where to point you for that. 

  • markaarnold

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by markaarnold on Mar 08, 2012 14:20

    Brian - thanks for your answers

    Re: my first question, I can surely do as you suggest, but a better question would have been is the svc that the soap endpoint exposes securable with the web.config file as a normal file would be?  It's hard to know since their is no svc file per-se, just the underlying domainservice.cs file 

    As to the authentication question, I have two sites, both hosted in Azure: 

    1) Silverlight web host which authenticates against an aspnetdb hosted in SQL Azure
    2) CAS web site which authenticates against the same aspnetdb.   

    I suspect my problem may be that these two are in separate sites.  I ran into problems combining the sites because the SL site is .Net4 based, but I could only get the CAS site to work properly as a .Net3.5 site.  When I targeted the CAS site to .Net4, none of the JSON entries for application services were added to the web.config file.  I also find it difficult in general to combine multiple web apps on the same virtual machine in Azure, mostly from a visual-studio publishing standpoint.  If you think hosting the SL app and the CAS app in the same web site will unify the authentication I'll pursue this further, and of course any pointers you have for doing so are appreciated!

    Thanks
    Mark

  • markaarnold

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by markaarnold on Mar 08, 2012 14:51

    Brian - thanks for your answers

    Re: my first question, I can surely do as you suggest, but a better question would have been is the svc that the soap endpoint exposes securable with the web.config file as a normal file would be?  It's hard to know since their is no svc file per-se, just the underlying domainservice.cs file 

    As to the authentication question, I have two sites, both hosted in Azure: 

    1) Silverlight web host which authenticates against an aspnetdb hosted in SQL Azure
    2) CAS web site which authenticates against the same aspnetdb.   

    I suspect my problem may be that these two are in separate sites.  I ran into problems combining the sites because the SL site is .Net4 based, but I could only get the CAS site to work properly as a .Net3.5 site.  When I targeted the CAS site to .Net4, none of the JSON entries for application services were added to the web.config file.  I also find it difficult in general to combine multiple web apps on the same virtual machine in Azure, mostly from a visual-studio publishing standpoint.  If you think hosting the SL app and the CAS app in the same web site will unify the authentication I'll pursue this further, and of course any pointers you have for doing so are appreciated!

    Thanks
    Mark

  • brian.noyes

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by brian.noyes on Mar 08, 2012 15:03

    Hi Mark,

    No, the pseudo-svc file address they create would probably not be securable with web.config alone since ASP.NET won't see it as a file - it just lets the RIA Services HTTP Module handle the request.

    As far as the separate sites goes, that is definitely the problem - secure session cookies can't cross domains. So the only way it would work is if you host your RIA domain services in the same site as your CAS auth services. If you do that, you will have to use the overloaded constructor on the DomainContext class that takes a Uri so that you can point it to the other site because the default behavior is to assume the RIA Services are exposed from the hosting site for the Silverlight app.

    Brian

  • Mirrow

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by Mirrow on Apr 10, 2012 11:38

    Hi Brian,
    I receive only the basic data types, any complex type like the Customer on the Task class is not available at the client side. Is there any solution to get these types send over the wire?

    Mirrow

  • deepto.it

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by deepto.it on Mar 26, 2013 07:42

    Hi Brian,

    Your post is very useful.... Thanks for this nice post... Now I have a little bit Complex Business Object where two objects have a relation between them. Like, Customer object holds a list of Task object (TaskList). Association and Composition is present there. Which means A Customer may have 0 or more Tasks but without Customer there is not Task. Now when I use WCF Ria Soap Service in Client I only get the Customer Object but the property TaskList as declared in Customer Object does not exist. I don't know why..? I think the previous pot from Mirrow faced the same scenario. How can I expose this property in Customer object? Thank you for any help........

      Deepto

  • brian.noyes

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by brian.noyes on Mar 26, 2013 14:16

    For your scenario, I think you need to add the Composition attribute I talked about in part 5 to treat the tasks as child objects that are "contained" by the Customer. Either that or you need to expose a query method for Tasks. Client side will not generate entities unless there is a top level query method for that entity type or it is part of a Composition property on another entity.

  • brian.noyes

    Re: WCF RIA Services Part 10 - Exposing Domain Services To Other Clients


    posted by brian.noyes on Nov 22, 2013 17:05
    @serpantyn - Could you restate the question you had posted before with a little more information about what you are trying to do and what the error is that you are seeing. I was misleading with my previous reply so I pulled that reply down. Would like to try to help you get past the issue you are seeing. Thanks.

Add Comment

Login to comment:
  *      *       

From this series