Communications Enabled Applications

Mobile widget support in the latest CEA refresh

2010-06-22T08:33:00.003-04:00

The latest 1.0.0.5 release of CEA Feature Pack is now available at this site

The refresh includes the following updates:

New Web 2.0 mobile widgets deliver versions of Click to call, Call Notifications, Contact Center Co-browsing, Peer-to-peer Co-browsing and Two Way Synchronized Forms optimized for iPhone and Android mobile browser applications.

Web 2.0 mobile widgets extend multi-modal communications across desktop and mobile browsers.

Helps customers build applications with native mobile web application look and feel.

Support for mobile specific interactions such as touch and gesture support for selecting, scrolling and zooming on mobile browsers.

Enables mobile users to Co-browse with desktop or mobile users.

Start a Cobrowsing Session on the Current Page

2010-06-15T09:19:00.003-04:00

A common scenario is to embed the CEA widget in a page fragment that is used across all the pages in the application. For example, for a commerce application, the widget may be displayed as part of the individual product pages. When enabling contact center or peer to peer cobrowsing for these pages the ideal scenario is start the session on the page the user is currently browsing. This can be achieved through a few simple steps.

First the initial steps to import the JavaScript and CSS are the same. However, instead of the div tag to place the widget on the page instead we will add a placeholder div. Next we will programmatically initialize the widget. Using this approach we can then pass in the current page for joinCollaborationURI and defaultCollaborationUri using window.location.href. The final step is to get a reference to the container div and then append the newly created widget as its child.


<div id="cobrowseContainer"></div>
<script>
  if ( window.top._ceaCollabDialog == null){
     this.cobrowse = new cea.widget.Cobrowse({
        joinCollaborationURI: window.location.href,
        defaultCollaborationUri: window.location.href
     });

     var container = document.getElementById('cobrowseContainer');
     container.appendChild(this.cobrowse.domNode);
  }
</script>

We can also wrap the code to create the widget in a check to see if the page is currently displayed in the CollaborationDialog and if so we can skip creating the widget.

Create a Page Allowing a Mobile User to Invite a Desktop User to Cobrowse

2010-05-27T15:26:00.008-04:00

One of the cool new features offered in the CEA Mobile Widgets Technology Preview is the ability to have a desktop user cobrowsing with a user on a mobile device. Since at the time the first user creates the invitation link we don't know if they will share it with a desktop or mobile user we can create the invitation link to a landing page that will re-direct to the page with the appropriate widget.

There are 4 steps to create this landing page. Using JavaScript first strip off the invitation information from the current page. Next check the user agent to determine if the page is running in a mobile browser. If so then redirect to the page containing the mobile widget otherwise redirect to the page for the desktop browser widget. In both cases append the invitation link information. The last step is to edit the joinCollaborationUri attribute in the existing pages for both the mobile and desktop cobrowse to point to this new landing page.

Here is a sample of the HTML/Javascript code for a basic cobrowse landing page:


<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>CEA Cobrowse Widget</title>

<script type="text/javascript">
   var CEA_COLLAB_PREFIX = "cea_collab=";
   var    href = document.location.href;
   var cobrowseString = "";

   if ( -1 < href.indexOf(CEA_COLLAB_PREFIX)){       
       index = href.lastIndexOf(CEA_COLLAB_PREFIX);
       collabID = href.slice(index + CEA_COLLAB_PREFIX.length);
       cobrowseString =  "?" + CEA_COLLAB_PREFIX + collabID;
   }

   if((navigator.userAgent.match(/iPhone/i)) || (navigator.userAgent.match(/iPod/i)) || (navigator.userAgent.match(/Android/i))) {           
       window.location = "/cea/cobrowse_mobile.html" + cobrowseString;
   } else {
       window.location = "/cea/cobrowse_desktop.html" + cobrowseString;
   }
</script>

</head>
</html>

New CEA videos..

2010-05-03T10:04:00.002-04:00

Two more demo videos aside from the one in the last post. We'll be using some of these in the IBM Impact 2010 sessions that I referenced here

The first one is doing some of the contact center widgets (like click to call then cobrowsing) on the iPhone:

The next is a shorter and HD version of our JavaScript widget walk through:

CEA Impact Sessions

2010-04-30T21:43:00.002-04:00

In case you are looking to learn more about Communications Enabled Applications (CEA) at Impact, here are some talks you can come into:
Enabling Cobrowsing and Coshopping on your website - 2040A Tue, 4/May 10:15 AM - 11:30 AM Venetian - San Polo 3506
Adding Rich Interaction Support to your Enterprise Application - 2272A Wed, 5/May 10:15 AM - 11:30 AM Venetian - Lido 3103

Also, we have a lab on Enabling Coshopping and Two Way Forms on your Web Applications with CEA - 2027A Tue, 4/May 04:45 PM - 06:00 PM Venetian - Murano 3304

Finally, here is a less than 3 minute video showing cobrowsing and the new mobile widgets we have made available and will be demoing at Impact here as a tech preview

Add the Mobile Cobrowse Widget to your Application

2010-04-30T09:35:00.012-04:00

After downloading and unzipping the ceadojo.zip directory into the WebContent directory of your application these 5 simple steps will get you up and running with the CEA mobile cobrowse widget:

1. Configure the widget page to be full screen and non-scalable using the viewport meta tag

<meta name="viewport" content="height=device-height, width=device-width,
initial-scale=1, maximum-scale=1, user-scalable=no"/>

2. Import the CEA widget toolkit

<script type="text/javascript" src="./ceadojo/dojo/dojo.js"
djConfig="parseOnLoad: true, isDebug: false"></script>

3. Add the CSS for the mobile cobrowse widget

<style type="text/css">
@import "ceadojo/dijit/themes/tundra/tundra.css";
@import "ceadojo/dojox/mobile/themes/iphone/iphone.css";
@import "ceadojo/cea/mobile/widget/Cobrowse/Cobrowse.css";
@import "ceadojo/cea/mobile/widget/CollaborationDialog/CollaborationDialog.css";
@import "ceadojo/cea/mobile/widget/iFrame/iFrame.css";
</style>

4. Add the following JavaScript code to hide the location bar when the page loads

<script type="text/javascript">
window.onload = function() {
setTimeout(function(){window.scrollTo(0, 1);}, 100);
}
</script>

5. Last place the widget as the only element in the page using the following HTML snippet

<body class="tundra mbl iphone">
<div ceadojoType="cea.mobile.widget.Cobrowse" joinCollaborationUri="/cea/cobrowse.html"
defaultCollaborationUri="/"></div>  
</body>

Thanks to Steps 1 and 4 when the page loads in the mobile browser it will display full screen as well as scrolling to hide the location bar. This gives the widget an 'app-like' look and feel as well as allows the user to take advantage of all the screen real estate offered by their device.

CEA Mobile Widgets Technology Preview

2010-04-29T10:52:00.006-04:00

One of the questions that keeps coming up, when people see a demo of the CEA widgets or try them out, is - "Will the widgets work with mobile devices?".

Since mobile devices have their own unique challenges around screen real estate and also touch interactions we have developed new versions of the CEA widgets, Click to call, Call notification and Cobrowse optimized for the iPhone and Android mobile browsers.

Fore more information and to download the updated ceadojo toolkit check out the
Communications Enabled Applications Mobile Widgets Technology Preview

Also if you would like to see the new widgets in action checkout the following video!

DevX article on CEA and other WAS Feature Packs

2010-02-05T10:26:00.004-05:00

Check out this article on CEA and other WAS Feature Packs on DevX.

"Imagine enabling customers to cobrowse a website with friends – without clunky browser plugins. Imagine two-way forms that help users complete gnarly virtual paperwork – without Java applets. Imagine a warehouse that phones suppliers when inventory is low."

All of those things are possible with the CEA Feature Pack. If you are just getting started, check out this link which links to some of the good content within this blog...and watch this video to learn of other great ideas like those above.

CEA now supports secure Web URIs

2010-01-14T11:41:00.003-05:00

During web collaboration sessions there was the potential for the web session to be ‘snooped’. The CEA 1.0.0.1 release took steps to resolve this. Now a random number is generated and provided as a way to prevent session snooping through man-in-the-middle attacks. The number is injected at the end of the 'invitation link' or URI that is generated and used for collaboration. When the 'invitation link' is generated a random number, called a 'nonce' is also generated and appended to the URL.

For example: http://s1.suq.hal.com/PlantsByWebSphereAjax/cobrowse.html?cea_collab=s1.1255561449053.0_2&nonce=-1554841135

is the URI User2 received from User1. User2 will paste in a browser to start the Web collaboration. User1's collaboration session will compare the nonce number value to the generated value, and if they match, the session is instantiated and Web collaboration is established.

CEA widgets now packaged with Dojo 1.3.2

2009-11-16T11:15:00.004-05:00

The ceadojo custom build packages the CEA widgets with a specific version of Dojo and eliminates the need to declare the cea module path and "importing" the widget. For the CEA 1.0.0.1 refresh a new version of Dojo 1.3.2 ( previously 1.3.1 ) was pulled in to create the custom build.

This updated version of Dojo now includes official support for:

Internet Explorer V8
Firefox 3.5
Google Chrome 2

Since the CEA widgets already supported these additional browsers this update is valuable for customers that are building pages that utilize the base Dojo functionality from the ceadojo custom build.

iWidget support for CEA widgets

2009-11-16T11:14:00.008-05:00

The core CEA widgets, ClickToCall, CallNotification and Cobrowse, can now be easily integrated into frameworks that implement the iWidget specification, for example IBM Mashup Center. These widgets have each been wrapped following the iWidget specification and packaged together in an iWidget Package file (\feature_packs\cea\samples \cea.war ) for easy deployment.

For more general information on iWidgets, please see the IBM Mashup Center wiki.

Clustering and Failover support in latest CEA refresh

2009-11-16T11:10:00.003-05:00

