FIMS Media SOA Framework - AMWA

FIMS Media SOA FrameworkAMWA SpecificationAMWA Application SpecificationFramework for Interoperable Media ServicesMedia SOA Framework Phase 1 (Preliminary)November 16, 2010 (rev v0.1)DRAFTExecutive SummaryThis document describes a vendor-neutral common framework for implementing Interoperable Media Servicesusing a Service Oriented Architecture (SOA) based system, supporting interoperability, interchangeability andreusability of media specific services.Copyright © 2010 AMWANOTES – The user’s attention is called to the possibility that implementation and compliance with this specification may require use ofsubject matter covered by patent rights. By publication of this specification, no position is taken with respect to the existence or validity ofany claim or of any patent rights in connection therewith. The AMWA, including the AMWA Board of Directors, shall not be responsible foridentifying patents for which a license may be required by an AMWA specification or for conducting inquiries into the legal validity or scopeof those patents that are brought to its attention.

FIMS Media SOA Framework Phase1 (Preliminary)ContentsExecutive Summary................................................................................................................ 1Contents................................................................................................................................ 21 Scope .......................................................................................................................... 52 Conformance Language................................................................................................. 63 Reference Documents ................................................................................................... 73.1 General References .................................................................................................. 73.2 Standards References............................................................................................... 73.2.1 Web and Internet Technology.......................................................................... 73.2.2 XML............................................................................................................... 73.2.3 Web Services ................................................................................................. 73.2.4 SOA AND BPM ................................................................................................ 83.2.5 Date and time formats (EBU Tech3295)............................................................ 83.2.6 Video and Audio time point references (EBU Tech3295) ..................................... 93.2.7 Security ........................................................................................................104 Overview.....................................................................................................................115 High-Level Architectures...............................................................................................125.1 What does it mean to be ‘FIMS Compliant’? (Both to Services and Systems) OPEN ISSUE– FIMS TO DECIDE ...........................................................................................................125.2 Reference architecture(s).........................................................................................125.2.1 Scenarios: Mediations, Dynamic resource allocation ..........................................135.3 Definitions / Glossary...............................................................................................136 Media Service Management ..........................................................................................146.1 Service lifecycle ......................................................................................................146.1.1 Deployment ..................................................................................................146.1.2 Decommissioning...........................................................................................146.1.3 Replacement/Upgrade....................................................................................146.1.4 Backward compatibility...................................................................................156.2 Service behavior .....................................................................................................166.2.1 Operation Implementation patterns.................................................................166.2.2 Input and Output Media .................................................................................19Copyright © 2010 AMWANOTES – The user’s attention is called to the possibility that implementation and compliance with this specification may require use ofsubject matter covered by patent rights. By publication of this specification, no position is taken with respect to the existence or validity ofany claim or of any patent rights in connection therewith. The AMWA, including the AMWA Board of Directors, shall not be responsible foridentifying patents for which a license may be required by an AMWA specification or for conducting inquiries into the legal validity or scopeof those patents that are brought to its attention.

FIMS Media SOA Framework Phase1 (Preliminary)6.2.3 Error and exception handling ..........................................................................206.2.4 Failure Recovery............................................................................................216.2.5 Job Queue ....................................................................................................216.2.6 Job Execution Priority.....................................................................................226.2.7 Events Notification.........................................................................................226.2.8 Operation Profiles [to be completed] ...............................................................236.2.9 Operation execution deadlines [to be completed] .............................................236.3 Job management ....................................................................................................236.3.1 Lifecycle of a job ...........................................................................................236.3.2 Management Commands ................................................................................257 Media Service Awareness..............................................................................................277.1 Service registry .......................................................................................................277.1.1 Registering a service......................................................................................287.1.2 Discovering a service .....................................................................................287.1.3 Service taxonomy ..........................................................................................307.2 Service-level agreements **FURTHER DISCUSSION NEEDED about how to constrainwhat needs to be defined** how this applies to scheduling resources and jobs......................327.2.1 Policy ontology and schema............................................................................327.2.2 Querying SLAs...............................................................................................327.2.3 Enabling business rules ..................................................................................327.2.4 Enforcing SLAs ..............................................................................................328 Media Service Communication.......................................................................................338.1 Common properties.................................................................................................338.1.1 Schema Design..............................................................................................338.1.2 Message Format and Patterns.........................................................................338.1.3 Transactional Management.............................................................................398.2 Service Provider Interface ........................................................................................398.2.1 Operations ....................................................................................................398.2.2 Schema ........................................................................................................508.3 Service Consumer Interface (Service Events Producer Interface ??).............................678.3.1 Operations ....................................................................................................688.3.2 Schema ........................................................................................................68Copyright © 2010 AMWANOTES – The user’s attention is called to the possibility that implementation and compliance with this specification may require use ofsubject matter covered by patent rights. By publication of this specification, no position is taken with respect to the existence or validity ofany claim or of any patent rights in connection therewith. The AMWA, including the AMWA Board of Directors, shall not be responsible foridentifying patents for which a license may be required by an AMWA specification or for conducting inquiries into the legal validity or scopeof those patents that are brought to its attention.

FIMS Media SOA Framework Phase1 (Preliminary)9 Media Centric Features (informative for this edition) .......................................................729.1 Composite Service...................................................................................................729.1.1 Profiles .........................................................................................................759.1.2 Capture Service [To be Moved/merged with Section 8] .....................................769.1.3 Transform Service [to be moved/merged with Section 8] ..................................799.1.4 Transfer Service [to be moved/merged with Section 8] .....................................809.2 Asynchronous operations for long running process.....................................................829.3 Resource Management ............................................................................................839.3.1 Process Scheduling and Resource Management................................................839.4 Media Aware Bus ....................................................................................................849.4.1 Definition ......................................................................................................849.4.2 Other Media Bus Features ..............................................................................859.4.3 M-SLA...........................................................................................................859.4.4 Automatic Transform .....................................................................................859.5 Security and Identity (Informative)...........................................................................869.5.1 Security Concerns ..........................................................................................869.5.2 SOA Application Security Models .....................................................................869.5.3 Message-level Security ...................................................................................8710 Framework Extensions FIMS .........................................................................................8910.1 Framework lifecycle.................................................................................................8910.1.1 Re-evaluation ................................................................................................8910.1.2 Taxonomy.....................................................................................................8910.1.3 SLA Ontology ................................................................................................8910.1.4 Submissions to WG ........................................................................................89Copyright © 2010 AMWANOTES – The user’s attention is called to the possibility that implementation and compliance with this specification may require use ofsubject matter covered by patent rights. By publication of this specification, no position is taken with respect to the existence or validity ofany claim or of any patent rights in connection therewith. The AMWA, including the AMWA Board of Directors, shall not be responsible foridentifying patents for which a license may be required by an AMWA specification or for conducting inquiries into the legal validity or scopeof those patents that are brought to its attention.

FIMS Media SOA Framework Phase1 (Preliminary)1 ScopeThis document describes a vendor-neutral common framework for implementing Interoperable Media Servicesusing a Service Oriented Architecture (SOA) based system for use in broadcast, production, post production,media distribution, and media archive applications. The framework supports interoperability, interchangeabilityand reusability of media specific services.The high-level architecture and framework is described. This framework will cover all system and managementrequirements (service management, awareness and communication, content and time awareness, security,framework extension).This preliminary edition addresses three basic Media Services: Capture, Transform, and Transfer. [The WorkOrder Service is also defined.]Copyright © 2010 AMWANOTES – The user’s attention is called to the possibility that implementation and compliance with this specification may require use ofsubject matter covered by patent rights. By publication of this specification, no position is taken with respect to the existence or validity ofany claim or of any patent rights in connection therewith. The AMWA, including the AMWA Board of Directors, shall not be responsible foridentifying patents for which a license may be required by an AMWA specification or for conducting inquiries into the legal validity or scopeof those patents that are brought to its attention.

FIMS Media SOA Framework Phase1 (Preliminary)2 Conformance LanguageNormative text is text that describes elements of the design that are indispensable or contains the conformancelanguage keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user,but not indispensable, and can be removed, changed, or added editorially without affecting interoperability.Informative text does not contain any conformance keywords.All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as"Informative" or individual paragraphs that start with "Note:”The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to thedocument and from which no deviation is permitted.The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended asparticularly suitable, without mentioning or excluding others; or that a certain course of action is preferred butnot necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated butnot prohibited.The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may bedefined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provisionwill never be defined in the future.A conformant implementation according to this document is one that includes all mandatory provisions ("shall")and, if implemented, all recommended provisions ("should") as described. A conformant implementation neednot implement optional provisions ("may") and need not implement them as described.Unless otherwise specified, the order of precedence of the types of normative information in this document shallbe as follows: Normative prose shall be the authoritative definition; Tables shall be next; followed by formallanguages; then figures; and then any other language forms.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 6 of 89

FIMS Media SOA Framework Phase1 (Preliminary)3 Reference Documents3.1 General References[1] World Wide Web Consortium (W3C), http://www.w3.org[2] Organization for the Advancement of Structured Information Standards (OASIS),http://www.oasis-open.org[3] Web Services Interoperability Organisation (WS-I), http://www.ws-i.org[4] Advanced Media Workflow Association (AMWA), http://www.amwa.tv[5] Society of Motion Picture and Television Engineers (SMPTE), http://www.smpte.org[6] Open SOA Collaboration (OSOA), http://www.osoa.org[7] Internet Engineering Task Force, Public-Key Infrastructure (X.509) Working Group (PKIX),http://www.ietf.org/[8] Object Management Group/Business Process Management Initiative, http://www.bpmn.org/[9] International Telecommunications Union (ITU) http://www.itu.int/net/ITU-T/info/Default.aspx -Public-Key Infrastructure (X.509)[10] Motion Picture Association of America - CONTENT SECURITY - Best Practiceshttp://www.fightfilmtheft.org/en/bestpractices/_piracyBestPractice.asp[11] National Institute of Standards and Technology (NIST) - Role Based Access Control (RBAC) andRole Based Security: http://csrc.nist.gov/groups/SNS/rbac/[12] European Broadcast Union, EBU Technical References, http://tech.ebu.ch/publications[13] ISO/IEC 29341-1:2008 Information technology -- UPnP Device Architecture -- Part 1: UPnP DeviceArchitecture Version 1.03.2 Standards References3.2.1 Web and Internet Technology1) HTTP / HTTPS2) HTML 4.03) XHTML4) CSS5) SSL3.2.2 XML1) XML2) XML Schema 1.03) SOAP 1.13.2.3 Web Services1) WS-I Basic Security Profile 1.12) WS-HumanTask 1.03) WSDL 1.1Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 7 of 89

