I am trying to improve the performance of a Silverlight 4 WCF RIA application. As it's for intranet use only, I figured switching from the default binary HTTP binding to the Net.TCP binding might improve performance a bit.
However, I am having a hard time just getting a simple proof of concept application running. I have:
switched the proof of conecpt app from Cassini to IIS (7)
added the appropriate bindings and enabled protocols on IIS
added a clientaccesspolicy.xml file to my IIS root
Now, when I create a context like so:
var context = new DomainService1(
new Uri(
"net.tcp://localhost:4502/BusinessApplication/BusinessApplication2.Web/ClientBin/BusinessApplication2-Web-DomainService1.svc"));
... I get the following error:
The provided URI scheme 'net.tcp' is invalid; expected 'http'. Parameter name: via
Now I'm stumped. As far as I can tell, the problem is that the client being created by the auto-generated WCF RIA code needs to be told that it's to use a Net.TCP endpoint, but I'm unsure how to do that.
I've found plenty of blog posts explaining how to get WCF services going over Net.TCP, but I haven't found a single one talking about WCF RIA, and I can't find any offical documentation either. All of those explanations involve changes to the web.config file that seem unsuited to a WCF RIA app.
Could some one please either explain to me how to get this configured, or point me at some documentation?
WCF RIA Services depends on HttpContext which is not available with Net.TCP binding.
As for perf issues, could you elaborate a bit further? What is the bottleneck query/operation? What is the size of data (entity size x entity count)? What is the delta between your perf requirements and current perf?
Perhaps there are other ways that don't involve Net.TCP?
Thanks.
Dinesh
(WCF RIA Services Program Manager)
Related
I have posted this same question in the msdn forums, but nothing yet ..
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/60cf36d1-c11a-4d8a-9446-f1d299db1222
I'm working on a project that is an MVC app that will be sourced data via a WCF service that may or may not be getting data via EF, but will definitely be using Stored Procedures..
The MVC app will maintain state in the session, and the entity-tracking portion of this state would preferably function much like the RIA Services DomainContext. Whether or not this context encapsulates saves and changesets is not really all that important, but how entities are loaded into the context and relate to one another (navigation properties) are.
Question 1: Is there such a pattern/solution in existence?
Question 2: Should the MVC and WCF layers share the same DTOs/Entities via a class library? (thereby maintaining state-awareness, navigation properties, etc on both ends of the pipe?)
Question 3: Does using WCF Data Services help solve these problems?
Question 4: Is this all misguided and is there a better approach?
Pretty basic stuff here..
The solution is use a WCF Data Service, and in the client add a Service Reference pointing to it. The client-side proxy will include a proxy and the context classes I was looking for, similar to RIA. If you're accustomed to RIA, there will be some differences and caveats, but by and large it's easy to work through and provides a client-side proxy to your server-side ObjectContext (or whatever repository you expose through the DataService)
In general, are WCF Data Services interoperable or Microsoft specific?
This ADO.NET Blog link shows very nice how EF could be used in WCF Services. But it also shows in that simple example a method with return type: IQueryable<Patient>. Is this breaking the interoperability?
Is there any special treatment regarding these Data Services with EF to be interoperable? Are there tips or things to take care in this matter?
This MSDN overview says WCF Data Services are interoperable. I believe returning IQueryable<> is to support the OData query expressions.
I'd assume you won't have to do anything special (other than maybe exposing the services with WebHttpBinding and WebHttpBehavior).
If you're evaluating technologies you may want to look into ASP.NET MVC4 Web API as an alternative to WCF Data Services. Take a look at this blog and this forum post.
Why do people call RIA services a black magic? What kind of black magic do they refer to ? Also, i have seen most people do not use RIA even though they are in Silverlight world. Why is it so? Even on stackoverflow, the % of people asking as well as answering to RIA services question is very very low. Why is it so?
WCF RIA Services provides the following benefits:
Makes a WCF RIA service that supports IQueryable and IEnumerable; WCF RIA Services creates client-side proxy which allows you to send only expression trees over the wire from the client in order to get back just the data you need. For example: you can call a method in your ria service called GetProducts() but also add a LINQ lambda such as GetProducts().Where( d => d.Quantity > 50 ) and only the expression is sent over the wire to the server. The server does the filtering and returns just the matches as strongly typed objects.
Dynamic generation of OData, REST/JSON, and SOAP endpoints with little more than a single line per endpoint in your web.Config.
Ability to automatically flow business rules created at the middle tier into the client tier
Allows you to efficiently flow validations from the middle tier to the user
Allows property, parameter, method, object, collection, and changeset level business rules through simple data annotation validator decoration
There are some deficiencies:
Still does not support WS-* (will in 5) for RPC
OData provider is not queryable
Well, I have not yet heard of people referring to WCF RIA Services as black magic.
I believe there is a small number of people using it (compared to the number of people writing stuff in Silverlight), because it is younger. People may have been developing their Silverlight applications for some time now (version 3.0 came out in July 2009) using classic WCF Services.
WCR RIA Services is still new (version 1.0 came out in May 2010, the final SP1 in December 2010) and we all know the rule, "Never change a running system", so if someone already has a working WCF webservice, why change it? In my case, we experimented with Silverlight and WCF some time ago and decided to wait. When RIA Services came out we thought that was great and started working on a Silverlight version of our main application. It is much easier using RIA Services in a new project than chaning your webservice access in an existing one.
In addition to that it should be noted that Silverlight is not limited to business applications with database access using a webservice. Therefore there may be quite a few Silverlight developers who do not need any kind of webservice.
Another reason might be the fact that for web applications requiring a database other technologies like ASP.NET, ASP.NET MVC, even PHP or JSP (and possibly others I may not even have heard of) have existed for quite a while. And although business applications ought to look nice, too, it usually is not the top requirement to have all kinds of fancy graphics and animations, etc.
Finally, why are so few questions regarding RIA Services asked on SO? Well, they do have their own forum which seems to be quite active. (I use it as a resource when looking for answers but don't post there.)
Regarding the "black magic" part of your question, I believe it is the ongoing shift to convention over configuration. Compared to vanilla WCF, you end up writing very little code to build the client-server relationship. Also, the WCF RIA tooling does a substantial amount of code generation to achieve this.
More on convention over configuration on specifically with WCF RIA and generally at Wikipedia.
Is there a good reason to deploy or consume a SOAP service without using a WSDL "file"?
Explanation:
I'm in a situation where a 3rd-party has created a SOAP service that does not follow the very WSDL file they have also created. I think I am forced to ignore the WSDL file in order to consume this service. Therefore I'm researching how to do this.
What I am really wondering is why it is even possible to do this? What is the intention?
Is it designed so that we can use poor services made by poor programmers? Surely there must be a better reason. I almost wish it wasn't possible. Then I could demand they write it properly.
The WSDL is supposed to be a public document that describes the SOAP service, so describes the signatures of all the methods available in the service.
Of course there may be service providers who want to expose a service to certain consumers, but who don't want to make the signature of the service public, if only to make it a little bit harder for people they don't want using the service to find it or attempt to use it. The signature of the services might expose some private information about the schema of their data for example.
But I don't see any excuse for writing a WSDL that doesn't match the service. I would worry that if they can't get the WSDL right what is the quality of the service going to be like?
To answer the other question yes you can consume the service without the WSDL. If you are using Visual Studio for example you could have VS build a proxy for you based on the incorrect WSDL and then tweak it to match the correct service method signatures. You just need to make sure your data contracts and method contracts in your proxy match the actual service data contracts and method contracts.
I'm trying to buid a site with the following:
VS 2010 (for the updated WCF RIA Services)
Silverlight 4.0 (packaged with WCF RIA Services).
MVC 2
EF 4.0
I am setting it up so that the public facing pages will be html from MVC, but the administration portion will be a silverlight navigation application using using WCF RIA Services for data access.
When I create the silverlight application within a webforms application, it works (I am able to add a datagrid and retrieve data using EF 4.0 and WCF RIA Services successfully):
alt text http://www.patleague.com/images/sl4_webforms.png
When I create the silverlight application within an MVC2 application:
alt text http://www.patleague.com/images/sl4_mvc2.png
I get an error as follows (I've added the same datagrid in both cases - a simple table with 2 records):
alt text http://www.patleague.com/images/sl4_mvc_dataerr.png
The webforms server-side works while the MVC server side doesn't. I've unsuccessfully tried WCF logging as well as fiddler, but I somehow can't get any output (using the example here: http://msdn.microsoft.com/en-us/library/ms730064.aspx), and I've also tried fiddler to get some information with no luck. I'm really struggling with this and I wonder if anyone else has run into this issue and found a way around it?
Thanks, Dennis
Ignoring the routes for the services corrected this problem when added to Global.asax.cs:
routes.IgnoreRoute("{*allsvc}", new { allsvc = #".*\.svc(/.*)?" });
Credit for this answer has to go to OneSmartGuy: his answer fixed my issue also.
This issue might be specific to my site, but perhaps other people are having the same issue, and I had been so darn frustrated by this that I had given up for a while and tried other methods to get done what I wanted, but came back to Silverlight because I have a hard time with Javascript and JS UI libraries. I had better luck with fiddler when working on the deployed site (I didn't get any output when working with the development server).
When I browsed to my site with the silverlight app, the dialog popped up with the usual "load operation failed for query...", and fiddler showed the following when highlighting the error:
IIS specified authentication schemes 'Basic, Anonymous', but the binding only supports specification of exactly one authentication scheme. Valid authentication schemes are Digest, Negotiate, NTLM, Basic, or Anonymous. Change the IIS settings so that only a single authentication scheme is used.
I looked up this error in the DiscountASP.net (my hosting provider) and found a KB article that instructed me to update the web.config (for IIS7) as follows:
<system.webServer>
<security>
<authentication>
<basicAuthentication enabled="false" />
</authentication>
</security>
</system.webServer>
And viola! I could use WCF RIA Services with Silverlight in asp.net MVC2! I found also that it was unnecessary for me to create a special service and a domainhostfactory as described in several blog posts while researching this stuff, or change the routing to avoid interactions with MVC and the service request. This is all I had to do
I guess this is a pretty basic fix, and hopefully it'll help someone else. I was extremely frustrated with this, and dissapointed that such a simple fix is publicly available, yet no step-by-step instructions for this scenario is given from Microsoft as this is using the most up-to-date microsoft technologies.
Thanks, Dennis