BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
http://www.oracle.com/technology/documentation/index.html | Site Map | Search | PDF Files | Contact | Glossary
Tuxedo Documentation | Programming BEA Tuxedo ATMI Applications Using C | Local Topics | Previous Topic | Next Topic | Contents
Communication Paradigms
The following table describes the BEA Tuxedo ATMI communication paradigms available to application developers.
Paradigm
Description
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 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
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:
Unsolicited events are unexpected situations that are reported by clients and/or servers directly to clients.
Brokered events are unexpected situations or predictable occurrences with unpredictable timeframes that are reported by servers to clients indirectly, through an "anonymous broker" program that receives and distributes messages.
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.
Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.