Making Use Of Communications Services To Collaborate

Work Completed By: Richard Scannell



The concept of service orientation has the potential to cross the boundaries between applications architecture and what is traditionally considered the domain of physical infrastructure. Using a web-based service can potentially negate the need to own and support the hardware and software that would have carried out the same role.

One area where the cloud model is mature is that of personal communication, e-mail is the most heavily used cloud service – and other communications services have followed.

Set up and demonstrate a user experience that provides a variety of methods of communicating/collaborating with others, using only web based services to do so. In setting this up consider what benefits can be accrued in working this way over the traditional model for providing such services within the organisation. Also discuss the problems or risks that are inherent in the web/cloud based approach.



Initially I looked into what technologies might help us with meetings. Finding suitable meeting spaces is a constant area of difficulties for us. The first part of this was to look into Google mail video conferencing. This involves a download (which failed to take), but appears to be restricted to a two way communication.

I implemented a "GotoMeeting" session with Chris J. This web based product allowed me to download a client . I was then able to invite chris to a meeting, which shared my desk top & let him take a control. Audio options included teleophone & microphone. The product is provided by Citrix : There was also an electronic 'chat' option but no video conference mode….

I also created a cisco webex conference. This had video, but forces you to alternate between the meeting & any desktop you may wish to share.

The second area I looked into was SMS.
The SKYPE API allows you to do this, but requires a client download to do this. This raises issues, particlarly if every user needs to download a client install. ( Impact on mobile working, firewall configuration to allow downloads, browser or other configurations which prevent popups & downloads), which could increase the number of support calls to the service desk. is an entirely web-based solution. I created an account.They texted me my password back in a moment or 2, & within 5 minutes I had created my own SMS entirely within a URL.<<myuserid>>&password=<<mypassword>>&dest=<<MyMobilePhone>>&msg=TestMsg+from+REDSMS

