I have WCf application with4 webserivce with indivdual Interface as contract. so do i need to define endpoint, serviceBehaviors for each web service in config file? to access individual web service in single or multiple web applications?
Each Webservice can be exposed using one (i.e. one endpoint for all webservices) or multiple endpoints (i.e. one for each webservice). Each endpoint will have behavior,binding etc
If you go with 1st option client will have one proxy-contract for an endpoint.
In your case you can expose all four service interface using single endpoint.
Each service must have a corresponding address, endpoint and binding definition. If you are using config files each service must be declared in a separate <service> node in the <services> collection.
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 seen people decorate their config file with multiple endpoints in WCF service. is there any reason. when one endpoint is ok then why two or more endpoints are require?
tell me small situation when multiple endpoints is required.
Scenario for multiple endpoints:
Service wants to expose more than one type of binding.
Service wants to expose more than one contract on the same binding.
Service wants to expose same binding and contract on different addresses.
http://debugmode.net/2010/05/25/multipleendpoint/
I have a WCF service which programmatically creates its endpoints rather than using a config file - I'm looking into this as our field engineers are prone to break XML easily and we may use different types of binding in different scenarios.
This works well in self-hosted environments (console app, windows app) and as a Windows Service.
Can I do this with a service in IIS or do I have to provide a .SVC file for each endpoint ?
Also will the endpoint address from the client end have to include the .SVC extension ?
This is not a service intended to be used by third parties, only by our client components. We may expose parts of our API later but not initially.
If you're using .NET Framework 4.0 (and later), you can use the ASP.NET routing integration to define a service using a custom ServiceHostFactory implementation. A few things you'll need:
In web.config, set the attribute aspNetCompatibilityEnabled on the <system.serviceModel / serviceHostingEnvironment> element to true
Add a global.asax / global.asax.cs file, and in the Application_Start add a new ServiceRoute to the ASP.NET RouteTable.Routes collection. The service route requres you to define a new service host factory, where you can define your endpoints programmatically.
With that you'll be able to have endpoints without the ".svc" in their addresses. You can also use the service host factory without using routes, by creating a .svc file for each service (not endpoint), and using the Factory attribute in the <%# ServiceHost directive.
For more information about service host factories, check the post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/06/14/wcf-extensibility-servicehostfactory.aspx.
I was wondering how a client project in Visual Studio could reference a WCF service that doesn't have a mex binding. Whenever I remove the default mex binding in any sample WCF service, the client apps cannot find the service and in the auto-generated comments, it's recommended that in production environment, mex binding should be removed. Then how are the client apps supposed to find the service and reference it?
If you have access to the assemblies which contain the types which define the service contract, operations, and data contracts, then you can just create a proxy on the fly using ChannelFactory. In this instance you would not need to retrieve any service metadata as you already have access to all the information you need to call the service.
For example
// Create service proxy on the fly
var factory = new ChannelFactory<IMyServiceContract>("NameOfMyClientEndpointInConfigFile");
var proxy = factory.CreateChannel();
// Create data contract
var requestDataContract = new MyDataContract();
// Call service operation.
var responseDataContract = proxy.MyServiceOperation(requestDataContract);
It also helps if you have access to the service-side config file so you can copy the endpoint details out of there into your client config.
The mex endpoint is a necessary part of WCF SOAP services. It is what enables client toolkits to pull down the WSDL and auto-generate proxy classes. As you point out, without it, clients have no way to get the information to consume the service. If you want clients to be able to consume and find your service, you should leave it available when your service is in production.
When I deploy the same service on different machines as they have different information that I need , how can I use my client gracely to consume these service .
You need to define the service endpoint you want to connect to in your client's config.
You cannot define a list of endpoints - if you need load-balancing features, you need to implement those on the server side and "hide" them behind a single service endpoint.
With .NET 4 and WCF 4, you have new capabilities you could check out:
WCF 4 has a new routing service which you can use to get called on a single URL, and you have control over how to "distribute" those calls to the actual back-end servers
WCF 4 also supports dynamic service discovery, so you could potentially just "yell out onto the network" and get back one service endpoint address that supports your contract you're interested in
Resources:
Developer's Introduction to WCF 4
10-4 Show on WCF 4 Routing Service
Content-based routing with WCF 4
WCF 4.0 Routing Service
WCF 4.0 Routing Service - Failover
Using WS-Discovery in WCF 4.0
Ad-hoc Discovery with Probing messages
It sounds like you want to connect to BOTH servers. you say they have different data that you need. Well, if you already know how to make a client to one of them, the easiest way is to define an entire other client to access the second one. You can define as many clients as you want in the config file. Then just call them both in code.