"One of our biggest challenges was in figuring out how to accommodate business process changes," said Kamlesh Sharma, a Scripps Networks software engineer. "Our asset registration workflow requires a lot of changes, so we needed a solution that was easily configurable to add or delete interactions to accommodate those frequent business changes."

In its search for a suitable solution, Scripps Networks had five primary integration requirements. First, it needed decoupled services for ease of reuse and flexibility. Second, it needed to accommodate frequent business process changes. Next, the solution had to integrate with legacy and third-party applications. It also required robust error handling for multiple exception types. Last, it needed a rich Web-based user interface for human workflow elements.

Scripps Networks decided on Mule - the open source Enterprise Service Bus (ESB) - as a core element in its service-oriented infrastructure for media asset management.

The Power of Decoupled Services
Using Mule as a core infrastructure component, Scripps Networks created a system comprising 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 be easily scaled simply by provisioning additional instances of Mule. The team can also easily make changes to any of the services, or even to the workflow, without negatively impacting the system or creating an undue maintenance burden.

Solving the Error Recovery Issue
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 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 a 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.

The benefits of using Mule are readily apparent at Scripps Networks. The lightweight Mule-based services scale easily by simply provisioning additional instances of Mule. Easy configuration allows for changes in the workflow, increasing business agility and minimizing maintenance costs. Mule's out-of-the-box exception strategies simplify error handling. Finally, its simplified programming model supports the easy creation of rich browser-based user interfaces.

Using Mule as the foundation for its new SOA infrastructure for media asset management, Scripps Networks can now better handle the increasing proliferation of content sources, channels, and media formats. Not only can Scripps deliver content to millions of viewers, but all of the accompanying metadata and digital assets (images, thumbnails, text) is brought together and delivered in a consistent and coordinated fashion.