Digital Studio looks at how an integrated web services API can help realise the potential of advanced workflows.
Many file-based workflows in operation today are essentially the same as yesterday's tape-based workflows.
Ingest servers act as the encoders or insertion points for content in workflows, doing no more than creating a file and making it available for other applications. Transmission servers receive ready-to-air content pushed to them by automation or media management, then play it out.
However, the introduction of active storage systems based on advanced, grid-based storage architecture has the potential to change dramatically the role of storage in broadcast workflows.
These active storage systems are, in fact, a step toward enabling file-based workflows to live up to their much vaunted potential for efficiency and for enabling media businesses to take advantage of the new distribution opportunities for leveraging content.
Used as central storage, an active storage system interfaces to third-party applications for processing, production, and archive management, enabling the functionality and performance of storage itself directly to benefit the entire workflow.
For example, with an active storage system in place, proxy generation and format transcode can be performed on content as it resides in central storage.
Paradoxically, however, the active nature of active storage, a boon to workflow efficiency, can at the same time create undesirable complexity. This is because each application functioning within it will have its own Application Programming Interface (API), making integration of it into the whole a challenge that can require as many as 10 APIs and network protocols.
One way to address the challenge created by this complexity is implementation of a single integrated web services API to tie together the storage systems in a cohesive way, providing a services platform for third-party integration and application development.
An integrated web services API is based on the principles of Service Orientated Architecture (SOA), which quickly are becoming the standard for open application integration.
Through the provision of an open, platform-independent framework, the storage system provider utilising such an API could ensure maximum interoperability with partner and customer systems. In addition, the integrated API would allow complex, distributed systems to be built more quickly than they can be using traditional programming techniques.
Structurally, an integrated web services API would provide the software platform required to manage complex systems, including a system database (for tracking content, storing rules and metadata, and storing relationships between content), a messaging bus for ease of integration, and a mechanism for publishing the web service.
An integrated API would also encapsulate and expose the key functionality of the active storage system's existing APIs but build on that functionality by offering core services targeted for maximum utility in a demanding multiple-product, complex deployment.
The integrated web services API is a multi-tier access control system that runs throughout the entire platform - for users, functionality, and content.
Within it, profiles could be created to represent specific roles within an organisation, and users conforming to each of these roles could be restricted via the API to seeing only certain content and performing only certain functions.
This virtual segmentation of the system would be useful in service-provider platforms because it also ensures that applications only interact with appropriate content as defined by the administrator.
The integrated API might also enable audit logging, the ability to view and analyse system activity to determine who did what, when, and how, which helps ensure accountability.
The integrated API has the potential to introduce multiple core foundation services that provide functionality above and beyond what traditional provider APIs offer. These services might offer the same functionality as the multiple physical systems, while content is distributed across those systems.
The services could be utilised by any integrated partner, depending on what is required, while allowing enterprise media asset management application providers to focus on functionality outside the environment of the active storage system provider.
Some services that could be introduced within an integrated web services API include Search, Transfer, Organising, handling metadata, managing media, establishing rules and establishing rules, which relates to the ability to schedule and automate specific tasks within the integrated web services API such that repeated tasks do not require manual intervention.
For example, rules can be configured to provide notifications of specific file actions, such as new files arriving or being closed. It is also possible to create and store rules for how content should be moved between systems, enabling third-party applications to create complex transfer or mirroring rules between systems, again using the most appropriate transfer mechanism for the job.
To conclude, an integrated web services API is designed to provide tight, simple integration of workflow management and automation applications.
End users will benefit from having more flexible, workflow-conscious and efficient systems and from management behavior that is tailored to individual workflows.
Such an API is also intended to provide an extensible platform for third-party application integration so that future media services easily can be rolled in under the common interface structure.
With an active storage system incorporating an integrated web services API, media and entertainment companies will be able to make the most of more efficient workflows, reduced implementation schedules, and the profit potential of media distribution platforms.