To illustrate the architecture of the connector, this section
describes request processing at a high-level, as illustrated in
Figure 1, and then the details of
how the connector works, as illustrated in Figure 2.
Figure
1. Request processing in the connector for COM

- 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
COM 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.
- The connector processes the proxy object by using it to invoke
the corresponding COM object running on COM server and write data
to the COM application.
- The connector updates the proxy object by reading, or getting,
data from COM server object.
- The adapter 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 how the different parts of the connector
process a business object, as illustrated in Figure 2.
Figure
2. The connector for COM

- When you
first start up the connector, the connector's Agent class performs
the following initialization processes:
- Instantiates the OLE environment.
- 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 connection
factory object instance, which is an object that refers to an
application. The factory object is persistent for the life of the
connector and 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 Loader.
- The
Loader uses the proxy class name to load the proxy class (qualified
using valid Java class notation, ie. Mypackage.myclass)
and create a proxy object instance, loading it in the per-call
object pool. The Loader checks to see 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 connection factory.
- Dispatch then 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 (LoadFromProxy function) and Store (WriteToProxy
function) 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 to a COM
component's public properties.
- Call Load or Store 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
COM component (proxy object), thus updating data on the COM server.
The value stored is from the corresponding attribute on the
business object that the COM component corresponds to.
- When values are returned from the COM server, the LoadFromProxy
function calls the "getters" of the proxy object and loads the data
returned from the proxy object onto the BO.
- The connector returns the business object to the integration
broker.
