I am very very to WCF. Rather this is my first shot at WCF. I have a service that just works fine on my local system. I have the following requirement. I need to host the service in a clustered server environment. I will have a group of lets say 3 servers. How should I go about hosting the service? I want to host it in the IIS. Do I host the service on all three servers? If so how would they fall back in case the primary server is down for some reason. Can I have one single endpoint address pointing to the active server?
Thanks
If you write the code without using session state you can use a load balancer in front of the 3 servers to handle the clustering. Be sure to write the code in a way that it does not matter what server you are on when the call is executed, since it could be different one call to the next.
Related
I'm having trouble hosting multiple websites on different sub-domains using Service Fabric and OWIN.
Let's say I have four HTTP(S) servers on my Service Fabric cloud. Each of them are running on a different port. So at some point of their initialization, they will respectively call:
Microsoft.Owin.Hosting.WebApp.Start("http://+:80/", UnsecureStartup);
Microsoft.Owin.Hosting.WebApp.Start("https://+:443/", MainStartup);
Microsoft.Owin.Hosting.WebApp.Start("https://+:4431/", ApiStartup);
Microsoft.Owin.Hosting.WebApp.Start("https://+:4432/", ExtrasStartup);
This all works fine. All requests are successfully fulfilled. All four ports serve the startups they've been assigned in their respective stateless services, and the HTTPS ones make use of the same certificate as set from ServiceManifest.xml in proper Service Fabric fashion. Here's a similar single-server setup.
We always planned to use sub-domains instead of different ports. Now we have our domain and we're trying to do the following:
Microsoft.Owin.Hosting.WebApp.Start("http://example.com:80/", UnsecureStartup);
Microsoft.Owin.Hosting.WebApp.Start("https://example.com:443/", MainStartup);
Microsoft.Owin.Hosting.WebApp.Start("https://api.example.com:443/", ApiStartup);
Microsoft.Owin.Hosting.WebApp.Start("https://extras.example.com:443/", ExtrasStartup);
The code above does run. All four stateless services start and go green in Service Fabric Explorer. Yet, every single request (both to http:80 and to https:445) is met with the same response:
Service Unavailable
HTTP Error 503. The service is unavailable.
Why does Service Fabric allow us to have multiple Owin servers, even on the same port, if it's not possible for me to select one based on hostname? Does anyone have any idea of how we can make this work?
Any help is greatly appreciated.
In my understanding, hostnames does not work very well with SF.
You have the following options as I see it:
1) You use different ports on your internal services and put a WAF in front of your SF Cluster and let that one handle SSL offloading, URL routing and NATing to your internal ports. This way you will only need 1 public IP.
2) You add more public IPs and let your public load balancing handle it. You will need 3 IP addresses for this, but since the first 5 IPs are free in azure, this wont cost you anything extra.
You probobly want to go with option 1 as it gives you easier certificate managing, better security and more flexibility but at the cost of $.
I am working with an Idea where I have created a WCF service and need to host it on two different servers with same port number and both of these WCF service is suppose to connect to same Database at back end, my question is it possible for me to execute this idea or it will create problem?
And if its possible,can anyone please guide me to helping documents or examples so that I can execute this task,
One of my confusion is, if I try to connect one table from Database(I have used Connected Architecture) via one WCF service and again there is call from another WCF service from other web server to hit same table then definitely it will be in mess, how I am going to handle this..???
My priority is only my WCF Service should not crash..
Thanks in advance,
This is a normal scenario, that there are several web servers hosting WCF services Connecting to the same database.
If you have several users calling a WCF service at the same time that Connects to a database, the database does not notice that the Calls are coming from one or 2 servers (except that there is not Connection pooling across 2 servers).
What you need to be carefull With is that you Lock data when it needs to be locked, and that you do not keep the Lock longer than necessary.
I have two applications using the same wcf service instance. These two applications will always be started in pairs, so I can have a second, third, or fourth instance of these two. Does this mean I need to have one wcf service being hosted by say a Windows Service, IIS, or console app using a common endpoint address for all four of the instance pairs? Or if I dynamically hardcode the endpoint addresses such that each individual pair has it's own and self host in one of the two applications, does that mean each pair has access to it's own service?
I could probably benchtop test this, but I figure someone with experience could save me quite a bit of coding time just trying to figure it out.
Update (for clarity):
The reason for this question is due to the particular situation I'm working with. The scenario is that the two applications involve one client exe that I am developing and a third-party exe that I have no control over. I can develop a dll that the third-party exe can load. Between my third-party app dll and the client exe the WCF service is intended to bridge the process space to allow the two to communicate transaction information. This will allow the client exe to control the third-party exe and the files it manages.
This is partly an answer partly a long comment. :)
One way to think of a WCF service is that it passes messages back and forth between two separate applications. At a very general level, although there are plenty of good reasons to make a stateful service, it is generally accepted that it is better to be stateless. This means that each time you call it you pass all the info it needs to do what it does, and the service does not need to remember what was done earlier.
The fact that you are worried about separate instances suggests to me that your service has state. I do not think multiple endpoints is the way to go for your situation.
I would suggest that when an application "pair" starts up the first thing it could do would be to request a unique ID from the service. From that point on all messages to the service would contain this ID and the service would process them accordingly. If the service application is maintaining state it would use this ID as a key to identify what information to access to process the call.
At this point you end up with One service application on one server and multiple client applications which is how most WCF systems are designed.
Updated, I think you should google "WCF: Instance Management Per-Call and Per-Session"
Your client should be able to open a connection from the client and keep it open. WCF will automagically create a new instance on the server for you. This would mean you don't need the "application pair ID" but you would need to keep the session open.
I have a need to install an "agent" (I'm thinking it will run as a Windows Service) on many servers in my network. This agent will host a WCF service with several operations to perform specific tasks on the server. This I can handle.
The second part is to build a control center, where I can browse which servers are available (the agent will "register" themselves with my central database). Most of the servers will probably be running the most recent version of my service, but I'm sure there will be some servers which fail to update properly and may run an out dated version for some time (if I get it right, the service contract wont change much, so this shouldn't be a big deal).
Most of my WCF development has been Many Clients to a Single WCF Service, now I'm doing the reverse. How should I manage all of these EndPoints in my control center app? In the past, I've always had a single EndPoint mapped in my App.config. What would some code look like that builds a WCF EndPoint on the fly, based on say a set of string ip; int port; variables I read from my database?
This article has some code examples on how to create an end point on the fly:
http://en.csharp-online.net/WCF_Essentials%E2%80%94Programmatic_Endpoint_Configuration
WCF4 has a Discovery API built-in that might just do everything you need.
Is there anyway to configure a WCF service with a failover endpoint if the primary endpoint dies? Kind of like being able to specify a failover server in a SQL cluster.
Specifically I am using the TCP/IP binding for speed, but on the rare occurrence that the machine is not available I would like to redirect traffic to the failover server. Not too bothered about losing messages. I'd just prefer not to write the code to handle re-routing.
You need to use a layer 4 load balancer in front of the two endpoints. Prob best to stick with a dedicated piece of hardware.
Without trying to sound too vague but I think Windows Network Load Balancing (NLB) should handle this for you.
Haven't done it yet with WCF but plan to have a local DNS entry pointing to our Network Load Balancing (NLB) virtual iP address which will direct all traffic to one of our servers hosting services within IIS. I have used NLB for this exact scenario in the past for web sites and see no reason why it will not work well with WCF.
The beauty of it is that you can take servers in and out of the virtual cluster at will and NLB takes care of all the ugly re-directing to an available node. It also comes with a great price tag: $FREE with your Windows Server license.
We've had good luck with BigIP as a solution, though it's not cheap or easy to set up.
One nice feature is it allows you to set up your SSL certificate (and backdoor to the CA) at the load balancer's common endpoint. Then you can use protocols to transfer the requests back to the WCF servers so the entire transmission is encrypted.