Need some expert opinion on this case study.
Problem Statement/Scenario:
My WCF client/proxy continually requiring some lockup data from relevant WCF service. More precisely, I've a WCF service that provides Location data (City/Country etc) from a database (although data is cached on Service). Some how I want to avoid Serialization/DeSerialization (Object contains a lot of associated properties as well as inner objects) cost and service operation execution for better throughput.
Few days back I studied WCF behaviors/WCF extension methods.I found an interesting article on MSDN (http://msdn.microsoft.com/en-us/magazine/cc163302.aspx). After reading this article I thought this could help me to improve performance of my service. So before implementing this I want to confirm that either I'm thinking in right direction or any other solution can solve my problem.
I'm thinking to implement Dispatcher Extensions to solve this problem instead of Proxy (Client) Extensions. I've following queries?
I) Where (Proxy/Service level) I need to implement extensions?
II) When implementing Dispatcher Extensions my call will not send to actual service and I'll save Serialization/DeSerialization cost. Right/Wrong?
III) Implementing Dispatcher Extensions in my case is also better, because why need not to bother about which proxy interface method call occurred as caching logic is on service side. Right/Wrong?
Please suggest me a better solution as I want to save Serialization/DeSerialization cost as well as I want to implement data caching.
Thanks in advance
/Rizwan
There are two ways I've incorporated WCF caching in the past:
Using Castle DynamicProxy to generate proxies for my ServiceContract interfaces. These dynamic proxies use interceptors to perform caching. If the data is not in the cache, the interceptor creates a real WCF client (a ChannelFactory<TInterface>) and invokes the WCF operation, then caches the result. I like this approach, because the caching implementation isn't really WCF specific.
Implement an IRealProxy for WCF which wraps the actual remote operations and performs caching/retrieval as necessary. In principal, this is similar to approach 1, but the implementation is specific to WCF (with remnants of .NET Remoting). I used this approach before migrating to #1. I migrated to approach 1 because approach 1 let me accomplish caching on both the client and the server in an implementation agnostic manner. At the time, I rolled my own RealProxy, but it looks like someone else has since done the same and posted the code: http://blog.ngommans.ca/index.php?/archives/31-Custom-Proxy-Generation-using-RealProxy.html
Related
Was planning to use Service Routing (on WCF/REST) to do some common tasks before a request hits the actual service. Now that I read more about it, looks like REST is not supported yet on RoutingService and the suggested method is to use System.Web.Routing or ARR.
What needs to happen in the router is a key validation, a header value extraction and versioning.
ARR doesn't look right for this as it just routes and there is no "handler" we have access to. System.Web.Routing looks like a lot of custom implementation which might undermine the efficiency of WCF.
An old school alternative am thinking of is to have the common functionalities in one chain-of-responsibilities implementation and just compose it in every service. This has the disadvantage of being referenced in N number of places for N services. But this increasingly looks like the only alternative if I don't want to mess with the WCF handling of endpoints.
Am looking for advice on a right way to do this, and any samples.
Didn't try, but maybe writing a custom service behavior can solve your problem. Take a look here : Extending WCF with Custom Behaviors.
The idea is to extend the WCF engine with a custom behavior, then attaching your service with this behaviors. This is transparent for the services.
Take a look at HttpMessageHandlers in the new WCF Web Api project htttp://wcf.codeplex.com This mechanisms allows you to do something similar to Rack or WSGI. I have a couple of examples of what you can do with them on my blog http://www.bizcoder.com/index.php/2011/05/22/how-to-get-ahead-with-messagehandlers/
I have a existing WCF in .NET which is consumed through wsdl and proxy classes. Soon, there will be multiple consumers and the load on the WCF will be pretty high. I was asked to develop a new WCF with REST which can be beneficial interms of performance. I don't have much knowledge on REST, hence can you please let me know whether implementing a RESTFUL WCF will improve the performance drastically? Please provide me any links to implement the same.
Thanks in advance,
Vinoth Khanna.S
You can also use WCF Data Services to easily offer a REST interface to your data.
The easiest way is to build an Entity Framework model of your data and then to expose that model as a WCF Data Service. This then exposes all data using the OData protocol, which is REST + AtomPub.
And Kiran is of course right, REST by itself does not increase performance. I assume that you want your UI to access the REST service directly rather than go through a web service which contains hand-written methods to read and write data. In that case, there may be some performance gain, but I wouldn't count on it much.
See also:
http://msdn.microsoft.com/en-us/library/cc668794.aspx
and
http://en.wikipedia.org/wiki/WCF_Data_Services
If you want to return results as JSON, the easiest way to get that to work is by adding the WCF Data Services Toolkit:
http://wcfdstoolkit.codeplex.com/
As far as I know REST is not for performance enhancement, it makes your webmethods URL accessible and make those URL's more predictable and logical. I would start with this video http://channel9.msdn.com/Events/PDC/PDC08/TL35 then with WCF REST Starter Kit http://www.asp.net/downloads/starter-kits/wcf-rest
We have a multi services application.
We have moved a method that involves a DB access to a separate component that is exposed by a WCF endpoint.
We have more than one service that need to use this method.
The dilemma is what to use:
A WCF call to the method.
Call directly to the method, resolved by our DI engine.
The system performance is a critical issue.
So what do you think is better?
Using WCF to make the cal
Reference the required service and call it in-process using the DI engine.
Thanks Or.
If performance is critical, referencing the service component and calling directly the DB without going through all the WCF layers and serialization processes will be faster but less robust. If you decide to change the implementation you will need to recompile the client application as well. My advice would be to measure the performance of the WCF service call and if you are happy with the results leave it that way.
For me I have a WCF service which acts as DAL and does all the CRUD operations
I just came to know regarding the new ADO.Net Data Service, just read somewhat but not actually sure when & where to use it?
Just to add more, my new project is in ASP.Net MVC, so is it wise to use ADO.NET Data Service rather than WCF service with it which will probably act somewhat like 'M'(Model) of MVC ???
First, my advice would be to write your MVC code so that it is oblivious to what the back-end data model is. Abstract away any dependencies right from the beginning.
As for deciding whether or not to use WCF, I'd suggest that you decide whether or not you'll want to reuse the data component that you write. If you have plans on using your data code in a Silverlight, WPF, or any other format, then I'd suggest sticking with WCF.
Also, remember that you can always simply wrap the ADO.NET data services with a WCF component and still enable the reuse scenario. Get the best of both worlds!
One big advantage is that with the ADO.NET Data Services, you don't have to specifically write all the services for basic CRUD operations as you may with WCF. Since ADO.NET data services basically expose those operations, you can focus more code writing and debugging on business logic.
The big advantage of WCF Data Services, and IMO it fits your need, is when your service layer is used for CRUD only. You do not have (and do not need) any business logic in it.
As Tad pointed out, the reuse is an advantage, but on the other hand, WCF Data Services will give your web app, or any consumer, a very flexible way to query data. With WCF, you'll have to write code to give the consumers the same query flexibility OData gives.
I had a experience recently. I created a service layer with WCF and in many cases, the service operations was used only to call a repository. There wasn't any rule, only query logic. The consumer was able to pass a criteria to have a result back.
The requirements changed and we realized that we could make it more simply (less code to maintain) by using WCF Data Service.
When working with WCF services, is it better to create a new instance of the service every time you use it? Or is it better to create one and re-use it? Why is either approach better? Is it the same for asynchronous proxies?
Or is it better to create one and re-use it?
Do not start to implement your own pooling implementation. That has already been done in the framework. A WCF proxy uses cached channels factories underneath. Therefore, creating new proxies is not overly expensive (but see Guy Starbuck's reply regarding sessions and security!).
Also be aware that a proxy times out after a certain idle time (10mins by default).
If you want more explicit control you might consider using ChannelFactories and channels directly instead of the "easy to go, full out of the box" ClientBase proxies.
http://msdn.microsoft.com/en-us/library/ms734681.aspx
And a "must read" regarding this topic is:
http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx
in addition to the things Guy Starbuck mentioned a key factor would be the security model you're using (in conjunction with the session requirements) - if you don't re-use your proxy, you can't re-use a security sessions.
This means that the client would have to authenticate itself with each call which is wasteful.
If, however, you decide this is what you wish to do, make sure to configure the client to not establish a security context (as you will never use it), this will save you a couple of roundtrips to the server :-)
One more point to consider is channel faults. By design WCF does not allow to use client proxy after unhandled exception happened.
IMyContract proxy = new MyContractClient( );
try
{
proxy.MyMethod( );
}
catch
{}
//Throws CommunicationObjectFaultedException
proxy.MyMethod( );
There is a corollary here to Server Activated Objects in .NET Remoting (one of the technologies that is replaced by WCF), which have two modes, "Single Call" (stateless) and "Singleton" (stateful).
The approach you take in WCF should be based on your performance and scaling requirements in conjunction with the needs of your consumers, as well as server-side design constraints.
If you have to maintain state between calls to the service, then you will obviously want to have a stateful instance, but if you don't you should probably implement it so that it is static, which should scale better (you can more easily load balance, etc).