Calling a method or accessing a property on a wrapper object instance calls into the underlying IDL object’s method or property. Each wrapper object is associated with an IDL process, controlled by the IDL main process, by giving it a process name during wrapper creation by the Export Bridge Assistant. All wrapper objects that use the same process name have their underlying IDL objects created within the same IDL process. For each wrapper object that provides a unique process name, a new IDL process is created.
As a COM or Java developer, you do not need to worry about IDL process creation or destruction. Creating a new object creates a new process for it (unless a process already exists and the new object is being added to it), and destroying the last object in a process also destroys the process.
The code for the IDL object must be available because the bridge’s process layers call it. The wrapper does not contain the IDL object, only provides an interface for it, and if you modify the IDL object after generation of its wrapper object, the wrapper might not work as expected. For more information, see Modifying a Source Object After Export.
See Configuring Build and Client Machines for information on setting up machines for building and using wrapper objects.
Note: Stock wrapper methods allow you to work with IDL processes. For COM, see GetProcessName and SetProcessName. For Java, see getProcessName and setProcessName. To take effect, you must set a process name before creating an object in order for the object to exist in that process.
Consider the following diagram:
In the diagram, the client has created instances of several different wrapper objects: A, B, C, D, and E. Wrapper objects A and B have their process name set to X, and thus all instances of A and B create their underlying IDL objects in the same IDL process called X. Wrapper object C uses a different process, Y. Since there are three instances of the same wrapper object C, there are three instances of the IDL object C created in the process, Y. Wrapper objects E and D use an entirely different process, Z.
IDL Ownership and Blocking
During a method call, the client-side wrapper object instance becomes the owner of the IDL process that contains the underlying IDL object and remains the owner until the method call returns. An IDL process can only have one owner at a time. If there is a current owner of an IDL process and another wrapper object attempts to access the same IDL process, an IDL busy indication is returned through the wrapper object.
COM and Java handle error conditions differently: COM method calls return an HRESULT error value, whereas Java method calls throw an exception. In COM, this results in an IDL_BUSY condition; however, in Java, the requests are queued so that no busy condition occurs. See Error Handling (COM) and Error Handling (Java) for more information.
However, if one wrapper object instance owns a particular IDL process, another client process is free to make calls on other wrapper object instances that map to different IDL processes. In other words, the client can have multiple method calls executing at the same time as long as each method call maps to a different process.
For example, using the diagram above, if Instance #1 of wrapper object A is the current owner of the IDL process named X, and then another thread calls a method on Instance #1 of wrapper object B, it will return an IDL busy error, since it will try to use the same process as the wrapper object A. However, another thread can call a method on any instances of wrapper objects C, D, and E since they map to a different processes that are not currently owned.
IDL Licensing Modes
By default, when a client COM or Java application initializes the IDL object, the IDL export bridge checks to see what type of license is available on the client machine. If an IDL development license is available, it is used and the IDL object runs in full development mode. If a development license is not found, the export bridge checks for a runtime license; if the IDL object runs in runtime mode, normal runtime limitations (no compilation of .pro code, for example) are enforced. If no development or runtime license is found, the initialization of the IDL object will fail.
COM and Java applications can explicitly set IDL process initialization parameters to specify which licensing mode the IDL object will use. See the description of the initializer argument to the createObject method for details on initializing IDL objects from a Java application. See the description of the flags argument to the application.