FIMS Media SOA Framework Phase1 (Preliminary)4) UDDI3.2.4 SOA AND BPM1) BPMN 1.02) WS-BPEL 2.03) BPEL4People 1.03.2.5 Date and time formats (EBU Tech3295)ISO 8601 and IETF RFC 3339It is particularly important to respect the syntax for date and time (http://www.w3.org/TR/NOTE-datetime andIETF RFC 3339), which can be summarized as follows:Year:YYYY (e.g. 1997)Year and month:YYYY-MM (e.g. 1997-07)Complete date:YYYY-MM-DD (e.g. 1997-07-16)Complete date plus hours and minutes:YYYY-MM-DDThh:mmTZD (e.g. 1997-07-16T19:20+01:00)Complete date plus hours, minutes and seconds:YYYY-MM-DDThh:mm:ssTZD (e.g. 1997-07-16T19:20:30+01:00)Complete date plus hours, minutes, seconds and a decimal fraction of a secondYYYY-MM-DDThh:mm:ss.sTZD (e.g. 1997-07-16T19:20:30.45+01:00)where:YYYY = four-digit yearMM = two-digit month (01=January, etc.)DD = two-digit day of month (01 through 31)hh = two digits of hour (00 through 23) (am/pm NOT allowed)mm = two digits of minute (00 through 59)ss = two digits of second (00 through 59)s = one or more digits representing a decimal fraction of a secondTZD = time zone designator (Z or +hh:mm or -hh:mm)It is not specified how many digits may be used to represent the decimal fraction of a second. An adoptingstandard that permits fractions of a second must specify both the minimum number of digits (a number greaterthan or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited").Common practice is to use 3 digits.Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z"), or times areexpressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm"indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A timezone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm"Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 8 of 89

FIMS Media SOA Framework Phase1 (Preliminary)minutes behind UTC. A standard referencing this profile should permit one or both of these ways of handlingtime zone offsets.Durations are represented by the format: P[n]Y[n]M[n]DT[n]H[n]M[n]S (or P[n]Y[n]W[n]DT[n]H[n]M[n]S touse the week format). In this representation replace [n] with the appropriate number for the element thatfollows it (leading zeros are optional but may clarify ambiguous durations). The capital letters ('P', 'Y', 'M', 'W','D', 'T', 'H', 'M' and 'S') are used as they are and not replaced.Example:"P3Y6M4DT12H30M0S" defines "a period of three years, six months, four days, twelve hours, thirtyminutes, and zero seconds".Elements may be omitted if their value is zero. To resolve ambiguity, "P1M" is one month and "PT1M" is oneminute. The smallest value used may also have a decimal fraction, as in "P0,5Y" to indicate half a year. Thenumber of seconds can include decimal digits to arbitrary precision.3.2.6 Video and Audio time point references (EBU Tech3295)FIMS uses three methods to identify video and audio time point references:1. a time duration according to ISO 8601 or IETF RFC 33392. timecodes as defined by SMPTE in specification ST 12-1-20083. a number of edit units, which are the fraction of time calculated as the inverse of the frame rate forvideo (i.e., image frames in a video sequence), or the inverse of the sample rate for audio (i.e., audiosamples).Audiovisual entities generally embed the property of having a “Timeline”, which comes from the fact that the AVwork is conceived to be played for a defined “Duration”, and all the events characteristic of the AV work itselfare located on the Timeline.The Timeline concept applies to AV ‘editorial entities’ as well as to the ‘physical entities’, which are the sourcesproviding the AV material for actual realizations.A typical application of the timeline mechanism is for identifying the location of a given AV-entity A which is apart (in time) of another AV-entity B.As B has got its own duration D(B), we can say that A, with its own duration D(A), is located at point S of theTimeline of B.This means that if A is located on the Timeline of B, from S to E, then E=S+D(A).In P-META there are two mechanisms for expressing a position on a Timeline:• the “Elapsed Time”, which gives the time elapsed on the Timeline of the reference entity (B in the exampleabove) from its beginning.the data type for that is a ISO 8601 duration(e.g. PT1M5.0S) or IETF RFC 3339;the reference point for the elapsed time is always the beginning of the reference entity.• the “Elapsed Units” which give the same information in terms of the number of Edit Units (which arecountable)this is to be preferred because it ensures that Timeline markers fall on the boundary of the Edit Unit;duration of the EditUnit must be known unambiguously and indicated, otherwise it is better to use the“Elapsed Time”.The two mechanisms mentioned above can also be used to locate the position of an AV-entity on theTimeline of a material source.However there are contexts, in terms of the type of source, where the information in those terms is notavailable or it’s possibly ambiguous. For instance, identifying the position on a clip within a video-tape in termsPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 9 of 89

FIMS Media SOA Framework Phase1 (Preliminary)of “Elapsed Time” or “Elapsed Units” from the “BOT (Beginning of Tape) is very difficult in practice. The BOTposition itself may be not precise enough. In those cases, typically, the position on material source (e.g. thetape) is indicated by the “TimeCode”, which is a label recorded together with the EditUnit.Although the “TimeCode” mechanism does not provide any certainty about the uniqueness of the pointon the Timeline (the same TimeCode might be repeated) and neither it provides reliable information onDuration (“TimeCode” is not constrained to be continuous), this is the way on which legacy production systemsrely for editing and for saving EDLs (Editing Decision Lists).This is the reason why FIMS also supports the indication of TimeCodes for all the cases where the Timelinepositioning deals with material sources.However, it is recommended to also provide, if available, the information in terms of elapsed time or edit units.3.2.7 SecurityANSI INCITS 359-2004 - American National Standard for Information Technology – Role Based AccessControlISO/IEC 27001:2005 - Information technology -- Security techniques -- Information securitymanagement systems -- RequirementsISO/IEC 27002:2005 - Information technology - Security techniques - Code of practice for informationsecurity management (Re-designation of ISO/IEC 17799:2005)MPAA - CONTENT SECURITY - Best Practices - Digital Services 12/31/2009MPAA - CONTENT SECURITY - Best Practices - Post-Production Services (Large) 12/31/2009MPAA - CONTENT SECURITY - Best Practices - Post-Production Services (Small) 12/31/2009MPAA - CONTENT SECURITY - Best Practices - Replication 12/31/2009CategoryTransport protocolsStandardsHTTP 1.0 and 1.1, HTTPS, JMS, FTP, SMTP, and UDPSecurity 3DES, AES, RSAv1.5, SHA-1, MD5, PKCS#12, MPKI, JKS, SSL3.0, and TLS 1.0XML & WebServicesSOAP 1.1, SOAP w/ Attachments, XSLT 1.0, XPath 1.0, XSD 1.0, 1.1, XKMS, WS-IBasic Profile 1.0, WSDL 1.1Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 10 of 89

FIMS Media SOA Framework Phase1 (Preliminary)4 OverviewThis specification defines a common approach to the integration of software components in modern mediaproduction facilities is believed to be a fundamental need of the entire media industry.The specification is based on an overall framework for integration of reusable components for multimediacontent production which would support the business functions of the professional media industry. Thisframework for media services includes specific detailed definitions of common media processes.The focus of this specification is on Service Oriented Architecture (SOA), and reflects a move by the mediaindustry toward systems that use this approach. Media companies are moving towards more rapid adoption ofthese systems because of a need to increase agility in a market where user requirements are changing rapidly.In addition to the need for agility, these companies require the increased maintainability, scalability andextensibility that a Service Oriented approach would provide.To properly exploit this technology a common framework should be adopted to help ensure integrationinteroperability, interchangeability and reusability of services. This will drastically reduce integration costs, allowusers to more freely choose the most appropriate products on the market at any given time, improvemaintainability, and aid in the adoption of new technologies.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 11 of 89

FIMS Media SOA Framework Phase1 (Preliminary)5 High-Level Architectures5.1 What does it mean to be ‘FIMS Compliant’? (Both to Services and Systems)OPEN ISSUE – FIMS TO DECIDE5.2 Reference architecture(s)Figure 1 shows the overall reference model of the FIMS Framework.Figure 1 FIMS Phase 1 Framework Reference ModelTo take account of the specific needs of audiovisual media, the following items differ compared withconventional IT-based SOA:1. Asynchronous communication to properly handle the very large amounts of data associated with AVmedia in a timely manner.2. Media Container/Media Descriptor to associate AV metadata with AV essence.3. Media Infrastructure Service (Resource Manager) for appropriate media handling.4. Media Aware Bus for AV data exchange, in addition to the conventional ESB for XML messageexchange.5. Media Bus M-SLA (Media-Service Level Agreement), in addition to the conventional SLA in ESB.6. Security guidelines for secure media handling.Media-centric issues are described in Section 9.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 12 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Figure 2 illustrates the scope of Phase 1 of the FIMS Framework for NAB 2011:Figure 2 Preliminary FIMS Framework for NAB 20115.2.1 Scenarios: Mediations, Dynamic resource allocation[to be completed]5.3 Definitions / Glossary[to be completed]Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 13 of 89

FIMS Media SOA Framework Phase1 (Preliminary)6 Media Service Management[Media services have high availability requirements that must be met by implementations]6.1 Service lifecycleThe FIMS framework includes a service registry, which among other functions manages the lifecycle of services.A lifecycle is a set of states with transitions defined between them. The FIMS standard does not specify how theservice registry shall be implemented, but it rather focuses on the following aspects:• Minimum set of capabilities that a service registry should provide to support the following servicelifecycle states:ooooService deployedService updatedService replacedService decommissioned• Information model for supporting the lifecycle states defined above.6.1.1 DeploymentThe service registry shall support the deployment of a service to the following types of environment:• Development environment• Test environment• Production environmentA service deployed to the development or test environment shall not be discoverable in the productionenvironment. A service can be deployed to one of the environment above (e.g. to the developmentenvironment) and can be promoted to other environments (e.g. to the test environment).A service is deployed when the new service or service instance is registered in the service registry. Theinformation provided in the registration process includes:• Service interfaces and imported schemas• Service endpoint information (might be imported from the WSDL service binding information)• Service description metadata (as described in xxxx)• Service policies• SLA/M-SLA contracts.Details on the information provided for registering the service are provided in section xxx. Once the service isregistered in the service registry, it becomes available for discovery and invocation.6.1.2 DecommissioningDecommissioning services from the production environment is supported by the service registry, which allowsthe system administrators to first deprecate existing implementations so that potential new consumers do notsee the specific implementation. Administrators can then use reporting and impact analysis capabilities in theservice registry to allow the operations team to identify remaining service version consumers and ensure thatthey migrate onto the correct alternative version. After all of the consumers have been migrated, the old serviceversion can be retired from use and remove it from the deployment environment.6.1.3 Replacement/UpgradeA service can be updated or replaced by updating the service information in the service registry. Theinformation to be updated might include:Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 14 of 89

FIMS Media SOA Framework Phase1 (Preliminary)• Service interfaces and imported schemas [for new versions of the specifications]• Service endpoint information• Service description metadata• Service policies• SLA/M-SLA contracts.The service interfaces and schemas are standardized in this FIMS proposal and should not require update if aservice is replaced by one providing the same business functionality with the same version of the interface.However, as FIMS specifications evolve, new versions of the interface may be published [see 6.2.4] and mayneed to be updated in the registry. As service versions are superseded by new implementations, which deliverthe same required business capability, the service governance lifecycle should allow specific versions to bedeprecated and, ultimately, retired6.1.4 Backward compatibilityBackward compatibility issues might arise for a variety of scenarios. This version of the specification focus ontwo key scenarios:• There is a new version of the FIMS specifications for the service interface.• A service implementation has been modified for adding or removing features (such as operations).6.1.4.1 New Version of the Service InterfaceWeb Services versioning approaches are described in detail in [REF1]. To summarize those findings, there aretwo key approaches to service evolution and versioning:• Compatible evolution: In compatible evolution, designers are expected to limit changes to those thatare either backward or forward compatible, or both. A change is backward compatible when thereceiver behaves correctly if it receives a message in an older version of the interaction language. Achange is forward compatible when the receiver behaves correctly if it receives a message in an newerversion of the interaction language.• Big bang: A change to the WSDL document implies a change to the document's namespace, a changeto the interface implies a new interface namespace and a change to the message contents iscommunicated using a new message namespace.• Combined approach: the approaches above are combined together. For example, the namespace couldbe changed when message descriptions are changed, but the namespace could stay the same whennew operations are added.With a compatible change the service need only support the latest version of a service. A client may continue touse a service adjusting to new version of the interface description at a time of its choosing. With anincompatible change, the client receives a new version of the interface description and is expected to adjust tothe new interface before old interface is terminated. Either the service will need to continue to support bothversions of the interface during the hand over period, or the service and the clients are coordinated to changeat the same time. An alternative is for the client to continue until it encounters an error, at which point it usesthe new version of the interface. There is currently not a standardized or recommended approach, but rather aset of best practices.The current FIMS specification recommends the following guidelines, based on current best practices and[REF1]:• Interface documents and schemas shall have a version with a major and minor number.• A compatible change shall be at least backward compatible.• If a change is compatible, the minor number of the version shall change. If a change is incompatible,the major number of the version shall change.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 15 of 89

FIMS Media SOA Framework Phase1 (Preliminary)The service registry should support the service update lifecycle by allowing specifying the version for eachimported service interface documents and schemas [see 6.2.3].6.1.4.2 New service implementationIn this scenario there is no change in the version of the interface, but the service is replaced with a differentimplementation where some of the features (operations) are implemented or more features (operations) areimplemented. In the latter case, the service is backward compatible. In the former case, there is the issue ofmaking the framework aware that the service is not implementing some features. The current FIMSspecification recommends the following guidelines:• Service description metadata for each service implementation shall bind service operations withproperties (e.g. transcode operation shall bind with a list of supported formats).• Only available operations shall have bindings in the service metadata.• Services are invoked through mediation in the ESB. The mediation is responsible of performing a lookupin the service registry to find the service instance(s) that implement the requested operation.• If no instance with the required operation is found, the mediation shall throw a fault (e.g. service withrequested feature not found)[REF1] Web Services Description Language (WSDL) Version 2.0 Part 0: Primer - W3C Recommendation 26 June2007. Available at http://www.w3.org/TR/wsdl20-primer.6.2 Service behaviorThis section addresses the service behavior that is common to all categories of services. Behavior specific toeach service category will be discussed when describing the service interfaces.6.2.1 Operation Implementation patternsService operations defined by FIMS interfaces provide different types of interactions between the serviceprovider and the service requester. Each one specifies how the result of an operation is made available to therequester. The interface definition along with the input parameters of the operation determines how the serviceshould return the response of the operation.6.2.1.1 Synchronous Request/ResponseIn this interaction mode the service client (e.g. a business process) invokes the service to perform an operationpassing the input parameters (par1, … parN) and receives the response in the same communication session asthe request. Operations that implement this mode of interaction should not be long-running processes to avoidblocking the service client for a long period of time and to prevent timeouts that may occur in thecommunication session.Examples of operations that use this type of interaction are the job and queue management operations.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 16 of 89

FIMS Media SOA Framework Phase1 (Preliminary)6.2.1.2 Asynchronous Request/Response with NotificationThis interaction pattern should be used for long running processes. The request and response associated to theoperation are exchanged in two different communication sessions. The request session includes the invocationby the client of an operation passing the input parameters (par1, … parN, jobGUID, notifyAt) and theacknowledgement by the service that the request was received.The jobGUID parameter identifies uniquely the job request from the business process (the service client) pointof view. The notifyAt parameter specifies to the service provider where to send the response message when theoperation execution completes. It also specifies where to send an error notification message if the service failsduring its execution.A separate communication session is used to send the response message to the address specified by thereplyTo element of the notifyAt parameter. If an error occurs during the process of the operation an errornotification should be issued to the endpoint specified by the faultTo element of the notifyAt parameter.An example of operation that employs this interaction mode is the transcode operation of the TransformMediaservice.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 17 of 89

FIMS Media SOA Framework Phase1 (Preliminary)6.2.1.3 Asynchronous Request/Response with PollingThis is another interaction pattern for long running processes. It is similar to the previous interaction mode withthe exception that a notification is not sent by the service when the service completes the operation. ThenotifyAt parameter should not be provided for the service to operate in this mode.When the client issues the request it receives an acknowledgement message that contains the ID of the job asidentified by the service.In this mode of interaction, it is the responsibility of the client to poll the service to retrieve the result of theoperation when it is completed. Using the jobID parameter (that is part of the acknowledgment message) theclient may poll the service to retrieve the status of the requested job. Once the job completes its execution theresponse message for the status request brings back the result of the operation.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 18 of 89

FIMS Media SOA Framework Phase1 (Preliminary)A transcode operation of the TransformMedia may be implemented using this type of interaction.6.2.2 Input and Output MediaMedia services often deals with media files. These services may consume and/or produce files that representmedia essences. References to these media files are passed in the input and output messages for theseservices.6.2.2.1 Processing the Input MediaThere are operations that require only a media essence (or list of essence), like transcoding a media. In thiscase the service receives a list of content objects (of type BMBaseContentType) that represents the mediaessence(s) the service should operate on.Other operations may require in addition the structural organization of the essence (or list of essence) withfolders and its relationship to the essence, like adding a complex asset into a repository. For these operationsthe service receives not only the list of content objects but also an object that represents this structure.6.2.2.2 Producing the output contentServices like TransformMedia produces a media essence (or a list of media essence). These services return a listof content objects (of type BMBaseContentType). It also shall return a mapping object that represents therelationship between the input content and the output content. This mapping information may be used byexternal services to keep track of the genealogy and utilization of each media essence.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 19 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Other operations, like retrieving a complex asset from a repository, may return not only the essence (or list ofessences) but a structural organization of this essence with folders and their relationship with the essence.6.2.3 Error and exception handlingErrors and exceptions detected by the service during the execution of job requests should be informed to theservice requester. For synchronous operations as described in 6.2.1.1 a fault message should be returned as aresponse to the request.The fault message contains detailed information about the error.The FIMS framework defines the enumeration of error codes and their description for each one of the servicecategories. A number of errors are common to all service categories and are presented in 8.2.2.4.1.2.For asynchronous operation as defined in 6.2.1.2 and 6.2.1.3 errors may occur in two distinct phases. An erroror exception may be thrown at the request time (e.g. Invalid Request Parameters) and a fault message shall bereturned immediately as a response to the request. The behavior is similar to the synchronous scenario.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 20 of 89

FIMS Media SOA Framework Phase1 (Preliminary)If an error is detected during the execution of a long-running process (e.g. Job Ended with Failure) and thefaultTo parameter has been set in the request message, then an error notification message shall be sent to thedestination specified by faultTo.The client may also retrieve the status of the failed operation by polling the service. The service shall provide aresponse message with the status indicating the operation failed and the associated fault information.6.2.4 Failure RecoveryA service failure during the execution of a workflow should be a recoverable process. The framework allows forthe retry of the failed service since in many cases the cause of the failure can be easily fixed by humanintervention. In this scenario the workflow is paused at the invocation of the failed service and can be restartedmanually after the service is fixed.The framework also allows for the definition of a compensation mechanism in the workflow to rollback to a welldefined condition when the failure cannot be recovered by a simple retry mechanism.6.2.5 Job QueueA service may implement a queue to support multiple simultaneous requests. If implemented, job requests arefirst en-queued in the order of priority and arrival. The service de-queue the jobs and processes them one byone. Multiple jobs can be de-queued at once if the service supports the execution of multiple simultaneous jobs(multi-threading).The figure below shows the states associated to the job queue and the transitions initiated by the queuecommands issued to the service. The states are associated to the processes that en-queue (accepts new jobs)and de-queue (starts execution of an en-queued job) requests. The Started state means that both the enqueuingand de-queuing processes are active. Locked means jobs cannot be en-queued but they are still beingde-queued. Stopped means jobs are not being either en-queued or de-queued.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 21 of 89

FIMS Media SOA Framework Phase1 (Preliminary)The service shall implement the manageQueue operation to process queue commands. In case the service doesimplement a queue it shall respond with “Feature Not Supported” error code.A job queue may have a maximum size and when it is reached no more jobs will be accepted. A fault indicatingthe queue is full shall be thrown by the service when a client issues a new job request.6.2.6 Job Execution PriorityThe service should execute requests in the order of priority. The priority of a job is indicated in the requestmessage. Higher priority jobs take precedence over lower priority jobs. If needed (and supported by theservice) lower priority jobs should be temporarily paused to allow for the execution of higher priorities request.The framework defines level of priority for the request. The list of possible values for priority are: "low","medium", "high", "urgent" and "immediate".- A new job with "low" priority shall be allocated at the end of the queue.- A new job with "medium" priority shall be allocated to be executed before any "low" priority job but afterexisting "medium" priority jobs.- A new job with "high" priority shall be allocated to be executed before any "medium" and "low" priority jobbut after existing "high" priority jobs.- A new job with "urgent" priority shall be allocated to be executed before any "high", "medium" and "low"priority job but after existing "urgent" priority jobs.- A new job with "immediate" priority shall be executed as soon as the job request is received.If the service supports only one job execution at a time, and the job being executed has a lower priority thanthe new submitted job, the existing job shall be paused and the job with higher priority shall be started. Thepaused job shall be resumed when there are no higher priority jobs. If the service supports only single jobexecution at a time, and the job being executed has the same priority, the new job has to wait for completionof the job currently in execution.6.2.7 Events NotificationA service may issue notifications of events associated to requested jobs (e.g. job is at 50% of completion), tothe job queue (e.g. queue is full), service (e.g. service will enter in maintenance mode in one hour) or system(e.g. system is running out of disk space). The service should emit those notifications to a broker that isPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 22 of 89

FIMS Media SOA Framework Phase1 (Preliminary)specified by a service configuration property. Clients that want to receive those notifications should register withthe broker.Events notification can be used to monitor the performance of a service, to generate alarms and to detectsituations where a manual intervention is required to guarantee a service continuous operation. They may alsobe used to gather statistics about a particular service (e.g. how long it takes to perform a particular task) thatmay be used by business processes to select the most appropriate service implementation to use.Detailed information about the different type of events and their message formats is provided in 8.3.2.1.6.2.8 Operation Profiles [to be completed]6.2.9 Operation execution deadlines [to be completed]6.3 Job management6.3.1 Lifecycle of a jobThe figure below shows the states associated to a long-running job since its request until its completion,cancellation or failure. It also shows the job commands or actions that initiates a transition to a new state.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 23 of 89

FIMS Media SOA Framework Phase1 (Preliminary)When a job request is received by a service its initial state is Queued. In this state a job may have its priority orprofile changed before starting its execution through external job management commands (if the servicesupports these features). The job may also be cancelled by an external command. Once the job is de-queuedfor execution it moves to Running state. In case the service does not implement the job queue the job goesdirectly to Running state upon the arrival of a request.The Running state indicates a job is being executed. An external command may pause the job (and resume itlater). The job can have its operational parameters modified (profile and priority) if supported by the service.The request may also be restarted or cancelled by external commands. Restarting means to start its executionfrom the beginning again. If a job executes until its completion it transitions to Completed state. If an erroroccurs during its execution it moves to Failed state. An external command may force the early termination of ajob execution. To terminate a job means to force its completion. This is not an error situation and the result ofthe job processing until that moment is considered to be the result of the job request. A job may need to betemporarily paused because of the arrival of a higher priority job. This is a service internal action (pausingmomentarily the job) and the job state should not change.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 24 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Media services often produce large media files that need to be available until the client or other services retrievethem. Once the job completes (or it is terminated) the by product of the operation shall be kept by the service.An external command (cleanup) is used to indicate to the service that they are no longer needed and the jobtransitions then to Cleaned state.The transition to Cancelled, Completed, Terminated and Failed states should produce a notification to one of theendpoints specified at the notifyAt parameter of the request message, if a notification is expected at the end ofthe job execution. Completed and Terminated should produce a response notification message to the replyToendpoint, while Cancelled and Failed should produce an error notification message addressed to the faultToendpoint.6.3.2 Management CommandsThe FIMS services interfaces provide two job management operations. They are the manageJob andListQueuedJobs operations.The manageJob operation allows a requester to send job commands to change the state of a job as describedin the previous section. In addition a client can request the status and the result of a particular job as shown in6.2.1.3.The listQueuedJobs operation returns a list with jobs that currently being executed and jobs that are waiting forexecution. The requester may opt to get only a list of jobs that are waiting for execution.The response list contains not only the identification of the jobs but some additional information such as theestimatedCompletionTime and the status of each job.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 25 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 26 of 89

FIMS Media SOA Framework Phase1 (Preliminary)7 Media Service Awareness7.1 Service registryA service registry provides support for publishing and discovery of services, acting as a central repository for allservices metadata. Furthermore, the service registry enables service virtualization, supporting selection ofservices at runtime according to static service characteristics (e.g. QoS, cost) and real-time performance data(e.g. CPU utilization, disk space, queue length). Service requestors submit semantic queries to the serviceregistry to locate services with the required processing capabilities (e.g. finding a transcoder for video content)and media format support (e.g. the transcoder should support DV25 in input and MPEG-4 on the output). Theservice registry establishes a central point for finding and managing service metadata. Part of the metadatamay constitute policies or SLAs that constrain and drive different aspects of SOA. For example, a user maydefine security policies and relate them to the services that are defined in the service registry. Another examplewould be to describe Service Level Agreements (SLA) and bind them to service providers and consumers as partof the overall service information model managed by the registry.This FIMS specification does not address the service registry implementation, which may be vendor-specific.This document rather focuses on key concepts and features that should be available to the framework.A service registry should support the following features:• Find: Search/browse for services with varying degrees of criteria driven by any metadata associatedwith the service• Publish: Add new services through an approval process to be available and managed in an enterprisewidescale• Subscribe: Register to listen to any changes to the metadata associated with the services• Manage lifecycle: Provide customizable processes to manage the lifecycle of services in the registryenabling access control, promote/retire and analyze changes to services through impact analysesA service registry enables searching service information, supporting reuse of common services. A commonexample of service information gathered or searched in these phases would be documents conforming to theWeb Services Description Language (WSDL) or XML Schema Definition (XSD) standards. Architects anddevelopers can also annotate this technical information in the registry and repository with extra informationusing formal classification techniques, such as using the Web Ontology Language (OWL) standard [REF2], or byadding other content defined following XSD standards. Such classification of services allows for meaningfulgroupings of the services based on business objectives.The implementers of a service registry must consider the scope with which the registry will be implemented. Forexample, there are public service registries available over the Internet to an unrestricted audience, as well asprivate service registries that are only accessible to users within a company-wide intranet. A service registryprovides the infrastructure mechanism to discover a service; however, a service provider has to provide theappropriate information to make the service discoverable. In addition to content directly related to servicedescription entities (e.g. WSDL), a service registry should support a number of user-defined metadata typesthat are used to decorate the service description entities to explain their semantics; we refer to those metadataas service description metadata. There are three types of service description metadata types:• Properties are name/value pairs that are associated with any of the service description entities. Someproperties are assigned by the system, such as the unique id, the owner, and the last time the serviceentity was changed. These system-assigned properties cannot be changed. Others are derived throughthe parsing of a key-type service description document into its logical model. Properties of this typeinclude name and namespace. Properties can be used in queries during the service discovery process.• Relationships describe the dependencies between entities of the standards-based service definitiondocuments such as WSDLs and schemas. Relationships can be used to attach rich semanticsdescriptions such RDF documents to services document entities.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 27 of 89

FIMS Media SOA Framework Phase1 (Preliminary)• Classifications provide means of classifying service artifact descriptions. Each classification systemrepresents a different way of organizing services and is represented as a hierarchy of classificationssimilar to a library indexing system. Classification systems can be loaded into the service registry wherethey can then be used to apply semantic meaning to Service description entities. Classification systemsare documents encoded using the Web Ontology Language (OWL) [2]. OWL classes are used asclassifiers and the subTypeOf relationship between these classes is used to establish a classificationhierarchy. OWL classes and relationships support the definition of ontologies to describe the mediaservices domain and taxonomies.Finally, a service registry shall enable resources management by supporting the collection of information onresource availability for different instances. Resource availability information can then be used by the dynamicselection mediation (resource management) to make service selections based on resource availability.7.1.1 Registering a serviceTo be discoverable, a service needs to be registered with the framework. The key scenario addressed in thisdocument is the one where different FIMS-compliant service implementations are provided to different FIMSframework vendors. Although the registration process might be vendor-specific, the information provided witheach service to enable the registration is part of the FIMS specification. The information to be provided for theregistration process is the following:• Interface Entities (e.g. port types, operations, namespaces).• Service Description Metadata (Properties, Relationships, Classifications)• Service endpoint information• Policies• SLA contractsThe service description metadata includes the following information:• Service name and description• Service Classification• Supported file transfer protocols for media content in input and output (e.g. file, ftp, http)• User defined-properties (name-value pairs)• Data Mover agent properties (target folder location for moving content to the service)• For each operation:ooList of supported media format IDs for the operation inputList of supported media format IDs for the operation output[Not all the above is needed for NAB. An example of a service description; UPnP]7.1.2 Discovering a serviceService requestors discover services and obtain binding information (in the service descriptions) for services forstatic binding (during development or configuration) or dynamic binding (during execution). Dynamicservice discovery allow a service consumer to dynamically discover a service at runtime and bind to that servicefor execution. An Enterprise Service Bus (ESB) can augment dynamic discovery. The ESB can provide a singlemanaged point of integration for the dynamic discovery and binding capability, so that a service consumer cansend a request through the ESB, which manages the dynamic discovery and binding to a service that satisfiesspecific criteria. Dynamic service discovery can be implemented with a service selector (router) pattern. In thispattern, a service consumer sends a request to an intermediary (the ESB), which provides the dynamicdiscovery and binding of the service according to one or a combination of the following options:Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 28 of 89

FIMS Media SOA Framework Phase1 (Preliminary)• Simple service discovery: a static service discovery query is configured in the ESB, providing simpleinformation such as the service classification (e.g. find a transcoder)• Message context-based discovery: some information inside the service request can be used to select aspecific service instance. For example, information in the message on the input media format andexpected output format can be used to select a particular transcoder instance.• SLA-based endpoint discovery: Service Level Agreement information is used to match a request to aservice provider that can provide the requested level of service. (SLA documents are maintained in theservice registry).• Resource utilization-based discovery: service resources (e.g. CPU, storage, and network) utilization datais used to dynamically discover and bind to a service according to specified policies or rules (e.g. selectthe service with the lowest CPU utilization or the shortest job queue).7.1.2.1 Context-specific discoveryWe first define what we mean by context adopting the definition from [REF1]: “Context is any information thatcan be used to characterize the situation of an entity. An entity is a person, place, or object that is consideredrelevant to the interaction between a user and an application, including the user and applications themselves.”Context-aware systems look at the who’s, where’s, when’s and what’s (that is, what the user is doing) ofentities and use this information to determine why the situation is occurring and take some action, such asselecting a particular service instance to perform a business task. According to [REF1] there are certain types ofcontext that are, in practice, more important than others. These are location, identity, activity (or usage) andtime. For the scope of this document, we consider only the first three types.Location• Needs defining of the entity for which the location applies – e.g. service consumer location or mediacontent location?IdentityUsage• Needs defining of the entity for which the identity applies – e.g. user identity? or media contentidentity?• Needs defining of the entity for which the usage applies – e.g. operation on media content ?REF1. Anind K. Dey and Gregory D. Abowd “Towards a Better Understanding of Context and Context-Awareness”. Available at ftp://ftp.cc.gatech.edu/pub/gvu/tr/1999/99-22.pdf.REF2. Web Ontology Language (OWL) W3C standard. Available at http://www.w3.org/2004/OWL/Should services be self-describing? DISCUSS resource managementNB: The concept of service registry may be vendor specificPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 29 of 89

FIMS Media SOA Framework Phase1 (Preliminary)7.1.3 Service taxonomyEach service may be classified into one two categories: (1) workflow services able to realize a given businessgoal, (2) infrastructure services that are essential components of the Media SOA system.Infrastructure services that are used to construct the Media SOA system are called Media Infrastructure (MI)services. The MI services include Resource Manager that conducts the resource allocation, as well as othercommon services like job scheduling and queuing. The details of the Resource Manager are described in Section9.2.3.Depending on the type of business workflow, the workflow services by themselves may vary, and for thegeneric AV post-production process will include Capture, Transform, Transfer, Edit, Publish, and so on.Although Capture, Transform and Transfer are the services included in the FIMS Phase 1 specification, Table1and Table 2 show examples of both Media Workflow and Media Infrastructure Service Classes/Taxonomy.Media Workflow Service Classes / TaxonomyClassServices [more description to be added]CaptureTransformTransferEditPublishColor CorrectionQCIngest VideoSource device controlMetadata generationFile importTransformRewrap (wrap/unwrap)Encode/DecodeCrop/Resize/Burn-inImport/ExportTransferPicture/Sound Editing/MixingPicture/Sound EffectsComputer GraphicsApprovalDevice ControlPlay-out OperationPlay-list EditingAV SyncSecurityColor CorrectionColor GradingLUT ManagementConformManual QCAutomatic QCConformTrafficPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 30 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Table 1 Example of Media Workflow Service Classes/TaxonomyInfrastructure Service Classes / TaxonomyClassServices [more description to be added]Resource ManagementFile ServicesStorage ManagementUtilityScheduleManagementMetadata ManagementArchive ManagementAsset/Repository ManagementInternal file copyDeleteDirectory listSpace availableStorage Mapping/AbstractionChecksumResource SchedulerPriority QueueMetadata ExtractionMetadata ExportMetadata MappingHSM Migration/RestoreArchiveBackupAddPreviewSearchCatalogingTable 2 Example of Infrastructure Service Classes/TaxonomyPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 31 of 89

FIMS Media SOA Framework Phase1 (Preliminary)7.2 Service-level agreements **FURTHER DISCUSSION NEEDED about how toconstrain what needs to be defined** how this applies to scheduling resourcesand jobs[The following sections are not needed for the preliminary specification for NAB20117.2.1 Policy ontology and schema7.2.1.1 Cost7.2.1.2 Availability7.2.1.3 QoS7.2.1.4 Deadlines7.2.1.5 Format support7.2.1.6 Resources needed7.2.2 Querying SLAs7.2.3 Enabling business rules7.2.3.1 Upfront analysis7.2.4 Enforcing SLAs7.2.4.1 Infringement notification]Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 32 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8 Media Service Communication8.1 Common propertiesFIMS services share a common object model, which serves two main purposes:• Promote interoperability of data objects between different classes of services;• Promote code reuse. Code libraries that manipulates shared data objects can be reused by differentclasses of services.The FIMS object model is described by a set of XML schemas, which provide the object model representationfor common objects and extensions for the different classes of service. Describing the object model as an XMLschema has the advantage of providing a binding-independent representation. The following sections do notdescribe a specific binding (such as SOAP/HTTP or REST) but rather focus on the types used to construct thejob request and response messages. This approach has the advantage of describing the structure and thesemantic of messages without placing specific binding constraints.8.1.1 Schema DesignEach FIMS service extends the base object types defined in the base schema. These base types model jobrequests and responses for long running, asynchronous operations and provide support for job and queuemanagement tasks. The base schema provides the following key types:• BaseRequestType: a type representing a job request.• BaseResponseType: a type representing a job response.• Business Media Object Types: a set of types providing a reference to media content and metadata.• MediaRequestType: extends the BaseRequestType to model a request that submits media content toa job.• MediaResponseType: extends the BaseResponseType to model a response from a job that returnsmedia content.• FaultType: a type representing the base fault, to be extended by each service class for providingservice-specific faults.• ManageJobRequestType: a type representing a job management request, such as pausing orterminating a job.• ManageJobResponseType: a type representing a response to a job management request.• ManageQueueRequestType: a type representing a queue management request, such as stopping orrestarting a queue.• ManageQueueResponseType: a type representing a response to a queue management request.• ListQueueRequestType: a type representing a request to list queued jobs.• ListQueueResponseType: a type representing a response to the list queue request.• MediaServiceEventType: a type representing an event generated from a FIMS service, such as a jobevent, queue event, system event or service event.8.1.2 Message Format and PatternsThe pattern adopted for message formats is based on the Command Message pattern. Messages use the typesdefined in the base schema or extended types. The base types used for messages are described in the followingsections.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 33 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.1.2.1 BaseRequestTypeThe BaseRequestType contains the common elements that are inherited by all service interfaces executing jobrequests. Specific job request types (such as transfer job request or transform content request) shall use orextend this data type or the MediaRequestType.8.1.2.1.1 ParametersParameter Type DescriptionPriority PriorityType Sets the job priority. It can be set to "low", "medium","high", "urgent" or "immediate".jobGUID xsd:string A globally unique identifier (GUID) for the job request.The invoked service can generate its own local job ID, butit must be able to persist the relationship between theprovided job GUID and the local job ID. The job GUIDprovides a mechanism for the FIMS framework to uniquelyidentify jobs at the global level.notifyAt AsyncEndpointType An optional element used to specify the endpoints where aservice can send back a notification for a job completed orfailed. If this element is set, the service must send anotification to the address indicated in the replyTo field forsuccessful completion and a notification to the addressindicated in the faultTo field for failure. If this element isnot set, the service should not send notifications to therequestor.8.1.2.1.2 Related Types8.1.2.1.2.1 PriorityTypeProvides the list of possible values for priority: "low", "medium", "high", "urgent" and "immediate".- A new job with "low" priority shall be allocated at the end of the queue.- A new job with "medium" priority shall be allocated to be executed before any "low" priority job but afterexisting "medium" priority jobs.- A new job with "high" priority shall be allocated to be executed before any "medium" and "low" priority jobbut after existing "high" priority jobs.- A new job with "urgent" priority shall be allocated to be executed before any "high", "medium" and "low"priority job but after existing "urgent" priority jobs.- A new job with "immediate" priority shall be executed as soon as the job request is received.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 34 of 89

FIMS Media SOA Framework Phase1 (Preliminary)If the service supports only one job execution at a time, and the job being executed has a lower priority thanthe new submitted job, the existing job shall be paused and the job with higher priority shall be started. Thepaused job shall be resumed when there there are no higher priority job. If the service supports only single jobexecution at a time, and the job being executed has the same priority, the new job has to wait for completionof the job currently in execution.8.1.2.1.2.2 AsyncEndpointTypeA type used to provide the replyTo and faultTo endpoints where a service can send back a notification for a jobcompleted or failed.8.1.2.1.2.2.1 ParametersParameter Type DescriptionreplyTo EndpointReferenceType Specifies the endpoint where the service shall send thenotification indicating the completion of a job. It uses theWS-Addressing EndpointReferenceType for setting theendpoint address. The endpoint shall be set in the Addressfield of the EndpointReferenceType.faultTo EndpointReferenceType Specifies the endpoint where the service shall send thefault notification indicating the failure of a job. It uses theWS-Addressing EndpointReferenceType for setting theendpoint address. The endpoint shall be set in the Addressfield of the EndpointReferenceType. Based on the invokingclient or business process, the endpoint for faultTo can bethe same as the replyTo or it can be different.8.1.2.2 BaseResponseTypeThe BaseResponseType contains the common elements that are inherited by all service interfaces providingresponses on the execution of jobs. Specific job response types shall extend or use this type as needed.8.1.2.2.1 ParametersParameter Type DescriptionoperationInfo OperationInfoType Provides information on the operation associated with ajob request, such as name of the operation, local job IDand current status of the job (e.g. started).serviceProviderInfo ServiceProviderInfoType Provides information of the service provider servicing therequest. It includes an optional name for the provider andthe provider endpoint, which uniquely identifies thePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 35 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.1.2.2.2 Related Types8.1.2.2.2.1 OperationInfoTypeprovider.Provides info on an operation associated with a job. It is provided in a job request response or in job statusqueries responses.8.1.2.2.2.1.1 ParametersParameter Type DescriptionoperationName xsd:string Provides the name of the operation associated with a job.It is provided in a job request response or in job statusqueries responses.jobID JobIDType Provides the global job ID and the local job ID using theJobIDType.Status JobStatusType The status for the job request. The job status code isspecified in detail in the JobStatusType.8.1.2.2.2.2 JobStatusCodeTypeProvides the list of possible job status codes. The status code shall be set to one of the following values:- queued: the job is in the queue and is ready to start.- running: the job has started successfully and is currently running.- paused: the job has been paused.- completed: the job has completed successfully.- canceled: the job has been canceled.- terminated: the job has been terminated. A partial result might be retrieved.- failed: the job has ended with an error.- cleaned: a cleanup command was issued for the job. All data related to the job has been removed.8.1.2.3 MediaRequestTypeThe MediaRequestType contains the common elements that are inherited by all service interfaces executing jobrequests on media content essence. It extends the BaseRequestType with a list of bmContent objects. Specificjob request types operating on content (such as transfer job request or transform content request) shall use orextend this data type.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 36 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.1.2.3.1 ParametersParameter Type DescriptionbmContent[1..*]BMBaseContentTypeProvides business-level information on the media contentexchanged by FIMS services (such as location of themedia, format and size).8.1.2.4 MediaResponseTypeThe MediaResponseType contains the common elements that are inherited by all service interfaces providingthe result of a job request, which produce content essence(s). It extends the BaseResponseType with a list ofbusiness media objects. Specific job results types providing in output media content shall use or extend thisdata type.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 37 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.1.2.4.1 ParametersParameter Type DescriptionbmContent[1..*]BMBaseContentTypeProvides business-level information on the media contentexchanged by FIMS services (such as location of themedia, format and size).bmResultMap BMResultMapType This element provides the relationship between thecontent components in input to a job and the contentcomponent in output from the job. The framework canexploit this information to track media content as it movesalong a business process.8.1.2.4.2 Related Types8.1.2.4.2.1 BMResultMapTypeThis type provides the relationship between the content components in input to a job and the contentcomponent in output from the job. It uses a choice of two elements (oneToMany and manyToOne). If theoperation produces a single content in output from multiple contents in input, use the oneToMany element. Ifthe operation produces multiple contents in output from a single in input, use the manyToOne element. Eachelement can be replicated multiple times, to indicate for example multiple sets produced by multiple inputcontent items. The IDs to be set for sources and targets are the attribute IDs and the URIs defined in eachreferenced object.8.1.2.4.2.1.1 ParametersParameter Type DescriptiononeToMany[1..*]manyToOne[1..*]MapOneToManyTypeMapManyToOneTypeUse this choice element to express the relationshipbetween one input and multiple outputs. You can havemultiple instances of this element, but you cannotcombine this element with the manyToOne element.Use this choice element to express the relationshipbetween multiple inputs and a single output. You can havemultiple instances of this element, but you cannotcombine this element with the oneToMany element.8.1.2.5 StructuredMediaRequestTypeThis type contains the common elements that are inherited by all service interfaces executing job requests onstructured media content essences, such as assets retrieved from a repository. It extends theMediaRequestType with the BMO element. Specific job request types operating on structured content (such ascontent repositories) must use or extend this data type.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 38 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.1.2.5.1 ParametersParameter Type DescriptionBmo BMObjectType Provides business-level information on the structuredmedia content exchanged by FIMS services.8.1.2.6 StructuredMediaResponseTypeThis type contains the common elements that are inherited by all service interfaces providing the result of a jobrequest as structured media content, which produce content essence(s). It extends the MediaResponseTypewith the BMO element. Specific job request types operating on structured content (such as content repositories)must use or extend this data type.8.1.2.6.1 ParametersParameter Type DescriptionBmo BMObjectType Provides business-level information on the structuredmedia content exchanged by FIMS services.8.1.3 Transactional Management• The framework may implement error handling or compensation to undo or rollback the effect of certainactions.8.1.3.1 Rollback• Needs to clarify what we mean by rollback – does it mean that some operations might alter the mediastate so that it needs to be rolled back to a previous state? (example: transfer operation that transfer afile and then removes the copy at the original location, or transcode operation that transcode a contentand removes original format – perhaps rollback would have some meaning here, but is this type ofbehavior what we are trying to achieve?)8.2 Service Provider InterfaceEach service class provides a service provider interface, which extends the types defined in the base schema.This section provides a description of the object model used to describe the interface of each service.8.2.1 Operations8.2.1.1 File Transfer InterfaceA transfer media service allows copying, moving, or accessing media files over local and/or wide area IPnetworks.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 39 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.1.1.1 TransferRequestTypeThis type represents a request to the transfer media service for transferring content from a source to a target.8.2.1.1.1.1 ParametersThis type inherits all the elements from the MediaRequestType. The table below details the additional elementsfor this type. However, it is important to notice that the bmContent element from the parent MediaRequestTypeprovides the location information for the source file or files to be transferred.Parameter Type DescriptiondestinationURI xsd:anyURI This element specifies the destination path forthe target. The URL field shall follow thestandard structure for a URL as defined inRFC1738 - Uniform Resource Locators (URL). Incase of a file protocol scheme, the host field shallexplicitly be included in the URL. The URL coversdifferent protocol scheme, such as NFS mountsRFC2224, which definesnfs://:/.../,and the internet draft for the smb: scheme forCIFS, with the restriction that only the path andnot the file name shall be provided.transferProfile BaseProfileType This element represents the profile used by thetransfer media service to transfer files. Theprofile provides a mechanism to specify servicespecificinformation for each service provider.The FIMS framework does not require havingvisibility of the actual content of the profile. Theprofile might be used to specify network resourceutilization, a list of acceptable transfermechanisms or additional security optionsincluding whether the received files should bechecked against a fingerprint and whether theyare encrypted.timeConstraints TimeConstraintsType An optional element to indicate the timeconstraints for running the job. It provides theoption to start the data transfer according totime-based criteria or external triggers.8.2.1.1.1.2 Related TypesPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 40 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.1.1.1.2.1 BaseProfileTypeThis type represents a profile used by a FIMS media service to perform a job on media content For example, itmay represent the profile of a transfer media service for transferring media content, and as such may specifythe media format to be produced in output. The profile provides a mechanism to specify service providerspecificinformation for each operation. The profile can be provided as an ID reference to a document availableto the service provider (using the ID field of the profile) or as URL to a profile document available through thenetwork, or can be embedded as document in this type, using the any type element.8.2.1.1.1.2.1.1 ParametersParameter Type DescriptionId UID The ID of the profile.Any xsd:any An optional choice element for providing theprofile as document embedded in this type.See comment for the ref element.Ref xsd:anyURI An optional URL reference to the profile,which might be used to retrieve the profileobject. This element is a choice: if theprofile document is provided it can beprovided either as a reference or in the anycontainer.8.2.1.1.1.2.2 TimeConstraintsTypeThis type provides the mechanism to describe different ways of starting a service job based on time or externaltrigger information, or completing a job by a deadline. Only one choice of the specified time element can beselected. If a start time is selected, the deadline cannot be selected because it would be difficult for the serviceto accomplish the deadline if not feasible. On the other hand, if a deadline is specified, the service can selectthe most appropriate start time internally to accomplish the deadline, so the start time cannot be specified.8.2.1.1.1.2.2.1 ParametersParameter Type DescriptionstartTime TimePointType This choice element specifies the start timefor a job execution, using theTimePointType.endBy xsd:dateTime A choice element used to specify therequested time for completion of a job. Ifselected, the service shall attempt tocomplete the job in the specified timeframe.If the specified deadline cannot be met, theservice shall send a notification message tothe framework to indicate that the deadlinePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 41 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.1.1.1.2.3 TimePointTypecannot be achieved. A service may notsupport this feature. If so, it has to respondwith a fault to the job request. The faultshall have a “feature not supported” codeset.This type provides time or timecode information on when to perform a task (e.g. starting or stopping a filetransfer or a video capture).8.2.1.1.1.2.3.1 ParametersParameter Type DescriptionTime xsd:dateTime If this choice element is set the job shallstart by the specified time. Provides dateand time info with format defined byxsd:dateTime (YYYY-MM-DDThh:mm:ss[.sss][zzzzzz]).timeCode TimeCodeType If this choice element is set the job shallstart by the specified time code. Providesdate and time info with format defined byhh:mm:ss:ff" (ff = frame number).External xsd:Boolean If this choice element is set the service shallwait for an external trigger signal to startthe job. The actual trigger depends on theservice implementation. This field can onlybe set to true.noWait xsd:Boolean If this choice element is set the job shallstart without waiting for a specific time orevent. This field can only be set to true.8.2.1.1.2 Transfer Request AcknowledgementWhen a job is submitted to the transfer media service, the service shall reply with an acknowledgement. Theacknowledgement message uses the BaseResponseType described in the base schema.8.2.1.1.3 TransferFaultTypeThis type provides the fault information for the transfer media service. It extends the base FaultType, and addsan extended code which allows to set adapter-specific error codes if needed. If an exception is generated whenthe transfer request message is submitted to the adapter, the adapter shall respond with a message based onthe TransferFaultType.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 42 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Specific error codes for the transfer media service are enumerated in TransferErrorCodeType, such as:- DATA0220: Invalid URI protocol specified for transport operations.- DATA0221: Invalid Output Directory or Target URI path8.2.1.1.4 Transfer NotificationIf the notifyAt element is set in the job transfer request, then the service shall respond with a notification to thespecified endpoint when the job completes. The transfer notification message uses the MediaResponseTypedescribed in the base schema.8.2.1.1.5 TransferFaultNotificationTypeThis type provides fault information for the transfer service fault notification. It extends the base response type,since the base response type provides information on the invoked job and operation, which allow correlating thenotification with the original asynchronous request. Fault information is provided with the TransferFaultType. Ifthe notifyAt element is set in the job transfer request, and a failure occurs during the job execution, then theservice shall respond with a transfer fault notification to the specified endpoint.8.2.1.2 File Transform InterfaceA transform media service operates on media content to transform the content or a list of content elementsfrom a source media format to a target or a list of target media formats.8.2.1.2.1 TranscodeRequestTypeThis type represents a request to the transform media service for transcoding content from a source format to atarget format. This type inherits all the elements from the MediaRequestType. The parameters section detailsthe additional elements for this type. However, it is important to notice that the bmContent element from theparent MediaRequestType provides the location information for the source file or files to be transcoded.8.2.1.2.1.1 ParametersPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 43 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Parameter Type DescriptionoutputFileName xsd:string This optional element allows specifyingthe name of the file to be produced inoutput. It can be specified only if thetranscode operation creates a single filein output. If this element is not specified,the transcode operation should use thename of the input file(s) (provided in thebmContent) to produce an output filename (or file names).transcodeProfile[1..*]TransformProfileIDTypeThis element represents the profile usedby the transform media service totranscode files. The profile provides amechanism to specify service-specificinformation for each service provider.timeConstraints TimeConstraintsType An optional element to indicate the timeor a deadline for running the job. Itprovides the option to start thetranscoding operation according to timebasedcriteria or external triggers.wrapperMetadata[0..*]MetadataTagTypeAn optional set of elements for wrappermetadata. These elements may containuser metadata such as: program name,description, content, location, scenenumber, rating, etc.8.2.1.2.1.2 Related Types8.2.1.2.1.2.1 TransformProfileTypeThis type represents the profile used by the transform media service to perform a transformation on mediacontent. The profile specifies what media format(s) should be produced in output and may specify how it isproduced. The FIMS framework does not require having visibility of the actual content of the profile, which canbe service provider specific. The only requirement for the profile is to have a reference to the ID of theformat(s) it produces as result of the transcode operation.8.2.1.2.1.2.1.1 ParametersParameter Type DescriptionformatID[1..*]FormatRefTypeThe format ID(s) associated with thisprofile. It might be the same as the mediaprofile ID, but not necessarily, since thereis in general a n to 1 relationship betweena profile and the media format(s) itproduces (meaning that there are manydifferent ways to create the same format).Providing the format ID in the mediaprofile allows the FIMS framework to beaware of which profiles can produce thePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 44 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.1.2.1.2.2 MetadataTagTyperequired format and make intelligentdecision on the choice of a suitableprovider for a media-processing job. Itshould be noted that the profile mightcarry (in the “any” container) serviceproviderspecific information to map eachspecified format ID to the service providerspecific format definitions.A metadata tag type provides a simple tag/value pair for simple metadata tagging.8.2.1.2.2 Transcode Request AcknowledgementWhen a job is submitted to the transform media service, the service shall reply with an acknowledgement. Theacknowledgement message uses the BaseResponseType described in the base schema.8.2.1.2.3 TransformFaultTypeThis type provides the fault information for the transform media service. It extends the base FaultType, andadds an extended code which allows to set adapter-specific error codes if needed. If an exception is generatedwhen the transform request message is submitted to the adapter, the adapter shall respond with a messagebased on the TransformFaultType.Specific error codes for the transform media service are enumerated in TransformErrorCodeType such as:- DATA0101: Invalid target media format8.2.1.2.4 TranscodeNotificationTypeIf the notifyAt element is set in the job transcode request, then the service shall respond with a notification tothe specified endpoint when the job completes. The transcode notification message uses theTranscodeNotificationType, which extends the MediaResponseType described in the base schema.The optional autoQCStatus element provides status information for a transform media service that supportautomatic QC of the transformed content. The status values enumerated in AutoQCStatusCodeType are thefollowing:- passed: the QC was completed with successPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 45 of 89

FIMS Media SOA Framework Phase1 (Preliminary)- warning: the QC passed but there were warnings issued- failed: the QC was not passed. Errors were found.8.2.1.2.5 TransformFaultNotificationTypeThis type provides fault information for the transform service fault notification. It extends the base responsetype, since the base response type provides information on the invoked job and operation, which allowcorrelating the notification with the original asynchronous request. Fault information is provided with theTransformFaultType. If the notifyAt element is set in the job transform request, and a failure occurs during thejob execution, then the service shall respond with a transform fault notification to the specified endpoint.8.2.1.3 File Capture InterfaceThe capture media service creates one or more related content items from video and audio sources. The servicemay involve a human operator to start and stop the operation.8.2.1.3.1 CaptureRequestTypeThis type represents a request to the capture media service for capturing content from a variety of sources.This type inherits all the elements from the BaseRequestType. The parameters section details the additionalelements for this type.8.2.1.3.1.1 ParametersParameter Type DescriptionPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 46 of 89

FIMS Media SOA Framework Phase1 (Preliminary)sourceID xsd:anyURI The ID of the source (e.g. device ID forthe VTR, Input port etc.). This parameteris optional, since it is possible to specifyonly the type of the source with thesourceType and have the service allocatethe actual source ID, which is returnedlater on by the service. However, ifsourceType is set, for example, to "file",this parameter shall specify the locationand the name of the file, using thestandard URL syntax, defined accordingto RFC1738 - Uniform Resource Locators(URL).sourceType SourceType The type of the source, specified by theSourceType type (vtr, feed, file, cd, dvd,others).Clips[1..*]ClipTypeClips define the different segments to becaptured from the source.captureMediaProfile CaptureProfileType This element represents the profile usedby the capture media service to capturefiles. The profile provides a mechanismto specify service-specific information foreach service provider.wrapperMetadata[0..*]MetadataTagTypeAn optional set of elements for wrappermetadata. These elements may containuser metadata such as: programmename, description, content, location,scene number, rating, etc.8.2.1.3.1.2 Related Types8.2.1.3.1.2.1 ClipTypeThe ClipType represents a segment to be captured from the source. It provides information on how to startand stop the capture for each segment and optional metadata to associate with each clip.8.2.1.3.1.2.1.1 ParametersParameter Type DescriptionstartPoint TimePointType This element defines the clip capturestarting point. The start point can betriggered by time, time code or anexternal trigger.stopPoint TimePointType This choice element defines the clipcapture stop point. The criteria forstopping can be defined as a stop point oras a duration (in time or frames) - seealso duration. The stop point can bePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 47 of 89

FIMS Media SOA Framework Phase1 (Preliminary)triggered by time, time code or anexternal trigger.Duration DurationType This choice element defines the clipduration in time or in number of frames.It can be used in alternative to the stoppoint. In this case, the client can specifythe startPoint and the duration insteadthen the start and the stop point.wrapperMetadata[0..*]MetadataTagTypeAn optional set of elements for clip-levelwrapper metadata.outputFileName xsd:string An optional element to specify the nameof the file produced by the capture for theclip. If the name is not provided, theservice shall automatically generate thename for each clip.8.2.1.3.1.2.2 CaptureProfileTypeThis type represents the profile used by the capture media service to capture media content. The profilespecifies how to make the capture, what media format(s) should be produced in output and may specify how itis produced. The FIMS framework does not require having visibility of the actual content of the profile, whichcan be service provider specific. The only requirement for the profile is to have a reference to the ID of theformat(s) it produces as result of the capture operation.8.2.1.3.1.2.2.1 ParametersParameter Type DescriptionformatID[1..*]FormatRefTypeThe format ID(s) associated with thisprofile. It might be the same as the mediaprofile ID, but not necessarily, since thereis in general a n to 1 relationship betweena profile and the media format(s) itproduces (meaning that there are manydifferent ways to create the same format).Providing the format ID in the mediaprofile allows the FIMS framework to beaware of which profiles can produce therequired format and make intelligentdecision on the choice of a suitableprovider for a media-processing job. Itshould be noted that the profile mightcarry (in the “any” container) serviceproviderspecific information to map eachspecified format ID to the service providerspecific format definitions.8.2.1.3.2 Capture Request AcknowledgementWhen a job is submitted to the capture media service, the service shall reply with an acknowledgement. Theacknowledgement message uses the BaseResponseType described in the base schema.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 48 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.1.3.3 CaptureFaultTypeThis type provides the fault information for the capture media service. It extends the base FaultType, and addsan extended code which allows to set adapter-specific error codes if needed. If an exception is generated whenthe capture request message is submitted to the adapter, the adapter shall respond with a message based onthe CaptureFaultType.Specific error codes for the capture media service are enumerated in CaptureErrorCodeType, such as:- DATA0200: Invalid target media format- DATA0201: Invalid source ID8.2.1.3.4 CaptureNotificationTypeIf the notifyAt element is set in the job capture request, then the service shall respond with a notification to thespecified endpoint when the job completes. The capture notification message uses the CaptureNotificationType,which extends the MediaResponseType described in the base schema.The optional sourceID element provides the allocated device ID for the capture (VTR, Input port etc.).8.2.1.3.5 CaptureFaultNotificationTypeThis type provides fault information for the capture service fault notification. It extends the base response type,since the base response type provides information on the invoked job and operation, which allow correlating thenotification with the original asynchronous request. Fault information is provided with the CaptureFaultType. Ifthe notifyAt element is set in the job capture request, and a failure occurs during the job execution, then theservice shall respond with a capture fault notification to the specified endpoint.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 49 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.1.4 Work Order Interface8.2.2 Schema8.2.2.1 Media ReferencingFIMS media services operate on content essence. In order to describe interoperability of content essence, aunified mechanism to reference content and metadata is required. This section describes an object model thatprovides a simple mechanism to support the FIMS requirements: the Business Media Object (BMO). A BMOprovides business-level information on the media content exchanged by FIMS services (such as location of themedia, format and size). The BMO provides visibility at the business process level of the media content, thusthe term 'business' - to indicate that this is a business-level object, which does not overlap with existingstandards for the description of media and metadata, but rather provides a convenient mechanism tointeroperate transparently with such standards. The BMO can be as simple as a URL to the media content andan optional description, yet it is very flexible, since it can represent complex structural metadata and provides amechanism for transporting metadata as needed. The BMO object model provides two main components:1. A simple content model: the content model is based on the BMBaseContentType. This type provides asimple reference to the content essence file (using a URI), and a minimum set of technical metadataproperties, which can be used by the FIMS framework to make business rules driven decisions (such asselecting the best transcoder for a job based on the content format or the size of the content).2. A simple structural content model: this model is based on the BMObjectType and provides, togetherwith the BMBaseContentType, a mechanism to describe a document folder model and contentrelationships model which allow complex content services such as content repositories to interoperate.For example, this type can be used to retrieve a content asset from a repository.8.2.2.1.1 BMBaseContentTypeThis type provides a reference to the content essence. It exposes content location, content id info and somesimple properties to provide visibility of the content to the business process. Since it inherits the elements fromBMBaseObjectType, it can also expose or reference metadata descriptors. This type should be extended bycontent-specific types to model different types of content (e.g. video content, image content, audio content,document content, wrapped content).8.2.2.1.1.1 ParametersParameter Type DescriptionUri xsd:anyURI A reference to the location of the essence. The URIshall be either a URL or a unique id. A unique idPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 50 of 89

FIMS Media SOA Framework Phase1 (Preliminary)can be used for frameworks where mediareferences are stored in a media repository. In thiscase the media repository shall provide amechanism to access a reference to the physicalessence. If a URL, the URL field shall follow thestandard structure for a URL as defined in RFC1738- Uniform Resource Locators (URL). In case of a fileprotocol scheme, the host field shall explicitly beincluded in the URL. The URL covers differentprotocol scheme, such as NFS mounts RFC2224,which definesnfs://:/.../,and the internet draft for the smb: scheme forCIFS.mimeType xsd:string The mime type for the content.formatRef FormatRefType A reference to the content format ID for theessence.Size xsd:long The size of the content.dateCreated xsd:dateTime The date and time content was created (optional).dateModified xsd:dateTime The date and time content was modified (optional).resourceInfo ResourceInfoType Resource information, such as type of storage andgeographical location.8.2.2.1.1.2 Related Types8.2.2.1.1.2.1 BMBaseObjectTypeThis common type is extended by the BMObject, BMFolderType and BMBaseContentType. It provides commonattributes and elements such as the id attribute, the optional description element and the metadata descriptors.8.2.2.1.1.2.1.1 ParametersParameter Type DescriptionId UID Unique Identifier - Based on SMPTE 434 - a generic termwhich may be a UL, UUID, UMID etc. It can be generatedor assigned by the business process or it can be extractedfrom the content.description[0..*]metadata[0..*]xsd:stringDescriptiveMetadataTypeAn optional element that can be used to describe themedia entity. It has unbounded multiplicity, so thatmultiple descriptions can be added as needed.Optional element that allows flexible insertion of metadatain the BMO and its components. Since it is based on theXSD schema "any" type, it can transparently host any typeof metadata schema. This metadata is treated by the FIMSframework as an opaque object, so there are noPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 51 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.1.1.2.2 ResourceInfoTypeconstraints on the schema adopted for metadata.This type provides resource information such as the type of storage and the geographical location.8.2.2.1.1.2.2.1 ParametersParameter Type DescriptionstorageType StorageEnumType The storage type, enumerated in StorageEnumType(e.g. "online").locationInfo xsd:string Location information for the media content (e.g. NewYork).8.2.2.1.1.2.3 FormatRefTypeThis type provides the reference to the content format ID. The description of the content format is treated as apartially opaque object by the FIMS framework, to provide maximum flexibility and transparency to theintroduction of new formats and codecs. The framework shall support a mechanism to registry and referencemedia formats and identify them by their unique id.8.2.2.1.1.2.3.1 ParametersParameter Type DescriptionId UID The unique reference to the format ID.Description xsd:description An optional description for the media format.8.2.2.1.1.2.4 DurationTypeThis type is used to specify the duration of audiovisual content. It provides a choice between two elements, oneexpressing the duration as time, and one expressing the duration as number of frames.8.2.2.1.1.2.4.1 ParametersParameter Type DescriptiontimeDuration xsd:time This choice element expresses duration as time.framesDuration xsd:long This choice element expresses duration as number offrames.8.2.2.1.1.2.5 DescriptiveMetadataTypeThis type allows the flexible insertion of metadata. Since it is based on the XSD "any" type, it can transparentlyhost any type of metadata schema. This metadata is treated by the FIMS framework as an opaque object, sothere are no constraints on the schema adopted for metadata. When using a type based on a standard or userdefinedschema, the xsi:type and xsi:schemaLocation attributes shall be used, as specified in XML Schema Part1: Structures Second Edition - W3C Recommendation 28 October 2004.8.2.2.1.1.2.5.1 ParametersParameter Type DescriptionId UID An optional attribute used to indicate thePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 52 of 89

FIMS Media SOA Framework Phase1 (Preliminary)ID of the metadata. This attribute can beused to reference by ID metadata thatcan be embedded in a content essencecontainer, such as MXF.Any xsd:any A choice element for wrapping theembedded metadata. This field cannot beset if the “ref” element is used.Ref xsd:anyURI A choice element with a URL reference tometadata, defined according to RFC1738 -Uniform Resource Locators (URL). Themetadata shall be accessible through thespecified URL. This field cannot be set ifthe “any” element is used.8.2.2.1.1.3 Extended Content TypesThe BMBaseContentType is extended by the following content types, each providing additional type-specificproperties:8.2.2.1.1.3.1 BMVideoContentTypeThis type extends BMBaseContentType and provides a reference to video content. It inherits all the elementsfrom BMBaseContentType, and provides an additional optional element (of type DurationType) to express theduration of the video as xsd:time or number of frames.8.2.2.1.1.3.2 BMAudioContentTypeThis type extends BMBaseContentType and provides a reference to audio content. It inherits all the elementsfrom BMBaseContentType, and provides an additional optional element (of type DurationType) to express theduration of the audio as xsd:time or number of frames.8.2.2.1.1.3.3 BMImageContentTypeThis type extends BMBaseContentType and provides a reference to image content. It inherits all the elementsfrom BMBaseContentType.8.2.2.1.1.3.4 BMDocumentContentTypeThis type extends BMBaseContentType and provides a reference to document content. It inherits all theelements from BMBaseContentType.8.2.2.1.1.3.5 BMWrappedContentTypeThis type extends BMBaseContentType and provides a reference to wrapped content. A wrapped contentcontains multiple elementary audio, video and data streams. Examples of wrapped content are: MXF files,MPEG-2 TS, Quicktime, Windows Media files. It inherits all the elements from BMBaseContentType, andprovides an additional optional element (of type DurationType) to express the duration of the content asxsd:time or number of frames. Furthermore, it provides a mechanism to describe structural information (whichstreams are inside the wrapper) specifying the tracks components.The following is a simple BMO example for a MXF file.MXF DV25 filefile://server1/home/virtuser/outbox/op1a-pal-dv25-dms1.mxfPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 53 of 89

FIMS Media SOA Framework Phase1 (Preliminary)application/mxf7840000002009-12-31T12:00:002009-12-31T12:00:0000:01:328.2.2.1.1.3.5.1 ParametersParameter Type DescriptionDuration DurationType Duration of audiovisual content (optional).Track BMTrackType The track element provides a mechanism to exposeinformation about the tracks inside the content. Examplesof tracks are audio and video streams inside anaudiovisual content essence. This mechanism can be usedto reference tracks when performing job requests. Forexample a transform media operation might be able to useonly selected tracks as input.8.2.2.1.1.3.6 Related Types8.2.2.1.1.3.6.1 BMTrackTypePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 54 of 89

FIMS Media SOA Framework Phase1 (Preliminary)This type extends BMBaseObjectType and provides a simple mechanism to give visibility to tracks inside acontent essence. Tracks are used to expose to the FIMS framework structural metadata for content streamsembedded inside a physical content essence. Examples of tracks are audio and video streams inside anaudiovisual content essence. Tracks have a type (for example video, audio, data, closed captioning) and areference to a format. Tracks have also an id, and optional descriptions and metadata, inherited from theBMBaseObjectType.8.2.2.1.1.3.6.1.1 ParametersParameter Type DescriptionType BMObjectType The type of the track (e.g. "video"), as defined inTrackCategoryType.formatRef FormatRefType A reference to the content format ID for the essence. Thisvalue shall be set for tracks of type "video" or "audio".8.2.2.1.2 BMObjectTypeThis type provides, together with the BMBaseContentType, a mechanism to describe a document folder modeland content relationships model which allow complex content services such as content repositories tointeroperate. The BMObjectType extends the BMBaseType and inherits its properties (id, description andmetadata). This type has been designed to provide additional structural information to the content maintaininginteroperability and transparency for services that are just operating on a list of content essence items. Forexample, an asset retrieved from a repository can have a set of video files, which can then be provided to atransfer service using the list of bmContent items. In this simple scenario, the transfer service does not need tobe exposed to the structural data represented in the BMObjectType.8.2.2.1.2.1 ParametersParameter Type DescriptionbmFolder BMFolderType A set of logical folder elements, which can be used togroup content. A bmFolder can contain other foldersand/or content.bmContentRef BMContentRefType A set of content references, providing the referenceto the content essence.8.2.2.1.2.2 Related TypesPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 55 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.1.2.2.1 BMFolderTypeThis type provides a simple structure to expose content structural metadata, for example the structure of anasset retrieved from a repository.8.2.2.1.2.2.1.1 ParametersParameter Type DescriptionbmFolder BMFolderType Provides an element to express a parent-childrelationship with child folders. This allows modelingstructural relationship of content if visibility from thebusiness process is needed.bmContentRef BMContentRefType A set of content reference elements, providing thereference to the content essence.8.2.2.1.2.2.2 BMContentRefTypeThis type provides a reference to the content essence represented by BMBaseContentType and its extendedclasses.8.2.2.1.2.2.2.1 ParametersParameter Type DescriptionId UID The reference to the id of a content of typeBMBaseContentType.bmContentRef BMContentRefType Provides an element to express a parent-child relationshipwith child content elements. This allows modelingstructural relationship of content if visibility from thebusiness process is needed.8.2.2.1.3 Partial Media Reference• Initial specs for transcode and transform do not require partial media reference• Capture provides a ClipType, which allows specifying partial media capture with time codes, time orexternal triggers.• Additional services might require the ability to reference partial media. A possible approach (based oncurrent BMO) is specifying in and out points with time codes in the reference to media content(BMContentRefType).8.2.2.2 JobsAn essential aspect for the management of long-running media operations is the ability to check the status ofoperations and interact with active queued jobs. For example, the following tasks might have to be performedfor transcoding operations:• Check the status of a job• Cancel an active job• Pause an active job• Stop an active job• Change priority of a jobPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 56 of 89

FIMS Media SOA Framework Phase1 (Preliminary)• List jobs in a queue• Clear a queue• Delete single job from a queue• Lock/unlock a queueThe adoption of a common interface for the status operations enables the use of common front-end tools formedia services management, and the ability to interact with running tasks from a client or workflow. Queue andJob management types provide a mechanism to query and manage the status of jobs and job queues.8.2.2.2.1 ManageJobRequestTypeThis type is part of the FIMS service common status interface and provides a mechanism to check the status ofjobs and update jobs properties, such as job priority. The manage job request uses the jobCommand to set theintent of the command (requesting status or acting on the job state).8.2.2.2.1.1 ParametersParameter Type DescriptionjobCommand JobCommandType The job command is used to determine the type of jobrequest, such as checking on the job status or performingan action on the job (e.g. pause the job). The allowed jobcommands value are enumerated on theJobCommandType.modifyJob ModifyJobType If the job command is set to "modifyJob", this elementshall be set, to provide one of the values listed inModifyJobType. If the job command is set to any othervalue, this element should not be set.jobID JobIDType The job id information for this job. It is provided with theJobIDType, where it is sufficient to set the jobGUID.8.2.2.2.1.2 Related Types8.2.2.2.1.2.1 JobCommandTypeEnumerates the allowed values for a job command:- status: request the status information for a job. It does not change the state of the job.- cancel: cancel a job- pause: pause a job. It can be restarted with resume.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 57 of 89

FIMS Media SOA Framework Phase1 (Preliminary)- resume: resume a job from a paused state.- restart: restart a job from the beginning.- terminate: terminate a job.- cleanup: remove all the data related to a job.- modifyJob: modifies the priority or the profile of a job.8.2.2.2.1.2.2 ModifyJobTypeThis type provides a choice for modifying the settings for the current job. It allows modifying the priority or theprofile.8.2.2.2.1.2.2.1 ParametersParameter Type DescriptionPriority PriorityType This choice element shall be set to the value of the newpriority.Profile BaseProfileType This choice element shall be set to the value of the newprofile. For example, a modified profile might changeresource utilization settings for the current job.8.2.2.2.1.2.3 JobIDTypeThis type provides the information on the jobGUID and the service provider job ID (local job ID).8.2.2.2.1.2.3.1 ParametersParameter Type DescriptionjobGUID xsd:string The globally unique identifier (GUID) for the job requestserviceProviderJobID xsd:string The service provider job ID. If the service providergenerates its own job ID associated with a job request,this field must be set. Otherwise, the service provider canuse the supplied jobGUID.8.2.2.2.2 ManageJobResponseTypeThis type provides job information as a response to a job management request (e.g. pausing a job orrequesting the job status). Furthermore, the response message provided by this type supports a pollinginteraction pattern for retrieving the status and the response of an asynchronous job request. The client canquery the status using the manage job request and can retrieve the result of the job, upon completion orfailure, using the jobResult element in this type.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 58 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.2.2.1 ParametersParameter Type DescriptionjobInfo JobInfoType This element provides the job information, such as statusand statistics.serviceProviderInfo ServiceProviderInfoType This element provides information on the service providerservicing the job.taskInfo TaskInfoType This optional list provides tasks information for the job.Tasks can be used to describe elementary activities whena job operates on multiple content elements, such as atransfer service moving multiple files. Each task can thenprovide the status on each individual activity, while theJobInfoType provides the overall job status.jobResult NotificationContainerType This element provides the result of a job. It shall be setfor jobs in completed, terminated or failed state. It usesthe NotificationContainerType, which provides an "any"type element as a container for the notification responseof the service. Each FIMS service shall support anotification and a polling mechanism for long-runningoperations. In order to support polling and being able toretrieve the result of a job operation, the result of theoperation shall be set in this element.8.2.2.2.2.2 Related Types8.2.2.2.2.2.1 JobInfoTypePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 59 of 89

FIMS Media SOA Framework Phase1 (Preliminary)This type provides detailed information on a job, such as the status, the job ID, the current priority and severaljob statistics.8.2.2.2.2.2.1.1 ParametersParameter Type DescriptionStatus jobStatusType The current status of the job (e.g. running,completed), enumerated in JobStatusCodeType.JobID JobIDType The job ID information. It provides both theglobal job GUID and the local job ID (serviceprovider job ID).operationName xsd:string The name of the operation associated with thisjob.Priority PriorityType The priority for the job (e.g. "immediate","high"...) enumerated in PriorityType.jobStartedTime xsd:dateTime The date and time this job started.jobElapsedTime xsd:time The time elapsed since the job started.jobCompletedTime xsd:dateTime The time and date the job completed. It must beset for jobs in "completed" state.estimatedCompletionTime xsd:dateTime An optional element providing an estimate on thetime it takes to complete the current job.percentageCompleted xsd:integer The percentage of job completed. The percentagecan be based on one of two metrics: number ofbytes processed, or number of frames processed(for video files). If the bytesCount metric isprovided, then the percentage is based onnumber of bytes processed. If the framesCountmetric is provided, then the percentage is basedon the number of processed frames.bytesCount xsd:long The number of bytes processed from the start ofthe job. This is a choice element, so the serviceshould provide this element or framesCount.framesCount xsd:long The number of frames (for audiovisual contentonly) processed from the beginning of the job.This is a choice element, so the service shouldprovide this element or bytesCount.8.2.2.2.2.2.2 JobStatusTypeProvides information on the status of a job.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 60 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.2.2.2.2.1 ParametersParameter Type DescriptionCode JobStatusCodeType Provide the job status code. SeeJobStatusCodeType for a list and description ofcodes.Description xd:string Optional description for job status info.8.2.2.2.2.2.3 ServiceProviderInfoTypeThis type provides the info required to uniquely identify a service provider servicing a request.8.2.2.2.2.2.3.1 ParametersParameter Type DescriptionName xsd:string An optional name for the service provider.Endpoint xsd:anyURI The provider endpoint, which uniquely identifiesthe provider servicing the job request.8.2.2.2.2.2.4 TaskInfoTypeThis type provides tasks information for the job. A job can be composed of tasks. For example a transfer mediaservice might transfer multiple file, each transfer operation being a task.8.2.2.2.2.2.4.1 ParametersParameter Type DescriptionName xsd:string The name for this task, for example "file transfer".Status JobInfoCompactType The status of this task.sourceRef anyURI A reference to the source on which this task isoperating, for example the URL to a file beingtransferred.8.2.2.2.2.2.5 JobInfoCompactTypeThis type provides summary information for a job. It provides only key information, in comparison with the typeJobInfoType, which provides more detailed information.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 61 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.2.2.2.5.1 ParametersParameter Type DescriptionPriority PriorityType The priority for the job (e.g. "immediate","high"...) enumerated in PriorityType.estimatedCompletionTime xsd:dateTime An optional element providing an estimate onthe time it takes to complete the current job.jobID JobIDType The job ID information. It provides both theglobal job GUID and the local job ID (serviceprovider job ID).operationName xsd:string The name of the operation associated withthis job.Status jobStatusType The current status of the job (e.g. running,completed), enumerated inJobStatusCodeType.8.2.2.2.3 Manage Job FaultIf an exception is generated when a manage job request message is sent to the adapter, the adapter shallrespond with a message based on the FaultType.8.2.2.2.4 ManageQueueRequestTypeThe manage queue request type. It is part of the FIMS service common status interface and provides amechanism to manage a queue, for example checking status of the queue, stopping and starting the queue andlocking the queue. The queue management request uses the queueCommand to set the intent of the command(request status or act on the queue state).8.2.2.2.4.1 ParametersParameter Type DescriptionqueueCommand QueueCommandType This element specifies the intent of thecommand. Possible values for the commandare listed in QueueCommandType.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 62 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.2.4.2 Related Types8.2.2.2.4.2.1 QueueCommandTypeThis is the list of valid commands associated to the management of the queue:- status: get status or current state of queue- clear: remove or delete all remaining jobs in the queue- stop: stop processing all pending jobs in the queue- start: restart all stopped jobs in the queue- lock: lock a queue from receiving or accepting new job requests- unlock: unlock a locked queue8.2.2.2.5 ManageQueueResponseTypeThis type represents a response to a queue management request. It provides information such as the statusand the length of queue.8.2.2.2.5.1 ParametersParameter Type DescriptionqueueInfo QueueInfoType This element provides the response to aqueue management request.8.2.2.2.5.2 Related Types8.2.2.2.5.2.1 QueueInfoTypeThis type provides basic queue information such as status and length of the queue.8.2.2.2.5.2.1.1 ParametersParameter Type DescriptionStatus QueueStatusType The status information for the queue.Length xsd:integer The current length of the queue, indicatinghow many jobs are in the queue.estimatedTotalCompletionTime xsd:time An optional estimate of the time requiredfor processing all jobs currently in thequeue.8.2.2.2.5.2.2 QueueStatusTypeThis type provides status information for the queue.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 63 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.2.5.2.2.1 ParametersParameter Type DescriptionCode QueueStatusCodeType The status for the queue, enumerated inQueueStatusCodeTypeDescription xsd:string An optional description for the status.8.2.2.2.5.2.3 QueueStatusCodeTypeThis type enumerates the status for the queue:- started: the queue has started successfully.- stopped: the queue has been stopped successfully. The queue is not accepting new submitted jobs.- locked: the queue has been locked successfully and will not accept any new submitted jobs. The jobsalready in the queue will continue to start or run to completion.8.2.2.2.6 ListQueueRequestTypeThis type represents a request for listing the jobs in the currently queue.8.2.2.2.6.1 ParametersParameter Type DescriptionlistQueuedOnly xsd:Boolean If this parameter is set to true, the serviceshall return only the list of queued jobs. If itis set to false, the service shall includequeued and running jobs in the list.8.2.2.2.7 ListQueueResponseTypeThis type is used to provide a list of all jobs in a queue (typically as response to a request operation usingListQueueRequestType).8.2.2.2.7.1 ParametersParameter Type DescriptionjobList QueueListType The list of jobs in the queue.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 64 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.2.2.2.8 Related Types8.2.2.2.8.1 QueueListTypeThis type extends the QueueInfoType to provide basic queue info (status, length of the queue) and the list ofjobs in the queue.8.2.2.2.8.2 ParametersParameter Type DescriptionjobList JobInfoCompactType A list of job info elements, providingsummary info on each job in the queue.8.2.2.2.9 Manage/List Queue FaultIf an exception is generated when a manage or list queue request message is sent to the adapter, the adaptershall respond with a message based on the FaultType.8.2.2.3 Return ValuesReturn values and status for each submitted jobs are provided by the BaseResponseType described earlier andextended types such as the MediaResponseType.8.2.2.4 ErrorsThe base schema defines a base fault type that can be extended by specific FIMS service classes to provideservice-class specific error codes. One of the benefits in utilizing a media service abstract class is the definitionof a common set of errors. This definition allows the client requesters to implement different error handlinglogic for each individual service provider used. With this approach, the client can implement a generalcompensation or error handling logic for all service providers that support a FIMS service specification.8.2.2.4.1 FaultTypeThis is the base fault type, which can be extended by each service class to provide additional error codes. Theextended fault shall provide an extendedCode field, which provides class-specific codes.8.2.2.4.1.1 ParametersParameter Type DescriptionPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 65 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Code ErrorCodeType The error code. It can be one of the values specified inErrorCodeType. It shall be set to "EXT0000" for serviceclass-level specific errors that are not in the base list. Inthis case the error code shall be set in the "extendedCode"field of the extended fault.Description xsd:string An optional description of the error.Detail xsd:string This optional field shall be used to provide the native errorstack trace from the service provider, if available.8.2.2.4.1.2 ErrorCodeTypeThis type enumerates common error codes that different classes of adapters can share. This code shall be set to“EXT0000” if the adapter provides an extended, class-specific error code. Error codes are classified in threemain categories:• SYSxxxx: system level errors• DATAxxxx: data validation errors• APPxxxx: service level errorsA list of common error codes is shown below. This list is not meant to be a comprehensive listing of all possibleerrors, but it is meant as an example to show only the different type of errors and their range of error codes, asfollows:- SYS0100: System Unavailable- SYS0101: System Timeout- SYS0102: System Internal Error- SYS0103: Unable to connect to the database- DATA0100: Invalid Request XML Format- DATA0102: Invalid Input Media Format- DATA0103: Invalid JobID- DATA0104: Missing required service metadata in request- DATA0105: Duplicate JobGUID detected for new job.- DATA0106: Invalid Request Parameters- DATA0107: Job Command not valid- DATA0108: Queue Command not valid- DATA0109: Invalid Priority- DATA0110: Input Media not found. Invalid Resource URI specified.- APP0100: Job Command is not currently supported by the adapter or the service provider- APP0101: Queue Command is not currently supported by the adapter or the service provider- APP0102: Operation requested is not currently supported by the adapter or the service provider- APP0103: Adapter unable to find/lookup service provider endpointPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 66 of 89

FIMS Media SOA Framework Phase1 (Preliminary)- APP0104: Job Command failed- APP0105: Queue Command failed- APP0106: Adapter unable to connect to service provider endpoint- APP0107: Job Queue is full, locked or stopped. No new jobs being accepted.- APP0108: Job ended with a failure- APP0200: Adapter received no response from service provider.- APP0201: Adapter received an exception from service provider. See description or exception detail.- APP0202: Adapter received an unknown or an internal error from service provider. See description forerror detail.- APP0203: Unable to connect to client's notification service endpoint (replyTo) to send the asynchronousjob result notification response.- APP0204: Unable to connect to client's service endpoint (faultTo) to send the asynchronous job faultresponse.- APP0205: Feature not supported.- APP0300: Internal or Unknown error encountered. See description for error detail.- EXT0000: Extended code. See extended error code for details.8.3 Service Consumer Interface (Service Events Producer Interface ??)The service consumer interface describes the mechanism used to provide the result and the status of longrunning operations. The support for long-running, asynchronous operations for FIMS services shall beimplemented by two different interaction patterns:• Request/response with asynchronous notification pattern: This pattern is composed by asynchronous request/response call to submit a job to the service and an asynchronous call back fromthe service to the invoking client to return the result of a specific media operation, as illustrated inFigure 1. In this scenario, a service client has to implement a client stub, used for invoking the serviceaccording to a traditional synchronous request-response pattern, and a server stub, used to receive theasynchronous reply back from the service. The service has to implement a server stub, to receive thesynchronous request and to acknowledge that the operation request has been received and processinghas started. In addition, this service has to implement a client stub to call back the client when theoperation is completed. The FIMS specifications require each service to implement this pattern byproviding a port for the synchronous exchange, and a port for the asynchronous reply, which should beimplemented as a client stub. During the initial synchronous interaction, the client sends to the servicean endpoint used by the service for the asynchronous response (replyTo); the service stores thisinformation and uses it later for the call back. A set of correlation parameters (IDs) is adopted tocorrelate the asynchronous reply with the operation initiated by the initial synchronous exchange. Theseparameters must be present in the initial synchronous exchange (in the request, in the response, or inboth) and in the asynchronous reply. The FIMS specification identifies a specific parameter used forcorrelation in the synchronous interaction and the asynchronous reply (jobGUID) see sections xxxx).• Request/response with status polling pattern: This pattern is composed by a synchronousrequest/response to submit a job to the service to the service and a periodic call to a status serviceinterface to check the job status (polling). The FIMS specifications require each service to implementthis pattern by providing a port for the status check, as described in section xxx.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 67 of 89

