There's a new firestorm brewing in web services architectures. Cloud services are being talked up as a fundamental shift in web architecture that promises to move us from interconnected silos to a collaborative network of services whose sum is greater than its parts. The problem is that the protocols powering current cloud services; SOAP and a few other assorted HTTP-based protocols are all one way information exchanges. Therefore cloud services aren't real-time, won't scale, and often can't clear the firewall. So, it's time we blow up those barriers and come to Jesus about the protocol that will fuel the SaaS models of tomorrow--that solution is XMPP (also called Jabber) . Never heard of it? In just a couple of years Google, Apple, AOL, IBM, Livejournal and Jive have all jumped on board. Sounds good, right? So, what's the hold up? Why aren't we building out cloud services with XMPP now? And, if people are already providing cloud services without XMPP, what's the motivation to switch? The rest of this post will shed some light on the current landscape and provide some answers to those questions.

Polling isn't working anymore

Since the beginning of the Internet, if you wanted to sync services between two servers the most common solution was to have the client ping the host at regular intervals, which his known as polling. Polling is how most of us check our email. We ping our email server every few minutes to see if we got new mail. It's also how nearly all web services APIs work.

Take, for example, Twitter. High Scalability recently covered the load stats on Twitter reporting that they average 200-300 connections per second with spikes that climb to 800 connections per second. Their MySQL server handles 2,400 requests per second! Recently, the Macworld keynote became the most recent culprit for causing Twitter to cut off its API, which has 10x the load of their website. While Twitter is not a cloud service, nor the largest demand service on the internet (with a paltry 350,000ish users, which pales in comparison to a MySpace or Yahoo!), they do illustrate the kind of frustration a user experiences with polling based services. And, that's just Twitter! Imagine the impact on overall Internet traffic congestion polling creates worldwide.

Interestingly, the recent Twitter outage lead some influencers, like Dave Winer,  to suggest that Twitter move to XMPP which we've already begun experimenting with   

Some companies are trying to address the polling problem with existing protocols. I think that move is largely motivated by a significant investment in legacy systems that makes moving to another protocol difficult. Salesforce is a perfect example of a company attempting to address the polling problem with creative applications of the old one way protocols.

The latest version of Salesforce will send notifications back to your own webservice to avoid polling. But, that's a pain to setup for developers. Worse, its very difficult to wire up reverse webservices calls through a corporate firewall.

The hold up

XMPP's largest hurdle is that its not HTTP, and common wisdom states everything new that's built must be web-based. That means we won't see a widespread application of XMPP in cloud services until a few more brave pioneers clear the path for the rest of us.

I've been heavily involved in the XMPP world as a developer of Smack (client library) and Openfire (server) and have also helped craft the standard as a member of the XMPP Standards Foundation. XMPP was invented for instant messaging and presence, and is the dominant open protocol in that space. Instant messaging? Yep, it turns out that all of the problems that had to be solved for instant messaging make the protocol perfect for cloud computing:

• It allows for easy two-way communication, so bye bye polling. It even has rich pub-sub functionality built-in.

• It's XML-based and easily extensible, perfect for both new instant messaging features and custom cloud services.

• It's efficient and proven to scale to millions of concurrent users on a single service (such as Google's GTalk). It also has a built-in worldwide federation model.

I'm not the only one to notice that XMPP is a great fit for cloud computing. Tivo is switching to XMPP as a more efficient alternative to their old architecture:

<div class="jive-quote">Today each TiVo polls TiVo’s severs roughly every 15 minutes to check for new scheduled recordings, TiVoCast downloads, Unbox downloads, etc. That’s highly inefficient - nearly all of those polling calls are for nothing. There is nothing waiting to be done. And it introduces a lag when you want to start a download - up to 15 minutes. And it doesn’t scale well as TiVo’s user base keeps growing.

So what’s changed? The polling system is gone. TiVo is using XMPP now instead. (...) Yep, TiVo is basically using instant messaging for real- time communication. Now when the TiVo server has a new recording to schedule, it will IM the TiVo to tell it. Or if there is a download to pull, it will IM the TiVo to tell it to do so. This is a much more efficient system and it eliminates latency. It is really a clever idea.

</div>

