Using Solid Framework directly within an ASP.NET process can be troublesome:
Concurrent requests under ASP.NET can occur within the same process (a single process can host multiple AppDomains). Solid Framework is not compatible with AppDomain process/thread behaviour.
Document reconstruction is resource intensive (CPU and memory): too many concurrent requests can easily exhaust server resources.
IIS user permissions (to save files locally or execute non-managed code) change with each IIS update. In contrast, permissions to make web service requests from ASP.NET are well understood and trivial to configure.
Solid Framework’s Job Processor is an elegant architectural solution to all these issues. It can be run as a Windows service and communicate with ASP.NET through WCF. The Job Processor runs concurrent conversions under parallel worker processes (not threads) and manages load in a highly configurable way. The number of worker processes is automatically determined based on the capacity of the server but can also be manually configured. Conversion jobs are automatically queued by the Job Processor for the next available worker process.
Your ASP.NET app on the web server calls the Job Processor (as a web service) to transfer files, submit jobs for processing and return results. The flow is as follows:
This sample includes source code for a reference implementation of a Windows Service that runs the Solid Framework Job Processor as a web service. It also includes a simple example of an ASP.NET web app that uses this conversion service. The Job Processor Service used in this sample is similar to the one used by SimplyPDF