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

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

brian.noyes — Tue, 26 Mar 2013 14:16:55 GMT

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.

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

deepto.it — Tue, 26 Mar 2013 07:42:50 GMT

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

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

Mirrow — Tue, 10 Apr 2012 11:38:41 GMT

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

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

brian.noyes — Thu, 08 Mar 2012 15:03:32 GMT

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

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

markaarnold — Thu, 08 Mar 2012 14:51:09 GMT

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

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

markaarnold — Thu, 08 Mar 2012 14:20:36 GMT

Brian - thanks for your answers

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.

Thanks
Mark

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

brian.noyes — Wed, 07 Mar 2012 17:43:11 GMT

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.

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

markaarnold — Wed, 07 Mar 2012 16:49:41 GMT

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

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

rohmansah — Sun, 04 Mar 2012 08:48:48 GMT

thanks for your information ,,, karanganyar online

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

brian.noyes — Wed, 16 Nov 2011 15:45:33 GMT

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

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

RynoB — Tue, 15 Nov 2011 16:34:38 GMT

Hi Brain,

I'm using the SOAP endpoint

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

brian.noyes — Tue, 15 Nov 2011 16:04:25 GMT

Hi RynoB,

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

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

RynoB — Tue, 15 Nov 2011 06:46:10 GMT

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

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

RynoB — Mon, 14 Nov 2011 15:07:24 GMT

Hi,

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:

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

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

prathibha — Mon, 07 Nov 2011 17:21:05 GMT

Very nice article.

Thanks a lottt.

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

Brian Noyes — Tue, 26 Apr 2011 15:01:48 GMT

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

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

Jason Wang — Tue, 26 Apr 2011 06:10:22 GMT

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

Brian Noyes — Fri, 04 Feb 2011 15:18:43 GMT

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

Cleyton — Fri, 04 Feb 2011 02:11:15 GMT

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

PerH — Fri, 14 Jan 2011 00:32:23 GMT

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

Thanigainathan — Sun, 09 Jan 2011 17:41:31 GMT

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

Stijn Liesenborghs — Sat, 08 Jan 2011 11:20:35 GMT

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

hngdoan — Fri, 07 Jan 2011 06:39:31 GMT

@David: thank you so much!

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

angelika — Fri, 07 Jan 2011 06:16:49 GMT

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

Regards,

Lean Blog

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

Brian Noyes — Wed, 05 Jan 2011 01:15:54 GMT

@ 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

David Rousset — Tue, 04 Jan 2011 14:06:52 GMT

Sorry, here is the proper link : How to open a WCF RIA Services application to other type of clients: the JSON endpoint (4/5)

Regards,

David

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

David Rousset — Tue, 04 Jan 2011 14:05:01 GMT

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

hngdoan — Tue, 04 Jan 2011 07:00:31 GMT

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?