A hello world application in the IPTV world

A hello world application

The other week, I was amused when I read an article analyzing on those who wrote "Hello World" applications.  The article reported that even though it is supposed to be the first and the simplest application written to demonstrate that one has gathered the necessary skills and knowledge to develop the application in the chosen programming language or framework, the work itself does show the experience and skills of the developer. What a coincidence!  This week I explore one of the first customization tasks required to create "A Hello world menu application" in the IPTV world.

When I first worked on the Commercial Client portal (code name: Avalanche), I was lucky to have the foundation of its predecessor (the MCS SDK). I have a jump start over other Solutions Architects and System Integrators who have no previous experience in the design of multi screen applications. As I began to get my hands dirty, it dawned on me that the engineers who designed this new Avalanche portal framework have done an impressive job. The portal is first class :- consistent and extremely customizable with its well designed pluggable framework. I don't get impressed too often, but this is one that really deserves my "kudo".

A bit of history first. The Avalanche portal is part of a large IPTV service provider product's Multiscreen Client Suite family which in turn is part of the company Multiscreen TV solution. It is designed as a ready to go into a client deployment with the only customization needed is put the customer's brand on it.  While this suits most customers, customers who wish to add additional application to the portal must design and develop their own application that integrates well into the portal framework.

An Objective approach

Like all exploration quests, I set myself the following objectives to prepare my training content:-

• Develop an understand of how menus are designed and rendered in the Avalanche portal
• Identify the design patterns used in the menu design

• Build up the subject matter expertise in the menu framework

• Discover and formulate the best practices for this task

Pluggable Design Pattern

As the first entry point to any customer's application, menu customization is normally the first piece of task an IPTV developer needs to tackle. Unlike the traditional menu design where one needs to add the menu in an existing menu hierarchy, creating a menu in the Avalanche portal is way way simpler.  It adopts a very flexible pluggable design pattern. 

1. There is no explicit hierarchy to place your menu. 

2. You do not need to add your menu explicitly.

3. You have the flexibility to add your menu to any of the existing menu or create your own top menu; again without needing to modify existing menus.

It reminds me of the Spring3 framework's IOC design pattern. The framework will inject your menu automatically if you code your menu according the guideline. I love it when things come for free!

Menus in the Avalanche portal

