Oracle® Fusion Middleware Developer's Guide for Oracle Enterprise Scheduling Service 11g Release 1 (11.1.1.6.0) Part Number E24713-01 |
|
|
PDF · Mobi · ePub |
This chapter introduces Oracle Enterprise Scheduling Service as a service for developing jobs that offload work such as executing Java, PL/SQL, and binary process code.
Section 1.2, "Oracle Enterprise Scheduling Service Overview for Application Developers"
Section 1.3, "Fixed-Rate Scheduling with Oracle Enterprise Scheduling Service"
Enterprise applications require the ability to respond to many real-time transactions requested by online users or web services. However, they also require the ability to offload larger transactions to run at a future time or automate the running of application maintenance work based on a defined schedule.
Oracle Enterprise Scheduling Service provides the ability to run different job types, including: Java, PL/SQL, and binary scripts, distributed across the nodes in an Oracle WebLogic Server cluster. Oracle Enterprise Scheduling Service runs these jobs securely, with high availability and scalability, with load balancing and provides monitoring and management through Fusion Middleware Control.
Oracle Enterprise Scheduling Service provides scheduling services for the following purposes:
To distribute job request processing across a grid of application servers,
To run Java, PL/SQL and binary process jobs,
To group job requests into job sets,
To schedule job requests based on recurrence expressions,
To administer job requests with Fusion Middleware Control.
Oracle Enterprise Scheduling Service provides the critical requirements in a service-oriented environment to automate processes that must recur on a scheduled basis and to defer heavy processing to specific time windows. Oracle Enterprise Scheduling Service lets you:
Support sophisticated scheduling and workload management,
Automate the running of administrative jobs,
Schedule the creation and distribution of reports,
Schedule a future time for a step in a business flow for business process management.
Oracle Enterprise Scheduling Service provides features to manage the complete life cycle of a job definition: development, distribution, scheduling, and monitoring. Using Oracle JDeveloper, application developers can easily create job requests in their development environment. Application administrators and other users can specify when and where they want their job requests to run. Users and administrators can monitor how the job ran and access the end results of those jobs.
Customers that implement large systems typically have to manage a large number of diverse machines to handle the workload of their users. Oracle Enterprise Scheduling Service provides the ability to control how work is distributed to individual machines or groups of machines.
Oracle Enterprise Scheduling Service is primarily a Java EE application that provides time- and schedule-based callbacks to other applications to run their jobs. Oracle Enterprise Scheduling Service compares with the Calendar application you might use in your phone or the Oracle Calendar, where you create events and meetings with details about time and recurrence; the application sends an alarm or notification at the right time for the particular event. Similarly, Oracle Enterprise Scheduling Service applications define jobs and specify when those jobs need to be executed, and Oracle Enterprise Scheduling Service gives these applications a callback when that time or when a particular event arrives. This is a simplified model of how a particular application can interact with an instance of Oracle Enterprise Scheduling Service. Oracle Enterprise Scheduling Service does not execute the jobs itself, it gives a callback to the application and the application actually executes the job request. This implies that Oracle Enterprise Scheduling Service is not aware of the details of the job request, all the job request details are owned and consumed by the application. An application that submits requests to run a job is called a client application.
For development purposes, both Oracle Enterprise Scheduling Service and the Oracle Enterprise Scheduling Service client application are deployed on the same Oracle WebLogic Server. The Fusion Middleware Control can provide an interface for interacting with Oracle Enterprise Scheduling Service. Typically, however, you will provide a client application with which the end user can set up a job request and to specify when the job request is scheduled to be executed, and eventually gets a callback from Oracle Enterprise Scheduling Service when the time or event arrives.
At design time an application developer uses Oracle JDeveloper to create a Java EE application that contains the Oracle Enterprise Scheduling Service executable class and Oracle Enterprise Scheduling Service specific metadata for this executable. The Oracle Enterprise Scheduling Service metadata consists of job definitions, including the executable class and parameters, and schedules. Schedules capture the times when a job request can be sent for execution. Schedules are defined independent of job requests and get associated with job requests at runtime when the job request is submitted for execution. Figure 1-1 shows the design time view of an Oracle Enterprise Scheduling Service application.
In Figure 1-1, although the metadata is written to the MDS store through Oracle Enterprise Scheduling Service APIs, the client application owns the metadata and the metadata does not belong to the Oracle Enterprise Scheduling Service application. This metadata together with the job implementation is packaged in an OAR, including the EAR for the application and the MAR containing the metadata; this is deployed in the runtime environment.
You can create the following types of metadata at design time.
Job type: This is a basic definition of what a job would be comprised of and defines the following:
The type of job to be run, such as Java, PL/SQL, binary script, and so on.
The Java executable class if the job is of Java type, or the PL/SQL function if the job is of PL/SQL type, or the script if the job is of Script type.
Parameters definitions for the job and their data type, and default values.
Job definition: A job definition, or job, is the smallest unit of work which gets performed in context of the client application. It is defined by an underlying job type and any parameters additional to the ones defined in the job type.
Job set: A job set is a sequential or parallel set of job steps, where a job step can be a single job or another job set. A job set and each of its job set steps can have additional parameters, the value for which will be provided when the job or job set is submitted as a job request.
Schedule: A job schedule is a predefined time or a recurrence for a period of time or indefinite. Schedules are defined independent of jobs but are associated with one or more jobs at run time when a job request is submitted.
Incompatibility: An incompatibility lets you specify job definitions and job sets that cannot run at the same time.
At run time an application user associates a schedule with the job to be submitted and provides values for the job parameters. This information is then submitted as a job request. Once Oracle Enterprise Scheduling Service receives a job request it determines the right time to execute the job request, and at that time sends a message to the owning client application. The client application then executes the job based on the job metadata and run time values for the parameters.
Figure 1-2 shows the sequence involved with running an application using Oracle Enterprise Scheduling Service, and the following steps:
User submits a request using a client application.
Client application sends the request to Oracle Enterprise Scheduling Service.
Oracle Enterprise Scheduling Service reads the metadata for the request.
Oracle Enterprise Scheduling Service puts the request in a wait queue in Oracle Enterprise Scheduling Service data store, along with the metadata.
At the appropriate time, according to the request specifics, Oracle Enterprise Scheduling Service sends a message to the client application with all the request parameters and metadata captured at the time of submission.
Client application performs the jobs and returns a status.
Oracle Enterprise Scheduling Service updates the history with the job request status.
Figure 1-3 shows the important Oracle Enterprise Scheduling Service components, including the following:
The scheduler component itself, including the runtime module, request dispatcher and request processor.
The client application, including the run time EJB and end point Message-Driven-Bean (MDB) which it calls and the job it requests to execute.
Oracle Metadata Store and the client application metadata.
Oracle Enterprise Scheduling Service schema, including the wait and ready queues and job history.
As shown in Figure 1-3, a client application is composed and runs as follows:
A user interacts with the client application, submitting a job request.
The client application specifies the two EJBs and the Endpoint MDB in its ejb-jar.xml. These beans are then instantiated in the client application context.
The beans in the application context contact the underlying Oracle Enterprise Scheduling Service modules. The run time EJB sends the job request to the underlying run time module in Oracle Enterprise Scheduling Service.
The run time module accesses the client application metadata from Oracle MDS.
The run time module persists the request along with its metadata and schedule in the wait queue in the Oracle Enterprise Scheduling Service schema.
The Oracle Enterprise Scheduling Service request dispatcher determines the correct time to run the job request based on its corresponding schedule. At this time, the request dispatcher moves the request to a ready queue in Oracle Enterprise Scheduling Service schema.
The Oracle Enterprise Scheduling Service request processor continues picking up job requests to be processed from the ready queue.
The request processor sends a message to the application using the endpoint MDB.
Oracle Enterprise Scheduling Service executes the scheduled job.
In most cases or at least in the simplified case, this application will be the same as the application which submitted the request.
Once you have installed a basic Oracle WebLogic Server instance, take the following steps to set up Oracle Enterprise Scheduling Service.
Configure Oracle Enterprise Scheduling Service.
Develop your client application which has your job definitions and other required metadata.
Deploy your client application.
Invoke your client application to submit job request, which in turn calls Oracle Enterprise Scheduling Service.
Invoke your client application to check the status of job request, or other history, which in turn calls Oracle Enterprise Scheduling Service. Alternatively, use Fusion Middleware Control to check the status of a given job request.
Oracle Enterprise Scheduling Service supports fixed-rate scheduling where instances of a repeating job requests are executed at a constant rate starting from the initial scheduled execution time. Each job request runs as near to the absolute time of the schedule as possible. Oracle Enterprise Scheduling Service ensures that only one job request in a repeating request is running at any one time. If a job request runs beyond the scheduled execution time of the next job request, the next job request becomes late and is dispatched immediately upon completion of the previous job request.
When a job request is dispatched, the next request is placed in the wait queue. The execution time for the next job request is the next time in the schedule that is no earlier than the current time. Oracle Enterprise Scheduling Service skips time slots that are in the past.
If the desired behavior is to run all instances of the repeating request regardless of when they are run and regardless of the requested or recurrence end date, the request must set the system property EXECUTE_PAST
.
Oracle Enterprise Scheduling Service does not support fixed-delay scheduling. Using fixed-delay scheduling, each request is executed a fixed delay period after the previous request completes. This means that when one request is late, all subsequent requests will be late as well. In contrast, fixed-rate scheduling tries to get things back on schedule after a late request.