I have WCF interface contract which is behind basic HTTP authentication. This serice have mostly stream methods for large file transfers (streaming). What i want is call one ClientBase instance call from multiple threads.
But when i do that, only one file is transfered at the time. Is WCF serializing requests and locking channel?
What is the best strategy for client creation for WCF service in .NET 4.5 for concurrent environment?
Related
I'm developing a UWP client project which need to consume some services of a WCF server. I uses the "add service reference" tool of Visual Studio to auto generate service clients(proxies). The binding type is NetTcpBinding. Below is some code snippet which create the service client:
NetTcpBinding tcpBinding = new NetTcpBinding();
tcpBinding.Security.Mode = SecurityMode.None;
tcpBinding.Security.Transport.ClientCredentialType = TcpClientCredentialType.None;
tcpBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
MainServiceClient = new MainServiceClient(tcpBinding, new EndpointAddress("net.tcp://localhost:8773/MyWCF/MainService/tcp"));
The question is do I need to call OpenAsync() method of MainServiceClient? It seems the service client can be auto opened when it is first called. But I read from this article that auto-opened service client would have some performance penalty. The article was written in 2007. I just wonder if this mechanism have changed today, especially in UWP project. Can anyone share more light on this topic? Thanks!
To explain this case, you should know three ways to do WCF instance management. WCF has provided three ways by which you can control WCF service instances:Per call, Per session, Single instance.
When we configure a WCF service as per call, new service instances are created for every method call you make via a WCF proxy client.
Very often we need to maintain state between method calls or for a particular session. For those kinds of scenarios, we will need to configure the service per session. In per session, only one instance of a WCF service object is created for a session interaction.
Often we would like to create one global WCF instance for all WCF clients. To create a single instance of a WCF service, we need to configure the WCF service as Single instance mode.
And there are three ways by which you can handle concurrency for each service instance in WCF :single, multiple, and reentrant.
Single: A single request has access to the WCF service object at a given moment of time. So only one request will be processed at any given moment of time. The other requests have to wait until the request processed by the WCF service is completed.
Multiple: In this scenario, multiple requests can be handled by the WCF service object at any given moment of time. In other words, requests are processed at the same time by spawning multiple threads on the WCF server object. So you have great throughput here but you need to ensure concurrency issues related to WCF server objects.
Reentrant: A single request thread has access to the WCF service object, but the thread can exit the WCF service to call another WCF service or can also call a WCF client through callback and reenter without deadlock.
In "Instance mode = Per Session and Concurrency = Single" combination, one WCF service instance is created for every WCF client session because the WCF instance mode is set to per session. All the method are executed in a sequential manner one by one. In other words, only one thread is available for all method calls for a particular service instance.
For the above scenario, you should always open WCF client proxy explicitly before you are making any calls. Because it will maintain service state between method calls and obtain high performance.
For more detail you could refer to "WCF Concurrency (Single, Multiple, and Reentrant) and Throttling" and "Three ways to do WCF instance management".
I currently have an application whereby a user makes a request to my ASP.Net UI, which in turns makes an async call into a WCF service to keep the ASP.net thread free.
The WCF service is essentially a translation module, sat on the restricted network, and bridging the DMZ to the Trusted network. This service calls out to a Java service, which will hit the DB, and I currently have this as a synchronous call.
My WCF services are setup with ConcurrencyMode.Single, and InstanceContextMode.PerCall, so I guess that when I run out of threads on the service host, I'll start backing up requests because the UI is calling async, allowing the user to send multiple requests.
Should I be calling the Java service as an async task, like I do in the UI?
async-await is almost always a good idea. It doesn't really matter which IO you are using (in this case a network call to a java service) as long as it can benefit from treating it as an asynchronous by releasing threads while waiting for IO to complete.
Of course you would get a bigger benefit by also making the java service fully asynchronous, but it isn't necessary.
Using .NET Framework 3.5 C#, I am in the process of moving from SOAP-based Web Services to JSON-based WCF Services. All my web services derive from a common ServiceBase class with common functionality like session validation, client authentication, database connection, logging etc. and in all my web service method I call a common method on the base class using a single line of code to perform the common tasks
base.InitCallThread()
Q1: What is the best way to do the same or similar in WCF in order to avoid having to write hundreds of lines of repetitive code?
Q2: If I was to support the same interfaces with both SOAP-based Web Services and JSON-based WCF services in parallel, what would be the best way to share the same common functionality? I guess it is possible to share the http session b/w the two?
You should refactor your base class code into a separate class. Call that separate class from the base class in your ASMX services; in the WCF service, call it from each individual service, or use one of the WCF extensibility mechanisms to call it centrally.
WCF permits the same service to be exposed on multiple endpoints with different bindings. You can expose the same WCF service with basicHttpBinding for SOAP, at the same time as exposing a webHttpBinding for the JSON.
Q1: You can derive from the same ServiceBase class with common functionality as you had before. WCF does not limit you in this matter. It requires only implementing some interface
Q2: You can define multiple bindings through web.config (or programmatic) configuration.
I am trying to create a number of WCF services. These services will expose certain public methods and require to consume each other (i.e. call WCF Service methods from another WCF Service)
Is there any good reference tutorial material that I can refer to for this?
Thanks all in advance!
Consuming a web service in another web service is no different to consuming it in any other client. You create a proxy and make your call so all the general WCF documentation and tutorials will apply.
However, this is usually not a good practice - although sometimes is unavoidable in an SOA. Services must be consumed by clients and they should not call each other unless they have to.
There are a host of problems that can happen. First of all, a service has to wait for the result of a synchronous call from one or more services to return and your service thread will be locked until those calls are finished. If one call takes long, the other service will take long as well and you will have scalability issues.
Let the client call these services. If a call requires data from another service, get the client to make the call and get the data and then make the call again.
What is the difference between them?
When would I opt for one over the other?
This answer is based on an article that no longer exists:
Summary of article:
"Basically, WCF is a service layer that allows you to build applications that can communicate using a variety of communication mechanisms. With it, you can communicate using Peer to Peer, Named Pipes, Web Services and so on.
You can’t compare them because WCF is a framework for building interoperable applications. If you like, you can think of it as a SOA enabler. What does this mean?
Well, WCF conforms to something known as ABC, where A is the address of the service that you want to communicate with, B stands for the binding and C stands for the contract. This is important because it is possible to change the binding without necessarily changing the code. The contract is much more powerful because it forces the separation of the contract from the implementation. This means that the contract is defined in an interface, and there is a concrete implementation which is bound to by the consumer using the same idea of the contract. The datamodel is abstracted out."
... later ...
"should use WCF when we need to communicate with other communication technologies (e,.g. Peer to Peer, Named Pipes) rather than Web Service"
From What's the Difference between WCF and Web Services?
WCF is a replacement for all earlier web service technologies from Microsoft. It also does a lot more than what is traditionally considered as "web services".
WCF "web services" are part of a much broader spectrum of remote communication enabled through WCF. You will get a much higher degree of flexibility and portability doing things in WCF than through traditional ASMX because WCF is designed, from the ground up, to summarize all of the different distributed programming infrastructures offered by Microsoft. An endpoint in WCF can be communicated with just as easily over SOAP/XML as it can over TCP/binary and to change this medium is simply a configuration file mod. In theory, this reduces the amount of new code needed when porting or changing business needs, targets, etc.
ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Basically you can see WCF as trying to logically group together all the different ways of getting two apps to communicate in the world of Microsoft; ASMX was just one of these many ways and so is now grouped under the WCF umbrella of capabilities.
Web Services can be accessed only over HTTP & it works in stateless environment, where WCF is flexible because its services can be hosted in different types of applications. Common scenarios for hosting WCF services are IIS,WAS, Self-hosting, Managed Windows Service.
The major difference is that Web Services Use XmlSerializer. But WCF Uses DataContractSerializer which is better in performance as compared to XmlSerializer.
Web Service
is based on SOAP and return data in XML form.
It support only HTTP protocol.
It is not open source but can be consumed by any client that understands xml.
It can be hosted only on IIS.
WCF
is also based on SOAP and return data in XML form.
It is the evolution of the web service(ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ.
The main issue with WCF is, its tedious and extensive configuration.
It is not open source but can be consumed by any client that understands xml.
It can be hosted with in the applicaion or on IIS or using window service.
Basic and primary difference is, ASP.NET web service is designed to exchange SOAP messages over HTTP only while WCF Service can exchange message using any format (SOAP is default) over any transport protocol i.e. HTTP, TCP, MSMQ or NamedPipes etc.
What is the difference between web service and WCF?
Web service use only HTTP protocol while transferring data from one application to other application.
But WCF supports more protocols for transporting messages than ASP.NET Web services. WCF supports sending messages by using HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ).
To develop a service in Web Service, we will write the following code
[WebService]
public class Service : System.Web.Services.WebService
{
[WebMethod]
public string Test(string strMsg)
{
return strMsg;
}
}
To develop a service in WCF, we will write the following code
[ServiceContract]
public interface ITest
{
[OperationContract]
string ShowMessage(string strMsg);
}
public class Service : ITest
{
public string ShowMessage(string strMsg)
{
return strMsg;
}
}
Web Service is not architecturally more robust. But WCF is architecturally
more robust and promotes best practices.
Web Services use XmlSerializer but WCF uses DataContractSerializer. Which is
better in performance as compared to XmlSerializer?
For internal (behind firewall) service-to-service calls we use the net:tcp
binding, which is much faster than SOAP.
WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25%
faster than .NET Remoting.
When would I opt for one over the other?
WCF is used to communicate between other applications which has been developed on other platforms and using other Technology.
For example, if I have to transfer data from .net platform to other application which is running on other OS (like Unix or Linux) and they are using other transfer protocol (like WAS, or TCP) Then it is only possible to transfer data using WCF.
Here is no restriction of platform, transfer protocol of application while transferring the data between one application to other application.
Security is very high as compare to web service
The major difference is time-out, WCF Service has timed-out when there is no response, but web-service does not have this property.