Articles Forum Examples Download Open Source
Copyright(c) 2006, 2007 by Pocomatic Software LLC. All rights reserved.
Portable Object Adapter (POA) is the portable programming model for CORBA server applications. A POA instance encapsulates and scopes server policy settings of all its objects. These policies determine service qualities, properties and behaviors. The PocoCapsule/CORBA supports POA server application deployment with all OMG standardized POA policies. Non-OMG policies introduced by ORB vendors can also be added easily. Among a handful of OMG standardized POA policies, the most important policy is the request-processing policy. This policy determines the scenario that a POA server resolves target object servants on processing received requests.
The CORBA server application in this example covers all possible POA request-processing policy settings by the following four POAs:
POA 1: The request-processing policy is "use-aom-only", and an object is activated with its servant. This policy means that servants of activated objects in this POA are registered to POA's "Active-Object-Map" (AOM). On processing requests, servants are resolved from this map.
POA 2: The request-processing policy is "use-default-servant", and a servant is set as the default one for the POA. This policy means that on processing a request, if the POA can't resolve the servant from AOM, the request will be sent to the default servant.
POA 3: The request-processing policy is "use-servant-manager", the servant-retention policy is "non-retain", and a servant locator is set on this POA. This setting indicates that servants are resolved for each individual request from an user servant pool by calling the given servant locator.
POA 4: The request-processing policy is "use-servant-manager", the servant-retention policy is "retain", and a servant activator is set on this POA. This setting indicates that request processing servants are resolved on demand by calling the servant activator, and then, the servants are cached by AOM for later use.
Object references from this server are exported as corbaloc URLs, with URIs declared in the deployment descriptor.
The core CORBA server application deployment model of PocoCapsule/CORBA is almost explicitly mapped from the OMG POA programming model. This does not imply PocoCapsule/CORBA could not be comparable or more abstract than CCM. In fact, with PocoCapsule/C++'s DSM feature, users can easily define customized CORBA server application deployment models that abstract out the POA concept largely, if this abstraction is desirable. An example of this user defined CORBA server deployment model can be found in the ${POCOCAPSULE_DIR}/examples/corba/dsm-server directory.
Greeting.idl: The IDL definition of the server's remote interface.
This interface only declares one operation, string hello(in string s). A client can invoke this operation to send a greeting message to server, and receive a reply greeting from server, as the return value.
Client stub and server skeleton classes source code from this IDL can be generated using a given ORB's IDL-to-C++ pre-compiler, for instance, the idl2cpp of VisiBroker/C++.
server.C: A simple container, used to deploy the server application.
client.C: A client application.
The client application assume the server IOR or URL is provided as the first main() argument. The string IOR or URL is converted into an CORBA object reference using ORB's string_to_object(),
and then, this reference is narrowed to the type specific client stub class, namely, the sample::Greeting_ptr.
GreetingImpl.h and GreetingImpl.C: These files implement following plain old C++ CORBA artifacts:
A servant implementation, namely, a POCO class inheriting from and implementing the POA_sample::Greeting. The instances of this servant class are used as the servant to activate object for POA1, the default servant for POA 2, the servants in the servants pool for POA 3 and the servant activated on demand and cached by POA 4.
A servant locator implementation. This servant locator is used by POA 3 to resolve servants from the servants pool on each individual request.
A servant activator implementation. This activator is used by a POA 4 to instantiate servant on demand. Servants instantiated by this activator will be cached in the AOM of this POA.
setup.xml: This is the server's deployment descriptor. It describes following server structure:
A bean of class GreetingImpl is allocated, and used as the servant for activating a server object on a POA with request-processing policy equals to “use-aom-only”. The URI of this object is “my-server-use-aom-only”.
Another bean of class GreetingImpl is allocated, and used as the default servant for a POA with request-processing policy equals to “use-default-servant”. An object reference is created on this POA, and the URI of this object is “my-server-use-default-servant”.
Another POA with request-processing policy equals to “use-servant-manager” and servant-retention policy equals to “non-retain” is created. A bean of the class ServantLocatorImpl class is allocated and passed to this POA as the servant manager. An object reference is created from this POA, with URI of “my-server-use-servant-locator”.
One more POA is created, with request-processing policy equals to “use-servant-manager” and servant-retention policy equals to “retain”. A bean of the class ServantActivatorImpl class is allocated and passed to this POA as the servant manager. An object reference is created from this POA, with URI of “my-server-use-servant-activator”.
The ORB node is declared with an user specified id, “my-orb”. This will let POCO to generate a lazy-init'ed ORB runnner bean, with the id of “pocomatic.dispatcher:my-orb”. Initiating this runner bean (such as by calling getBean(“pocomatic.dispatcher:my-orb”) on the bean deployed application context), will start the server's request dispatching loop, after printing out all declared object URLs.
To build this example, the environment variable POCOCAPSULE_DIR should point to the PocoCapsule/C++ installed directory. Also, this example assumes an underneath ORB (e.g. VisiBroker/C++, TAO, etc.) is installed and its runtime and development environment (such as POCOCAPSULE_DIR, VBROKER_DIR or TAO_ROOT, etc. env variable) are set according to its product specification. Then, this example can be built by simply invoking gmake/make on linux/unix or nmake on windows.
· Before starting the server, make sure the LD_LIBRARY_PATH (on linux and solaris) or the PATH (on windows) environment variable is set correctly to include the ${POCOCAPSULE_DIR}/lib directory and the ${VBROKREDIR}/lib (if VisiBroker is used) or the ${TAO_ROOT}/lib directory (if TAO is used).
· Start the server as:
prompt> server
By default setting, on successful startup, server will print out all declared corbaloc URLs (namely, <object> elements, with specified uri attribute). In this server, object elements are declared with their uri attribute equal to “my-server-use-...”, the print out will be, for instance:
Server is ready, with URLs: corbaloc::192.168.2.3:2809/my-server-use-aom-only corbaloc::192.168.2.3:2809/my-server-use-default-servant corbaloc::192.168.2.3:2809/my-server-use-servant-locator corbaloc::192.168.2.3:2809/my-server-use-servant-activator
Here, the URI values “my-server-use-...” are declared in the beans descriptor setup.xml file.
· Start client: The server's corbaloc URLs should be used as the first command line argument when starting the client. For instance:
prompt> client corbaloc::192.168.2.3:2809/my-server-use-aom-only .... prompt> client corbaloc::192.168.2.3:2809/my-server-use-default-servant .... prompt> client corbaloc::192.168.2.3:2809/my-server-use-servant-locator .... prompt> client corbaloc::192.168.2.3:2809/my-server-use-servant-activator ....
On success, the client sends multiple greeting messages to the server, and the server replies one to client on receiving each of them. Both sides will print out the greeting messages they received.