What Are 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 \| Getting Started \| Topic List \| Previous \| Next \| Contents

Introducing the BEA Tuxedo System

All ATMI functions send or receive data using typed buffers. The BEA Tuxedo system handles translations and data conversions between dissimilar machines. By using buffers, BEA Tuxedo programs avoid the need to translate data that crosses different platforms with different data representations.

A buffer is a memory area that serves as a logical container for data. When a buffer contains no metadata (that is, no information about itself), then it is an untyped buffer. When a buffer includes metadata such as information that can be stored in it (for example, a type and subtype, or string names that characterize a buffer), then it is a typed buffer.

Typed buffers can be transmitted over any network, on any operating system, with any protocol supported by the BEA Tuxedo system. They can also be used on platforms with different data representations. As a result, the use of typed buffers facilitates the tasks of translation and data conversion between dissimilar machines.

The BEA Tuxedo system supports five sorts of typed buffers:

You assign buffer types in the ENVFILE parameter defined in the MACHINES section of the configuration file. Assigning or overriding them in the ENVFILE parameter in the SERVERS section of the configuration file can make them unavailable to processes that require them.

Definitions of the various types of message buffers are provided in the description of tm_typesw in tuxtypes(5) in BEA Tuxedo File Formats and Data Descriptions Reference. It is to your advantage to change tm_typesw so it contains only buffer types specifically needed by a given server.

Characteristics of Buffer Types

When you use ATMI communication functions, your application must first use tpalloc to get a buffer from the system, specifying its size, type, and optionally subtype. The BEA Tuxedo system recognizes and processes the buffer type, so that your data is transmitted over any type of network, protocol, and operating system supported by the BEA Tuxedo system. The following table describes the different types of buffers available in a BEA Tuxedo environment.

Buffer Types Characteristics

This Typed Buffer
Is Defined As Follows
And Is Used for

CARRAY

Character array type is a collection of characters that is handled opaquely:

Characters are not interpreted in any way.
No subtypes are specified.
Your application must specify the buffer length for CARRAY message buffers used as input to ATMI functions.

Data that will not be interpreted by the BEA Tuxedo system and for which data-dependent routing, encoding, or decoding is not required.

FML

Field Manipulation Language (FML) is a data structure that stores tagged values. Values are typed, may be specified more than once, and vary in length.

The FML buffer is an abstract data type used in operations to create, modify, delete, or access fields. In your program, you access or update a field in the fielded buffer by referencing the identifier, and the FML function provides for a run-time translation of the field's location and data type, and performs the operation.

One interface to FML uses 16 bits (FML16) for field identifiers and lengths of fields; the other uses 32 bits (FML32).

The 16-bit version allows for up to approximately 8000 unique fields, character strings, and arrays of up to 64,000 bytes, and similar lengths for the entire buffer.
The 32-bit interface allows for millions of unique fields and buffer lengths of up to two billion bytes.
The functionality of the two interfaces is identical. The power of FML is in its flexibility. The size of the buffer can vary, depending on the needs of the application for each message. Character fields may also vary in length, so wasted space is avoided.

Fielded buffers offer data independence to the application. When writing an application, you do not need to know how or where the data is stored within a fielded buffer. FML provides associative field access, so you simply specify a field by name and its value is returned. FML also contains conversion functions, so that you can store or retrieve a field in a particular data format, regardless of the underlying storage type.

FML buffers also support storage of more than one value for a field. The variable length format of fielded buffers allows for multiple field occurrences to be stored and retrieved.

Fielded buffers provide a convenient way to transfer a collection of fields, perhaps different with each message, from a client to a server and back, or to store fields in an application queue. We recommend using FML, particularly if the interface between clients and servers may change.

Communications
Creating, modifying, deleting, or accessing fields during operations

STRING

A set of non-null characters ending with a null character. The data type is character and the length is determined by counting characters in the buffer until reaching the null character. No subtype is specified.

C programs

VIEW

A VIEW is simply a C structure or a COBOL record that has an associated definition of which fields and their types appear in the record in which order. This buffer is used for fixed collections of data elements, or structures or records; its subtype is used to specify the record format name.

VIEW records are flat data structures. They do not support structures within other structures, nor do they allow arrays of structures or pointers. They support integral data types such as long integer, character, and decimal.

VIEWS are provided as a way to use C structures and COBOL records with the BEA Tuxedo system. The BEA Tuxedo run-time system understands the record format based on the view description read at run time. When allocating a VIEW, your application specifies a buffer type of VIEW and a subtype that matches the name of the view. The run-time system can do the following:

Determine how much space is needed, based on structure size, so the application need not specify buffer length
Compute how much data to send in a request or response, and handle encoding and decoding when a message is transferred between different machine types

C structures and COBOL records used with a BEA Tuxedo application

XML (Extensible Markup Language)

XML buffers enable BEA Tuxedo applications to use XML for exchanging data within and between applications. BEA Tuxedo applications can send and receive simple XML buffers, and route those buffers to the appropriate servers. All logic for dealing with the XML documents, including parsing, resides in the application. An XML document consists of: a sequence of characters that encode the text of a document and a logical structure of the document and meta-information related to the structure.

The XML parser in the BEA Tuxedo system performs autodetection of character encodings, character code conversion, detection of element content and attribute values, and data type conversion.

Data-dependent routing is supported for XML buffers.

XML documents and datagrams
Data interchange between humans and machines, such as from a Web server to a user's browser
Data exchange between applications, or from machine to machine

This Typed Buffer	Is Defined As Follows	And Is Used for
CARRAY	Character array type is a collection of characters that is handled opaquely: Characters are not interpreted in any way. No subtypes are specified. Your application must specify the buffer length for CARRAY message buffers used as input to ATMI functions.	Data that will not be interpreted by the BEA Tuxedo system and for which data-dependent routing, encoding, or decoding is not required.
FML	Field Manipulation Language (FML) is a data structure that stores tagged values. Values are typed, may be specified more than once, and vary in length. The FML buffer is an abstract data type used in operations to create, modify, delete, or access fields. In your program, you access or update a field in the fielded buffer by referencing the identifier, and the FML function provides for a run-time translation of the field's location and data type, and performs the operation. One interface to FML uses 16 bits (FML16) for field identifiers and lengths of fields; the other uses 32 bits (FML32). The 16-bit version allows for up to approximately 8000 unique fields, character strings, and arrays of up to 64,000 bytes, and similar lengths for the entire buffer. The 32-bit interface allows for millions of unique fields and buffer lengths of up to two billion bytes. The functionality of the two interfaces is identical. The power of FML is in its flexibility. The size of the buffer can vary, depending on the needs of the application for each message. Character fields may also vary in length, so wasted space is avoided. Fielded buffers offer data independence to the application. When writing an application, you do not need to know how or where the data is stored within a fielded buffer. FML provides associative field access, so you simply specify a field by name and its value is returned. FML also contains conversion functions, so that you can store or retrieve a field in a particular data format, regardless of the underlying storage type. FML buffers also support storage of more than one value for a field. The variable length format of fielded buffers allows for multiple field occurrences to be stored and retrieved. Fielded buffers provide a convenient way to transfer a collection of fields, perhaps different with each message, from a client to a server and back, or to store fields in an application queue. We recommend using FML, particularly if the interface between clients and servers may change.	Communications Creating, modifying, deleting, or accessing fields during operations
STRING	A set of non-null characters ending with a null character. The data type is character and the length is determined by counting characters in the buffer until reaching the null character. No subtype is specified.	C programs
VIEW	A VIEW is simply a C structure or a COBOL record that has an associated definition of which fields and their types appear in the record in which order. This buffer is used for fixed collections of data elements, or structures or records; its subtype is used to specify the record format name. VIEW records are flat data structures. They do not support structures within other structures, nor do they allow arrays of structures or pointers. They support integral data types such as long integer, character, and decimal. VIEWS are provided as a way to use C structures and COBOL records with the BEA Tuxedo system. The BEA Tuxedo run-time system understands the record format based on the view description read at run time. When allocating a VIEW, your application specifies a buffer type of VIEW and a subtype that matches the name of the view. The run-time system can do the following: Determine how much space is needed, based on structure size, so the application need not specify buffer length Compute how much data to send in a request or response, and handle encoding and decoding when a message is transferred between different machine types	C structures and COBOL records used with a BEA Tuxedo application
XML (Extensible Markup Language)	XML buffers enable BEA Tuxedo applications to use XML for exchanging data within and between applications. BEA Tuxedo applications can send and receive simple XML buffers, and route those buffers to the appropriate servers. All logic for dealing with the XML documents, including parsing, resides in the application. An XML document consists of: a sequence of characters that encode the text of a document and a logical structure of the document and meta-information related to the structure. The XML parser in the BEA Tuxedo system performs autodetection of character encodings, character code conversion, detection of element content and attribute values, and data type conversion. Data-dependent routing is supported for XML buffers.	XML documents and datagrams Data interchange between humans and machines, such as from a Web server to a user's browser Data exchange between applications, or from machine to machine