The latest 1.0.0.1 release of the CEA Feature Pack now includes full support for High Availability. This important new feature enables clustering and failover for both Web Collaboration and the Telephony services delivered in CEA. This capability insures that any web application built using the CEA widgets have the capability of being deployed in a highly available environment.

In addition, advancements were also delivered in this refresh with respect to converged web services in the base container. Now its possible to build a truly converged web service that will maintain session affinity to the related SIP and HTTP sessions associated with a web service session before and after a failover.

First refresh of CEA shipped

2009-11-13T11:21:00.002-05:00

At this site, you can download the first refresh fix pack of the CEA Feature Pack. Here is a list of what we changed:

Clustering and failover support for CEA services on distributed platforms (Web Collaboration and Telephony services)
iWidget support for CEA widgets
Increased Web Collaboration security
New Dojo level supported by the widgets

We'll try to blog in the upcoming weeks about some more details of these features but if you have downloaded the first release of CEA, we highly recommend picking up this fix pack!

Adding Value with Communications Enabled Applications

2009-11-10T09:00:00.004-05:00

Here is a video explaining three scenarios in which the Communications Enabled Applications Feature Pack can be used to add value to your applications and website.

This video covers three scenarios:

1) Adding CEA functions to a retail website which enables the customer to:

Click to make a call to a customer service representative
Cobrowse through the website with the customer service representative
Cobrowse with a friend through the website

2) Adding CEA functions to an insurance website

Use two way forms to help customers fill out forms and drive more forms to completion.

3) Using CEA within an inventory management system

Let the application drive calls between buyers and suppliers through the make a call web services or REST services.

If nothing else, its a very entertaining video!

Introducing Feature Packs and the CEA Feature Pack

2009-11-09T20:29:00.001-05:00

Here is a quick video I had missed the opportunity to blog about when it first came out talking about our WebSphere Application Server Feature Packs and the Communications Enabled Applications Feature Pack.

Add file transfer capabilities to the CollaborationDialog

2009-09-18T15:37:00.010-04:00

The CollaborationDialog widget in the WAS CEA feature pack provides capability that is leveraged during cobrowsing sessions. Part of the function in the widget consists of sending data between the participants in a cobrowse session. This enables function like highlighting, following, and sending a page. It's this, the capability to send data back and forth between participants, that can be leveraged to produce very useful extensions to the base CollaborationDialog widget.

Take for example the previous scenario I blogged about. In that case, a few extensions to some of the CEA widgets provided an enhanced, online communications experience between a customer and an insurance company customer service representative. What if during the course of that communication the policy was updated and the customer service representative wanted to send the new policy to the customer? Well, it could be sent via email and the customer could check it at some later time. However, a simple extension to the CollaborationDialog widget to provide file transfer capabilities will allow the customer service representative to send and the customer to receive the updated policy right away.

To do this we can leverage the CollaborationDialog widget's existing ability to send data back and forth between cobrowse participants. Your first thought may be that we actually use the data sending capability to directly send file contents back and forth, but that's not what the data sending infrastructure was designed for. Rather, it was designed to send small, chatty messages. With that in mind, we use simple AJAX functionality to post a form containing a file attachment to a backend file server. Then, we leverage the data sending infrastructure to notify the other cobrowse participant that they are being sent a file, and we provide the location of that file so it can be downloaded.

We also make some changes to the HTML and CSS files for the CollaborationDialog, and combined with the necessary JavaScript additions mentioned above, we can now choose and send files as seen below:

We can also receive files from our cobrowsing partner:

The capability to send and receive files while in a cobrowse session can significantly enhance the experience of both participants. If you are interested in how you can add this extension into your WAS CEA environment, drop a comment right here and we'll be happy to set you up with some examples.

CEA sample environment using the non default SIP port

2009-09-16T13:50:00.018-04:00

In Roger's post Setting up and Exploring the CEA Feature Pack he provided and in-depth set of instructions to get started with the feature pack. The instructions were recently updated to better support situations where the application server does not utilize the default TCP/IP ports.

This post provides an additional level of detail on setting up the CEA (WAS) configuration and the soft phones when the application server does not utilize the default SIP port, i.e., the SIP_DEFAULTHOST port is set to a value other than 5060.

The default SIP port for the Application Server is 5060. If using a different port first check the server config to determine the port that is being used. For this example I will be using port 5065.

Next update the port for Telephony access method in the Communications Enabled Application ( CEA ) settings panel from 5060 to 5065
After saving the change restart the Application Server.

Now for the soft phone setup launch Express Talk Basic and go to the Advanced Line Settings configuration ( File -> Options -> Lines Tab -> Advanced Line Settings ). Then select the radio button for Use a different outbound server and enter "localhost:5065" for Outbound Server.
After saving the changes Express Talk will re-connect to the Sample PBX Application using the new settings.

Next launch X-Lite and edit your SIP Account settings ( Show Menu -> SIP Account Settings -> Properties ). Select the radio button for Send outbound via: Proxy and enter "localhost:5065" for the Address.
After saving the changes X-Lite will re-connect to the Sample PBX Application using the new settings.

The numbers used by the widget remain the same "sip:Customer@localhost" and sip:CSR@localhost" and specifying the port is not needed.

Extending the Cobrowse widget

2009-09-04T14:33:00.016-04:00

I'm still looking at and experimenting with the WebSphere CEA Feature Pack widgets. In my last two posts I took a look at scenarios that lead to extending the WebSphere CEA ClickToCall widget. In my latest project, I took a look at the Cobrowse and CollaborationDialog widgets.

It's clear that there are many scenarios where users would want to employ and maybe even extend these two widgets. For instance, check out the demonstration below for one such scenario.

There are a few things to note about the sample as far as the extensions go. First of all, I did a very simple extension to the ClickToCall widget along the same lines of my previous posts, so I won't go into much detail about that particular piece.

Other than the ClickToCall extension, I extended both the Cobrowse (cea.widget.Cobrowse) and CollaborationDialog (cea.widget.CollaborationDialog) widgets to provide the function you see in the sample. With the Cobrowse widget, I added functionality such that when the customer service representative creates the collaboration link, a resource representing that link and the customer it is intended for is created on the backend. That was easy to do by overriding the Cobrowse widget's _convertToWaitingState method and providing custom function to create the necessary resource.

When a customer logs into the Insurance Company's home page, JavaScript running on the page checks the backend for any resources that would indicate a customer service representative has invited that particular customer to a collaboration session. In the sample video, this is shown when the customers logs into the Insurance Company's site.

Next, I needed to extend the CollaborationDialog widget in a couple of ways. First, I added the Send Policy Data button to the dialog's toolbar. All that was required to add the button was a small update to the widget's JavaScript. No HTML or CSS changes were necessary.

After that, I added a function that allows the customer service representative to send the retrieved policy information from his window to the customer's window. This was done by piggy-backing on the ability of the CollaborationDialog widget to send data back and forth between the collaboration participants. There was a nifty Dojo function that came into play when implementing this capability. Once the data was received by the CollaborationDialog instance on the customer side, the contents of the content pane in the CollaborationDialog needed to be updated. This was done by using dojo.withDoc as seen below:

dojo.withDoc(iframeDoc,
function() {
          var data = this.receivedPolicyData;
          dojo.style(dojo.byId("policyTable"), "display", "block");
          dojo.byId("policyNumText").innerHTML = data['policyNum'];
          dojo.byId("policyHolderText").innerHTML = data['policyHolder'];
          dojo.byId("policyTypeText").innerHTML = data['policyType'];
          dojo.byId("policyAmountText").innerHTML = data['policyAmount'];
          dojo.byId("policyPremiumText").innerHTML = data['policyPremium'];
          dojo.byId("policyPaymentScheduleText").innerHTML =                                                   
                     data['policyPaymentSchedule'];
          dojo.byId("policyDeductibleText").innerHTML =
                     data['policyDeductible'];
          },
          this
);

The dojo.withDoc method allowed me to update the DOM of the source HTML page for the content pane, and in this case it was extremely helpful.

The required changes to implement these widget extensions were fairly minimal considering the capabilities that were added. In fact, the backend data services for the various resources used by this sample took most of my time. If you are interested in seeing more of the code for the sample above just drop a reply to this blog post. I'd be happy to share more of the extension implementation.

More use cases for CEA widget extension

2009-08-25T13:00:00.019-04:00

Just a few days ago I documented my first example with extending the WebSphere CEA click-to-call widget to provide a customized experience between a customer and customer service representative.That experience opened my eyes to the tons of use cases for extending the click-to-call widget (or any of the WebSphere CEA widgets for that matter).

For instance, a growing trend among restaurants is to offer food ordering online. You can go online, place your order, and either have it delivered or pick it up at some later time. So, I thought about the employee back at the restaurant monitoring these orders, and in particular I thought about how they may benefit from embedding communication capabilities in that online ordering system.

Consider my fictional pizza company, The Acme Pizza Company, and the back-end to their online ordering system. The employee back at the restaurant may view a list of the pizza orders and confirm each of those orders for the kitchen team.

When the restaurant employee clicks the Confirm Order it is probably necessary to show more information about the order and the customer who placed the order. But wouldn't it also be nice to allow the restaurant employee to simply click a button to call the customer that placed the order when it was necessary?

An easy extension to the WebSphere CEA click-to-call widget gives us both the information about the order and the embedded communication capabilities that allow the restaurant employee to connect with the customer directly from the web page.

The panel you see above is a simple dijit.Dialog widget that contains an extended version of the cea.widget.ClickToCall widget. The Acme Pizza Company employee has all the information they need to confirm the order, and they can even call the customer directly from the web page if necessary.

The possibilities for extending the WebSphere CEA widgets are endless. I hope to post more scenarios of interest involving different widgets soon. In the meantime, if you're interested in the JavaScript and HTML involved in building up this extension, you can download it here.

