FIMS Media SOA Framework - AMWA

More documents

Recommendations

Info

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
Page 1 and 2: FIMS Media SOA FrameworkAMWA Specif
Page 3 and 4: FIMS Media SOA Framework Phase1 (Pr
Page 27: FIMS Media SOA Framework Phase1 (Pr
Page 79 and 80:
FIMS Media SOA Framework Phase1 (Pr
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89:
show all

FIMS Media SOA Framework - AMWA

Create successful ePaper yourself

Delete template?

Save as template?