Chapter 34: Creating and Using EAServer Pseudocomponents
For the most part, pseudocomponents can be created and implemented like any EAServer CORBA/Java or C++ component. However, since they are not executed by the component dispatcher, there are additional restrictions on their implementation and use. This section explains the implementation restrictions and required property settings for pseudocomponents. For additional information on creating components, see “Defining components”.
Pseudocomponents must be implemented in C++ or Java. If using Java, the component type must be Java/CORBA; you cannot instantiate an Enterprise JavaBean as a pseudocomponent.
Since pseudocomponents execute outside of the EAServer dispatcher, their execution is not governed by component properties defined in EAServer Manager. Thus, components that run as pseudocomponents are subject to these restrictions:
They cannot participate in server-managed transactions.
Lifecycle interface methods, such as those in CtsComponents::ObjectControl, are not called and instances are never pooled or reused. Each time a client program instantiates a proxy instance of a pseudocomponent, a new instance of the implementation class is constructed.
They are not affected by component threading properties. A pseudocomponent’s methods run in the same process of the calling program, on the same thread from which they are called.
Pseudocomponents executed in standalone programs cannot use server-side classes and methods such as connection management, client credential access, and so forth. These classes and methods are available only to components executed by the EAServer component dispatcher. A pseudocomponent that is executed by a server-dispatched component can use server-side features, but does so in the context of the server-dispatched component that instantiated the pseudocomponent.
They are not affected by access control restraints. Any client with local access to a component’s implementation library or class can instantiate the component as a pseudocomponent.
A pseudocomponent must be defined in EAServer Manager in order to generate stubs and skeletons. Stubs and skeletons are required to execute the pseudocomponent. You can use any of the techniques described in “Defining components” to define the component in EAServer Manager. You must configure the properties described in this section.
For a Java pseudocomponent, set the following properties and leave other properties at their default settings. Properties other than these have no affect on the behavior of the pseudocomponent:
Component Type – choose Java - CORBA.
Java Class – enter the dot-notation Java
class name, for example
The Component Properties dialog box appears. Set the following fields for a C++ pseudocomponent, leaving other fields at their default settings. Properties other than these have no affect on the behavior of the pseudocomponent:
Component Type – choose C++.
DLL Name – enter the base name for the
shared library or DLL that will contain the component implementation.
For example, the setting
the Windows file mypseudo.dll on Windows.
C++ Class – leave at
the default setting (the name of the component, appended with “Impl”,
You can generate special stubs and skeletons that improve the performance of pseudocomponent method calls issued from Java or C++. In a process called marshalling, regular CORBA stubs convert parameter and return values to the format required for IIOP network transport. Direct-access pseudocomponent stubs and skeletons improve performance by eliminating the marshalling step.
To generate direct-access pseudocomponent stubs and skeletons in EAServer Manager, select the normal EAServer Manager settings for Java/CORBA or C++ Stubs, except in the Advanced Options wizard page, select the option Generate Pseudo Component Access in C++ and Java Stubs and Skeletons.
|Copyright © 2005. Sybase Inc. All rights reserved.|