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.
