Click here to Skip to main content
15,307,359 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
I have an architecture question:
I wrote an enterprise 3-tier application, DDD approach, it runs in IIS and I have problems with this because:

1) Memory limit: my application work with huge images, and IIS is memory limited.
2) Long running task: somethime a task run for 30-40 minutes (doing tons of query processing loads of data ecc) this is an issue with IIS.

I like to divide the application "somehow" in 2 modules:
1) web UI that get user request and call the other module
2) server module that get the calls from web ui.

So, my questions: how can I do this? and: it is a good approach?

Mainly I have issues with the server module: It have to be a windows service? Some other kind os application?

Use web service/WCF service.
Use SQL query optimization techniques.
Luca Dominici 6-Dec-12 11:52am
ok for the WCF service, but I still miss some point... : WCF are hosted in iis or windows service or...? I have heard of appfabric.. But I really don't know where to start with those technology... Any help?
Start by instantiating a ServiceHost class in a windows service. Then, on the service interface, define a method that would kick off your long running process. You can use the leaders-followers pattern to service requests using multiple threads. Alternatively, use a One-way method on your service interface so that the requestors don't wait for the windows service to spin up a thread or whatever it would do. Using a One-way method you must then queue requests on your service.
I suppose, the basic scenario is like following:
1) user initiates a the process, gives parameters - let' call it job
2) your application is starting to do the job, and creates the desired output
3) user is happy with he output :)
I also suppose, that your server does not have unlimited resources, thus a heavy load would inrease even more processing time measured during single request.

Now, in this situation I suggest the following approach:
1) Separate your user interface in two: job initiation and "inbox" for handing over finished jobs
2) Create a job model and a queue based on that model. This can be a simple database table, but something more complicated something for a complex job. Don't forget to link the job to the initiator user.
3) Create a windows service that looks for jobs in the queue, does the job and stores the result attached to the job in the queue.
4) The finished job is added to the inbox of the user. You can use ajax calls to refresh inbox on client side and/or send out email to notify user.
5) You have to choose the level of parallelism implemented in the windows service based on the job in general, the concrete job parameters and the load on the server.
6) You can even inform the user about the status of his jobs, by updating some sort of status or progress information on the job itself and the UI.

You could create and call a separate application from, by spawning a process - and thus escaping the limitations you know. But this way you could not schedule the jobs and the overall resource limits would impact performance. WCF can handle async calls, but you still have to handle asynchronicity on client side, and I think a windows service is more appropriate for such scenarios.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900