Introduction

Media Extender provides a flexible and powerful approach for defining processes involving media content and services. Media Extender provides support for adapting media formats or moving content through the use of media-sensitive metadata.

This article will tell people how to use Media Extender to setup the mediation facility for effective media or rich content management. The paper introduces two common scenarios: the first one enables media industry people quickly and automatically to locate candidate service from a service registry, selecting those which can consume the input media content; the other one enables media industry people to create a process to convert media formats or move content when a media file can not be directly handled by any candidate service.

Readers are required to have some skill experience of WebSphere Process Server/WebSphere Enterprise Service Bus/WebSphere Integration Developer(WPS/WESB/WID) and have some knowledge of media content and services.

Why Media Extender?

The proliferation of new content formats and distribution channels (mobile devices, IPTV, Web, CD/DVD) is accelerating the growth of workflows for media production, processing and distribution. However, digital media contents are acquired from different contributors in multiple formats, and required processing and distribution to a variety of formats matching client devices. If using fixed and explicated workflow to support multiple formats, multimedia tools and distribution channels. These variations require recurring updates to the workflow or the creation of new ones. This approach is labor-intensive and increases time to market. These challenges can be mitigated by the adoption of dynamic workflow composition strategies introduced by Media Extender.

There are two levels workflow composition in Media Extender SOA approach as shown in Figure 1:

Statics composition level:

A workflow realizing the media process as an abstract workflow based solely on high-level business requirements and does not have to consider technical requirements such as content adaptation, content movement. The abstract workflow is then extended at run time by dynamic composition.

Dynamic composition level:

The abstract workflow invokes the target service through Media Extender. The mediation flow looks up a target service that can consume the media object or applies a dynamic matching by create an execution plan which resolves the media mismatching before invoking the target service.

The execution plan is then provided to the SubProessBP engine for parsing and execution.

Back to top

Media Extender Fundamental

The high-level Media Extender architecture overview is shown in Figure 2. The client workflow will invoke the Media –Oriented ESB to process the media. Media Extender will work with Service Registry and service providers to complete the service selection and media-awareness routing.

In the Service Registry, the service wsdl files and service properties files (*Descr.xml) are used to describe the each media-oriented service. The wsdl files provide the service API implementation parameters while the properties files describe the characteristics of the service and the capabilities it provided. The relationship associated each WSDL service definition with the XML service metadata is using the Resource Description Framework (rdf) tag. And the service registry type can be WebSphere Service Registry and Repository (WSRR) or file system based.

Media Extender provides two capabilities to enhance the Enterprise Service Bus (hereafter called ESB) make it as Media-Oriented ESB: one is media awareness, the other one is content based routing. The former one can be treated as plus version of service endpoint lookup which provided by ESB. Media Extender can select appropriate service based on media content, metadata, location and policies. While the media awareness routing provides transformation support for mismatching between media/content and target service. It support necessary implicit transcoding and transport the media if next service requires another format or data movement. The implicit service (so call inserted service) and target services invocation sequence will be organized as an execution plan.

The media is treated as the referenced metadata in Media Extender, which means media control flow and real media processing flow are splitted. Media Extender focuses on control flow to handle the content processing by using the message which contains the media properties while real media processing such movement and format transform are done in other Bus.

The properties of the media are extracted and constructed as the MPEG-21 digital items, then contained in the incoming message of Media Extender. The typical MPEG-21 digital items structure is illustrated in Figure 3. The media info is carried by "didl:Container/didl:Item/didl:Component/didl:Descriptor/didl:Statement/md:MediaDescriptor". For the other media metadata format, such as MXF or Mpeg7, it can be also carried by MPEG-21 digital items but need a mapping to DIDL format which can be digested by Media Extender.

Media Extender components:

The whole components provided by Media Extender are shown in Figure 4: three ESB mediation primitives to construct the ESB mediation flow and Subprocess engine which parses the execution plan and processing service invoke.