Educational Overview of the Feature Pack

2009-08-24T08:08:00.002-04:00

Our IBM Education Assistant has some good presentations and information available to learn more about the CEA Feature Pack. I wish I could embed it here, but after trying to figure out their nested frames I gave up and thought it would be better just to link to it.

Here is the feature pack overview narrated presenation (around 15 mins long)

Also, here is the main page which also has a link to the PDF version of that presentation.

Where to get started?

2009-08-21T08:06:00.002-04:00

We have had a lot of activity on our blog here. I have had several blogs highlighting scenarios from retail to finance to inventory management. You can walk through some of the scenarios using the tag cloud on the right sidebar of the blog. Beyond that, there has been a whole bunch of information presented and I wanted to give you all a quick summary and reference to some of those blogs.

First, Roger wrote a great and verbose cheat sheet in PDF format on how to get up and running with the CEA Feature Pack and Plants by WebSphere sample. If you are looking to try it out, his document is a great place to start.

James has written some specific details on which version of vendor systems we tested our CEA Feature Pack against. He also wrote a more in depth piece on how to configure the feature pack to work with Avaya AES.

Andy wrote some getting started and advanced usage blogs on the Web 2.0 widget capabilities in the CEA Feature Pack. To get started, he wrote a blog on embedding the telephony widgets like click to call and embedding the peer to peer cobrowsing (aka coshopping) widget. He also wrote several more advanced blogs on how to create a two way form, how to handle personalized content and actions in cobrowsing scenarios, and how to add CEA widgets to a page already using another version of dojo.

Finally, we had our first guest blogger. Dustin Amrhein tried out the feature pack for the first time this week and found good ways to easily extend the Web 2.0 widgets included. He wrote his first blog showing how you can customize the click to call widget to add the ability to select a specialist. We are looking forward to him writing several more blogs on the other scenarios he tried out.

Extending WebSphere CEA widgets

2009-08-19T13:02:00.002-04:00

Since it’s my first time posting here, I guess a quick introduction is in order. My name is Dustin Amrhein and I’m a technical evangelist for emerging technologies (cool stuff) in WebSphere. I do not work on the WebSphere CEA development team, but I have been experimenting with the new CEA Feature Pack for the WebSphere Application Server lately.

The first thing I did after installing the CEA Feature Pack was install and play around with the PlantsByWebSphere sample application that is included in the install. The cool features provided by the CEA Feature Pack, like co-browse, click-to-call, and call notification immediately jump out through the sample.

With the introduction to some of the features of the CEA Feature Pack behind me, I decided to peek under the covers a bit. In particular, I was interested in the Dojo widgets that provided the interface to the functionality on display. If you are familiar with Dojo, you’re well aware that one of the benefits of Dojo widgets is that they can be easily extended to deliver custom function and interfaces. With that in mind, I decided to look into extending one of the widgets delivered by the CEA Feature Pack, the click-to-call widget.

If you look at the Contact Us page of the PlantsByWebSphere, you will see an example of the click-to-call widget:

Suppose I wanted to extend this widget just a bit. I want to give my users the option to select from a list of specialist in the different areas of my site (flowers, trees, vegetables, accessories), and once they select a particular specialist I'd like to display information about the person with whom they will be in contact. After all, it's always nice to know who's on the other end!

To do this, I first start by extending the provided cea.widget.ClickToCall JavaScript:


dojo.provide("extension.ClickToCall");
dojo.require('cea.widget.ClickToCall');

dojo.declare("extension.ClickToCall", [ dijit._Widget, dijit._Templated,
  cea.widget.ClickToCall ], {

templatePath : dojo.moduleUrl('extension', 'ClickToCall/ClickToCall.html'),
templateString : "",

handleSpecialistSelect : function(item) {
 var url = "/proxy/bpp?specialist=" + item;
 var responseHandler = dojo.hitch(this, "handleContactResponse");
 var errorHandler = dojo.hitch(this, "handleContactError");
 dojo.xhrGet( {
    url : url,
  handleAs : "json",
  timeout : 5000,
  load : responseHandler,
  error : errorHandler
 });
},

handleContactResponse : function(response, ioargs) {
 this.returnedInfoRow.style.display = "block";
 this.callInfoRow.style.display = "block";
 this.contactInfoFromGet.innerHTML = "Click the Call Me button to be contacted
    by " + response['firstName'] + " " + response['lastName'] + " in "
  + response['city'] + ". Alternatively you may email "
  + response['firstName'] + " at " + response['email'] + ".";
  this.widgetNumber = response['phone'];
},

handleContactError : function(response, ioargs) {
 console.error("error getting contact info " + response + " status " +
    ioArgs.xhr.status);
}
});

The above contains the dojo declaration of my custom widget that extends the existing cea.widget.ClickToCall. The handleSpecialistSelect above will send an HTTP GET request when a user selects the particular type of specialist with whom they wish to talk. In my case, the GET request is sent to an Ajax proxy that then forwards the request for contact information along to the appropriate service. This allows us to use data in our JavaScript that is provided by a service in a different domain. The handleContactResponse populates the page with the contact information returned from the GET request.

The JavaScript above also references a new HTML template via the templatePath variable. The new template can be seen here:

<div>
<table class="clickToCallWidget">
  <tr id="contactInfoRow">
     <td>
        <table>
           <tr dojoAttachPoint="getContactRow">
              <td>I want to contact a  
               <select
                   dojoType="dijit.form.ComboBox"
                   dojoAttachEvent="onChange:handleSpecialistSelect" id="specialist"
                   name="specialist">
                   <option value="none">-- Make Selection --</option>
                   <option value="flowers">Flowers Specialist</option>
                   <option value="trees">Trees Specialist</option>
                   <option value="vegetables">Vegetables Specialist</option>
                   <option value="accessories">Accessories Specialist</option>
               </select></td>
           </tr>
           <tr dojoAttachPoint="returnedInfoRow" style="display: hidden">
              <td><span dojoAttachPoint="contactInfoFromGet"></span></td>
           </tr>
        </table>
      </td>
   </tr>
   <tr dojoAttachPoint="callInfoRow" style="display: none">
      <td>
         <table dojoAttachPoint="callInfoTable">
            <tr>
               <td><label dojoAttachPoint="phoneNumberLabel"
                  title="${myNumberString}"><input name="phoneNumber"
                  dojoType="dijit.form.TextBox" dojoAttachPoint="phoneNumber"
                  class="clickToCallWidgetTextBox" value="${myNumberString}"></input></label>
               </td>
               <td>
                  <button dojoType="dijit.form.Button" dojoAttachEvent="onClick:call"
                   dojoAttachPoint="callButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetCallIcon"
                   class="clickToCallWidgetButton">${callButtonString}
                  </button>
               </td>
               <td>
                  <button dojoType="dijit.form.Button"
                   dojoAttachEvent="onClick:hangup" dojoAttachPoint="hangupButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetEndCallIcon"
                   class="clickToCallWidgetButton" style="display: none">${hangupButtonString}
                  </button>
               </td>
               <td>
                  <button dojoType="dijit.form.Button"
                   dojoAttachEvent="onClick:cobrowse" dojoAttachPoint="cobrowseButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetCollaborateIcon"
                   class="clickToCallWidgetButton" style="display: none">${cobrowseButtonString}
                  </button>
               </td>

            </tr>
            <tr>
               <td colspan="4" dojoAttachPoint="status" class="clickToCallWidgetStatus" style="display: none">
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>
<div dojoAttachPoint="collaborationDialog"
   dojoType="cea.widget.CollaborationDialog"
   canControlCollaboration="${canControlCollaboration}"
   defaultCollaborationUri="${defaultCollaborationUri}"
   highlightElementList="${highlightElementList}"
   isHighlightableCallback="${isHighlightableCallback}"
   isClickableCallback="${isClickableCallback}">
</div>
</div>

To get my extended click-to-call widget in the PlantsByWebSphere sample application I need to do a couple of things. First I need to add my new files to the application. I'll add them in the PlantsByWebSphere.war file within the PlantsByWebSphere.ear. Relative to the root of the WAR file, I'm adding the following:

/ceadojo/cea/extension/ClickToCall.js (JavaScript file above)

/ceadojo/cea/extension/ClickToCall/ClickToCall.html (HTML above)

I'm also going to modify the contactus.html at the root level of the PlantsByWebSphere.war to use my custom widget instead of the normal one. To accomplish this, I first add the following to the HTML head section:

<script type="text/javascript">
 ceadojo.registerModulePath("extension","../cea/extension");
 ceadojo.require("extension.ClickToCall");
 ceadojo.require("dojo.parser");
</script>

After that is taken care of, I change the value of the ceadojoType attribute. Before it referenced the cea.widget.ClickToCall widget shipped with the CEA Feature Pack. As seen below, I change the ceadojoType attribute's value to extension.ClickToCall.

<TD>

<h2>Click To Call</h2>

<div ceadojoType="extension.ClickToCall" widgetNumber="sip:CSR@localhost" enableCollaboration="true"

canControlCollaboration="true" defaultCollaborationUri="index.html">

</div>

</TD>

Now I'm ready to test out my changes. When I visit the contactus.html page, I'm greeted by a different view:

Once I select a particular specialist I want to contact, I then see information about the person who will be contacting me:

This is just one example of how the widgets provided by the WebSphere CEA Feature Pack can be extended to deliver customized function and behavior. I hope this helps give you a glimpse into the basic pattern for customizing the WebSphere CEA widgets. By the way, you can download a PDF of the JavaScript and HTML displayed above here.

Using CEA Services - Inventory Management example

2009-08-19T09:23:00.000-04:00

We have spent a lot of time talking about how to use our CEA Web 2.0 widget features in WebSphere to communications enable your website but there certainly are several other use cases we have provided for. Overall, we are providing three main access points to help communications enable your applications. We provide the Web 2.0 widgets, REST like services, and web services. I wanted to blog in more depth about the CEA services that are available in WebSphere.

