Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

I'll do it on one condition

Unify event-triggered conditional processes in a single platform

By Chang Sau Sheong, JavaWorld.com, 05/03/02

Most software applications feature processes strung together in sequences, each fulfilling specific functions. In such systems, an end user, directly or indirectly, initiates or starts most processes. Further, most processes are instantaneous—they execute the moment such execution is requested.

In contrast, conditional processes do not immediately execute. Conditional processes execute on the provision that a particular event or occurrence takes place. A conditional process is usually managed by the application system that needs it; for example it could be managed by a cron (a command that executes processes at a specific date/time) job in Unix or by database triggers embedded in a database management system.

In this article, I describe a mechanism that allows Java-based applications to manage conditional processes within the applications themselves. The mechanism unifies all the conditional processes and provides portability to them.

Before we delve into the mechanism for managing conditional processes, let's go through some conditional process groundwork.

Note: You can download this article's source code from Resources.

Conditional processing

Processes come in a hierarchy—all processes stem from some initial root process, in most cases the operating system itself. The root process creates all other subsequent processes. In a controlled environment, spawning subprocesses does not involve the programmer. In other words a programmer can rely on the operating system to handle the processes it spawns. Similarly, in an application, the application handles the processes it generates.

Normal processes execute instantaneously upon creation. In contrast, conditional processes wait for an event to occur before execution. If the controlling environment produces the event, the process becomes simple because the environment can track the event and notify the waiting process. For example, in a graphical user interface (GUI) application, you can track mouse-generated events and notify any processes waiting for a particular mouse click. GUI frameworks like Swing and AWT trap the operating system events and pass them to the processes that need them.

This all works well in controlled environments. Unfortunately, problems arise when the monitored event resides outside the environment that spawns the process's control. A common example is a time-triggered event. The passage of time does not trigger any events in most operating systems. As a result, a passive event-listener mechanism like Swing or AWT cannot monitor this occurrence, and hence such mechanisms usually rely on an external program, like cron in Unix or the AT command in Windows NT/2000. Similarly, other application-specific events, such as user logins or transactions, do not trigger events implicitly if the stimulus resides outside the program.

You could solve the problem with explicit triggers. For example, to listen to user logins, you'd log such events into the database and add database triggers to monitor the data change. However, explicit triggers are native implementations; they depend on the underlying event's triggering mechanism. Further, you cannot directly control them from the waiting process's environment. For example, to use database triggers you need to either depend on the database vendor's trigger implementation or to have a separate process to execute if different events occur. No unifying factor ties either event.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.