OpenAssetIO
An abstract API for generalising interactions between a host application and an asset management system
|
OpenAssetIO defines a common set of interactions between a host of the API (eg: a Digital Content Creation tool or pipeline script) and an Asset Management System.
It aims to reduce the integration effort and maintenance overhead of modern CGI pipelines, and pioneer new, standardized asset-centric workflows in post-production tooling.
OpenAssetIO enabled tools and asset management systems can freely communicate with each other, without needing to know any specifics of their respective implementations.
The API has no inherent functionality. It exists as a bridge - at the boundary between a process that consumes or produces data (the host), and the systems that provide data coordination and version management functionality.
The API covers the following areas:
The API, by design, does not:
Once we have a common standard, any Asset Management System or host implementing it can be considered to be compatible. This means that neither party needs to pay any particular attention to who it is talking to, unless they specifically desire to do so.
Our hope is that a common baseline level of support for the key operations performed within multi-site production pipelines will greatly simplify integration and allow innovative new workflows to be developed. Bridging tool vendors, asset management system authors and facility pipelines.
We define an Asset Management System as a system that tracks, and potentially manages, the state and location of digital media. Within the Media and Entertainment sector, these are often known as assets. Within OpenAssetIO, we call anything managed by the system an entity.
Within post-production, entities are often things like project, sequences, shots, clips, image sequences and 3d models that are used to produce final content. In the API, entities are referred to using an Entity Reference.
A host is a tool, script or application that either consumes or produces data, that needs to be managed by an asset management system. We call it the "host" as it is responsible for hosting the API and making appropriate calls to one or more asset management systems as part of its operations.
Depending on whether you are reading this as a host author, or as an Asset Management System integrator, it is worth understanding the high-level architecture of the system. After this, the documentation (and code base) is separated depending on your focus. The following (potentially confusing) diagram attempts to show a simplified version of the architecture as a UML Class Diagram:
It attempts to show that the API is organized into two main namespaces - the hostApi and managerApi. Within each of these, you will find the components you need depending on whether you are adopting the API in a host or providing support for a manager through a plugin.
The first step in any integration is to write an implementation of one of the two abstract interfaces defined by the API, illustrated in orange above - either the HostInterface or ManagerInterface.
The interface implementations are "wrapped" in the Host or Manager classes by the API before being passed to the other side, to provide state management and audit functionality.
A design goal of this API was for it to be (relatively) easy to retro-fit into an existing application or tool. In a minimal implementation, the host follows a few simple rules:
For this reason, OpenAssetIO has the concept of mapping an entity to one or more traits that contain meaningful data for someone wanting to consume the entity.
OpenAssetIO also allows arbitrary key/value pairs to be associated with an entity. This means other more complex data structures can be managed by the asset management system. The only prerequisite being that they can be sensibly encoded in a string and/or simple typed key/value pairs.
A renderer for example, could query the correct file format, colorspace and compression options from the manager for the images it is about to create.
OpenAssetIO was developed to make it possible for an Asset Management System to support any host application without specific knowledge, and vice versa. This is achieved though the use of common specifications that define well-known traits and two simple rules for the manager:
If these rules are followed, then arbitrary assets from arbitrary hosts can be round-tripped through an asset manager without specific support. However, there is scope to build more advanced and useful functionality by mapping OpenAssetIO traits to the manager's native asset types and data.
Copyright 2013-2023 The Foundry Visionmongers Ltd. OpenAssetIO is released under the Apache 2.0 License