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 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.]

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.

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 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.

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::ValueFactoryBasewhich 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 ().

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 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.

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.

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.

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.

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.