How a website and a web application communicate?

I want to develop an interactive website in ASP.Net and what I mean by interactive is that it has a back-end application to provide real-time logic (which does not follow HTTP's model of Request/Response) and eventually it is provided with dynamic *.aspx pages with an SQL Server database.

And how would the components go together (as a design and as a communication mechanism) to have a scalable application?

EDIT: Ok, the story is as you know, we all are tending to get something more vital than HTTP model, I want my back-end application to be persistent working in real-time, for example, It would have some constant-intervals to do some queries on the database.

The design as I picture it is a server (holding an ASP.Net website, the back-end application and the database),开发者_开发技巧 the design may get more hybrid with time. The website is the interactive interface for the users, the website needs (sometimes) intensive calculations and queries which better be handled by the back-end application, then the application delivers the website the info to be wrapped and formatted as HTML markup to be returned the user eventually.

Any suggestions about the design? What key ideas you can share to go with a robust application which can be developed iteratively to make future changes/enhancements easier? It could be about the tiers of the whole project or whether to prefer using WCF over regular web services between the website and the back-end application?

Interesting. Can you elaborate more on the flow of logic in this application? What is the non-web application (I assume it's running on the same server) doing?

Based on the description so far, I'm picturing a website driven by a SQL database and a Windows Service running on that same machine (for the real-time logic application) doing whatever it needs to do with that database. But it sounds like you're looking for more direct interaction than that.

Edit:

I want my back-end application to be persistent working in real-time, for example, It would have some constant-intervals to do some queries on the database.

That could (should, probably) be a Windows service or some otherwise always-on application which simply interacts with the database. It and the website need not know of each other's existence. The website just serves up the data that's placed/manipulated in the database by this process.

the website needs (sometimes) intensive calculations and queries which better be handled by the back-end application

Asynchronous processing like this is often very useful for a website, since not everything can be done while a browser patiently waits. The design varies heavily on the intuitive nature of what you're doing, but for a start I'd suggest something like this:

1. User "initiates" a "calculation" on the website. Whether it's setting up some values, uploading some kind of batch of things to process, etc. is entirely up to what you're doing. The main point is that the user starts it off.
2. The necessary information for the process to do its magic is persisted to the database and the user is told that the process has been queued for processing. The user can now go about doing other things.
3. The back-end application (or multiple applications) polls the database periodically (every minute, every 5 minutes, etc.) or, in the case of an uploaded "batch" file could use something like a FileSystemWatcher, to look for new things to do and does them. Use multi-threading or whatever you need to make that happen, but the main point is that it's an "offline" process that the website isn't waiting on.
4. When the process completes, some flag is set in the database (on the record being processed, or maybe a "message" record in the user's "inbox" or whatever) indicating that the process is done.
5. The website UI has some indicator which, any time it's loaded, checks for the aforementioned flag(s) to indicate to the user that a queued process has been completed and is ready to be viewed.

The back-end process could additionally send an email to the user at the time a process completes, etc.

Is that the gist of what you're thinking? Or does the interaction need to be more direct for some reason?