Code Examples. More...
Code Examples.
The recommended way to use RMD is to generate the code throught IDE (refer IDE User Guide). The code thus generate works irrespective of the architecture as the arguments are marshalled at sender side and unmarshalled on receiver side using the XDR library.
If there is a need to use RMD Library directly we have below various examples to illustrate the usage of RMD. There are various possibilities with the many flags and options available with RMD. We cover the recommended way to use RMD in the examples.
The communication parties have a client-server relationship. The server exposes certain services in conjunction with the Exectuion Object (EO) infrastructure. The client tries to execute these services either locally or remotely.
The two modes - syncrhonous and asynchronous calls can be made with or without reply from the client. The four combinations explained are:
Server Side:
For the client to make a RMD call the server should expose the services as illustrated below:
A typical service provided by an EO (RMD server here) will look as below:
Many such services as above can be installed into the native table of EO (RMD server) as illustrated below. The serviceTable needs to be populated with all the services that need to be exposed and then installed via the call - clEoClientInstall() during the initialize as described further below:
The native table (or any other client table) is installed as illustrated below. These calls usually reside in the clCompAppInitialize() callback registered in the clEoConfig structure of the EO.
The uninstall of the native table is done as illustrated below. Such calls reside in the clCompAppTerminate() registered with the Component Manager (CPM).
Client Side:
One of the simpler ways to invoke an RMD is to make a synchronous call with the default flags but we strongly recommend using CL_RMD_CALL_NON_PERSISTENT flag to avoid any unnecessary duplication of buffers (which is the default) unless the inMsgHandle needs to be re-used. Care should be taken in releasing the resources allocated like the outMsgHandle which is not applicable in this case.
If the application is interested in the response from the server then it has to create a buffer - outMsgHandle to hold the data the server wants to send back. This buffer needs to be deleted soon after the call when it is no longer being used.
When the application just wants to notify the server with some information without waiting for a reply then the following mode can be used.
The application may want to be notified about the success of an asynchronous rmd call with the response data from the server. In this a callback such as the one below is required when invoking the call:
To make the asyncrhonous call the application needs to specify the callback as illustrated below in the form of asyncRmdOptions. It can also supply some argument which will be supplied in the callback (cookie). In this case care has to be taken to release the outMsgHandle in the callback instead of after the RMD call unless there is an error condition. The return code in the above callback lets the application know if the RMD call was successful.
The above code only depicts the typical flags used. If you want to ensure that the invoked call is executed no more than once at the server you need to set the CL_RMD_CALL_ATMOST_ONCE flag. This flag is only necessary only for the calls that have a side effect if invoked more than once and are not idempotent in nature. The buffer is held at the server so this flag needs to be used judiciously.
The CL_RMD_CALL_NON_PERSISTENT is recommended as in most cases the application deletes the inMsgHandle as soon the call is invoked. Only if the application intends to re-use the inMsgHandle should it avoid this flag. In such a case the application is required to delete the inMsgHandle as indicated in the comments in the examples above.