...
...
...
...
| Tip | ||
|---|---|---|
| ||
Please note that as of the Nolana release (Q3 2022) the Codex app was retired - these pages may still reference the app and associated modules. |
What is Codex?
Codex is a normalization and virtualizationlayer that allows Folio to integrate metadata about various resources regardless of format, encoding, or storage location. It is the piece that allows disparate resources to be surfaced using a common vocabulary and description.
...
But in practice, domains, and the microservices they contain, form a system and there are necessary interactions between the microservices, including across domain boundaries. Those interactions create dependencies, and in a flat model, this leads to entanglement - thus breaking the promise of a loosely coupled system.
The Entanglement Problem
The interaction between microservices (i.e. modules) is an integration problem. It requires that individual modules be aware of other modules. For modules in the same domain, this is expected and not an issue. However, the same is not true across domain boundaries.
...
This may seem like a manageable approach that can scale linearly. But it is not. Now imagine that a Folio system has 5 resource managing modules. In all likelihood, in a flat modular system, each module will likely need to be aware of each of the other 4. As shown below, the number of interdependencies grows to 10.
<IMAGE: DEPENDENCIES 3>
In the general case, if a Folio system has N resource managing modules, the number of potential integration points is N(N-1)/2, which is not linear, but scales on the order of N2.
A different approach is to use a brokered integration. A new service can act as a coordinator between the different related modules. Each module in turn needs only to integrate with the brokering module. The problem of managing the state and availability of the different services can be achieved in one place. This allows the individual modules to “keep minding their own business” and remain blissfully unaware of other modules’ business. A brokering microservice does need to be aware of the other modules, because that is its business.
...
Codex is a hierarchical domain that acts as a coordinator for resource management. As a coordination domain it is Codex’s business to know about the other domains.
A Hierarchical Domain Model
A significant responsibility of Folio is to manage resources, and more specifically the records that describe those resources. However, not all parts of Folio require the same level of detail for those resources. Nor do they have the same scope requirements: Circulation doesn’t much care about the purchase price of an item, but Acquisitions certainly does. The following diagram focuses on resource management specifically. As shown, the resource managing domains can be organized into layers based on the depth of detail that they require and the purpose they serve.
...
How to tell if a particular resource is available to an institution, either available for circulation or for access or even just on order?
In this example there are 3 domains shown, each of which might represent any number of resource managing apps within.
None of the individual resource managing apps has a complete picture of all resources available in the system.
Codex is the starting point for locating a resource. Each of the resource managing apps “registers” itself to Codex so that resources may be located.
The resource managing apps inform Codex of the matching resource for which it is responsible..
Once the resource is located, the user can drill down into the responsible app to retrieve full details about that resource.
The Order system is a resource managing app within the acquisitions domain.
...
Where do I store the relationship between two different records?
It would be simple enough to create a structure to represent and store such a Work in Inventory or likewise in eHoldings. But the problem arises when the two instances to be related, exist in two different parts of Folio: in this example, in Inventory and in eHoldings. Do we create the work structure in Inventory? Or do we do it in eHoldings? Or do we do it both? The answer is neither. We create the Work object in the Codex domain and link it to the resources that are managed respectively in Inventory and in eHoldings. This avoids a direct entanglement between Inventory and eHoldings. In this case, both can remain blissfully unaware of each other. Furthermore, since we are linking and not duplicating resource records between domains, we also avoid the problem of data synchronization.
...
Each Folio installation has its own Codex domain consisting of relevant Codex apps. From this perspective, Codex is not only the starting point from which to start resource management within each Folio. It is also the point where each Folio can pull in Codex compatible components from other Folio installations.
Multiple scenarios are Illustrated above:
...