![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Media Extender for WebSphere Process Server (Media Extender) provides extended service mediation facilities that can be used as components in workflows that handle media content. It enables the integration of business and content systems together for effective and dynamic rich content management. Comparing with Media Extender version 6.2, many new features have been implemented in 7.0 to better integrate with the WebSphere BPM&C portfolio and improve the capability of content-aware routing and management.
This article covers the new features and functions in Media Extender v7.0, including adopting Abstract Service Definition (ASD) media service interfaces, evolution of the Media Hub Solution, enhancement of MxLookup, capability of controlling Quality of Service (QoS) requirements of inserted service, supporting user specific media metadata in media process workflow decision making and influencing service routing.
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. Familiarity with the article "Getting started with Media Extender for WebSphere Process Server Part 1: Overview" is assumed.
ASD usage in the Media Extender
The Abstract Service Definition for Media Services (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. This allows the realization of the SOA principles, simplifies the orchestration and provides the appropriate mediation taking into consideration the complexity of media operations and associated metadata. By using ASD, the ISV can focus on service implementation to provide the desired media functions. ASD enable easier connect to Media Service Bus, inter-operation with other ISV or customer service, and better scalability and fault/error handling
There are 11 service interfaces definitions cover typical media operations:
- Transcoder - to perform conversion of one media format to another or to encode from analog source into digital media format
- Watermark - to embed a unique watermark in a digital media file
- Transport - to perform data movement of large media file from one server to another
- Repository (Digital Asset Management) - to add new asset, retrieve or manage existing digital asset of a catalog or repository
- Media Verification - to perform analysis or validate specific characteristics of the digital media file, normally as part of the quality assurance process
- Fingerprint - to perform forensic fingerprinting analysis of a digital media file
- Physical Asset Management (PAM) - to add new asset or manage existing physical asset (e.g., video or audio tapes) in the catalog or repository
- Resource scheduler - to schedule new or manage current available resources
- Publish - to perform packaging and publishing of the digital media to one or more distribution channels
- Edit - to help manage the Non-Linear Editing (NLE) process of a digital media
- Digital Rights Management (DRM) - to manage media asset intellectual rights to help prevent illegal copying or conversation to other format
ASD is adopted in Media Extender v7.0
The samples SubProcessBP and 2 non service gateway mediation flow shipped with the Media Extender provide supporting for the ASD.
In SubProcessBP, inserted service processing is based on ASD definition. The SubprocessBP will extract the MPEG-21 "didl:Container" from ASD defined message structure and map it to the request message of inserted services. Each of the inserted service will validate and propagate to matching process branch based on the service classification, port type, port type namespace, and the invocation type which defined in ASD. Each inserted service request message is organized as ASD defined. And fault handling of service invoke will package the fault/exception message followed the ASD recommended.
Actually SubprocessBP also support inserted service which non ASD supported. When customer use transcoder and transport services are non ASD supported, there should be a mapping between non-ASD service and ASD service. The sample SCA module assembly is shown as Figure 1.
Figure 1. ASD and Non ASD service mapping
2 concreted service (non service gateway) mediation flow using ASD Repository service interface demonstrate how to assembly the primitives provided by Media Extender and base WESB to achieve media processing Repository lookup and construct execution plan for invoke Repository if there is media format or location mismatching.
Each interface defined in ASD exists in two versions:
- Request/Response (RR) where a service request has a simple response message. This style of the interfaces is simple to use in business workflows.
- A synchronous request/response with asynchronous notification (RRN) pattern where the initial response is an acknowledgement of the request, and the real service response is delivered as a callback. This style of interface can simpler to use as a service implementation.
An adapter can be used to convert between the two styles of interface, and an example of this is provided in the project ASDRRtoRRN which shipped within Media Extender package. The project ASDRRtoRRN, has an SCA binding which can be used by client business processes and contains a BPEL process that represents a proxy Repository that can call either of the sample mediations, depending on the wiring of the reference to one of the imports in the assembly. And ASDRRtoRRN application acts as an adapter, which handles conversion of the Request/Response style to the Request/Response With Notification style. It can be used as a reference for other service interface conversion.
The sample ASD wsdl files and service description files (*.Descr.xml) are also included in Media Extender image. It can be used for as file system based service registry.
Evolution of the Media Hub Solution
To exploit the Media Extender, a system is required which is capable of acting as a service to accept and interpret the output messages from the Media Extender mediation flows. The Media Hub Workflow Builder Services Asset (Workflow Builder) provides this support in the early version of Media Extender such as version 6.2. The client workflow was created in Workflow Builder editor and the Execution Plan interpreted in Workflow Builder runtime engine.
Media Extender v7.0 removed this highly dependence with service asset, to enable the product better integrated into WebSphere BPM&C portfolio. The client workflow can be modeled in WebSphere Business Modeler (WBM) and constructed in the WID. The execution plan parsing and service invocation control can be completed in Sample SubProcessBP which is a BPEL application run on the WPS.
SubProcessBP execution plan engine
This article will give a brief introduction for SubProcessBP work mechanism, the workflow diagram is shown as Figure 2, here we only show the inserted transport and target service process to simplify the statement (it is also fit for inserted transcoder processing).
Figure 2. The workflow of SubProcessBP
In the step 1, the execution plan will be extracted from message to control the service invocation sequence. The MPEG-21 Container which carrying the media metadata will be extracted and components of it will be send to inserted services that process the referenced media files and updates the MPEG-21 description. The number of service instances in the execution plan will used to control the process loop which shown in step 2. SubProcessBP will check current service instance and find out the matching processing branch in step 3. In step 4, it completes the inserted service invocation preparation: the original DID container is mapped to the DID input parameter of the inserted service request message; callback parameters are set correctly for the RRN service type; the service endpoint address is also ready for inserted service dynamic invocation during this step. The request message will be sent to inserted service in step 5. In this step, the fault handling will treat the business fault and runtime fault during service call and return the fault message to client workflow for furthermore analyze. For the RRN service type, a correlation set will be used to identify the callback message and additional step picking up the callback is required. The results from the inserted services are used to update the DID container in preparation for a subsequent inserted service, or for the final target service which is completed in step 6. When all the inserted services has been handled, the target service invoke will be done in step 7-8 and reply to result to client workflow through the mediation flow who invoke the SubProcessBP.
Service Gateway Mediation to achieve Media Oriented ESB
To implement the real media-orient ESB, Media Extender shipped a sample Service Gateway mediation flow to handle the request from client workflow. It is the second evolution for Media Hub Solution. It based on WESB service gateway new feature, using single gateway interface to accept multiple request and complete the media awareness selection, content based routing and service dynamic invocation. The media module and media flow assembly are shown in Figure 3.
Figure 3. Service gateway mediation flow assembly diagram
The mediation module accept the JMS binding input and rout the message to direct target service calling or SubProcessBP execution plan processing. The mediation flow covers common media service endpoint selection, execution plan based routing, demonstrates the capabilities of enhanced endpoint lookup and inserted QoS which will discussed in later sections.
Two "LocateTarget" MxEndpointLookup supporting MPEG-21 DID and non DID searching seperately, are used to pre-select the target service. The query criterias are loosed for non DID endpoint lookup, for example, only use the service ID or porttype and classification. If there is at least one candidate service, the message will move the filter inserted service by QoS pamaters, here we use the Transport with required transfer priority as example. This step pre-select a set of inserted services meet the sepecified QoS requirement. After that, the message will be propagated to MxRules primitive named Execution Planning. The direct out or execution plan constructed by QoS restricted inserted service and target service will be the result output. Finally the message will send to proper Callout node for next step.
When candidate target or execution plan can not be found out, the message will be propagated to fault handling custom primitive and return to client workflow by Fault node. At the mediation response flow, the normal response and fault info of target service or SubProcessBP will be also taken care by mediation fault handling and return to client workflow. The code in fault handling custom primitive is shown in List 1.
Listing 1. Sample code of fault handling in servcie gateway mediation flow
//create fault message body
ServiceMessageObjectFactory factory = ServiceMessageObjectFactory.INSTANCE;
DataObject newBody = factory.createServiceMessageObjectBody(
new QName("http://com.ibm.wemx/SoapFault","SoapFault"));
// create faultBO
DataObject exception = DataFactory.INSTANCE.create(
"http://schemas.xmlsoap.org/soap/envelope/", "Fault");
exception.set("faultcode",
"http://com.ibm.wemx/WEMXRulesServiceGatewayMd#RequestPathFault");
exception.set("faultstring",
smo.getContext().getFailInfo().getFailureString());
exception.set("faultactor",
"http://com.ibm.wemx/WEMXRulesServiceGatewayMd/RequestPathFault");
exception.set("detail", smo.getContext().getFailInfo());
newBody.set(0, exception);
smo.setBody(newBody);
|
In Service Gateway mediation, user can specified the xpath of Media Extender primitive properties as wildcard xpath expression to ignore concrete input message type. Both "/body/*/RequestDID/Container.0" and "/body/message/RequestDID/Container.0" are supported.
Enhancement of MxEndpointLookup
The other new feature introduced by Media Extender v7.0 is Enhancement of MxEndpointLookup. In previous version, end user must specify the Xpath Digital Item of MxEndpointLookup properties. It should be point to the DID Container of the incoming message. The end user have to use the ESB endpoint lookup primitive for non-DID message. In version 7.0, MxEndpointLookup well support non-DID and DID endpoint lookup from the WebSphere Service Registry and Repository (WSRR) or file system based service registry. When end users keep Xpath Digital Item to empty, the MxEndpointLookup can be treated as non-DID lookup, the portType, portType namespace, classification and user properties will be used to construct the service registry query statement. Otherwise the Xpath Digital Item, Target output properties and Input protocol will be added into query. Figure 4 is illustrated the properties of MxEndpointLookup primitive.
Figure 4. The properties of MxEndpointLookup primitive
Capability of controlling QoS requirements of service
In the custom product environment, there are different service provided various QoS level to meet the specific business requirement. For example, high definition videos subscribed by the VIP customer require high resolution/quality transcoder to transform the original media. Other example, a fast transport service is needed for urgent news publish. In Media Extender V7.0, a new option in MxRules primitive called "Enable inserted service QoS" provides the capability of controlling the QoS requirement during execution plan generation. This article use the Figure 3 mediation flow to explain the work mechanism.
Firstly, one MxEndpointLookup is used to pre-select the candidate target service if target service QoS required. QoS parameters can be carried by input message, and associated query criterias can be defined as the "User Properties" of the MxEndpointLookup primitive. MxEndpointLookup will find out the matching service and set the endpoints information into "/headers/SMOHeader/Target/address" for single matching instance or "/context/primitiveContext/EndpointLookupContext" for multiple matching.
Second, additional MxEndpointLookup primitves are used to pre-select the inserted service with specified QoS parameters, such as quality for transcoder service and speed for transport service. The setting of primitive is the same as above. The result will set into "/context/primitiveContext/EndpointLookupContext" (must specify the matching policy to "return all matching endpoints")
In MxRules, execution plan will be filtered by the pre-selected target and inserted services (service pool). Only the execution plan constructed by services within service pool will be returned as result. If execution plan contained any service excluded out of service pool will be dropped.
All of above QoS criterias can be the primitive promoted properties which can be modified the value during runtime by adding the PolicyResolution WESB primitive into media flow as shown in Figure 5. It can make the mediation flow more reusable. More information about dynamically change the primitive promoted properties please refer the WESB infoCenter.
Figure 5. Dynamically change the primitive promoted properties
Supporting user specific metadata
Media Extender processes the media by using content passed by reference technology which using media metadata not real media. The media metadata is carried in the "didl:Component" of MPEG-21 DID. The example of DID structure shown in the top of Figure 6 is complex and iterative. In previous Media Extender version, there are many limitation for DID process as shown in bottom of Figure 6.
- (1) Single "didl:Item": no iterative structure supported, only one "didl:Item" can be placed under "didl:Container".
- (2) Fixed structure: the media metadata must placed in "Container.0/Item.0/Component.0"
- (3) Single resource and associated descriptor at pre-determined location: "Container.0/Item.0/Component.0/Resource.0"
- (4) No user specified metadata can be carried by message: only accept the metadata which defined as "md:MediaDescriptor"
In version 7.0, Media Extender support:
- (1) Support the iterative structure with some restriction: "didl:Resources" must have "@ref" attribute and a preceding sibling "didl:Descriptor" element must have with a "didl:Statement/md:MediaDescriptor". In the Figure 6, Resource 2 and 3 do not match this criterias so they will be ignored with the warning information during Media Extender processing.
- (2) Allow carry the user specific metadata.
In custom scenario, incoming message maybe only contain the user specified metadata, for example MXF or MPEG 7, to present media properties. If incoming message not followed MPEG-21 DID format, client workflow is required mapping it into a new MPEG-21 DID message. If incoming message using MPEG-21 DID to carry the metadata, client workflow is required mapping the media metadata in to Media Extender support metadata "md:MediaDescriptor" and creating a new "didl:Descriptor" within the same "didl:Component" to carry it. New Md:MediaDescriptor can be derived from existing metadata or directly extracted from media file as shown in Resource 4 under "Container.0/Container.0/Item.1/Component.0". There are MPEG 7 and mapped "md:MediaDescriptor" existed within same "Container.0/Container.0/Item.1/Component.0"
If other metadata as business logic or media service required can also be presented in MPEG-21 DID message as shown in "Container.0" and "Container.0/Container.0/Item.1". All of user specified metadata will be reserved during Media Extender processing. - (3) If input message contain more than one "didl:Resource" as shown in Figure 6, Media Extender v7.0 can analyse all of Resource matching criterias listed in (1). But only process the first "didl:Resource" in user specified "didl:Container".
For example, when user specify the "didl:Container.0", the MxLookup or MxRules can analyse all the xpath of Resource and MediaDescriptor within this "didl:Container.0", but only search the target service or caculatet the execution plan for Resource 1 (under "Container.0/Item.0/Component.0"), other Resources (Resource 4 under "Container.0/Container.0/Item.1/Component.0", Resource 2/3 under "Container.0/Container.0/Item.0/Component.0" will be ignored but still kept in the message. When the message propagate into SubProcessBP, only the Resource 1 (under "Container.0/Item.0/Component.0") will be constructed the request message of inserted service, DID updating based on reply/response of inserted service will only happened Resource 1, while other Resource DID contents will be unchanged. Finally, the merged DID is passed to target service.
Figure 6. MPEG-21 DID example
This article covers the new features shipped in Media Extender v7.0. Built on existing ESB offering, the new functions will improve the capability of media aware routing and better enable rich media services and Digital Asset Management (DAM) applications to connect as true services in a flexible dynamic workflow environment that brings the power of SOA to media businesses.
The sample mediation flow used for service gateway scenario in this artical has been attached in Downloads section.
| Description | Name | Size | Download method |
|---|---|---|---|
| The sample service gateway mediation flow1 | WemxRulesServiceGatewayMd.zip | 83KB | HTTP |
Information about download methods
Note
- The sample service gateway mediation flow for media oriented bus.
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. -
"What's new in WebSphere Enterprise Service Bus V6.2, Part 3: Mediation policy"
(developerWorks, Jun 2009) Part 3 describes dynamic configuration of mediation flows using mediation policy, including creation, storage, and use of a mediation policy to dynamically configure a mediation flow. -
"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.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