QuickTime and adecompressorare needed to see this picture.QuickTime and adecompressorare needed to see this picture.QuickTime and adecompressorare needed to see this picture.QuickTime and adecompressorare needed to see this picture.QuickTime and adecompressorare needed to see this picture.QuickTime and adecompressorare needed to see this picture.FIMS Media SOA Framework Phase1 (Preliminary)Web Service Client / Business ProcessLong-running Web ServiceClientRequest- correlationID- replyToAckServiceAsync Operations PortSOAP/HTTPNotificationConsumercorrelationIDSOAP/HTTP-correlationID-replyToPersistentStore / DBNotificationNotification Producer8.3.1 OperationsFigure 1: Request/response with asynchronous notification patternEach FIMS service shall implement a notification producer as a client stub using the message format defined forthe notification message. Furthermore, each FIMS service shall support polling with the operations using theManageJobRequestType and ManageJobResponseType as request and response messages.8.3.2 SchemaThe types used for the notification and polling operations have been described in sections xxx. The operationsshall use the following types:• Notification operation: shall use an input message based on the types BaseResponseType,MediaResponseType or their extended types.• Polling operation: shall use an input message based on the type ManageJobRequestType and itshall use an output message based on the ManageJobResponseType.8.3.2.1 EventsFIMS services can generate events to indicate job or queue relates state changes, or system / service statuschanges. FIMS service events are based on a publish-subscribe pattern. As mentioned earlier, this sectionfocuses on the structure of the types used by the messages and not on the specified bindings, however it isworth mentioning that for SOAP/HTTP binding FIMS service shall adopt the Web Services Brokered Notification1.3 (WS-BrokeredNotification) OASIS standard. Since the WS-BrokeredNotification standard does not addressthe container used for transporting the event or the event content, this section focuses on the definition of theevent container and of the event payload.8.3.2.1.1 Event ContainerThe event container is based on the WSDM Event Format defined in the Web Services Distributed Management:Management Using Web Services (MUWS 1.1) Part 1 OASIS Standard, 1 August 2006. The WSDM Event Formatdefines an XML format to carry management event information. The format defines a set of basic, consistentdata elements that allow different types of management event information to be carried in a consistent manner.The WSDM Event Format provides a basis for programmatic processing, correlation, and interpretation of eventsfrom different products, platforms, and management technologies.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 68 of 89

