Architecture of the COM connector

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


  1. The connector receives a business object request from the integration broker.
  2. 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.
  3. 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.
  4. The connector updates the proxy object by reading, or getting, data from COM server object.
  5. 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.

How the connector works

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


  1. When you first start up the connector, the connector's Agent class performs the following initialization processes:
  2. The integration broker sends a request, in the form of a business object, to the connector.
  3. The connector's BO handler receives the object.
  4. 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.
  5. 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:
  6. 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.
  7. For each method on the verb ASI list, the InvokeMethods() method of the BO handler calls InvokeMethod() to do one of the following:

    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.
  8. For each method of the proxy object, Invoker constructs the parameters and arguments of the method by doing the following:
  9. 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.
  10. The connector returns the business object to the integration broker.

Copyright IBM Corp. 1997, 2004