Chapter 14 Creating CORBA C++ Components

Running C++ components externally

EAServer's C++ component model allows you incorporate legacy C and C++ business logic code into a component. However, if legacy code is unstable, it can cause the server to crash.

Beginning in version 4.0, you can configure C++ components to execute within a dedicated external process. EAServer spawns a subprocess to execute the component, and issues component invocations using interprocess communication.

Limitations

Because external components execute in a different process than the host server, they cannot use the following features:

Sharing, Concurrency, or Bind Thread properties The Sharing, Concurrency, and Bind Thread component properties have no effect when components execute externally, because each component instance runs in a separate process. You can get a form of instance reuse by enabling the Pooling property. With Pooling enabled, the server reuses component processes for multiple invocations.
Transactions or connection caches Server managed transactions and connection caching are not supported in components that execute externally.
C and C++ API routines None of the Jag* C routines or server-side C++ classes documented in the EAServer API Reference are available to components that execute externally. These routines and classes can only be called by code that executes within the host server process.
Input, output, and logging You cannot read from standard input in C++ components (whether they execute in-process or in an external process). C++ components that execute externally cannot call the JagLog C routine, but any text written to standard output is recorded in the server log file.
Stateful components Components that execute externally must be stateless, and no control interface methods are called on the component implementation class. The Auto Demarcation/Deactivation property must be enabled for components that execute externally.

Configuring a component to run externally

To run your C++ component externally, configure the following component properties:

General / C++ Executable Specifies the name of the executable that the server launches as a subprocess. Specify a plain filename, with no path information or platform extensions such as .exe for Windows. The executable must exist in the EAServer cpplib subdirectory. When you generate a component skeleton, Jaguar Manager generates a makefile to build the executable.
Resources / Maximum Wait Specifies the maximum time, in seconds, that the server waits for method execution to complete. A value of 0 indicates infinity, which is the default. If the method does not complete in time, the server returns a CORBA::NO_RESOURCE_EXCEPTION to the caller.
Resources / Maximum Active Instances Specifies the maximum number of external component processes that run simultaneously. A value of 0 indicates no limit, which is the default. There is one process per component instance, and one component instance per client session. When the limit has been reached, client requests for new instances block until an existing instance is destroyed. The maximum blocking time is limited by the Maximum Wait setting.

Building and deploying the external component executable

Before you can build an external component executable, you must generate a skeleton. The skeleton for an external component is different than for a component that runs in-process, so regenerate skeletons if you have changed the component properties to run externally. "Generating required C++ files" describes how to generate the C++ code.

The executable indicated by the component properties General / C++ Executable must be deployed in the EAServer cpplib directory, as well as the library specified by the DLL Name field. The generated Makefile builds the library and executable and copies both to the cpplib directory when you run the "all" make target.