| Home >> All >> org >> omg >> [ PortableServer Javadoc ] |
• org.omg.PortableServer: Javadoc index of package org.omg.PortableServer.
Package Samples:
• org.omg.PortableServer.CurrentPackage: The Portable Object Adapter (POA) provides more control on the request processing than it is possible when connecting objects directly to the ORB.
• org.omg.PortableServer.POAManagerPackage
• org.omg.PortableServer.POAPackage
• org.omg.PortableServer.ServantLocatorPackage
• org.omg.PortableServer.portable
Classes:
• Servant: The servant is responsible for handling the method invocation on the target object. It can be one servant per object, or the same servant can support several (possibly all) objects, associated with the given POA. Till JDK 1.3 inclusive, a typical IDL to java compiler generates an implementation base (name pattern _*ImplBase.java) that is derived from the org.omg.CORBA.portable.ObjectImpl . Since JDK 1.4 the implementation base is derived from the Servant, also having a different name pattern (*POA.java). This suffix may be confusing, as the servant itself is not POA nor it is derived from it. In ...
• RequestProcessingPolicyValue: Specifies the behaviour in the case when the requested object is not found in the Active Object Map or that map is not in use. The map is not in use when the ServantRetentionPolicyValue.NON_RETAIN 55 policy is active. USE_ACTIVE_OBJECT_MAP_ONLY Raise an org.omg.CORBA.OBJECT_NOT_EXIST with the minor code 2. ServantRetentionPolicyValue.RETAIN 55 policy is also required. USE_DEFAULT_SERVANT Dispatch request to the default servant. If no such exists, raise org.omg.CORBA.OBJ_ADAPTER with minor code 3. IdUniquenessPolicyValue.MULTIPLE_ID 55 is also required. USE_SERVANT_MANAGER Dispatch request to the ...
• ThreadPolicyValue: Defines the possible values for the POA thread policy. This enumeration can obtain the following values: ORB_CTRL_MODEL Each object in POA has a separate serving thread and a separate server socket, listening on the objects individual port. Additionally, when the request is accepted, it is also served in a separate thread, so several requests to the same object can be processed in parallel. The servant can always get the Id and POA of the object it is currently serving by invoking Servant._object_id() 55 and Servant._poa() 55 . These two methods use thread to data map and must work correctly even ...
• Current: Provides the Id of the object currently being served and POA to that this object is connected. Both Id and POA can be simpler obtained from the servant by Servant._object_id() 55 and Servant._poa() 55 that use POA Current indirectly. The operations on Current for obtaining these data are defined in CurrentOperations . As long as the ORB reference is still available, the current information is available via Current that is returned by ORB.resolve_initial_references("POACurrent"). To support this call, the ORB maintains the thread to invocation data map for all calls that are currently being processed ...
• CookieHolder: The CookieHolder is used together with the org.omg.PortableServer.ServantLocator , allowing the ServantLocatorOperations.preinvoke(byte[], org.omg.PortableServer.POA, java.lang.String, org.omg.PortableServer.ServantLocatorPackage.CookieHolder) > ServantLocatorOperations.preinvoke(byte[], org.omg.PortableServer.POA, java.lang.String, org.omg.PortableServer.ServantLocatorPackage.CookieHolder) 55 to return an arbitrary java.lang.Object that will be later passed to ServantLocatorOperations.postinvoke(byte[], org.omg.PortableServer.POA, java.lang.String, java.lang.Object, org.omg.PortableServer.Servant) ...
• ServantActivatorPOA: This ServantActivator stub is an optional base for the servant activators. This stub cannot serve remote invocations, as methods in ServantActivatorOperations take POA as one of parameters. Both JDK 1.5 API and OMG specifies that POA is a local object that must not be transferred to the remote invocation target. You do not need to derive your servant activator from this stub, it is enough to implement the ServantActivator interface. But you may choose to do this if you need the functional _all_interfaces(POA, byte[]) 55 method or want to keep default behavior during the incarnation or etherialization ...
• ServantLocatorPOA: The ServantLocator stub is an optional base for the servant locators. It cannot serve remote invocations, as methods in ServantLocatorOperations take POA as one of parameters. Both JDK 1.5 API and OMG specifies that POA is a local object that must not be transferred to the remote invocation target. You do not need to derive your servant locator from this stub, it is enough to implement the ServantLocator interface. But you may choose to do this if you need its functional gnuServantObject._ids() > gnuServantObject._ids() 55 method or want to keep default behaviour during pre- or post- invokcations ...
• _ServantActivatorStub: This ServantActivator stub is an optional base for the servant activators. This stub cannot accept remote invocations, as methods in ServantActivatorOperations take POA as one of parameters. Both JDK 1.5 API and OMG specifies that POA is a local object that must not be transferred to the remote invocation target. You do not need to derive your servant activator from this stub, it is enough to implement the ServantActivator interface. But you may choose to do this if you need the functional _ids() 55 method or want to keep default behavior during the incarnation or etherialization.
• _ServantLocatorStub: The ServantLocator stub is an optional base for the servant locators. This stub cannot accept remote invocations, as methods in ServantLocatorOperations take POA as one of parameters. Both JDK 1.5 API and OMG specifies that POA is a local object that must not be transferred to the remote invocation target. You do not need to derive your servant locator from this stub, it is enough to implement the ServantLocator interface. But you may choose to do this if you need its functional _ids() 55 method or want to keep default behavior during per- or post- invokcations.
• POA: The Portable Object Adapter (POA) provides more control on the request processing than it is possible when connecting objects directly to the ORB. For details, see the general description of the org.omg.PortableServer package. The operations, supported by POA are defined separately in POAOperations . In the simpliest case, the servant implementation is connected to POA by POAOperations.servant_to_reference(org.omg.PortableServer.Servant) 55 , the returned object being a target of remote and local invocations, despite the numerous other strategies are possible.
• CurrentOperations: Provides the Id of the object currently being served and POA to that this object is connected. Both Id and POA can be much simpler obtained from the servant by Servant._object_id() 55 and Servant._poa() 55 that use the CurrentOperations indirectly. As long as the ORB reference is still available, the current information is available via Current that is returned by ORB.resolve_initial_references("POACurrent"). To support this call, the ORB maintains the thread to invocation data map for all calls that are currently being processed.
• State: Defines the possible states of the POA manager. This enumeration can obtain the following values: ACTIVE When the manager is in the active state, the associated POAs receive and process requests. DISCARDING When the manager is in the discarding state, the associated POAs discard all incoming requests. The sending clients receive the org.omg.TRANSIENT system exception, with standard minor code 1. This mode is needed for flow control, when the system is flooded with requests. HOLDING When the manager is in the holding state, the associated POAs queue incoming requests. INACTIVE This state is entered ...
• ForwardRequest: This exception is raised by ServantManager to indicate that the invocation target has moved to another known location. In this case, the client will receive a redirection (LOCATION_FORWARD) message and should resend the request to the new target. The exception contains the object reference, indicating the new location. The exception can be thrown both by servant locators and servant activators. If the exception is raised anywhere else than in the ServantManager methods, it is handled as an ordinary user excepton.
• ImplicitActivationPolicyValue: Specifies the implicit activation policy. This enumeration can obtain the following values: IMPLICIT_ACTIVATION The POA supports implicit activation of servants. ( IdAssignmentPolicyValue.SYSTEM_ID 55 and ServantRetentionPolicyValue.RETAIN 55 policies required). NO_IMPLICIT_ACTIVATION The POA does not support implicit activation.
• AdapterActivator: Adapter activators are associated with POAs and supply the the ability to create child POAs on demand. The new POA can be created As a side-effect of receiving a request that names the child POA (or one of its children). When calling POAOperations .find_POA(name, true) if the parameter name refers a non existing POA. An AdapterActivator is always a local object.
• POAManager: A POA manager is associated with one or more POAs and provides means to regulate they activity. Using manage, it is possible to force requests for those POAs to be queued or discarded or have those POAs deactivated. The manager can turn POAs to and from holding, active and discarding states, but the incative state is irreversible. The manager of the ORBs root POA can be obtained by resolving initial reference "RootPOAManager".
• ServantManager: A servant manager is associated with POA and provide possibility to activate objects on demand. A servant manager interface itself is empty, but it is inherited by other two interfaces, ServantActivator and ServantLocator .
• ServantManagerOperations: This interface would define the operations, applicable to the ServantManager. A servant manager interface itself is empty, but it is inherited by other two interfaces, ServantActivator and ServantLocator .
• POAManagerOperations: Defines the operations, applicable to the POAManager . These operations can turn the associated POAs to and from holding, active and discarding states, but the incative state is irreversible. The inactivated POAs can only be recreated after they were destroyed.
• IdAssignmentPolicyValue: Specifies the Object Id assignment policy. USER_ID Objects created with that POA obtain they Object Ids from the application. SYSTEM_ID Objects created with that POA obtain they Object Ids from POA. If the POA also has the PERSISTENT policy, these Object Ids must be unique across all instantiations of the same POA.
• RequestProcessingPolicy: Specifies the behaviour in the case when the requested object is not found in the Active Object Map or that map is not in use. The policy can return its current value, as defined. in RequestProcessingPolicyOperations .
• LifespanPolicyValue: Specifies the object life span policy. This enumeration can obtain the following values: TRANSIENT The objects implemented in the POA never outlive the POA instance in which they are first created. PERSISTENT The mentioned objects can outlive the process in which they are first created.
• ServantLocator: When the POA has the NON_RETAIN policy it uses servant managers that are ServantLoacators. The operations, that must be supported by these managers, are defined separately in ServantLocatorOperations .
• ServantActivator: The POA, that has the RETAIN policy uses servant managers that are ServantActivators. The operations, that must be supported by these managers, are defined separately in ServantActivatorOperations .
• Delegate: Each org.omg.PortableServer.Servant has an associated delegate, where the most of the calls are forwarded. The delegate is responsible for providing the actual functionality. This class is required to supports a conceptions of the CORBA 2.3.1 Servant.
| Home | Contact Us | Privacy Policy | Terms of Service |