suppose you've written a great n-tier application in ASP.NET

and you want to extend it to perform scheduled tasks, such as

sending e-mail to selected users in the database every two

hours, or regularly analyzing the data in the ASP.NET cache

for application health monitoring. You don't want to throw

away your object model from your ASP.NET application or

create too many dependencies between a separate scheduler and

the ASP.NET application, so how can you avoid this but still

have these apps work together?

In .NET Framework-based applications, timers are frequently

used to perform activities at scheduled intervals, so using

one would seem to be an appropriate solution. You could start

a timer from the Application_Start handler in Global.asax to

run your scheduled tasks. Unfortunately, this solution is not

robust through application domain, process, or system

restarts because a request must be made to the application to

start the timer. ASP.NET is a passive programming paradigm

that only responds to HTTP requests, so a process or user

input must call the code for it to run.

A better solution is to use a Web service to provide an

interface to your ASP.NET application and to build a Windows®

service that calls to it at scheduled intervals. This way the

ASP.NET application doesn't have to own the scheduling logic

and only needs to be concerned with performing tasks it is

already capable of performing. And since a Web service can

run in the same application context as the rest of your

ASP.NET application, it can execute in the same context that

your existing code expects.

I'll be using a Windows service to initiate the Web service

call because Windows services can start themselves when

Windows boots up. So even if the server is restarted, the

application will be able to start itself. This restart

capability makes a Windows service a more robust solution for

the task than a typical Windows-based application. It's also

the reason why Windows services are used for many background

processes (such as IIS).

In this article, I'll demonstrate how to do this while

creating the smallest number of dependencies between your

scheduling application and your ASP.NET application. The

solution involves simplifying the scheduling application that

initiates the ASP.NET job. In the scheduling application,

there will be no logic called that is specific to the ASP.NET

application except for the Web service endpoint that it

calls. The Windows service will use an app.config file to

store both the URL of the Web service and the interval that

the Windows service should wait between calls to the Web

service. By storing these two settings in the Windows

service's app.config file, you can change them without having

to recompile the Windows service. If you need to change the

application's behavior when it is called, you can just change

the logic in the ASP.NET application; however, you won't have

to change the scheduling application's code. This means that

the scheduling application will be isolated from changes in

the ASP.NET application.

Note that this solution is based on the premise that there

are some tasks that should only be executed in the context of

a running ASP.NET application. If this is not a requirement

for your tasks, you should strongly consider referencing the

ASP.NET application's business logic assembly directly from

your Windows service and bypassing the ASP.NET process to

fire the tasks.

The Application Structure

A typical ASP.NET application is built with a series of

independent layers that perform specific functions. In my

particular example, I have database access classes, business

logic classes, business flow classes, and ASP.NET pages that

serve as the entry point to these layers (see Figure 1). 

The ASP.NET pages are merely used to display and retrieve

data. They are an interface into and out of the business flow

classes which actually coordinate all of the work. The flow

classes call the business logic classes in the proper order

to complete a particular transaction, such as ordering a

widget. For example, the flow class could first call the

business logic to check inventory, then to order the widget,

and finally to decrease the inventory to the proper level.

The business logic classes decide how to call the database

access classes and process that result if necessary to get a

final result that you can use for other operations. For

example, business logic would be used to calculate the total

price including the tax for a particular state. First you may

need to retrieve the tax rate for that state and base prices

from the database using the data access classes, then

multiply them to find the total tax on each item.

The database access classes hold the logic to connect to the

database and to return a resultset in a format such as a

DataSet, DataTable, or a DataReader that can be consumed by

the higher layers. These classes merely retrieve data from

the database and update it according to the information they

are fed; they do not process the result. For example, they

may retrieve the tax rate for a particular state, but they

would not calculate the total tax on the order.

The Microsoft® Data Access Application Building Block

simplifies the data access classes by providing easier ways

to communicate with the database and stored procedures (for

the download, see Data Access Application Block). For

example, you can make a call to its SQLHelper object's

FillDataSet method to fill a DataSet from the output of a

stored procedure using one line of code. Typically, you would

have to write the code to create at least the DataAdapter and

a command object, which would take at least four lines of

code.

The Data Access Application Block connects to the stored

