Production Technology Seminar 2009 - EBU Technical

Altogether the EBU scope is the following one. We started to discuss on asset management. At IBC
2008, some vendors told us “we are already working on SOA, and our Web services are publicly
described”. Other said “This is all the know-how of our company and we do not want to disclose the way
we manage the different functionalities when we pull up one of the Web services”. One of the company
is developing its Web Service Interface as a big bag and you activate only the part of the functionalities
that you need according to the Interface on which you are working. So, the only way is to have a very
high-level abstract Web service description language. The diagram [10] with the Enterprise Service Bus
(ESB) in the middle, the 2 layers of the abstract Web Service Description Language (WSDL) represents
a similar approach as the one from IBM (§ 2.3), and the lower layer is to be managed by different people
to be connected to this SOA layer (cf. Cisco - § Error! Reference source not found.).
Starting from this complete picture, what do we want to do? First, some of the MAM providers are
tempted to take over the layer of the abstract description language. We do not want them to do that. We
think it is not beneficial to the industry and we want it to be open. Second, what can we do to describe
this directory of services? This is where you should know which services are available, if you want to
refine some workflows. And finally, because we have all these problems of interoperability in MXF, we
also have to deal with the lower layers. In order to reach a ‘plug and play’ service description,
discovery and use, we propose to:
� Investigate possible solutions for a common abstract WDSL
o Recommend a preferred protocol for Web Service access ( definition and SOAP
parameters).
o Recommend a common approach to describe the operations / functions available through the
web service ().
o Recommend common rules and formats for message exchange () and common
datatypes ().
o Harmonise service localisation and associated network definitions.
o Support mapping to publicly defined or more abstract WS interfaces from different MAM providers
or manufacturers.
� Register services in a common directory (adapting and restricting the UDDI concepts to production)
o Provide harmonised WS description about functionalities, requested parameters and expected
effects.
o Provide localisation information.
o Support additional profiling (contextualisation) and access information.
An unexpected potential bonus: a metadata logical reference model [12]
We have been working with the identification of metadata at the different interfaces. Considering the
different steps in production, you get technical metadata on the video format, then some editorial
information, some Edit list, and finally publication data. So, all these metadata that you may collect now
through the Web services is going to contribute to your overall data model in your Broadcasting facilities.
What we have done at the start in EBU was to develop metadata specifications that look at different
models and tried to make THE metadata model. But we are a little stepping back from this position
(although we have more EBU members using P/META that we are still supporting and maintaining). But
on the other hand, because of the impact of Web services on metadata, we now want to have a much
higher Common Logical Data Model (CLDM). It is not a question of structuring this data, but of
understanding what is your amount of data that participates to the logical data model. By doing this we
still benefit from the experience we have gathered embedding the metadata specifications and from the
experience of the EBU members. But this logical data model could become a common reference to allow
Broadcasters to discuss between themselves or with 3 rd parties like manufacturers or MAM providers.
For instance, if a broadcaster has a data model, he would map it to this CLDM. A MAM provider mapping
its data model to this CLDM, can then compare its data model to all broadcasters‟ data models, because
he has one common reference to which each broadcaster has mapped its own data model.
Conclusions
File-based tapeless production is becoming a reality, but issues still need to be addressed through
additional rules and guidelines, and EBU can help.
Tapeless production is a trigger to develop new architectures and improve asset and workflow
© EBU 2009 / Production Technology seminar / January 27 - 29, 2009
Reproduction prohibited without written permission of EBU TECHNICAL & EBU TRAINING
25