撑服务端从数据库中读取定时方案，并动态创建定时器的具体流程图；
图3是所述实施例中定时调度触发判断的具体流程图；
图4是所述实施例中方法的时序图； 图5是所述实施例中定时调度服务系统的整体架构图；
图6是所述实施例中装置的结构示意图。
【具体实施方式】
[0019]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0020]在本发明定时调度服务系统的配置方法及装置实施例中，其定时调度服务系统的配置方法的流程图如图1所示。在介绍定时调度服务系统的配置方法之前，先介绍一下定时调度服务系统。本实施例中，定时调度服务系统包括定时调度支撑服务端、定时调度后台服务端、定时调度客户端和存储层。其中，定时调度支撑服务端是一个独立运行的服务，封装了定时器、调度管理、日志等功能，执行用户的调度逻辑程序就靠这个服务，但它与用户要执行的具体的业务逻辑完全松耦合；定时调度后台服务端是专门给定时调度客户端提供比如数据存储、数据查询等服务的，以及提供逻辑文件上传等功能，并不具备调度的功能，只是用来读写数据库及文件管理；定时调度客户端是面向调度开发人员的客户端，提供可视化任务调度配置(包括定时方案配置、选择逻辑文件上传)、任务查看、开启和关停、日志查看等功能；存储层用来存储用户配置的数据以及上传的逻辑文件。
[0021]图1中，该定时调度服务系统的配置方法包括:
步骤SOl用户将业务执行逻辑程序编绎成设定格式的逻辑文件:本步骤中，用户将业务执行逻辑程序编绎成设定格式的逻辑文件，本实施例中，上述设定格式为DLL格式。换句话说，就是用户实现自己的业务执行逻辑程序后，将程序编绎成DLL格式的逻辑文件。
[0022]步骤S02将逻辑文件通过定时调度客户端上传到定时调度后台服务端，并配置定时方案:本步骤中，将逻辑文件通过定时调度客户端上传到定时调度后台服务端，并在可视化的定时配置界面中配置好定时方案。
[0023]步骤S03定时调度后台服务端将定时方案存储到所述存储层中的数据库中，并将逻辑文件存放到相应的文件目录下，同时在数据库中记录逻辑文件的基本程序集信息:本步骤中，定时调度后台服务端将用户配置好的定时方案存储到存储层中的数据库中，并将用户上传的逻辑文件存放到相应的文件目录下，同时在数据库中记录逻辑文件(程序文件)的基本程序集信息。
[0024]步骤S04定时调度支撑服务端从数据库中读取定时方案，并动态创建定时器:本步骤中，定时调度支撑服务端从数据库中读取用户配置的定时方案，并在定时调度支撑服务端内存中动态创建定时器。
[0025]步骤S05判断定时调度是否被触发:本步骤中，判断定时调度是否被触发，如果判断的结果为是，则执行步骤S06 ;否则，返回步骤S04。
[0026]步骤S06加载逻辑文件并根据程序集信息反射执行用户的逻辑程序:如果上述步骤S05的判断结果为是，则执行本步骤。本步骤中，加载用户上传的逻辑文件，并根据程序集信息反射执行用户的逻辑程序。通过抽象出除业务执行逻辑之外的其余部分，开发人员只需专注在业务逻辑的开发上，简化了开发人员的工作量，同时可以帮助实现服务通用化、统一化；此外，用简单易理解的定时调度配置客户端，让操作者可以轻松的配置出复杂的定时方案。
[0027]对于本实施例而言，上述步骤S04还可进一步细化，其细化后的流程图如图2所示。图2中，步骤S04进一步包括:
步骤S41接收任务通知:本步骤中，接收新任务通知。
[0028]步骤S42读取数据库中的任务的定时配置:本步骤中，读取数据库中的任务的定时配置。
[0029]步骤S43动态创建定时作业并将其加入到作业库中:本步骤中，动态创建定时作业并将其加入到作业库中。
[0030]步骤S44根据用户通知启动定时作业:本步骤中，根据用户通知启动定时作业。
[0031]对于本实施例而言，上述步骤S05- S06还可进一步细化，其细化后的流程图如图3所示。图3中，步骤S05- S06进一步包括:
步骤S51判断定时调度是否被触发:本步骤中，判断定时调度是否被触发，如果判断的结果为是，则执行步骤S52 ;否则，返回步骤S04。
[0032]步骤S52读取数据库中任务中对应的逻辑文件信息:如果上述步骤S51的判断结果为是，则执行本步骤。本步骤中，读取数据库中任务中对应的逻辑文件信息。值得一提的是，执行完本步骤，执行步骤S53。
[0033]步骤S53在相应目录下加载逻辑文件:本步骤中，在相应目录下加载逻辑文件，具体就是以反射形式加载用户上传的DLL格式的逻辑文件。
[0034]步骤S54通过反射机制读取入口函数:本步骤中，加载DLL格式的逻辑文件成功后，通过数据库中针对该逻辑文件的描述信息，找到DLL程序的入口函数。
[0035]步骤S55执行入口函数中的业务逻辑:本步骤中，调用并执行入口函数中的业务逻辑。
[0036]步骤S56等待下一次调度:本步骤中，等待下一次调度。
[0037]步骤S57判断是否有关停任务通知:本步骤中，判断是否有关停任务通知，如果判断的结果为是，则执行步骤S58 ;否则，返回步骤S51。
[0038]步骤S58停止任务:如果上述步骤S57的判断结果为是，则执行本步骤。本步骤中，停止任务，并返回步骤S04。
[0039]本实施例中定时调度服务系统的配置方法的时序图如图4所示。
[0040]值得一提的是，本发明对实现其技术方案的程序语言、开发方式并没有具体的要求，只要能够实现其技术方案的原理，用任何方式的语言都可以。本实施例中将以.net语言为例，来讲述其技术方案的实现原理。
[0041]对于定时调度支撑服务端，首先搭建一个Windows服务,做为定时调度支撑服务的宿主。在定时调度支撑服务端中封装调度框架Quartz (.net下则使用Quartz, net版本)。对于Quartz而言,其基本原理是:在一开始就创建定时作业并把该定时作业加入作业仓库，当定时调度被触发时，将执行每个作业的Execute方法。所以一般业务逻辑会写在Execute方法中，让Quartz去执行。
[0042]本实施例中，为了使调度支撑服务端和业务执行逻辑完全分离，但又能在调度时执行用户的业务逻辑，可将用户的业务逻辑形成DLL格式的逻辑文件，并在作业的Execute方法中，以反射形式加载用户上传的DLL格式的逻辑文件。加载DLL格式的逻辑文件成功后，通过数据库中针对该逻辑文件的描述信息，找到DLL程序的入口函数，调用并执行其中的业务逻辑。由于将调度支撑服务端和业务执行逻辑完全分离，这样可以简化开发人员的工作量，节省时间和资源。实现日志可用Log4net组件,并在Execute方法中加入日志信息。由于集成日志，这样可减少重复开发日志功能的工作量。
[0043]对于定时调度后台服务端,仓Il建WebServices服务。服务中至少提供如下接口:定时配置存储接口 ；文件上传接口 ；任务启动、关停接口 ；任务查询接口 ；日志查看接口。其中定时配置存储接口、任务查询接口和日志查看接口是直接读写操作数据库。文件上传接口用来将用户把要执行的逻辑文件，通过此接口上传到调度支撑服务端，上传时先给逻辑文件创建好目录(按用户指定的目录名来建目录)，或使用默认目录来存放逻辑文件。上传方式一般以二进制流的方式进行文件内容上传。任务启动、关停接口只是一个通知接口，可把通知写在数据库中，定时调度支撑服务端轮询读取数据库中的这个信息，并控制相关任务的执行；也可以在Windows服务中实现remoting (远程)接口，这样任务的启动、关停通知可以立即通知到定时调度支撑服务端，而不用轮询扫描的方式来读取通知。
[0044]对于定时调度客户端，提供用户四个配置界面:定时配置页面、任务逻辑文件上传及配置页面、任务逻辑文件上传及配置页面、调度控制页面和日志查看页面；其中，定时配置页面提供友好的调度配置界面，把用户配置的定时方案转换成Cron (克龙)表达式，并传输给定时调度后台服务端。在任务逻辑文件上传及配置页面，用户把要执行调度的逻辑文件(DLL