I want to make a form where people can sign up for a course. Number of people for a course is limited. I want to make a page where user can see how many places are still available and that number is dynamically updated, so if another user signs for a course the other one sees change. When number of available places reaches 0 the signup button should be disabled. Such task should be easy to implement but I am afraid it is not. I suppose some Ajax will be involved but how to handle server side counting? WebServices? I have a problem to design a logic behind all of this.
The technology/technique you're looking for is called Server Push.
Basic idea: Client should respond to some events happening on Server.
Possible solutions:
Polling some server action via AJAX in a timely fashion;
Keeping long-running AJAX request open on server-side until timeout occurs or event happens, then process acquired result on client (determine if it was server action or just timeout), reestablish connection from client if necessary.
and a couple of other solutions which are basically variations of the above two. Also solution will much depend on server-side technology you're using.
Google has a short yet very informative article on what this technique is and how it can be implemented here. It's (almost) technology agnostic so it should help you to understand concepts and possible solutions.
I'd use a database on the server. For the "courses" table, have an associated table containing the "bookings". Add them up in a SQL query.
Related
Given that the web is a very one-way synchronous architecture, is there any benefit to an NSB-enabled web application using MVC4?
I love the fault tolerance and ease of development that comes with NSB, but since the technology is all about one-way asynchronous messaging, how can I design my application around it in such a way that the user doesn't (often) notice their commands not being complete by the time a postback occurs? What paradigm should I adopt in designing my UI to naturally fit the curvature of NServiceBus?
Indeed, it seems NSB is an unnecessary complexity between a website and its SQL store because users always assume the "work" is done when their browser is done refreshing. Am I wrong in this regard?
Edit: I've seen other solutions whereby each command handler publishes an event when the work is done by the NSB service, and that event handlers on the ASP.NET project will create "stub files" that a Java-script enabled page is constantly polling to indicate that an operation completed. Is this the only way to bridge the gap between one way sync and async platforms?
NServiceBus fits in quite nicely with any web front-end. You are just going to need to be aware of how asynchronous message processing affects your UI. In most instances one could simply indicate to the user that the request has been accepted and will be processed. But in other cases you may need to forgo eventual consistency for immediately consistent.
For instance, for user registration I typically check availability of the user name and then register the user immediately but I send a command to e-mail the activation message so that the user does not have to wait for that. The user will eventually receive their e-mail. So a message is displayed indicating that an e-mail will be sent and that they need to click the activation link even though the mail may only be sent in 5 minutes.
Another example is an application where the user could convert various document formats to TIFF. The request would be sent and the web front-end would poll to wait for the result of the conversion and then display the converted pages.
So it is going to affect how your UI/UX works. It is definitely still useful and in some instances makes your life a whole lot easier.
In my case I used my FOSS Shuttle Service Bus: http://shuttle.codeplex.com/ --- but the concepts apply anyway.
NServiceBus has hooks into the typical MVC web application that allow you to cause the user's postback to wait until a response arrives over the bus. See the AsyncPages sample to see how it's done.
We are considering a web application to provide users with frequent updates to system data. Initially, the data would be limited to system pressure, flow, etc. but the concept could apply to many areas of our business. The data is stored in SQL Server.
The question is, how do we force a table on a webpage to update when new data is inserted into the database. For example, a pump reports a new flow value. The updates to the database can be throttled but realistically we're looking at a new update every minute or two for our purposes.
This seems like a case where push notification would be used but what can we use with ASP.NET? HTML5 is out of the question although we've watched some push demos with web sockets.
Is there a push technology we can use for ASP.NET?
If not, or if it's a better solution, should we poll the database with jQuery / AJAX? Any suggestions for samples we should look at?
Using HTTP you can only send responses to client queries, so pushing content without web sockets is not possible.
The most common solutions are
polling the server for changes and updating the table if there are any
updating the page on the client often and having the server generate the page if there are new data.
The latter method is the closest to pushing content, as the client do not retrieve data, but if you want to manipulate the data client-side it will be better to retrieve only the data.
A bonus in the latter is that the server handles data and turns it into a plain file, that the server can easily serve to many clients instead of creating the page every time it's opened.
Polling via ajax is the best solution here.
Since you are using ASP.NET, some of the built in ajax controls can make this pretty simple:
http://ajax.net-tutorials.com/controls/timer-control/
If you want to make a better job of this, you might consider creating a web service and using raw JavaScript or the JQuery framework to handle the ajax request / update. I say this because ASP.NET ajax sends the full page view state back to the server, which is inefficient and usually unnecessary.
"Comet" is the technology you're looking for. It's basically a handful of techniques people have come up with to do the sort of thing you're asking for. The simplest of these techniques involve causing the browser to make constant requests to the server for any updates it should know about. The most versatile (but complex) technique involves clever use of an embedded <script> tag which references a dynamic script resource.
You can use an ASP.NET Timer control coupled with an UpdatePanel to periodically check for new data and then refresh the UpdatePanel.
I was wondering if there is any way to always run some server side code when a user leaves a page in ASP.NET. The page Unload event is no good because that doesn't get called if someone clicks on a link. Ideally I'd also like the code to run even if the user closes the browser.
I suspect what I'm asking isn't possible, but it doesn't hurt to ask
Problem is, HTTP is a stateless protocol, so when the page has finished being served, you wont know if the user is still on the page or not.
The only way to acheive this would be a hidden piece of Javascript that constantly pings the server with it's session ID, or another similar mechanism. When the ping becomes unresponsive you can reasonably assume the page is not being viewed by the user anymore.
Here is a diagram that explains traditional HTTP message flow.
im not really sure if you can do that but i have a workaround in mind.
There is an event in the DOM called onbeforeunload. it get calls everytime a user leaves a page. you can try sending an ajax request to the server from this function.
The closest thing you can come without creating too messy a solution is to enable ASP sessions. This will create a session on the server for each visitor, who will be identified by a cookie.
After a certain amount of inactivity from the visitor, the session will be closed, and a SessionEnd event will be raised. This you can hook up to in the Global.asax file.
I will not recommend this however, because HTTP is pr. definition a session-less protocol, and using server based sessions violates this fact, and are often problematic. Many solutions that use server based sessions run into problems when the user uses the browser-back button, and resubmits a form. Because the content of the submitted form no longer corresponds the data that exists in the server session.
Also, enabling server based sessions seriously hurts the scalability of the application.
Not that I know of. You'll need to use javascript for that, and call a web service on the server side.
I know that there are a variety of similarly posed questions here on SO and I've had a look at the ones that are suggested as matches. However, none quite manage to solve the issue that I'm facing. Basically, I'd like to know if there's a way to 'subscribe' to an event at client level in order to have a small portion of the page rendered from the controller. I know that I can use javascript setInterval() (in combination with jquery ajax) to 'poll' the controller action in order to determine if something 'new' should be renedered onto the page. However, I'm not a huge fan of polling, especially when client browsers can be left unattended and are uneccessarily polling for changes. Multiply that by the number of potential client machines that could be browsing the app and you get a feel for the scale of the issue with this approach. Now, in truth, this is EXACTLY the approach that I use to refresh certain page fragments on some ('read' - MANY!!) of my existing sites.
However, I'd like to know what the options are for subscribing in 'reverse' to events and having the controller 'know' about the client browser and any events that it is subscribed to and the controller then 'push' out the update to the client on a 'needs must' basis. Is this something that happens outside of the normal desktop events scenario?? is the idea even scaleable or is it just the same potential bottleneck in reverse of the method that I currently use.
Hopefully, some interesting approaches out there to this double edged sword.
The server can not contact the client. The only other option besides polling is leaving an open connection between the client and server that the server can then stream info through. This is not less resource consuming than polling.
You can write a script that detects action on the client browser and goes into a "sleep" mode after a few idle minutes during which it does not poll.
Never tried it, as it seems to me that maintaining a long-running connection is a good way to run out of worker threads1 - but Comet seems to be what you're looking for.
Note that others have suggested ways around the thread per connection model.
We just recently wrote an online job application that is made up of multiple, dynamic modules and each one has individual Create/Edit/Update modes that they invoke asynchronously to avoid full page postbacks. Basically you save the data in the different modules as you fill out the application and then you submit it at the end.
Being new to AJAX, we initially implemented the modules using UpdatePanels. Now that we have been using it for awhile we are better understanding some of the limitiations to the UpdatePanel approach. At any one time the application page has between 30-40 update panels.
So we are getting ready to update the code to be more client focused and use web service calls to get data, with the intent to decrease postbacks as much as possible. One of the issues that we are running into now is the fact that only one asynchronous request can be running at one time, so if a user answers one question and then answers another while the first one is still saving, the request for the first one is dropped and doesn't complete.
My question is whether this is just a behavior of UpdatePanels and that it will not be an issue when I move to making web service calls from javascript code. I'm assuming the page can make as many different asynchronous javascript calls at one time as it wants, but I wanted to make sure this was the case as that is a big point we are trying to resolve with a re-write.
Thanks
Yes, that is only a limitation of the UpdatePanel. Its single-request limitation is necessary because the UpdatePanel's asynchronous postbacks are still just postbacks, with all the ViewState roundtripping that is normally associated with full postbacks. If more than one were allowed to execute simultaneously, the ViewState would quickly get out of sync between them and things would go downhill from there.
Using web services, you can perform as many simultaneous requests as the user's browser supports per-domain.