| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| <!-- package.html - describes classes in org.omg.PortableServer package |
| Copyright (C) 2005 Free Software Foundation, Inc. |
| |
| This file is part of GNU Classpath. |
| |
| GNU Classpath is free software; you can redistribute it and/or modify |
| it under the terms of the GNU General Public License as published by |
| the Free Software Foundation; either version 2, or (at your option) |
| any later version. |
| |
| GNU Classpath is distributed in the hope that it will be useful, but |
| WITHOUT ANY WARRANTY; without even the implied warranty of |
| MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| General Public License for more details. |
| |
| You should have received a copy of the GNU General Public License |
| along with GNU Classpath; see the file COPYING. If not, write to the |
| Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
| 02110-1301 USA. |
| |
| Linking this library statically or dynamically with other modules is |
| making a combined work based on this library. Thus, the terms and |
| conditions of the GNU General Public License cover the whole |
| combination. |
| |
| As a special exception, the copyright holders of this library give you |
| permission to link this library with independent modules to produce an |
| executable, regardless of the license terms of these independent |
| modules, and to copy and distribute the resulting executable under |
| terms of your choice, provided that you also meet, for each linked |
| independent module, the terms and conditions of the license of that |
| module. An independent module is a module which is not derived from |
| or based on this library. If you modify this library, you may extend |
| this exception to your version of the library, but you are not |
| obligated to do so. If you do not wish to do so, delete this |
| exception statement from your version. --> |
| |
| <html> |
| <head><title>GNU Classpath - The Portable Object Adapter package</title></head> |
| <body> |
| <p> |
| The Portable Object Adapter (POA) provides more control on the request |
| processing than it is possible when connecting objects directly to the |
| ORB. The POA model defines a tree structure of POAs, the root POA being |
| connected directly to the ORB. Any branch of this tree can be temporary or |
| permanently inactivated using {@link org.omg.PortableServer.POAManager}. |
| The same manager can control several branches in the POA tree. Also, |
| any branch in this tree can have different processing options (policies). |
| </p><p> |
| The newly created POA is in holding state, just queuing requests. To start |
| processing requests, it must be turned into the active state by its |
| {@link org.omg.PortableServer.POAManagerOperations#activate}. |
| </p><p> |
| The previously monolite object implementation is now divided into object |
| (that implements {@link org.omg.CORBA.Object}) |
| and servant (that implements either {@link org.omg.CORBA.portable.InvokeHandler} |
| or {@link org.omg.PortableServer.DynamicImplementation}). |
| Frequently each object has its own servant, but it can also be a single servant |
| per multiple objects and also default servant for POA |
| (see {@link org.omg.PortableServer.POAOperations#set_servant}). Each object |
| has its own Object Id, unique in the scope of the POA, where the object is |
| connected. These Ids need not be different for objects belonging |
| to different POAs, even if these POAs are connected to the same ORB. |
| Under the USER_ID is assignment policy this Id can be a specified by user in |
| {@link org.omg.PortableServer.POAOperations#activate_object_with_id}, |
| encapsulating some meaningful information about the object. The Id of the |
| object being currently served can be identified with |
| {@link org.omg.PortableServer.Servant#_object_id}. This approach is used in cases |
| when it is possible to encapsulate all object-related data into the |
| Object Id. Such system only needs one servant, one server socket and one |
| socket port per POA that can handle thounsands of objects. |
| </p><p> |
| Instead of being connected directly to the ORB, objects are now connected |
| to one of the ORBs POAs. Since JDK 1.4 the application specific implementation |
| base is derived from the {@link org.omg.PortableServer.Servant}, having a |
| different name pattern (<code>*POA.java</code> instead of the previous |
| <code>_*ImplBase.java</code>). This <code>*POA</code> suffix does <i>not</i> |
| mean that these servants implement or are derived from POA. They are different |
| classes that can be connected to one of the POAs, by instance, using |
| {@link org.omg.PortableServer.POAOperations#servant_to_reference}. |
| The implementation base also inherits an *Operations interface, containing |
| definitions of the application specific methods. The application programmer |
| writes a descendent of the implementation base, implementing these methods |
| for the application - specific functionality. |
| </p><p> |
| The POA objects support the method invocation by name, using |
| {@link org.omg.CORBA.Request}. This alternative method works without the |
| service-specific classes that may not be available at run time. |
| </p><p> |
| The objects in POA can also be activated and inactivated independently. It |
| is possible to set a listener ({@link org.omg.PortableServer.ServantActivator}) |
| that would register the object activations ("incarnations") and deactivations |
| ("etherializations"). The servant need not be specifyed when creating an |
| object. Under the IMPLICIT_ACTIVATION |
| {@link org.omg.PortableServer.ImplicitActivationPolicy} |
| the {@link org.omg.PortableServer.ServantActivator} can provide the servant |
| in response to the first (local or remote) call of any method on the |
| previously incative object. |
| </p><p> |
| The root POA is obtained by resolving the initial reference "RootPOA" |
| for the orb. In the simpliest case the objects can be connected directly |
| to that root POA without creating the POA tree. The policies, used by |
| the root POA, are defined by OMG as following: |
| <table border="1"> |
| <tr><th>Policy type</th><th>Accepted policy</th></tr> |
| <tr><td>{@link org.omg.PortableServer.IdAssignmentPolicy} </td><td>SYSTEM_ID |
| (Ids are created by POA)</td></tr> |
| <tr><td>{@link org.omg.PortableServer.IdUniquenessPolicy}</td><td>UNIQUE_ID |
| (single object (and Id) per servant) |
| </td></tr> |
| <tr><td>{@link org.omg.PortableServer.ImplicitActivationPolicy} </td><td> |
| IMPLICIT_ACTIVATION (if inactive, activate)</td></tr> |
| <tr><td>{@link org.omg.PortableServer.LifespanPolicy} </td><td>TRANSIENT |
| (the POA objects cannot outlive POA)</td></tr> |
| <tr><td>{@link org.omg.PortableServer.RequestProcessingPolicy} </td><td> |
| USE_ACTIVE_OBJECT_MAP_ONLY (the servant is provided during activation)</td></tr> |
| <tr><td>{@link org.omg.PortableServer.ServantRetentionPolicy} </td><td> |
| RETAIN (retain servants for subsequent invocations)</td></tr> |
| <tr><td>{@link org.omg.PortableServer.ThreadPolicy} </td><td>ORB_CTRL_MODEL |
| (single thread per request and single server socket per object)</td></tr> |
| </table> |
| These values are also default for the child POAs The policies are |
| <i>never</i> inherited from the parent POA. |
| </p><p> |
| This set of policies means that each object will have a separate serving |
| thread, separate network socket port and usually a separate servant. It |
| is appropriate when the expected number of objects is not too large. |
| If the expected number of objects is larger than the supportable number |
| of threads and socket ports, the SINGLE_THREAD_MODEL |
| {@link org.omg.PortableServer.ThreadPolicy} is |
| used. Then all objects in POA with this policy are served in a single |
| thread, using the same server socket, connected to a single port. If the |
| request processing policy is additionally set to USE_DEFAULT_SERVANT, |
| all objects of this POA share the same (default) servant. |
| </p><p> |
| The operations, supported by POA are defined |
| separately in {@link org.omg.PortableServer.POAOperations}. |
| </p><p> |
| <h3>The typical POA usage scenarios</h3> |
| <h4>POA converts servant to the object reference</h4> |
| In the simpliest case, the servant implementation is connected to POA by |
| {@link org.omg.PortableServer.POAOperations#servant_to_reference}, the |
| returned object being a target of remote and local invocations. |
| It may be converted into the stringified reference, registered with |
| the naming service, used locally or, when serving or invoking local or remote |
| method, passed as a parameter or return value having the CORBA Object type. |
| The object obtains Id from POA and is activated due default implicit |
| activation policy. This scenario is supported by the default policy set |
| and is used in the most of the "hello world" examples. |
| <h4>Servant provides to the object reference</h4> |
| The servant can be connected to an ORB by |
| {@link org.omg.PortableServer.Servant#_this_object(org.omg.CORBA.ORB)}, |
| obtaining the object reference. The overridable |
| {@link org.omg.PortableServer.Servant#_default_POA()} |
| specifies POA to that the servant will be connected. The default method |
| connects to the root poa. IDL compilers frequently generate the |
| <code>_this(ORB)</code> metod for servants for getting the object reference |
| that is already narrowed to the exact object type. |
| <h4>Explicit activation with POA assigned ids</h4> |
| The objects are activated by calling the |
| {@link org.omg.PortableServer.POAOperations#activate_object} on the |
| POA with the object in question. The POA allocates, assigns, and |
| returns a unique identity value for the object. This scenario requires the |
| SYSTEM_ID {@link org.omg.PortableServer.IdAssignmentPolicy}. |
| <h4>Explicit Activation with User-assigned Ids</h4> |
| The POA supports an explicit activation operation, |
| {@link org.omg.PortableServer.POAOperations#activate_object_with_id}, |
| that associates a servant with the user-defined Object Id. |
| This scenario requires the USER_ID |
| {@link org.omg.PortableServer.IdAssignmentPolicy}. The servant manager |
| may be or may not be used. |
| <h4>References before activation</h4> |
| It may be useful to create references for objects before activating them. |
| Such reference can be created using |
| {@link org.omg.PortableServer.POAOperations#create_reference} or |
| {@link org.omg.PortableServer.POAOperations#create_reference_with_id}, both |
| methods also requiring to give the object repository id. Such object may |
| be later activated either by |
| {@link org.omg.PortableServer.POAOperations#activate_object_with_id} or |
| automatically, if the IMPLICIT_ACTIVATION policy applies. |
| <h4>Multiple Ids per servant</h4> |
| If the MULTIPLE_ID policy applies, the servant may be activated many times. |
| Under this policy, |
| {@link org.omg.PortableServer.POAOperations#servant_to_reference} |
| and {@link org.omg.PortableServer.POAOperations#servant_to_id} |
| during each call create a new object and object reference for the |
| used servant. |
| <h4>One servant for all objects</h4> |
| If the USE_DEFAULT_SERVANT policy applies, that default servant serves all |
| objects, belonging this POA. This approach is used when there is |
| very little data associated with each object, so little that the data can be |
| encoded in the Object Id. Also, it may be needed when a very large |
| number of objects is expected. If the RETAIN applies, it is possible to |
| activate an object explicitly setting the servant other than default. |
| If NO_RETAIN applies, the default servant will serve all known an |
| unknown objects for that POA. |
| <h4>Single Servant, Many Objects and Types</h4> |
| Combining USER_ID, USE_DEFAULT_SERVANT and RETAIN, it is possible to |
| create and serve objects "on the fly". The servant must determine the |
| object type (for instance, from the value of the agreed attribute, |
| shared by all supported types, or from the Object Id) and be able to |
| handle the method, named in request. If the names and parameter lists |
| of the object methods are also created "on the fly", the requests |
| to such object can still be submitted using {@link org.omg.CORBA.Request}. |
| This method is used when the created object represents some |
| entity in the complex database. |
| <h4>The ServantLocator finds a servant for each call</h4> |
| The {@link org.omg.PortableServer.ServantLocator} is used by POAs that |
| combinine NON_RETAIN and USE_SERVANT_MANAGER policies. It provides |
| a new or reused servant every time the invocation is made. The servant |
| locator must provide a servant in response of calling |
| {@link org.omg.PortableServer.ServantLocatorOperations#preinvoke}. |
| This method has access the the Id of the object being served and |
| the name of the method being called. It must return the appropriate |
| instance of the servant or throw an exception, forwarding the request |
| to another object (usually in another server). After the invocation, |
| a {@link org.omg.PortableServer.ServantLocatorOperations#postinvoke} |
| is called. It should be not assumed that the call of <code>preinvoke</code> |
| will be followed by the call of the <code>postinvoke</code>; in |
| multithreaded environment these calls are not serialized in this way. If |
| the <code>preinvoke</code> has to tell something this-call-specific to |
| the <code>postinvoke</code>, it must use the provided cookie holder. |
| The <code>preinvoke/postinoke</code> are also called to provide a servant |
| during each local invocation on the objects, belonging to the described POA. |
| </p><p> |
| All these scenarios must work with the current GNU Classpath release. |
| |
| @author Audrius Meskauskas, Lithuania (AudriusA@Bioinformatics.org) |
| </body> |
| </html> |