procedures that are in the database. The stored procedures

provide the SQL code that is needed to access and modify data

in the database.

Adding Scheduled Jobs to the Application

An ASP.NET Web service will provide you with an interface

into the existing ASP.NET application that holds the task

logic. This will serve as the broker between it and the

Windows service that calls the ASP.NET application into

action. A Windows service will then call the ASP.NET

application at scheduled intervals. By building an ASP.NET

Web service in the existing ASP.NET application, the business

objects and logic that were already created for the ASP.NET

application can be reused in the scheduled jobs. Figure 2

shows the details of the application flow from the client

Windows service application through the Web service

initiating that run on the server, all the way through the

execution of each scheduled task.

As you can see in Figure 3, the process will require some

modifications to the standard layering previously depicted.

The Windows service will wake up the ASP.NET Web service at a

specified interval. The ASP.NET Web service will then call a

method in the Web application's flow layer that will actually

determine which scheduled jobs should be run and will then

run them. Once the basic solution is implemented, you'll use

the client-side app.config file to determine the intervals at

which the Windows service calls the Web service. Next, you'll

add the functionality needed by the business flow layer in

order to loop through and run jobs. You n-tier gurus out

there will be much more interested in the flow tier than the

remaining ones, so I'll save the database table, database

stored procedure, data access code, and business logic for

last.


Finally, add the code to the existing layers of the

application from the bottom (the database table level) to the

middle (the business logic layer) in order to support the job

functionality used by the flow layer.

Building Your Web Service

To build the Web service, first add the JobRun ASP.NET Web

service to the ASP.NET application within the same layer as

your existing ASP.NET code. Make sure that your ASP.NET

project has a reference to the business logic, flow, and data

access projects. Next, to create the RunJob Web service

method in the JobRun Web service, the Web service method will

need to call the flow layer's function that runs the proper

jobs. This means that the RunJob method can start out as

simply as this:

[WebMethod]
public void RunJob()
{
    Flow.JobFlow jf = new Flow.JobFlow();
    jf.RunAllActiveJobs();
}

Use the RunJob function to create an instance of the JobFlow

class (which is in the flow layer) and call its

RunAllActiveJobs function. The RunAllActiveJobs of the

JobFlow function does all the real work in coordinating the

running of the jobs, while the RunJob function merely serves

as an entry point into the sequence.

Note that this code does not prevent jobs from running on

more than one thread at a time, which could happen if the

Windows service scheduled tasks too frequently (faster than

they could be run) or if some other application invoked the

entry point. If the method is not thread safe and allows

multiple threads through it at the same time, it may cause

problems with the results of these jobs. For example, if job

X sent an e-mail to Mary Smith, but hadn't yet updated the

database when job Y queried the database to do its e-mails,

then Mary could receive two e-mails.

To synchronize access to the function, I'll use the Mutex

class from the System.Threading namespace:

private static Mutex mut = new Mutex(false,

"JobSchedulerMutex");

Mutex provides for cross-process synchronization, so this

will prevent multiple runs at the same time even if two

different ASP.NET worker processes are involved. Now, let's

change the RunJob method to use the Mutex to ensure that no

other job is running before starting the jobs.

As you can see in the RunJob function in Figure 4, you call

the WaitOne function of the Mutex to make this thread wait

until it is the only one before executing. The ReleaseMutex

function is then called to indicate that you are finished

with the code that needs to run only in one thread. Of

course, blocking here may not be the correct solution. You

might choose to return immediately if another thread is

already executing jobs, in which case you could specify a

short timeout to the WaitOne method, and immediately return

from RunJob if the mutex couldn't be acquired.Put all of the

main actions of the function in a try-finally block so that

ReleaseMutex is called even if an unexpected exception in the

RunAllActiveJobs function causes the RunJob function to exit.

You'll want to secure your Web service using some form of

authentication and authorization, possibly using Windows

security, to ensure that no one runs the service without

proper authorization, but I won't go into the details of that

in this article.

Now that you have the Web service built so that you can call

it from another app, let's build the Windows service that

will use it.

Building the Windows Service

Start by creating a new Windows service project in another

instance of Visual Studio® .NET and name it

InvokingASPNetService.cs. Make sure that this service will

start properly by adding a Main method as follows:

