|
|
|
|
|
|
How Messages Are Passed from BEA TOP END Clients to BEA Tuxedo Servers
A BEA TOP END client sends requests to BEA Tuxedo servers in the conversational mode in the same way that it sends requests in request/response mode. The TEDG then manages the conversation with the server as shown in the following table.
How the TEDG Works with BEA TOP END Clients
Client operations are programmed with the same functions used for any BEA TOP END client.
|
Use this API . . . |
For . . . |
|---|---|
|
tp_client_send |
Making asynchronous requests |
|
tp_client_signon |
Making asynchronous requests |
|
tp_client_receive |
Receiving responses |
These functions are used in the normal manner when making a service request to a BEA Tuxedo server through the TEDG.
As a BEA TOP END client programmer, you need to know the following information:
If a BEA Tuxedo service supports FML32 input, the BEA TOP END client must use the FML32 message type. FML32 is beneficial because the TEDG and the BEA TOP END system support data marshalling of these buffers when the buffers are transmitted between the TEDG and a BEA TOP END node of a different type. A BEA Tuxedo service may support one or more of these buffer types.
How the TEDG Maps Client Requests
A client request may be transactional or non-transactional; it must require a response. The following table shows how BEA TOP END client flags are mapped. By mapping these flags, the TEDG accomplishes a task that is normally done in the BEA TOP END system. Do not use the input_format and attach_info parameters on requests to the TEDG; they are not supported.
The status and extended status values returned to the BEA TOP END client are standard values. For additional information about the mapping of error values, see Error Values.
The TEDG maps the response from the BEA Tuxedo system or server to a response that the BEA TOP END client accesses through the tp_client_receive(3T) call. BEA Tuxedo servers should send responses in one of the following types of buffers: CARRAY, X_OCTET, or FML32. A CARRAY or X_OCTET buffer is mapped by the TEDG to a raw message; an FML32 buffer, to a BEA TOP END FML32 message. The administrator may constrain the response buffer to a specific type (CARRAY, X_OCTET, or FML32). If the BEA Tuxedo service returns an incompatible buffer, then the TEDG returns a TP_RESET status.
How the TEDG Works with BEA Tuxedo Servers
Relative to a BEA Tuxedo server, the TEDG functions as a conversational BEA Tuxedo client: it receives mapped BEA TOP END client requests in the normal manner. The TEDG always relinquishes control after one message is sent. As a result:
The buffer received is a CARRAY, X_OCTET, or FML32 buffer, depending on the message sent by the client. The BEA Tuxedo server processes the request in the normal manner. Client requests may be transactional or non-transactional.
A BEA Tuxedo server responds to client requests in the standard manner. If the conversation is being continued, it calls tpsend(3c) with the TPRECVONLY flag and data. In this case the server must then call tprecv(3c) to receive the next client message, an error indication, or an indication that the conversation was terminated (TPEV_DISCONIMM). To send the last message of a conversation, the server calls tpreturn(3c) with the TPSUCCESS flag. To terminate a conversation and indicate an error, a server calls tpreturn() with the TPFAIL flag. Reply messages are supported only with tpsend or TPSUCCESS. The application-defined return code, rcode, is not supported by the TEDG.
The BEA Tuxedo server buffer may be a CARRAY, X_OCTET, or FML32 buffer, depending on which types are supported by the BEA TOP END system, the TEDG configuration, and the BEA TOP END client. This buffer is mapped to a BEA TOP END message as described in How the TEDG Maps Client Requests. The server may indicate an error by calling TPFAIL or by responding with an application-defined field value in the reply buffer. The BEA TOP END client must be programmed accordingly. To terminate a conversation, the client ends the dialog by calling tp_client_signoff(3T) or invoking a function switch that calls a different service.
Because BEA TOP END messages are limited to 30K bytes, the BEA Tuxedo server reply may not exceed that limit. For an FML32 message, the limit applies after the FML index is stripped from the message.
How the TEDG Maps BEA Tuxedo Server Flags
The following table shows how the TEDG maps flags to tpsend(3c), the function that transmits BEA Tuxedo server responses. All other flags (TPNOBLOCK, TPNOTIME, TPSIGRSTRT) either are local to the application or affect only server-TEDG interactions in the BEA Tuxedo system.
In addition to regular BEA TOP END error status messages, a number of other status messages may be returned to a BEA TOP END client as a result of problems in the TEDG, the BEA Tuxedo system, or the BEA Tuxedo server. Keep in mind that a single error status value may be used to report any one of many possible causes of the error being reported.
Because the TEDG does not advertise services based upon the actual availability of BEA Tuxedo services, a message may be routed to a BEA Tuxedo node where the services actually are unavailable, resulting in a TP_SERVICE error, while other routing decisions may result in successful requests. If a service is to be available on multiple nodes, the design of the BEA Tuxedo application, the BEA TOP END application, and the TEDG must take into account the possibility that this type of failure may occur. A well-designed application, that ensures that there are multiple, restartable copies of the servers, reduces the possibility of such errors occurring.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|