FIMS Media SOA Framework Phase1 (Preliminary)The event payload shall be inserted in the “any” element of the ManagementEventType.8.3.2.1.2 MediaServiceEventTypeThis type represents a FIMS event payload sent from a service to the framework. The information in this type iswrapped by the event container specified by the WSDM Event Format. This base type is extended to providespecific events types:- SystemEventType- QueueEventType- JobEventType- ServiceEventType8.3.2.1.2.1 Event Types8.3.2.1.2.1.1 SystemEventTypeThis type represents a system-level event. It extends the base MediaServiceEventType.8.3.2.1.2.1.1.1 ParametersParameter Type DescriptionCode SystemEventCodeType The code for this system event,enumerated in SystemEventCodeType(e.g. low disk space).eventData xsd:string Optional element, which provides detailson the event.8.3.2.1.2.1.2 QueueEventTypeThis type represents a queue-level event. It extends the base MediaServiceEventType.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 69 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.3.2.1.2.1.2.1 ParametersParameter Type DescriptionCode QueueEventCodeType The code for this event. It isenumerated in QueueEventCodeType.eventData QueueInfoType This element provides queueinformation.8.3.2.1.2.1.3 JobEventTypeThis type represents a job-level event. It extends the base MediaServiceEventType.8.3.2.1.2.1.3.1 ParametersParameter Type DescriptionCode JobEventCodeType The event code. It provides the type ofjob event that occurred, typically achange in the status of a job. It isenumerated in JobEventCodeType.jobStatusChangedpriorityModifiedprofileModifiedestimatedCompletionTimeChangedmissedDeadlineeventData JobInfoCompactType This element provides job information inPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 70 of 89

