WebFacing

Many ISVs have started migrating their RPG/iSeries applications into the web-based architecture.  The first step involved in this transition is always the conversion of the presentation layer of existing applications from RPG/System i (IBM iSeries/AS400) into a web-based interface while maintaining the core business logic and DB I/O in RPG.  This document gives an overview of the classic iSeries programming model, discusses the various options available for web-enabling the current iSeries/RPG applications and focuses on WebFacing – one of the technology approaches for web-enabling iSeries applications.

In the classic iSeries program model, the application performs READs and Writes to the terminal workstation.  The workstation data manager merges the application data with the display file and generates a 5250 data stream that is sent to the display.  The following figure shows the data flow in an RPG application in the iSeries programming model using RPG:

 

In this model, there is typically one model object and multiple views on that object.  Presentation logic typically goes in the view and business logic goes in the model. 

The following are some of the available options for converting green-screens into a web-based architecture:

 

Host Access Transformation

There are several third-party solutions available that dynamically convert the green-screens into a web-based UI during runtime.  These solutions are based on a screen-scraping architecture which interfaces directly with the 5250 data stream.  HATS and Host-On-Demand APIs from IBM are some of the sample solutions:

Pros:

• No changes required to RPG applications
• Easy to deploy

Cons:

• Licensing costs involved in implementing the solution
• Less flexibility in customizing the UI
• Not very scalable as each client requires a 5250 data stream

 

CGI Web Development Toolkit

CGIDev2 is a web development toolkit for iSeries that facilitates the development of web-based programs using RPG or COBOL.  The gateway interface is implemented using an RPG ILE service program that contains all of the procedures required to read input from a browser, generate and send the appropriate response back to the browser.

Pros:

• Avoids 5250 data streams and reduces the load on the system
• Better design in separating HTML templates from RPG/CGI
• Open Source

Cons:

• Doesn’t always scale well
• HTTP server and web application must be in the same tier and locks you into using iSeries as your webserver and backend.
• Requires good knowledge of RPG for extending it into the CGI framework

 

WebFacing

WebFacing is an IBM’s WebSphere based solution which provides a java-based connector framework for interfacing with iSeries programs.  WebFacing helps iSeries programmers to web-enable RPG applications using java.  WebFacing converts RPG display files to JSPs and JavaBeans, which in turn access the core business logic residing in RPG/System i.  This conversion allows host application to act as a web application.

Pros:

• Minimal changes to underlying RPG applications
• Better architecture using MVC design pattern with Struts framework
• Conversion done at development time making runtime faster
• Runtime is part of OS/400 and the tools are fully integrated with WebSphere Development Studio
• Highly Scalable

Cons:

• Requires DDS source files for RPG applications. If there are no DDS source files, it requires advanced edition with HATS support.
• Cannot change the screen to screen navigation.

 

Comparing the benefits and drawbacks of these solutions, an IBM WebSphere based solution using WebFacing tools provides a cost effective approach for converting the presentation layer of the current system into a web-based architecture. 

WebFacing is an IBM’s WebSphere based solution which provides a java-based connector framework for interfacing with iSeries programs.  WebFacing helps iSeries programmers to web-enable RPG applications using java.  The development toolkit allows conversion of RPG display source files to Web UI easily.  The application is converted during development time and thus increases the efficiency during runtime.  The following figure shows a typical e-business program model using MVC framework:

 

 

The e-business program model used in WebFacing architecture follows the Model-View-Controller paradigm, organizing the application into three separate components:

• Model: the application model with corresponding data representation and business logic
• View: data presentation, providing views for user input
• Controller: to dispatch requests and control data flow

 

The controller handles the interactions between the view and the model. When the model changes it updates the view, when the user does something with the view the controller informs the model.

Using the WebFacing toolkit that comes with IBM WebSphere Development Studio, the application is first converted to create JSPs and Java Beans for each record format. When the program performs a READ on a record format, control as well as the application data is sent to the controller.  Because the job was started by the WebFacing server, the controller knows this is a WebFacing request and passes the data and control to the WebFacing server which runs on the iSeries.  Control returns to the WebFacing runtime servlet that runs in WebSphere Application Server. The WebFacing servlet locates the appropriate JSPs and Java beans. The WebFacing servlet tells WebSphere Application Server to return the JSP back to the browser. The JSP is compiled and the resultant HTML is returned to the browser.  Note that no 5250 datastream is generated in this flow.  The following figure depicts these data flows in a WebFaced application: 

 

 

WebFacing is part of the WebSphere Development Studio for iSeries.  The studio includes all the compilers and tools to support WebFacing and includes the development environments Code/400 and VisualAge for RPG.

