Friday, April 4, 2008

Volantis for Mobile Content Serving (Preliminary Evaluation)

Volantis recently released a GPL'd Community edition of their Volantis Mobility Server. Volantis Mobility Server in essence has three components:
  • Multi-Channel Server (MCS). The rendering engine.
  • Media Access Proxy (MAP). The transcoding engine.
  • Message Preparation Server (MPS). Push based content delivery engine.
The Multi-Channel Server (MCS)
This is the rendering engine. The engine runs as a web application in a J2EE container (e.g. Tomcat). It uses a database for storing configurations and for small setups can also store configurations in XML files instead. The databse table structure is simple and primarily stores the XML defination of content capsules and page layouts. It was interesting to note the way MCS chunks larger content into multiple records for storage instead of using a BLOB column. Each site created is typically a "project" for the MCS. It provides tools built on the Eclipse framework to ease configuration of a "project". It lets you do the following for a project:
  • Have a device capability database. The device database is in the form of a ".mdpr" file. It is in essence a compressed (zip) collection of multiple xml files containing the device characteristics. The device databse is hierarchal, similar to WURFL. Updates to device databse are available for a price. Andrea Trasatti of WURFL is working with DeviceAtlas and Volantis is also a partner of DeviceAtlas. Unfortunately we are not seeing frequent enough updates to WURFL recently. So the Volantis device database could, in future, become far more complete than open source WURFL.
  • Define page layouts. A complex page layout can be created by combining the different simple layout elements provided - panels, grids, sequences etc. Content place holders are named in the layout defination.
  • Define content objects. Content objects are of different types e.g. image, audio, text. For each content object you need to assign multiple content assets (binaries). For each content asset you can specify which class of or which exact device should this be rendered on. This essentially is a content capsule.
  • Create simple pages using the layouts and content objects that the MCS can render. These pages are in a XML based markup language called XDIME. A XDIME page refers to a layout, and for every placeholder in the layout, defines the content object to be displayed.
  • For complex pages you will have to create HTTP (e.g. JSP, PHP) based applications that use the same layouts and content objects and generate a XDIME markup page.
After creating/modifying a project in Eclipse environment, the project needs to be 'imported' into the Volantis server using a tool.

The Media Access Proxy (MAP)
The MAP transcoding engine closely links up with MCS to provide transcoding services. Currently it has only (but comprehensive) image transcoding capability using Java Advanced Imaging (JAI). It however lacks an image 'area of interest' based transcoding scheme. The MAP claims to have a pluggable architecture using which audio and video transcoding can be plugged in, of course the plugins have to be developed by you. Volantis has tied up with Mobixell for joint Mobile Video platform, so we should expect to see some offering in this space.

The MCS before delivering the page connects to a component (the media agent) of the MAP to assess transcoding requirement and changes the content source to point to the MAP. Subsequent request to fetch the content is routed to other components of the MAP that call appropriate transcoder plugins to transcode content.

The Message Preparation Server (MPS)
The MPS provides push based content delivery. It provides APIs (Message Preparation Services API - MPSAPI) that applications can use to push messages to the device. Messages can be SMS, WAP push, MMS or MHTML (.mht format). Content definition for messages are also through XDIME with varying restrictions depending on the message type. For WAP push messages, the MPS can locally store and serve the target page using its message store servlet (MSS) which can be used for short temporary pages that you don't want to or can't serve through the MCS. The MPS has integration interfaces for SMTP (JavaMail), Nokia MMSC and SMPP (Logica SMPP APIs). If the target device type is not known and only the subscriber id is known, MPS can integrate (through pluggable components) with operator device databases to push device appropriate content.

Volantis Community Edition is well packaged, and very useful for organizations looking at coming in quickly to the mobile space.

For large scale mobile content serving and commerce you would need to integrate additional systems that the Volantis Mobility Server lacks to have a complete system.
  • Content Management
  • Charging (Billing)
  • Usage Reporting
  • Workflow Engine
One drawback, I feel, is in the way MCS achieves device based rendering is by tagging contents and layouts with appropriate device identifier. It would have been better if it looked at the device capabilities instead of device names. That way, if a new device came up in the market, as long as the device database is updated, the rendering should work fine. and one would not have to re-visit the layouts and contents to match the new device against one of the contents.


Anonymous said...

Hi. Very good article. Couple of comments (note: I work for Volantis). Actually, couple of sets of comments.

The first set is around the implication that if a new device enters the market you need to create new layouts (and other design stuff). The system's actually designed to avoid this.

Firstly, if a new device is added to the database, then because the database is actually a hierarchy, it should fall back to find policies (layouts etc) in the hierarchy for similar devices - typically there's no requirement to create policies for new devices unless the device is very different from anything for which you've previously created a design.

Secondly, you can create classifications of devices based on attributes, including custom attributes; and then link policies to those classifications.

Thirdly, you can make decisions within the markup against device attributes using the W3C DISelect support - eg only use the following markup if it's a Nokia phone, or if it has a screen resolution of x, and so on.

Finally, if the device is not in the database at all, the server looks at a number of other headers to try and classify it, and will then use the fallback mechanisms to automatically find some policies to apply. Again, this tends to be sufficient in many cases.

The second set of comments is as regarding the requirement for other features for content management and e-commerce. We have other products, built on VMS, which provide these features, including both an embedded CMS and integration with third party CMS's such as Vignette. The product is called Volantis Storefront - it's not available under an open source license and is typically deployed as an enterprise e-commerce solution in very large clients, including operators. We are however also trying to encourage integration of VMS with open source CMS's such as AlFresco, also.

Tanmay said...

Thanks Mark for the explanation. I'm sure I'll be getting more insights and tips as I use VMS further and from the VMS community going forward.