One form of queuing that is relatively easy to implement is to write changes into a staging table. This table is designed for fast writes; for instance, it may be a set of sequential rows with all transaction details in a row and no or only one index. The table could be in a separate database or on another machine. Then a writer program can apply the updates. A strat- egy like this is used by several enterprise applications, such as leading ERP products. By using the database for queuing, we do not need to acquire another piece of software and we can use a data format compatible with the final destination. The problem is latency, since the delay in the update might affect another transaction, and we need to take that into account in the design, possibly by checking the queued transactions when necessary. Figure 11.6 illustrates queuing in the database. Queuing is a very good method for loosely coupled communication between applications. One obvious way to get queuing is to employ a “mes- sage queuing” product. While messaging can be implemented over a data- base, mail, HTTP POST, or FTP, message queue products can provide higher-level facilities including serialization, idempotency, and support for long-running transactions and transaction reversal. Proprietary products include IBM Message Queue Series, BEA, and Microsoft Message Queuing. There are several open source tools for messaging, including JBoss, and sev- eral Java Messaging Services (JMS) products, OSMQ and MOM4J are two open source products that implement JMS for open source languages in addition to Java.