ASP.NET 设计问题 - Web 服务

Question

Creating a web interface so our helpdesk can create users and setup some of the applications that are used in our environment, the web interface is written in ASP.NET but I'm seeking advice on the best way to implement the backend.

I was planning to use a web service to do the creation of accounts. My main concern is security and seperation of concerns so I didn't think app domains would be sufficent.

The idea is to take the information through the web service request and spawn a thread under a priviledged account to do the actual work. As we have other systems we may end up using multiple web services.

Can anyone see issues with this or have better suggestions?

Answer 1

You propose a reasonable solution but I can think of an alternative. Dealing with threads can be a pain in ASP.NET applications. Not impossible but a pain. Are you spawning a thread so that your task can run under a separate identity, or is it because the task can be long running, or both? Another thing to consider is how you authenticate users. You will need to know how to impersonate another user account with ASP.NET.

Depending on load and other factors it might be better to introduce a queue into your applications (in a database, or using MSMQ, Rhino Queues, or similar). When a request comes in validate it. If it is OK then dump it into the queue and return a correlation ID to the client. The client can check the status of the task using this ID.

Your queue could be stored in a database or you can use a specific queuing API/system. Create a separate app that runs as scheduled job, or Windows service. This application would run under a separate ID from clients that call your web service, and does the work you would do on the other thread. When the queued work is completed, the database updated with the status.

By doing this you avoid having any special code in your ASP.NET application and have a clean distinct interface between your concerns. If a task fails, say a 3rd party application you are setting up is offline, then you have an opportunity to retry the operation. I've found this method to be easier to monitor too. If an application is offline, it also lets you continue to accept incoming requests without too much difficulty.