Broadcast Engineering | Testing FIMS 1.0
By Ian Hamilton, Signiant Chief Technology Officer
The rapid pace of change in the media industry demands that leading media organizations implement efficient and agile digital media processing capabilities to control costs and capitalize quickly on new business opportunities. However, achieving the full promise of file-based media workflows and the efficiencies they bring requires seamless interaction among products from different vendors. Therein lies the challenge: Getting disparate products to interoperate is like getting a group of individuals each speaking a different language to understand each other. The effort requires standards for more than just the words or the dialogue — i.e. the file formats. Seamless interaction also requires standardizing the way the dialogues are handled — i.e. the approaches to coordinating and connecting the components of media processing systems.
Most modern businesses today leverage service-oriented architectures (SOAs) to assemble agile business systems. Indeed, SOAs offer tremendous advantages to processing media for playout and distribution. A key element of SOA involves exposing system components as shared network-based services. Connections with services can then be created and reconfigured quickly to respond to changing requirements and demand.
The Framework for Interoperable Media Services (FIMS) was initiated as a joint project between the Advanced Media Workflow Association (AMWA) and the European Broadcasting Union (EBU) to create a common framework for applying SOA principles to processing media. FIMS standardizes service interface definitions for implementing media-related operations in a SOA. As one example of how it can be used, a system that ingests and prepares content for playout and nonlinear delivery can leverage FIMS to interact flexibly with media capture, transfer and transform products from multiple vendors. Using FIMS, system components can easily be added, updated and removed in response to changing business requirements and demand.
The problem
Although workflows are commonplace for moving, processing and storing media using software-centric systems deployed on commodity IT infrastructure, many software-based media processing systems suffer from problems endemic to older hardware and physical media-centric film and video processing systems. Whenever unique media processing requirements must be addressed — and let’s face it, what broadcaster does not have a unique requirement of some sort — there’s an expensive custom software integration project needed to delivered bespoke hardwired media processing silos.
Worse yet, many software-based systems use watch folders to hand off media between components of the system. While watch systems can allow multivendor interoperability and loose coupling, they create a whole new set of quality, reliability and management problems.
The approach
FIMS focuses on the abstract service layer that connects applications and orchestration systems with services that perform operations on media like capture, transform and transfer. (See Figure 1.) FIMS addresses media specific requirements associated with the resource-intensive nature of processing and storing media.
For example, FIMS accommodates long-running processes by incorporating an asynchronous calling pattern and resource prioritization through queuing. The FIMS 1.0 specification defines services interfaces for capturing, transforming and transferring media, with ongoing development efforts under way to define additional services. With FIMS, a workflow that receives media, transcodes it into the required formats and then transfers the result for linear playout and nonlinear distribution can easily be automated through standards-based service orchestration.
Figure 1. FIMS Reference Model
To those unfamiliar with SOA and Web services, the breadth of products and technologies marketed by big IT vendors can be intimidating and overshadow the underlying principles. The FIMS 1.0 specification avoids much of this complexity by defining a resource model as a central component of interaction between service providers and consumers. The resource model approach places more emphasis on what is being communicated between the service consumer and provider than on how it is being communicated. This allows a neutral position on Web services technical debates such as those concerning SOAP versus Representation State Transfer (REST).
The main resources in the FIMS 1.0 model are Services, Jobs and Media Objects. Jobs are processed by Services to perform operations on Media Objects. In the context of the resource model, the Media Objects are formally called Business Media Objects. This qualification is made because these objects only contain the metadata relevant to the business operation being performed along with information about how to access actual media content.
FIMS 1.0 also makes a clear distinction between Media Objects on the message bus and the media bus. The term bus is borrowed from computer architecture where a bus is a subsystem that transfers data between components of a system. The message bus is used to communicate information about media, including media processing instructions. The media bus is used to store, access and move master, mezzanine and finished media products. This model is analogous to the management of physical products where business systems track raw materials, components and inventory for associated real-world objects that are stored and transported using warehouse, ships, planes and trucks.
FIMS Test Harness Project
A practical approach to standardization requires more than object models and interface definitions to gain serious traction. Consequently, the FIMS Technical Board recognized the need for a tool to help FIMS implementers validate their implementations. Signiant did as well, given the test-driven development methodology we use to develop software. Using such an approach, developers create and code tests to validate an implementation before coding it. This leads to higher quality products that can be evolved quickly.
Signiant initiated the FIMS Test Harness Project within the FIMS Technical Board and helped design and build a test harness for contribution to the FIMS effort. The ultimate goal of the test harness is to remove barriers to FIMS adoption and promote implementation of FIMS-compliant interfaces.
Through discussion among the technical board, it was agreed that the test harness should consist of a set of service consumer and service provider simulators. (See Figure 2.) Doing so facilitates interaction between third-party products, which is a key benefit of FIMS. The simulators allow FIMS implementers to independently test their service consumer or provider implementation. These independent tests give vendors confidence that their products will interact properly in real-world conditions.
Figure 2. FIMS Test Harness Components
Completely data-driven testing was another goal of the test harness project. As such, test cases and associated service behaviors are specified with test configuration data. Service consumer configurations specify a sequence of commands to invoke against a service provider. Service provider configuration specifies how the service responds to specific commands with mock behavior. This approach helps ensure that no coding is required to use the test harness and create new test scenarios.
In addition, the test harness project sought to leverage an existing Web services test framework. Broad availability of standards-based testing tools is a significant benefit of a standards-based SOA approach. Through a series of proposals and discussions in the technical board, the decision was made to use the soapUI test framework. SoapUI is an open-source Web service testing application for SOAs. The functionality of soapUI covers Web service inspection, invoking, simulation and mocking, functional testing, and compliance testing. As such, the soapUI framework covers most of the service consumer behavior, and new code was only required to implement mock service provider behavior.
Despite its name, the soapUI framework supports both SOAP and RESTful interactions between service providers and consumers. SOAP is a remote procedure call (RPC) standards-based approach to Web services that references a stack of related standards. The REST approach is conceptually simpler than SOAP and uses standard HTTP operations to interact with resources. FIMS 1.0 formally defines SOAP bindings for services and, although the resource-based approach allows for RESTful interactions, work is ongoing in the FIMS Technical Board to further specify a REST interface. The test harness design allows a REST interface to be easily plugged in on top of existing mock service implementations.
A first version of the FIMS test harness has been contributed to the FIMS initiative for free use by the FIMS community. The FIMS test harness is an easy way to gain practical experience with FIMS, including working with FIMS calling patterns and the FIMS resource model. It provides valuable feedback to both vendors implementing FIMS and users wanting to start working with FIMS. The FIMS community is encouraged to utilize and help expand the test harness through the implementation of additional test cases and behaviors.
Toward lower costs, greater agility
The full promise of file based workflows requires seamless interaction amongst products from multiple vendors. FIMS applies SOA principles to media to facilitate an important part of this interaction. The FIMS Test Harness Project provides a practical starting point for working with FIMS. Adoption and implementation of FIMS brings the media industry a big step closer to file-based workflow’s promise of lowering costs and ultimately improving business agility.