This example was entirely as an HTTP Get, although it can also be done as an HTTP POST, which is their recommended method(No source code is provided for this though). They provide an SSL service through a different URL( Interestingly this shares authentication & account details with redsms. It would be best to put any calls to these URLS within our own wrapper. This will let us to perform our own validation & give u the flexibility to change SMS provider, by just changing the call in one place
This call<<myuserid>>&password=<<mypassword» allows you to query your balance & return an OK status, & the number of texts that you areable to send. This in turn means that we can programmatically test that credit exists for a given batch, before an attempt is made to use it.

The 3rd area was email.
I looked into who had developed a .net interface for linking through to the Gmail API. Unfortunately the latest post for the version control list for this was in 2005 which states that the API is broken due "due to Gmail's protocol change". Another post reports that the "SourceForge project for this API has been created", although it is not clear as to whether this resolves any issues with the protocol change. This site demonstrates some .net code for controlling the Gmail API, & therefore shows that it is possible to do this. However, it also shows that underlying changes to the GMAIL system can break attempts to use it.

This is backed up by the report @ which states that a subsequent release of GMAIL in 2007 also broke many implementations of an earlier API.

Yahoo also offer a web service API, to build email applications. Looking closer to home, Domino could also be used as the core of a web service to provide mail services to external applications.

The 4th area was instant messaging
A good starting point for this is Meebo. This a really social networking site, in that it links people who are using different instant messaging services. Its basic interface lets you record your logins for msn , yahoo , aim , windows live messenger, facebook, , google talk, web msn, myspace & a variety of others, & then loginto them when you authenticate to Meebo. There is an API, which can be invoked through JavaScript Many sites are using inserting Meebo chat widgets into their webistes. This would give us the option to offer a real time support facility to people who are using interactive applications, but who are not in a postion to use the telephone.

In one of my earlier documents on media monitoring I looked into Yammer. The main difference between this product & others is that it is more business focused & requires people to have the same business email domain( eg before they can chat. Yammer's API ( currently in a beta stage. Security is handled by integration with OAth ( This is a tool which can integreate with OpenId & which allows the user to grant access to private resources on the Service Provider site (IE where you have actually authenticated with your Open ID) to another site, where they actually want to do things (called the Consumer)
While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all (or its secret parts). There is a security advisory about OAth. Yammer appear to have been responsive to this problem


It has found several examples, where web based technologies are being used to aid communications. This can either be between groups of WCC employees o between the the public & WCC.

Some of the tools such as as gotomeeting or webex would be visibily not WCC products. These are used to by businesses to host webinars, discussions & meetings using a richer environment than a simple telephone call. One are where there are issues, is with face to face contact. Some of the products offer video conferencing builtin, & others don't citing bandwidth concerns.

In terms of typed communications, there are a variety of tools which offer email, SMS & live chat services. These come with an API, & so can be imbedded into genuine WCC branded applications. One area of concern though, is who such messages would appear to come from. An email visibly from a domain will have will have more of an official feel than one from hotmail (IE ku.vog.erihskciwraW|sggolBeoJ#ku.vog.erihskciwraW|sggolBeoJ vs. moc.liamtoH|erihskciwraW.sggolbeoJ#moc.liamtoH|erihskciwraW.sggolbeoJ)


Redsms may provide a set of tools to replace our current SMS engine. Meebo can be invoked using Javascript, which is a standard web language. Therefore it should be capable of being imbedded into Domino, Moss or .net applications.
Electronic meetings from the desktop are also feasible.


If we were to use APIs for sending emails, then this would have implications for 'WCC' as a brand. Currently emails from "@Warwickshire.Gov.UK do have a certain provenance. We would not want emails to appear to come from yahoo or hotmail, as these appear to be from anyone & may be treated as SPAM or fake by the recipients. Similarly we don't want to use an API where "@Warwickshire.Gov.UK" could be inserted in the "from" field, as this would allow malicious individuals to fake emails from the council.

Websites such as webex or gotomeeting extend the scope of flexible working so that meetings can be conducted remotely. The icing on the cake would be if bandwidth were to allow video conferencing on demand as well. This would help the drive towards hotdesking. We would need to purchase more webcams & microphones or headsets to support this approach. Additionally Office design may need to account for increased noise levels as meetings are conducted from the desk ( extended phone calls, use of speakers etc…..)

In terms of systems design, the use of external resources does mean that it is advisable to develop WCC 'wrappers' for them, to act as web services, & entry points for WCC applications. So, for example, 10 or 20 applications which needed to send an SMS, would all invoke the same WCC SMS service & pass to it the parameters that were needed, & would consume(if needed) a return code from it. This WCC SMS service, would contain all the code needed to initialise & invoke the external service. If we changed service provider, or the service provider changed their API, then it would be just WCC SMS service itself that would need its code tweaking & not the 10 -20 applications which are sending the SMSs: they would still contain the same code to invoke the WCC service wrapper. This process of abstracting the call to an external service also reduces the number of elements that need to be tested when new applications are written or existing ones upgraded & opens the scope the use of automated test harnessess. These harnesses could be used for load testing ( which we aer not able to do at the moment, to test production systems against predetermined expected results & to push component testing 'out of hours'.


Issues surrounding web-based communications

1) Availability of Service.
Lotus Notes keeps our internal email communications within 1 internal domain, which sits in a pair of clustered servers. These are linked so that if one falls over, then the other is instantly available. There is no need for a Lotus Notes email ever to leave this cosy secure environment. Emails on the web can go through dozens of extra servers. Routing of email on the web involves alot more connections & (virtual) boxes. Therefore the scope for something to go wrong is much bigger. The Guardian website observes the following on the feb 2009 problems experience by google gmail:
There's not a peep about the problems on the Official Google Gmail blog, but then that is run from the US. The communications team in London were unable to send out statements on what went wrong… because their email was down.
It is inevitable that this will happen from time to time. What it does prove is that the more data we entrust to the cloud, the more important it is that we have reliable backups in place.
A similar crisis occurred when Amazon Web Services went down almost exactly a year ago; thousands of web-based businesses rely on Amazon for their storage services and after two hours of downtime, users were observing that cloud computing can't become mainstream, certainly for businesses, until it becomes almost infallible.
Within minutes of the Gmail downtime unfolding, I was sent a very pertinent message on Twitter speculating on the cost of the problem:

"Let's count the cost: 25m users, 33% affected; average of $50 per hour lost productivity = $415m per hour economic cost…"
• Update: Two hours later, we're back up. I was asked to do a captcha as my request "looks similar to automated requests from a computer virus of spyware application" - which could well be a clue to the culprit. If someone out there did manage to hack the mighty Google, they will be feeling very chuffed with themselves, regardless of how much disruption they have caused. Now back to work

2) Lost mail & other problems. Another side effect of 1) is that we are currently able to logically differentiate between internal WCC » WCC mail & any emails involving the outside world. This vastly simplifies firewall & other virus / security settings - simply put "" can reasonably be trusted, other domains need to be virus checked, or scanned for other malware much more thoroughly. Routing all of our internal mail via the web breaks this architecture, & means that WCC internal emails may be more susceptible to hacking. The routing of emails via external servers could also lead to an increase in lost mail, if external server A doesnt accept messages from external server B, if external server B has been used by nasty spam person C in the past… This may result in our emails getting rejected along with the spam.

3) Security.. Hosting our own mailservers means that WCC staff are the only ones with any kind of admin role. Externally hosted servers cannot guarantee the same level of security,by their very nature because we have no control or influence over who can operate as an administrator, or where the servers are physically located. Additionally the higher profile, of services such as Gmail will serve to make them a target for hacking attempts

4) Bandwidth.

Video conferencing between many different locations would impact heavily on performance.

5) Web based delays - Conversations over the web happen with a delay of 1 -2 seconds. This mean that any conversation involving a mixture of real time comunication ( IE people in the same office or using a tradtional telephone & web based ( EG Skype) telecoms wouldbe quite difficult.

6) Support
We could either be faced with support hour not operating during UK office hours if we were to use a US or an Asia based support service, or 'Chinese Whispers' if a support problem is passed from team to team, if the company offers 'follow the sun' support service. Additionally the fact that Gmail is a web based product, means that it will be required to work with a variety of web clients. Google support lists a variety of issues that impact on some browser & not others . This means that support resources are diluted between IE, Firefox, Opera, Safari issues. It also means that the environment is not as readily tweakable as it would be in a dedicated client such as Lotus Notes or Outlook / Exchange

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License