FIMS Media SOA Framework Phase1 (Preliminary)8.3.2.1.2.1.4 ServiceEventTypecompact form.This type represents a service-level event. It extends the base MediaServiceEventType.8.3.2.1.2.1.4.1 ParametersParameter Type DescriptionCode ServiceEventCodeType The code for this system event,enumerated in ServiceEventCodeType(e.g. “serviceAvailable”).eventData xsd:string Optional element, which provides detailson the event.8.3.2.1.3 WS-Notification and RESTPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 71 of 89

FIMS Media SOA Framework Phase1 (Preliminary)9 Media Centric Features (informative for this edition)SOA has become an established approach for a range of IT systems such as information systems, accountingsystems, etc. However, in seeking to apply a SOA approach to a Media system, several unique media-centricissues also need to be considered. This section describes the specific Media centric features applicable to aMedia SOA system.9.1 Composite ServiceA Composite Media Service is composed of more than one existing service in order to realize functions and/orperformance that use of individual existing services by themselves cannot achieve.Because there seems to be no other service than Capture (or Ingest) that requires tight service integration withpipelined processing, this section focuses on the Capture service, while the generic mechanisms needed todefine a composite service are left for future study.Capture provides a function that imports the AV essence from other AV systems to the media system,Transform is a function that transforms the properties of AV essence such as format, data size, and colorgrading, within the system, and Transfer is a function to move a media file from one place to another within thesystem.A workflow that receives AV essence from other AV systems, transforms it as appropriate and stores it in thesystem is usually called ‘Ingest’. While this would seem to be capable of being realized simply by invoking inturn the Capture service, the Transform service, and the Transfer service, for AV media there are several issuesthat need to be carefully considered. For example, AV process handling, the interface boundary between theCapture and the Transform services, and the issue of pipelined handling in order to optimize performance.Figure 3 shows a block diagram of typical Ingest system, where the video handling part is highlighted.In this diagram, the AV Process indicates baseband signal processing such as LUT (Look Up Table) based Colorgrading, QC (Quality Check), Cropping, Resizing, and Burn-in (text-overlay). The preferred order and/orconfiguration of such processes depend on the workflow, which needs to be flexibly tailored to meet the user’sspecific demands.One of the most important performance factors of Ingest is to minimize the delay between the Capture of AVessence and its readiness for use by downstream services. Movement of AV essence between internal blocks istherefore optimized. In addition, frame or GOP based pipelined processing is introduced (see Figure 4) tofurther reduce delay.FileSDIHD‐SDIBasebandFile CaptureFileUnwrap DecodeVTR/LiveCaptureBasebandAVProcessBasebandEncodeWrapTransferIngestFileFigure 3 Typical Ingest Process Block DiagramPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 72 of 89

