This chapter deals with the use of the Interface Definition Language (IDL).
BEA TUXEDO TxRPC supports the IDL grammar and associated functionality as described in Chapter 3 ("Interface Definition Language") of DCE: REMOTE PROCEDURE CALL (Doc Code: P312 ISBN 1-872630-95-2). This book is available from the following.
X/OPEN Company Ltd (Publications) The X/OPEN document is the ultimate authority on the language and rules adhered to for the BEA TUXEDO product. Note that the X/OPEN TxRPC IDL-only interface is supported (parts of the document concerning the DCE binding and runtime do not apply). The X/OPEN document is based on the OSF DCE AES/RPC document. There are several books containing tutorials and programmer's guides that can be used, although most will not contain the latest features. The programmer's guide available from OSF is OSF DCE Application Development Guide, published by Prentice-Hall (Englewood Cliffs, New Jersey, 07632).
The X/OPEN Preliminary Specification for TxRPC Communication Application Programming Interface is also available from X/OPEN (see above). TxRPC adds transaction support for RPCs to the original X/OPEN RPC interface.
A Universal Unique Identifier (UUID) is used to uniquely identify an interface. The This template is then used to create the IDL input file for the application (adding type definitions, constants, and operations).
If both the BEA TUXEDO and DCE The BEA TUXEDO system The References
P O Box 109
Penn
High Wycombe
Bucks HP10 8NP
United Kingdom
Tel: +44 (0) 494 813844
Fax: +44 (0) 494 814989
uuidgen - Creating an IDL Template
uuidgen
command is used to generate UUIDs. The output might look something like the following.
$ uuidgen -i > simp.idl
$ cat simp.idl
[uuid(816A4780-A76B-110F-9B3F-930269220000)]
interface INTERFACE
{
}uuidgen
commands are available, the DCE command can and should be used to generate the template (the DCE version will most likely have a machine-specific approach to getting the node address, as described below).
uuidgen
command is similar to the DCE command with the exception that the -s
option (which generates a UUID string as an initialized C structure), and the -t
option (which translates an old style UUID string to the new format) are not supported. See the uuidgen
(1) reference page for details of the interface.
uuidgen
command requires a 48-bit node address as described in ISO/IEC 8802-3 (ANSI/IEEE 802.3). There is no platform-independent way to determine this value, and it may not be available at all on some machines (a workstation, for example). The following approach is used for the BEA TUXEDO system uuidgen
command:
NADDR
environment variable is set to a value of the form num.num.num.num.num.num
where num
is between 0 and 255, inclusive, it is taken to be an Internet-style address and converted to a 48-bit node address. This allows conformance with the use of the 8802-3 node address. It also allows users who do not have access to this address to use another value, most likely the Internet address (which is not the same as the 8802-3 address). If the Internet address is used, the last num.num
should be 0.0 (because Internet addresses are only 32-bit addresses).
The IDL compiler recognizes the IDL grammar and generates stub functions based on the input. The grammar and its semantics are fully described in both the X/OPEN and OSF/DCE references listed earlier in this chapter. The grammar will be recognized in its entirety with some changes as described in the following sections.
The following are changes to the base X/OPEN RPC specification that are defined by the X/OPEN TxRPC Specification:
Changes in the Language
Changes Based on the TxRPC Specification
[transaction_optional]
and [transaction_mandatory]
attributes in the interface and operation attributes in the IDL file. [transaction_optional]
indicates that if the RPC is done while in a transaction, the remote service is done as part of the transaction. The [transaction_mandatory]
attribute requires that the RPC be done within a transaction. Without these attributes, the remote service is not part of any transaction of which the client may be part.
The following are enhancements to the X/OPEN RPC specification. In most cases, the language has been enhanced to more closely follow the C language, simplifying the porting of existing interfaces (converting from ANSI C to IDL prototypes).
Enhancements to the Language
space
(0x20) through tilde
(0x7e). Other characters in the character set (0x01 through 0xff) are allowed, as in OSF DCE RPC.
This means that white space need not follow or precede identifiers or numbers if preceded or followed by one of these tokens. (The IDL specification requires white space, as in '|| && ? | & _ == != = << >> <= >= < > + - % ! ~
a = b + 3
', instead of allowing 'a=b+3
'.) This also seems to be the behavior of the OSF DCE IDL compiler.
nor does it allow for structure or union returns. While this could be considered correct (everything could be hidden in a defined type), the DCE IDL compiler and, of course, C compiler allow a much richer operation return. The supported grammar will be
where long *op(void);
[
operation_attributes
] <type_spec
> <declarator
><declarator
> must contain a <
function_declarator
>.
(If a <function_declarator
>
does not exist, then a variable is declared, which results in an error.) Declaring an array of operations or an operation returning an array (both allowed by this grammar) will be detected and flagged as an error.
<
ACS_type_declaration
>
takes <
ACS_named_type
>
values, just as the IDL <
type_declaration
>
takes a list of declarators. This seems to be the behavior of the DCE IDL compiler.
transmit_as()
] cannot have the [represent_as
] attribute.
There are four additional BEA TUXEDO enhancements to the X/OPEN RPC specification that, while making the specification more C-like, are not supported in the OSF DCE IDL compiler and thus have the effect of limiting portability of the IDL file:
Enhancements that May Limit Portability
is treated the same as
const char *str = "abc" "def";
const char *str = "abcdef";
is treated the same as
const char *str = "abc\
def";const char *str = "abcdef";
The following seven features are not supported in the Features that Are Not Supported
tidl
compiler:
[v1_struct]
, [v1_enum]
, [v1_string]
, and [v1_array]
are recognized but not supported (these appear in the OSF IDL specification but not the X/OPEN specification).
The interface for the IDL compiler is not specified in any X/OPEN specification.
For DCE application portability, the BEA TUXEDO system IDL compiler has a similar interface to the DCE IDL compiler, with the following exceptions:
tidl - The IDL Compiler
tidl
instead of idl
so an application can easily reference either when both appear in the same environment.
-space_opt
option, which optimizes the code for space, is ignored. Space is always optimized.
By default, the IDL compiler takes an input IDL file and generates the client and server stub object files. The By default, at most 50 errors are printed by See the -keep c_source
option generates only the C source files, and the -keep all
option keeps both the C source and object files. The sample RPC application (listed in Appendix A, "A Sample Application,") uses the -keep object
option to generate the object files.
tidl
. If you want to see them all (and have more than 50 errors), use the -error all
option. The error output is normally printed to the stderr
, but is printed on the standard output on DOS and OS/2 platforms (since there is no standard mechanism to redirect the standard error on these platforms).
tidl
(1) reference page for details on the many other options that are available.