I have a simple web application that allows users to upload a file to the server and store the data in the Database.
There will be a decoupled service (probably WCF) which needs to act upon the data, but i am not sure what the best mechanism is to alert the service? Is it a good idea for the WCF service to poll the database every few minutes to check for new data? Or should i be looking at other patterns (?) to better accomplish this task? using Events perhaps?
I have not done anything like this before so looking for some guidance to start off with.
Thanks
Why don't you want to call the service from the web application in the same code that performs the upload? Typically, an application calls a service, not the other way around.
Polling from client side is an option. Or you can have a non duplex service for file upload and have a duplex service for callback on the progress of the upload.
Also Take a look this sample which uses non duplex channels to track file upload and download.
Related
i have a bit theoretical question.
When creating web applications, there is difference to desktop applications with working and active connection to database. So im curious if there is some solution, which can provide more desktop-like access to database e.g. transactions on asynchronous requests from client (web browser)?
edit:
So i figured out, that there can be a transaction process of asynchronous request, from client. Is there solution, which can provide it in web apps?
e.g I have assynchronou ajax call, which consist of multiple operations, and i wana to process them as transaction. If everything is okay, operations will be all done. But if one of them fail, just rollback it. Like its in DB. Is it possible?
edit2: maybe im wrong and the issue is not about ajax, but about whole web applications, but i dont think there is a way how to make a asynchronnous request from web client.
Transaction need continuous connection to database. To make it work with web application you need a platform which allow the application to run continuously independent of client request. Java servlet is best fit, php is a no-no. So I asume you will use java servlet.
In java servlet, you can create a db transaction, create an id for it, and then store them in a static variable or in the provided application-wide object, context. Then, return the id to the client.
When the client want to send another request, make it send the id. The application then can locate the transaction variable based on the id. As long as the application doesn't restarted between the two requests, the transaction is still there and active.
Because web application don't know when the user leave the application, you must create a mechanism to check the transactions periodically, and then rollback it if the user leave them for a specified time period.
The database has no knowledge of who is connected outside of authentication.
I'm designing a database monitoring application. Basically, the database will be hosted in the cloud and record-level access to it will be provided via custom written clients for Windows, iOS, Android etc. The basic scenario can be implemented via web services (ASP.NET WebAPI). For example, the client will make a GET request to the web service to fetch an entry. However, one of the requirements is that the client should automatically refresh UI, in case another user (using a different instance of the client) updates the same record AND the auto-refresh needs to happen under a second of record being updated - so that info is always up-to-date.
Polling could be an option but the active clients could number in hundreds of thousands, so I'm looking for a more robust and lightweight (on server) solution. I'm versed in .NET and C++/Windows and I could roll-out a complete solution in C++/Windows using IO Completion Ports but feel like that would be an overkill and require too much development time. Looked into ASP.NET WebAPI but not being able to send out notifications is its limitation. Are there any frameworks/technologies in Windows ecosystem that can address this scenario and scale easily as well? Any good options outside windows ecosystem e.g. node.js?
You did not specify a database that can be used so if you are able to use MSSQL Server, you may want to lookup SQL Dependency feature. IF configured and used correctly, you will be notified if there are any changes in the database.
Pair this with SignalR or any real-time front-end framework of your choice and you'll have real-time updates as you described.
One catch though is that SQL Dependency only tells you that something changed. Whatever it was, you are responsible to track which record it is. That adds an extra layer of difficulty but is much better than polling.
You may want to search through the sqldependency tag here at SO to go from here to where you want your app to be.
My first thought was to have webservice call that "stays alive" or the html5 protocol called WebSockets. You can maintain lots of connections but hundreds of thousands seems too large. Therefore the webservice needs to have a way to contact the clients with stateless connections. So build a webservice in the client that the webservices server can communicate with. This may be an issue due to firewall issues.
If firewalls are not an issue then you may not need a webservice in the client. You can instead implement a server socket on the client.
For mobile clients, if implementing a server socket is not a possibility then use push notifications. Perhaps look at https://stackoverflow.com/a/6676586/4350148 for a similar issue.
Finally you may want to consider a content delivery network.
One last point is that hopefully you don't need to contact all 100000 users within 1 second. I am assuming that with so many users you have quite a few servers.
Take a look at Maximum concurrent Socket.IO connections regarding the max number of open websocket connections;
Also consider whether your estimate of on the order of 100000 of simultaneous users is accurate.
I need to read the data from the COM port in a web application, so I have written a Windows Service for reading data from serial ports. Now I need to access that data in a web application. Can anyone tell me how to access it? Is using threads the best way to do this or not? What other possible ways are there?
upendra
Get your Windows Service app to store the data to disk (xml or SDF for example). Your Web application could then access the same data store...
An idea would be to use an .Net Queue to read the values from. Read more here: http://msdn.microsoft.com/en-us/library/system.collections.queue(v=vs.71).aspx
Your other options would be to write the data to a file or a DB but then you have to write your own logic to handle disposing of read data which the Queue functionality will take care for you.
Cheers,
Stefan
In similar scenario I used self-hosted WCF service within windows service. In this way you expose api to control the service and get information from it.
You can read more about WCF self-hosting in Michele Leroux's article : link
Suppose I have either an ASP.NET displaying my results, or a Silverlight client. And I'd like to show the current status of my server, or embedded device. (pretend the device reads temperature and humidity stats)
How should I send the status information from my device to the front end? Should I poll the device and save the results to SQL, Azure Table, or the like? (Azure is a technology that fits with this project for other reasons. That's why I mention it)
Or should I create a WCF service that polls the device directly and returns the current status.
What makes more sense?
In either ASP.NET or Silverlight you are going to have to poll from the client (web page or Silverlight app) to the backend to get the current status. In ASP.NET I'd look into doing this via an AJAX poll to a service using Javascipt (look at using Jquery or something similar to make this easier).
In silverlight you will need to have some sort of service configured to return the results and poll it using the Timer control running on a seperate thread.
You can also using a "push" binding within your silverlight app. Basically instead of you manually polling the server, the server will send you a push notification anytime it deems it necessary to let the client know of any change.
We’ve got a back office CRM application that exposes some of the data in a public ASP.NET site. Currently the ASP.NET site sits on top of a separate cut down version of the back office database (we call this the web database). Daily synchronisation routines keep the databases up-to-date (hosted in the back office). The problem is that the synchronisation logic is very complex and time consuming to change. I was wondering whether using a SOAP service could simply things? The ASP.NET web pages would call the SOAP service which in tern would do the database calls. There would be no need for a separate web database or synchronisation routines. My main concern with the SOAP approach is security because the SOAP service would be exposed to the internet.
Should we stick with our current architecture? Or would the SOAP approach be an improvement?
The short answer is yes, web service calls would be better and would remove the need for synchronization.
The long answer is that you need to understand the technology available for you in terms of web services. I would highly recommend looking into WCF which will allow you to do exactly what you want to do and also you will be able to only expose your services to the ASP.NET web server and not to the entire internet.
There would be no security problem. Simply use one of the secure bindings, like wsHttpBinding.
I'd look at making the web database build process more maintainable
Since security is obviously a concern, this means you need to add logic to limit the types of data & requests and that logic has to live SOMEWHERE.