FIMS Media SOA Framework Phase1 (Preliminary)IngestCapture12 3 4 5 6Transform12 3 4 5 6Transfer12 3 4 5 6Pipelined per frame (GOP)timeFigure 4 Pipeline ProcessFigure 5 shows a typical block diagram of Ingest composed of Capture, Transform and Transfer.The input for the Capture service includes file or SDI/HD-SDI from the live production system and/or theconventional VTR. Because SDI/HD-SDI is baseband signal, it is hard to move it as it is to the followingdownstream services. Hence, the Capture service in Figure 5 transforms the incoming baseband signal into aform of file, and passes it to the following service. In this case, problems occur not only due to the largeoverhead of data movement between services but also because of the highly duplicated functionality among theCapture and Transform services due to the former containing processes used in the latter.As shown in Figure 5, when the Capture service contains a Transform service, Ingest is realized without anadditional external Transform service. This also makes it possible to realize the optimized pipelined processingbetween the Capture and Transform services. Note, however, that even in this case, pipelined processingcannot be realized between Capture and Transfer services.FileSDIHD‐SDIFile Capture Unwrap DecodeVTR/LiveCaptureAVProcessEncodeWrapFileCaptureUnwrap Decode Encode WrapAVProcessFileTransformIngest 1TransferFilePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 73 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Figure 5 Ingest Service Decomposition (1)When Transfer is contained within the Transform service, which is then contained within the Capture service,the problem is resolved as shown in Figure 6. The overall service provided is equivalent to that shown in Figure3 and pipelined processing is applicable to both Capture/Transform and Transform/Transfer boundaries.FileSDIHD‐SDIFile Capture Unwrap DecodeVTR/LiveCaptureAVProcessEncodeWrapTransferTransformFileCaptureIngest 2Figure 6 Ingest Service Decomposition (2)Figure 7 shows an indicative WSDL description of the Ingest Service shown in Figure 6. transferProfile is aparameter of the Transform service for defining AV process, Codec, and Wrapper, and transferProfile is aparameter of the Transfer service for defining file destination. See 9.2.3.1.1 for an example of transformProfileconfiguration.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 74 of 89

