Concepts

In general, applications and software components communicate via three mechanisms: method calls, events, and messages. A method call is a direct invocation of a specific operation performed by a specific component. For example, the method call database.deleteRecord(key) tells a specifc database object to delete the record identified by the parameter key.

Communication via events is less direct, because there is at least one intermediate layer between the initiator of an operation and the component that performs the operation. The most familiar events are those generated by a user interacting with objects (buttons, menus, etc.) in an application's user interface. In such cases, the user action (clicking a button, choosing a menu item, etc.) is not an end in itself—the action is interpreted by an event listener which in turn dispatches it to the appropriate destination. For example, a user interface could include a Record menu that provides Insert and Delete options and is implemented to listen for menuChoice events. When a user chooses an item from this menu, the system generates a menuChoice event and sends it to the Record menu component, which parses the event and invokes a method, for example, database.insertRecord or database.deleteRecord, based on event parameter values. Note that in this typical scenario, the event listener needs to know which object and which method to invoke. To implement an event listener, developers must decide up front which events to handle and what actions to take when an event is received.

Messaging is the least direct mechanism of the three. The sender must know how to format the message and where to send it, and the recipient must know the message format and where to get it, but neither component needs to know anything about the other. J2EE components and applications perform messaging tasks using the Java Messaging Service (JMS) API. JMS provides two programming models:

• Point-to-point (queue), where each message is sent to one recipient.
• Publish and subscribe (topics), where messages are broadcast to one or more registered listeners.

JMS queues and topics are bound to the JNDI environment and made available to J2EE applications.

The EJB specification uses the point-to-point JMS model as the basis for message-driven beans (MDBs). In essence, an MDB is a JMS listener with additional functionality provided by the EJB container. Senders place messages in a queue, and the container processes the queue by dispatching each message to the appropriate MDB (the deployment descriptor for each MDB declares the queue it will listen to). Processing is asynchronous, meaning that the container does not have to wait for any given MDB to respond before performing the next operation.

Oracle Containers for J2EE (OC4J) provides support for MDB in conjunction with Oracle JMS (Java Messaging Service), which is installed and configured on an Oracle database. Within this database, messages are managed using Oracle Advanced Queuing (AQ). The following figure gives an overview of the process.

Oracle AQ is implemented as an integral part of the Oracle database management system. Advanced Queues are relational database tables, enhanced to support queuing operations like enqueue and dequeue. Messages are stored as rows in a table, and you can use standard SQL to:

• Access a message's payload, control information, and history.
• Optimize access using technology such as indexes.

The Design section describes how OTN developers decided where and how to use MDBs in the FBS 10g. Coding details are discussed in the Implementation section.