public static void Main()
{
    ServiceBase.Run(new InvokingASPNetService());
}

Now add using statements for the following namespaces:
using System.Configuration;
using System.Globalization;

Add an installer for the service by right-clicking the design

surface of the InvokingASPNetService.cs and selecting Add

Installer. You should change the created serviceInstaller1's

StartType property to Automatic so that the Windows service

starts when Windows boots. Set the ServiceName property of

the serviceInstaller1 to InvokingASPNetService so it will be

appropriately named in your Services Manager, and then change

the serviceProcessInstaller1 Account property to Local

Service.

The third step is to create a Web reference to the

InvokingASPNetService Web service and then name it

JobRunWebService. Change the JobRunWebService URL Behavior

property to be Dynamic in order to have Visual Studio .NET

automatically augment the app.config with your Web

reference's URL. The proxy class generated will look to this

configuration file for the Web service's URL, thus allowing

you to point the Windows service at a different endpoint

without recompiling.

Fourth, create a method in the Windows service to run the Web

service every time it is called. The method will look like

this:

private void RunCommands()
{
    JobRunWebService.JobRunInterval objJob =
        new JobRunWebService.JobRunInterval();
    objJob.RunJob();
}

As you can see, you'll declare the Web service proxy and

create it just like any other .NET object. Then, call the Web

service's RunJob method in order to run the jobs on the

remote Web server. Note that neither step is different from

using a local class even though you are using a Web service.

Fifth, you'll need to call the RunCommands function in the

Windows service. You should call this method at a set

interval of time based on how often you would like to run the

jobs on the remote server. Use a System.Timers.Timer object

to ensure that the RunCommands function runs at the proper

intervals. The Timer's Elapsed event will allow you to

trigger any function that you specify after each interval has

elapsed. (Note that interval length is specified in the

Interval property.) You'll use the triggered function to call

the RunCommands function so you can automate this feature. By

default, this timer class only triggers an event the first

time that the timer expires, so you need to ensure that it

repeatedly resets itself every time by setting its AutoReset

property to true.

You should declare it at the service level, so that any

function of the service can reference it:

private Timer timer;

Next, create a function that will initialize the timer and

set all of its relevant values:
private void InitializeTimer()
{
    if (timer == null)
    {
        timer = new Timer();
        timer.AutoReset = true;
        timer.Interval  = 60000 * Convert.ToDouble(
           

ConfigurationSettings.AppSettings["IntervalMinutes"]);
        timer.Elapsed += new

ElapsedEventHandler(timer_Elapsed);
    }
}

To allow for the configuration interval to be changed without

recompiling the application, I've stored the interval in the

app.config file so that the InitializeTimer method can access

it using ConfigurationSettings.AppSettings instead of having

it hardcoded, as shown in the following:

<add key="IntervalMinutes" value="5" />

Make sure that the timer calls the timer_Elapsed function to

handle the Elapsed event when the timer runs out. The

timer_Elapsed method is very simple and calls the RunCommands

function that was just built, as shown here:
private void timer_Elapsed(object

source,System.Timers.ElapsedEventArgs e)
{
    RunCommands();
}

Finally, you have to install the Windows service using the

installutil command. The easiest way is to open the Visual

Studio .NET command prompt, navigate to the service's

directory, and run the installutil utility, specifying your

assembly as the parameter.

Expanding the Flow Layer to Handle Scheduled Jobs

It is important to expand the flow layer to handle the needs

of running scheduled jobs (assuming the jobs differ enough

that they need to be coded rather than merely parameterized).

This involves collecting all jobs from the database where the

next start time in the database has passed and running them

individually. Within the flow layer, you will create a base

class called Job to provide all of the functionality that is

common between jobs. This includes a mechanism to initialize

and retrieve the JobID, a common method (RunSingleJob) to run

the job and set the next time to run in the database after a

successful run, and an overridable method (PerformRunJob) to

be customized for each individual job.

The flow layer will also need to have job-specific classes

built for each job it performs. These will inherit from the

base Job class and will override the PerformRunJob function

of the Job class to customize the execution of that

particular job. You'll also need a factory class (JobFactory)

to create and initialize the JobID of the correct Job class.

The static CreateJob function will create the appropriate job

