Docstoc

corba-poa

Document Sample
corba-poa Powered By Docstoc
					Portable Object Adaptor

        Martin Senger
      senger@ebi.ac.uk
     Significant news in CORBA
•   Objects By Value
•   CORBA Components
•   CORBA scripting
•   Metadata and modeling
•   Quality of Service
•   Portable Object Adaptor
    – BOA deprecated now
        CORBA Object Adaptors
                                   remember this term,
                                      use this term

• a piece of CORBA architecture dispatching
  client requests to the servants (implementations)
• object adaptors are only on the server side
• key functions are         remember: object references and
                            servants are two different things
   – they create CORBA object references
   – they ensure that target objects are incarnated by
     servants
   – they direct requests to the servants (they connect orb
     with the servants - locating and marshaling)
              BOA and POA
• BOA was the original CORBA object adaptor
• BOA was under-specified and therefore less
  portable between ORBs
• BOA had no servant management
• BOA has been removed from CORBA!
• POA is everything else
  – portable
  – providing many more features
            POA abstract model
                                        Object Id



            ORB                        POA            servant
                  logical connection
 Object
                  to the target
Reference         CORBA object                        servant



                                       POA            servant



   Client                                    Server
              Three key Entities
[CORBA Object is a programming entity with an identity, an
  interface and an implementation]
• Servant
   – a programming language object implementing requests on
     one or more CORBA objects (modifier “native” in IDL)
• Object Id
   – a value identifying a particular CORBA object within the
     scope of its POA
   – Ids are hidden from clients, encapsulated by object
     references
• Object Reference
   – a usual reference to a CORBA object
   – encapsulates an Object Id and a POA identity
            A simplified picture
Incoming
 requests


                                      Servant
                                       Servant
                                         Servant

               POA           POA      Servant
  ORB                         POA      Servant
             Manager           POA       Servant


                                      Servant
                                       Servant
                                         Servant
                 Server Application
                           How to code Server
import org.omg.CORBA.*;                     import org.omg.CORBA.*;
                                            import org.omg.PortableServer.*;

// Initialize ORB and BOA                   // Initialize ORB and POA
ORB orb = ORB.init (args, props);           ORB orb = ORB.init (args, props);
BOA boa = orb.BOA_init(args, props);        POA rootPOA = POAHelper.narrow (
                                                           orb.resolve_initial_references ("RootPOA"));

                                            // Get a reference to the POA manager
                                            POAManager manager = rootPOA.the_POAManager();

// Create a servant and activate it         // Create a servant and activate it
HelloWorldImpl hw = new HelloWorldImpl();   HelloWorldImpl hwImpl = new HelloWorldImpl();
                                            HelloWorld hw = hwImpl._this (orb);

// Wait for requests                        // Wait for incoming requests ("run the implementation")
boa.impl_is_ready(null);                    manager.activate();
                           with BOA         orb.run();                               with POA
             The old way - with BOA
  CORBA.Object                            CORBA.<skeleton>          Server
           extends                                    extends

     HelloWorld         implements       _HelloWorldImplBase       overview
                                                      extends

                                            HelloWorldImpl           How to connect
                                                get_text()
                                                                  your implementation
                                                                      classes with
             The new way - with POA                                the generated code
   CORBA.Object
                                         PortableServer.Servant
  portable.IDLEntity
                                                                    this is an interface
                                                      extends
     HelloWorld                                                     of the same type as
                        implements         HelloWorldPOA            the object reference
     Operations

extends   extends                                     extends
                         _this() or

     HelloWorld
                     activate_object()      HelloWorldImpl          this is a servant
                                                get_text()
 Object Reference                            Yet another picture
 (with Object Key)
   request
from a client

        ORB                           POA               Default Servant
 extract POA name     find       extract Object Id                         incarnate
 from Object Key      POA        from Object Key       Active Object Map    servant
                                                            Object ID                Servant
        or                            or
                                                            Object ID
                                      or                                             Servant
                                                            Object ID


call Adaptor        create POA                              update
Activator if                                                                create
                                                             map
POA not found                                                              servant


                                                Servant       Servant
 Adaptor Activator                              Activator     Locator
                                                Servant Manager
             POA Policies
• there can be more POAs and each of them
  can have different features = policies
• the policies are given to the POA in its
  creation time, they are not changeable later
• the policies are not inherited from parent
  POA to its children POA
• the policies are locally-constrained objects
  – they cannot be passed as arguments to normal
    CORBA operations, or be converted to strings
           enum LifespanPolicyValue { TRANSIENT, PERSISTENT };



 policy:   CORBA Object Life Span
• TRANSIENT
  – the objects created in the POA cannot outlive
    this POA
  – they are more modest regarding resources
