Successfully Deploying Enterprise Service Bus Technology in the Broadcast Environment

The amount of media content that broadcasters need to create is growing exponentially. Soon broadcasters will reach a point when their current workflows cannot handle the increasing content production demands. A solution is the deployment of a media Enterprise Service Bus (ESB), which will unify content data, media applications, and IT networking resulting in improved efficiency.

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.

Figure 1. The ideal media ESB has media apps residing as backend resources to service the fronted systems and processes.

Figure 1. The ideal media ESB has media apps residing as backend resources to service the fronted systems and processes.

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.)

Figure 2. Generic API connectors are re-useable to link media apps to systems and processes. Datasets use the same or similar API messaging calls common in transcoders, orchestrators, databases, etc. Non-standard gateways may adopt SDK or combination of pre-built API sets.

Figure 2. Generic API connectors are re-useable to link media apps to systems and processes. Datasets use the same or similar API messaging calls common in transcoders, orchestrators, databases, etc. Non-standard gateways may adopt SDK or combination of pre-built API sets.

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. 

Augusto Villaseñor, Vice President of Broadcast Engineering, Globecomm.

Augusto Villaseñor, Vice President of Broadcast Engineering, Globecomm.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

Dealing with Technology End of Lifecycle

Mean Time Before Failure (MTBF) has morphed into Mean Time Before Obsolescence (MTBO). You may have a device that is barely two years old but what if the manufacturer tells you it is obsolete? It cannot be repaired and the…

Your Guide to Understanding IP

See that hill up ahead? It’s not a hill, it’s Mt Everest and your job is to conquer that mountain. Rendered into familiar industry vernacular, you, video engineer, are charged with building an IT-centric facility. A SMPTE standard was…

The Perils of a Software-Centric Facility

Broadcasters have historically not had to endure regular large-scale technology transitions. Sure, the industry moved from B/W to color, analog to digital, and SD to HD. But the upcoming move from the familiar and comfortable SDI technology to an…

Articles You May Have Missed – November 22, 2017

At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground. In less than four years the facility was on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…

BCE Going Deeper - Part 2, Choosing Routers

At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground and in less than four years they were on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…