FIMS Media SOA Framework Phase1 (Preliminary)transferProfile.xsd….transformProfile.xsdImport….Capture Service ParametersCaptureService.wsdlTransformService.wsdl…….ImportImported “transformProfile”Figure 7 Indicative WSDL Description for Capture Service9.1.1 ProfilesThe transformProfile (and other profiles) can be implemented in two ways, one as an opaque vendor specificdocument (as in a transcoder profile), and the second as a part of the FIMS defined framework.The first approach is the current methodology used by most third party device vendors to define parameters fora job. This can apply to capture, transfer, and transcode or transform operations. The vendor system definesand may provide a way to input parameters and store them in a named profile document, which can bereferenced when a job is created.The second approach provides a means to support “well defined” or standardized a/v formats. It uses preagreedformat name tags plus a minimum of user defined parameters in a FIMS defined XML profile document.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 75 of 89

FIMS Media SOA Framework Phase1 (Preliminary)9.1.2 Capture Service [To be Moved/merged with Section 8]Figure 7 below shows the detailed interface for Capture service. The Transform function (which may containTransfer function) is configured with the transformProfile input. An example description of transferProfile isgiven in Section 9.2.3.1.1.INOUTpriorityjobGUIDrequestedCompletionTimesourceIDsourceTypesourceURIcaptureTypeclips[1..*]transformProfile[1..*]outputFileName[0..1]descriptiveMetadata[0..1]Descriptive MetadataserviceMetadata[0..1]Technical MetadatanotifyAtCaptureoperationInfo (Ack)serviceProviderInfo (Ack)operationInfo (Notification)serviceProviderInfo (Notification)sourceID (Notification)bmo (Notification)Technical MetadataautoQCStatus[0..1] (Notification)Figure 8 Interface Parameters of Capture ServiceCapture Service – Input ParametersParameterPriorityjobGUIDrequestedCompletionTimesourceIDsourceTypesourceURIcaptureTypeclips [1…*]transformProfile [1..*]Description‘Immediate’, ‘Urgent’, ‘High’, ‘Middle’, and ‘Low’.Global Job IDOptional - Time to be finishedId of source to captureType of source to capture (e.g. vtr, live, file)Contains reference to source location and input file. (in the case of ‘file’)‘whole’, ‘in-out’, ‘in’, ‘out’, and ‘not specified’.Info on clips to capture (trigger type, start time, end time, duration) for eachclipContains reference to the profile used for the transform.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 76 of 89

FIMS Media SOA Framework Phase1 (Preliminary)outputFileName [0..1]descriptiveMetadata [0..1]serviceMetadata [0..1]notifyAtOptional - if provided it should be used to name the new file, otherwise nameshould be generated form source file name.Optional - contains user-defined metadata (description, comment etc.) forwrapperOptional - Used to provide a extension mechanism for service providerimplementations, e.g. File Division on Time code Break / Capture Speed /Acquisition of Metadata.Optional - contains replyTo and faultTo endpoint addresses. If provided, theservice must respond to the supplied URIs when job completion or failed statusoccurs.Table 1 Input Parameters of Capture ServiceTransform Service – Output Parameters (Ack)ParameteroperationInfoserviceProviderInfoDescriptionIncludes: operationName, jobID, jobGUID, statusIncludes sp name, endpointTable 2 Output Parameters (Ack) of Capture ServiceTransform Service – Output Parameters (Notification)ParameteroperationInfoserviceProviderInfobmoautoQCStatusDescriptionIncludes: operationName, jobID, jobGUID, statusIncludes sp name, endpointContains the reference to the output media.Includes: Captured File Information (AssetID, start & stop code, duration)Contains the result of Auto QC.Table 3 Output Parameters (Notification) of Capture Service9.1.2.1 Examples of transformProfile configurationIn the transformProfile, the selection of the AV processes (LUT, Resize, Burn-in, etc) and their configurations,the kinds of codec and file wrapper to be used in Transform service is described according to thetransformProfile schema defined elsewhere.Figures 9 and 10 show two indicative transformProfile configurations for ‘simple’ and ‘complex’ capturerespectively.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 77 of 89

FIMS Media SOA Framework Phase1 (Preliminary)AV ProcessHD‐SDIVTR/LiveCaptureEncodeDNxHDWrapMXFTransferFile…transformProfile(Indicative)TransformCapture...Figure 9 Indicative transform Profile Description (‘simple’)HD‐SDIVTR/LiveCaptureLUTtransformProfile ImageResizeAV ProcessBurn‐InEncodeJ2KEncodeAVCWrapMXFWrapMP4TransferTransferFileFile…transformProfile(Indicative)TransformCapture...Figure 10 Indicative transform Profile Description (‘complex’)Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 78 of 89

