BEA Logo BEA Tuxedo Release 7.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy


   Tuxedo Doc Home   |   Programming   |   Topic List   |   Previous   |   Next   |   Contents

   Programming a BEA Tuxedo Application Using COBOL

Communication Paradigms

The following table describes the BEA Tuxedo communication paradigms available to application developers.

Communication Paradigms



Request/Response Communication

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.

Refer to Writing Request/Response Clients and Servers for more information on this paradigm.

Conversational Communication

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.

Refer to Writing Conversational Clients and Servers for more information on this paradigm.

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 off-line for maintenance, or for buffering communications if the client and server systems are operating at different speeds.

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

Event-based Communication

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.

Refer to Writing Event-based Clients and Servers for more information on this paradigm.