Telco-AJAX

Feb 08 2008

Whitepaper

A Concept Approach at bringing Legacy Telecom ApplicationServers to Web 2.0

iiHSC PROPRIETARY

PROPRIETARY NOTICE

All rights reserved. This publication and its contents are proprietary toHughes Systique Corporation. No part of this publication may be reproducedin any form or by any means without the written permission of HughesSystique Corporation, 15245 Shady Grove Road, Suite 330, Rockville, MD20850.

Copyright © 2008 Hughes Systique Corporation

iiiHSC PROPRIETARY

TABLE OF CONTENTS

SECTION PAGE

1.0 EXECUTIVE SUMMARY ..............................................................................................................4

2.0 GROWTH OF AJAX .....................................................................................................................5

3.0 AJAX AND THE TELCO SOLUTION SPACE.............................................................................7

4.0 TELCO AJAX CONCEPTUAL ARCHITECTURE........................................................................84.1 HOW DOES TELCO AJAX FIT IN ?............................................................................................84.2 APPLICATION SERVER INTEGRATION ARCHITECTURE ......................................................94.3 “2.0”-IZING AN EXISTING VOIP IM CHAT SERVER .................................................................104.4 BINDING TO THE ACTUAL CHAT SERVER ..............................................................................114.4.1 Connecting the widgets to the backend AS ..........................................................................114.5 TAKING THIS CONCEPT FURTHER..........................................................................................12

5.0 CONCLUSION ..............................................................................................................................13

4HSC PROPRIETARY

1.0 EXECUTIVE SUMMARY

With the increasing acceptance of AJAX as a mechanism to deliver real-time user experienceswithout the need of proprietary local clients and the increasing demand from consumers to have abetter user experience with more features, both the Telecom and the Internet world are looking atmeans to be able to converge their offerings. However, being able to provide converged services is achallenge largely due to the fact that Telecom players already have existing applications they wouldlike to monetize in addition to having limited know-how of Web 2.0 related technologies, whereas theInternet players, while proficient in Web 2.0 technologies have limited understanding of wireline andwireless networks to be able to offer ubiquitous service access.

The author believes that middleware SDP providers can help bridge this gap and provide“convergence” building blocks that would allow developers on both sides of the world developfunctionality, or integrate existing functionality with ease.

Specifically, this paper, proposes the concept of “TelcoAJAX” – a set of building blocks that are awareof telecom primitives and how to represent and interact with users using a browser interface whichdevelopers can implement on top of SIP/Presence based applications.

TelcoAJAX consists of two parts:1. A set of enhanced Telecom widgets that are service specific and provide UI,event detection

and actions for identified services2. An XML binding layer that allows application developers to connect the above mentioned

widgets to their back-end ASs for protocol action.

5HSC PROPRIETARY

2.0 GROWTH OF AJAX

Before we talk about how AJAX may enhance Telco Apps, let us first take a look at how AJAX itself hasevolved over the years.

This is a growth illustration that was drawn up by the author in 2006. AJAX has grown considerably tillthen. However, this diagram still illustrates the basic point that with the advent of industry leaders such asGoogle, Yahoo and others implementing AJAX to create impressive (and quick to load) interfaces, theuse of such technology has become increasingly mainstream in replacing “locally installed thick clients” to“browser enabled thin clients” without loss of functionality.

With the growth of AJAX, the industry felt a need to develop “additional libraries” on top of “basic AJAX”,which is just a combination of CSS+JS+HTML. The goal of these libraries were specific:

Abstract browser incompatibilities from users Provide easy to use APIs so that developers don’t need to reinvent the wheel for common

functions Provide a set of ‘graphical widgets’ that users could directly use (like dialog boxes, trees, lists)

without having to re-create their own.

6HSC PROPRIETARY

The next diagram illustrates some of the players who created enhanced libraries for programmersbuilding solutions on AJAX.

The growth of AJAX powered libraries has largely been responsible for many impressive AJAX basedapplications being rolled out into the market.

7HSC PROPRIETARY

3.0 AJAX AND THE TELCO SOLUTION SPACE

While the general growth of AJAX and associated libraries have led to significant proliferation of AJAXpowered applications, including new VoIP applications such as Meebo, Click4Me and others, very littlework has actually gone in in being able to somehow leverage existing VoIP applications from providersand “2.0”ize it (for lack of a better term).