FIMS Media SOA Framework Phase1 (Preliminary)9.1.3 Transform Service [to be moved/merged with Section 8]INOUTpriorityjobGUIDrequestedCompletionTimebmoTechnical MetadatatransformProfile[1..*]outputFileName[0..1]descriptiveMetadata[0..1]Descriptive MetadataserviceMetadata[0..1]Technical MetadatanotifyAtTransformoperationInfo (Ack)serviceProviderInfo (Ack)operationInfo (Notification)serviceProviderInfo (Notification)bmo (Notification)Technical MetadataautoQCStatus[0..1] (Notification)Figure 11 Interface Parameters of Transform ServiceTransform Service – Input ParametersParameterPriorityjobGUIDrequestedCompletionTimebmotransformProfile [1..*]outputFileName [0..1]descriptiveMetadata [0..1]serviceMetadata [0..1]notifyAtDescription‘Immediate’, ‘Urgent’, ‘High’, ‘Middle’, and ‘Low’.Global Job IDOptional - Time to be finishedContains reference to source file and locationContains reference to the profile used for the transform.Optional - if provided it should be used to name the new file, otherwise nameshould be generated form source file name.Optional - contains user-defined metadata (description, comment etc.) forwrapperOptional - Used to provide a extension mechanism for service providerimplementations, e.g. File Division on Time code Break / Capture Speed /Acquisition of MetadataOptional - contains replyTo and faultTo endpoint addresses. If provided, theservice must respond to the supplied URIs when job completion or failed statusoccur.Table 4 Input Parameters of Transform ServicePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 79 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Transform Service – Output Parameters (Ack)ParameteroperationInfoserviceProviderInfoDescriptionIncludes: operationName, jobID, jobGUID, statusIncludes sp name, endpointTable 5 Output Parameters (Ack) of Transform ServiceTransform Service – Output Parameters (Notification)ParameteroperationInfoserviceProviderInfobmoautoQCStatusDescriptionIncludes: operationName, jobID, jobGUID, statusIncludes sp name, endpointContains the reference to the output media.Includes: Captured File Information (AssetID, start & stop code, duration)Contains the result of Auto QC.Table 6 Output Parameters (Notification) of Transform Service9.1.4 Transfer Service [to be moved/merged with Section 8]INOUTpriorityjobGUIDrequestedCompletionTimebmoTechnical MetadatatransferProfilestartTimeserviceMetadata[0..1]Technical MetadatanotifyAtTransferoperationInfo (Ack)serviceProviderInfo (Ack)operationInfo (Notification)serviceProviderInfo (Notification)bmo (Notification)Technical MetadataFigure 12 Parameters of Transfer ServiceTransfer Service – Input ParametersParameterPriorityDescription‘Immediate’, ‘Urgent’, ‘High’, ‘Middle’, and ‘Low’.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 80 of 89

FIMS Media SOA Framework Phase1 (Preliminary)jobGUIDrequestedCompletionTimebmotransferProfilestartTimeserviceMetadata [0..1]notifyAtGlobal Job IDOptional - Time to be finishedContains reference to source file and locationCovers: Input File Configuration (Source of Media File/ Input File Name)Contains reference to destination location and output fileIndicates when starting the transferOptional - Used to provide a extension mechanism for service providerimplementationsOptional – contains replyTo and faultTo endpoint addresses. If provided, theservice must respond to the supplied URIs when job completion or failed statusoccurs.Table 7 Input Parameters of Transfer ServiceTransfer Service – Output Parameters (Ack)ParameteroperationInfoserviceProviderInfoDescriptionIncludes: operationName, jobID, jobGUID, statusIncludes sp name, endpointTable 8 Output Parameters (Ack) of Transfer ServiceTransfer Service – Output Parameters (Notification)ParameteroperationInfoserviceProviderInfobmoDescriptionIncludes: operationName, jobID, jobGUID, statusIncludes sp name, endpointContains the reference to the output media.Table 9 Output Parameters (Notification) of Transfer ServicePrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 81 of 89

FIMS Media SOA Framework Phase1 (Preliminary)9.2 Asynchronous operations for long running processMedia SOA workflows are often long running processes, sometimes active for hours, days, or even weeks. Thisplaces specific persistence requirements of the SOA BPM platform. Servers may be stopped or restarted whileprocesses are running, and the system needs to save state and be able to restart at the same point in theworkflow and process orchestration without loss or state or data.Many Media SOA service are external hardware or software based systems that operate in a loosely coupledasynchronous environment. Therefore if servers are stopped or started these services may continue running,and job process state must be recovered after the SOA system restarts.Asynchronous operation status updates may be implemented with either callbacks or polling depending on SOAplatform architecture.The details of asynchronous communication are discussed in Section 8 Media Service Communication.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 82 of 89

FIMS Media SOA Framework Phase1 (Preliminary)9.3 Resource Management9.3.1 Process Scheduling and Resource ManagementBecause of long processing time resulting from the huge size of AV data as discussed in Section 9.2.1, processscheduling as well as the resource management can be crucial for the Media SOA system in order to effectivelyutilize the limited resources.Although the Resource manager service includes Process scheduling and Resource management, the Processscheduling service may be invoked by only the user application of the system where the Resource managementservice may be invoked by the user application of the system, the mediator in the middleware, or by any of theworkflow services.The interface for a service could be hidden if it is only invoked within the closed system because it is left to thesystem developer. However, considering that it is also used by the workflow services, the interface needs to bedefined as a part of the FIMS framework.Therefore the Resource manager service which includes only the resource management is defined as one of therecommended media infrastructure services in the FIMS framework.The concept and the sequence chart of the Resource manager service are depicted in Figures xxx and xxx,respectively.ServiceConsumerUser applications,other workflow services,or middleware (mediator)ServiceRequest / ResponseInquiry workload andestimated time ofeach service.Service AllocateRequest / ResponseMiddlewareGet the service list.WorkflowServiceWorkflowServiceWorkflowServiceResource ManagerServiceServiceRepositoryDecide which service isutilized for the requestbased on business rule.Figure xxx Resource Manager Concept DiagramPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 83 of 89

FIMS Media SOA Framework Phase1 (Preliminary)ServiceConsumer:Resource ManagerService:TransformService A:TransformService B:…TransformService N:Service Allocate Request/w “Service Class”, “Service Profile”, and etc.e.g.) Service Class = “Transform Service”Get the transform service list from the SLA repository.Inquiry workload and estimated time of eachtransform service using Queue Status Requestand Job Estimate Request, etc.Decide which service is utilized for the jobbased on business rules.Service Allocate Response/w “Service ID” of the specified servicee.g.) Service ID = “Transform Service B”Transform RequestTransform ACKFigure xxx Resource Manager Sequence DiagramThe sequence of Resource Manager Service is as follows:1. Service Consumer sends a request message to the Resource Manage Service by specifying the “ServiceClass” (such as Transform) and “Service Profile” (parameters such as codec used in the Transform Service),2. The Resource Manager Service obtains the service list of the specified service class from the ServiceRepository,3. The Resource Manager Service obtains the workload and the expected execution time of each service inthe list by using the Queue Status Request and/or Job Estimate Request,4. The Resource Manager Service determines the service to be invoked based on the information obtained inItem 3 above, its SLA, and the business rule,5. The Resource Manager Service returns ID of the selected service to the Service Consumer.In this scenario, all user applications, other workflow services and Middleware (mediator) are regarded as theService Consumer of the Resource Manager Service. A user application will query whether a service is suitableby explicitly issuing the request message to the Resource Manger Service in one case. Or in another case, asystem may provide for automatic selection of an appropriate service by a mediator in the middleware, whoseprocess is hidden from the user applications.9.4 Media Aware Bus9.4.1 DefinitionAn extension to SOA often called the “Media Bus” can facilitate storage and media file centric operations. TheMedia Bus extension is similar to an Enterprise Service Bus (ESB) optimized for large files.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 84 of 89

FIMS Media SOA Framework Phase1 (Preliminary)Since the system manages the storage and movement of a very large number of large files (sometimes millionsper project) it is important that an asset data repository be available as part of the system core functionality, oras an external (third party) service.There can be many copies of file instances and also many versions located in multiple island data storage areasin the system. There will also be many lower resolution video proxy files in the system representing the originalhigh resolution “camera negative” files or file sequences. These proxy files must be tracked and versioned aswell.9.4.2 Other Media Bus FeaturesReliable transfers are also critical, so the capability to provide check sums or other file verification technology isalso a function of the media bus.File naming and name management in Post Production workflows is a major issue. File names are oftenchanged when new instances are created to serve the needs of a specific creative task like Picture Editorial orDigital Intermediate. So the same file or sequence may exist in various parts of the system with different filenames. It is critical that all of these instances of the same essence be tracked and managed.Maintaining the correct metadata for any given file or file sequence (clip) as it passes through the manyprocessing stages in a media workflow is also a big problem. Many processes, both internal and outsourced (likeVFX) may change or strip off metadata from the essence and even change the identity of the objects involved.Maintaining a clear relationship between a media object and its original and modified or added metadata is veryimportant.Storage management is also critical due to the large number of large files in a 2K or 4K workflow. The systemmust facilitate the efficient use of the hierarchal storage system and assist is selecting files to be migrated totape library storage.9.4.3 M-SLAFor the treatment of Media Aware Bus in the FIMS Framework, the performance of elements on Media AwareBus (mainly storage devices) such as bandwidth, transfer speed, capacity, and available protocols are to bequeried by using a common format message.Based on this, a client such as service consumer and/or the media infrastructure service can select the storagedevice which is best suited to the client, and/or more precisely estimate the execution time it will request.This corresponds to SLA in a conventional IT-based SOA system and is referred to as M-SLA. Because thedetailed specifications of M-SLA need to be harmonized with SLA, it will be specified at a later date inaccordance with SLA developments.9.4.4 Automatic TransformIn the FIMS Framework, it will be possible for Mediation that resides in the Media Aware Bus to provideautomatic transformation by using the Media Descriptor. But since the support of automatic transformationdepends on the system design policy, it shall not be made mandatory in the FIMS Framework.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 85 of 89

FIMS Media SOA Framework Phase1 (Preliminary)9.5 Security and Identity (Informative)Due to the high value of the intellectual property passing through the system, it is critical that security bemaintained and access provided only to those with proper authorization. There are several types of security thatcan be implemented across the SOA: agent‐based security, message based security, watermarking, and DigitalRights Management. Typical media enterprises will require most if not all of the security provisions. Agent‐basedsecurity involves keeping track of the various participants in the SOA, and doing this correctly will no doubtrequire some sort of identity management infrastructure.Identity management technology is well developed in IT, and can be put to very good use in SOA middleware.Instead of using disparate repositories and application‐specific methods to authenticate users and securesystems, identity management tools allow the integrator to unify all of an enterprise under a single repositoryand management system of user data. This allows easy changes to user information and quick provisioning ofnew users. In an integrated SOA, identity management solutions also allow for role‐based views into data.In the FIMS Framework, we propose to select the technologies as appropriate from the existing securitystandards, and to provide guidelines on how to use them specifically for the FIMS Framework.9.5.1 Security ConcernsFunctional aspects of security: These aspects of security are standard in the sense that they exist even withtraditional applications as well. These are:• Authentication— Verifying identity of users.• Authorization— Deciding whether or not to permit action on a resource.• Data confidentiality— Protecting secrecy of sensitive data.• Data integrity— Detecting data tampering and making sure neither the sender nor the receiver candeny the message they sent or received.• Protection against attacks— Making sure attackers do not gain control over applications.• Privacy— Making sure the application does not violate the privacy of the users.Nonfunctional aspects of security: These aspects are nonfunctional in the sense that they do not directly relateto security. Instead, they are required to make sure that a security solution works well in an enterprise setting.These are:• Interoperability— This concern is specific to SOA, where different security solutions must not breakcompatibility of services that are otherwise compatible.• Manageability— This concern is bigger for SOA, as a security solution needs to protect many differentservices.Ease of development— This concern is common for any security solution. Be it SOA or traditional applicationdevelopment, complexity reduces adoption of any security solution.9.5.2 SOA Application Security ModelsBy lowering long-standing barriers between applications, SOA forces us to rethink how we approach security. Atthe same time, SOA fortunately allows a few new approaches, thanks to the standards it supports, that fit thechanged requirements of application security. These include:• Message-level security• Security as a service• Policy-driven securityPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 86 of 89

FIMS Media SOA Framework Phase1 (Preliminary)9.5.3 Message-level SecurityMessage-level security entails encrypting or otherwise securing the messages that pass between services. WebServices, the most widely used technology for implementing SOA within an enterprise, is an XML‐basedcommunication protocol for exchanging messages between loosely coupled systems. Web Services provides anexcellent toolset to accomplish message‐based security, with technologies like XML encryption and signature. Inaddition, the most well‐accepted technique for achieving message‐based security in a Web services based SOAis to use a standard known as WS‐Security. WS‐Security goes hand‐in‐hand with standardized technologies likeSOAP to secure messages and endpoints. It provides end‐to‐end security, which means that a message issecure even if it passes through a number of routing steps in between its source and destination.9.5.3.1 Security as a ServiceFigure xxx - NIST SOA Message Based Security PatternA security service can offer applications the ability to authenticate, authorize, encrypt/decrypt messages, signmessages/verify signatures, and log messages. It may also scrub messages to protect applications againstknown and unknown vulnerabilities. Applications might still need to know a little bit about security—forexample, they may need to know how to invoke a security service and use the information provided by thesecurity service in return—but the meat of the security logic can be executed by a central security service.The idea of a security service is in some ways similar to the idea of an application service, and in some waysdifferent. Like an application service, a security service should be usable by any application; technologydifferences should not be a barrier. Unlike an application service, a security service is infrastructural and maycome into play even if it is not explicitly invoked. For example the security service may be implemented as partof the ESB or by application-aware network devices.9.5.3.2 Policy-driven SecurityThe idea behind policy-driven security is simple. Security requirements and mechanisms must not be hard-wiredinto applications. Instead, security requirements of an enterprise should be declared separately as a "securitypolicy."Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 87 of 89

FIMS Media SOA Framework Phase1 (Preliminary)A security policy declaration becomes handy in many ways: It separates security logic from business logic,leaving the former to security specialists. It becomes easier to ensure consistency of security enforcementacross multiple applications. Most importantly, interoperability is enhanced as policies of involved parties can becompared to figure out how to make their security implementations compatible.9.5.3.3 Service securityThe framework should support WS-I Basic Security Profile 1.1 standards and X.509 v3 security tokens anddigital certificates for public keys and message encryption and signing. Support level used will depend onfeatures of third party systems used and configuration desired by customer.9.5.3.3.1 Access management9.5.3.4 Media security9.5.3.4.1 Digital Rights Management (DRM)9.5.3.5 Client & Message SecurityMost services require a user to establish his identity before his requests are served. This is because:• Security restrictions require that services be provided only to authorized users. While it is not alwaysnecessary to determine user identity to figure out if a user is authorized, most often it is.• Service logic requires the knowledge of who the user is. For example, if you are checking email, theemail service needs to know whose messages it needs to return.9.5.3.5.1 AuthenticationAuthentication of a client or user can be provided by the organization’s existing Identity Managementinfrastructure (LDAP, Active Directory, etc.) or by a local (within the Media SOA system) identity database. Thefunction of authentication is to validate the user’s identity – username and password – so that his/her rights,permissions, and privileges can be established.Most secure media systems require that each user have a unique identity and password. Shared logincredentials are not permitted.9.5.3.5.2 AuthorizationAfter the user’s identity has been confirmed by a trusted system, his/her rights, permissions, and privilegesmust be established. This may be a local function (within the Media SOA system) or a service provided by theorganization’s existing Identity Management infrastructure.Traditional IT based systems often use membership in security groups to define permissions and privileges forusers. Controls can be very granular and are based on projects, file systems, directories, or individual files.9.5.3.5.3 IdentityOnce identity and permissions are established, these may be encoded into a security token which can be usedby the client process to request access to media and services.9.5.3.5.4 LoggingMedia systems typically have a requirement that all actions and operations that “touch” media files be logged ina secure database. This allows forensic analysis of any improper or unauthorized access or modification ofsensitive media content.This requirement can be difficult to support in many facilities that allow direct access to SAN and NAS filesystems by user workstations and applications.9.5.3.6 Database Security9.5.3.7 Network SecurityPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 88 of 89

FIMS Media SOA Framework Phase1 (Preliminary)10 Framework Extensions FIMS10.1 Framework lifecycle10.1.1 Re-evaluation10.1.1.1 Pre-requisite standards10.1.1.2 “Eat our own dogfood”10.1.2 Taxonomy10.1.2.1 Enumerations10.1.3 SLA Ontology10.1.4 Submissions to WGPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 89 of 89