MxEndpointLookup dynamically route messages to appropriate media-oriented service endpoints by searching the services registry which can be file system based or WSRR based.

MxRules calculates what other services invocation are needed to transform, or move the media before it is delivered to the target service. The result can be directly service invocation or generating an execution plan, if there is mismatching.

MxDynSelection calculates the cost associated with each one of the candidate services, and selects the one with the lowest cost. The following dynamic properties are used: CPU load, Available storage capacity, Available network bandwidth and Job queue size.

Subprocess engine is BPEL based application, which parses the execution plan, prepares the inserted service invoke, updates the media metadata based on the response of the inserted service, and finally invokes the target service.

Back to top

Use Media Extender to process the content scenarios

The Media Extender usage scenarios will be introduced in this section. A typical series steps for digital media distribution is demonstrated in the Figure 5. The video is ingested as a digital asset, it will be analyzed and classified by topic. After that, the asset will be stored in a repository as potential resource. When the company decides publish this asset, the editor will review the content and do some necessary modification. Once the asset passed the review, it can be delivered by multiple channels based custom requirement. At above steps, Media extender can involve the repository selection, review promo generation and multi-channel delivery. This section will discuss them separately.

Media awareness selection scenario

It is supposed there is no format and location mismatch between digital asset and repository service in the paragraph. It can easily demonstrate the capability of MxEndpointLookup due to the target service can be directly selected. The mediation flow constructed by MxEndpointLookup can be used complete repository selection shown as Figure 6.

The properties of MxEndpointLookup primitives used for endpoint searching are:

• Service port type, namespace and version - Service WSDL information
• Xpath Digital Item - User can specify the xpath of "didl:Container" within incoming message
• Match Policy - Return all matching endpoints or return first matching endpoints
• Classification - Search for objects that match a particular service classification
• User Properties - Any properties end user want to used for service endpoint query
• Target Output Properties - The properties used for searching transcoder and transport service. The "Output Format" and "Output Location" are two restricted options
• Input Protocol Matching - User can specify the matching policy performed on the input protocol of the media resource referenced by the DID. "Default" option means check for matching, while "NoHostname" means ignore checking.

There are 2 types of service searching:

• content based
• no content based

The first one will analyze the media descriptor, and found out the service can handle the media characteristics. The matching service endpoint address will be the result of this selection. The end user need specify the Xpath of MPEG-21 digital item in the input message which indicates the media matedata descriptor location.

The second searching type is non-DIDL/content based. It is the similar as ESB EndpointLookup primitive. But enhance it by supporting the file system based service registry. Further more, the end users can directly specify service identificaiton as primitive user properties for searching parameter, such as "repositoryID" for Repository service lookup.

Here is an example to demonstrate the MxEndpointLookup function. The input message carried media metadata as shown in List 1, the whole message please refer the attachment 1- InputMessage.xml. The MxEndpintLookup will check the service registry to find out the Repository which can store the input "testfile.wmv" which format ID is "wmv.1", located in "server1" and supported protocol is "file". Actually other parameter such as QoS, service classification etc. can also used for querying the service based on the MxEndpintLookup properties setting. The return result can be controlled by "Match Policy" setting. If end users prefer "returning the first matching service", the result will be set in "/headers/SMOHeader/Target/address" of SMO message. If end users choose "returning all matching endpoints", a set of endpoint will be listed in "/context/primitiveContext/EndpointLookupContext".

Note! If change service selection from storage service to Transcoder or Transport service, the "Target Output Properties" under the primitive properties advance panel should be set for "Output Format" or "Output Location" separately.

        
<?xml version="1.0" encoding="UTF-8"?>
<didl:Container xmlns:didl="urn:mpeg:mpeg21:2002:02-DIDL-NS">
 <didl:Item>
  <didl:Component>
   <didl:Descriptor>
    <didl:Statement mimeType="text/xml; charset=UTF-8">
     <md:MediaDescriptor xmlns:md="http://md.wemx.ibm.com" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://md.wemx.ibm.com md.xsd ">
       <MediaFormat ID="wmv.1" extension="wmv" format="Windows Media" info="WMV Media">
        </VideoFormat>
        </AudioFormat>
       </MediaFormat>
     </md:MediaDescriptor>
    </didl:Statement>
   </didl:Descriptor>
   <didl:Resource mimeType="video/quicktime" ref="file://server1/testfile.wmv" />
  </didl:Component>
 </didl:Item>