based on the JobID passed into it. Finally, the flow layer

will need to be able to determine which jobs need to run,

loop through them, and run them. This is what the JobFlow

class will provide through its RunAllActiveJobs method.

First, let's create the Job base class in the flow layer

project, which will be the parent of each individual job

class. The core of the Job abstract base class is shown in

Figure 5. It allows the initialization and retrieval of its

JobID, as well as ensuring that the database is updated if

the job is run successfully. The JobID will not change for a

given job after it is created, so you must ensure that after

initialization the set function will not change the value.

The JobFactory class that creates each Job class will set its

JobID value.

The RunSingleJob function determines that this job's JobID

has been initialized, runs the job (PerformRunJob), and

updates the database after successful runs with the

RecordJobSuccess method. The isInitialized variable is used

to make sure that each job has its JobID initialized before

running the job. The PerformRunJob abstract method is

implemented by derived Job classes and holds the actual logic

for the task.

After a job's implementation (PerformRunJob method) runs

successfully, the base class calls the RecordJobSuccess

function, which uses the UpdateJobDone method of the Business

Logic layer's JobLogic class to record the time that it ran

in the database as well as the next scheduled time to run. I

will create the JobLogic class of the Business Logic layer

later.

The Job class provides both the ability to initialize the

JobID variable and to update the database upon success with

the next run time. Plus, you only have to override one

function with class-specific code. This allows you to create

the child classes of the Job class. To do so, you need to

create two classes that will run a particular type of job and

inherit from the Job class to obtain the rest of their

functionality. Create a JobRunTest class and a JobEmailUsers

class and make sure that each one inherits from the Job

class, as shown in the following:

public class JobRunTests : Job

Now, override the PerformRunJob method for both classes as

follows (using the JobRunTest class as a sample):
protected override void PerformRunJob()
{
    ///Do RunTest specific logic here
}

Place your job-specific logic inside this method. The rest of

the code that runs the jobs and updates the next run time in

the database is inherited from the Job base class. Your jobs

will combine calls to the existing Business Logic classes in

order to run complex processes. Now that you have the sample

jobs, let's look at how to create these jobs using the

JobFactory object.

The JobFactory class is used to create the corresponding

child Job class for each JobID. The JobFactory class takes a

JobID variable in its static CreateJob function and returns

the appropriate Job subclass. Figure 6 shows the code in the

JobFactory.

The CreateJob function takes a currentJobID and uses it in a

case statement to determine which child class of the Job

class should be returned. It then initializes the current

JobID and returns the Job-derived class. Now that you have

the Job base class, its job-specific children, and a way to

select which class to create, you can look at how to pull it

all together using the JobFlow class.

To create a class called JobFlow that will gather and execute

the appropriate jobs, add a function called

"RunAllActiveJobs" to loop through each job that you need to

run and call their individual RunSingleJob functions. You'll

need the RunAllActiveJobs function to grab a list of the jobs

that are due to run from the database through the business

layer, data access layer, and stored procedures, and then run

them using their respective RunSingleJob functions. The

following code shows how the RunAllActiveJobs method of the

JobFlow class accomplishes these goals:

JobLogic jl = new JobLogic();
DataSet jobsActiveData = jl.GetAllActiveJobs();
foreach (DataRow jobsActive in jobsActiveData.Tables[0].Rows)
{
    int currentJobID = Convert.ToInt32(jobsActive["JobID"]);
    Job myJob = JobFactory.CreateJob(currentJobID);
    myJob.RunSingleJob();
}

Basically, you would store the jobs in the database with

information on the last time that they ran as well as the

interval that the code should wait between runs. The jobs

that need to be run are then retrieved through the JobLogic

class of the BusinessLogic layer with the GetAllActiveJobs

method. Each active job's ID is used to get a Job object,

whose RunSingleJob method can be used to execute the task as

previously described.

Job Timing Information

Determining which scheduled jobs should be run means that you

need to store basic information about them such as the

interval between runs, the last time that they ran, and the

next time that they should run. In order to do this, create a

job table in a SQL Server database (see Figure 7).

The JobID column holds the unique identifier for each job in

the job table. The JobTitle column contains the job name so

that you can determine which job is being run. The

JobInterval column holds the interval between jobs. This is

