Institute for Software Integrated Systems Vanderbilt University CORBA

Institute for Software Integrated Systems Vanderbilt University CORBA Object-by-Value An overview of the value type and its IDL-to-C++ mapping.

What is Object-by-Value? § Object-by-Value (OBV) is the CORBA mechanism for enabling objects to have passby-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. 9/16/2020 2

Object-by-Value Semantics § OBV implies semantics similar to pass-byvalue 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. ] 9/16/2020 3

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. 9/16/2020 4

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. 9/16/2020 5

Valuetype C++ Mapping § An IDL valuetype maps to: § An abstract base class with the same name. § Inherits from CORBA: : Value. Base. § 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. 9/16/2020 6

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: : Value. Factory. Base 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 (). 9/16/2020 7

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 any factories declared in IDL. 9/16/2020 8

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. § § § 9/16/2020 9

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. 9/16/2020 10

Supporting an Abstract Interface § Valuetypes can support multiple abstract interfaces. § Abstract interfaces inherit from CORBA: : Abstract. Base, 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-byreference semantics to be made at run-time. 9/16/2020 11

Reference Counting § CORBA: : Value. Base declares pure virtual _add_ref () and _remove_ref () methods. § Programmer must fulfill the Value. Base reference counting interface with custom implementations or mix-in classes. § CORBA: : Default. Value. Ref. Count. Base can serve as a base class for valuetypes that will never be registered with a POA. § Portable. Server: : Value. Ref. Count. Base must serve as a base class for valuetypes that will be registered with a POA. 9/16/2020 12

Valueboxes § A valuetype with only a single state member is a “valuebox. ” § Declared as “valuetype” <identifier> <type> § Ex: valuetype String. Value 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 String. Value and WString. Value. 9/16/2020 13

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 Custom. Marshal. § The concrete valuetype must provide implementations of the marshal () and unmarshal () operations. § Intended to facilitate the integration of legacy code. 9/16/2020 14