</didl:Container>
			

Content based routing scenario

In the steps for media distribution shown in the Figure 5, media production review and multi-channel delivery can utilize the content based routing provided by Media Extender. The original content of the media always need some adjust before consumed. For example, the media format of review promo is the lower resolution copy of original asset. And different delivery/publish services located in different areas require various input format. This powerful capability of content based routing is using the implicit inserted service to resolve the mismatching between media and target service.

Content based routing is the backbone of the dynamic composition discussed in section 1. Here, only use the multi-channel delivery as the example to explain its work mechanism. The business professional no need take care of potential steps handling the formant converting and movement of content during multiple channel delivery workflow modeling. Content based routing of Media Extender will calculation of additional process steps required before the final concrete publisher service call. The mismatching handling is transparent for client workflow which can reduce the work effort and improve the re-use.

The mediation flow constructed by MxRules can be used multiple channel publish processing is shown as Figure 7.

The properties of MxRules primitive are:

• Service port type, namespace and version - Service WSDL information
• Xpath Digital Item - user can specify the xpath of "didl:Container" within incoming message
• Xpath Output Format – User can specify the xpath location of the media format descriptor that contains the expected output format to be produced by the target service (especially for transcoder service)
• Classification - Search for objects that match a particular classification
• Enable Dynamic Selection – Enable cost calculation for target service or execution plan (count the each inserted service and target service). The one has the lowest cost will be the final result
• Enable Inserted Service QoS – Restrict use the inserted service that matched required QoS to construct the execution plan

The MxRules mediation primitive operates in four stages:

• 1. A set of potential target services is established. This set is passed into the "/context/primitiveContext/EndpointLookupContext" of the input SMO, or is created using a MxEndpointLookup for services pre-selection. The selection can be DID based or non DID based in this stage. If there is no concreted service can be found out in the service registry during pre-selection, an abstract service which characterized by the portTypeName, namespace, and classification properties specified on the MxRules primitive will be created as target service.
• 2. Based on the properties of the media described by the Digital Item and the target services, the MxRules determines if the targets can consume the media unchanged, or if it requires the media to be format transformation in preparation. If required, a suitable transcoder is sought in the service registry.
• 3. If there is the need for data movement between input source and transcoders or targets is considered, based on service metadata.
• 4. Execution Plans which contain the inserted service and target service will be created and set in the SOAPHeader of the SMO. The structure of execution plan description is shown as Figure 8. The whole SMO message propagate from MxRules subflow terminal please refer the attachment 2- OutputMessage.xml

We would like discussion a little bit more about Execution Plan structure. Because MxRules maybe generate multiple execution plan, the "executionPlanID" used to identify the one propagate to MxRules subflow terminal. The value of "xpathDID" indicate the xpath of "didl:Container" handled by MxRules which will be valuable for multiple DID usage, more details please refer the part 2 of the series topic. The value of "messageName" will be used reserving the input message type for service gateway scenario. Each service (inserted service and target service) within Execution Plan is organized as "ServiceInstance", it will record service wsdl portType, operation, endpoint address, some properties and classification. Any properties related for service implementation and function logic can be set in "ServcieProperty" field. And classification divided to serviceClassfication which indicate service type, when operationClassification used identify the Synchronize (RR) and Asynchronized (RRN) operation by using the "SyncAsync" flag.

If there is a set of execution plan generated by MxRules, the first one will be the output result propagated to "subflow" terminal of MxRules. If end users enable the "Dynamic Selection" or "Inserted Service Qos", the whole number of execution plan generated by MxRules may be discounted and only the one met the proper condition can be output result. It will be discussed as below:

Use dynamic selection will return the lowest cost execution plan. The construction of the cost based on each service cost in the execution plan. The weighted sum of the metrics describing CPU load, available storage capacity, available network bandwidth, and job queue size are counted. And only the each service whose "available" property set to true condition will used calculation, otherwise this execution plan will be dropped. The matrices are recorded in the dynamic registry of Media Extender which collected by an independent monitoring system.

Enable Inserted Service Qos will exclude the execution plan whose service instance can not match the QoS requirement of the inserted service, such as the high transfer speed or high quality of transcoder output.

The whole SMO message propagate from "subflow" terminal of MxRules please refer the attachment 2- OutputMessage.xml

Execution plan engine

To complete the content based routing scenario, such as multi-channel delivery, the execution plan will be parsed in the SubProcessBP - execution plan runtime engine which is demonstrated in Figure 9.

The SubProcessBP takes the input message propagated from Media Extender mediaiton flow and extracts the MPEG-21 Container which used to create the request message sending to inserted services that process the referenced media files. After getting the response from inserted service, SubProcessBP updates the MPEG-21 description in preparation for a subsequent inserted service, or for the final target service. This step will be recurred until all service instance within executon plan have been invoked without error.

For example, it is supposed there is the service sequence as Transcoder1 to Publisher1 for mobile phone video delivery. The original DID container is mapped to the DID input parameter Transcoder1 service. Finally, the updated DID component from the Transcoder1 is mapped to the DID container of the target Publisher1. When the target Publisher1 work complete the original media has been delivered to required device with the specified format. The client workflow and mediation flow can be re-used for other channel delivery (IPTV, Web and DVD/CD) without the change as mobile phone.

Back to top

Summary

This article provided a brief for Media Extender fundamental concept. And author used two typical scenarios to demonstrate the Media Extender can reduce the efforts setting up the media processing workflow, help media industry people achieve a dynamic and automatic media content management.

The sample mediation flow used for multiple channels delivery scenario in this artical has been attached in Downloads section.

Back to top

Downloads

Information about download methods

Notes

1. Sample input message for Media Extender.
2. Sample SMO message propagate from MxRules subflow terminal.
3. The project intechange (PI) file for multiple channels delivery scenario

Resources

Learn

• "Media Extender for WebSphere Process Server product page"
  Product descriptions, product news, training information, support information, and more.
  
  
• "Redbook: Abstract Service Definition for Media Services"
  The Abstract Service Definition (ASD) for digital media. The ASD provides a flexible and extensible mechanism to access classes of media services independently from the particular implementation of each service at an appropriate level of abstraction.
  
  
• "MPEG-21 Standard"
  MPEG-21 Standard
  
  
• "What's new in WebSphere Enterprise Service Bus V6.2, Part 1: Overview"
  (developerWorks, Jun 2009) Part 1 describes the new or enhanced transport protocol bindings, data binding capabilities, mediation primitives, and declarative flow control introduced in WebSphere ESB V6.2 and its associated tooling, WebSphere Integration Developer.
  
  
• "What's new in WebSphere Enterprise Service Bus V6.2, Part 2: Service gateway support"
  (developerWorks, Jun 2009) Part 2 describes the service gateway and policy capabilities.
  
  
• "WebSphere ESB developer resources page"
  Technical resources to help you use WebSphere ESB as a flexible connectivity infrastructure for integrating applications and services to support an SOA.
  
  
• "WebSphere ESB information center"
  A single Web portal to all WebSphere ESB documentation, with conceptual, task, and reference information on installing, configuring, and using WebSphere ESB.
  
  
• Browse the technology bookstore
  for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Liang Rui is a software engineer on WebSphere team of IBM CDL. He is working for WebSphere Process Server development and was the developer of WebSphere Media Extender for WPS (Media Extender).

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Why Media Extender?
• Media Extender Fundamental
• Use Media Extender to process the content scenarios
• Summary
• Downloads
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers