Comment lines by Erik Burckart: Every application needs communications

IBM® WebSphere® Application Server V7 Feature Pack for Communications Enabled Applications (CEA) can help easily add powerful communications capabilities to your applications. In many cases, integration starts simply with one line of HTML while importing the JavaScript™ and CSS. This article briefly describes the capabilities of this new feature pack, including the ability to browse a Web site with a friend, or click to make a call to someone all via JavaScript. If you want to see it in action, this article includes easy ways to get started plus links to YouTube demo videos. This content is part of the IBM WebSphere Developer Technical Journal.


Erik Burckart (, WebSphere Application Server Lead Architect, IBM

Erik BurckartErik Burckart is a lead architect of the WebSphere Application Server product. He is a graduate from the University of Pittsburgh'’s School of Information Science, where he studied telecommunications, software development, and human computer interaction. Through his work with SIP servlets in WebSphere Application Server, he has joined the SIP Servlet 1.1 (JSR 289) Expert Group and has made numerous contributions in combining the state of the art Java EE platform with the latest SIP Servlet specification.

30 September 2009

Revolutionize the Web experience

Over the past six months, I have been talking with customers about our new IBM WebSphere Application Server V7 Feature Pack for Communications Enabled Applications (CEA). Before this feature pack, access to communications technologies from inside applications came only in the “build it yourself from the SIP servlet API up” option. This feature pack introduces a lot of new functionality that -- with a single line of HTML plus two imports -- can be easily integrated with a Web application.

A quick overview of the feature pack might be helpful here.

The WebSphere Application Server V7 Feature Pack for CEA revolutionizes how applications can have users connect and communicate. From the lowest level up, a new revision of the SIP servlet capability brings it to the 1.1 specification, as described in JSR 289. But because writing an SIP servlet into most enterprise business applications would take too long, several other APIs are introduced.

The feature pack introduces a set of telephony access services for enterprise users. These services include basic ways to make and disconnect phone calls between two parties, as well as ways to get notifications for a particular phone. The feature pack provides two ways to access each of these services: a Web service route and a REST-like service. I say “REST-like” because while it follows many of the semantics of a REST service definition, it is not strictly stateless for performance and scale reasons. Also, the REST-like service supports XML and JSON payloads, depending on which type you prefer. The Web service interface uses WS-Addressing and WS-Notification for efficient asynchronous one-way communications. These services have been tested against Avaya, Cisco, and Nortel equipment. More details on interoperability with these vendors is available on our blog.

Figure 1. Architectural diagram of the Feature Pack for Communications Enabled Applications
Figure 1. Architectural diagram of the Feature Pack for Communications Enabled Applications

Another REST-like service offered by the feature pack is the collaboration service. This service joins two HTTP sessions and enables the two users to share data back and forth by sending HTTP requests to the service running on WebSphere Application Server. There are a couple of ways that two sessions can be joined. If one user is using telephony access services to create a call and the other user is polling for a call notification, both HTTP sessions can be automatically joined to share data back and forth. Otherwise, one user can create a simple invitation URL using the REST service, which, when accessed by a peer user, links the two HTTP sessions. This invitation URL can be sent via e-mail, instant messaging, or by some other means.

On top of these REST-like services is a set of highly customizable Web 2.0 widgets that can be used to access these services. First is a click-to-call widget and a call notification widget that utilize the telephony access service. These are highly customizable (and if you check out our blog, you will find some examples of how they can be extended). The click-to-call widget can be used to front a contact center sort of deployment, in a corporate directory, or even in a situation where someone is making outbound calls to vendors, partners, or customers.

The feature pack also includes a set of advanced widgets around the collaboration service. It starts with a modal window, called a CollaborationDialog, and a basic Javascript API to send and receive data events. On top of that is a Cobrowsing widget and a Two-way forms widget:

  • The cobrowsing widget enables two parties to pass URLs and elements that have been clicked on back and forth so that both users can navigate through a site together. Unlike screen sharing, both parties maintain their separate HTTP sessions and only have back-end access permitted to them by the application. It does, however, let them share the browsing experience and even do things like highlight elements on one page so that another user can see it. There are some great demonstrations of this function on YouTube if you’d like to see it in action (see Resources). The cobrowsing widget can be accessed directly from the click-to-call widget for contact center-like cobrowsing, or it can be put on a page with the ability to add an invitation URL in a peer-to-peer cobrowsing sense.
  • The two-way forms widget extends the cobrowsing function by enabling you to create a custom form in which each field can be edited by one side so that the other side can see what was typed when focus leaves that field. This function is also displayed in the contact center demonstration video on YouTube.

The best part about all of these widgets is how simple they are. None of these widgets require anything but JavaScript. They all utilize Dojo syntax for being able to extend the widgets for further function. Aside from the two-way forms widget, each requires only one line of HTML and two imports -- one for the CSS and one for the Javascript -- to revolutionize your user’s experience.

What Web application doesn’t need this sort of function? Any Web site that you would share with a friend could benefit from being shared via the cobrowsing widget. If you are fronting a contact center, how much easier would it be if you could show your customers something rather than just tell them over the phone? Show them product information, travel itineraries, financial transaction details, policy information, and so much more.

Check out Feature walk-through for Communications Enabled Applications on WebSphere Application Server video in Resources to see all of these widgets explained.

So, how does it work?

The feature pack can be installed on all editions of WebSphere Application Server V7, including the no charge WebSphere Application Server for Developers. As it supports the SIP Servlet 1.0 and 1.1 specifications, the feature pack first replaces the SIP servlet engine that exists in base WebSphere Application Server V7. A simple configuration switch turns CEA services on: navigate to Servers => Application Servers => server name => Communications Enabled Applications (CEA). Check the box there to enable the CEA services and configure various pieces of the service.

The feature pack includes several sample applications. First is a sample IP-PBX application that lets you set up a unit test environment without accessing your corporate telephony services (install the application and download a freely available IP software phone, like XLite or Express Talk Basic). Also included is the classic Plants by WebSphere sample, as seen in the YouTube videos. That sample shows you a basic Web 2.0 retail site using the click-to-call, call notification, cobrowsing, and two way forms widgets all on one Web page. With these applications installed on WebSphere Application Server and a phone, you can test each one of the widgets for yourself and see how they work. Plants by WebSphere also has peer-to-peer cobrowsing configured, so you can try cobrowsing without installing the IP-PBX and without a phone.

Detailed steps and scripts automating the above processes are available on our blog.

If you want to include the widgets on your own page, there are some simple steps you need to do to add the widget. These steps are shown below using the ClickToCall widget as an example:

  1. Import the CSS and set the body class to Tundra since the widgets are based on the tundra theme.
    <style type="text/css"> 
    @import "./ceadojo/dijit/themes/tundra/tundra.css"; 
    @import "./ceadojo/cea/widget/ClickToCall/ClickToCall.css"; 
    @import "./ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
    <body class="tundra">
  2. Import the Javascript.
    <script type="text/javascript" src="./ceadojo/dojo/dojo.js" 
    djConfig="parseOnLoad: true, isDebug: false"></script>
  3. Add the div tag in the appropriate place within the body of the HTML document and configure the div tag.
    <div ceadojoType="cea.widget.ClickToCall" widgetNumber="xxx-xxx-xxxx" 
    enableCollaboration="true" canControlCollaboration="true" 

The div tag has various attributes to be configured. More details on how to embed the widgets and configure these various elements can be found on our blog

Other samples are available if you need them, such as how to create two-way forms and how to embed it on a Web page using a different version of dojo. One of the best posts on our blog explains how to get started and links to other applicable posts within the blog.

I hope you will download and try this new CEA feature pack. You’ll find a simple Getting Started guide on our blog, as well as scripts to set it all up on a Windows® or Linux® box. We have also included a sample application that can act as your telephony infrastructure, and you can run unit tests making calls through it. If you don’t have the time to try it, check out the YouTube videos and see how your Web experience can be revolutionized.

And please, send us feedback! I am available on twitter (@burckart) or through email.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Comment lines by Erik Burckart: Every application needs communications