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.
November 20, 2018

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 caller’s 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.]
November 20, 2018

4. When to Use Valuetypes
Valuetypes are often useful in the following situations:
An application needs a “copy” of an object.
An object’s 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.
November 20, 2018

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.
November 20, 2018

6. Valuetype C++ Mapping An IDL valuetype maps to:
An abstract base class with the same name.
Inherits from CORBA::ValueBase.
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.
November 20, 2018

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 CORBA::ValueFactoryBase 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 ORB::register_value_factory ().
November 20, 2018

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.
November 20, 2018

9. Abstract Valuetypes An IDL valuetype can be declared abstract.
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.
November 20, 2018

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 interface’s 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.
November 20, 2018

11. Supporting an Abstract Interface
Valuetypes can support multiple abstract interfaces.
Abstract interfaces inherit from CORBA::AbstractBase, not CORBA::Object.
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.
November 20, 2018

12. Reference Counting
CORBA::ValueBase declares pure virtual _add_ref () and _remove_ref () methods.
Programmer must fulfill the ValueBase reference counting interface with custom implementations or mix-in classes.
CORBA::DefaultValueRefCountBase can serve as a base class for valuetypes that will never be registered with a POA.
PortableServer::ValueRefCountBase must serve as a base class for valuetypes that will be registered with a POA.
November 20, 2018

13. Valueboxes
A valuetype with only a single state member is a “valuebox.”
Declared as “valuetype” <identifier> <type>
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.
November 20, 2018

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.
November 20, 2018