First, we have a REST like service. I say REST like because while we tried to follow the REST semantics as much as possible, it definitely made more sense to build some level of affinity logic into the service to tie a HTTP request to a specific server which is participating in the telephony side of the conversation. To build a similar system stateless would have been much more challenging and not perform as well. The service however does use the REST semantics. The verbs are still HTTP methods, PUT, POST, GET, and DELETE and at the root of the URLs are nouns. The REST services use either encoded URLs or Cookies for affinity. These services either send back data in JSON or XML formats depending on which is easiest for the consumer to handle. Here is a great in depth article on the REST services in the Communications Enabled Applications Feature Pack.

Second we have web services. As I stated above, we have challenges with having affinity for these services and needing a call back mechanism in order to get updates about the call state. We used WS-Adressing to deal with the affinity issues by having specially encoded end point references which tie the web services to a backend SIP session talking to your telephony infrastructure. We also use WS-Notification as a way to send updates about a particular call state.
Here is a good reference usage of using the web services to make a phone call.

So, how can these be used? Well, one example as briefly talked about in the video above is in an inventory management system. When the inventory begins to run low, a call could be made between the buyer and supplier using web services so that more stock could be ordered. This could be in addition to sending the appropriate message to the buyer letting them know what is low, what needs ordered, and the account information for the supplier. Now, this scenario could also be handled through REST integration or even using the widgets, it really just depends where the right place in your existing application is to plug in communications.

Setting Up and Exploring the CEA Feature Pack

2009-08-13T20:10:00.006-04:00

Version 1.0.0.1 of the Feature Pack for CEA now includes a dedicated demonstration system setup guide, as well as a set of scripts to automate many of the setup tasks. For further information, please see the IBM WebSphere Application Server Information Center, as well as the following support page: CEA Feature Pack Fix Pack V1.0.0.1 for WebSphere Application Server V7.

Communications Enabled Applications Vendor Interoperability

2009-08-12T09:37:00.001-04:00

With so much buzz around the release of the Communications Enabled Applications 1.0.0.0 feature pack I would like to highlight the vendors that we worked closely with to ensure product interoperability.

Below is a listing of each vendor and PBX version used in our testing.

Avaya:
Application Enablement Services
Version: r4-2-1-20-5-0
Server Type: DELL1950
Offer Type: TURNKEY

Cisco:
Cisco Unified CM Administration
System version: 7.0.1.11000-2
Cisco Unified Presence Administration
System version: 7.0.2.10000-36

Nortel:
Nortel Communication Server 1000E CPPM
Version: 4021
Release: 550J

I would like to thank Avaya, Cisco, and Nortel for their support in helping us ensure our product worked seamlessly with their specific PBX solution.

How to configure WAS CEA to use Avaya AES 4.2

2009-08-05T15:34:00.000-04:00

We are proud to announce that Avaya's PBX solution, Application Enablement Server (AES) version 4.2, passed all initial interoperability tests with CEA 1.0.0.0. We are successfully able to control various telephony endpoints configured on the AES directly from our CEA 1.0.0.0 enabled application. As with most interoperability tests, there were a few issues that were exposed that had to be addressed. This blog post will serve as an early warning to the greater community of how to get around a major issue we found when inter oping with AES 4.2.

The Avaya AES 4.2 only supports the TLS transport for receiving TR/87 requests. This prerequisite is fine as CEA supports sending requests over UDP, TCP, or TLS transports. However, there is a problem where AES 4.2 does not support "sips:" over the TLS transport. This is a bug in their code and they are working to fix this in a subsequent release. In the mean time, a work around has been crafted to circumvent this issue.

By default, the Websphere Application Server (WAS) has UDP, TCP, and TLS defined as available transports to send data across the network. When CEA 1.0.0.0 constructs a request outbound to a PBX over UDP or TCP it uses the "sip:" construct in the request. This typically denotes that the request is not secured when its sent out over the network.

Example:

Invite Request: INVITE sip:+19194863101@subzero.rtp.raleigh.ibm.com:4723;user=phone;transport=tcp SIP/2.0
From: sip:ibmtest1@9.42.92.132;tag=5109292067337619_local.1249402695153_2_1
To:
Call-ID: 5620596434574489@9.42.92.132
Max-Forwards: 70
CSeq: 2 INVITE
Content-Type: application/csta+xml
Content-Length: 362

However, if you delete a transport channel, WAS will only utilize the remaining transports to send data. We will use this behavior to our advantage.

What we want do is delete the UDP and TCP transport thus only leaving the TLS transport available to send CEA traffic. You can do this by browsing to Application Servers --> Server Name --> Transport chains. You should see a menu like the one presented below.

Select and Delete the SIPCInboundDefault and the SIPInboundDefaultUDP . This will leave you with the SIPCInboundDefaultSecure (TLS Chain).

On the CEA configuration panel where you specify the host, port, and transport of your Avaya AES, you will specify TCP as the outbound transport.

By doing this, the CEA application will construct its outbound request to the AES server using the "sip:" construct. Normally, CEA would attempt to send out the TR/87 request to the AES over the TCP transport you defined on the panel, but since only the TLS transport is available, its forces WAS to send the TCP formatted request over the TLS transport.

Thus, you get a "sip:" constructed request over a TLS transport. This is exactly what the Avaya AES supports.

Example:

Invite Request: INVITE sips:+19194863101@subzero.rtp.raleigh.ibm.com:4723;user=phone;transport=tls SIP/2.0
From: sip:ibmtest1@9.42.92.132;tag=5109292067337619_local.1249402695153_2_1
To:
Call-ID: 5620596434574489@9.42.92.132
Max-Forwards: 70
CSeq: 2 INVITE
Content-Type: application/csta+xml
Content-Length: 362

Retailers need WebSphere CEA

2009-08-05T10:00:00.000-04:00

There have been so many times lately that I have been realizing that websites need the WebSphere CEA features and functions. Recently my wife was shopping online and trying to send me links and describe over instant messaging what she was seeing. It was painful and we finally decided we would hold off until later that evening. We forgot that night and looked again at it a day later. That was a sale that was almost lost. Actually, to be honest, the sale was lost...but had we had peer to peer cobrowsing on that site we may have purchased it that first day.

I have also had the experience many times when buying gifts where I knew nothing about the subject matter and had to call a company or visit their store. Whether it was custom jewelry I bought my wife for mother's day or shopping for something for my own mother, there are times I just need more information than I can find online.

After talking to a major US retail company the past couple of days it became evident that our CEA functions when shown were much more amazing. This is why I made the video above, to show this typical experience I have when shopping for something and I need help. But the ability to shop with a friend brings a whole new experience to online shopping and could help drive another boost to online commerce sites. Below I have shown a video describing how that interaction might work.

There are other major areas when seeing something online would be useful when on the phone. For example, last year it was apparent our credit card info was stolen and had to call into Chase and describe the transactions that were invalid. We could have saved time if I could have shown them which transactions through a couple of clicks rather than describing them. But security is a constraint...can you show your customer information without security? How about without a plugin? The CEA FEP does this with security, using the application's current security model. There is no plugin, its all Javascript. It requires some new thinking - but not necessarily new code. :-) We'll talk more about secure cobrowsing soon...

Creating a Basic Two Way Form

2009-08-04T08:31:00.000-04:00

We had a brief description of the Two Way Forms feature back in May and since then we've gotten a lot of great feedback. I'd like to expand on that and show the steps necessary to augment an existing dojo dijit style form to create a Two Way Form.

Here is a very simple dojo dijit style form with a single text field

<html>
<head>
   <script type="text/javascript" src="/PlantsByWebSphereAjax/dojo/dojo.js"
     djconfig="parseOnLoad: true, isDebug: false"></script>
    
   <script type="text/javascript">
      dojo.require("dijit.form.TextBox");
      dojo.require("dojo.parser");
   </script>
   <style>
      @import "/PlantsByWebSphereAjax/dijit/themes/tundra/tundra.css";    
   </style>
</head>

<body class="tundra">
   <form method="post" action="/PlantsByWebSphereAjax/myAction">
   <table border="0" cellpadding="0" cellspacing="5" width="100%">
      <tr>
    <td><label for="fullName">Full Name</label></td>
    <td><input id="fullName" type="text" name="fullName" class="medium" dojoType="dijit.form.TextBox"/></td>
      </tr>
 <tr>
    <td><input type="button" name="submit" value="Submit" alt="Submit"></td>
 </tr>
   </table>
   </form>
</body>
</html>

1. The first step when creating a Two Way Form is to replace the existing javascript import with one pointing to ceadojo, the ceadojo toolkit must first be copied to the application from the WAS install.

 <script type="text/javascript" src="/PlantsByWebSphereAjax/ceadojo/dojo/dojo.js"

2. Next you need to replace dojo.require statements with ceadojo.require.

 ceadojo.require("dijit.form.TextBox");
 ceadojo.require("dojo.parser");

3. Then replace dojoType with ceadojoType for the input element.

 <input id="fullName" type="text" name="fullName" class="medium" ceadojoType="dijit.form.TextBox"/>

These first three steps update the form to use the ceadojo toolkit that is included in the CEA Feature Pack. Since the Two Way Form interacts with the other CEA widgets to send and receive the notifications its is required that they all use the same version of dojo.

4. Next add the CSS import for the Two Way Form's style

<style>
 @import "/PlantsByWebSphereAjax/ceadojo/dijit/themes/tundra/tundra.css";
 @import "/PlantsByWebSphereAjax/ceadojo/cea/widget/TwoWayForm/TwoWayForm.css";   
</style>

5. Finally add ceadojoType="cea.widget.TwoWayForm" to the form element

<form method="post" action="/PlantsByWebSphereAjax/myAction" ceadojoType="cea.widget.TwoWayForm">