Fixing the polling and scaling problems with XMPP as Tivo has done is compelling, but the built-in presence functionality also offers tantalizing possibilities. Presence includes basic availability information, but is extensible and can also include things like geo-location. Imagine cloud services taking different actions based on where the client is connecting from. 

More people, us included, will make the shift to XMPP, which will provide the missing evidence to create momentum toward a tipping point. In fact, I'm happy to announce that Clearspace 2.0 will include a feature that's powered by an XMPP-based cloud service. We'll be publishing a series of blog entries in the near future to discuss how we built it.

Resources for XMPP cloud service developers

There are a few places you can turn for help building cloud services around XMPP. Here is a list of a few:

• XMPP Standards Foundation -- where the standard gets defined

• Ignite Realtime -- Jive Software's Open Source XMPP projects

• Jabber Website -- lists XMPP servers, libraries and clients

We wanted to remind everyone that you only have two weeks left to enter our Clearspace plugin contest and win cash, iPhone, t-shirts, free licenses and more!

All you have to do is submit an awesome plugin (fine print) for Clearspace by October 25th.

What can you win?

• iPhone

• Cash prizes up to $5000

• Free 25 user license of Clearspace

• Jivespace T-shirt

You can learn more about the judging / submission process and some additional prizes on Jivespace.

I see Dave's point. He's worried we're going to burn bridges. Not that it's a heated debate. It's not. Dave and I just thought it would be good to voice our perspectives and get feedback. Regardless, we strongly believe in how Clearspace stands up to other choices.

My idea is to have a place on our website that compares us to other applications and then allows for public comments. If people have other information or opinions they could just post them right under the matrix. Everyday, we get the "how do you compare" question. I bet your company does, too. If you're like us, there aren't any really good places to go to get that sort of information, short of consumer reports. Is the fact that no one else puts up comparison charts reason enough to not do it? What would you think of a company that did have that information public?

I do realize that it will be hard to capture everything accurately and stay on top of it, I know we'd make mistakes. But I think it's worth the risk to give it a shot. Perhaps the other idea is to just buy all those applications and host them so that people can test drive them all in one place.  I mean, Saturn is doing it. You can go to their lot and test drive their competitor's cars, too.

I'd rather focus on providing customers with the information they want then to worry about potential relationship conflicts. No doubt, as much as the matrix wouldn't be intended as a commentary on other people's products it would be perceived that way. Not to mention how objective could we be, right?

My opinion is that we shouldn't worry about upsetting potential partners or other friendly companies. These are risks worth taking. We will make some people upset and some people happy.

What do you think?

Just a quick note that I'll be doing one of the seven Launch Pad Presentations next Tuesday as part of the ETel Conference. It's a pretty significant shift to add VoIP to Wildfire (not to mention all the other major features) and the ETel conference is the perfect venue.

If you'll be at the conference, please stop by the booth or grab me. I'll be with Greg Unrein, the product manager for all of our RTC applications.

We just launched a new home for jivesoftware.org: igniterealtime.org. The new site has an improved UI, community blog, and better content. Why the change?

• Having jivesoftware.org along with jivesoftware.com was simply confusing. The new site helps us articulate the Open Source business model more clearly and is a better home for the community.

• We've been growing a lot lately -- from feature set, to community involvement, to download numbers. Both Wildfire and Spark are moving beyond the "awkward teenager" phase and ignite realtime helps us spread that message.

As always, launching a new site is way more work than one would expect and many people helped out. However, I'd like to specifically thank Contegix. They host all Jive websites and generously sponsor hosting of igniterealtime.org. Their professionalism and expert help were appreciated at 1:00 am last night as we put on the finishing site touches.

Please check out the site and let us know what you think!

We've been hard at work on one of the most requested features for Wildfire, HTTP Binding. This feature will allow clients to connect and communicate with Wildfire over HTTP, including AJAX web clients. There are several popular clients out there already utilizing the HTTP binding protocol, such as JWChat. All of these clients will benefit as they'll be able to connect to Wildfire without any extra configuration or external components as were needed before.

Performance

One of the things we've focused on in developing this feature is performance. With AJAX growing ever more popular, HTTP performance has become a huge concern for server administrators. Traditionally, HTTP servers are optimized for large numbers of short-lived requests (people clicking from web page to web page). AJAX breaks that model since web connections are held open for long periods of time. This problem directly applies to HTTP Binding since virtually all web IM client implementations use AJAX. To help improve the performance of the HTTP Binding component, we've upgraded our embedded Jetty server to its latest version, 6.0, which includes support for Java NIO ("New I/O") and continuations.