One primarly reason for this is, in general, ‘telco’ programmers are different from ‘Web 2.0’ providers interms of skillsets. Being able to ‘2.0’ an application requires a very good understanding of several webbased technologies as well as the web programming model, which is often data driven as opposed tofunction driven.

Secondly, AS vendors would like to protect their existing investments in applications. As would operatorsdeploying their solutions. If “2.0izing” their products means a rewrite, or re-doing majority of existing codeto connect it to a browser based system, that is clearly undesirable.

Furthermore, while several toolkits over AJAX have extended it to offer easier functionality, none of themare ‘telecom aware’. Consider this example: Let us suppose that an application provider already offersand IM service and is now looking at implementing an Ajax based client for IM interaction, but one that re-uses its existing IMS service back end. To be able to do this, the programmer would need to understandAJAX, one of the generic libraries on top of it, and then implement screens, actions and events that arespecific to the IM service. This is a lot of work. And Complexity.

This is where the concept of ‘Telco-AJAX’ comes in.Companies providing “SDPs” which are SIP enabled can choose to implement “helper classes” that helpdevelopers adapt their existing solutions to an AJAX model for presentation. The assumption made therein this statement is that the middleware that offers these libraries is also being used for the core servicedevelopment (which is generally true: most AS vendors I know of today use some SDP or the other, likethose from BEA, Oracle, Ericsson, NSN, Sylantro, Avaya/Ubiquity or others)

8HSC PROPRIETARY

4.0 TELCO AJAX CONCEPTUAL ARCHITECTURE

4.1 How does Telco AJAX fit in ?

The following illustration depicts how telco AJAX fits into the overall service creation chain.

9HSC PROPRIETARY

4.2 Application Server Integration Architecture

The concept here is to use an existing AS service (“Backend Server” in the diagram) and be able tobridge it to the AJAX world. The most important part to be able to do this is the “XML Binding componentthat allows an AJAX front-end to interface successfully with the backend.

Specifically, the “XML Binding” component is envisaged to an XML driven engine that in the northboundinterface interfaces with the SIP/IMS telecom classes which are “telco” aware widgets from a presentationperspective, with in the southbound interface, offer a hook for programmers to insert procedure calls toinvoke specific protocol/state action on their AS. The exact interface from the WebServer to the backendAS could be any RPC/IPC mechanism, including API interfaces.

In addition to this XML binding layer, the middleware provider can also provide “Telecom Widgets”(called IMS Widgets here). The objective of these widgets are to provide commonly usedscreens/events/actions for well known telecom services. It is expected that this widget set increases asmore service primitives are added to this library.

At this stage, how this really works may be a little confusing. So an example is in order:

XML Binding

10HSC PROPRIETARY

4.3 “2.0”-izing an existing VoIP IM Chat Server

Consider an example, where an AS provides a SIMPLE (SIP) based chat service and now wants to offera platform which is AJAX based that uses its AS for chatting as a replacement for a downloadable client.

If one breaks up a chat-client functionality, one would realize that a lot of it can be converted to commonlyused classes. For example:

User InterfaceA typical chat client will have:

A dialog box widget A friends list widget An authorization widget

Events InterfaceThe UI described above would have some basic associated events:

Receive an object (message/file/stream) Send an object (message/file/stream) A text entry area for composing a message Allow/Deny/Stealth requests/responses Incoming/Outgoing friend requests Key-type events

And so on.

Using the existing AJAX frameworks today, to “2.0”ize a chat application would require writing all of theabove from scratch (except the dialog box widget which is generic).

However, consider that the middleware SDP provider were to provide such telecom AJAX libraries, whichoffers simple APIs like so:

(written in pseudo code)

1: telco_initChatWindow(type=>visible);2: telco_attachBehavior(events=>keypressed,textin,textout,auth=>true,

mode=>secure)3: telco_setAttr(from=>“sip:alice@example.com”, to=>”sip:bob@example.com”);

Dissecting the APIs above:

1: Invoking this API automatically takes care of instantiating a chat window, that will be visible on thescreen. This in turn invokes a base AJAX widget library for skinning and actions. Note that in addition tothe base AJAX dialog class, a “chat dialog” will also add buttons such as fonts, buzz, and otheremoticons.

