Overview of Typed Buffers


	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 \| Programming \| Topic List \| Previous \| Next \| Contents

Programming a BEA Tuxedo Application Using C

Before a message can be sent from one process to another, a buffer must be allocated for the message data. BEA Tuxedo System clients use typed buffers to send messages to 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 BEA 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 buffers 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 BEA 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.

Typed Buffers

Typed Buffer
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 BEA 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 BEA 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.

Refer to Using an FML Typed Buffer for more information.

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.

Refer to Using an FML Typed Buffer for more information.

Yes

No

Yes

Yes

STRING

Array of characters that terminates with a NULL character. The STRING buffer is self-describing, so the BEA 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. Refer to Using a VIEW Typed Buffer for more information.

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.

Refer to Using a VIEW Typed Buffer for more information.

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 determines the character encoding being used; if the encoding differs from the native character sets (US-ASCII or EBCDIC) used in the BEA Tuxedo configuration files (UBBCONFIG(5) and DMCONFIG(5)), the element and attribute names are converted to US-ASCII or EBCDIC. Refer to Using an XML Typed Bufferfor more information.

No

No

Yes

No

X_OCTET

Equivalent to CARRAY.

No

No

No

No

Typed Buffer	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 BEA 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 BEA 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. Refer to Using an FML Typed Buffer for more information.	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. Refer to Using an FML Typed Buffer for more information.	Yes	No	Yes	Yes
STRING	Array of characters that terminates with a NULL character. The STRING buffer is self-describing, so the BEA 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. Refer to Using a VIEW Typed Buffer for more information.	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. Refer to Using a VIEW Typed Buffer for more information.	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 determines the character encoding being used; if the encoding differs from the native character sets (US-ASCII or EBCDIC) used in the BEA Tuxedo configuration files (UBBCONFIG(5) and DMCONFIG(5)), the element and attribute names are converted to US-ASCII or EBCDIC. Refer to Using an XML Typed Bufferfor more information.	No	No	Yes	No
X_OCTET	Equivalent to CARRAY.	No	No	No	No

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 BEA Tuxedo administrative servers, and application clients and servers.