CORBARequest node

Use the CORBARequest node to call an external CORBA application over Internet Inter-Orb Protocol (IIOP).

The CORBARequest node is available in the following operation modes:
  • Developer
  • Application Integration Suite
  • Standard
  • Advanced
  • Adapter
For more information, see Operation modes.
This topic contains the following sections:

Purpose

You can use the CORBARequest to connect IBM® Integration Bus to CORBA applications. CORBA is a standard for distributing objects across networks so that operations on those objects can be called remotely. CORBA objects are described in Interface Definition Language (IDL) files. You can create a message flow that contains a CORBARequest node, which calls a CORBA server. The message flow uses the IDL file to configure which operation is called on which interface. By using a message flow that includes a CORBARequest node, you can give existing CORBA applications a new external interface; for example, a SOAP interface. The IDL file is stored in a message set project inside a folder called CORBA IDLs, and is used to configure the CORBARequest node in the message flow.

Using this node in a message flow

One possible use of a CORBARequest node is to connect a SOAP-based web service application to an existing CORBA IIOP application by using a synchronous style of message flow. You can achieve this connection by creating the following message flow:
The diagram shows how you can use a CORBARequest node to connect to a SOAP-based web service.
In this example, the SOAPInput node receives a web service request, the Mapping node transforms the data in the SOAP message to a CORBA request, and a request is made to the CORBA server. The second Mapping node transforms the response message back into a SOAP reply, which is propagated by the SOAPReply node.

The CORBARequest node is not transactional. After the node has made a request, it cannot roll back the request. The CORBA nodes use the DataObject domain.

The CORBARequest node is contained in the CORBA drawer of the message flow node palette, and is represented in the IBM Integration Toolkit by the following icon:
SOAPRequest node icon

When you have put an instance of the CORBARequest node into a message flow, you can configure it; see Configuring a message flow node. The properties of the node are displayed in the Properties view.

All mandatory properties for which you must enter a value (properties that do not have a default value defined) are marked with an asterisk.

Terminals and properties

The CORBARequest node terminals are described in the following table.
Terminal Description
In The input terminal that accepts a message for processing by the node. Data is taken from the message tree and sent to the CORBA server.
Out The output terminal from which return parameters are propagated.
Failure The output terminal to which a message is routed if a failure is detected.
Error CORBA exception messages that are received in response to the sent request are sent to the Error terminal. If the Error terminal is not connected, and an error is received, no further processing occurs in the message flow. The error is logged as a warning in user trace.

The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value when no default is defined; the column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).

The CORBARequest node Description properties are described in the following table.
Property M C Default Description
Node name No No The node name The name of the node.
Short description No No None A brief description of the node.
Long description No No None Text that describes the purpose of the node in the message flow.
The CORBARequest node Basic properties are described in the following table.
Property M C Default Description mqsiapplybaroverride command property
Naming service Yes Yes   The location of the naming service that contains the object that you are calling. For this property, you can specify either the host name of the naming service or a CORBA configurable service.
  • Specify the host name of the naming service from which to get the object reference in the format host:port, where port is optional. For example, localhost:2809. If you do not specify a port number, the default value is 2809. You can obtain this value from the administrator of the CORBA application that you are calling.
  • Specify the name of a configurable service of type CORBA. If you specify a configurable service name, you can use the configurable service to override the Naming service and Object reference name properties.

    For more information about using a configurable service to specify a naming service, see Defining where the CORBARequest node gets the object reference.

namingService
Object reference name Yes Yes   The name of the reference to the object in the naming service. You can obtain this value from the CORBA server that you are calling.

For more information about how to specify the object reference name, see CORBA naming service.

You can also use a configurable service to specify an object reference name. For more information, see Defining where the CORBARequest node gets the object reference.

referenceName
IDL file Yes No   The IDL file in a message set project that is used to configure the CORBARequest node. Click Browse to select an IDL file in a referenced message set. If you have dragged an imported IDL file onto the canvas or onto the CORBARequest node, the IDL file property is set to the name of the IDL file.

When you specify an IDL file, the Interface name property is populated with a list of available interfaces.

 
Interface name Yes No   The interface from the IDL file that the node calls. Either type a valid interface name, or click Select interface and select an interface from the list. If the list contains a large number of interfaces, you can filter the results.

The values that are listed for this property are the interfaces in the selected IDL file that have one or more operations. This list is populated only when an IDL file is specified. If you have dragged an imported IDL file onto the canvas or onto the CORBARequest node, the Interface name property is set according to the IDL file.

If the interface name is contained in a module in the IDL file, the interface name is qualified with the name of the module. If the module is nested in another module, the interface name is qualified with all module names, starting from the root module; for example:

ModuleNameA.ModuleNameB.InterfaceName

When you specify an interface name, the Operation name property is populated with a list of available operations.

 
Operation name Yes No   The operation to call from the interface.

The values that are listed for this property are the supported operations that are available in the selected interface. This list is populated only when an interface name is specified. If you have dragged an imported IDL file onto the canvas or onto the CORBARequest node, the Operation name property is set according to the IDL file.

You can override this property in the local environment by specifying a value in the following location:
$LocalEnvironment/Destination/CORBA/Request/OperationName
 
The CORBARequest node Response Message Parsing properties are described in the following table.
Property M C Default Description
Message domain No No DataObject The domain that is used to parse the response message. By default, the message that is propagated from the CORBARequest node is in the DataObject domain. You cannot specify a different domain.
Message model No No Set automatically The name of the message set in which the incoming message is defined. The node detects the message set automatically.
Message No No   The name of the response message. The node detects the message type automatically. You cannot set this property.
Physical format No No   The name of the physical format of the response message. You cannot set this property.
The CORBARequest node Request properties specify how to make a request, and are described in the following table.
Property M C Default Description
Data location Yes No $Body The location in the incoming message tree from which data is retrieved to form the request that is sent by the CORBARequest node.
The CORBARequest node Result properties specify where to store the reply, and are described in the following table.
Property M C Default Description
Output data location No No $OutputRoot The message tree location to which the CORBARequest node sends output.

See Combining a result message with an input message when fetching data from external systems.

Copy local environment No No Selected This property controls how the local environment is copied to the output message. If you select this check box, a new copy of the local environment is created in the tree (at each node in the message flow), and it is populated with the contents of the local environment from the preceding node. Therefore, if a node changes the local environment, the previous nodes in the flow do not see those changes because they have their own copies. This behavior might be an issue if you are using a FlowOrder node, or if you use the propagate command on a Compute node.

If you clear the check box, each node does not generate its own copy of the local environment, but it uses the local environment that is passed to it by the previous node. Therefore, if a node changes the local environment, those changes are seen by the upstream nodes.

The Monitoring properties of the node are described in the following table.
Property M C Default Description
Events No No None Events that you have defined for the node are displayed on this tab. By default, no monitoring events are defined on any node in a message flow. Use Add, Edit, and Delete to create, change or delete monitoring events for the node; see Configuring monitoring event sources by using monitoring properties for details.

You can enable and disable events that are shown here by selecting or clearing the Enabled check box.