the date and time interval greater than 1/1/1900 that should

be added to the current time after a job succeeds to

calculate when the next job should be run. For example, a

value of 1/2/1901 in the JobInterval field would mean that

one year and one day would be added to the time that the job

last ran.

The DateLastJobRan column contains a datetime value for the

date and time that the job last ran. The last column,

DateNextJobStart, contains the next time that the job should

run. While this column should be a computed column which is

equal to JobInterval plus DateLastJobRan, you can understand

the application layers more vividly if you set this up as a

regular datetime column.

Retrieving and Setting Job Timing Information

To retrieve and set job timing information through the new

stored procedures in the SQL Server database, the stored

procedures must find all of the jobs in the database that

need to be run by the application, update a single job's

information in the database to indicate that it has run, and

set the next job-run date for that job. Each job has a

DateNextJobStart column in the database that indicates the

date and time at which the job should run. If the current

date and time is past that of the DateNextJobStart column,

then the job should be run in the process. The stored

procedure that selects the jobs that should be run is shown

here:

   CREATE PROCEDURE   
     dbo.Job_SelectJobs_NextJobStartBefore
@DateNextJobRunStartBefore datetime
AS
SELECT * FROM JOB WHERE DateNextJobStart <

@DateNextJobRunStartBefore

This selects all of the columns of the Job table for the jobs

that have a DateNextJobStart value that is before (less than)

that of the @DateNextJobRunStartBefore DateTime parameter. To

find which jobs should run, simply pass in the current date

and time through the stored procedure's parameter. Now that

you can select the jobs that need to run, you can switch to

building the procedure to update them after they run.

The stored procedure that updates the database with a single

job's last run date and next run date is as follows:

CREATE PROCEDURE dbo.Job_Update_StartEnd_CalcNext
@JobID int,
@DateLastJobRan datetime
AS
UPDATE JOB
    SET
    DateLastJobRan = @DateLastJobRan,
    DateNextJobStart = @DateLastJobRan + JobInterval
WHERE
    JobID = @JobID

This procedure updates the job that is identified by @JobID

with a new DateLastJobRan and calculates the DateNextJobStart

value by adding the JobInterval to the @DateLastJobRan that

was passed in. This procedure should only run after the job

referenced in @JobID is run and should be called with the

@DateLastJobRan parameter equal to the date and time that the

job ran last.

Calling the Job Timing Stored Procedures

You can extend the data access layer to call the job timing

stored procedures by adding a new class called JobAccess. The

role of functions in the data access layer is to translate

the parameters passed to it by the business layer into a

stored procedure database query and return the result to the

business layer. The parameters in the data access layer's

functions will mirror those of the stored procedures that

they access because they do not perform any Business Logic on

the values.

You'll be accessing the database through Microsoft Data

Application Building Block's SQLHelper class. This class

contains functionality that simplifies data access code,

making your code more concise and readable.

To change the data access layer to run the scheduled jobs,

first add a JobAccess class to the existing data access layer

to hold the functions that are needed to schedule jobs. Next,

create a function in the JobAccess class that returns a

DataSet of the jobs that need to be run through calling the

Job_SelectJobs_NextJobStartBefore stored procedure. You'll

also need to create a function in the JobAccess class to call

the Job_Update_StartEnd_CalcNext stored procedure without

returning a result.

First add the JobAccess class to the data access layer. Then,

edit the JobAccess class to add the following "using"

statements:

using System.Data;
using System.Data.SqlClient;
using Microsoft.ApplicationBlocks.Data;

Let's look now at how to add the SelectJobsBeforeDate

function, which retrieves the list of jobs that need to be

run. Here is the signature of the SQLHelper's ExecuteDataset

function:

public static DataSet   
ExecuteDataset(
    string connectionString, string spName,
    params object[] parameterValues)

The following is the SelectJobsBeforeDate function, which

uses ExecuteDataset to invoke the

Job_Update_StartEnd_CalcNext stored procedure, returning a

DataSet of the results:

public DataSet SelectJobsBeforeDate(DateTime beforeDate)
{
    return SqlHelper.ExecuteDataset(
        ConnectionInfo.connectionString,
        "Job_SelectJobs_NextJobStartBefore, myparams);
        new object[]{new SqlParameter("BeforeDate",

beforeDate)});
}

