I have created a WCF SOAP web service in C# and a C# application. Other users will work with the application and are trying to get information from a local database via the web service.
Now is it possible that the web service can go down. Then I want as quickly as possible, let's say getting an email.
I can let the application which is by the users sending an email when they don't get a connection with the web service, but there are more than 10.000 users. And I don't want to get 500 emails when there are 500 online.
Is there a better solution for getting an email when my web service is down?
I would suggest a sort of heartbeat program that runs on another server / location.
This will not only test the server, but also your internet connection for example;
Will work even when the power is down.
There are programs to do this already. The only I know is Microsoft System Center and Nagios.
There are a lot of monitoring software packages out there if you want a pre-made tool. The company I work for uses New Relic. (http://newrelic.com/server-monitoring).
If you add a simple function to your webservice, that simply returns true, you can call it periodically (maybe every minute?). If it times out, your service is down, and your monitoring program can email you.
Related
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.
I would like to write a Web Application that can interact with 3D Cad program for our company. So I was thinking that I would create a program that would be locally installed on the client machines which would send and receive data back and forth from Client App to Web App. I would like to use xml for moving the data back and forth too. Does anyone suggestions or can this even be done?
In this case you need 2 way communication between app and service. and for solving that there are two way:
use two service and they must be client of each other (Hard way)
use Duplex Services. (you can use WCF-Duplex services - it's not simple)
in this case you must handle too many issue's.(take look at this)
As example:
app need to notify self on your service and service save address of active client's. so every time service want's to call one of client, service must find client's address in active-client's and then call that.
Let me know if this help you.
I have an application that users were complaining that it hangs when the user trys to perform a certain action. I found it that it is hanging in a web service call. The web service is running on a remote server. I can't figure out how to debug into the web service through VS when the code is on a remote server.
How do I find out in the web service where exactly the code is hanging?
If you don't have access to the source of the web service then you're not going to be able to "debug" it. If you want to try to externally debug it then you can create a page that sends various inputs to it (some that should work, some that should error out, etc). You can then access this page in a browser that has developer tools (I would recommend Firefox w/ Firebug or Google Chrome) and then look at how long the calls are taking. Google Chrome will show you how long it took to send the request, how long it waited, how long it took to receive, etc. If it IS the actually web service and you don't have access to it then it would be odd that you were responsible for fixing this issue. I have a feeling though, if this is a robust web service, you're going to find that you're either having a networking issue or your sending it some invalid input or something along those lines.
If you do have access to the source code then simply run the web service locally and point your local version of the application at the local version of the web service. Any breakpoints you put in the web service will hang the application and you will be able to step through it just like you can non-web-service code.
In your own code, take a look at what is going on with the web service call. e.g Does it throw a fault? Timeout? Does it ever return a successful response? If not, are you sending valid data?
If the web service call is successful but just slow, consider how you might make your application appear to be more responsive. One possibility is to use Asynchronous Programming.
I am planning a SaaS system, to be written in C#, ASP.NET using WCF that has two separate components:
On a static IP web server in the cloud will be a web app, common to all clients.
Inside each client's office will be another app, installed on a server with IIS.
The site app will obviously be able to connect to the web services published on the web site. But here's the rub - I also want the web app to be able to initiate a connection to the site app... and the on-site server may not necessarily have a static IP. I can't control this, because we may have hundreds of clients at some point in the future, and we cannot limit our saleability by insisting that the customer has a server with fixed IP.
So, how to do this?
I could have the site apps "checking in" with the web every minute or so, to give the web app the possibility of responding with a "while you're here, please do x,y,z..." but that seems very inelegant. Also, if we're talking about hundreds of clients, I don't want to be bombarding my web server with all these "hi there!" messages if they're not actually required.
Is there a better way?
WCF? Here we go:
Use a message based approach (exchange message, no stateful method calls).
Clients connect to the server. Establish a HTTP-based TWO WAY CONNECTION. This way the server can call back to connected clients. This is standard WCF stuff and works well through NAT with version 4 of the .NET framework.
Voila. In case of a disconnect the client can re-connect, re-identify himself and gets the pending messages.
IIRC "push communication" is done by letting the client do a HTTP Request with an indefinate timeout. Then the server responds when he has something to say. After the respons the client immediately makes a new request.
It works out the same way like the server is making the connection and takes far less resources than polling.
Dynamic DNS is one possibility, but depends on your clients/customers.
If the site app is created by you, it only has to contact the web server when its address has changed (or when the site server/web app is restarted). Still, a keep-alive heart beat of, say, every 30 min. to 1 hour isn't a bad idea.
Edit: I think SNMP services may provide the answer but I'm not a networking expert. You'll have to do some digging or ask a separate question on stackoverflow.
What would you say about Comet technology?
Sounds like you'll definitely need some sort of registry on the server, then it could attempt to call out to the client apps if it needs work doing.
Generally it is client apps that check in with the server every X seconds - this is how Selenium grid works anyway. With a central hub with which clients register. When the hub receives a request to run some tests it passes the jobs out to the clients to perform.
You may not need the "checking in". The server could just attempt to call out to a registered client app until it finds one that is available.This way only the server would need a static address (could use a DNS name instead of an IP to make it more robust).
Also have a look at XMPP PubSub. This could be a more robust and standardised way to handle this.
In the end I decided to go with NetTcpBinding, for reasons best given by #Allon Guralnek here. It's worth clicking through and reading what he has to say...
i have the current scenario:
my app generates for each user an
valid system email address of form
lets say: uuid#website.com
when an user has a problem/question he can send an
email from any address to that
predefined system email address
the app should receive the emails sent by the user and process them(check for spam, insert in db)
in this scenario a possible first solution that i had in mind was to pool the emails addresses on a 15 minutes period, process them(spam or not spam) in an external desktop app(or similar) and insert them in a database.
because i want to do this in .net, C#, SQL server 2008, and it should run on a webserver is the below solution possible using WCF?
i create a WCF webservice that when an email is received by an email address it captures it and starts the processing procedure.
One problem i see with WCF from the start is that i don't think that it can auto react, the only way i used wcf until now was only for calling it directly and receiving a result. So i think another layer should be put between the email server and the wcf service and that layer should "react" when something is received.
the main idea is to process the emails as they arrive not to be pulled out of the inbox periodically.
any pointers? thank you
You are right. A web service cannot capture anything for you. You will have to call(using an .ashx/or etc) the web service. That is what the web services are for, to be called.
the app should receive the emails sent by the user and process them
It sounds like you are looking to develop an email client; if so, then how about:
Create an email client app (for instance here)
Create a windows service, to help process the mails.
Assuming that you've tailored the client program, the windows service would work-with the client, look for new messages, and processes them accordingly.
For email client examples, checkout:
This answer
And this article
If connecting to Exchange 2007 SP1 or later Exchange Web Services looks like the best approach:
Read MS Exchange email in C#