Patent Application
20080163219
The field of invention relates generally to the software arts, and, more specifically, to remotely or locally maintain, schedule, and process tasks or jobs.
Traditional client-server systems employed a two-tiered architecture such as that illustrated in
The “business logic” component of the application represents the core program code of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in
This separation of logical components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122. If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code. In addition, presentation logic 121 may be provided which generates code for a variety of different user interfaces 120, which may be standard browsers such as Internet Explorer® or Mozilla Firefox®.
The multi-tiered architecture illustrated in
As illustrated in
The computer systems described above consist of many smaller pieces of program code referred to as “objects” which interact with each other. For example in a computer program for booking cars at least three objects are required for storing the relevant information: one for the person who makes the booking (name, credit card number etc), one for the booked car (model, engine, class, etc) and another for the booking itself (booking date, return date, etc).
Enterprise computer systems (and to a lesser extent smaller computer systems) utilize task or job scheduling to take advantage of the available processing power without the intervention of a person to start these tasks. For example, instead of having an administrator physically start a file backup program for users on a network at 2 AM (when, presumably, the users on the network will not be on the network), the backup program may be scheduled to automatically run at 2 AM without any further intervention.
Additionally, background tasks in these clusters 303, 305, and 307 may be remotely scheduled, if the computers and systems of the clusters have an interface to the central scheduler 301. In other words, the central scheduler 301 is specific to the particular systems and/or software platforms that it supports and cannot be used with other platforms.
The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which like references indicate similar elements and in which:
a illustrates a traditional two-tier client-server architecture;
b illustrates a prior art multi-tier client-server architecture;
A system and method for interaction with a batch processing system such as a remote server is described. Using an enterprise scheduler, jobs and other tasks may be scheduled on a remote server. Typically, the enterprise scheduler and remote server communicate through an API which servers as an interpreter between them. A Java API is used to when the remote server utilizes Java technology.
As described earlier, prior art systems rely on the central scheduler to have an interface to all systems and software platforms that it triggers remote execution of jobs for. In prior art systems, there are interfaces available for Java systems for remote execution of jobs by a central scheduler however these solutions have several shortcomings, for example, they are specific to a particular central scheduler system 301 from a specific vendor and do not take the landscape of the Java system into consideration. The enterprise scheduling system described below overcomes these shortcomings and more.
The enterprise scheduler 401 described works with different operating systems. For example, Java system 403 could run Microsoft Windows and Java system 421 could run Linux and both could have could scheduled by the enterprise scheduler.
Through the Java API illustrated in
A remote system, such as Java system 403 or 421, performs one or more “jobs” 407, 409 locally. Exemplary jobs include, but are not limited to: removing outdated or irrelevant job instance information from the system (“CleanJob”), generating reports at certain points in time (e.g. daily sales reports), triggering daily backup jobs, retrieving monitoring information from remote systems at a regular basis, etc. Jobs are also objects in the Java 403, 421 or UNIX 423 system. In an embodiment, each job runs only once regardless of how successful or unsuccessful the job is. For example, a new job (and new job ID) is created if the job is restarted.
A job (sometimes referred to as a job instance) is a concrete instance of a job definition. (Job definitions are also objects in the system.) Job definitions are abstract meta representations of tasks performable by the remote system. For example, a job definition defines the parameters that a particular job requires to execute. In an embodiment, job definitions originate from a deployment descriptor (such as an EJB deployment descriptor) and job definition file found in a deployment archive. The job definition class may be Extensible Markup Language (XML) serializable/deserializable for ease of transport across a network (for example, from the Java system 403 to the enterprise scheduler 401). Accordingly, jobs have these properties but with concrete values. Job definitions are stored remotely in storage areas 425,427 and/or locally at the enterprise scheduler 401.
A job definition has one or more of the following properties: an ID, a name, a description of the job to be performed, parameters, retention period (the period for which logs of individual job instances are kept), and a type that identifies the job definition type (for example, MDB job or EJB job). The retention period may be specified in days where −1 days means that no information for this job is kept after it has finished execution. Job definitions may also be created or deployed onto a remote system as it is running. A job, therefore, has concrete values for these properties. A job may also have vendor data associated with it. Typically, this vendor data is related to the internal state of the central scheduler which scheduled the job. This can be used to associate the vendor specific job id with the job id in the remote system.
Jobs have statuses associated with them. Exemplary statuses include, but are not limited to: cancelled, completed, error, running, starting, unknown. A completed job is one that has finished. An error means that the job has completed but had a problem or failed completely. A running job is currently executing. A starting job is one that is currently being started by the runtime. A cancelled job is one that was running or starting but was stopped. Job statuses are maintained remotely and may also be mirrored or at the enterprise scheduler.
Jobs have a log file associated with them. These log files may be used to determine if the job executed correctly or if it didn't what the problem was.
Jobs may be scheduled locally with internal scheduler 411, 419 or scheduled using the enterprise scheduler 401. In one embodiment, the enterprise scheduler 401 schedules jobs in the remote system 403, 421 using the internal scheduler 411, 419. The API 405 transforms the commands of the enterprise scheduler 401 into commands that the internal scheduler 411, 419 understands. In other words, the API 405 acts as a translator between the enterprise scheduler 401 and the Java system 403, 421. Of course, the API may be deployed on the enterprise scheduler 401 instead of on the remote servers.
In systems where the enterprise scheduler 401 and internal scheduler 411, 413 co-exist, that is where each may schedule, a priority system may be employed to determine which scheduler has priority in making scheduling decisions. For example, the enterprise scheduler 401 may be given higher priority (and therefore overrides the internal scheduler 411, 413) or lower priority (and does not override the internal scheduler 411, 413) depending upon the needs of the enterprise at a given point in time.
The internal scheduler 411, 413 is controlled by the enterprise scheduler 401 in other embodiments. In this configuration, the enterprise scheduler 401 is directly responsible for maintaining job schedules for each remote system.
Java system 421 operates in the same manner to Java system 403. Due to the difference between application server and operating systems, the UNIX system 423 may have different components to the Java systems.
The interface 501 may also include a display area 523 to display relevant information for a particular function. For example, when scheduling a job the display area 523 may display input fields to be filled in to create a job instance using the requirements of the relevant job description (job definition). In the exemplary display area shown in
The information provided above is sufficient for the described java system, the information provided for another system such as a UNX system may be of a slightly different nature depending on the scheduling approach taken (not described here).
In most cases, an enterprise scheduler must be registered with the remote system prior to the enterprise scheduler being allowed to schedule jobs. For example, enterprise scheduler 401 would be registered with Java system 403 prior to any scheduling by enterprise scheduler 401. The enterprise scheduler is registered at the remote system by a configuration mechanism provided by the remote system. This may include but is not limited to a configuration file, or a graphical user interface. Typical information used to register/add an enterprise scheduler includes a unique name for the scheduler, a description of the enterprise scheduler, and/or a listing of events that the enterprise scheduler is interested. Most actions performed by the scheduler or remote system raise events. Exemplary events include, but are not limited to: a job starting, a job finishing, a job being cancelled, a job being removed or deleted, a new job definition being deployed, a job definition being updated, a job definition being undeployed, etc. Additionally, in most cases information associated with the user that added the enterprise scheduler is retained. For example, a user's name may be retained so as to ensure that only qualified users are adding enterprise schedulers.
The remote system may or may not offer functionality in order to list which external schedulers are allowed to trigger jobs on the system. The list may be filtered by name, ID, description, user, etc. to display only certain registered enterprise schedulers.
Jobs are scheduled through link 503. As described above, a job definition provides the abstract properties for a job instance. In essence, a job definition is a template that when filled in creates a job instance. Through the link 503, a job may be scheduled if the information required by the relevant job description is provided. For example, the remote system identifier, a name for the job, the jobs input parameters (start time, etc.), retention period (the period for which logs of individual job instances are kept), etc. may used to create a job. As described above, once the job instance is created it is given a unique ID. Typically, jobs, job definitions, logs, etc. are stored in an array(s) or array-like structure(s) (not shown).
A refreshable display in the display area 523 may be used for one or more of the input parameters of a job definition during the creation or revision of a job instance, or, the display area 523 may have input areas for the creation of a job instance without the need to refresh for different needed parameters. Additionally, drop down lists of available job definitions may be provided for the user to select which job to create. Scheduling a job may also include modifying an existing job that is scheduled. For example, changing the start time of a scheduled job or changing other parameters of the scheduled job.
During scheduling, it is important that the local time of the remote server be taken into account. It is not uncommon for the enterprise scheduler to be in a different time zone than the remote server. For example, scheduling a resource intensive job to run on a remote server in New York at 10 PM Munich local time would tie up the resources at the remote server during the middle of the day (presumably when those resources would be used for other, more time critical purposes).
A listing of job definitions available on the remote server is accessible through link 505. The listing may include all jobs or be a filtered list. Job definitions are filterable by ID, name, description, or any combination of ID, name, or description. A listing of job definitions may be specific to the external scheduler.
The jobs scheduled on remote servers are listable using link 507. Individual jobs may be retrieved by remote system identifier and any combination of ID, name, start time, end time, status, vendor data, or return code. A complete listing of all jobs is also possible. However, these listings may be extremely large, and in one embodiment, these listing are iterated in chunks. In other words, only a portion or block of the jobs is retrieved at a time. When the first portion has been retrieved the next block may be retrieved. Processing the array(s) in this manner uses fewer resources and is less susceptible to a memory leak or crash. Depending upon the needs of the system, the block size may be user definable, set by an administrator, or hard coded during deployment.
Of course, the listing of jobs may be further filtered by job status. For example, a list running jobs link 509 provides a list of jobs that have the status of “running;” the list completed jobs link 511 provides a list of jobs that have completed; and the list failed jobs link 513 provides a list of jobs that have failed; etc.
The interface 501 also provides for accessing, planning, or executing scheduler tasks through link 515.
Not shown, but may be provided, are functionalities for one or more of the following: removing an enterprise scheduler; removing, editing, or adding job definitions (a job definition may not be edited or removed if a job using that job definition is scheduled; retrieving job logs; removing job logs; etc.
The scheduling logic 619 interfaces with one or more modules. If the scheduler provides a graphical user interface or “GUI” (such as interface 501) the scheduling logic interfaces with a GUI module 617. Through the interaction between the GUI module 617 and the scheduling logic, commands for scheduling a job, retrieving job definitions, etc. are created for transmission to a remote server. For example, the GUI module 617 may provide input fields for the reception of concrete values for a job definition from a user. These values and other information about the job definition chosen are then transmitted to a remote server.
Job definitions are associated with the scheduler 601. As illustrated, the scheduler 601 has separate job definition listings 601, 605, 609 for each remote server that it communicates with. In an alternative embodiment, the scheduler 601 has one listing but in the entries of the listing as a field for the identification of the remote server that each job definition is associated with. The scheduling logic 619 reads the job definitions as necessary as a template for the creation of a scheduled job, editing of scheduled job, etc.
Jobs that have been scheduled by the enterprise scheduler 601 are also associated with the scheduler 601. As illustrated, the scheduler 601 has separate job listings 603, 607, 611 for each remote server that in communicates with. In an alternative embodiment, the scheduler 601 has one listing but in the entries of the listing as a field for the identification of the remote server that each job is associated with. The scheduling logic 619 reads the jobs as necessary for provide a user with job specific information. Using that information, a user may request the scheduling logic 619 communicate with the remote server to perform a variety of tasks such as stopping a job from starting, etc. In an another embodiment, enterprise scheduler 601 leaves the job list on the remote system and only retrieves by user request though the GUI Module 617. Job definition listings and job listings may be stored in any type of storage type including, but not limited to: hard disk, optical disk, volatile memory, etc.
Additionally, an enterprise scheduler 601 may also have an API 613, 615 associated with each type of server (or even per specific server) that it communicates with. However, if the remote server already has an API on its end, the enterprise scheduler 601 may not need to have or use these APIs.
A filter may be applied to the returned event types at 703. Generally filtering done by the name or string associated with an event type and/or scheduler. Filtering what event types are to be managed by the external scheduler helps reduce the amount of traffic between the scheduler and remote server, thereby decreasing the bandwidth and resources used.
The external scheduler requests the unhandled events from the remote server that the external scheduler is interested in (what has not been filtered out) at 705. Information about one or more of these unhandled events such as deployment (new job definitions added), alterations (job definitions changing), removal, etc. is received by the external scheduler at 706.
The external scheduler may act on these unhandled events at 707. For example, the external scheduler may add, edit, or remove a job definition that it has stored. Upon receiving and/or acting on the receiving unhandled events, the external scheduler sends a command to the remote server at 709 to clear the unhandled events that it sent earlier at 706. At some point later in time, the external scheduler may repeat one or more of the above actions to manage new unhandled events.
Job definitions available at a remote server may change over time. New job definitions may be added, existing definitions removed or altered, etc. Because of these changes, the enterprise scheduler should be updated to have current definitions. This updating may be scheduled to occur at a particular point in time or be performed on demand.
To update the available job definitions, the enterprise scheduler requests that the remote server alert it of any job definitions that have “unhandled events” such as deployment (new job definitions added), alterations ( job definitions changing), removal, etc. at 805. The following description requires that the enterprise scheduler has registered for the new job definitions added and job definition removed events (a job definition updated scenario is mapped to a job definition removed followed by a job definition added event). The remote server returns a listing of events which have not yet been processed by the enterprise scheduler at 807. If there have been deploy or undeploy operations, the list of returned events will contain corresponding events for the deploy/undeploy operations. The deploy/undeploy events do contain the id of the changed job definitions, so the enterprise scheduler can request them 809 or delete it from its repository in case it has been removed from the remote server.
The enterprise scheduler requests job definitions metadata from the remote server using the job definition IDs returned at 807. The enterprise scheduler may make several requests for job definitions associated with unhandled events and receive several job definition IDs prior to the request for job definitions at 807. In essence, the enterprise scheduler may create a batch of job definitions to acquire from the remote server.
The remote server returns job definitions metadata in response to the request for them at 811. The enterprise scheduler then updates its listing of available job definitions.
In an embodiment, instead of getting updated job definitions, the enterprise scheduler simply requests all job definitions in the same manner as the request for job definitions at 801, however, some problems exist with this approach such as too much data may need to be transferred, there is a danger of outdated job definitions being used, etc.
Of course, the external server may also be locally provided with a copy of the job definitions without having to query the remote server. However, using this approach may result in not getting the most up-to-date job definitions.
If the number of jobs is deemed too large, then the number of jobs is divided into smaller chunks. For example, if several hundred jobs are available for review and retrieving the information associated with those jobs would either tie up too many resources (such as the bandwidth between the enterprise scheduler and the remote server) or be difficult to manage, then only a portion of the jobs is viewed/transferred at a time.
The first chunk of jobs is requested at 905 by the enterprise scheduler and received by it at 907. A determination of if there are more job chunks to request is made at 809. If there are no more chunks then the enterprise scheduler will have received all of the jobs available at the remote server.
If there are more chunks, the enterprise scheduler requests the next chunk at 911 and receives the chunk at 913. This process of determining if there is another chunk to retrieve, requesting and receiving that additional chunk is repeated until the enterprise scheduler has all of the jobs available.
Of course, it should be understood that a scheduler local to the remote server may also retrieve job information in a similar manner (i.e., retrieve the information in chunks). Additionally, a similar chunk based technique (i.e., break request into chunks and ask for and receive only a chunk at a time) may by used by an external or local scheduler to get job logs, job definitions, etc.
Multiple jobs may be scheduled to run sequentially or in parallel in one or more components on the remote server as a job chain.
At some point after the scheduled job completes, the external server may again request the unhandled events at the remote server at 1107. These unhandled events are returned at 1108. One of the unhandled events may be an indication that the job has completed.
The external scheduler schedules a second job for execution at 1109. Before or during the execution of the second job, the external scheduler sends a command at 1111 to the remote server to clear the unhandled events that it returned at 1108 as these events are now considered handled.
The external scheduler may continue to request unhandled events and commands to clear the unhandled events that it receives information for including the unhandled events associated with the completion of the second job.
Processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract”) instructions into processor specific instructions (e.g., an abstract execution environment such as a “virtual machine” (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.)), and/or, electronic circuitry disposed on a semiconductor chip (e.g., “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code.
It is believed that processes taught by the discussion above may also be described in source level program code in various object-orientated or non-object-orientated computer programming languages (e.g., Java, C#, VB, Python, C, C++, J#, APL, Cobol, Fortran, Pascal, Perl, etc.) supported by various software development frameworks (e.g., Microsoft Corporation's .NET, Mono, Java, Oracle Corporation's Fusion etc.). The source level program code may be converted into an intermediate form of program code (such as Java byte code, Microsoft Intermediate Language, etc.) that is understandable to an abstract execution environment (e.g., a Java Virtual Machine, a Common Language Runtime, a high-level language virtual machine, an interpreter, etc.).
According to various approaches the abstract execution environment may convert the intermediate form program code into processor specific code by, 1) compiling the intermediate form program code (e.g., at run-time (e.g., a JIT compiler)), 2) interpreting the intermediate form program code, or 3) a combination of compiling the intermediate form program code at run-time and interpreting the intermediate form program code. Abstract execution environments may run on various operating systems (such as UNIX, LINUX, Microsoft operating systems including the Windows family, Apple Computers operating systems including MacOS X, Sun/Solaris, OS/2, Novell, etc.).
An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection)).
The one or more processors 1201 execute instructions in order to perform whatever software routines the computing system implements. The instructions frequently involve some sort of operation performed upon data. Both data and instructions are stored in system memory 1203 and cache 1204. Cache 1204 is typically designed to have shorter latency times than system memory 1203. For example, cache 1004 might be integrated onto the same silicon chip(s) as the processor(s) and/or constructed with faster SRAM cells whilst system memory 1203 might be constructed with slower DRAM cells. By tending to store more frequently used instructions and data in the cache 1204 as opposed to the system memory 1203, the overall performance efficiency of the computing system improves.
System memory 1203 is deliberately made available to other components within the computing system. For example, the data received from various interfaces to the computing system (e.g., keyboard and mouse, printer port, LAN port, modem port, etc.) or retrieved from an internal storage element of the computing system (e.g., hard disk drive) are often temporarily queued into system memory 1203 prior to their being operated upon by the one or more processor(s) 1201 in the implementation of a software program. Similarly, data that a software program determines should be sent from the computing system to an outside entity through one of the computing system interfaces, or stored into an internal storage element, is often temporarily queued in system memory 1203 prior to its being transmitted or stored.
The ICH 1205 is responsible for ensuring that such data is properly passed between the system memory 1203 and its appropriate corresponding computing system interface (and internal storage device if the computing system is so designed). The MCH 1002 is responsible for managing the various contending requests for system memory 1003 access amongst the processor(s) 1201, interfaces and internal storage elements that may proximately arise in time with respect to one another.
One or more I/O devices 1208 are also implemented in a typical computing system. I/O devices generally are responsible for transferring data to and/or from the computing system (e.g., a networking adapter); or, for large scale non-volatile storage within the computing system (e.g., hard disk drive). ICH 1205 has bi-directional point-to-point links between itself and the observed I/O devices 1208.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. For example, while the above description refers to a remote server, other configurations such as clusters of computers or non-servers may have jobs remotely scheduled through an API. Additionally, while the enterprise scheduler is illustrated as being stand-alone, it may be a program run on a computing system such as a server or normal personal computer. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
