The Challenge – highly reliable media management and delivery

Over the course of the past few decades, the consumer media industry has evolved from a slow-moving oligopoly dominated by a handful of vertically integrated networks to becoming a highly fragmented and competitive marketplace of content creation, publication, and distribution players. This disaggregation of the industry value chain, in combination with the proliferation of content sources, channels, and media formats has created a daunting logistical challenge for anyone attempting to deliver content to the consumer in the right format and at the right time.

At Scripps Networks, a program destined for the HGTV television channel might come from one of many media content partners. The same program might be formatted for the standard definition HGTV channel, as well as for the high definition HGTV-HD. The content might also be repurposed for streaming on the HGTV website, or on one of Scripps Networks’ broadband channels, where consumers can watch the program on a broadband-enabled TV or personal computer. In addition, not only does the media asset itself need to be delivered, but also all accompanying metadata and digital assets (e.g., images, thumbnails, and text) need to be brought together and delivered in a coordinated fashion.

This scenario is played out daily across all of Scripps Networks’ properties, in the context of a highly intricate and constantly evolving schedule. To efficiently manage this complex problem, Scripps requires an infrastructure that can incorporate and orchestrate services that perform the various required business functions, such as ingesting media, registering and indexing assets, retrieving stored assets, and scheduling. Since the business requirements are constantly changing, the infrastructure needs to be modular and flexible, even though some of this business logic resides in legacy systems and third-party applications. Additionally, given that millions of consumers rely on this application functionality, error handling within this mission-critical application needs to be automated where possible, and efficient where human intervention is required.

The Solution – composite applications with robust error handling

Using Mule as a core infrastructure component, Scripps Networks created a system comprised of a number of decoupled services, so that any upgrades or changes to one of the services would have minimal impact on the other services or the overall application. Any given business process is executed by appropriately orchestrating the services using Mule, with JMS as the messaging transport.

For example, to register a new media asset in the system, a user enters it into the domain application interface, where detailed metadata for the asset is stored. The domain application calls the Mule-hosted asset registration service via a SOAP interface, which performs initial validation and then uses a JMS queue to register the asset in the system and update the asset repository. A final message is sent to a JMS topic, which sends the “add asset” event to the indexing application, scheduler, and any other applications that are interested in the event.

Because the infrastructure is service-oriented, with separate JMS queues for each component, any Mule-hosted service can easily be scaled simply by provisioning additional instances of Mule. Additionally, the team can easily make changes to any of the services, or even to the workflow itself, without negatively impacting the system or creating an undue maintenance burden.

“One of our biggest challenges was in figuring out how to accommodate business process changes,” said Kamlesh Sharma, a Scripps Networks software engineer. “The asset registration workflow requires a lot of changes, but Mule is easily configurable to add or delete interactions to accommodate those frequent business changes.”

Because not all of the services are transaction-oriented, implementing error recovery was a challenge for the Scripps team. The solution was to leverage and extend the out-of-the-box Mule exception strategies. If an error happens during any part of the workflow, Mule throws an exception and calls the exception strategy component. The component ascertains whether the exception is a “service exception” or a “processing exception.” A service exception indicates that the service is not available  –  either the network is down, or that particular service is down. If that is the case, Mule will automatically put the message back into the queue for replay, without human intervention.

 

A processing exception, on the other hand, may be due to bad data or a bug in the system, so replaying the message is insufficient  –  human intervention is required. For this situation, Scripps created a Web-based user interface using a JavaScript-based framework, allowing the user to see the error logs and dynamically access, change, and replay the workflow as needed. As an added benefit, the rich Internet application (RIA) architecture harnesses the power of the client machine and relieves the server from computing HTML, making the application responsive and highly scalable.

In developing the RIA for mule based applications, Scripps considered 5 out of various frameworks. They settled on the open source Qooxdoo for its maturity and enhancements on top of standard JavaScript features. Implementing the application with Mule was straightforward, entailing the creation of one Mule component that parses a request and sends the JavaScript resource file to the browser, and another JavaScript Object Notation (JSON) service to supply the data. Finally, the application was compiled using Qooxdoo, and the JavaScript and resources were deployed as a single JAR to the Mule user library.

“Mule is clearly a critical component of our overall business architecture at Scripps Networks” said Sharma. “With Mule, we possess the flexibility and agility to meet the business’ needs while simultaneously being able to robustly handle any system errors that come our way.”