Media.Manager namespace er designet til at håndtere mediefiler og metadata fleksibelt og generisk. Dvs. at håndtere klip af video og audio samt tilhørende tekst. Det tilbyder transkodning af video / audio fra et format til et andet, manipulation af billeder, fil kopiering samt andre basale og nødvendige operationer når man skal arbejde med digitale medier.

Samtidig håndteres metadata. Metadata er tekster og ord som beskriver mediefiler både i forhold til mennesker og maskiner. I forhold til mennesker bruges metadata f.eks. til at beskrive materialer, så det kan gemmes og fremfindes. I forhold til maskiner kan det f.eks. bruges til præsentation i en web browser og lignende. I den virkelige verden vil medie filer sjældent kunne bruges uden metadata, hvorfor vi i dette skriv fremover vil benævne en samling af metadata og mediefiler som Asset.

Media.Manager namespace kan altså ses som en implementation af Asset Management.

Fordelene ved at samle metadata og filer i assets er, at der opnås størst mulig fleksibilitet. Da assets er en virtuel instans og derfor ikke har nogen fysiske begrænsninger, kan en asset struktur benyttes i alle tilfælde, hvor man har behov for at arbejde med medier og tekst.

Eksempelvis har et video-asset følgende metadata. En titel, en beskrivelse samt tre filreferencer. De tre filreferencer peger på tre fysiske filer som så udgør de tilknyttede medier - i dette tilfælde en højopløselig video kildefil, en lavopløselig video gennemsynsfil samt en thumbnail billedfil.

Titel og beskrivelse benyttes ved lagring / fremsøgning samt præsentation. Endvidere benyttes thumbnail billedet og gennemsynsvideoen ved præsentation. Den højopløselige kildefil benyttes ved klip af uddrag eller transkodning til andre formater.

Den opnåede fleksibilitet ved at benytte en sådan assetstruktur betyder, at et samlet system skal tilbyde samme fleksibilitet. Metadata håndteringen skal kunne håndtere forskellige datamodeller og filhåndteringen skal kunne håndtere mange formater og filoperationer.

Med hensyn til de fysiske filer er det derfor i praksis nødvendigt at kunne arbejde med kæder af filoperationer uafhængigt af kontekst. Samt håndtere alle tænkelige operationer på alle tænkelige formater indenfor det pågældende systems scope.

Ligeledes med hensyn til metadata er det nødvendigt at håndtere assets uden fast definerede tekst strukturer. Således skal kontekst specifikt metadata adskilles fra generel asset håndtering.

Media.Manager namespace opdeles derfor i tre lag som hver for sig er uafhængige funktionelle komponenter, men som tilbyder ekstra funktionalitet baseret på hinanden.

Media.Manager.WorkFlow

Behandling og håndtering af fysiske filer. Denne komponent varetager generel håndtering og bearbejdning af de fysiske mediefiler. Den tilbyder plugin baserede jobs, som kan afvikles i rækkefølge, og som er komplet uafhængige af kontekst. Dvs. alle jobs er selvbeskrivende og afvikles asynkront. Derfor tilbyder dette lag heller ingen forretningslogik eller dataudveksling som udgangspunkt.

Media.Manager.Logic

Den anden del er koncentreret omkring håndtering af assets. Assets er i systemet en komplet virtuel instans, som er adskilt fra både filhåndtering og metadata. Logic laget tilbyder en række generelle funktioner og klasser til at håndtere virtuelle assets. Disse er inddelt efter type, video, audio, image osv. og indeholder regler og metoder til at konvertere fra det ene til det andet.

Laget er designet til at arbejde sammen med WorkFlow og udstiller altså en programmeringsmæssig indgang (API) sammen med et objekt hierarki.

Media.Manager.Presentor

Den tredje del er præsentationslaget som tilbyder grafisk bruger tilgang til filer og metadata, samt en kontekst baseret metadata model. Denne del vil typisk være en Windows applikation eller en web applikation, som er bygget til det enkelte projekt, da den endelige metadata model er defineret her.

Media.Manager.WorkFlow

Denne komponent er bygget som en asynkron Windows service og tilgås via et socket baseret XML API. Den er bygget til at modtage en liste af jobs, som så afvikles et ad gangen og i rækkefølge.

Grunden til dette er, at fil jobs i en asset kontekst tit afhænger af hinanden, således at efterfølgende filoperationer ikke kan udføres, med mindre at først kommende jobs er lykkedes. Eksempelvis består det overordnede job "Klip et uddrag ud af en video og lav en gennemsynsfil af den nye video" af flg. underjobs.

1. Klip uddrag af video
2. Transkod en gennemsynsfil af ny videofil

Job nr. 2 er afhængig af, om job nr. 1 lykkedes, hvorfor at jobkæden skal stoppes hvis job nr. 1 fejler.

Ligeledes er den konstrueret til at håndtere transaktioner, således at jobkæden kan rulle tilbage, hvis der sker en fejl. I ovenstående eksempel vil det være uhensigtsmæssigt at have den ny kildefil fra job nr. 1 liggende, hvis job nr. 2 fejler. Transaktioner sikrer, at kildefilen fra job nr. 1 slettes, hvis job nr. 2 fejler, således at konsistens i det overordnede system sikres.

Media.Manager.WorkFlow er plugin baseret, således at hvert job udføres af et dertil konstrueret plugin. Dvs. at selve servicen afvikler jobkæden ved at kalde forskellige plugins og vente på at de bliver færdige eller fejler. Servicen styrer således at afviklingen sker i den rigtige rækkefølge samt at transaktioner bliver overholdt. Servicen er endvidere multi trådet og kan afvikle n antal samtidige job kæder.

Plugins udvikles i .NET ved at implementere et interface. Denne konstruktion sikrer maksimal fleksibilitet ved altså at lave plugins til lejligheden, hvilket sikrer en høj grad af integrations muligheder imod eksisterende og nye systemer.

Media.Manager.Logic

Logic laget består af en række klasser som repræsenterer de forskellige medie typer som kan behandles i systemet. Video, Audio, Image og File. De implementerer alle det samme Interface [IBinary] og er i essensen et API til håndtering af konvertering og placering af fysiske filer.

Koden kommer som en .NET dll som kan refereres direkte. Endvidere indeholder biblioteket klasser til at kalde Media.Manager.WorkFlow for fuld integration Media.Manager namespace.

/// <summary>

/// Interface representing a binary file

/// </summary>

publicinterface IBinary

{

    /// <summary>

    /// Human readable string for describing the object.

    /// </summary>

    string Token { get; set;}

    /// <summary>

    /// File extension og the desired output

    /// </summary>

    string Extension { get; set;}

    /// <summary>

    /// Url to use when writing the binary

    /// </summary>

    string UploadUrl { get; set;}

    /// <summary>

    /// URL to use when reading the binary

    /// </summary>

    string DownloadUrl { get; set;}

    DateTime Created { get; set;}

    /// <summary>

    /// The Xml used to create the specific object. This is useful when serializing the

    /// object to disk.

    /// </summary>

    XmlElement CreateXml { get; set;}

    /// <summary>

    /// Method for converting object to another IBinary type. For example one video size

    /// to another video size.

    /// </summary>

    /// <param name="Destination">IBinary object which holds specifications for the

    /// desired output</param>

    /// <returns>Returns a list og actions to use with Manager.WorkFlow</returns>

    ActionList ConvertTo(IBinary Destination);

    /// <summary>

    /// Serialize an instance to XML for database

    /// </summary>

    /// <returns>XML as string</returns>

    stringSerialize();

}