The SDMX Beans underpin the framework and are what may be referred to as ‘domain objects’, ‘data transfer objects’, or ‘business objects’. The SDMX beans are an Object representation of the information being exchanged. The information may have been exchanged in SDMX, EDI, or CSV, it does not matter, as the SDMX Beans are not coupled to a particular syntax or version of the standard. The SDMX Beans are format and version independent allowing the software that uses them to be decoupled from how the data was exchanged.
Due to the conflicting use cases for the SDMX domain objects, Metadata Technology has defined 3 core ‘flavours of Bean’; the SDMX Beans (immutable), the SDMX Mutable Beans, and the SDMX Super Beans. The SDMX Bean is an immutable Bean closely related to the information model. The SDMX Mutable Bean is a Mutable version of the SDMX Bean. The SDMX Super Bean, also immutable, contains artefacts by composition, rather then by reference. The following sections expand on the previous points.
Immutable : ‘Once the object is created it’s state can never be changed‘
Immutability is a very powerful concept, and absolutely necessary when writing SDMX domain objects. On creation the domain object will validate all of its state, and then it can never be modified. This concept of immutability ensures that each component that performs an action requiring information from one or more SDMX Beans, can be sure that the internal state of the object is known to be valid.
If modification to the Bean is required, then this is still possible by creating a Mutable Bean Instance. Each Immutable Bean can create a Mutable Bean, and vice-versa. Mutable Beans are explained in the section below.
The Downside and Dangers of Having Mutable Beans
Without the concept of immutability, an object can be modified at any point, by any process – it is important to note that even if process A is working on the object, there is nothing to stop another, unrelated process to be working on it at the same time. Due to this mutable (changeable) nature, any component working with Mutable Beans would have to perform some level of validation to ensure what they are processing is valid. Without checking validity the component is assuming the Bean to be valid, and this is where software systems break down and behave in unexpected ways. Never assume!
This changeable state could be a real problem in a software application such as an SDMX Registry. An SDMX Registry has to ensure referential integrity: all cross referenced artefacts must exist. The danger of mutable beans is that an artefact’s cross reference declarations can be modified even after they have been validated. The modification does not break any rules imposed by the SDMX standard, so regardless of the internal validation, the mutable bean would not detect any wrong doing. However the modification is invalid with regards to the current part of the process that this registry is performing. It is not impossible to build solid systems with mutable beans, but it is very hard to build a simple elegant solution with mutable beans, as the object can be in any state at any time.
Whist Immutable beans provide a very powerful and secure mechanism for transmitting data internally in a system, there still needs to be a mechanism to create the Beans in the first place. Metadata Technology Immutable Beans can be created from the SDMX-ML or EDI, and also programatically with the Mutable Beans. A Mutable Bean can exist in any state, valid or invalid, therefore meeting use cases such as creation by the means of user interfaces. Each Mutable Bean has the means to create an Immutable Instance, on creation the Immutable Bean is verified the ensure all required fields have been set and the set values are valid. Mutable Beans are not intended to be passed around a system, only to allow easy creation of the Immutable Beans.
‘The SDMX Super Beans provide referenced structures by composition rather then by reference‘
The SDMX Super Beans are very powerful when used in appropriate situations. Many SDMX structures can contain cross references to other structures. These cross references are defined in the XML and SDMX Beans as a simple references, defining the structure type and unique identifiers. With only a few simple attributes it is possible to resolve a cross referenced structure. Some structures rely heavily on cross references, these tend to be the more powerful structures, one such example is the Data Structure Definition (DSD). The DSD is required to understand how the Data is structured, and cross references Codelists and Concepts. Many components that require information from a DSD also require the cross referenced structures. The SDMX Super Beans provide these cross referenced structures by composition rather the by reference, this means that a DataStructureSuperBean contains the Codelists and Concepts as opposed to containing the reference.
An SDMX Super Bean is the full package in a single Object, allowing for simple interfaces defining a single Super Bean as an input parameter as opposed to the SDMX Bean and all cross referenced Beans. The Super Beans, just like the SDMX Beans, are immutable, meaning that one can be sure that they are not only valid, but do also contain valid referenced structures. Without the concept of Super Beans, any component requiring a structure alone with its references would need to also provide validation that all the required structures are present – this would require the cross references to be resolved and additional error handling. The SDMX Super Beans simplify interfaces, simplify structure navigation, and remove the need for any additional validation and error handling code.