view release on metacpan or  search on metacpan

ORBit/mapping.pod  view on Meta::CPAN

For instance, when implementing the following IDL:

  module Foo {
     interface A { long method1(); };
     interface B : A { long method2(); }
  }

with the following Perl code;

  package MyA;

  @MyA::ISA = qw(POA_Foo::A);
 
  sub method1 {
      return 1;
  }  

  package MyB;

  @MyA::ISA = qw(POA_Foo::B MyA);
 
  sub method2 {
     return 2;
  } 

  sub new {
     my $self = bless {};
  }

C<POA_Foo:B> must come first in C<MyB>'s C<@ISA>. 
(The rational for this is that the ORB will use a hidden
method in order to identifiy the class that a servant
implements.)

A servant is simply an Perl object blessed in a package
implemented as above.

=head2 Implementing operations and attributes

Operations and attributes are implemented exactly as expected 
from the client-side mapping. That is, the operation is called
with the same parameters as a client would use to 
invoke the operation.

=head2 PortableServer routines

In general, the POA routines map from their description in the .idl
file as specified above. One major exception to this rule is the
policy objects and the create_POA routine. There are no policy
objects, instead, the create_POA routine is variadic, with the
additional arguments being key-value pairs specifying Policy values.

For example:

  $root_poa->create_POA ("MyPOA", undef,
			 id_assignment => 'MULTIPLE_ID',
		         lifetime => 'PERSISTENT');

=head2 Mapping for ServantManager

The opaque Cookie type maps to an arbitary Perl value.

=back

=head1 AUTHOR

Owen Taylor <otaylor@redhat.com>

=cut