CORBA Object-by-Value

1
CORBA Object-by-Value

• An overview of the value type and its IDL-to-C
  mapping.

2
What is Object-by-Value?

• Object-by-Value (OBV) is the CORBA mechanism for
  enabling objects to have pass-by-value semantics
  in CORBA operations.
• Conventional CORBA objects always have
  pass-by-reference semantics.
• The IDL keyword valuetype declares an object that
  will be passed by value.
• Valuetype instances are guaranteed to be local to
  the context in which they are used.

3
Object-by-Value Semantics

• OBV implies semantics similar to pass-by-value in
  standard programming languages
• The receiving entity of a valuetype parameter (or
  returned object) instantiates a new object with
  identical state to the parameter.
• The new instance has a separate identity and no
  relationship to the callers parameter.
• OBV requires that the receiving entity have
  access to an implementation of the valuetype.
• George, please briefly mention how this affects
  C vs. Java.

4
When to Use Valuetypes

• Valuetypes are often useful in the following
  situations
• An application needs a copy of an object.
• An objects primary purpose is encapsulation of
  data, rather than operation implementations.
• An application needs the performance
  predictability of local method invocations.
• An application needs to transfer an arbitrarily
  complex or recursive tree, lattice, or other
  graph data structure.

5
Capabilities of Valuetypes

• An IDL valuetype can
• Have operations, attributes, and factories.
• Be recursively defined.
• Be declared abstract.
• Be shared across or within other instances.
• Inherit from a single concrete valuetype.
• Inherit from multiple abstract valuetypes.
• Support a single concrete interface.
• Support multiple abstract interfaces.
• Be declared truncatable.
• Be a boxed value.

6
Valuetype C Mapping

• An IDL valuetype maps to
• An abstract base class with the same name.
• Inherits from CORBAValueBase.
• Pure virtual methods corresponding to value type
  operations.
• Pure virtual accessor and modifier methods
  corresponding to state members.
• A class with OBV_ prepended to the fully-scoped
  name.
• Inherits from the abstract base class.
• Is abstract if value type has operations
  concrete otherwise.
• Provides default implementations of accessors and
  modifiers.
• A factory class with _init appended to the
  name.
• A _var type for life cycle management.

7
Valuetype Factories (1/2)

• For each concrete valuetype, a factory class is
  generated _init is appended to the valuetype
  name.
• Valuetype factory classes inherit from
  CORBAValueFactoryBase which declares a pure
  virtual create_for_unmashal () method.
• The create_for_unmashal () method is used by the
  ORB to create an instance of a valuetype received
  as a parameter or return type.
• Valuetype factories must be registered with the
  ORB via ORBregister_value_factory ().

8
Valuetype Factories (2/2)

• Each factory method declared in IDL maps to pure
  virtual method that returns an instance of the
  valuetype.
• The factory class is concrete for valueboxes and
  valuetypes that have no IDL factories or
  operations an implementation of
  create_for_unmashal () is generated.
• If the factory class is not concrete, the
  programmer must provide implementations of the
  create_for_unmashal () method and any factories
  declared in IDL.

9
Abstract Valuetypes

• An IDL valuetype can be declared abstract.
• Abstract valuetypes
• Have only operations no state or factories.
• Have no generated OBV_ classes.
• Are not subject to single inheritance
  restrictions.
• Are inherited as public virtual base classes.
• Cannot be instantiated cannot be parameters or
  the return type of an IDL operation.
• Essentially just a bundle of operation
  signatures.

10
Supporting a Concrete Interface

• A valuetype is declared to support a concrete
  interface with the IDL keyword supports.
• A valuetype that supports a concrete interface is
  NOT a subtype of the interface and is NOT
  substitutable.
• The interfaces operations are mapped to pure
  virtual methods in the valuetype ABC.
• A skeleton (POA_) class is generated for the
  valuetype that inherits from the interface
  skeleton.
• The valuetype can be registered with a POA and
  manipulated via an object reference of the
  interface type pass-by-reference semantics apply.

11
Supporting an Abstract Interface

• Valuetypes can support multiple abstract
  interfaces.
• Abstract interfaces inherit from
  CORBAAbstractBase, not CORBAObject.
• Abstract interfaces have unique parameter passing
  semantics to their operations.
• A valuetype that supports an abstract interface
  IS a subtype of the interface and IS
  substitutable.
• Allows determination of pass-by-value vs.
  pass-by-reference semantics to be made at
  run-time.

12
Reference Counting

• CORBAValueBase declares pure virtual _add_ref
  () and _remove_ref () methods.
• Programmer must fulfill the ValueBase reference
  counting interface with custom implementations or
  mix-in classes.
• CORBADefaultValueRefCountBase can serve as a
  base class for valuetypes that will never be
  registered with a POA.
• PortableServerValueRefCountBase must serve as a
  base class for valuetypes that will be registered
  with a POA.

13
Valueboxes

• A valuetype with only a single state member is a
  valuebox.
• Declared as valuetype ltidentifiergt lttypegt
• Ex valuetype StringValue string
• Any IDL type except a valuetype can be boxed.
• Valueboxes may not be a subtype or base type.
• Valueboxes for string and wstring are included in
  the CORBA module as StringValue and WStringValue.

14
Custom Marshalling

• A programmer can provide custom code to marshal
  and unmarshal valuetype instances.
• A valuetype that is declared custom in IDL
  implicitly inherits from the abstract valuetype
  CustomMarshal.
• The concrete valuetype must provide
  implementations of the marshal () and unmarshal
  () operations.
• Intended to facilitate the integration of legacy
  code.