Level: Intermediate Jean-Luc Collet (jean-luc.collet@fr.ibm.com), Digital Media IT Solution Specialist, IBM
Carole Truntschka (TRUNTSCH@fr.ibm.com), Project Manager, European Business Solution Center, IBM
19 Apr 2006 Learn how to exploit WebSphere® Portal V5.1 key capabilities in an IP-TV (Television over Internet Protocol) environment. You see how to configure a portal for heterogeneous Digital Television (DTV) services to enable a central "home dashboard" for communication and entertainment on a TV. This article is for IT middleware architects, Web application designers and developers, portal designers and developers, service providers, and anyone who is interested in IP-TV. You should have a good understanding of Web application architecture and an overall understanding of JSPs, servlets, XML, JavaScript, and Java™. If you are not already familiar with WebSphere Portal, you can get a quick introduction by reading
New to WebSphere Portal. Includes an IP-TV portal demo.
From the IBM WebSphere Developer Technical Journal.
Introduction
The landscape for digital TV services (DTV) is changing rapidly. Digital cable, digital terrestrial, and satellite services are developing around the world, and it appears that broadband networks are emerging as a significant fourth platform for existing and new DTV services. IBM provides technology which enables personalization and consolidation of services so that televisions can become a center for entertainment, information, and communication at home.
From an IT perspective, an IP-TV solution is based on three groups of components as shown in Figure 1.
- The headend, consisting of content providers and equipment (such as the satellite receiver, encoders, and so on) needed to transmit and receive digital assets , onto the IP network.
This platform presents available live content and, if possible, manages the dynamic information coming from the broadcaster for the EPG (Electronic Programming Guide), the main link between the headend and middleware.
- The middleware consists of the infrastructure that delivers the digital assets to the end users; for example, IP network infrastructure, portal servers, storage, Video On Demand (VOD) servers, and so on.
- The components at the customer's premises, which consumes the digital assets and presents them to the end-users. These devices are heterogeneous and includes IP and analog phones, PDAs, set-top boxes (STB), PCs, DSL or Residential Gateway modems, Wireless Access Point routers, TVs, and so on.
The aggregation of data (internet access), voice services, and video services is called "Triple Play". With the emergence of new handset wireless IP devices (for example, mobile phones, PDAs, and car embedded devices) the reality is more like "Multi Play" rather than only Triple Play.
IBM adds value to the middleware. Using IBM hardware (such as the Blade server or xSeries® server) and software (such as the WebSphere family), the middleware infrastructure can be dramatically improved in terms of agility, performance, and scalability. This article focuses on the role that WebSphere Portal can play.
Figure 1. IP-TV architecture
How does WebSphere Portal fit in?
WebSphere Portal provides many capabilities that make it uniquely able to support a consolidated interface for accessing a wide varieity of products and technologies. It provides application programming interfaces (APIs), and extension points for business partners, developers, and clients so that they can extend and customize their environments.
Portlets are reusable components that provide access to enterprise applications, Web-based content, host and data systems, content-management systems, process-driven workflow applications, and other resources. A portlet is the smallest piece of logic running within the portal framework, implementing a service such as mail client, syndicated news, or instant messaging.
The WebSphere Portal architecture, shown in Figure 2, illustrates the capabilities it contributes to on demand business architectures. For more information on WebSphere Portal, see New to WebSphere Portal.
In the next section, you see how specific WebSphere Portal features help enable the home IP-TV dashboard portal.
Figure 2. WebSphere Portal architecture
Applying the features to IP-TV portals
You can apply these WebSphere Portal to fulfill the requirements of an IP-TV environment:
Multiple devices support
WebSphere Portal supports various devices by generating portal pages in three mark-up languages:
- HTML, for desktop computers and some personal digital assistants (PDAs)
- Wireless Mark-up Language (WML), for Wireless Access Protocol (WAP) devices (typically mobile phones)
- Compact HTML (cHTML)
You can also add new mark-ups to support additional languages and devices, such set-top boxes, which are the portal considers to be HTML-derived browsers.
A unique GUI for rendering services
The WebSphere Portal framework provides a clear separation of services, then aggregates and renders the results in the client browser. Rendering of services in a uniform manner can be done using different techniques. Depending on the service implementation, rendering can involve:
- Themes and skins for the overall portal
- Web-clipping (revamping existing Web sites)
- Transcoding rules to adapt the rendering of existing services output
For an IP-TV portal, this flexibility enables a wide variety of services to be aggregated into the portal as shown in Figure 3.
Multiple device support and unique GUI rendering are essential features in an IP-TV context.
Using WebSphere Portal, you can provide the same look-and-feel for any application incorporated into the portal, independent of the original implementation or rendering. For example, portal developers use Web clipping techniques to encapsulate an existing Web application within a portlet, hiding the original GUI and keeping the portal consistent.
Figure 3. Sample GUI with video
Manage Single-Sign On (SSO) between applications with high security
WebSphere Portal provides single-sign on support using WebSphere Application Server and authentication proxies, which can enable users to log on once to gain access to all the enterprise applications aggregated by the portal within the single-sign on realm.
In an IP-TV environment, you want to minimize the number of user interactions because the input device is likely to be a remote control, because it is me convenient for TV management than a remote keyboard. Being able to access my mail account and check my new voice mails while watching the evening news, without having to sign in for each service, is essential in terms of usability. Because all the major STB providers embed a Web browser supporting cookies and HTTP sessions, there are no major difference from a regular PC browser SSO implementations.
Personalization
The WebSphere Portal framework includes a personalization engine which enables you to target content to specific users in support of your portal’s business goals. The personalization component provides facilities that enable subject matter experts to select content suited to the unique needs and interests of each site visitor. These Web-based tools help companies quickly and easily leverage content created by line-of-business administrators.
The personalization process involves these three components:
- A user profile repository. Provides information about users of the site, including user attributes stored in an LDAP repository.
- A meta data content model. Defines attributes about the content such as product descriptions, article topics, and other information.
- Matching technology. Includes engines which match users to the right content. These engines include filtering, rules, and recommendations engines, or combinations of all three.
Personalization is mandatory for an IP-TV portal. You need to program the number of user interactions between the user and a new service, and you want to provide TV programs that the user might be interested in according to a profile and usage habits.
From a Business perspective, you want to minimize the "time to consume" so that TV users consume as much services as possible with a high level of satisfaction. For example, by referencing my user profile information (which is created by logging my previous usage of the platform) and my personal settings, the portal should advise me when a new science fiction movie is available for renting, whenever I access the Video On Demand film catalogue. Or, because I live in Nice (near Antibes) and because I frequently listen to Jazz music items on the portal, it should notify me when a new Video of the Antibes Jazz festival becomes available for renting.
Customization
Super administrators on WebSphere Portal can delegate the look-and-feel administration to subordinate administrators, so they can further refine page layouts and content to meet their individual needs. The refinement process can continue for any number of levels, until it finally reaches users. If permitted, end users can customize their own pages by selecting and placing portlets, and by changing portlet settings. To compute the page that a user finally sees, the WebSphere Portal merges the page fragments defined by each successive refinement.
The ability to customize the look-and-feel of my portal and its content is a mandatory feature for user acceptance of using a centralized IP-TV portal. The portal I am accessing should look like "my" portal not "a" portal. Just as PC users can manage their desktop (colors, background, layout, and so on) IP-TV portal users want to manage their interface as well. For example, the user might want to:
- Change the appearance of the portal (for example, the colors, skins, and login images)
- Change the order in which the services are presented
- Manage a favorite channels list
The user must be the administrator of his or her home IP-TV dashboard.
WebSphere Portal provides the capabilities to support such a rich user experience.
Virtual portals
Beginning with WebSphere Portal V5.1, you can create several portals relying on a single , common infrastructure (application server, user repository, and hardware). Customers often do not need unique installations for new portals. In many cases, a new portal can be a new instance of an similar, existing portal. Also, many new portals are within a company’s intranet, so that multiple portal instances could reuse of a common user repository and common applications. Customers need the ability to expand their portal base without requiring new hardware investments, especially if the existing hardware is underutilized.
This unique feature enables an ISP (Internet Service Provider) to provide IP-TV portals using different internet addresses for its cable users versus its xDSL users. The ISP can implement these virtual portals using the same infrastructure (hardware and software), common services, common portlets, along with some specific portlets and services.
Heterogeneous services aggregation
WebSphere Portal server has an open standards-based architecture which enables integration and federation of existing applications within the portal. IBM has worked to standardize the APIs between portals and other applications, and often assumes lead technical positions within many standards organizations. In particular, the Java Community Process (JCP) and the Organization for the Advancement of Structured Information Standards (OASIS) work cooperatively to standardize the Java and XML technology needed to link portals to disparate applications; for example, JSR 170, JSR 168, and the OASIS Web Services for Remote Portals (WSRP).
The aggregation capability of a portal is a key difference between a "regular" Web application and a portal.
Consider the example illustrated in Figure 4. When a page is composed of several parts coming from several servers, the client Web browser makes at least as many independent HTTP requests as there are page frames (three, in this example). If server C is down, the Web browser will not be able to correctly render all the pages because some information will be missing, and error messages will pollute the overall page rendering.
Figure 4. Regular page retrieval mechanism
As shown in Figure 5, when portal technology is used, the the workflow is simpler and much more optimized in terms of bandwidth management.
- The client Web browser sends a single request to the portal.
- The portal gathers all the information from the various providers (servers A, B, C).
- The information can be cached by the portal.
If one of the servers fails, but all the data is available, the portal returns the entire content to the client within a single request/response pair.
If a server is down and the associated data is not in the portal cache, then a consistent message is returned to the client for the entire request, which can be more convenient and clear for the end user.
Figure 5. Portal Page retrieval mechanism
In the case of an IP-TV portal, the users are not PC users and the Graphical User Interface (GUI) and page rendering should be as clear and simple as possible; therefore, the ability to aggregate various services and possibly cache results, is also a key feature for the TV environment.
Caching
Because portlets are very much like servlets, they have similar re-entrance and performance considerations. A single portlet is shared among all requesters. Portlets involved within a client request can be executed in parallel (to optimize response time) or sequentially depending on their thread-safe state. The portal server assembles all the mark-up fragments when all portlets finish processing.
To optimize response time, you can enable portlet output to be cached. You configure portlet caching policies in the portlet deployment descriptor.
In the IP-TV space, because there is the potential for millions of simultaneous users, you need to cache all the most used pages, services,and portlet output to optimize TV users' response time. Waiting one second for a response to an action is about the maximum delay a TV user can accept.
For example, the Electronic Program Guide, which describes the TV program schedule, is a service which is often requested multiple times each day by each user. You must cache this service.
A centralized search engine for all portal services
WebSphere Portal provides integrated Web-content indexing capabilities, methods to categorize indexed content, and an optional workflow-approvals process to manage publication of indexed content. WebSphere Portal provides two sets of search portlets. You can deploy a document search and browse portlet on a portal page so that users can search within one indexed search collection. It enables users to access advanced capabilities such as browse and search by optional applied taxonomy of indexed content, and the ability to conduct advanced searches using fielded search constraints, such as search by document type (such as audio, video, and documents), author, date range, and so on.
Last but not least, an IP-TV portal requires a powerful search engine. A user should be able to search on all the services aggregated, federated by the portal including Electronic Program Guide (EPG), the Video On Demand (VOD) or Music On Demand (MuOD) catalogs, the network Personal Video Recordings (nPVR) assets meta data, and so on. Again, the idea is to minimize the "time to consume" which is a key advantage in the IP-TV area.
The search engine, combined with the personalization and the recommendation engines, are the primary components in the infrastructure of an efficient IP-TV portal.
Customizing WebSphere Portal for IP-TV
Now you see how we created the example IP-TV portal.
Figure 6 shows the various WebSphere Portal components involved in the customization process for the IP-TV environment.
On the right side of the diagram are the middleware applications and connectors to back-end services such as the Video On Demand (VOD) server, the Electronic Program Guide (EPG) provider, and so on. Portlets, acting as proxies for the application and running within the portlet container of the portal, render these services to the TV user. This container also provides the common features such as the search capability, persistent data, the administration interface, SSO, and collaboration.
The portlets are aggregated by the portal using various themes and skins. The transcoding component of the portal framework handles the adaptation capability of the GUI for each portlet on each device accessing the portal. Therefore, the user can access the multimedia portal from any supported devices including a PC, PDA, set-top box, and mobile phone, as illustrated in Figure 7.
Figure 6. WebSphere Portal components to customize
Figure 7 shows an example of an IP-TV portal created using Websphere Portal.
Figure 7. Example IP-TV example home page
Customizing the themes and skins
Before customizing the portal site, it helps to understand the underlying structure of the the JSPs that work together to form the portal.
Portal page layout
This summary is taken from the WebSphere Portal Infocenter topic on
Layout of the portal page. It is repeated here to give you some background for the customization task.
A typical portal page is composed of JSPs for screens, themes, and skins (see Figure 8), which are typically created by the Web designer of the portal. These JSPs reside in the corresponding screens, themes, skins directories under:
was_root/installedApps/hostname/wps.ear/wps.war |
In this path, you find subdirectories for mark-up, locale, and client types, all of which support portal aggregation (see the WebSphere Portal Infocenter topic on
Aggregation for a more detailed description).
Themes
A theme determines the look and layout of the portal, including colors, fonts, and images outside of the portlet content area (Home screen). Themes often provide the initial navigation to portal pages.
Screens
A portal screen is the area that typically displays portlets (Home screen), but it can also display other content such as a login form or error message. Screens are selected from navigation icons in the theme.
Skins
A skin represents the border rendering around components, such as row containers, column containers, or portlets. Skins also provide navigation to levels deeper than the navigation that is provided by the themes. Skins can use the theme name to select the graphics that match the theme colors. Skins are installed independently from themes; however, the administrator can set a default skin for a theme.
The starting place for building the portal page is Default.jsp in the themes directory under <was_root/installedApps/hostname/wps.ear/wps.war> tree. The screen and skin are called by the corresponding <wps:screenRender/> and <wps:compositionRender/> tags from the engine tag library.
Figure 8. Layout of a portal page
Defining the IP-TV portal menu
The theme developed for the example IP-TV portal has the following structure:
IBM TV Portal
- home
- TV
- VOD
- gaming
- phone
- mail
- internet
|
The first page of the example IP-TV portal, IBM TV Portal, provides links to seven sub-pages which correspond to the seven services aggregated by the portal.
Specifying navigation
Using the skins, themes, and screens the designer can organize different kinds of navigation rendering layouts. For simplicity, the example in this article uses a non-layered layout, located in the skins folder called IPTV_skin in the <was_root>/installedApps/hostname/wps.ear/wps.war tree; specifically, it resides in the UnlayeredContainer-H.jsp. This JSP defines the heart of the portal pages navigation. It is called at page build time, and manages the style and behavior of the main menu. Figure 9 shows the example implementation of the IP-TV menu described above.
Figure 9. Example: IBM IP-TV portal menu
This page uses the tag <wps:navigationloop> to define the navigation through all the pages which are part of the IBM TV Portal main page, and to retrieve all the necessary information to dynamically create the main menu.
Constructing the menu and navigation
To avoid user interface (UI) issues and because only a small number of fonts are available within the set-top box browsers, use images instead of text, whenever possible. You can provide a similar look-and-feel for different set-top box (Amino, Kreatel) devices, despite the set-top box browser support.
For each page, two images that correspond to the two possible selection states (selected and not-selected, are located in the theme folder. Figure 10 shows the two images for the TV page:
IBM IP-TV Portal menu selection images
| Menu item | Selection state images |
|---|
| Home | home. gif, homeSelect.gif | | TV | tv.gif, tvSelect.gif | | VOD | vod.gif, vodSelect.gif | | Gaming | gaming.gif, gamingSelect.gif | | Phone | phone.gif, phoneSelect.gif | | Mail | mail.gif, mailSelect.gif | | Internet | internet.gif, internetSelect.gif |
Figure 10. Selection state images for the TV page
When the UnlayeredContainer-H.jsp is called, the <wps:navigationloop> tag is called to browse the various nodes within the "IBM TV Portal" page structure.
String nodeId = nodeTitle;
String image = nodeId + ".gif";
String imageSelect = nodeId + "Select.gif";
|
During this process all the page elements are gathered (images, properties), and the portal retrieves the nodeTitle . All the images associated with the nodes are put into a table of n elements, where n is the number of pages belonging to the IBM TV Portal page.
Figure 11. Example menu implementation
Optimizing navigation
To optimize the navigation for the end user, minimize the number of request and response interchanges between the set-top box and the portal. Therefore, the example IP-TV portal stores all page navigation elements and information into the page using JavaScript code.
At the implementation level, each menu button has the following information:
- Identifier
- Image for the non selected state (tv.gif)
- Image for the selected state (tvSelect.gif)
- URL for the link
A JavaScript object, mainMenu, stores this information for each node:
<script language='javascript'>
mainMenu.imageButton[mainMenu.navigationLOOP] =
'<wps:urlFindInTheme file="<%=image%>"/>';
mainMenu.imageButtonSelected[mainMenu.navigationLOOP] =
'<wps:urlFindInTheme file="<%=imageSelect%>"/>';
mainMenu.idButton[mainMenu.navigationLOOP] = '<%= nodeId %>';
mainMenu.urlButton[mainMenu.navigationLOOP] = '<%= selectURL %>';
</script>
|
For each <wps:navigationloop> iteration, the
mainMenu JavaScript object is filled with the information retrieved by the portal:
<wps:urlFindInTheme file="<%=image%>"/>
<wps:urlFindInTheme file="<%=imageSelect%>"/>
<%= nodeId %>
<%= selectURL %>
|
The last element, selectURL, is the URL generated by the portal to access the node page from the menu.
The mainMenu JavaScript object enables user navigation from the various menu elements and selection of a service without the need to request anything to the portal.
Viewing the example IP-TV portal
Now that you have seen how to customize an IP-TV portal, watch the video capture of the example created for this article.
Conclusion
In this article you saw why and how to use WebSphere Portal in an IPTV environment to create a "home dashboard" portal for communication and entertainment on a TV set.
In the future, IP portals will aggregate more and more services. A recent study enumerated more than 50 different software vendors providing IP-TV portal-like interfaces, most of which are built as non-portal, Web applications, using either J2EE or PHP. Because of the growing number of services proposed by TelCo operators to catch market share, such ISVs (Independent Software Vendor) need to move their architecture to a real Web portal infrastructure to insure a single, convenient experience for their TV users. WebSphere Portal provides all the required capabilities to build competitive IP-TV portals.
Download | Description | Name | Size | Download method |
|---|
| IP-TV demo | iptv.wmv | 14.9 MB | HTTP |
|---|
Resources Learn
Get products and technologies
Discuss
About the authors  | 
| | Jean-Luc Collet is an IT Solution Specialist at the European Business Solution Center in La Gaude, (South of France) in IBM. He has an extensive experience in software development, design and architecture of complex software systems involving midlleware technologies and ISV products. Jean-Luc joined IBM in 2000 and worked in various Emerging Business Organizations within IBM (Internet, HealthCare and Life Sciences, Digital Media). He is currently part of the Technical Sales Support team at the European Digital Media Solution Center. He is an IBM Certified Professional. |
| 
| | Carole Truntschka is a Project Manager at the European Business Solution Center in La Gaude, (South of France) in IBM. Carole as Project Manager led many IBM Digital Media customer engagements. |
Rate this page
| 