With these five changes you have created the most basic Two Way Form. At this point both the reader and writer will have access to modify the field.

Lets take it a step further. For this scenario we only want the writer to have access to modify the field. By setting the ceaCollabWriteAccess attribute we can make the field read-only for one of the peers.

 <input id="fullName" type="text" name="fullName" class="medium" ceadojoType="dijit.form.TextBox" ceaCollabWriteAccess="writer"/>

Note: The roles of reader and writer are determined by who has collaboration control when the Two Way Form is launched. The active user will be the writer and the passive user the reader.

Two Way Forms also offer the ability to perform field validation and data masking for more information on these two topics please check out the Infocenter.

One of the questions that keeps coming up is whether a Two Way Form can be used outside of the Contact center cobrowsing and Peer to peer cobrowsing scenarios. The answer is yes. This works because when the Two Way Form is loaded it checks to see if its being used in a collaboration session and if not the additional attributes are ignored.

This gives you the ability to augment an existing form and only have one copy that can be used for both the single user scenario and the collaborative scenarios offered thru the CEA widgets.

CEA Packs a Punch with PBX Interoperability

2009-07-31T10:50:00.000-04:00

CEA 1.0.0.0 now gives system administrators the ability to extend their telephony and J2EE architecture to include 3^rd party SIP-CTI enabled PBXs. This feature strategically allows IT environments running WebSphere Application Server (WAS) the flexibility to extend their current applications to include features and functionality supplied through the WebSphere implementation of the SIP-CTI (ECMA TR/87) API.

From an interoperability standpoint, we attempted to make the setup and configuration of an external PBX as painless as possible. We’ve created a panel that will require you to specify the hostname, port, and protocol of the SIP CTI (ECMA TR/87) Gateway. Also, if your gateway supports this, you can specify a “superuser” that will be solely utilized to authenticate and authorize outbound calls through the gateway. Conversely, if your PBX does not support the use of a “superuser”, an application developer has the option of extracting the username from the request and using it to authenticate and authorize the outbound call.

For those out there who do not have access to their PBX, we’ve also included a sample PBX application which can be deployed on stand alone appserver. Although this application is for test purposes only, this sample PBX will allow a customer to get a feel as to how to deploy and test applications that interact with a virtual SIP CTI enabled PBX.

It’s our hope that you take action in deploying and consuming all of the new features made available in the CEA feature pack. In future posts, I will be blogging about some of the technical nuances that you should be mindful of when deploying a CEA solution with specific vendor PBXs.

CEA Feature Pack available for download!

2009-07-31T10:25:00.000-04:00

We are happy to announce that the CEA Feature Pack is available for download. The CEA Feature Pack can be downloaded here: http://www.ibm.com/software/webservers/appserv/was/featurepacks/cea/.

Additionally, the new documentation (aka InfoCenter) is available here: http://www-01.ibm.com/software/webservers/appserv/was/library/v70/fp-cv/index.html.

Finally, here are the support pages: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27016107.

All of the links will be updated in the sidebar ---->

Interoperability with major vendors

2009-07-31T08:04:00.001-04:00

One of the things that we believe makes WebSphere CEA unique and ready for our customer's environments is that we partner with and test our solution with major vendors like Avaya and Cisco. These partners have helped us to create a solution that is ready for customer deployments. In the next couple of weeks, our lead interoperability engineer, James Hales, will be talking about how some of this works. I talked James into doing the above spoof video to introduce the set of blogs about testing and interoperability.

CEA FEP will be available tomorrow!

2009-07-30T14:37:00.000-04:00

Recently, we sent out an announcement about the availability of the WebSphere Application Server Feature Pack for Communications Enabled Applications (CEA) V1.0 . I wanted to highlight some of the points in the announcement..

Planned availability date
July 31, 2009

The WebSphere Application Server family is an innovative, performance-based application foundation for building, deploying, and managing all types of applications, and for ensuring they deliver on business objectives regardless of the situation. At its core, it provides a highly-effective performance foundation for creating and implementing agile and re-useable SOA applications and services. This Smart SOA Application Foundation can help you to deliver on business objectives and contain or even reduce cost across mainframe and distributed applications and all interaction modes (for example, Web 2.0 or voice).
Only WebSphere Application Server has the three foundational attributes to enable robust and agile business applications:
Efficient development and management
Highly effective performance
Application innovation

The WebSphere Application Server Feature Pack for Communications Enabled Applications (CEA) V1.0 helps simplify development of innovative applications by offering an SOA-based programming model to add multimodal communications capabilities such as Click to call, Cobrowsing and Two-way Synchronized Forms, to existing and new applications using existing Java skills.
WebSphere Application Server Feature Pack for Communications Enabled Applications V1.0 is a product extension available to WebSphere Application Server V7.0 customers that:
Delivers an innovative programming model that simplifies the addition of communications capabilities into existing and new applications by leveraging existing Java skills
Provides Web services and REST services-based APIs which enable a richer user experience and increases user interaction effectiveness
Delivers customizable and extensible multi-modal communications widgets: Click to call, Contact Center Cobrowsing, peer-to-peer Cobrowsing and Two-way Synchronized Forms
Provides a unit test environment to prototype and test applications without the need to access the corporate Telephony/Unified Communications network
Provides third party Telephony/Unified Communications support and an on-ramp to CEBP (communications enabled business process) solutions
Supports the latest Session Initiation Protocol (SIP) Servlet 1.1 standard (JSR 289)

Telephony interoperability -- Tested with leading Telephony/Unified Communications solutions:
Avaya Communication Manager
Cisco Unified Communications Manager

We were so excited to have gotten this release out the door and into our customer's hands. The entire team did a great job innovating throughout this product and we did a significant amount of test against the platform even testing against Cisco and Avaya infrastructures. We plan to have more information on our testing and usage of the product now that we are generally available but go on and download the feature pack and try it out for yourself!

Handling personalized actions in a cobrowsing session

2009-07-13T13:36:00.000-04:00

Another scenario to consider with commerce applications is personalized actions for example "Add to Cart", "Add to wishlist" and "Checkout" buttons. In a cobrowsing session it may make sense to block a user from sharing those actions when "Follow-Me' mode is enabled. This way one user adding an item to their shopping cart will not cause the peer to also add the item. This can be accomplished by writing a callback function and then specifying the function name for the isClickableCallback attribute of the CEA widgets:

<div ceadojoType="cea.widget.Cobrowse" joinCollaborationURI="PlantsByWebSphereAjax/cobrowse.html" defaultCollaborationUri="PlantsByWebSphereAjax/index.html" isClickableCallback="cobrowseClickable"></div>

This callback function will be called each time the passive user receives a "Follow me" event from the peer. If the function returns true the information is processed and the click is performed. If the function returns false a warning message is displayed informing the user that the peer's action can not be followed.

The callback function is passed the HTML element that will be clicked and must return a boolean, the application developer can use a number of approaches to determine if the element is clickable . For example in the sample code below we want to disallow the user from clicking the "Add to cart" button:

function cobrowseClickable(node) {
// Summary: Callback function to allow the application to
// determine if a specific node click should be sent to the peer
if (node.innerHTML == "Add to cart" || node.alt == "Add to Cart"){
return false;
}
return true;
}

In this example the code checks if either the button text or alt text matches "Add to cart" and if so returns false to denote that this element can not be clicked. For all other elements it returns true.

Handling personalized content in a cobrowsing session

2009-07-10T15:47:00.000-04:00

In commerce applications a page may contain personalized content for example a user's shopping cart or a targeted product recommendation.

When two users are cobrowsing using the CEA widgets the personalized sections of the page may be completely different. In this scenario it makes sense to block the users from highlighting the personalized content. This will minimize the chance of a user trying to highlight and draw attention to content that is not shown on the peer user's page.

This can be done by writing a callback function and then specifying the function name for the isHighlightableCallback attribute of the CEA widgets:

<div ceadojoType="cea.widget.Cobrowse" joinCollaborationURI="PlantsByWebSphereAjax/cobrowse.html" defaultCollaborationUri="index.html" isHighlightableCallback="cobrowseHighlightable"></div>

This callback function will be called each time a user mouses over a HTML element after clicking the highlight button. If the function returns true the element's style will be updated to show that it can be highlighted. If it returns false no change is made. If the user attempts to click on an element that is not highlightable a warning message will be displayed.

The callback function is passed in the current HTML element and must return a boolean, beyond that the application developer has the freedom to decide how to determine if an element is highlightable . For example in the sample code below we want to disallow the user from highlighting the shopping cart:

