Messaging Paradigms Supported by Domain Gateways


	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Doc Home \| Administration \| Topic List \| Previous \| Next \| Contents

Using the BEA Tuxedo Domains Component

The functions of the BEA Tuxedo client/server model are supported by the following messaging paradigms in domain gateways:

Request/Response Communication Between Local and Remote Services

Domain gateways provide support for the request/response model of communication defined by the ATMI interface. A BEA Tuxedo application can request remote services exactly as if they were offered locally.

Support for ATMI Functions

The following BEA Tuxedo ATMI functions are logically limited to use within a single application and are not supported across domains:

tpinit(3c)/tpterm(3c)-BEA Tuxedo applications do not attach to the environment of a remote domain; they use Domain gateways to access a remote domain. Therefore, an extra tpinit()/tpterm() sequence is not needed for remote applications.
tpadvertise(3c) and tpunadvertise(3c)-cannot be used across domains. Domain gateways do not support dynamic service advertisements across domains.
tpnotify(3c) and tpbroadcast(3c)-Domains does not support the unsolicited communication paradigm provided by these primitives.
Event posting (tppost(3c)) and notification of events (tpsubscribe(3c))-Domains does not support these functions across domains.

Support for tpforward(3c) is provided to preserve application portability. Forwarded requests are interpreted by domain gateways as simple service requests. This process is shown in the following diagram, which illustrates the simple scenario of a service using tpforward to send a request to a remote service.

Using tpforward to Send a Request to a Remote Service

Conversational Communication Between Local and Remote Services

The ATMI is a connection-oriented interface that enables clients to establish and maintain conversations with services programmed in the conversational paradigm.

BEA Tuxedo applications use tpconnect(3c) to open a conversation with a remote service, tpsend(3c) and tprecv(3c) to communicate with this service, and tpdiscon(3c) to end the conversation. Domain gateways maintain the conversation with the remote service, and support the same semantics for returns (that is, tpreturn with TPSUCCESS or TPFAIL) and disconnects that are defined for BEA Tuxedo conversational services.

Note: The ATMI connection-oriented functions provide half-duplex conversations; tpforward(3c) is not allowed within a conversational service.

Application administrators indicate that a remote service is conversational by specifying CONV=Y in the DM_REMOTE_SERVICES section of the DMCONFIG file.

Queued Messaging for Data Storage

The BEA Tuxedo system enables messages to be queued to persistent storage (disk) or to non-persistent storage (memory) for later processing or retrieval. ATMI provides primitives that allow messages to be added (that is, tpenqueue) or read (that is, tpdequeue) from queues. Reply messages and error messages can be queued for later return to clients. An administrative command interpreter (that is, qmadmin) is provided for creating, listing, and modifying queues. Server are provided to accept requests to enqueue and dequeue messages (that is, TMQUEUE server), to forward messages from the queue for processing (that is, TMQFORWARD server), and to manage the transactions that involve queues (that is, TMS_QM server).

Domain gateways extend support for queued messaging services across domains.