CORBA operation parameters

CORBA operations can have parameters that can be modified by the server.

CORBA operations can have in, out, and inout parameters. In and inout parameters dictate the appearance of the tree under the DataObject domain when going into a CORBARequest node. The return type, inout and out parameters dictate the appearance of the tree when leaving a CORBARequest node.

The inbound message is contained in the element interfaceName.operationName and needs an element for every in or inout parameter. If the interface is contained in a module, the name is qualified with the name of the module. If the module is nested in other modules, all module names are stated; for example: moduleNameA.moduleNameB.interfaceName.operationName. Out parameters are not required because the client does not send a value for out parameters. These elements must be in the same order as the parameters in the IDL file.

The output message from the CORBARequest node is contained in the element interfaceName.operationNameResponse. If the interface is contained in a module, the name is qualified with the module name. The outbound message has an element for the return type, named _return, and an element for every inout and out parameter.

Here is an example of an IDL file:

interface exampleInterface {
	string outsideModuleOperation(in string one, out string two, inout string three);
	
};

The input message might look like the following example:

<exampleInterface.outsideModuleOperation>
	<one>something</one>
	<three>something</three>
</exampleInterface.outsideModuleOperation>

The output message might look like the following example:

<exampleInterface.outsideModuleOperationResponse>
	<_return>something</_return>
	<two>something</two>
	<three>something</three>
</exampleInterface.outsideModuleOperationResponse>

The input message requires all in and inout parameters, therefore one and three are specified. The output has the following elements:

A _return element (because the operation has a return type of string)
An element called two (because two is an out parameter)
An element called three (because three is an inout parameter)

User-defined exceptions

Exceptions are propagated to the Error terminal under the DataObject domain; the structure of the message depends on the exception.

The following example shows how a user-defined exception is defined in an IDL file.

exception BadRecord {
    string why;    
  };


  interface SomeInterface {
    long bar(in float pi) raises (BadRecord);
  };

The operation bar can issue the exception BadRecord. If this exception is issued, the following message is propagated to the Error terminal.

<BadRecord>
	<why>Reason text</why>
</BadRecord>

Edge cases

Two identified edge cases exist for reading a tree and producing a tree:

No input parameters exist.
A void function has no inout or out parameters

The following sample IDL file illustrates two examples.

interface exampleInterface {
	string exampleOne();
void exampleTwo(in string one);	
};

Example 1 - no input parameters exist
Input message: The input message is irrelevant because the CORBARequest node does not look at the body of the message.
Output message:
```
<exampleInterface.exampleOneResponse>
	<_return>something</_return>
</exampleInterface.exampleOneResponse>
```

Example 2 - A void function has no inout or out parameters

Input message:

<exampleInterface.exampleTwo>
	<one>something</one>
</exampleInterface.exampleTwo>

Output message:

<exampleInterface.exampleTwoResponse>
</exampleInterface.exampleTwoResponse>