function cobrowseHighlightable(node) {
// Summary: Callback function to allow the application
// to determine if a specific node is highlightable
if (node.id == "ibm_widget_HtmlShoppingCart_0"){
return false;
} else {
//If this is not the shopping cart then use the default logic
// to make sure its a highlight element
var highlightElementArray = ["DIV","SPAN","TR","TH","TD","P"];
var isHighlightableElement = false;
for (var i=0; i

This example uses the node.id to determine that the element is the shopping cart and then returns false so that it will not be highlighted.

One other note is that specifying the callback function overrides the default processing of the highlightElementList. The highlightElementList is used to determine what HTML elements can be highlighted. The sample code above shows how to add this logic if needed for your callback.

Web communications enhancing interactions

2009-07-09T09:21:00.000-04:00

One of the common questions as people are learning about our WebSphere Communications Enabled Applications (CEA) function is if we are trying to replace interactions with "real people" when they see features such as the cobrowsing. The real idea behind CEA is using an interactions via the web to enhance real time communications which could be phone calls or instant messaging. There are several scenarios that we try to show in the demo video below, but here are some of the common issues that a web based interaction could solve in a contact center:

Click to Call:

Increase efficiency by removing the need for people to type in phone numbers they see on a web site.
Help a user connect to the most relevant help based on what page they are on without having to traverse a voice based menu system.
Provide the backend contact center with relevant user information from their web session.

Contact Center Cobrowsing

Help explain complex data to customers which may be too difficult to describe. Some examples include mortgage closing costs, insurance policy details, order information, financial transaction details, or product information. Customers could print or save the information which could result in them not having to transcribe what the contact center representative is saying.
Teach a customer how to use a specific site rather than just telling them an answer so that they may not need to call again for a similar issue.

Two way forms

Allows a customer to visually verify information rather than waiting for the contact center representative to repeat it. For example, a misspelled last name can take time, cause problems looking up information in the future, and decrease customer satisfaction. Two way forms allows the customer to visually verify what the contact center representative has entered.
Either party in the session could fill out some fields which, if it makes more sense for the customer to do it, can increase efficiency.
Some vital data like Social Security Numbers or Account/Credit Card numbers could be entered by the customer and obfuscated to the contact center representative reducing the risk of critical information being misused.

All of these scenarios are in the context of a real time communications session like a phone call. Here is a demo we have shown in the past showing these features in a contact center scenario. Download the beta now from the link on the right hand column and try the application shown below yourself.

Adding a CEA widget to a page already using Dojo

2009-07-01T21:06:00.000-04:00

The Dojo Toolkit, starting in version 1.1, offers the ability to use multiple versions of Dojo in the same page. This feature comes in handy when users want to experiment with a new version of Dojo or when using a custom namespaced library like the one shipped with the CEA Feature Pack. For a detailed description of how using multiple Dojo versions works please see this dojotoolkit article.

To enable users to utilize a previous version of Dojo, we provide a custom namespaced library called ceadojo and all of the components you need to embed the CEA widgets with their own dojo version. This custom namespaced library has baked-in a djConfig.scopeMap to map dojo, dijit and dojox to ceadojo, ceadijit and ceadojox respectively. This essentially allows a user to embed the CEA widgets and keep them isolated from an existing version of Dojo running on the page.

In the last two posts I covered how to embed the CEA widgets on a page that is not already using a Dojo Toolkit. This next example shows the updated steps to import ceadojo when your application is already using a Dojo Toolkit.

Here is an example of the existing script tag to include your version of Dojo for the page.

<script type="text/javascript" src="./dojo/dojo.js"
djconfig="parseOnLoad: true, isDebug: false"></script>

Widgets using this toolkit will use "dojoType" to define a widget. Typically this is the way that pages using Dojo instantiate a widget, so when embedding a CEA widget no changes are necessary to the widgets already placed on the page.

The next script tag is used to redefine djConfig to allow proper loading of the ceadojo NLS files.

<script type="text/javascript">
var djConfig = { baseUrl:"./ceadojo/dojo/" };
</script>

The final step is to import the ceadojo toolkit for use on the page. The CEA widgets are defined using "ceaDojoType".

<script type="text/javascript" src="./ceadojo/dojo/dojo.js"></script>

The HTML for importing the CSS and placing the widget on the page remain the same as the exanples in the last two posts.

Embedding the CEA Peer to Peer Cobrowsing Widget

2009-07-01T21:05:00.001-04:00

The first step when embedding any of the CEA widgets into your application is to copy the ceadojo directory ( <washome>\feature_packs\cea\javascript\ceadojo ) into your application.

Based on where you copied the ceadojo directory you will need to use that path when pointing to the various JavaScript and CSS files. For this post I will assume that I've copied the ceadojo directory directly under the context root and the HTML file that I am adding the widget to is at the same path.

For the Peer to peer cobrowsing widget we need to import the following CSS files:

<style type="text/css">
@import "./ceadojo/dijit/themes/tundra/tundra.css";
@import "./ceadojo/cea/widget/Cobrowse/Cobrowse.css";
@import "./ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
</style>

The next step is to import the CEA widget toolkit. Importing the CEA widget toolkit is just like importing any other Dojo toolkit.

<script type="text/javascript" src="./ceadojo/dojo/dojo.js" djConfig="parseOnLoad: true, isDebug: false"></script>

The CEA widgets are built on top of Dojo's Tundra theme. So next we need to add this theme to the body:

<body class="tundra">

And finally the last step is to place the CEA widget on the page. The following HTML code snippet will place the Peer to peer cobrowsing widget on the page:

<div ceadojoType="cea.widget.Cobrowse" joinCollaborationURI="PlantsByWebSphereAjax/cobrowse.html" defaultCollaborationUri="index.html" ></div>

There are a few additional attributes that need to be configured for Peer to peer cobrowsing.

joinCollaborationURI is used by the Peer to peer cobrowsing widget to generate the invitation link that can be sent to the peer.
This needs to be a link to a page that contains the Peer to peer cobrowsing widget and can accept an additional request paramater. Commonly this will be a link to the current page you are adding the widget to or a specific page created with instructions detailing how to use Peer to peer cobrowsing. For example in the plants sample we used the same page we added the widget to "/PlantsByWebSphereAjax/cobrowse.html"
defaultCollaborationUri specifies what page to load first when Peer to peer cobrowsing is started. For example in the Plants sample we used "/PlantsByWebSphereAjax/index.html"

Embedding the CEA Telephony Widgets

2009-06-05T14:54:00.001-04:00

The first step when embedding any of the CEA widgets into your application is to copy the ceadojo directory ( <washome>\feature_packs\cea\javascript\ceadojo ) into your application.

Based on where you copied the ceadojo directory you will need to use that path when pointing to the various JavaScript and CSS files. For this post I will assume that I've copied the ceadojo directory directly under the context root and the HTML file that I am adding the widget to is at the same path.

For the Click to call widget we need to import the following CSS files:

<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";
</style>

The CSS imports for the Call notification widget are the same just replace ClickToCall/ClickToCall.css with CallNotification/CallNotification.css.

The next step is to import the CEA widget toolkit. Importing the CEA widget toolkit is just like importing any other Dojo toolkit. This step is the same for both telephony widgets. ( Note: I will cover the steps to import ceadojo on a page already using Dojo in a later post )

<script type="text/javascript" src="./ceadojo/dojo/dojo.js" djConfig="parseOnLoad: true, isDebug: false"></script>

The CEA widgets are built on top of Dojo's Tundra theme. So next we need to add this theme to the body:

<body class="tundra">

And finally the last step is to place the CEA widget on the page. The following HTML code snippet will place the Click to call widget on the page:

<div ceadojoType="cea.widget.ClickToCall" widgetNumber="xxx-xxx-xxxx" enableCollaboration="true" canControlCollaboration="true" defaultCollaborationUri="cobrowseWelcome.html"></div>

There are a few additional attributes that need to be configured for Click to call.

widgetNumber is used by the Click to call widget to determine what number to call.
enableCollaboration determines whether this widget will be made available for Contact center cobrowsing. If Contact center cobrowsing is enabled you should also configure the next two attributes
canControlCollaboration determines whether this widget will be able to drive the collaboration session
defaultCollaborationUri specifies what page to load first when the Contact center cobrowsing is started.

The following HTML code snippet will place the Call notification widget on the page:

<div ceadojoType="cea.widget.CallNotification" enableCollaboration="true" canControlCollaboration="true" defaultCollaborationUri="index.html"></div>

For the Call notification widget the same attributes apply, however "widgetNumber" is an optional attribute that determines what number to monitor for incoming calls. If not specified the user will be presented with a textfield to enter the number.

Embedding the CEA widgets in your application

2009-06-05T14:22:00.000-04:00

In Erik's post "Widgets in the CEA Feature Pack" he gave a high level overview of some of the widgets that are included in the CEA Feature Pack. I'd like to take it step further in the next few posts and discuss how easy it is to embed each of these widgets in your application.

If you had a chance to check out our widgets in the Open Beta you will notice that the steps to embed the widgets have gotten simplier. This is all thanks to the ceadojo custom build that was shipped with the Beta refresh. This custom build packages the CEA widgets with a specific version of Dojo and eliminates the need to declare the cea module path and "importing" the widget.

Refresh of the Communications Enabled Applications Beta

2009-06-04T15:58:00.000-04:00

Good news! We have a refresh available of our Communications Enabled Applications Feature Pack.. This refresh provides a lot of fixes as well as some new function. With this refresh we are going to start to blog how some of these APIs, particularly the easy to embed web widgets, can be added to applications and websites.

One new piece of function included in this release is the ability to support third party providers of the underlying telephony integration. This will allow our partners to provide Unified Communications integration with extended functionality or in a way other than through using SIP CTI.

I would encourage you all to download the beta refresh and install it!

Extending the CEA Cobrowsing feature

2009-05-15T14:31:00.000-04:00

The widgets in our Communications Enabled Applications Feature Pack are very extendable. When we first created it, we thought of many ways to extend those widgets. Below is one example I have...

In that video, I talked about adding basic instant messaging to the cobrowsing window. Inserted in that interview was a recorded usage of our WebSphere Commerce sample we showed at Impact where our WebSphere Commerce team integrated the CEA cobrowsing functionality into their sample store and then extended the cobrowsing Web 2.0 widget with instant messaging support. For a javascript developer, adding this function on top of our existing cobrowsing function would take just a couple of days.

Over time on our blog here we plan to post descriptions and sample code as to how you would do these sorts of extensions to help further a rich communications experience over multiple modalities. For now, if you have some great ideas on what else we could be adding into the cobrowsing scenario please comment here, tweet @burckart, or send me an email to ejburcka at us dot ibm dot com. We will consider these for future blogs or releases!

Provisioning Complexity in JBoss and Glassfish

2009-05-13T07:18:00.000-04:00

Ask most enterprise IT developers how to provision their application into a telephony infrastructure and I imagine you won't get many answers. IT applications have far different implications than a telephony applications. Furthermore, most IT developers and administrators do not know much about the telephony infrastructure. This is why an IT person trying to provision their communications enabled applications into a telephony system is overly complicated and therefore expensive. This complexity is exactly what solutions such as JBoss and Glassfish are trying to pass on to enterprise IT developers and administrators.

In our Communications Enabled Applications Feature Pack, we worked hard to significantly reduce the provisioning complexity associated with creating a communications enabled application. We built our telephony access services in such a way that keeps our services out of the flow of a telephone call. We did this using SIP CTI, a standard formally called ECMA TR/87 which many unified communications vendors provide solutions for. In other words, we left the telephony call flows to the unified communications vendors and kept ourselves out of the call flow.

If your communications enabled applications require new servers or services to be provisioned into your telephony environment, you have to become a telephony expert, learn how your machine will affect real time communications, and deal with your network side of your business which may not be thrilled to have IT applications in the network. The politics alone around trying to provision your application into your telephony infrastructure may make it impossible. Our Feature Pack for CEA avoids these issues and even helps you complete a POC without having corporate telephony access through our unit test environment.

On the other hand, JBoss and Glassfish implement something such as RFC 3725. Its not important to understand that RFC, but more important to understand the implications of that RFC. The call flow of RFC 3725 looks something like this:

In that call flow, the telephony access services is in the phone call the entire time. These services must know about every piece of communications between devices. For call notifications, every call, whether the phone is being monitored or not, must go through this controller. This is a provisioning nightmare and frankly this is why telephony providers offer their systems as hardware because the standard IT administrator does not need to know how to provision a system into a real time call flow.

SIP CTI, on the other hand, works in a different manner. In this, our telephony access services connects to a SIP CTI Gateway provided by the unified communications vendor. That gateway is in the call flow while the SIP CTI client gets asynchronous messages letting it know what is going on with the call or phone.

Utilizing SIP CTI, we are able to stay out of the call flow and avoid passing the complexity of provisioning a IT application into a real time communications environment on to our users whereas with JBoss and Glassfish you are stuck knowing all the details about the call in the RFC 3725 picture. We send our messages to the SIP CTI gateway and let them deal with the details about how to connect up the call. Various vendors offer these SIP CTI Gateways, Cisco has one built into their Unified Presence Server, Nortel has one on their CS1000, Avaya has one in their Application Enablement Services, and many others also have them. These gateways keep our code out of the call flow path and significantly reduce the expertise needed to create a communications enabled application.

Does this mean we don't have the expertise in unified communications? Of course not. IBM is a leading unified communications provider with IBM Sametime, our WebSphere Application Server is used in companies like AT&T for their telecommunications services, and our services team is a leader in the unified communications space with their Converged communications services. Those services are even ready to help utilize our CEA Feature Pack today. Not only do we have the expertise to work in the unified communications space, we have the partners to make the solution work great. An example of some of our partners in unified communications can be seen here. Names like Cisco, Avaya, Nortel, Siemens, Alcatel Lucent, NEC, Mitel, and Dialogic.

Reducing the complexity of provisioning your communications enabled application will continue to be a top requirement in our communications enabled application solutions.

Getting Started with the CEA Widgets is Easy!

2009-05-11T09:12:00.000-04:00

From the very outset of the CEA project, the development team has focused on providing a top-notch out-of-the-box experience; as a result, installing, configuring, and exploring the feature pack is quick and easy. The beta library materials provide complete setup instructions, but we would like to highlight the basic steps here today.

Download and install the new IBM Installation Manager utility available via IBM WebSphere Application Server V 7.0 Feature Pack for Communications Enabled Applications Open Beta. Then use Installation Manager to install the CEA Feature Pack. (Installation Manager already includes the addresses of the appropriate IBM software repositories.)
Create new configuration profile(s) that support CEA or augment your existing profile(s) to support CEA.
Install, configure, and start the sample IP-PBX application included with CEA.
Download, install, and configure two instances of a free softphone (available from several suggested vendors).
Configure, install, and start the CEA PlantsByWebSphereAjax sample application (site) that includes the widgets.

After completing these steps, you can use the CEA PlantsByWebSphereAjax application to verify your setup and explore the features of the widgets. (CEA also includes samples for exploring the Web Services interfaces to the communications features.)

It's that easy...

JSR 289 Compliance and documentation

2009-05-11T07:39:00.000-04:00

For the enterprise, Communications Enabled Applications (CEA) are about using existing programming skills (Java, web services, javascript, HTML) to be able to access communications services. But for some of our communications partners and customers, the communications applications they are creating require a robust infrastructure with some extensive telecommunications standards. Our feature pack, the WebSphere Application Server v7.0 Feature Pack for Communications Enabled Applications, also produced the latest SIP Servlet specification, SIP Servlet 1.1, for these customers. The openly available beta provides that JSR 289 support and is fully compliant. Here is a snapshot of the API report in the specification, 100% compliant.

We did have some exclusions as part of the testing, all of which were agreed to by the specification leads.

Recognizing we have two types of users creating applications with the CEA feature pack, we adjusted the way we show our documentation to reflect that. The beta documentation is linked on the right hand side of this blog. If you click on that you will note that under the feature pack's documentation we have two sections entitled "Accessing communications in business applications" and "Creating SIP communications applications." The former is for those business users looking to use their existing programming knowledge in areas such as Java, web services, Javascript, or just HTML. The latter is focussed on the advanced communications developers who are looking to build applications utilizing SIP.

Contact Center Demo of CEA function

2009-05-06T09:39:00.000-04:00

Here is another homemade demonstration of the WebSphere Application Server Communications Enabled Applications function in a Contact Center environment. Here we have our call notification widget, click to call widget, and contact center cobrowsing functionality embedded in our Plants by WebSphere sample application.

Savio wrote more about how these Contact Center scenarios can play out here. Also, the widgets have some further detail here in a blog I wrote. Finally, if you are at IBM Impact this week, check out our 10:30 AM Session in Murano 3205 entitled "Lower Costs, Improve Satisfaction with Communications-Enabled Applications." And, more importantly, ask us questions while there!

Peer to Peer cobrowsing in retail makes for a real coshopping experience?

2009-05-06T01:29:00.000-04:00

A couple of days ago, Savio wrote more about utilizing our peer to peer cobrowsing functionality. Today at Impact 2009, we demonstrated WebSphere Commerce utilizing the peer to peer cobrowsing widget to allow for a coshopping environment. In this, Daisy Tan extended the cobrowsing functionality to add instant messaging into a Commerce deployment so that users of that could cobrowse and instant message with one another in the cobrowsing modal window. Perhaps I will get a demo of that integration up later, but for now here is a homemade video of the peer to peer cobrowsing with the sample provided in the feature pack. This shows a simple scenario for coshopping within the application. Our demonstration could have been just as easily a travel planning application, insurance benefits application, or any number of applications allowing two people to view a similar page and use the web as another communication modality. Check it out and let us know what you think! (aside from the fact that I am obviously not a professional voiceover guy or video editor ;-) )

Your applications need a dose of CEA - Peer to Peer Scenario

2009-05-03T15:05:00.000-04:00

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions. Well, what does that really mean? I've already covered the Contact Center scenario. Now, let's discuss a Peer to Peer scenario.

Your loyal customers, Savio and Hilary, always use your travel planning website to decide on itineraries and book travel.

Savio is away at IMPACT for a week. This leaves Hilary alone with their two month old. Erik, Savio's wise friend suggests Savio take Hilary on a vacation as a "thanks for putting up with me and rearing our child while I travel". Hilary loves to be involved in vacation planning. But Savio's in Vegas and Hilary's in Toronto (See P.S. below). Savio IM's Hilary and proposes the vacation idea. She's in. Now the tough part. Deciding where, which flight, hotel and car. It's made tougher by the fact that their multi-modal interaction is not linked in any way.

If Savio and Hilary continue the interaction over IM, they're forced to send URLs back and forth to keep track of the itinerary item that the other person is looking at. But then, they'd also have to type "flight #348 will get us in on time" and similar information into the IM application. But switching over from IM to the phone is no better because they still have to describe which page each person is on, (spelling out a URL over the phone...FUN!?!?), and which flight they are looking at etc. Savio and Hilary are in for a poor user interaction no matter how you slice it.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario of two users trying to jointly make a decision through a multi-modal interaction.

Peer to Peer Cobrowsing
Let's start the same scenario off with a Peer to Peer Cobrowsing Web Widget that is delivered in the WAS V7 Feature Pack for CEA Beta. Savio would click on the "Invitation Link" button on your website and IM it to Hilary. Once Hilary clicks the link, Savio and Hilary would be in a shared session together. There's not software for Savio or Hilary to install to enable this shared session. In fact, Savio and Hilary have individual sessions with WebSphere Application Server, so there's an added layer of security. Calling this feature Peer to WebSphere Application Server to Peer, while perfectly okay with the IBM Naming Police, seemed cumbersome. Ease of use and security? Check.

With this shared session both Savio & Hilary can take control and direct what is shown on the other person's browser window. Both can highlight elements on the page for the other person to see. Vastly improved user experience? Check.

And of course, if either needs more information before deciding, they could use the Click to Call feature enabled by the WAS V7 Feature Pack for CEA and enter into a joint session with one of your customer service representatives. I described this scenario before.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here. Also, here's a good description of the widgets from Erik. Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

P.S.: Hilary and I planned our last trip sitting beside each other, with our individual laptops scouring Expedia for info. It was painful to keep track of the itinerary item that the other person was suggesting. So, while the scenario above describes two geographically separated users, I'm certain it'll apply to two users sitting beside each other on a couch! What that says for our society is a different story ;-)

Your applications need a dose of CEA - Contact Center Scenario

2009-05-03T13:58:00.000-04:00

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions. Well, what does that really mean? Let's start with a common scenario.

While searching for a life insurance policy online a user might want to call a customer service representative (CSR) about discounts since her mortgage is held by the bank. More often than naught, the CSR wants to point the user to more information on the bank's website. But here's the dilemma. The user and CSR are involved in a multi-modal interaction, but there's no synchronization between the two modes of communication. If the CSR wants to direct the user to a specific page on the site, he must tell the user "okay, go to the homepage, on the left navigation bar, click Other Offers and then scroll half way down the page, look for a link that says...." Agreed, that's an ugly interaction.

When the user decides to purchase life insurance, the interaction is no prettier. While the user and CSR are speaking on the phone and both have browser windows open, there is no linkage between the two modes of communication. The user still has to speak certain information which the CSR must transcribe into the application form. There's no visual way for the user to verify that the CSR has transcribed the spoken information properly. Try saying "Savio Rodrigues" and the person on the other end of the phone not transcribe "Fabio Rodriguez" or "Flavio Rodriguez" or "Sabio Rodriguez". Not cool.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario in which a user and CSR are involved in a multi-modal interaction prior to the user making a decision.

Click to Call
Let's consider the same scenario with a Click to Call Web Widget that you can embed in existing and new web applications.

Unlike third party hosted Click to Call offerings, the Click to Call feature in the WAS V7 Feature Pack for CEA Beta can be completely integrated into your application. No need to spawn another browser window or advertise your hosted provider's service. Integrated and consistent user experience? Check.

Next, our Web Widget is integrated with your telephony infrastructure (so far, Cisco & Nortel). Why pay a third party Click to Call hosted provider per minute fees for calls when you can leverage your existing telephony infrastructure? Lower costs and driving higher utilization of existing resources? Check.

Finally, any information that you want to share between the user and the CSR through the Click to Call session, such as login information or account numbers, does not have to go through a third party. Increased privacy & security? Check.

Contact Center Cobrowsing
Okay, you added a Click to Call widget to your application, now what? Well, your customer enters her phone number and clicks on "Connect". The result is a shared session between the user and the CSR (through WebSphere Application Server). Oh, and there is no software for the user or CSR to install. Security and ease of use? Check.

With this shared session both the CSR and the user can take control and direct what is shown on the other person's browser window. Both can highlight elements on the page for the other person to see. No more having to say "scroll half way down the page and look for the link to the right of the picture of a monkey". Improved user experience? Check.

Two Way Forms
Next up, the dreaded filling out of forms over the phone. But have no fear. Since you have a shared session between the user and CSR, there's no reason that the form can't be displayed to both parties. But why stop there? The Two Way Forms feature of the WAS V7 Feature Pack for CEA Beta lets both parties enter data into various elements of the form. You can even restrict the data shown in a form field between the CSR and user. For example, the user could type in and see their full credit card or social security number, while the CSR would only see the last 3 digits. The user can even click to confirm that individual form field data was transcribed correctly by the CSR. Fewer frustrated users? Check.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here. Also, here's a good description of the widgets from Erik. Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

Your applications need a dose of CEA

2009-05-03T13:16:00.000-04:00

As Erik posted on Friday, the IBM WebSphere Application Server V7.0 Feature Pack for Communications Enabled Applications Beta (WAS V7 Feature Pack for CEA Beta) is now live.

Why should developers care?

Skills Reuse, Improved User Experiences & Lower Costs:
Well, with your existing Java skills, the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences that improve the effectiveness of multi-modal online interactions and reduce costs. The WAS V7 Feature Pack for CEA Beta targets scenarios where users are interacting with each other through multiple modes of communications.

We've all been on a website, or for that matter, any web-based application, trying to find the right information before making a (purchase) decision. Often, multiple modes of communications (i.e. phone & website; instant messaging & website, etc.) are needed to obtain the information and make the decision.

Over the next two posts (here & here) I'll discuss two key scenarios where the WAS V7 Feature Pack for CEA Beta shines. Saddle up...

Widgets in the CEA Feature Pack

2009-05-01T13:50:00.000-04:00

Here is a quick rundown of some of the Web 2.0 widgets in our CEA Feature Pack:

Click to call- the ability to send a message into our REST service for it to make a phone call between two parties. This widget needs two phone numbers, one for the callee and one for the caller. The caller can be specified by the user of the widget and the callee can be embedded. The widget could also be easily extended to pull the caller information from another source.

Call Notifications - the ability communicate with our REST service to monitor a phone for caller ID type information. This widget needs the phone number to monitor, which could have been entered or pushed through an extension to the javascript.

Collaboration Dialog - this is a modal window which controls the sharing of information between two peers. There are some basic send and receive event semantics around this widget that allow extensions to send and receive various pieces of data.

Contact Center Cobrowsing - when a caller enters through our click to call widget and the callee enters through the call notification widget, the two users are able to launch a collaboration dialog that has the ability to have a controlled browsing session between the two peer users. This is described and demonstrated in detail in the video above.

Peer to Peer cobrowsing - has the ability to create a link which allows two users to enter a cobrowsing session without being involved with the telephony widgets. One user creates the link and sends it to the other via some method such as instant messaging or email. Since this link is created via a REST service, there could be some intelligence in a site which includes this sort of interaction without the widgets involved. Once the link is entered on the peer user's side, the two users can enter a collaborative cobrowsing session.

Two Way Forms - allows you to take a dojo dijit style form and augment it to have a writer and reader side on various fields. This is handy when one side must review the correctness of the data the other side is entering. The video above shows this flow even more.

IBM Impact 2009 Sessions

2009-05-01T13:30:00.000-04:00

We have multiple sessions at IBM Impact 2009 to talk more about the features in the feature pack. Below are some of the session numbers and their abstracts that you attend to learn more:

Monday, May 4, 2009
Session #1697 Revolutionizing Web-Enabled User Communications

This session details how Communications Enabled Applications (CEA) can improve Web application user experience for customers, partners and employees. It also discusses the revolutionary capabilities surrounding CEA that will be introduced in a Feature Pack for IBM WebSphere® Application Server Version 7.0. These new capabilities, and an innovative programming model, will enable developers to create applications exploiting dynamic Web-enabled communications while leveraging their existing skills. This session will cover the Web and RESTful services-based APIs and widgets that make up this exciting new programming model. It will cover how to use these capabilities to create voice and data sessions between users, and some of the innovative user experience benefits possible.

Tuesday, May 5, 2009
Sessions #2219 Adding Interactive Communications to a IBM WebSphere® Commerce Deployment

IBM WebSphere® Commerce can be enhanced by utilizing the Communications Enabled Applications functions that will be introduced in a Feature Pack for IBM WebSphere Application Server Version 7.0. These new capabilities will enable the users of your online store to interact with one another and your representatives in a unique and innovative way. Learn more about these new features and how to integrate them into your IBM WebSphere Commerce store to provide your customers with a new and improved shopping experience.

Wednesday, May 6, 2009
Session #1694: Lower Costs, Improve Satisfaction with Communications-Enabled Applications

Communications-Enabled Business Processes (CEBP) addresses your quest to do more with less in a SOA environment. Learn how Communications-Enabled Applications (CEA), a key aspect of CEBP, can help lower costs while improving customer, partner and employee satisfaction. Learn about the revolutionary capabilities surrounding CEA that will be introduced in a Feature Pack for IBM WebSphere® Application Server Version 7.0. These new capabilities, and an innovative programming model, will enable your developers to build multi-modal Web-based applications without having to become experts in communications technologies or specifications. Learn how your developers can leverage their existing skills to build innovative CEA that significantly improve user experience and revolutionize the ways that users interact with one another.

For all of our Inner Circle participants, we also have a session on Thursday entitles "Introducing the new Communications Enabled Applications programming model and Futures." That is session #3147.

I hope to meet you there!

Communications Enabled Applications on WebSphere

2009-05-01T12:41:00.000-04:00

Great news! The IBM WebSphere Application Server V7.0 Feature Pack for Communications Enabled Applications Open Beta has begun. That means we can finally start talking about the many exciting features in the beta.

First, I thought it would be useful to define what a Communications Enabled Applications are. As defined by Wikipedia, Communications Enabled Applications are:

A communications enabled application (CEA) is a set of information technology (IT) components and communication technology components that are integrated using a particular service-oriented architecture (SOA) to increase the productivity of an organization and/or improve the quality of users' experiences.

Communication enablement adds real-time networking functionality to an IT application. Providing communications capability to an IT application:
removes the human latency which exists when (i) making sense of information from many different sources, (ii) orchestrating suitable responses to events, and (iii) keeping track of actions carried out when responding to information received;
enables users to be part of the creative flow of content and processes.

What distinguishes a CEA from other software applications is its intrinsic reliance upon communications technologies to accomplish its objectives. A CEA depends on real-time networking capabilities together with such network oriented functions as location, presence, proximity, and identity.

Another distinguishing characteristic of a CEA is the implicit assumption that network services will be available as callable services within the SOA frameworks from which the CEA is constructed. To provide callable services, the network services which are available today must be made virtual and component-like.

CEAs apply to business processes as well as instances where no obvious business process which requires improvement exists (e.g., games, entertainment video). CEAs that apply to business processes are referred to as communications enabled business processes or communications enabled business solutions.

This feature pack has a lot of exciting capabilities including:

Web services & REST services-based APIs that
- build on existing Java skills for simplified creation of, and access to, communications sessions
- enable a richer user experience for two parties inputting and reviewing data, and while browsing web content
Widgets such as Click to Call, Contact Center Cobrowsing, Peer to Peer Cobrowsing and Two-way Synchronized Forms
Unit test environment to prototype and test communications enabled applications without the need to access corporate Telephony network
Sample reference application to speed learning
Access to standards-based Telephony infrastructure
Support for the latest SIP Servlet 1.1 standard (JSR 289)
Asynchronous Invocation API for accessing remote SIP sessions
Telephony interoperability testing with Cisco Unified Communications Manager and Nortel Communications Server 1000 in conjunction with Cisco & Nortel respectively

Stay tuned over the next couple weeks and months as we will be talking a lot more about our IBM WebSphere Application Server V7.0 Feature Pack for Communications Enabled Applications.