Broadcasters have much to gain from incorporating an Enterprise Service Bus into new IT-centric facilities.
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.
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.
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.
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.
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.
You might also like...
Many engineers believed that the release of SMPTE2110 was sufficient to ensure compatibility for all the gear in a media IP-centric environment. Not so, the standard defines the transport layer only. Complying with ST2110 will only guarantee a signal will…
The bewildering number of video and audio compression formats available is difficult for those new to the industry to come to terms with. For broadcast engineers and IT engineers to work effectively together, IT engineers must understand the formats used,…
Protecting media systems from hacking, malware and viruses are genuine concerns to every broadcast and production facility engineer. Unfortunately, antimalware protection software is seldom used on audio and video media systems because the two technologies often prove incompatible.
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…
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…