Overview of Typed Buffers

2.1 Overview of Typed Buffers

Before a message can be sent from one process to another, a buffer must be allocated for the message data. Oracle Tuxedo ATMI clients use typed buffers to send messages to ATMI servers. A typed buffer is a memory area with a category (type) and optionally a subcategory (subtype) associated with it. Typed buffers make up one of the fundamental features of the distributed programming environment supported by the Oracle Tuxedo system.

Why typed? In a distributed environment, an application may be installed on heterogeneous systems that communicate across multiple networks using different protocols. Different types of buffers require different routines to initialize, send and receive messages, and encode and decode data. Each buffer is designated as a specific type so that the appropriate routines can be called automatically without programmer intervention.

The following table lists the typed buffers supported by the Oracle Tuxedo system and indicates whether or not:

The buffer is self-describing; in other words, the buffer data type and length can be determined simply by (a) knowing the type and subtype, and (b) looking at the data.
The buffer requires a subtype.
The system supports data-dependent routing for the typed buffer.
The system supports encoding and decoding for the typed buffer.

If any routing functions are required, the application programmer must provide them as part of the application.

Table 2-1 Typed Buffers

Typed Buffers	Description	Self- Describing	Subtype	Data- Dependent Routing	Encoding/Decoding
CARRAY	Undefined array of characters, any of which can be NULL. This typed buffer is used to handle the data opaquely, as the Oracle Tuxedo system does not interpret the semantics of the array. Because a CARRAY is not self-describing, the length must always be provided during transmission. Encoding and decoding are not supported for messages sent between machines because the bytes are not interpreted by the system.	No	No	No	No
FML (Field Manipulation Language)	Proprietary Oracle Tuxedo system type of self-describing buffer in which each data field carries its own identifier, an occurrence number, and possibly a length indicator. Because all data manipulation is done via FML function calls rather than native C statements, the FML buffer offers data-independence and greater flexibility at the expense of some processing overhead. The FML buffer uses 16 bits for field identifiers and lengths of fields. For more information about the FML buffer, see Using an FML Typed Buffer	Yes	No	Yes	Yes
FML32	Equivalent to FML but uses 32 bits for field identifiers and lengths of fields, which allows for larger and more fields and, consequently, larger overall buffers. For more information about the FML32 buffer, see Using an FML Typed Buffer	Yes	No	Yes	Yes
STRING	Array of characters that terminates with a NULL character. The STRING buffer is self-describing, so the Oracle Tuxedo system can convert data automatically when data is exchanged by machines with different character sets.	Yes	No	No	No
VIEW	C structure defined by the application. VIEW types must have subtypes that designate individual data structures. A view description file, in which the fields and types that appear in the data structure are defined, must be available to client and server processes that use a data structure described in a VIEW typed buffer. Encoding and decoding are performed automatically if the buffer is passed between machines of different types. VIEW does not support mbstring type buffers. For more information about the VIEW buffer, see Using a VIEW Typed Buffer	No	Yes	Yes	Yes
VIEW32	Equivalent to VIEW but uses 32 bits for length and count fields, which allows for larger and more fields and, consequently, larger overall buffers. VIEW32 supports mbstring type buffers and treat mbstring data in the same manner as carray. For more information about the VIEW buffer, see Using a VIEW Typed Buffer	No	Yes	Yes	Yes
X_C_TYPE	Equivalent to VIEW.	No	Yes	Yes	Yes
X_COMMON	Equivalent to VIEW, but used for compatibility between COBOL and C programs. Field types should be limited to short, long, and string.	No	Yes	Yes	Yes
XML	An XML document that consists of: Text, in the form of a sequence of encoded characters A description of the logical structure of the document and information about that structure The routing of an XML document can be based on element content, or on element type and an attribute value. The XML parser, such as the Apache Xerces C++ Version 3.2.3 parser available in Oracle Tuxedo 22.1, determines the character encoding being used; if the encoding differs from the native character sets (US-ASCII or EBCDIC) used in the Oracle Tuxedo configuration files (`UBBCONFIG(5)` and `DMCONFIG(5)`), the element and attribute names are converted to US-ASCII or EBCDIC. For more information about the XML buffer and the Xerces C++ parser, see Using an XML Typed Buffer and the Apache Xerces C++ Parser	No	No	Yes	No
X_OCTET	Equivalent to CARRAY.	No	No	No	No
MBSTRING	Character array for multibyte characters—available in Oracle Tuxedo 8.1. For more information about the MBSTRING buffer, see Using an MBSTRING Typed Buffer	No	No	No	No
RECORD	COBOL copybook record defined by application. RECORD types must have subtypes that designate record structure. A record description file, in which the fields and types that appear in the record structure are defined, must be available to client and server processes that use a record structure described in a RECORD typed buffer. For more information about the RECORD buffer, see Using a RECORD Typed Buffer.	No	Yes	No	Yes

All buffer types are defined in a file called tmtypesw.c in the $TUXDIR/lib directory. Only buffer types defined in tmtypesw.c are known to your client and server programs. You can edit the tmtypesw.c file to add or remove buffer types. In addition, you can use the BUFTYPE parameter (in UBBCONFIG) to restrict the types and subtypes that can be processed by a given service.

The tmtypesw.c file is used to build a shared object or dynamic link library. This object is dynamically loaded by both Oracle Tuxedo administrative servers, and application clients and servers.