Request/response communication enables one software module to send a request to a second software module and wait for a response. Can be synchronous (processing waits until the requester receives the response) or asynchronous (processing continues while the requester waits for the response).

This mode is also referred to as client/server interaction. The first software module assumes the role of the client; the second, of the server.

Conversational communication is similar to request/response communication, except that multiple requests and/or responses need to take place before the "conversation" is terminated. With conversational communication, both the client and the server maintain state information until the conversation is disconnected. The application protocol that you are using governs how messages are communicated between the client and server.

Conversational communication is commonly used to buffer portions of a lengthy response from a server to a client.

Application queue-based communication

Application queue-based communication supports deferred or time-independent communication, enabling a client and server to communicate using an application queue. The BEA Tuxedo/Q facility allows messages to be queued to persistent storage (disk) or to non-persistent storage (memory) for later processing or retrieval.

For example, application queue-based communication is useful for enqueuing requests when a system goes offline for maintenance, or for buffering communications if the client and server systems are operating at different speeds.

Refer to Using the ATMI /Q Component for more information on the /Q facility.

Event-based communication allows a client or server to notify a client when a specific situation (event) occurs.

Events are reported in one of two ways:

Event-based communication is based on the BEA Tuxedo EventBroker facility.