| Previous | Table of Contents | Next |
Value types can override the default marshaling/unmarshaling model and provide their own way to encode/decode their state.
Custom marshaling is intended to be used to facilitate integration of existing “class libraries? and other legacy systems.
It is explicitly not intended to be a standard practice, nor used in other OMG specifications to avoid “standard ORB? marshaling.
The fact that a value type has some custom marshaling code is declared explicitly in the IDL. This explicit declaration has
two goals:
• type safety - stub and skeleton can know statically that a given type is custom marshaled and can then do sanity check on what is coming over the wire.
• efficiency - for value types that are not custom marshaled no run time test is necessary in the marshaling code.
If a custom marshaled value type has a state definition, the state definition is treated the same as that of a non custom
value type for mapping purposes (i.e., the fields show up in the same fashion in the concrete programming language). It is
provided to help with application portability.
A custom marshaled value type is always a stateful value type.
// Example IDL
custom valuetype T { // optional state definition ... };
Custom value types can never be safely truncated to base (i.e., they always require an exact match for their RepositoryId
in the receiving context).
Once a value type has been marked as custom, it needs to provide an implementation that marshals and unmarshals the valuetype.
The marshaling code encapsulates the application code that can marshal and unmarshal instances of the value type over a stream
using the CDR encoding. It is the responsibility of the implementation to marshal the state of all of its base types.
The following sections define the operations and streams that are used for custom marshaling.