The transaction tree for the tightly-coupled integration shown in Figure 2‑1 eliminates the probability for intra-transaction deadlock by minimizing the number of transaction branches required in the interoperation between two domains. Application A makes three requests (r1, r2 and r3) to a remote Domain B. OSI TP sends all three requests mapped to the same OSI TP transaction, T1. On Domain B, the TMA OSI TP gateway checks the
COUPLING flag for the remote service and discovers that for service B the
COUPLING=TIGHT. In this case all requests for service B belong to the same Oracle Tuxedo system transaction. Each request for service B is added to the previous requests and all will have the same Oracle Tuxedo
XID indicated by T2. Resources in group G1 will not be isolated and changes made by any instantiation of service B for this transaction will be “seen” by the others. Request r4 is mapped to identifier T2 on Domain B, but the Tuxedo domain generates a new branch in its transaction tree (r4: B to A'). This is a new transaction branch on Domain A, and therefore, the gateway generates a new mapping T3, to a new Oracle Tuxedo system transaction. The gateway group on Domain A also coordinates group G4, so the hierarchical nature of inter-domain communication is fully enforced with this mapping; group G4 cannot commit before group G1.
The transaction tree for the loosely-coupled integration shown in Figure 2‑2 shows group G0 in Domain A coordinating the global transaction started by the client. In this case application A sends three requests (r1, r2, and r3) to a remote Domain B. Like the tightly-coupled case, all three branches are represented by OSI TP transaction T1. On Domain B, the TMA OSI TP gateway checks the
COUPLING flag for the remote service and sees that service B is
COUPLING=LOOSE. In this case, the TMA OSI TP gateway generates three Oracle Tuxedo system transactions: T2, T3 and T4. Any changes made to G1 are isolated. For example, any changes made by service B can not be “seen” by service B'. When B calls back the A', a new transaction, T5, is generated.
The TMA OSI TP instantiation optimizes GTRID mapping by optionally implementing a tightly-coupled relationship. In TMA OSI TP, service requests issued on behalf of the same global transaction are mapped to the same network transaction branch. Therefore, incoming service requests can be mapped to a single Oracle Tuxedo transaction. However, the hierarchical structure of inter-domain communication and the inter-domain transaction tree must still be maintained. See
Figure 2‑1 for an example of a tightly-coupled relationship.
See Figure 2‑2 for an example of a loosely-coupled relationship. Notice that the gateway still must perform mappings between an Oracle Tuxedo transaction and a network transaction, and that the hierarchical nature of the communication between domains must be strictly enforced.
Figure 2‑2 shows that requests r1, r2, and r3 are mapped to a single TMA OSI TP transaction branch. Therefore, on Domain B only one Oracle Tuxedo transaction needs to be generated; request r4 is mapped to an identifier on Domain B, but TMA OSI TP generates a new branch in its transaction tree (r4: B to A'). This is a new transaction branch on Domain A, and therefore, the gateway generates a mapping to a new Oracle Tuxedo transaction. The graph shows that gateway group GW on Domain A also coordinates group G4. Hence, the hierarchical nature of inter-domain communication is fully enforced with this mapping: group G4 cannot commit before group G1.
•
|
The INBUFTYPE parameter describes the Oracle Tuxedo input buffer that the local client program provides to the TMA OSI TP gateway through Oracle Tuxedo software. When this parameter is specified, the data type and subtype are verified.
|
•
|
The INRECTYPE parameter describes the input record that is sent to the service on the remote system.
|
•
|
The OUTRECTYPE parameter describes the output record that is received from the service on the remote system.
|
•
|
The OUTBUFTYPE parameter describes the Oracle Tuxedo output buffer that is returned to the local client program.
|
The INBUFTYPE parameter is used to specify the request buffer type that is provided to a local TMA OSI TP gateway when a local client program issues a service request. Tuxedo uses this information to restrict the buffer type from the local client to only the types defined by the
INBUFTYPE parameter.
The INRECTYPE parameter is used to specify the type, and in some cases the format, of the request record that a particular remote service requires. The TMA OSI TP gateway uses this information to convert Oracle Tuxedo request buffers into records that remote services can process.
The INRECTYPE parameter may be omitted if the request buffer is identical, in type and structure, to the request record the remote service expects.
You must specify the INRECTYPE parameter when one of the cases described in the following table is true.
The OUTBUFTYPE parameter is used to specify the type, and in some cases the structure, of the reply buffer that a local client program expects. The TMA OSI TP gateway uses this information to map reply records from remote services to the appropriate kinds of reply buffers.The TMA OSI TP maps the incoming record to the type and subtype defined by the
OUTBUFTYPE parameter.
The OUTRECTYPE parameter is used to specify the type, and in some cases the format, of the reply record that a particular remote service returns to the local TMA OSI TP gateway. The TMA OSI TP maps the incoming record to the type and subtype defined by the
OUTBUFTYPE parameter.
The OUTBUFTYPE parameter may be omitted if the remote service returns a reply record that is identical, in type and structure, to the reply buffer the local client program expects.
You must specify the OUTBUFTYPE parameter when one of the cases described in the following table is true.
•
|
The OUTRECTYPE parameter describes the record that the remote client sends to the TMA OSI TP gateway.
|
•
|
The OUTBUFTYPE parameter describes the Oracle Tuxedo buffer that is provided to the local server.
|
•
|
The INBUFTYPE parameter describes the Oracle Tuxedo buffer that the local server returns to the TMA OSI TP gateway.
|
•
|
The INRECTYPE parameter describes the record that the local TMA OSI TP gateway returns to the remote client program.
|
The INBUFTYPE parameter is used to specify the type, and in some cases the structure, of the reply buffer that the TMA OSI TP gateway expects from a local server. This restricts the buffer type naming space of data types accepted by this service to a single buffer type. Because the gateway determines the type of buffer automatically at runtime this parameter is described here for conceptual completeness only.
The INRECTYPE parameter is used to specify the type, and in some cases the format, of the reply record that the local TMA OSI TP gateway sends to the remote client. You can omit the
INRECTYPE parameter if the local server program sends a reply buffer that is identical in type and structure to the reply record the remote client expects.
You must specify the INRECTYPE parameter when one of the cases described in the following table is true.
The OUTBUFTYPE parameter specifies the request buffer type that the local TMA OSI TP gateway provides to the local server. The TMA OSI TP gateway uses this information to convert request records from remote clients into buffers that local server programs can process.
The OUTRECTYPE parameter is used to specify the type, and in some cases the format, of the request record a particular remote client program sends to the TMA OSI TP gateway. The TMA OSI TP maps the incoming record to the type and subtype defined by the
OUTRECTYPE parameter.
The OUTBUFTYPE parameter may be omitted if the local service's request buffer is identical, in type and structure, to the request record the remote client program provides.
You must specify the OUTBUFTYPE parameter when one of the cases described in the following table is true.
1.
|
Oracle Tuxedo CARRAY input buffers can be copied to X_OCTET input records. A CARRAY buffer contains raw data that is not converted or translated. The TMA OSI TP gateway automatically sends the CARRAY Tuxedo buffer as X_OCTET to the remote system; there is no need to set the INRECTYPE parameter.
|
2.
|
Oracle Tuxedo STRING input buffers can be mapped to X_OCTET input records. No data conversion or translation is performed. The STRING buffer is copied left to right, up to and including the first NULL character encountered. However, before sending the data, the gateway removes the NULL terminator. The TMA OSI TP gateway automatically sends the STRING buffer as X_OCTET; there is no need to set the INRECTYPE parameter.
|
3.
|
Oracle Tuxedo XML input buffers can be mapped to X_OCTET input records. The XML buffer is copied to an X_OCTET buffer. There is no translation or conversion performed on the data. This can be useful when passing XML data to systems that do not support XML data types.
|
4.
|
Oracle Tuxedo VIEW input buffers can be mapped to X_COMMON or X_C_TYPE input records. Specify the desired record type and the name of this VIEW definition with the INRECTYPE parameter. The TMA OSI TP gateway translates the VIEW into the correct X_COMMON or X_C_TYPE input record.
|
5.
|
Oracle Tuxedo VIEW, X_COMMON or X_C_TYPE input buffers can be mapped to X_COMMON or X_C_TYPE input records-in any combination. However, in this situation, the data structure that the remote service expects (designated as X_COMMON `B' mapping possibilities in Figure 3-3) differs from the data structure the client program uses (designated as VIEW `A' in Figure 3-3). Consequently, you must
|
1.
|
Incoming X_OCTET output records can be copied to CARRAY or X_OCTET output buffers. A CARRAY buffer contains raw data that is not converted or translated. Set the OUTBUFTYPE to either CARRAY or X_OCTET; the OUTRECTYPE does not need to be set.
|
2.
|
Incoming X_OCTET output records can also be copied to STRING output buffers. This creates a string that goes through no conversion and no translation. When going from X_OCTET to STRING, a NULL value is added at the end for the Tuxedo application. The resultant buffer is the length of the original X_OCTET buffer. Since all characters are copied, if the X_OCTET buffer contains null characters, it affects the buffer when later handled as a STRING. The OUTBUFTYPE should be set to STRING.
|
3.
|
Incoming X_OCTET output records can be mapped to XML output buffers. No translation or conversion is performed on the data. This can be useful when passing XML buffers from systems that do not support XML buffer types to a Tuxedo domain that does support XML data types.
|
4.
|
Incoming output records can be mapped to identical Oracle Tuxedo VIEW output buffers. In this situation, the data structure that the remote service returns is identical to the data structure the local client program expects. There is no need to create a new VIEW definition. The OUTRECTYPE parameter can be set to VIEW:viewname, for greater type checking, but it is not mandatory.
|
5.
|
Incoming X_C_TYPE and X_COMMON output records can be mapped to VIEW output buffers-in any combination. However, in this situation, the data structure that the remote service returns (designated as X_C_TYPE `B' in Figure 2‑6) differs from the data structure the client program expects (designated as VIEW `A' in Figure 2‑6). To facilitate the conversion process, perform the following tasks.
|
6.
|
Incoming X_COMMON or X_C_TYPE output records can be mapped to FML output buffers. To facilitate the conversion process, you must perform the following tasks.
|
7.
|
Incoming NATIVE A output records can be mapped to VIEW output buffers.
|
•
|
If the incoming buffer (INBUFTYPE) or (OUTRECTYPE) = STRING, CARRAY, X-OCTET, or XML the conversion type must be STRING, CARRAY, X-OCTET, or XML
|
•
|
If INBUFTYPE = "FML" or " FML32": or if the buffer being sent to a remote service is of type "FML" or "FML32", then...
|
INRECTYPE, of the remote service,
must be configured to "
VIEW" or "
VIEW32", respectively.
•
|
INRECTYPE and OUTRECTYPE cannot be "FML" or " FML32".
|
•
|
For INBUFTYPE and OUTBUFTYPE, configure buffer type FML as follows:
|
•
|
INBUFTYPE and OUTRECTYPE must be configured to the same type/subtype as the incoming buffer type/subtype.
|
•
|
Packed decimal type dec_t cannot be used in views participating in a conversion when either the source or the destination buffer is FML or FML32 or when the source and destination are two different views.
|
•
|
Packed decimal type dec_t cannot be used in views participating in conversion to NATIVE A buffers.
|
In the following example, incoming buffer VIEW:v12 gets converted to FML, before the request is sent to the local service, and FML gets converted to
X_C_TYPE:v16 before the reply is returned to the remote client.