1 Overview of Oracle Application Server Containers for J2EE

Oracle Application Server Containers for J2EE enables J2EE clients to submit asynchronous, autonomous background jobs to be run in Oracle Application Server Containers for J2EE (OC4J). Some major features of this component are:

• API for submitting, controlling, and monitoring jobs

• API-level Java Transaction API (JTA) support for job submission and control

• Temporal- and trigger-based jobs

• Automatic retry of failed jobs

• Job blackout windows

• Java Management Extensions (JMX) MBeans for monitoring and administering Oracle Application Server Containers for J2EE

• Configurable logging of various system, error, and warning messages

This chapter provides an overview of Oracle Application Server Containers for J2EE. The following topics are covered:

• Job Scheduler Concepts and Terminology

• Basic Job Scheduler Implementation Example

1.1 Job Scheduler Concepts and Terminology

This section introduces basic concepts and terminology you should know before using Job Scheduler. The following topics are covered:

• Notifications and Triggers

• Schedules

• Blackout Windows

1.1.1 Notifications and Triggers

A notification is a message sent from the application to a trigger. The message contains information about the occurrence of a specific condition or conditions in the application.

The recipient of a notification is known as the trigger. Each trigger contains a description of a condition that is evaluated against any incoming notifications. When a trigger (or multiple triggers) evaluates to true, a job associated with the condition is started.

Triggers are described by logical expressions, where the operands are the notifications. Notifications are generated either programatically by the application or as a result of a timer expiration (for example, if a job does not execute by a specific time). A notification may be sent to either a specific trigger or sets of triggers. Triggers, however, do not generate notifications when they receive notifications.

For more information, see Chapter 8.

1.1.2 Schedules

A schedule specifies the time and period or periods when a timeout notification is sent to the associated trigger. The specific point in time is expressed as the expiration, and the frequency is expressed as an interval. A schedule instance can be categorized as either single-action (non repeating) or repeating.

For more information about schedules, please refer to Chapter 3.

1.1.3 Blackout Windows

A blackout window specifies a period of time during which all jobs are suppressed. A blackout window contains a schedule and a duration (for example, Friday between 6:00 p.m. and 12:00 a.m.). A blackout window may also be repeating (for example, every Tuesday between 6:00 p.m. and 8:00 p.m.).

For more information, see Chapter 4.

1.2 Basic Job Scheduler Implementation Example

In this example, the application developer wants to create a report that can be run periodically according to the application's needs. The application will submit requests to run the report, supplying some query input parameters and stating how often to run the report.

1. The developer writes a class that implements the Job Scheduler Executable interface, using the execute() and getContext() methods. The execute() method is written by the developer and will be called by Job Scheduler. The application calls the system-supplied getContext() method to get the input parameters.

   For more information about adding jobs, see Chapter 2.

2. The developer writes a client program for the application through which a user can submit a report request, cancel a report request, or check to see what requests were made. To service requests, the client program gets a reference to a Scheduler Enterprise Java Bean (EJB) deployed with the application (the Job Scheduler is deployed as a stateless session EJB). Note that the client program could be implemented as a standalone GUI, a servlet, or indirectly through another EJB.

   For more information about deploying Job Scheduler-enabled applications, see Chapter 9.

   1. To submit a job, the program parameters are specified using the java.util.Properties class. Then, the Scheduler.add() method is used to submit the job to be run at a particular time.

   2. To find out what jobs were submitted, use the Scheduler.getJobs() method. Both pending and completed jobs are displayed.

   3. To remove a job, use the Scheduler.remove() method. This action terminates any future scheduling of a job.

   4. To cancel jobs that are running, use the Scheduler.cancel() method.

      For more information about canceling jobs, see Chapter 6.

3. The developer packages the application, including:

   1. The classes described previously.

   2. An EJB JAR file referencing Job Scheduler EJB. This is a pre-written, system-supplied EJB that has methods for submitting, querying, and controlling jobs.

   3. The client portion of the application.

      For more information, see Chapter 9.