One of the main benefits of NIO is that you can have a small pool of threads handling I/O operations instead of one thread per a socket, which allows much greater scalability for large numbers of client connections. Jetty 6 also includes a continuations feature which further optimizes thread handling in the server. The standard Ajax programming model is to connect to the server and then wait until data is ready (such as a new IM message). Continuations allow the server to free up internal resources while the client is waiting. These two optimizations should allow Wildfire to handle a huge number of HTTP clients (significantly more than any other HTTP Binding implementation). We're just starting performance testing now, so stay tuned for actual numbers. We also added HTTP Binding support to connection managers, which provides furthers performance and scalability options.

Ease of Use

Like any other Wildfire feature we wanted HTTP Binding to be easy to use. The configuration of the feature is automatic -- no patching and no external components are necessary to get it up and running. The server administrator can configure the ports that is runs on and also various other settings such as how often clients can forward requests to Wildfire and how long to wait before Wildfire will consider a session inactive and invalidate it.

What's Next

The HTTP Binding feature is only one part of the equation, as it just provides the building blocks for XMPP web clients. But we're also working on direct web client support and will have more to announce soon, along with a timeframe for when HTTP Binding will make it into an official Wildfire release.

...in which we learn what's working with the commercial edition and make some changes. See my first post on our Open Source Philosophy for background.

I want to keep sharing how the Wildfireproject is doing from a financial perspective, and what we're doing to tweak the model so you can understand why we make decisions with the product. Unlike a lot of the larger company-sponsored open source projects, we're a bootstrapped company, so profitability is the only path to success. Plus, EIM is a very small market compared to a lot of other OSS applications (BI, CRM, etc.), so careful execution of the business model is critical.

This last quarter was an interesting one for Wildfire, most notably with the launch of Enterprise Edition in July. With the number of downloads of the OSS edition, we had expected to get a fair number of users interested in converting to the commercial edition -- this would be our first real metric in figuring out the symbiotic relationship between the two applications. We didn't expect the phone to be ringing off the hook, but (perhaps naively) expected a 1% rate of download (i.e. 1% of OSS downloaders would check out Enterprise) and a reasonable conversion process (after all, just the support and indemnity alone makes it worthwhile to a lot of companies).

The actual figure, unfortunately, was closer to .0001%. D'oh!

What happened and what have we learned?

1. Features: Since it was the first launch, the commercial feature set was not unique enough to convince a large number of people to try it out. EIM is an emerging market, and many people seek a basic solution. Just adding additional features like reporting and archiving is important, but it's the big value-add features (like Fastpath) that truly give the Enterprise Edition legs.

2. Process: The process for learning about and downloading the commercial application has been a bit cumbersome. People didn't always know that it could be easily installed as a plugin, and it was difficult for people to learn about it and why it could be really valuable to them.

3. Pricing: The pricing is very appealing to mid and large-sized organizations, but our smaller customers have told us it's a bit high for them.

4. Name: Our community have told us that they expect a product named "Enterprise" to have features that are only valuable to Fortune 1000 companies. But we had designed the product to be just as valuable to small and mid-sized organizations.

What did we do?

1. Name: We're keeping it as-is for now, but may change it in the near future after some more conversations with customers. Please feel free to share ideas.

2. Process: We have added a tab called "Enterprise" to the latest version. This makes it easy for people to learn about the features and try it out. We also want to be able to show people the usefulness of features in the context of tasks (coming later). The goal is to make it very clear what value people get by upgrading. Again, feedback is welcome.

3. Features: This is always improving, but we're working hard to put some great new stuff into Enterprise (and the OSS edition for that matter), but ultimately it needs to transform into a larger value-add business solution to be successful -- not just bells and whistles.

4. Pricing: We'll be releasing new pricing soon to make it easier for small groups to get up and running.

So, we're constantly trying to tweak the model for growth. It's a difficult process, but the OSS community (ours and other companies doing the same thing) are great at sharing what works. We'll keep you posted. In the meantime, please keep the ideas coming.