For any of you who are going to design your own menu, you would have at your  disposal, the development documents (the SDK Beginner's guide, the SDK  application development guide, SDK Customization guide, Commercial Client Customization guide) and the SDK library help files.  Even with these documentations, you will find the learning curve quite daunting. Of course you can reach the end goal but it does need time and effort to be competent to develop a good IPTV application. That is where I come in; acting as the mentor for you and provide to you the right training to jump start on your development effort.

My first step to prepare the training content for this topic is to understand the background of how menus are designed and rendered in the Avalanche portal. Without this background, you may not be able create a consistent look and feel of your application within the portal. 

I powered up my tomcat and deploy the necessary war files to the webapp folder. I found that menus in the Avalanche portal are rendered on both the main menu bar and as column menus. The diagram below illustrates the default application menus.

Avalanche Portal menus

Exploring the menus further led me to have a deeper understanding of how the menus are rendered. For the menu in the main menu bar, the image is rendered via css which is identified by the class name of the menu item.

Main Menu bar

I noted that each application menu is inserted as a separate div under mainMenuItems in the HTML markup. That looks easy enough. I thought - all I need is to add the menu item into the HTML markup. Boy was I wrong in my deduction!  Upon exploring further, I discovered that I do not need to do so. The portal framework will do this automatically for you. I will elaborate on this later.

Likewise the column menu, the image is rendered via css while the text of the image is retrieved from the message file.

Column menus

The menu is implemented via the HTML markup but as I have discovered earlier, I do not need to modify any HTML markup to add my menu; the framework does this for me for free.

Know the framework

It reminds me of my experience in designing the first Apache Tiles web application. The pre-requisite to implement a good Tiles application is to know the Tiles framework.  I have diverted from the topic  so let's go back to my current quest - to prepare the training materials for this technical topic.

The pre-requisite to create a menu effectively and correctly is to understand the menu framework. This is where I identified the key concepts of the menu framework. They are

• com.company.iptv.portal.coreapps.common.main.interfaces.MainMenuItemIF

• Avalanche main menu

• Menus namespace

com.company.iptv.portal.coreapps.common.main.interfaces.MainMenuItemIF

You need to inherit this interface in your module and declare the static structure of this interface. As alluded by the previous section, you do not need to make any explicit call to create your menu. All that is required is to fill in the details of the static structure and the framework will do the rest for you automatically. Nothing could be as simple as this!

MainMenuItemIF statics

cssModule, langModule

The IDs of these modules identify the skin and language modules respectively.

iconClass

The class name of the menu image icon

appNameKey

The key of application title.

activate

The namespace of the module that is activated by this menu

parentNode

The namespace that identifies the parent menu

menuPosition

The position relative to the main menu.

Avalanche main menu

The namespace of the main menu is

com.company.iptv.portal.avalanche.second.mainmenu.view.MainMenu

To add your application menu to Avalanche portal, you specify the above namespace in the parentNode (see previous section) to indicate that your application menu is a sub menu of this menu.

Menu namespace

All the menus in the Avalanche portal follow a consistent namespace naming convention i.e.

com.company.iptv.portal.avalance.second.{application}.view.MenuItem[{Module}].js

I collected all the namespaces used by the default Avalanche applications and listed them below:-

com.company.iptv.portal.avalanche.second.home.view.MenuItem

com.company.iptv.portal.avalanche.second.epg.view.MenuItem

com.company.iptv.portal.avalanche.second.vod.view.MenuItemMovies

com.company.iptv.portal.avalanche.second.vod.view.MenuItemVideos

com.company.iptv.portal.avalanche.second.mycontent.view.MenuItem

com.company.iptv.portal.avalanche.second.search.view.MenuItem

com.company.iptv.portal.avalanche.second.settings.view.MenuItem

com.company.iptv.portal.avalanche.second.settings.view.MenuItemSystem

com.company.iptv.portal.avalanche.second.settings.view.MenuItemUser

The menus in the Avalanche portal follow the same design convention. They all inherit from the com.company.iptv.portal.coreapps.common.main.interfaces.MainMenuItemIF and has the same parentNode. This is illustrated  by the diagram below.

Mappings

Menus in the Avalanche portal have the following characteristics  :-

• Each application has its own menu in a separate source file .
• This is the object oriented way of doing things; the separation of concerns.
• Built for pluggable design

• Each menu activates its own view which is created in its own file
• This is the object oriented way of doing things; the separation of concerns.
• Built for pluggable design

• Each menu position is spaced generously (e.g. 10,20,30,40,50).
• This allows the insertion of new application menu between existing menus.

• All the menus adopt a consistent namespace.
• Consistent design allows one to understand the system easier.
• Built for pluggable design

• The image icon in each menu is rendered via css.
• Easy to change the image.

• The messages for menu are specified in a message interface file and an actual message module file.
• Enabled for localization.
• Follows the service oriented pattern

Hello World menu application

With the above understanding, it is time to formulate the process of adding my menu.  To be consistent with the existing framework, I create some template modules  :-

1. Skin module - a skin interface module, a skin module and its the corresponding css, and the image icon file

Note: No HTML markup is required for menu creation.

2. Language module - a message interface file and its implementation
3. MenuItem module - implements the MenuItemIF interface.

4. The main application view module

Development Process

I summarized the key steps to create the Hello World menu application :-

1. Create your MenuItem.js with the right namespace

2. Declare MainMenuItemIF.js as your implementation.

3. Fill in the statics details of MainMenuItemIF

How to map

4. Link your image in your css
1. Render in the main menu bar - .app-icon- paint-target.{iconClass}

2. Render in the Home Column  - .{iconClass}{space}.app-icon- paint-target

5. Create your messagesIF.js to add the application title key

6. Create your messages.js to set the application title text in the application text key

7. Fill in the template view.js with the module id as the value in 3c and enter the following text

Are you ready?

I believe I have prepared the necessary concepts and training materials for my training session. 

The next step is to prepare a practical exercise for the trainees to apply  their new found knowledge and to build up their competency in IPTV development. With both the theoretical and practical training sessions, I am sure that my trainees are ready to be assessed with my quiz.  Are you ready?

Preparing training materials for a specialized technical topic - IPTV on-demand services

The Challenge

I am not sure about you but reading on a specialized technical topic is always a challenge. The information available to you is always of a very dry nature.  In most technical documents that I have read, it is difficult to absorb the information from the documents because of the way the content is organized and described. Unlike fictions where the book author (s) can keep you engrossed with their way of story telling, there is no equivalent story telling in technical documentations. They do inform you about facts but due to their dry nature, most engineers find that learning by just reading the documents will incur a high learning curve.

If reading on a specialized technical topic is a challenge, preparing the training materials for such a topic is a bigger challenge. When I was tasked to present training on an area in IPTV i.e. On Demand services (e.g. VOD), I have to sit back and think of a strategy on how to do the story telling.  Non-fiction story telling to a group of highly skilled engineers is a different ball game from writing a fiction where you have the luxury of introducing interesting characters, a plot with twists and turns and besides enchanting your readers with exotic sceneries, you can add into the story line the emotional factors to stimulate the interest of your readers.

Putting myself into an engineer shoes, I scanned through the documentation and painted the documents all over with a yellow highlighter.  Looking at the highlighted keywords, I thought to myself: "Hmm, keywords may help a scholarly engineer to memorize the information but he will not be able to develop the necessary skills to apply his new found knowledge.” Realizing that my effort is not enough to conduct an effective training presentation, I asked myself some self-probing questions

• Who are my audiences?
• Why would the trainees attend this training?
• Which of the facts are more important to the trainees?
• Can the trainees apply the information learned to real life scenarios?

With these targeted goals in mind, I now looked at the information at a different angle.  This time, I re-scanned through the documentation using an "objective approach".

Metadata – 1st class citizen

“Metadata” was the first to put her hands up to get my attention. She told me that she deserved first place in the class of must know information. I agreed with her that she is definitely a first class citizen for solutions architects, presales engineers and system integration engineers. I remembered during my first encounter with OTT technologies where I was the solutions architect for a large greenfield project in Singapore, I was working furiously with my peers from Atlanta to work shop on the design. To address the client business requirements, we were exploring how to use the metadata standards (we were using CableLabs VOD Content Specification 1.1) to translate the requirements to design artifacts.

For the solutions architects, they must

• Acquaint themselves on the differences between the standards (CableLabs VOD Content Specification 1.1, CableLabs VOD Content Specification 3.0, Microsoft TV 2.0 Metadata),

• Identify types of information that categorized the various VOD contents,

• Know which piece of metadata information can be changed at various phase.

For the SI engineers, they need to have a deeper knowledge on metadata so that they can

• Perform normalization of various metadata to a common metadata format,
• Migrate between different versions of metadata standards.

I conclude that Metadata is definitely the first class citizen in the world of VOD.

Standards galore

To provide On Demand service is a complex process. There are many standards involved. One of the objectives for the resulting training project is to make aware to solutions architects of the numerous industrial standards that are adopted in various phases of the process.

Standards for On Demand service

Metadata

 Metadata standards describe the various formats that we used to encapsulate the information of a content. From the standards, we know where we store the descriptive information of a content (e.g. the title, the artists, the ratings, and the summary of a video) and the business information (e.g. the licensing window, the contract agreement, the provider id).

I have already hinted that Metadata is a first class citizen in the VOD world. The motivation to be skillful in applying the knowledge metadata is many. One example on why metadata is important to the Solutions Architect is that he may in a situation where he needs to plan to upgrade an existing VOD system  when they are transitioning from CableLabs 1.1 to CableLabs 3.0. Another example is that he has to work out the impacts on a swap-out project when the company takes over a competitor’s solution at a client; a solution that needs to handle different metadata format from several content providers.

Encryption

Encryption standards define the various algorithms used to secure VOD content and transmission. We will learn why Data Encryption Standard (DES) is not employed in modern systems to secure our data. We will also learn about the differences between AES (Advanced Encryption standard), DES and Triple-DES. With this knowledge, the Solutions Architect will know the basis of how to select the best encoder that matches the service provider infrastructure.

Transmission

For VOD transmission, the transmission standards affect three key technologies namely

• Satellite
• Microwave
• IP

“Why would I need to know about transmission standards?” asked the Solution Architect. The short answer is that he needs to know the details so he can spec out the most suitable equipment and client infrastructure with his network engineers to handle the transmission requirements. For example, without knowing the difference between the IF (Intermediate Frequency) modulator and L-Band modulator, the Solution Architect will not be able to decide on which modulator will meet the requirements of the client infrastructure. 

Compression

There are two different compression standards that are relevant to On Demand service namely video compression standard and audio compression standard. By exploring the standards and techniques, the trainee can build up a good background knowledge on MPEG (MPEG-1, MPEG-2, and MPEG-4) and various Dolby standards. He can then apply his background concepts during the transcoding stage of MPEG to other device formats (e.g. AVI, FLV or 3GP) and/or Dolby Digital to AAC.  One of my other training objectives is to ensure the Solutions Architect is made aware of the different requirements (e.g. storage capacity and performance) when he needs to design his solution to support SD (Standard Definition) and HD (High Definition) video offerings.

Distribution

For the distribution from a content distribution system to a CMS (Content Management System), CableLabs ADI 1.1 is the most widely adopted standard used. It defines not only the language but it also provides the structure and method for the distribution of the content. Knowing the limitations of the standard will equip the presales engineer and/or Solutions Architect to provide the right expectation to the client and design the appropriate solution to meet the client needs. As an example, ADI 1.1 does not allow the updating of a content once it has been ingested into the CMS. By knowing the standard, the Solution Architect can work with SI to design an efficient work around solution to “update” the content.

Content Management System (CMS)

CMS

CMS deserves a chapter on her own for the significant amount of contributions to provide a reliable On Demand service.  As this is the first of a series of technical training in the subject of IPTV, I prepared my training materials in this topic as an introductory level; a must have stepping stone towards becoming competent to IPTV. I described the key responsibilities of a CMS, the processing in each of the steps and highlighted the important concepts in CMS.

Last words

After I have designed the key topics for this project, I started to create the assessments questions cross referencing them to the objectives that I have identified. Again, I used Adobe Captivate quizzing engine to perform my data entry on my quiz. For the finishing touch, I reviewed the content, the flow structure and the assessments to ensure that I have developed the right content that covers the identified objectives.

In summary, preparing the content for a technical training is always a challenge. At least I know I have developed a good process and put in my best effort to design the content that will address the objectives of the trainees. The real reward will be when I receive feedback and stories from my trainees on how they have put into good use of their new found knowledge and skills.