a java-based scheduling service for the enterprise domain

A JAVA-BASED SCHEDULING SERVICE FOR THE ENTERPRISE DOMAIN Vassileios Tsetsos

Odysseas Sekkas

Ioannis Priggouris

Stathes Hadjiefthymiades

University of Athens, Dept. of Informatics and Telecommunications, Panepistimiopolis, Ilissia, GR-15784, Athens,Greece

University of Athens, Dept. of Informatics and Telecommunications, Panepistimiopolis, Ilissia, GR-15784, Athens, Greece

University of Athens, Dept. of Informatics and Telecommunications, Panepistimiopolis, Ilissia, GR-15784, Athens,Greece

University of Athens, Dept. of Informatics and Telecommunications, Panepistimiopolis, Ilissia, GR-15784, Athens, Greece

ABSTRACT Elaborated task Scheduling is considered of major importance for contemporary information systems and service platforms. We present a Java-based implementation of a task Scheduler primarily targeted to the large scale provision of mobile telecommunication services. The requirements for such a system are identified. The object-oriented design of our architecture is presented along with the specific characteristics of the EJB (Enterprise Java Beans) technology that has been adopted as a basis for implementation. A series of trials, involving the scheduling of volumes of tasks, were performed to evaluate the performance achieved by the system. We present our findings, indicating the specific performance bounds of the proposed architecture. KEYWORDS

scheduler, performance evaluation, J2EE, push paradigm, middleware platform, service provisioning

1. INTRODUCTION Scheduled task execution is, nowadays, a widely supported model in many enterprise systems. The concept of scheduling jobs, however, stems from the very early days of computing and is indissolubly connected with the service provisioning domain. An enterprise scheduling service could be incorporated in a variety of systems and enable them to serve their clients according to the Push paradigm [Fra98]. In this paper the architecture of an enterprise scheduling service is presented. This service, referred as Scheduler from now on, was developed as an integrated component of a service provisioning platform used in the mobile networking context. Its role is to support the time/event-triggered service delivery. Although the middleware and service provision platform was focused on the mobile-oriented services (e.g., locationbased and context-aware services) the design of the Scheduler was based on a much more general-purpose requirements analysis and can support a wide range of real-time applications. A prototype implementation of the Scheduler was also developed and tested for its performance and efficiency. Implementation was based on Java technology, which comprises an open and widely adopted standard. One additional goal of the presented work is to supplement the poor bibliography in the scientific domain of service-level scheduling. The rest of the paper is structured as follows. Section 2 references some existing enterprise schedulers. Section 3 presents the architecture and implementation of the Scheduler, including the requirements analysis that drove the design phase, an in-depth architectural analysis and implementation issues. Section 4 summarizes the results of the various tests carried out to verify high performance of the prototype. The paper concludes with a small summary of the presented work and its applicability in the enterprise domain.

I - 339

IADIS International Conference Applied Computing 2004

2. RELATED WORK There are some enterprise schedulers available, but they are mostly proprietary solutions. One such job scheduler is Flux [Sim02], a commercial product that can be used either as a standalone program or as a software component. A user can schedule time-driven, event-driven and file-driven tasks. It also enables the creation of very expressive and flexible schedules, clustering and failover. Kronova eScheduler [Dal03] is a pure enterprise solution. It is used mainly for scheduling batch jobs, such as weekly backups and monthly reports. eScheduler supports many types of tasks: operating system commands, EJBs, local and remote Java objects and e-mail messages. To the best of our knowledge, the only open source scheduler is Pulsar [Bha03], which, however, lacks most of the advanced features of the commercial ones. The abovementioned solutions have much functionality in common; indicative examples are persistence and logging. Finally, all of them are implemented with J2EE, thus taking advantage of the application server’s container facilities.

3. ARCHITECTURE AND IMPLEMENTATION 3.1 Requirements Analysis Our Scheduler was developed as an integrated component of a middleware and service provisioning platform for mobile value added services. Many of the requirements, considered during its development stem from its application domain, but there were also general-purpose requirements, which were taken into account. Existing related solutions provided also a good basis for identifying requirements. The most important requirement is definitely the accuracy of the scheduling engine. A highly accurate engine guarantees that the scheduled tasks will be executed on time or, at least, with the minimum possible delay. This delay should in any case be very short (e.g., in the order of milliseconds) so as not to decrease the reliability of the scheduling service. Scalability issues should be also heavily considered, as the enterprise nature of the scheduler, supposes that a large number of concurrent requests may be handled. Another important feature is the existence of a persistence mechanism, which will enable the scheduler to automatically reschedule tasks after a system crash, thus catering for a smooth failover. Stored information could be further exploited for management purposes or statistics. A logging mechanism may also be used for gathering the same type of information. Special care should be taken, though, so that the logging activity does not degrade the overall scheduler’s performance. Other technical requirements that should be considered include portability, stability and support for clustering and load balancing. Portability across different operating systems, application servers and databases is particularly important, as it ensures independence from specific platforms and potential usability by the largest portion of the market. The rest of the requirements are also important but most application servers have these functionalities inherent and the scheduler can directly exploit them. Finally, support for priorities was not included in our implementation, as it is a characteristic more appropriate for CPU schedulers. The performed requirements analysis resulted to the identification of the main functionalities that need to be incorporated in the enterprise scheduler. The following subsystems, representing also its core functionality, were identified: • the Scheduling subsystem, which includes the client-side interface and the registration mechanisms. • the Task execution subsystem, which is responsible for the accurate execution of the scheduled tasks. • the Persistence subsystem, which performs the persistence of the scheduled tasks, thus providing the desired reliability. The implementation of these subsystems is further discussed in Section 3.4.

3.2 Technology Overview Trying to meet the above requirements, the Scheduler was implemented with state-of-the-art enterprise technologies and standards, using open source software and tools. Specifically, it was developed according to J2EE 1.3 specifications [Cat00]. The Jboss [Sta02] application server was used for development and testing.

I - 340

A JAVA-BASED SCHEDULING SERVICE FOR THE ENTERPRISE DOMAIN

The main advantage of the J2EE application server is the built-in Enterprise JavaBeans 2.0 (EJB) support. EJBs are distributed components running within a container of the application server. They allow the separation of application logic from system-level services thus allowing the developer to concentrate on the business domain issues and not system programming. In addition, the EJB container takes care for advanced issues such as instance pooling, transactions, security and caching. Three EJB types are currently defined in the J2EE specifications: session beans, entity beans and message-driven beans (MDBs). Session beans, either stateless or stateful, represent the enterprise processes and implement the application logic. Entity beans perform the object-oriented mapping to an underlying datastore table. There are two entity bean types: those with Container Managed Persistence (CMP) and those with Bean Managed Persistence. CMP entity beans are more flexible as they are mapped to database entries through an abstraction layer that makes them portable across different databases. MDBs are special EJB components that can consume JMS (Java Message Service) messages from queues, where they are placed by any valid JMS client [Cat00]. A MDB is decoupled from the clients that address messages to it. It is the server’s responsibility to provide concurrent message consumption by pooling multiple MDB instances [Rom02]. These beans are ideal for implementing asynchronous communication and binding with other message-oriented applications. The core scheduling engine of the proposed architecture was implemented with the standard Java Timer class [Joy00] which is highly scalable. As presented in the performance analysis (Section 4), this timer implementation proved to be very efficient. Finally, the lightweight Log4J [Gül03] framework, developed by the Jakarta Project [Goo01] team, was used for logging purposes.

3.3 Architecture Overview The considered Scheduler is a software module consisting of EJBs and plain Java objects. The central architecture element is the stateless session bean SchedulerBean, which is responsible for the initialization of the Scheduler and the scheduling/removal of tasks. This component can schedule two different types of tasks: 1. Time-triggered tasks, which can be either periodic or aperiodic [Fra98]. They have certain time constraints, which are defined upon their registration and should be respected until their expiration. 2. Event-triggered tasks. These are tasks requiring immediate execution, which does not have any time constraints. Although not strictly bound to the scheduling paradigm, such tasks are supported by the scheduling service in order to provide a unified service execution interface. The EJBs were designed according to the Session Façade design pattern, which defines that clients have access only to session beans, not to entity beans [Mar02]. The SchedulerBean’s interface is the only interface a client should know in order to manage the Scheduler. In addition, the SchedulerBean guarantees persistence of the tasks to a relational database through the CMP 2.0 entity bean TaskBean. The primary key of each task is a unique ID generated by the entity bean SequenceBean. Only event-triggered tasks are excluded from this procedure. Such tasks are directly forwarded for execution to the TaskHandler message-driven bean. EJB Container

Database

TaskBean retrieves PK stores tasks

SequenceBean

Persistence Subsystem

Client

SchedulerBean

sends tasks for execution

Task Execution Subsystem

Queue listens for next task

schedules tasks

sends tasks for execution

TaskHandler

Timer

Scheduling Subsystem

Figure 1. Scheduler architecture

I - 341

IADIS International Conference Applied Computing 2004

The TaskHandler executes the core task logic of the time- and event-triggered tasks. The execution details are passed to this EJB as method arguments. Its asynchronous implementation decouples the core scheduling engine from the execution of the tasks. This decoupling has a significant effect on the performance of the Scheduler as will be shown in Section 4. The Scheduler has a reconfigurable logging mechanism that logs every internal activity, including failures, with little additional performance overhead. The scheduler architecture along with its components is depicted in Figure 1. These components can be deployed inside any J2EE-compliant application server, either in the same machine or in remotely connected hosts. The second option provides the advantages of clustering, but the first one is more time-efficient (due to the local interfaces defined in EJB 2.0 specification). The design of the Scheduler was based on the system decomposition presented in Section 3.1 and is discussed in more detail in subsequent sections.

3.4 Detailed Design and Implementation 3.4.1

The Scheduling Subsystem

The Scheduling subsystem is implemented by the session bean SchedulerBean and the Timer. SchedulerBean is responsible for scheduling tasks in the Timer or sending tasks directly for execution in the TaskHandler. Furthermore, it collaborates with the Persistence subsystem, in order to store information pertaining to each scheduled task. The SchedulerBean has three basic methods: “initialize”, “schedule” and “remove”. • Method “initialize”. Initialization performs the rescheduling of all tasks that are stored in the database and have not expired yet (the expired tasks are removed from the database). The relevant UML Sequence Diagram can be viewed in Figure 2. • Method “schedule”. This method is invoked when a new task needs to be scheduled. Upon being scheduled, each time-triggered task receives a unique ID and then is registered on the Timer (Figure 3). Event-triggered tasks, on the other hand, are executed immediately without being registered. • Method “remove”. The method is called for removing a scheduled task from the Timer. After its removal the task is also deleted from the database and is not executed again.

Figure 2. The sequence diagram of method “initialize”

Figure 3. The sequence diagram of method “schedule” (time-triggered)

Each task (represented with the class Task) has a start time, a stop time and a period. We define them as invocation parameters. Obviously, there are eight possible combinations of the invocation parameters and

I - 342

A JAVA-BASED SCHEDULING SERVICE FOR THE ENTERPRISE DOMAIN

Scheduler can handle all of them. Apart from the invocation parameters and the ID, the Task object has an attribute which defines the data of the service to be executed. The service can be any Java object or servlet. The most important component of the subsystem is the Timer. It is based on the java.util.Timer class and is responsible for triggering the execution of tasks when needed. Each Timer object uses a single background thread for executing all of the timer's tasks. Internally, it uses a binary heap to represent its task queue, so the cost to schedule a task is O(log n), where n is the number of concurrently scheduled tasks. Tasks may be scheduled for one-time execution, or for repeated execution at regular intervals in two ways: fixed-delay execution and fixed-rate execution [Joy00]. In Scheduler we chose fixed-delay execution because this method is more appropriate for activities that require "smoothness" (i.e., keeping the frequency accurate in the short run rather than in the long run). Scheduled tasks can be canceled at any time, using the reference ID assigned to them upon their scheduling. Canceling a task results to its removal from both the Timer and the database where it may have being stored.

3.4.2

The Persistence Subsystem

The Persistence subsystem, comprised of TaskBean and SequenceBean (see Figure 1), is responsible for storing data pertaining to time-triggered tasks in order to maximize the reliability of the Scheduling service. The TaskBean is the interface of the relational database used for storing the task details. It is a CMP 2.0 entity bean. CMPs can be developed much more rapidly because the EJB container performs storage operations, handles all data access logic and generates the JDBC code. This simplifies development and enhances scalability offering an abstraction layer over JDBC [Eck00]. The SequenceBean, which is responsible for generating unique IDs for the scheduled tasks, is also considered as part of this subsystem. The generated IDs are used as primary keys for the records stored in the DB. Stored data include the start and stop time as well as the execution period for each task and is used during the initialization of the Scheduler.

3.4.3

The Task Execution Subsystem

The basic component of this subsystem is the message-driven bean TaskHandler, which is bound to a message queue (see Figure 1). When a Task “runs”, it acts like a JMS client that sends a message to the Queue. This message contains information pertaining to the service execution. The SchedulerBean has also the same role (i.e., JMS client) in the case of event-triggered tasks. This asynchronous implementation has a great impact on performance because tasks complete quickly without delay. Specifically, the actual operation performed by each scheduled task is degraded to the simple insertion of a message in the JMS queue. This is considered as a very lightweight operation, compared to what a service might have involved. Execution of the service takes place immediately after the message is consumed from the Queue and is completely decoupled from Timer. Thus it does not affect at all the Scheduler's performance.

4. PERFORMANCE EVALUATION The performance evaluation of the scheduler component was performed in a machine with Athlon 1.3 Mhz CPU. The operating system was Windows 2000 Professional, configured to execute a minimum set of background services. Jboss 3.0.4 was the J2EE application server, which was used for both the development and the performance evaluation of the software component. Its embedded Hypersonic SQL database was used for the persistence of tasks. No special performance tuning was applied to the overall server software. Several different test cases were developed and used. In most of these tests the time intervals between the scheduling of two successive tasks follow the exponential distribution (thus, simulating a random arrival model). The exact testing configurations, as well as the metrics used, are described in the following sections.

4.1 Metrics The performance metrics of a scheduler can be divided in system metrics and user metrics [Fei98] [Jai91]. The first category includes throughput, utilization, makespan and efficacy. All of them try to capture how efficiently the system resources are being utilized and for that reason are best suited for low-level schedulers (e.g., CPU schedulers). The second category, which is of most importance for an application scheduler, includes turnaround time and average delay. These metrics focus on the measurement of the performance

I - 343

IADIS International Conference Applied Computing 2004

from the end user’s perspective. The inclusion of all kinds of metrics in a test suite, can give a quite clear view of the scheduler’s capabilities and limitations. The most important metric in a real-time scheduler is the actual time that a task execution has delayed. The delay metric is defined as the elapsed time between the trigger of a task and the start of its execution. In our case, delay includes both the delay of the timer and the time a task has been waiting in a queue. Delay is not related to the nature of the scheduled jobs (unless they are classified into priority classes). So a simple arithmetic mean is enough to capture the implications of average delay. This time, as already stated, should be less than a second for the vast majority of the tasks. Hence, the appropriate time measurement unit is the millisecond. In order to measure the maximum, minimum and average task delays and indicate their correlation with the scalability of the Scheduler, several tests were performed. The throughput, which is defined as the number of jobs that are completed per unit time, has also been measured. This metric, is not very important for end users, but is strongly related to the scalability of the scheduler. Turnaround time is the time from the moment the user submits the job to the system till the system finishes its execution. From the user’s perspective, turnaround time is a crucial metric, which must be minimized. Turnaround time has two components, waiting time and run time. The waiting time is the time that the job spends in a queue waiting to be assigned to a server while the run time is the time needed for the complete execution of a task. In the context of the present test suite, we measure both the throughput and the turnaround times (the latter only for event-triggered tasks).

4.2 Test Descriptions and Results Before performing the actual tests, some stressful test cases were examined in order to determine the behavior of the Scheduler under heavy load conditions. The results of these stress tests allowed the determination of limit values of the Scheduler’s performance. During the initial stress test an inordinate number of tasks (actually 300) were scheduled for simultaneous execution (at the same millisecond). The delays observed were between 0 and 30 ms and the average delay was approximately 19 ms. Additionally, the delay was a linear function of the number of tasks scheduled. Moreover, when 50 tasks were scheduled, each one of them having an 20 ms interval from the previous one, the average delay was 17 ms. These results indicate that the maximum throughput our Scheduler can handle, before delay starts to increase exponentially, is in the order of 50 tasks/sec.

Test 1: Delay This test demonstrates the delays imposed on the tasks by the Scheduler. Apparently, hourly or daily periodic tasks, even in a large number, would not induce an overload problem on the Scheduler. We are interested in more frequent executing activity. In this respect, the task periods were randomly picked up from the set [2, 3, 5, 10, 30] seconds. It should be stressed that, such periods are not representative for real-world tasks, but were appropriate for the desired load tests. As tasks are supposed to commence execution at random times, thus simulating random arrivals, the interval time X between the scheduling of two successive tasks was modeled as exponentially distributed variable with mean arrival rate λ=5 tasks/sec. The formula used is: 1 X = - ln(u ) (1) λ where λ is the arrival rate and u a uniformly distributed random number in the [0,1] interval. Provision has also been taken so as not to exceed the limit of 50 task executions/sec. Thus, the number of tasks in each period group was adjusted accordingly. Figure 4 depicts the average and maximum delay observed. The minimum delay was systematically 10 ms, which reflects the delay for inserting and consuming a message from the queue. These values were measured when all tasks were executing. The average throughput during this time period was 2500 tasks/min (or 41.67 tasks/sec).

Test 2: Delay with Variable Offered Load In this test, we exceeded the 50 tasks/sec limit and observe how performance varies. The offered load (tasks/sec) is increased on steps of 5 tasks/sec and the periods (the same as in Test 1) are evenly distributed

I - 344

A JAVA-BASED SCHEDULING SERVICE FOR THE ENTERPRISE DOMAIN

among them. As shown in Figure 5, maximum delay increases substantially as throughput increases. Moreover, Figure 6 shows that the delay is a rough approximation of a linear function of time (or task executions). The solid line shows the first execution of the last scheduled task, whereas the dashed line shows the time this task should normally have been executed. If the offered load is higher than 50 tasks/sec, the delay systematically increases. Finally, Figure 7 shows the delay values and behavior for a “normal” throughput of 50 tasks/sec. In this figure, the dashed line shows both the first execution of the last scheduled task and the time it should normally have been executed, as there is only a 23 ms delay.

Test 3: Turnaround Time of Event-triggered Tasks This test is quite similar to Test 1. The only difference is that during the last minute of test execution around 360 event-triggered tasks were fired, arriving at random times. The rationale behind this test case was to measure the turnaround times of these tasks. The average times were found to be between 3 and 50 ms, the maximum times between 800 and 2640 ms and 90% of the invoked tasks had execution times lower than 20 ms. The corresponding average turnaround time for tasks invoked on an idle scheduler is 1.6 ms, with less than 1% of the tasks exceeding the 20 ms. 2500

150000

2000

max delay (ms)

delay (ms)

100000 max delay

1500

1000

50000 average delay 500

708 ms 0 100

200

300

400

500 600 tasks

700

800

900

0

1000

45

50

Figure 4. Average and maximum delay

55

60

65 70 task/sec

75

80

85

90

Figure 5. Maximum delay

150000

800 700 600

100000

delay (ms)

delay(ms)

500 400 300

50000

200 100 0 0

27

54

81

108 135 timeline(sec)

162

189

Figure 6. The delay for 90 tasks/sec

216

243

0 0

28

56

84 112 timeline (sec)

140

168

196

Figure 7. The delay for 50 tasks/sec

Test 4: Heavy Load Conditions This test case aims at demonstrating the Scheduler’s behavior under more realistic conditions regarding the mobile services context, which is, after all, its targeted environment. The periods used are shown in Table 1. The number of scheduled tasks was also increased significantly (10000, 15000 and 20000 tasks) and the scheduling rate was raised to 10 tasks/sec. To compare the results, both the delay as well as the number of tasks scheduled so far were monitored, 40 minutes after the initial scheduling. For 10000 tasks, the results

I - 345

IADIS International Conference Applied Computing 2004

were quite satisfactory: the average delay was below 200 ms, and all the tasks had been scheduled 15 minutes after the start. For 15000 tasks, the delay was very short (below 300 ms) until the number of scheduled tasks reached 13800. After that point the delay began to increase, and 40 minutes after the test start, delay was Table 1. Period distribution Percentage of scheduled tasks Period (min) 1% 0.5 4% 1 5% 2 20% 5 70% 10

about 8 minutes with only 14600 out of the 15000 tasks having been scheduled. Finally, for 20000 tasks the delay started to increase uncontrollably when the number of tasks reached 12000 and after 40 minutes of test execution only 12350 tasks had been scheduled. The above results are quite promising, as the majority of the tasks in real-world conditions should have even larger periods. In general, what became obvious from this study is that the main factor that affects the performance is not the number of scheduled tasks but the load that was offered by the Scheduler’s clients. The aforementioned results prove that only a minimal performance overhead is imposed by the Scheduler.

5 CONCLUSION We have presented the architecture of a scheduling mechanism capable of supporting the scheduling paradigm in different application domains. Scheduled execution of services and tasks is an important aspect of every enterprise system since the origin of the computing technology. Today, the increased focus on service delivery by business vendors as experienced by the cataclysmic admission of new advanced, multipurpose services in the market requires more than ever the existence of integrated solutions capable of supporting a variety of provisioning schemes. Within this context the presence of an efficient scheduling service capable of supporting the triggered execution of service instances using a plethora of different parameters is evident. The scheduling service, whose design, characteristics and performance was discussed, could provide a competent solution and cover this need. Moreover its open design and implementation using java technologies makes it an ideal solution for integration with existing service provisioning solutions running over heterogeneous infrastructures. Finally, high performance and scalability determined through intensive testing guarantees its applicability and suitability for the enterprise sector.

REFERENCES [Bha03] Bhattacharya B., 2003, Pulsar J2EE Scheduler. Online reference: j2eescheduler.sourceforge.net [Cat00] Cattell R. et al, 2000, Java 2 Platform, Enterprise Edition: Platform and Component Specifications. AddisonWesley Pub Co, USA. [Dal03] Dale G., 2003, Kronova eScheduler Concepts Guide. Indus Consultancy Services, Inc. [Eck00] Eckel B., 2000, Thinking in Java Second Edition. Prentice-Hall, USA. [Fei98] Feitelson D. and Rudolph L., 1998, Metrics and Benchmarking for Parallel Job scheduling. In Job Scheduling Strategies for Parallel Processing, Springer-Verlag, Lect. Notes Comput. Sci. Vol. 1459, pp. 1-24 [Fra98] Franklin M. and Zdonik S., 1998, Data In Your Face: Push Technology in Perspective. ACM SIGMOD International Conference on Management of Data, Seattle, Washington, USA, pp. 516-519. [Goo01] GoodWill J., 2001, Apache Jakarta-Tomcat, Apress Publishing, Berkeley. [Gül03] Gülcü C., 2003, The complete log4j manual. QOS.ch, Lausanne, Switzerland. [Jai91] Jain R., 1991, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling.Wiley- Interscience, New York, USA. [Joy00] Joy B. et al, 2000, Java(TM) Language Specification, 2nd Edition, Addison-Wesley Pub Co, USA. [Mar02] Marinescu F., 2002, EJB Design Patterns, John Wiley and Sons, Inc., USA. [Rom02] Roman Ed et al., 2002, Mastering Enterprise JavaBeans 2nd Edition, Wiley Computer Publishing, USA. [Sim02] Sims D., 2002, Job Scheduling in J2EE Applications. Sims Computing, Inc. USA. [Sta02] Stark S. et al, 2002, Jboss Administration and Development 2nd Edition. Jboss Group LLC, Atlanta, USA.

I - 346