• PERSISTENT
  – the objects can outlive the process in which
    they were first created
  – their POA name is stored in the object
    references
        enum IdUniquenessPolicyValue { UNIQUE_ID, MULTIPLE_ID };



   policy:   Object Id Uniqueness
• UNIQUE_ID
 – each servant support exactly one Object Id
• MULTIPLE_ID
 – a servant may support one or more Object Ids
 – good, for example, for many database objects
   which may all be served by a single servant
   (assuming that the state of the objects is kept in
   the database)
         enum IdAssignmentPolicyValue { USER_ID, SYSTEM_ID };



          policy:     Id Assignment
• USER_ID
  – Object IDs are assigned by the application, not
    by the POA
  – typical for persistent objects (the same ID is
    used for keeping track where the object state is
    stored)
• SYSTEM_ID
  – Object IDs are assigned by the POA
enum RequestProcessingPolicyValue {
 USE_ACTIVE_OBJECT_MAP_ONLY, USE_DEFAULT_SERVANT, USE_SERVANT_MANAGER };


          policy:   Request Processing
• USE_ACTIVE_OBJECT_MAP_ONLY
  – an Object Id must be found in the active object map
• USE_DEFAULT_SERVANT
  – if an Object Id is not found in the active object map
    the request is dispatched to the default servant
• USE_SERVANT_MANAGER
  – if an Object Id is not found in the active object map
    the servant manager gets control
             enum ServantRetentionPolicyValue { RETAIN, NON_RETAIN };


policy:   ObjectId to Servant Associations

 • RETAIN
     – the POA will keep active servants in its active
       object map
     – various combinations of this policy and Request
       Processing policy
 • NON_RETAIN
     – servants are not retained by the POA
     – it is up to the application to keep track about active
       (existing) servants
 enum ImplicitActivationPolicyValue { IMPLICIT_ACTIVATION, NON_IMPLICIT_ACTIVATION };


           policy:      Implicit Activation

• IMPLICIT_ACTIVATION
  – the POA will support implicit activation of servants
  – also requires SYSTEM_ID and RETAIN policies
  – implicit activation is done (in Java) using a shortcut
    method “_this”
• NO_IMPLICIT_ACTIVATION
  – the POA will not support implicit activation of
    servant
  – typically used to avoid accidental object creation
   enum ThreadPolicyValue { ORB_CTRL_MODEL, SINGLE_THREAD_MODEL };


                    policy:     Thread
• ORB_CTRL_MODEL
 – servants can be called in parallel from separate
   threads (created and controlled by the ORB)
 – servants must be written as thread-aware
• SINGLE_THREAD_MODEL
 – a model which guarantees that all requests for
   all objects in this POA will be dispatched
   sequentially
 – but the application still can have more single-threaded
   POAs running in parallel (in separate threads)
         How to create “policies”
• each policy has its own factory:
          interface POA {
                      LifespanPolicy create_lifespan_policy (
                                  in LifespanPolicyValue value);
          };

• an example how to use the policy factory:
          Policy policy =
                       parentPOA.create_lifespan_policy (LifespanPolicyValue.ORB_CTRL_MODEL);

• typically, all necessary policy objects are passed
  in a PolicyList to the POA creation function
• …and then invoke destroy on the policy objects
 Object Reference                            Yet another picture
 (with Object Key)                                    (now let’s show where
   request
from a client
                                                     different policies apply)
        ORB                           POA                 Default Servant
 extract POA name     find       extract Object Id                          incarnate
 from Object Key      POA        from Object Key        Active Object Map    servant
                                                             Object ID                Servant
        or                            or
                                                             Object ID
                                      or                                              Servant
                                                             Object ID


call Adaptor        create POA                                update
Activator if                                                                 create
                                                               map
POA not found                                                               servant


                                                Servant         Servant
 Adaptor Activator                              Activator       Locator
                                                Servant Manager
             POA Creation
• each POA is created as a child of another
  POA
• all server applications have a “RootPOA”
• POAs are created in a tree, in a hierarchy
• each POA has its own namespace for its
  Object Ids
• remember: if you need a different policy you
  need a new POA
                            code:        POA Creation
interface POA {
            POA create_POA (
                        in string adapter_name,
                        in POAManager manager,
                        in CORBA::PolicyList policies)
            raises (AdapterAlreadyExists, InvalidPolicy);
};

// get a reference to the Root POA
POA rootPOA = POAHelper.narrow (orb.resolve_initial_references ("RootPOA"));

// get a reference to the POA manager
POAManager manager = rootPOA.the_POAManager();

// create an empty PolicyList for child POA
Policy[] policies = new Policy [0];