After jobs have been run, you'll need to execute the stored

procedure which updates status information about the jobs.

The method that accomplishes this, UpdateJob, will use the

SQLHelper class's ExecuteNonQuery method. Here is the

signature:

public static int ExecuteNonQuery(
    string connectionString, string spName, params object[]
    parameterValues)

The UpdateJob method can be written as follows:
public void UpdateJob(int jobID, DateTime dateLastJobRan)
{
    string connStr = ConnectionInfo.connectionString;
    string spName = "Job_Update_StartEnd_CalcNext";
    SqlParameter myparam1 = new SqlParameter("JobID", jobID);
    SqlParameter myparam2 = new 
        SqlParameter("DateLastJobRan",dateLastJobRan);
    object[] myparams = {myparam1, myparam2};
    SqlHelper.ExecuteNonQuery(connStr, spName, myparams);
}

The UpdateJob function in the JobAccess class is supposed to

mirror the parameters that are passed to the stored procedure

that it uses. Therefore, the UpdateJob function has a jobID

parameter and a dateLastJobRan parameter with the same

datatypes as those in the Job_Update_StartEnd_CalcNext stored

procedure. Using the jobID and the dateLastJobRan parameters,

you can create the two SqlParameters, put them in the

myparams object array, and use the ExecuteNonQuery function

to execute the stored procedure. Now that you've created the

JobAccess class, you need to create the final layer of

classes to bridge the gap between the flow layer and the data

access layer.

Working with Scheduled Jobs

The final layer that must be modified to work with scheduled

jobs is the Business Logic layer, which I'll call JobLogic.

This class will perform basic logic on the variables between

the flow layer and the data access layer.

First, add the JobLogic class to the DataAccess layer using

the following statements::

using System.Data;
using ScheduledWebService.DataAccess;

Second, build the GetAllActiveJobs function of the JobLogic

class to find all of the jobs that still need to be run at or

before the current time, as shown here:
public DataSet GetAllActiveJobs()
{
    JobAccess ja = new JobAccess();
    return ja.SelectJobsBeforeDate(DateTime.Now);
}

The GetAllActiveJobs function creates an instance of the

JobAccess class and calls its SelectJobsBeforeDate with the

parameter value of the current date. GetAllActiveJobs picks

the current date to pass to this function, so you can find

out which jobs were scheduled to run before the current time.

Lastly, create the UpdateJobDone function of the JobLogic

class to update the database to indicate that the job

specified was just completed, as shown here:

public void UpdateJobDone(int jobID)
{
    JobAccess ja = new JobAccess();
    ja.UpdateJob(jobID, DateTime.Now);
}

This function creates an instance of the JobAccess class and

calls its UpdateJob method. It passes along the jobID

parameter and then uses the current date for the

dateLastJobRan parameter. You pass the current date and time

to the UpdateJob function because it is the time at which the

job completed successfully.

Conclusion

Extending your ASP.NET application with automated tasks

allows you to program events explicitly rather than waiting

for a request to execute code. You can harness this power to

perform a variety of tasks from running complex calculations

to creating and sending reports to executives on a regular

schedule. Such tasks can reuse both your existing logic and

the objects in your ASP.NET layers, decreasing development

time and improving maintainability. You can also expand the

jobs that this scheduler starts without changing the Windows

service that initiates it.

Note that there are many variations to what I've discussed in

this article. For example, rather than creating a custom

Windows service to act as the scheduler, you could use

something as straightforward as the Windows Task Scheduler,

which is quite robust and implements much of the capabilities

discussed here. That said, the creation of Windows services

has been vastly simplified by the .NET Framework, so they

should be reconsidered as an option even if you have

previously found them too difficult to use. Similarly, Web

services are a great way for apps to expose functionality to

other apps and will continue to be valuable in that regard.

原文地址：http://msdn.microsoft.com/asp.net/default.aspx?pull

=/msdnmag/issues/05/03/schedulingaspnetcode/default.aspx

引用通告地址 (0)：[收藏此页]
http://www.mikecat.net//trackback.asp?tbID=1093
http://www.mikecat.net//trackback.asp?tbID=1093&CP=GBK