For decades, Enterprise Service Bus (ESB) technology has been used in the broadcast and media environments to support IT systems, such as database, email, storage, and web services. Recently, the role of ESB technology has started to expand. One of the key benefits of ESB technology is that it unifies the integration of backend services to the frontend client/hosts and their users. This article will examine the challenges that broadcasters face in terms of workflow constraints, the benefits of using a media ESB for content processing tasks, and key ESB design considerations.

Broadcast Media Workflow Challenges

Broadcast media infrastructure, unlike IT, consists of a wide range of proprietary-based technologies and interfaces that are not interoperable. This causes a strain on production quality, especially when mass quantities of content are being requested. Over the last two decades, broadcasters have increasingly adopted IT-based workflow components to address this issue.

Most broadcasters today rely on file-based systems for content storage and have started transitioning to an entirely file-based workflow for content preparation, asset transformation, and content distribution (e.g., ingest, transcoding, editing, regulatory-compliance, on-air playout, archiving, asset management, publishing and content re-purposing). While workflow efficiencies and flexibility can be achieved with IT-based technologies, this replacement approach can also result in scattered, stand-alone systems that cannot keep up and interact with modern content processing adaptability.

Creating a media ESB based upon decentralized media applications that can be dynamically assigned to any content processing requirement eliminates duplicated processes, content queue bottlenecks, dependencies, interoperability, and scalability issues. This allows broadcasters to effectively manage networking connectivity constraints and boost efficiencies.

Value Proposition of Media ESB

The concept of media ESB is based on client-server architecture that speeds up the content completion cycles by integrating content and the systems and processes to media applications via API and the IT network, thereby eliminating detached functions that are typical in traditional systems. (See Figure 1.) Media ESBs include a centrally managed bus structure that is easy to control and is powered by distributed back-end media apps supporting various front-end systems and processes. Ultimately, with a media ESB, broadcasters gain the flexibility to assign available resources for content processing.

There are a host of benefits for broadcasters that implement a media USB. For instance, using ESB, workflows can be initiated, refined, and completed with greater efficiency. ESB handles media apps and IT networking as resources that may be attached, detached, and re-allocated to rapidly adapt to event-driven requirements. Moreover, media ESB is built on open technologies to promote re-usability, modularity, and collaboration to optimize operational performance and reduce system complexity. This type of workflow approach is perfect for the dynamic nature of the broadcast environment.

Design Considerations

There are a few fundamental design requirements to consider when implementing a media ESB. In particular, it’s important to think through reusable APIs, networking, and standards and technologies.

Strategizing about the type of API to deploy is essential. When selecting an API, there is a common misconception to tailor infrastructure needs on specific endpoints during integration phase. While customization can limit risks, it also reduces the system flexibility and diverts the system ability to interface to other possible gateways in the future. Using generic re-useable API COTS connectors, broadcasters can easily add required media apps to the media ESB. (See Figure 2.)

It is not uncommon for broadcast engineers to oversize the network capacity in order to ensure traffic data flows seamlessly. However, oversizing an IT network isn’t recommended. Performing basic data traffic calculation broadcasters can determine the required network throughput, prioritization and the segmentation needed for the media ESB to balance the network performance, efficiency, and visibility.

Finally, the media ESB must comply with various rules and protocols. Common API styles include REST and SOAP. REST API requires less bandwidth when requesting services and can consider networked media apps as resources when connections are requested. On the other hand, SOAP API is extremely stable and features an interfacing language that relies exclusively on XML (eXtensible Markup Language) for communicating messages. Media apps requiring fixed error-free communications can use SOAP to interact data interchange representation. While REST dominates 83 percent market share of all APIs deployed, according to recent Cloud Elements’ report, using SOAP is advantageous for industries requiring critical authentication calls such as bank records and financial transactions.

Conclusion

Deploying a media ESB unifies content data, media applications, and IT networking, making broadcasters better equipped to handle a greater volume of content, with increased efficiency. With a media ESB, broadcasters can test out and launch new features and processes with ease. The flexibility and efficiency of the ESB system is realized through running media applications as independent code inside a virtual machine. Using open technologies, VM and COTS hardware, the ESB eliminates software, hardware, and vendor specific technology reliance, which is cost saving.

Most importantly, by optimizing processes, introducing modularity to the infrastructure, and VM implementation, media ESB allows broadcasters to better focus on creating new revenue streams.