System Independence

· Language independence

DCE RPC is language independent in the sense that the stubs generated by the IDL compiler can be called by programs written in any traditional programming language, provided that the language follows the calling conventions that the stub expects. The DCE IDL compiler generates stubs that use the C language calling conventions. A client written in FORTRAN, for example, can call an IDL stub in the same way that it calls any local C procedure. It can then make a remote call to a server (possibly written in another language) that contains the server stub generated from the same IDL file as the client stub was generated from.

· Data representation independence

The default data representation format is the DCE Transfer Syntax, which is currently the Network Data Representation (NDR). It allows various representations for different types of data, including multiple encodings for characters, integers, and floating-point numbers. It is multicanonical; that is, there are several canonical formats that can be used. The sender chooses one of these formats (in most cases, it will be the sender's native data representation), with information about what representation it has chosen. The receiver transforms data into its own format, if it is different from the format the data was sent in. This model optimizes for the case when both sender and receiver use the same data representation, a frequent occurrence. (Note that this data transfer is handled by the RPC software, and is not visible to the application programmer.)

The DCE RPC architecture allows the use of transfer syntaxes other than DCE Transfer Syntax (although the only transfer syntax currently provided in the OSF implementation is DCE Transfer Syntax). For example, data could be formatted according to the ISO ASN.1/BER specification and sent over the wire in that way.

· Protocol independence

Independence of RPC, transport, and network protocols is achieved as follows. The DCE RPC offering includes two different RPC protocols. The first runs over connection-oriented transport protocols; the second runs over connectionless (datagram) transport protocols. The programmer can specify the underlying RPC protocol, but the semantics of RPC calls are the same whether the RPC is running over a connectionless or connection-oriented transport. Another RPC protocol could be used in place of these two DCE RPC protocols; for example, when ISO defines an RPC standard, it could be used transparently as a third RPC protocol under the DCE RPC interfaces.

Servers identify themselves to the Directory Service according to the interface they support and the protocols they use. In this way, a client can look up a server that uses network protocols that are compatible with those that the client supports.

· Machine independence

Because DCE RPC uses the DCE Transfer Syntax, distributed applications are machine independent. DCE Transfer Syntax allows machines to transfer data even when their native data representations are not the same.

· Operating system independence

Finally, DCE RPC offers independence from the local operating system. The application programmer is not directly using the networking system calls provided by the local operating system. By being one level of abstraction up from this layer, the programmer is insulated from networking system calls that are operating system specific.