2: Invoking this API automatically adds Javascript event handers to the dialog box. For example,events=>keypressed maps to a local Javscript event of onKeyPress and a remote hook to notify the Chatserver that remote keypress, if supported, should also be reported. Similarly, other attributes describehow this dialog should behave (secure protocol, text only)

3: Invoking this API is a hint to the Chat Server about the source and destination users.

Note that since all of these classes are built on top of existing AJAX libraries, all base class properties areinherited, like dialog box roll-up, resize, relocation and others.

11HSC PROPRIETARY

4.4 Binding to the actual chat server

While the explanation above provides an example of how UI and associated events can be tied togetherin form of a library for ease of use and development, we have not yet described how this ties into actualprotocol acton (i.e. how does the Chat server know it needs to send a MESSAGE method when the telco-widget clicks the SEND button?)

This section takes a look at how that may be achieved.

It is proposed that middleware companies offer an XML driven template that helps tie the telco-classes tobackend operation.

4.4.1 Connecting the widgets to the backend AS

There could be several ways to connect the telcoAJAX widgets to a backend Application Server. Oneexample could be to use an XML schema instead of an API based approach. The author prefers XMLover API based approach for the following reasons:

For an average developer, building applications on top of an XML schema is typically much fasterthan having to learn a new API. Naturally, the new XML schema and its allowances have to beunderstood, but typically in practice, the learning curve for XML based services is much less

The structure of an XML schema enforces future extensions and flexibility by design. Newattributes can be added, controls can be included without breaking the existing flow.

The exact XML schema can be different, but one could envision a possible binding as follows:

<telco:page onload=”id#init”>

<style>// Add any CSS imports, class definitions here</style>

<h1> Welcomed to the new AJAX based Chat system </h1>

<init><function> telco_initChatWindow(type=>visible);<handler> javascript:myHandlerforInit </handler></function><function>telco_attachBehavior(events=>keypressed,textin,textout,auth=>true,mode=>secure)<handler> javascript:mySomeEventOccurred </handler></function><function>telco_setAttr(from=>“sip:alice@example.com”,

to=>”sip:bob@example.com”);<callback type=onError>javascript:myOops </callback></function><function> default <handler> mySomeEvent </handler> </function>

</init>

// this section will now contain all the callback and event handlers that mayoccur for the instantiated widget.function mySomeEventOccured (TelcoEvent evt, TelcoData td){

// here you can put in any code to handle the event// including calling your backed server functionality// for example: lets say that the event is “IM to be sent”// then you could add:

12HSC PROPRIETARY

msg_sendMessage(from,to,data);// where msg_sendMessage is an instruction to the backend Server to

send the data. This could be an HTTP AJAX post to the server from the browserwith the required data, and the server in turn sends it out}

</telco>

The binding above is just one example using how a developer may create a web based widget for hisservice and have it connected to the backend server to execute the service.

4.5 Taking this concept further

Effectively, to wrap our arms around this proposal, there are two things are being discussed.The first, is essentially a library of telecom widgets that know what actions/events and interfaces are to bepresented for typical telco services. These widgets can be combined in any way to create more complexservices by the developer.

The second is this concept of an XML binding layer that allows us to tie in the widgets to the backendserver. Do note that by it’s own, the “telco AJAX widgets” , without the XML binding layer would be veryuseful to application developers who are creating new telco services, or, already have an alternatemechanism to communicate with their backend AS servers.

Taking this concept further, one could imagine that similar widgets are also developed for other telecomservices like those for Network Management, OSS, Billing which makes Web integration much simpler forall these verticals.

Further, this XML integration layer is essentially independent of the presentation technology, and hencecould also be applied to non AJAX environments such as Flash (with actionscript taking the place ofjavascript for hooks/callbacks) like so:

13HSC PROPRIETARY

5.0 CONCLUSION

This paper suggests the concept of building telco specific AJAX libraries that are aware of thetools/widgets that telco services require and making the same available to application developers to easethe transition to web 2.0 based integration. Further, it suggests a mechanism, via XML, that allows for thewidgets to be able to interact with backend application servers to execute procol action.

For comments, queries or suggestions, please contact the author:Name: Arjun RoychowdhuryEmail: arjun@hsc.com