FIMS:互操作型媒体服务架构

可互操作媒体服务框架（The Framework for Interoperable Media Services, FIMS）是一个定义关于如何使用SOA架构构建媒体系统的标准的项目。 使用FIMS架构可以提供传统架构所缺少的灵活性，高效率和可扩展性。FIMS是由AMWA和EBU共同管理的特别工作组。FIMS 1.0版本在2012年最初被提出，目前仍在持续进行更新和迭代。FIMS2.0与时俱进，通过媒体云和微服务进行服务模型重构和提升，正在加速推进。

为什么媒体行业需要一种新的系统架构 1.媒体消费者的改变

电子媒体行业如今正面临着诸多挑战。内容消费者的需求变得更加复杂，无论是对可用内容的期望，还是他们消费内容的方式。内容分发渠道的数量也在不断增加，而内容本身变得越来越复杂，同时来自消费者和广告的收入逐渐下降。

这给那些制作和提供内容的人带来了巨大的压力。媒体系统已经从传统的“广播（broadcast）”结架构中走了很长一段路，并且需要对一个“程序（program）”的多个版本进行不同的处理。通常需要程序组件的多个版本，包括视频，语言，环绕声，字幕等。这些都必须在一个既有创造性价值又有高效工厂化生产的环境中进行低成本的分发。 2.技术的演进

目前，传统媒体系统架构程序链中的每个流程都与下一个流程紧密相连，以构建制定和交付最终程序所需的复杂活动集。在过去的“广播”系统中，这是可以提供的唯一方法。但是，这种架构无法有效的传输和分发越来越庞大的媒体内容数据量和快速引入越来越多的创新性服务。

图1 传统媒体系统架构

因此，AMWA和EBU正在提出一项全新的提案：每个媒体处理过程都被认为是一种“服务”，可以在必要时调用，并可以通过发布供其他人使用。这个计划就是基于SOA架构的可互操作媒体服务（FIMS）框架。

面向服务的架构（SOA）不是一种产品，而是一种部署松散耦合的软件系统的体系结构，以实现提供业务工作流的流程。SOA提供了一种更可行的架构来构建大型复杂系统，因为它更适合人类活动本身的管理方式——通过委派的执行媒体处理业务。

图2 基于SOA的媒体系统架构

SOA并不新奇，它已在其他领域使用了十年或更长时间，包括银行、金融业和保险行业。它是从面向对象的软件设计和分布式处理的原理发展而来的。SOA的根源在于面向对象的软件和基于组件的软件。出于若干原因，媒体行业在采用此类系统方面落后于其他领域。其中包括媒体对象的庞大大小，文件大小以及某些进程的持续时间。有关在线机票预订的查询可能需要最多一分钟; 电影的转码可能需要几个小时。传统的SOA实现不太适合处理这种长期运行的流程和关键任务活动。

FIMS在SOA架构的基础上，着手提供一个具有以下特性的解决方案：

• 灵活性
• 低成本
• 可靠性
• 可扩展性
• 面向未来
• 可与商业媒体系统集成

FIMS架构概览

考虑到视听媒体的特定需求，FIMS框架必须考虑可能与传统的基于IT的SOA不同的媒体服务方面，例如：

1）异步通信，以及时正确处理与AV媒体相关的大量数据。

2）媒体容器/媒体描述符将AV元数据与AV实体相关联。

3）媒体基础设施服务（资源管理器），用于适当的媒体处理。

4）用于AV数据交换的媒体总线，以及用于消息交换的传统ESB（企业服务总线）。

5）媒体总线M-SLA（媒体服务水平协议），以及ESB中的传统SLA。

6）安全媒体处理的安全准则。

图3 FIMS架构参考模型

FIMS项目扩展了传统的SOA，增加了功能以满足媒体运营的需求。重点扩展增加了以下几个方面：

• 异步操作：异步操作允许长时间运行的服务。媒体流程可能需要数小时或数天; 传统的SOA允许在几秒或几分钟内完成的过程。这就提出了SOA BPM平台的特定持久性要求。尽管服务与业务流程松散耦合，但仍可以在时间限制的情况下运行作业。这可能只是在某个时间开始工作，但服务也可以是实时的，如流的捕获和播出。在这些案例中的工作对服务的请求还将包括该过程的开始和停止时间。
• 资源管理：资源管理允许进程和资源调度识别非常长时间运行的媒体进程。SOA通常基于在服务之间传送XML消息的ESB。 媒体总线：媒体总线与ESB并行运行，以在服务之间传输大型媒体文件。
• 安全性：安全性包括授权和访问控制，但对于媒体操作，它可能包括对内容本质文件的水印的数字权限管理。 SOA和ESB的企业性质将使安全策略的需求比旧的孤立体系结构更加严格。

