Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using WCF in an ASP.Net Application and Best Practices

Tags:

asp.net

wcf

I am completely new to WCF. I was pretty sure it was going to work like regular web services - and I'm also pretty sure I was doing that wrong too, but now I want to make sure I'm doing it right.

Our ASP.Net app connects to the WCF service across the internet. I have impletemented basic security and using SSL. It is working, but slower than when we had regular web services going. The data being returned is fundamentally the same as with the regular web service.

When I was using the regular web service, anytime I needed to get data, I would create a new service object and call the function for the data I needed. This seemed to work ok, but as I would imagine, not the best way to do it especially if there were thousands of users connecting at the same time. So when I converted to WCF, I decided to keep one client open and just use that for everyone connecting to the site. I put it in the cache and when the cache would dump the object, I had a callback function to dispose it.

Now I didn't even think about it till after I changed all this that it might pose an issue for multiple people connecting. If person A requests data, person B has to wait for that to finish before their data is fetched through the service.

So I changed it to be session based. I either implemented this wrong or it just backfired as it didn't work well at all. The client would time out, cause a fault, or just plain not work. I changed it back to being cached for now and it seems to be working fine (except slow).

What is a "best practice" for this scenario? Do I create the client on the fly when it's needed, create one session based (and figure out what I did wrong), or keep it as is and use the one client cached method?

like image 738
TheCodeMonk Avatar asked May 22 '09 19:05

TheCodeMonk


People also ask

What is the use of WCF service in asp net?

Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application.

Can we use WCF in web application?

In other words, I am consuming the WCF Service in an ASP.Net web application. Similarly, you can use the same WCF Service in Windows, console application, Java and other applications.

Can we consume WCF service in .NET core?

You cannot "host" or have a ASP.NET Core app that implements a WCF service, but you can "consume" WCF services.

Is WCF obsolete?

NET and its key APIs for the transition to . NET Core and the unified . NET, its heyday had passed and new technologies like gRPC were seen as the way forward. WCF was deprecated and handed over to the community, and developers working on .


2 Answers

This sort of problem is usually solved by maintaining a pool. Rather than only having one service object in one extreme and one per user in the other extreme, the pool would hold a collection of service objects that are needed to support the con-current demand for their services. Hence the pool should grow only to a point of maximum demand.

You would make sure that objects dropped out of the pool before any other timeout from inside the service object and also ensure they dropped out if they have any kind of exception.

This way you don't have multiple client requests waiting for access to single object nor do you have idle objects hanging around in a service and likely dying of old age before they can be reused again anyway.

like image 170
AnthonyWJones Avatar answered Oct 21 '22 06:10

AnthonyWJones


The general best practive for WCF services would be to have the per-call, single-instance model whenever possible. This gives you the best throughput, the best and simplest behavior in the service instance. So whenever possible, and unless you have a really compelling reason, use this model.

It seems that in your case, creating the service instance is a rather expensive operation. Maybe you need to get this cleaned up somehow - make the actual service instance very lean and lightweight so it can be created and disposed of in a blink of an eye (or less), and then have some background worker processes (or possibly a pool of those, as suggested by Anthony) which you can then call from your actual service instances.

Marc

like image 20
marc_s Avatar answered Oct 21 '22 06:10

marc_s