The connector can process requests in the following two ways:
- The connector acts as a client that sends business object requests to a
CORBA server, as illustrated in Figure 1. These requests invoke methods on objects running on
an external CORBA server.
- The connector acts as a server that receives requests from external CORBA
clients, as illustrated in Figure 3. These requests invoke collaborations on the
integration broker, which, for example, can update data in an external
application.
This section describes the architecture of the CORBA connector when it runs
as a client. For details about the CORBA connector running as a server,
see Architecture of the connector running as a server.
Figure 1 illustrates the request flow when the connector runs as a
client. In this scenario, the connector invokes a method on an object
that resides on an external CORBA server. The connector acts as a
client communicating with the CORBA server through the ORB. The
connector communicates with the CORBA server by sending object requests to the
server where the CORBA objects reside.
Figure 1. Request process when the connector acts as a client

- The connector receives a business object request from the integration
broker.
- The connector creates a proxy object instance of the business
object. The proxy object instance acts as a representation of the CORBA
object to which the connector is sending the request. For details about
how the connector creates and processes the proxy object, see How the connector works as a client.
- The connector processes the proxy object by using it to access the
corresponding CORBA object running on CORBA server and write data to the
application (object). The connector can also invoke methods on the
CORBA object.
- The connector updates the proxy object by reading, or getting, data from
CORBA server object.
- The connector returns a message to the integration broker indicating that
the original object request was either successful or unsuccessful (a FAIL
status). If the request was successful, the connector also returns the
updated business object to the broker.
This section describes in detail how the different parts of the connector
process a business object when the connector runs as a client, as illustrated
in Figure 2.
Figure 2. The connector for CORBA running as a client

- When you first start up the connector and run it
as a client, the connector's Agent class performs the following
initialization processes:
- Instantiates the CORBA environment by initializing the ORB.
- Does one of the following, depending on how the connector properties have
been set. For details about the connector properties and how they
affect each of the following scenarios, see Connector-specific properties.
- Scenario 1: Creates a factory object instance, which is
an object that refers to an application. The factory object, which is
persistent for the life of the connector, creates connections that are placed
in the connection pool. The number of connections created depends on
the value specified in the connector PoolSize property.
- Scenario 2: Creates connection objects only that are
placed in the connection pool. The number of connections depends on the
value specified in the PoolSize property. No factory object
is created in this scenario.
- Scenario 3: Creates a factory proxy object against which
the business object will call methods (the factory class matches the proxy
class ASI of the BO). In this scenario, no connections are
created.
- The integration broker sends a request, in the form of a business object,
to the connector.
- The connector's BO handler receives the object.
- The doVerbFor() method of the BO handler calls the
Dispatch() method, which reads the BO ASI to obtain the proxy class
name. The Dispatch() method gets the proxy class name and
sends it to the CORBA Proxy Instantiator.
- The CORBA Proxy Instantiator uses the proxy class name to load the proxy
class (qualified using valid Java class notation, ie.
xxxxx.myclass) and create a proxy object instance, loading
it in the per-call object pool. The CORBA Proxy Instantiator verifies
if the object is one of the following:
- Is it a connection? If so, retrieve it as a connection object from the
connection pool.
- Is it a factory object? If so, retrieve it as a static object from the
factory. The CORBA Proxy Instantiator also checks whether or not a
factory method is specified in the business object ASI. If so, then it
uses the factory method on the factory object.
- Dispatch reads through the BO's verb ASI and builds a list of
methods. The verb ASI is an ordered list of attribute names.
Each attribute represents a method on the proxy object. In other words,
the verb ASI is not a list of methods, but a list of attributes, each one
having a value that represents a proxy object method.
- For each method on the verb ASI list, the InvokeMethods()
method of the BO handler calls InvokeMethod() to do one of the
following:
- Call Invoker, if the method is a regular method. If the argument is
marked as a foreign key, store it in the per-call object pool. If the
attribute is not populated, check the attribute ASI for
use_attribute_value. If the use_attribute_value
ASI is present, attempt to pull the object from the per-call object
pool.
- Call the Load and Store operations of Synchronizer (the BO handler's
object synchronization process) against all attributes on the proxy
object. The operation called depends on what is in the verb ASI.
LoadFromProxy (Load) and WriteToProxy (Store) are pre-defined functions that
you can include in the verb ASI. Their purpose is to synchronize a
business object's simple attributes with a CORBA object's public
properties.
- Call Load (LoadFromProxy function) or Store (WriteToProxy function)
operations against a single, specific attribute (LoadFromProxy gets the proxy
property and sets the BO property to that value; WriteToProxy sets the
proxy property with values from the BO).
- Note:
- If the verb ASI is empty, the BO handler will search for a method on the BO
with populated parameters and call that. Only one method can have
populated parameters. Otherwise, if multiple methods are populated and
the verb ASI is empty, then the connector logs an error and returns a FAIL
code.
- For each method of the proxy object, Invoker constructs the parameters and
arguments of the method by doing the following:
- If it encounters a BO type (rather than a simple data type, such as a
String) in the attribute, Invoker recursively calls the Dispatch()
method on the active BO handler.
- Dispatch() returns a proxy object that the parent method can
use to invoke its method call.
- The BO handler's synchronization process, called Synchronizer, invokes
WriteToProxy to store (set) a value in each property of the CORBA object
(proxy object), thus updating data on the CORBA server. The value
stored is from the corresponding attribute on the business object that the
CORBA object corresponds to.
- When values are returned from the CORBA server, the LoadFromProxy function
loads the data returned from the proxy object onto the BO. (For return
parameters, the connector creates the return proxy object and also updates the
in / out parameters).
- The connector returns the business object back to the integration
broker.