而传统的媒体系统如需迁移到FIMS架构，需满足以下条件：

1）消息应按照FIMS服务描述框架中的描述实现

2）不得修改消息名称或定义的模式。

3）不得以依赖于模式扩展的方式处理消息。

4）在SOAP实现的情况下，每个服务接口应符合FIMS WSDL。 对于REST实现，消息应符合规范为每个服务定义的头和主体REST映射，消息有效负载应使用FIMS模式进行验证。

5）在SOAP实现的情况下，每个服务至少应实现FIMS WSDL定义的强制部分。 类似地，服务的REST实现应至少实现在通用FIMS模式中定义的强制部分。 除了明确允许供应商扩展的字段外，不得扩展定义。

FIMS项目的最新进展

媒体云和微服务架构（Media Cloud and Microservice Architecture，MCMA）构建并继续作为可互操作媒体服务框架（FIMS）的一部分开发的服务，即FIMS2.0。它是EBU媒体信息管理和人工智能部门（MIM-AI）的一个项目。

MCMA的目标是开发一组具有最小有效负载的简化REST API，以允许集成工作流，将云中的微服务与其他内部服务和流程相结合。

MCMA还将在高级API和底层（例如云）平台之间共享包含粘合代码的库。MCMA的宗旨是“implementation by the example”。MCMA还将发布媒体云服务架构的指南。

MCMA云服务在特定于提供商的云服务之上提供抽象层，支持跨供应商兼容。新方法不是强制执行一组接口，如FIMS 1.X，而是通过支持远期投标对象定义（JsonLD）和微服务架构来实现更加开放的集成模型。MCMA库还为云基础架构的实施，部署和管理提供了一个交互的解决方案。服务注册和自动发现的概念也是基础结构的关键特性。所有库和组件都可以作为GitHub FIMS存储库上托管的项目使用。

MCMA REST调用代表了任何现有云平台（或其他）的最高抽象级别。特定于每个平台的库构成REST接口和工具之间的API层。FIMS使用相应的云基础架构来加速服务发现。诸如AI工具返回的数据之类的有效负载本身可通过专用REST调用或直接由应用程序访问。这些特性已在2017年IBC和NAB成功展示。

在此基础上，FIMS项目组建议就最近的发展情况进行沟通，具体如下：

• 继续使用GitHub上的新库和指南来丰富项目https://github.com/fims-tv/fims
• 使用MCMA EBU工作空间和tech.ebu.ch信息页面发布最新结果，并通过指向GitHub的链接突出显示技术方法及其优势
• 在MCMA上进行通信，应用于AI和云微服务，以围绕面向服务的体系结构传达信息，并在未来发挥其日益重要的作用。

使用FIMS的优势

FIMS特别工作组积极鼓励媒体公司，供应商和独立顾问的参与。参加FIMS项目是免费的，并且不需要AMWA或EBU的会员资格。

对媒体公司而言，参与FIMS项目允许其在项目中运用FIMS项目的方向和优先级，以确保结果可以为其业务带来最大利益；对于供应商而言，参与使其能够确保其产品符合不断发展的标准，监控各种媒体公司的技术战略，并保持与未参与的竞争对手相比的竞争优势。

作为FIMS项目的参与者，可以设置适合其业务和可用资源的参与级别。对于简单的参与，可以只是监控项目的发展，以了解思路并观察其进展；对于更深层次的参与，可以是贡献知识和经验，积极影响项目，以帮助参与者的业务。

图4 当前加入FIMS的组织与公司

到目前为止，FIMS项目在支持媒体内容摄取，内容传输，转码以及管理各个服务的所有重要Orchestration层的项目上已经取得了明显进展。目前，计划继续进行库、质量分析接口以及REST架构实现的开发。

总结

FIMS是基础设施和媒体处理领域的突破性但易实现的变革

FIMS将在业务敏捷性和效率方面带来诸多益处

FIMS工作组将跟踪行业内的具体媒体业务需求，但需要行业对FIMS活动的更多投入和支持

参考 [1] FIMS homepage, https://www.fims.tv/index.shtml [2] EBU MCMA project homepage, https://tech.ebu.ch/groups/mcma