what is difference between the WCF proxy object and the normal class object and service object (actual WCF service object) in detail ?
Is there any functionality which can be performed on class object and which cannot beperformed on WCF proxy.
Your client proxy is a usual .NET class which is inhereted from ServiceModel.ClientBase class. When you create proxy, .NET environment just adds the logic of consuming your service methods so as if they are locals. Proxy contains the dublicates of your service methods and some constructors, where you can define bindings, endpoints and so on. When you call method in proxy - it opens the chanel, creates a message and sends it to the server. That is what proxy does. It does not contais the logic of your methods.
You service class - is also a usual .NET class, marked with some special service attributes. When you start your service, the .NET environment begins to listen for the messages, sent by clients. And when it recives such messages - it unpacks them, creates the instance of your service class (or uses created already) and executes the method. Then the result is send back in return message.
So client proxy does not contains any logic - it is used only to send messages with info of what method it called and what params are used. The service class contains all the logic of your methods.
Related
I am consuming a WCF service in my .net core API project and I used the following steps:
The binding in WCF service (for testing) <add binding="basicHttpsBinding" scheme="https" />
Created a proxy class using https://learn.microsoft.com/en-us/dotnet/core/additional-tools/dotnet-svcutil-guide?tabs=dotnetsvcutil2x (This created a proxy which has an interface IService1 and calls Service1Client).
In the startup class I have bound the interface with the class services.AddSingleton<IService1, Service1Client>();
The method endpoint in the WCF service gets the data form the database according to the parameter passed to consume the WCF service.
I am not sure which one I should use, services.AddSingleton or services.AddTransient, because I am not sure what the proxy class is using to call the method.
If I create a single instance, will it be locked?
I have done a Jmeter test with 1000 rows in the database and 1000 rows from csv as a parameter to consume the API, but did not find any lock and all were successful under 3 minutes.
You can view the servicereference.cs file to see which method in the wcf service is called by the proxy class.
Then we need to instantiate the proxy class and call the WCF service through the instantiated proxy class:
ServiceReference.Service1Client service1 = new Service1Client();
By this documentation in a web api a single httpclient should be instantiated:
https://learn.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client#create-and-initialize-httpclient
Of course if you have multiple target services, with different endpoints, an HttpClient per service is needed (you set the base address in the HttpClient)
In your case your generated client should use an HttpClient under the covers. If you can determine if the whole genrated client is thread safe then you can inject the client as a Singleton, if not you should add it as scoped
I have a WCF service that calls another SOAP service (that I don't have control over). I would like to return the dependent services proxy types to my services clients.
I have done this manually by adding DataContract and DataMember attributes to the proxy classes.
Is there anyway to automate applying these attributes to these proxy classes?
So the problem I was having was that when using add service through visual studio 2015, it passes a flag that generates IPropertyChangedNoify on the objects which when trying to reuse a proxy class that has been generated from an external source this would cause WCF test client to throw an exception when adding a service that was returning such type.
My Semi solution so far was to use svcutil manually.
svctuil /namespace:*,<MyNameSpace> path-to.wsdl /out:MyClass.cs
I'm now able to add my service that uses an external proxy class as a return type.
The next problem I'm having now is that WCF test client won't let me call/test the method, because I'm using this type. WCF hover note says "WCF test client doesn't support this method because it uses 'MyCustomType'". And the method is grayed out.
I'm getting closer, to the solution.
I am not sure this is even possible to be honest,
I am wondering if there is a way of removing the use of the config file without having to override the creation of the client proxy. Let me give an example:
In a client app we have a WCF DAL project. This is a wrapper for their WCF Server for the client app to consume. At present the client app would need all the bindings and endpoints given in the config file and would normally (in our projects) do something like the following to wrap the WCF service:
public MyObject GetMyObject(int id)
{
using(var service = new MyObjectDataServiceClient())
{
return service.GetMyOBject(id);
}
}
This would create the call to the server and get an object back. If the client app didn't have the bindings and endpoints it would blow up. We could change each creation of the data service client to create the binding and endpoint, or create our own chanelfactory to do this for us but this means changing the current WCF DAL layer code.
My goal is to try and create a way of inserting a process into the WCF DAL layer that will handle the bindings and endpoints without the consuming code having to change, whilst removing the need for the config file.
My thoughts so far were to try and use a TT file so that it would create a partial class of the data service client and override the channel factory part. This failed because of the constructor call for the data service client goes straight into the abstract class (System.ServiceModel.ClientBase<T>) and tries to get the config stuff out. I could not find a way of stopping it looking in the config via this partial class and not changing the WCF DAL service layer.
If you have the binding and the endpoint at the DAL, you can use a different constructor of the client class (one which takes the binding + endpoint address). That constructor completely bypasses configuration, so you don't need to have anything in config.
So I already have a working implementation of StructureMap with the WCF service (including custom instance provider, behaviors, etc.)
When I try to have an object that is instantiated only once per user request, I use the InstanceScope.HttpContext and it throws because the context is null.
Do anyone have a proper way of doing that?
On the server-side of the WCF service? By default, WCF has nothing to do with ASP.NET and thus all your HttpContext etc. aren't there.
By default, your WCF services will be called on a "per-call" basis, e.g. each request gets a brand-new, separate, totally isolated instance of your service class. Why not just put those things into the service class as internal fields??
Or you might want to check out this blog post on how to abstract request state and providing sample implementations for ASP.NET (using HttpContext.Items) and WCF.
I want to know what happens when I create an instance of a ServiceHost class?
What it does ?
The ServiceHost (whether instantiated by yourself directly, or whether you delegate that job to IIS/WAS) is the runtime environment for your WCF class - which is just a simple .NET class after all (which needs to run somewhere).
The ServiceHost basically provides all the "plumbing" around your WCF service - creating the endpoints and the listeners on those endpoints to listen for messages and catch those as they come in; it provides the whole channel stack from the transport level through all the layers of WCF up through deserializers on to the dispatcher which then decides which class and which method on that class to call, and so on.
In WCF, in your service class, you write only the actual busienss logic of your service - the ServiceHost and all its classes around it handle all the nitty-gritty details of the receiving of messages and sending back of responses etc.
Marc
Typically the ServiceHost class is used to host your WCF services in a standalone app (such as a console app), if you are not using IIS or Windows Activation Service (WAS).
In simple terms it will deal with the COMs (listening for messages for a particular service).
You can also derive from ServiceHost to add customization if required, in combination with a specialization of ServiceHostFactory.
See MSDN example.
HTH
Phil'
It creates channels that are responsible for things like reliable transfer and security. It listens for incoming messages and calls your operation methods.