WebFacing tools help to quickly convert existing RPG applications into web UI with minimal changes required to the underlying applications.  It introduces very less additional costs to the application stack price and requires no user enablement licenses.  The architecture also eliminates the interactive (OLTP) workload and improves the efficiency of the web application during run time.

Targeted Advertising for IPTV

Targeted advertising and local ad insertion enables cable and telecom service providers to generate additional revenues by delivering targeted ad campaigns and promotions to IPTV-based interactive applications.  In a typical IPTV application, the content that flows from the service provider to the end user takes the form of a live broadcast video stream, an on-demand video stream or non-video interactive user elements (e.g. images, banners, EPG information, Asset Catalogs, System Messages, interactive games etc).

 

IPTV Architecture
In a typical IPTV deployment, live TV channels are encoded in real-time, into MPEG video streams and broadcasted over the network, which is accessed immediately by the user.  On the other side, on demand content like movies and music are aggregated from content providers, encoded into MPEG transport stream videos and stored in a cluster of on-demand video streaming servers at the service provider’s network available for the users to purchase and playback.  The subscriber management server or the middleware server provides the user interface elements, asset catalogs, electronic program guide and all the required client-side applications for a subscriber to access these contents.  The content is accessed by the end user using a media center PC or a TV with a digital set-top box.  The following figure shows various components of an IPTV and VOD architecture:

 

 

Traditional Advertising Model
In the traditional advertising model, the ad content and the program content are assembled, encoded and streamed to all the users, with everyone receiving the same advertisement.  Programs and ads are encoded using transport stream mixers and broadcasted live or stored in video streaming servers.  Banner ads and static contents are pushed to the users using tight integration techniques with the middleware applications.

The following figure shows the advertising components in a traditional advertising model:

 

 

Targeted Advertising Model
The interactive nature of IPTV enables targeted advertisements towards subscribers, thereby increasing revenues per viewer and enhancing the user experience with highly personalized content.  The advertisements that are pushed to a subscriber can be varied according to demographics, geography, viewing habits, content, context and subscriber based campaigning rules.  Because of the in-built addressability of IPTV, ads can be targeted towards large groups, small groups or even single television sets within a household.  The following figure shows the various components in a traditional advertising model:

 

 

The ad management server interacts with the subscriber management or middleware server to deliver targeted ad campaigns to the consumer.  Typical features of an ad management server include:

·      Campaign Management for managing session based rules and ad campaigns for targeting ad banners, ad videos and promotions.

·      Inventory Forecasting for summary of available inventory, projected campaign, delivery and progress.

·      Reporting Module for campaigning and delivery reports.

·      Pricing Module for supporting different pricing models

·      Billing and Sales Modules for integrating with existing billing and sales support systems.

·      Ad Content Management for managing associated ad banners, videos and promotions with related rules.

·      Purchasing Module for advertisers to buy ads and manage their ad slots.

 

The Ad content server is responsible for managing all the advertising media with optional caching feature for instant delivery of the advertisements in real time.  It is also responsible for a highly automated digital ad insertion into the streaming content at the scheduled point.

Typical features of an ad content/insertion server include:

·         Content Management

·         Content Caching

·         Transport Stream Insertion

·         High-Definition Insertion

 

Digital Ad Insertion
Inserting digital ads to the live streams involves two components – a splicer and an ad server.  A splicer is typically a switching device which can generate an output video stream from one or more inputs.  In addition, it can also look for the video splice points from the digital cue tones and insert the ad content at these points from the ad server.  The following picture shows a typical ad insertion process in a broadcast video stream:

 

 

Broadcast streams from the live encoders come in to the splicer and when the ad isn’t being shown these are just re-transmitted as separate but identical streams to the different target groups.  Embedded in the incoming streams are the digital cue tones that signal the location of the “ad avails” and these are detected by the splicer and passed as triggers to the ad server.  At the start of the ad avail the ad server starts playing out the separate ad streams.  These are then fed back into the splicer which inserts them into the outputs sent to the target groups. When the ad avail is completed, the splicer reverts back to the live content and so on; generally acting in a much more interactive manner.  The ad content server is also responsible for static campaigns like banner ads, images, coupons and promotions which are pushed to the end user based on the session parameters.

Targeted ad insertion provides huge opportunities and potential returns for IPTV service providers.  From a marketing perspective, it would become easier to target end users with customized campaigns and increase revenues per consumer.  From a service provider’s perspective, providing such an advertising solution could be a big challenge.  A combination of targeted ad campaign manager and ad insertion technology could provide the necessary advertising solution to meet the needs of advertisers for simplified ad buying.