now, everything detailed in the Forethought application has been
based on synchronous
. This simply means that an event is
triggered by some client, then responded to by an application
component, and finally an answer is returned to that client. For
example, when a Java class requests that a new user be created, the
UserManager accesses the User bean, that bean
interacts with the database, and an acknowledgment is triggered back
up the calling stack. The extensive coverage of this type of
interaction is justified, as you will be dealing with synchronous
processing far more often than not.
However, there are times when you want more of a listener paradigm. In this case, an application component waits for certain types of events and responds only when those events occur. That component is called a listener , because it listens for application events. When it is activated, it takes some sort of action, often interacting with various other components in the application. It typically does not send any acknowledgment when its actions are done, making it asynchronous in operation. I’ll detail this sort of behavior in this chapter, focusing on the scheduling component of the Forethought application. Meetings will be added to the Forethought queue and reported to a scheduling client, which simply spits these meetings back out to waiting recipients.
Additionally, this chapter will wrap up some loose ends by detailing the final packaging ...