I am building an ASP.NET website which will collect data from a user and submit it to a 3rd party webservice. The webservice is somewhat unreliable and for this reason there is a backup service.
If a call to the primary service fails (timeout or some other error) then I need to flip a bit in a static class which will trip the system to use the secondary service.
At this point, I need to start polling the primary service (with dummy data) to see if it is back up (at which point I will receive an OK code in return). At this point I need to flip the bit back so that the website starts using the primary service again.
I've had a read of this Should I use a Windows Service or an ASP.NET Background Thread? and I think that separating out the code into a Windows Service would be the cleanest method of performing the polling, but then how would I communicate with the web appication.
One thought I've had is to expose a webservice that the Windows Service could use to communicate into the webapp but this seems both messy and over-kill.
I'd appreciate your thoughts and experiences performing similar tasks.
Thanks
I think the Windows service is the way to go, definitely.
As for the communication between the service and your web site, the best answer depends on the size and scale of your solution. If you are building something that needs to be reliable, I'd suggest you implement some sort of queue between your ASP.NET site and your Windows service. You have a lot of options here too, depending on budget and ability: BizTalk, MSMQ, and SQL Server queues (SSIS). Alternatively if you are looking for something smaller scale, I'd recommend you just stick it into a database table somewhere.
I would avoid using files on the file system because you will encounter issues with file locks and multithreading. I would also avoid directly communicating with the service because you risk losing the in-memory queue if the service fails for any reason.
Edited to add:
If reliability isn't a concern here, you could use a WPF named-pipes hosted service for communication between your website and your Windows service. This avoids much of the overheads normally involved in classic Web Services and is surprisingly quick. The only down-side is that self-hosting a WPF service is tricky and can be difficult to keep the service up.
Related
I want to create a program for my desktop and an app for my android. Both of them will do the same, just on those different devices. They will be something like personal assistants, so I want to put a lot of data into them ( for example contacts, notes and a huge lot of other stuff). All of this data should be saved on a server (at least for the beginning I will use my own Ubuntu server at home).
For the android app I will obviously use java and the database on the server will be a MySQL database, because that's the database I have used for everything. The Windows program will most likely be written in of these languages: Java, C#c C++, as these are the languages I am able to use quite well.
Now to the problem/question: The server should have a good backend which will be communicating with the apps/programs and read/write data in the database, manage the users and all that stuff. But I am not sure how I should approach programming the backend and the "network communication" itself. I would really like to have some relatively easy way to send secured messages between server and clients, but I have no experience in that matter. I do have programming experience in general, but not with backend and network programming.
side notes:
I would like to "scale big". At first this system will only be used by me, but it may be opened to more people or even sold.
Also I would really like to a (partly) self programmed backend on the server, because I could very well use this for a lot of other stuff, like some automation features in my house, which will be implemented.
EDIT: I would like to be able to scale big. I don't need support for hundreds of people at the beginning ;)
You need to research Socket programming. They provide relatively easy, secured network communication. Essentially, you will create some sort of connection or socket listener on your server. The clients will create Sockets, initialize them to connect to a certain IP address and port number, and then connect. Once the server receives these connections, the server creates a Socket for that specific connection, and the two sockets can communicate back and forth.
If you want your server to be able to handle multiple clients, I suggest creating a new Thread every time the server receives a connection, and that Thread will be dedicated to that specific client connection. Having a multi-threaded server where each client has its own dedicated Thread is a good starting point for an efficient server.
Here are some good C# examples of Socket clients and servers: https://msdn.microsoft.com/en-us/library/w89fhyex(v=vs.110).aspx
As a side note, you can also write Android apps in C# with Xamarin. If you did your desktop program and Android app both in C#, you'd be able to write most of the code once and share it between the two apps easily.
I suggest you start learning socket programming by creating very simple client and server applications in order to grasp how they will be communicating in your larger project. Once you can grasp the communication procedures well enough, start designing your larger project.
But I am not sure how I should approach programming the backend and
the "network communication" itself.
Traditionally, a server for your case would be a web server exposing REST API (JSON). All clients need to do http requests and render/parse JSON. REST API is mapped to database calls and exposes some data model. If it was in Java, it would be Jetty web server, Jackson Json parser.
I would really like to have some relatively easy way to send secured
messages between server and clients,
Sending HTTP requests probably the easiest way to communicate with a service. Having it secured is a matter of enabling HTTPS on the server side and implementing some user access authentication and action authorization. Enabling HTTPS with Jetty for Java will require few lines of code. Authentication is usually done via OAuth2 technique, and authorization could be based on ACL. You may go beyond of this and enable encryption of data at rest and employ other practices.
I would like to "scale big". At first this system will only be used by
me, but it may be opened to more people or even sold.
I would like to be able to scale big. I don't need support for
hundreds of people at the beginning
I anticipate scalability can become the main challenge. Depending on how far you want to scale, you may need to go to distributed (Big Data) databases and distributed serving and messaging layers.
Also I would really like to a (partly) self programmed backend on the
server, because I could very well use this for a lot of other stuff,
like some automation features in my house, which will be implemented.
I am not sure what you mean self-programmed. Usually a backend encapsulates some application specific business logic.
It could be a piece of logic between your database and http transport layer.
In more complicated scenario your logic can be put into asynchronous service behind the backend, so the service can do it's job without blocking clients' requests.
And in the most (probably) complicated scenario your backend may do machine learning (for example, if you would like you software stack to learn your home-being habits and automate house accordingly to your expectations without actually coding this automation)
but I have no experience in that matter. I do have programming
experience in general, but not with backend and network programming.
If you can code, writing a backend is not very hard problem. There are a lot of resources. However, you would need time (or money) to learn and to do it, what may distract you from the development of your applications or you may enjoy it.
The alternative to in-house developed of a backend could be a Backend-as-a-Service (BaaS) in cloud or on premises. There are number of product in this market. BaaS will allow you to eliminate the development of the backend entirely (or close to this). At minimum it should do:
REST API to data storage with configurable data model,
security,
scalability,
custom business-logic
Disclaimer: I am a member of webintrinsics.io team, which is a Backend-as-a-Service. Check our website and contact if you need to, we will be able to work with you and help you either with BaaS or with guiding you towards some useful resources.
Good luck with your work!
I have an existing application (WPF) that monitors OPC Servers and alarms. There is a requirement for this to be accessible via a browser so that users can view the status of alarms etc remotely. I'm feeling out of my depth (I'm not a Web developer) and I just need some advice on the best technology to accomplish this.
I've written several WCF Services, but all these have done is, via a function call, crunch some data sending back a result.
This 'service' will have to be persistent and able to be interrogated by x number of clients. For example, a client will need to be able to connect, stay connected and be informed of events as an when they happen. This has been a major problem in the past when I've developed WCF services (channel faults etc) and I've learnt to only keep a connection open for as long as it's needed. Is a WCF Service the best option in this case (as opposed to a normal Window's Service)
I need to be able to 'push' information from the service to clients. So, someone navigates to a webpage, the page shows in realtime, what is happening in the service. Do I need to use timers since this could be big problem if session state cannot be maintained.
I've read about Observer Design Pattern, but can this be implemented in ASP.net and how would ASP connect (and remain connected) to a remote windows service? Again, do I have to resort to timers?
I apologise it this appears vague, but the situation boils down to the following:
A process that's continually running (somewhere), receiving connections from remote clients (desktop/web), and then keeping the clients informed as events (alarms going off etc) occur.
I need to implement simple file watcher utility. I have decided to implement this in a simple windows service which will internally use FileSystemWatcher. The purpose is to monitor given directory path (or ftp) and copy the file to some other server wherever new file comes in after checking some predefined logic
As I am using .net 3.5; client suggested me to use WCF. I have very less experience in WCF.
I am not sure how I can create WCF service which will function like WindowsService and can be deployed in services on windows server.
To be a futuristic is it a good idea to create WCF service instead of windows service, or I should insist on window service.
Windows Service != WCF
You can't create a WCF service that acts functions like a windows service. A WCF service waits for messages from third parties and acts on them, a windows service is a process that is always running in the background. WCF tries to solve the problem of separating out the communication mechanism (transport protocols such as Tcp, Http, Named Pipe, etc) from the service interfaces.
File Watcher Utility
While in theory it's possible to create a new Flat-File binding in WCF that "could" have it's address set to a file system location, one does not exist directly in the .NET framework. Looking at the Custom Bindings article on MSDN it's not immediately obvious to me how one would construct a File System binding. These are the defined transport options available:
TCP
HTTP
HTTPS
Named Pipes (IPC)
Peer-to-Peer (P2P)
Message Queueing (MSMQ)
Custom
If communication must be done through file drops, then WCF does not solve your problem.
Where WCF Might Work
What the client might have meant is to create a WCF endpoint that does the copy the file to some other server wherever new file comes in after checking some predefined logic, but you would still want to have a windows service with a FileWatcher monitoring the input directory.
If you have multiple clients that need to be able to perform that same logic and then send the output to that other server then it might make sense to make the WCF service, otherwise it's over-engineered at this point.
You should choose the simplest option until you find a need to change, with the simplest option being a Windows Service.
There is a coding principle call YAGNI (you ain't gonna need it) that applies in this case as simply wrapping something up in a WCF service would do nothing but add unneeded complexity for the majority of cases. Simply put do the minimum viable solution and extend only when you need to.
PS. If you are using the FileSystemWatcher over network shares note that there are documented problems with it and you should use a combination of a poll + FileSystemWatcher. There are lots of explanations on Stack Overflow about it.
In your use case, the Windows Service makes a lot more sense and I think that to be the more appropriate solution. You need something that is always running and monitoring a directory and thats exactly the use case which Windows services are very good at.
I would consider talking to the client and explaining the Windows Services are the more appropriate solution to this kind of use case. Also, windows services are not old hat, they are there to solve exactly these kinds of use cases and WCF / windows services complement each other.
Both features have Service in their names by they have virtually nothing in common.
A Windows service runs constantly on a single machine.
A WCF service is code than can be called remotely by other machines.
It simply depends on what you need to do. A Windows Service and a "WCF service" have little in common.
The question here is whether you need a HTTP endpoint or not. If you do, you could even host a WCF service in your windows service to provide that. Keep in mind that a WCF is only used as a way to communicate between applications.
Reading your description, though, it doesn't seem like you need it.
WCF Service in a Managed Windows Service
We have a core windows service hosting around 9 WCF service and acting as a client to another 3 WCF services. We have a front-end website that communicates with this windows service through WCF.
At somepoint, the windows services is executing some heavy operations which results in 100% CPU utilization, usually split 60-40 between the windows service and SQL server.
This is where the WCF connection/requests between the website times out, and this results in a very non responsive UI.
I am looking for a way to make sure any UI-related WCF calls gets executed anyway and takes the highest priority.
Our main problem is that we need to stick with this deployment scenario, where the windows service, the website and SQL server are all running on one machine. We are required to maintain a responsive UI even with a 100% CPU utilization. I am not sure where to start looking for a fix for that ...
It sounds like you should split your service endpoint onto two separate hosts, one for high volume, or process-intensive operations and one for low latency operations. The high-volume endpoint would process from a queue offline, and the low-latency endpoint would handle requests synchronously from the UI.
The kind of problems you are having are typical of when you try to balance the conflicting resource needs of high volume and low latency together in the same process.
If you cannot scale out in this way then I can't really suggest much you can do about it and must apologize for not answering your question directly.
Another thing you could look at is moving everything asynchronous and using a pattern such as CQRS to provide separation between your read and write requirements.
I need to find the most efficient way to communicate from an asp.net web server and a windows C++ application. The windows application does not have any permission to access the database of the asp.net web server.
When the user presses a button, that action with some bytes should be received by the C++ application.
In return, after processing the data on the C++ application, it will send back the result to the web server.
The only way I can think of at the moment is as following:
The asp.net web server will have two web service methods:
the C++ application will call that web service for a method for an interval. if there is a change, then the C++ application will process.
after the C++ application finished its process, it will call a method on that web service to inform about the result.
Any other ways to solve this kind of communication?
Thanks in advance.
If the C++ Application is also on Windows, named pipes would be a good solution. They can be configured to be durable so they can queue messages if either side is not ready to receive the message and they are quite easy to use. They basically look like files that you can read or write from and the data appears on the other side of the "pipe".
Take a look at the documentation (C++) here: http://msdn.microsoft.com/en-us/library/aa365781(v=VS.85).aspx
On the ASP.NET side you would use .NET API's. Here's a nice example to get you started: http://msdn.microsoft.com/en-us/library/bb546085.aspx (This example includes both client and server code.)
Named pipes would be a great solution if the C++ application is located in the same physical server as the ASP.NET application. In that case the OS would be just moving memory between processes for you so it could be very quick.
Additionally, I would configure the C++ Application as a Windows Service so it's always available and can be restarted when the server it's running on is restarted. If keeping it running is very important you could integrate Performance Counters and then have your ops team monitor the counters to make sure it is operating within expected thresholds.
The C++ application can also make a simple GET or POST request with enough information that the webserver can handle in case you don't want to expose a webservice.
You could use network sockets. It's been a long time since I have done anything with them so I can't be much help. Research Winsock (aka Windows Sockets API).
You could use WCF services and connect to them using your C++ client. You will have to research consuming WCF services from C++ client.
As #parapura suggested you could use simple HTTPRequest get & post methods. You could create your own http handler for these request to customize the response.
As you suggested you could use simple web services.