Consensus-based standardisation initiatives stood out as the major sub plot of IBC. George Jarrett examines the road to a SOA for big content exploitation concerns.
We had DVB-3DTV close to technical realisation; ACES IIF coming up fast from the Academy of Motion Picture Arts and Sciences; plus an enterprising partnership between the European Broadcast Union (EBU) and the Advanced Media Workflow Association (AMWA) for the creation of FIMS.
Conceived as the ‘Framework for Interoperable Media Services,’ FIMS is an advanced Service Oriented Architecture (SOA) that will see the monolithic production systems common to so many of the big content exploiters split back into sub systems and services. It will benefit users and manufacturers alike, but many from the second group will take persuading to move off proprietary pathways.
Having formed a joint board — Giorgio Dimino of RAI, Jean-Pierre Evain, of the EBU (pictured), John Footen of Chime Media, and AMWA CEO Brad Gilmer – and already capitalising on a strong response to the request for technology (RFT) issued in April, the FIMS crew ran a multi-speaker roundtable event at IBC that impressed on all fronts.
Going into the session, Evain explained: “We are going to do something that allows us to organise architectures in a different way. Users should be able to call up services, and we are defining the interfaces.
“In the past you would go to a manufacturer and he would offer you a turnkey solution with a built-in, proprietary system. You were locked in,” he added. “FIMS allows two things, starting with fragmenting the system into sub systems. It has taken four years to evolve this technology, but it has been a requirement that people have identified.”
With the promised ‘common service definition format’ users will implement services in many different ways but through a common interface. Manufacturers could offer competitive services over the same interface, with the best of breed prevailing. The session, jointly chaired by Gilmer and Hans Hoffmann for the EBU, started with end user plights as identified by Luk Overmeire of VRT, Ian Wimsett from Red Bee Media, and Mirko Zimmer of Hessischer Rundfunk. All of them had found the SOA road to the future.
Why will an SOA help?
Mirko Zimmer explained: “It is about islands and how we bridge the deep water between them.” Out of a project looking at video I/O he cited the must factors as, “Flexible, growing, transparent and traceable.” And he asked, “So why can SOA help us?”
His first SOA concept was to establish services – archive, tapeless production, TV automation, editing, online distribution, and planning. SOA concept two was to orchestrate and follow the key factors reliability and versioning. He showed a VID SOA model with four layers, and stated: “The end user does not come into touch with the software. All processes are monitored by a web client, and next up is the visual process log.” On the issues of problems and challenges, Zimmer highlighted daily business and service development.
Ian Wimsett talked about systems scaling in a media factory that handles 129 streams of TV. He said: “Scale is the problem that needs to be resolved in an elegant way – the efficient scaling of services. In 2007 the concepts of SOA were starting to appear, and we have already moved from the monolithic.”
Picking the three things that caused Red Bee the most grief he cited client data, the orchestration engine, and transcoders. He added, “We do not want to be building adaptors in house, but defining commonsense definitions is not easy.”
On the question of human interaction, Wimsett said: “Not all workflows can be put into being perfectly. You have to allow for bedding in and good user contribution opportunities. The one percent of time that things go wrong it uses up your resources and takes time to fix. The trick is not to give staff step changes.”
Luk Overmeire came at the subject from an integration architecture angle, and laid out the three phases in SOA adoption. These are integration, innovative workflows offering the integration of new functionalities, and an end-to-end service-based workflow. VRT’s digital media factory with its built-in ESB integration is already a famous achievement, but Overmeire had in mind something cheap, fast and stable for the future.
Easy to replace a vendor
On behalf of the manufacturers that had responded to the FIMS RFT, Lewis Kirkaldie, Cinegy product manager, promised proof of concept demonstrations at NAB in April, while Peter Lude, senior VP of Sony Electronics’ professional solutions business, talked about a first media-based SOA product before the end of September, and tackling the challenge of workflow islands.
Lude equated the potential impact of FIMS to the first sightings of HD with Joe Flaherty attached, back in the early 80’s.
“We believe the standardisation of industry-wide common interfaces is essential, to maximise the SOA,” he said. “FIMS is exactly in alignment with Sony’s goals.”
Kirkaldie is sure that FIMS will instigate an era of best quality products at a better price to users. “It will help customers buy services and not be locked in,” he said. “By reducing proprietary interfaces as much as possible, vendors can focus on producing great tools for media customers, instead of spending time re-inventing and supporting a different version of the same wheel,” he added.
Speaking for BBC R&D, a major player in the setting of so many standards, Peter Brightwell talked about getting involved as a respondent. “We are keen to encourage the use of simple techniques,” he said. “Number one is access to stored media, and we are proposing a container format built on both AAF and MXF.”
Steve Canepa, GM of IBM’s Global Media & Entertainment business unit, observed that expanding the SOA as we know it to media introduces challenges to do with larger files and huge amounts of metadata.
“The benefits to users start with it being easy to replace a vendor and to decouple functionality from the implementation,” he said, “The FIMS program is a significant step forward towards a more simple, agile, modular, and market responsive approach to media service integration.” Canepa also warned that adapters will be needed at the beginning of FIMS implementation.
Bruce Devlin, the CTO of Amberfin, asked: “Why can’t we just define a language we all speak?”
Recalling the relatively happy days when users could trust RSI and 4:2:2, he said: “We are trying to get back to the glory days. There is only one group doing that and it is FIMS. We need to define the IT building blocks that allow the media industry to create a custom solution from commodity components — without any eye-watering integration and sustaining costs.”
The new standard defines a dialogue. The key commerical factor is that “vendors can concentrate on building great products not great interfaces, so end users can use cheaper technology.”
We need a common solution
Before passing over to principal speaker and co-chair John Footen, Hans Hoffmann affirmed, “We do want competition on the market, so we need fundamental agreements. Manufacturers should not complain later, once the FIMS standard is agreed. It is no good to say we were not asked to support FIMS and still carry on selling proprietary stuff.”
Footen’s job was to talk about the reasons why people are participating in FIMS, and why it is a benefit to the entire world.
“First of all, I noticed during Ian Wimsett’s presentation that we have only been discussing this subject as an industry since 2007, although SOA as a subject has been around for ten or more years,” he said. “In retrospect, to be reaching the point where we’re coming together to make some standards I think it is pretty amazing.”
The less obvious party to this whole endeavour is the vendor community. “They want to participate in FIMS because manufacturers need to focus on what it is that they do best,” said Footen.
“It probably isn’t the best use of the engineering staff of all of those vendors to be spending their time working on numerous proprietary integrations. As you saw in the (user) presentations, in addition to the already existent proprietary integrations everyone has created their own now,” he added.
Pointing out that three different sets of service definitions had been exposed, Footen said: “Every one of those transcode definitions as an example of what you saw were standardised within that (specific) organisation, but they were not standardised to that vendor. That vendor still has to create three different transcode implementations.
“So it is in the vendor’s interest, whose real business is not to create integrations, to work in this environment to help us find the service definitions for the services that their products provide,” he added. “Maybe it’s an indifferent example, but to me it’s like SDI. Would it make sense for everybody to be defining their own SDI? We need a standardised means for all vendor products to expose what it is they do and still allow for special capabilities that they may provide, and new business functions, etc.”
Perfecting FIMS will mean finding a way for users to find services and use them without a lot of effort.
“On the vendor side we already have numerous supporters involved, through the AMWA. There are a lot of proponents who submitted to that RFT that we put out,” said Footen. “On the user side it is a little more obvious. At this point every major media company is involved in doing some kind of SOA project or creating an SOA initiative. The benefits of creating this kind of at least internal standard, and separating the orchestration from the various services that are being orchestrated, is becoming rather obvious to media companies.”
The reasons for users and vendors wanting FIMS are similar. “The media houses are not in the business of doing integration. Vendors are not in the business of doing integration, so by working on the FIMS standard we are able to create a means for those two types of company to come together, without spending a whole bunch of time on integration,” said Footen. “We welcome anyone that wishes to participate in the FIMS activity. We need a common solution, and that’s what FIMS is.”
The service interface to come first
Jean-Pierre Evain explained that the FIMS executive had taken the risk of following AMWA’s licensing rules, which are compensation free. He also reported that it was a group decision to ask IBM and Sony to work together on a first version of the specification, as they had kindly submitted technology under a royalty free framework.
“Other RFT respondents have come with more specific services, so in phase one we are relying on them to look at the work being done by IBM and Sony, to make sure they cover all the user requirements and implement those requirements,” said Evain.
“The FIMS framework is very complex. The EBU represents the broadcasters, and we will make sure their requirements are taken into account. There will also be discussions about the wrappers and containers to be used in this framework,” he added.
Turning on the recruitment charm, Evain stated that FIMS is open to all. “You can still participate and influence the results of the specification. All you need to do is sign the participation agreement. This is to make sure we do not pollute the free framework we are working to right now,” he said.
“The next step (at the end of October) will see IBM and Sony working on the first draft. And then we have to come with a consolidated version by the end of the year,” he added. “At NAB we want to stage demonstrations, but as you can guess it is going to require a lot of work to be ready for April. Phase one is going to focus on the service interface, the service definition. The second phase will be where we can specify services by themselves.”