// create the child POA
POA child = rootPOA.create_POA (“child”, manager, policies);
  Activation: don’t be confuse...
• “Object activation” is not the same as
  “Server activation”
  – Server activation is about “how to start a
    separate process on the server side”
     • also called: “Implementation repository” issue (see
       another talk)
  – Object activation is about “how to make objects
    visible within already running process
  Object creation and activation
• POA provides several options for creating
  objects and activating them
  – an application can create objects without
    creating any servants
  – a servant can be explicitly or implicitly
    registered to incarnate an object - and POA can
    remember it in its Active Object Map
  – an application can supply servant managers
  – an application can provide a default servant
      Creation and activation methods
                                                          Creating CORBA Objects
           Object activation
                                                          without creating servants
 ObjectId activate_object (in Servant serv)          Object create_reference (in CORBA::RepositoryId intf)
              raises (ServantAlreadyActive,                      raises (WrongPolicy);
                WrongPolicy);                        Object create_reference_with_id (in ObjectId oid,
 void activate_object_with_id (in ObjectId oid,                              in CORBA::RepositoryId intf)
                          in Servant serv)                       raises (WrongPOlicy);
              raises (ServantAlreadyActive,
                ObjectAlreadyActive, WrongPolicy);



            Registration of                                       Registration of
           Servant managers                                       Default Servant
ServantManager get_servant_manager ()                    Servant get_servant ()
            raises (WrongPolicy);                                    raises (NoServant, WrongPolicy);
void set_servant_manager (in ServantManager imgr)        void set_servant (in Servant serv)
            raises (WrongPOlicy);                                    raises (WrongPOlicy);
   Conversions among key entities
Object Reference

              ObjectId reference_to_id (in Object ref)
                           raises (WrongAdapter, WrongPolicy);
              Object id_to_reference (in ObjectId oid)
                           raises (ObjectNotActive, WrongPolicy);

                          Servant reference_to_servant (in Object ref)
                                      raises (ObjectNotActive, WrongAdapter, WrongPolicy);
   Object Id              Object servant_to_reference (in Servant serv)
                                      raises (ServantNotActive, WrongPolicy);


           ObjectId servant_to_id (in Servant serv)
                       raises (ServantNotActive, WrongPolicy);
           Servant id_to_servant (in ObjectId oid)
                       raises (ObjectNotActive, WrongPolicy);

    Servant
                          Servant managers
• Used when an explicit servant registration is
  difficult or impossible
  – e.g. dealing with too many objects
  – or finding objects dynamically
• Servant Activator
  – Servant incarnate (in ObjectId oid, in POA adapter)
  – void etherealize (in ObjectId oid, in POA adapter, …)
  – the resulting servant retains in the Active Object Map
• Servant Locator
  – Servant preinvoke (in ObjectId oid, in POA adapter, in CORBA::Identifier operation, out Cookie the_cookie)
  – void postinvoke (in ObjectId oid, in POA adapter, in CORBA::Identifier operation, out Cookie the_cookie,…)

  – the resulting servant does not appear in the AOM
 Common for both Servant managers
• The incarnate() and preinvoke() may raise any system
  exception
   – e.g. OBJECT_NOT_EXIST if the object corresponding
     to the Object Id cannot be incarnated
      • SeqFactory.get_sequence()
                                normally would raise at once exception
        WrongAccession but if the real access to the database is postponed
        some other exception must be used
• Both operations may also raise a ForwardRequest
   – then the ORB is responsible for delivering the current
     and subsequent requests to the object denoted in
     forward_reference member
                                  Default Servant
      • a single Servant for many CORBA objects
            – typically of the same type
            – ideally suited to objects in large databases
      • the invoking POA and ObjectId is
        accessible using Current interface

                  How to get Current                          What to get from Current
org.omg.CORBA obj =                                            interface Current {
            orb.resolve_initial_references (”POACurrent"));                POA get_POA();
Current current = CurrentHelper.narrow (obj);                              ObjectID get_object_id();
                                                               };
           Object deactivation
• deactivation is breaking object-to-servant
  association
• after deactivation the object is not visible
  any more
  – but the corresponding servant can still be available and
    may be activated later again
• an administrative tool for controlling the
  contents of the Active Object Map
             void deactivate_object (in ObjectId oid)
                         raises (ObjectNotActive, WrongPolicy);
           Notes on hands-on
• POA/stage1
  – plain differences between BOA and POA
• POA/stage2-persistent
  – create persistent object reference
• POA/stage3-servantActivator
  – create a factory for sequence references,
  – the servants are created later only when a
    method on a sequence reference is called
�� create a factory for sequence references,
  – the servants are created later only when a
    method on a sequence reference is called

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:19
posted:8/27/2012
language:Latin
pages:31