Return to Jive Software

Up to Blog Posts in Jive Talks
Previous Next

Jive Talks

Currently Being Moderated
Matt Tucker
45

  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:

 

Attachments:
53,895 Views Tags: xmpp, planet-jabber, salesforce, soap, cloud_services, rest, twitter, tivo


Comments (45)
Add a comment Leave a comment on this blog post.
Jan 24, 2008 3:56 PM Dawn Foster Dawn Foster    says:

If anyone is interested, you can also Digg this post here: http://digg.com/software/XMPP_a_ka_Jabber_is_the_future_for_cloud_services
Jan 24, 2008 4:12 PM Michael Sigler Michael Sigler    says in response to Dawn Foster:

Ok Matt. You can't post that and not geek out over the new logo. I've corrected that for you.

 

http://siglerdesign.com/index.php/site/article/xmpp_jabbers_new_logo/
Jan 24, 2008 5:51 PM Guest Jungle  says:

Very correct analysis. I'm sad I didn't read it 3 year ago...

 

I spend two years building the backend of a complex infrastructure of 200 servers, all very dependent and communicating with each other. We originally used Jabber to communicate with our 10 million clients deployed world-wide, and it was straight forward to use Jabber to communicate between our servers. However, maintaining Jabber connections with 10M clients was a pain, and we decided to replace Jabber with SOAP. My mistake was to also replace inter-server Jabber communications with SOAP. Indeed, SOAP communication proved unreliable, not scalable and inflexible, due to complex firewall setup and SOAP's inherent one-way communication style.

 

BTW: Great work on Smack, its a great library.
Jan 24, 2008 5:51 PM Guest Dave Hoff  says in response to Michael Sigler:

That new logo certainly does rock. Very important for adoption in this web2 world we live in.

 

Excellent post Matt. Things are heating up.
Jan 24, 2008 5:51 PM Guest Marshall  says:

Fascinating stuff and really exciting to see a company serving such major customers going this kind of open route.  The speed and scaling possibilities are very interesting.
Jan 24, 2008 5:58 PM Guest Programmer  says:

Can you explain how this is fundamentally different from RPC's (besides server->client)?  I'm more interested what is happening, application/protocol-wise, on the client.
Jan 24, 2008 7:11 PM Guest Chule  says:

That's a great article. of course he completely glossed over the fact that XMPP finally has a logo!

http://www.spymac.com/details/?2331904
Jan 24, 2008 6:01 PM Matt Tucker Matt Tucker    says in response to Jungle:

Jungle: thanks for sharing your SOAP horror story. I think that you're right about XMPP being a good tool for enterprise integration projects in general. Any thoughts about switching back from SOAP, or too late for your project?

 

Also, seeing how REST has displaced SOAP for simple web services gives me hope. I love the Amazon stat: 85% of developers choose REST over SOAP (http://www.oreillynet.com/pub/wlg/3005).
Jan 24, 2008 6:03 PM Matt Tucker Matt Tucker    says in response to Chule:

Chule: I'm pretty psyched about the logo too! We (XMPP Standards Foundation) spent quite a bit of time working on it so now it's time to spread the word. I'd love to see it on the front page of dataportability.org, for example.

Jan 24, 2008 8:31 PM Guest Corin Royal Drummond  says:

Dude, you are so f-ing right about XMPP it's not funny.  I hope one day we look back at this article and laugh that people had to be convinced.  I remember when Jabber first started and explained that they were building a platform for real-time two-way communication and thought that this was where things need to go.  ??

 

I've been thinking about XMPP as part of a solution to the problem of data soverignty.  The question "Dude, where's my data?" is becoming more relevant in an era where our everything from our click streams to our blog posts are being data mined.  We're in an unprecedented era where we're having intimate conversations with trusted friends in an hugely public medium.  Basically shoveling some pretty sensitive data to the government, your stalker, your creditors, etc.  ??I don't see why Facebook has to control my social network.  That's pretty personal data.  My friend network shouldn't be used for marketing purposes.  As open source people, we need to solve that problem.  I propose we do what the Miro people did, and build our own solution out of open source parts.  ??

 

Why not have a desktop application that holds our Facebook profile, and applications, and acts as a server.  Using a combination of encrypted XMPP and bittorrent, our profile data and applications are shared with our friends in real time and in a distributed manner (a la bittorrent) to handle the bandwith issue.  So your social network browser app (using embedded mozilla gecko, flash, and VLC like Miro) is also a peer to peer server.  There is no Facebook central server farm, just a cloud of peers sharing encrypted data based on existing trust relationships (BKA friendship).  Or maybe there's a very limited central registry of sorts so that friends can find each other.  ??

 

That way our private information isn't an open free for all for any corporation, crime syndicate, or wayward government with access to a cracker team to use against us.  ??What say ye, Brothers?  ??

If you like this idea, let me know at username: corin domain: studiochango.com (parse that you spambot bitch).
Jan 24, 2008 9:25 PM Guest Jon G.  says in response to Matt Tucker:

How is SOAP not firewall friendly exactly?  That doesn't make any sense to me.

 

Don't get me wrong, love the post, but the bit about SOAP and other webservices not being firewall friendly is wrong.

 

PS. We use openfire for inter-component messaging at Massify.  Right now, we specifically use it as an event notification mechanism in our encoding farm.  When a video is done processing, it sends events to other components/servers to complete the entire process.
Jan 24, 2008 9:25 PM Guest Eric  says in response to Matt Tucker:

Compelling- but what about the sockets?  I work on a SOAP infrastructure that serves tens of millions of unique clients daily.  My segment serves just under a million users per day with a relatively lightweight (about 8 machines not including shared DB) infrastructure... and SOAP.

 

I can't imagine what would happen if suddenly all those users had stateful connections.

 

I'm not sure I even agree with the Tivo approach.  Maintaining a stateful connection, and then making a decision about what data to push to which users still has about the same amount of processing overhead.  The TV listings probably represent small changes at a time for large groups of users, so if they want to be more efficient they can setup a decentralized distribution network that offsets the load to some of those TIVO's wasting their cpu cycles all day long.  The logic for what data to get will still be on the client side, and more of the I/O moves to this idle network.

 

I'd love to see a better solution than maintaining all these sessions, but SOAP seems like a better fit for my environment right now.

 

My feeling is that gradually we will see different solutions make themselves apparent as IPV6 is fully adopted over the next 10 years or so - then the one-way problem of HTTP is gone.

(by the above, I really mean advocates like yourself pushing new solutions and making them available to people like me )

 

RFC 3920 was very useful and it seems like XMPP will adopt well to a two way stateless approach.  I'd be really interested to see more examples of applications in practice using it.

 

Of course I have used jabber implementations and love it :).  It seems very specific to IM but it is honestly one of the most feature complete, useful and robust OSS projects I've implemented.

 

Nice read.  Thanks!
Jan 24, 2008 10:09 PM Guest BRD  says in response to Eric:

I was thinking the same thing as Eric.  Does it become problematic to have that many concurrent connections all at once?  It seems to me that XMPP becomes most valuable when near real-time responsiveness is required but how often is that really case?  I'm specifically thinking about a notification system on the scale of something like Windows Update...
Jan 25, 2008 6:45 AM Guest Terence Pua  says:

Matt, thanks for the article (now I don't have to write about it   We are actually putting XMPP in the cloud for our own product called iTenna, which is perfect for bi-directional syncing on various devices (including the Web).

 

However, we are using JSON to pass data around.
Jan 25, 2008 3:06 AM Matt Tucker Matt Tucker    says in response to Jon G.:

Jon G. -- SOAP isn't firewall friendly when you need two-way communication. Let's use a phone line as an analogy:

 

  • With XMPP, the client dials the phone number of the server. The server picks up and then both parties stay on the line. The server and the client speak whenever they each need to.

  • With SOAP, the client dials the server's phone number and asks a question. When the question gets answered, both parties hang up. There's simply no way for the server to call the client back -- it simply has to wait until the client chooses to call again. A phone system where only one party is able to place calls is pretty dumb.

 

Cloud computing is full of these cases and that's when the firewall becomes a problem. Take a look at what you have to do with salesforce.com and SOAP as an example: http://blogs.neudesic.com/blogs/enterprise_integration/archive/2007/01/17/3451.aspx. Having to figure out how to tunnel those reverse web services calls through your corporate firewall is a definite pain in the ass.

 

Also, an interesting take from ReadWriteWeb on this whole discussion: http://www.readwriteweb.com/archives/xmpp_web.php
Jan 25, 2008 3:19 AM Matt Tucker Matt Tucker    says in response to Eric:

Eric: great comment, thanks for taking the time to post it! Maintaining an open socket for every client is indeed not free. A few points:

 

- I don't think XMPP means that SOAP goes away, just like REST didn't mean that SOAP went away. But, there are a class of problems where XMPP is a great fit.

 

- Use XMPP when bi-directionality is required. If your web service is just information look-up, then SOAP or REST is a great fit. Polling probably used to work fine for TIVO when the client was just asking for program updates. But now that you can program your TIVO remotely and do things like ask it to download a movie from Amazon's Unbox -- that's when XMPP becomes compelling.

 

- XMPP federation will eventually provide really interesting economies of scale when weaving cloud services together. Say I'm an XMPP client on jivesoftware.com and I want to interact with a cloud service on foobar.com. Rather than opening a socket to foobar.com directly, I let my server do the work for me (it will have one open socket for everyone that's connecting to the foobar server). It's a lot like how email servers work, although XMPP actually got federation right from a security and functionality perspective compared to SMTP.
Jan 25, 2008 6:45 AM Guest Nick Vidal  says:

Hi Matt,

 

Take a look at <a href="http://iss.im">ISS</a> (Instant Syndicating Standards). ISS is a set of open standards that enable people to discover and syndicate information within their social network. It blends the Web and XMPP in an elegant way.

 

Best regards,

Nick Vidal
Jan 25, 2008 8:19 AM Guest ?  says:

Fascinating stuff and really exciting to see a company serving such major customers going this kind of open route. The speed and scaling possibilities are very interesting.
Jan 25, 2008 8:19 AM Guest Erik  says in response to Programmer:

Programmer - Using XMPP for server integration can be RPC-like if that's what you need, but the number of options available to you are far greater than traditional RPC-style approaches. For one, you have information about the endpoint you want to contact via XMPP's presence information. If you're a client who wants to deliver a message to a remote service, you have a lot more information about weather that service is on-line before you even attempt deliver which allows you to build much more robust clients.

 

More importantly though, is that with XMPP you can avoid the limitations of point-to-point integrations with XMPP's Publish-Subscribe. With Pub-Sub, you send messages to a logical end-point but there may be one or 50 parties listening, the number is irrelevant. In a traditional RPC environment, the client must have an awareness of all downstream consumers of data and must publish its message to each endpoint. With Pub-Sub, interested parties come and go as they choose removing the burden of delivering the same message multiple times from the client.

 

On the client, most XMPP programming I've done is more event-driven than RPC-like. Typically, you publish a message and wait for a response asynchronously. If you don't get one, you try a different end point or replay the same message. In RPC you call your endpoint and block until that endpoint issues a response.
Jan 25, 2008 9:09 AM Guest Jake Morgan  says:

I started my career in 2000 working for Marimba implementing a software distribution product based on Java. During Marimba’s heyday there were two types of notifications: pull and push. Does anyone remember PointCast? It was a hot company that “pushed” (completely controlled by the content provider) various media content over the internet to consumer desktops. It ended up making the headlines for choking networks and eventually went by the wayside.  Unfortunately, Marimba’s product was lumped into the “push” space even though it used the “pull” (controlled by the endpoint) technique to check for updates (similar to today’s RSS feeds however Marimba’s communication used a proprietary protocol embedded within the http(s) protocol so it could securely traverse the Internet and firewalls).  Marimba continued on and eventually purchased by BMC Software in 2004.

 

Over the four years instant messaging became a popular business tool. It was an excellent medium to communicate with my colleagues around the globe, especially if there was an audible language barrier.  Around 2002 I was tasked to implement Marimba’s product in a datacenter which had various pockets of firewalls. The combination of the “pull” technique and the product’s use of http(s) was a perfect fit. However, one would lose the fine “on demand/push” control of the Marimba agent unless the firewalls were modified to allow in-bound connections which from a security standpoint is bad.

 

I had envisioned embedding a XMPP SDK within the Marimba agent so I could leverage all the excellent features that XMPP offered (firewall traversals, presence, groups, broadcast, etc).  The “server management” console could see and group my servers according to their function/service so that I could send a set of commands to the agents to perform various actions such as: do an inventory of the machine, update xyz application, run this script, obtain/cat this file, etc.  I even envisioned this to interact with other systems such as switches, load balancers, certificate servers, DNS servers, IP management systems, OS provisioning systems, etc. Each one of these “systems” would be plugged-in via XMPP giving datacenter operations a near real-time management system.

 

I didn’t get a chance to actually build the system of my dreams since I wasn’t being tasked to build but to implement.  At the time there was very few completed Jabber servers and no Jabber/XMPP SDKs such as Smack. However, Jive Software was in the planning stages of building Wildfire and Smack.

   

I certainly believe we’re close to having a world where we’ll be able to obtain instant feedback from various common systems and devices. I would for one would love to see all the clocks in my apartment stay in sync perhaps via XMPP. How about a nice message on my TV from my dishwasher letting me know it’s finished or one from my drier letting me know my clothes are dry.
Jan 25, 2008 2:10 PM Guest Slim Amamou  says:

there is also a plugin for firefox to make the transition smoother :

 

https://addons.mozilla.org/fr/firefox/addon/3632
Jan 25, 2008 2:24 PM Guest Cedric Veilleux  says:

Your post is spot on. XMPP is an excellent transport for some webservice applications. We discovered this 4 years ago when we started developing an online hotel booking service.

 

The main advantage is that you get presence notification at no additional cost, beside the fact that the protocol also support a wide range of features such as encryption, delivery notifications, routing, etc..

 

It does impose some overhead though. Accounts need to be created on the server for both consumers and services. Anonymous access is not really practicable. The need to establish a connection to the server is an unnecessary overhead for a short lived webservice call.

 

For our online booking needs though, it did wonders. The communication is fully handled via XMPP (using OpenFire as the server). The initial prototype for our software used a SOAP interface, but we changed that to an XMPP transport 4 years ago.

 

There is unfortunately a lack of libraries to ease the work of doing messaging over XMPP. There are a handful of XMPP client libraries available, but few ways to make webservices on top of them.  We ended up developing our own in-house RPC over XMPP library based on Smack and java serialization. We always thought of releasing our library as open-source but a few forum posts from us yielded not much interest. I am glad to see this subject coming up. If you are interested, drop me an e-mail.
Jan 25, 2008 5:56 PM Guest David HM Spector  says:

I guess I am missing something -- XMPP is a fully connected client server protocol, where clients establish a session with a server and subscribe to some collection of messages of interest.  Keeping tens of thousands of (in the case of Google Talk), or millions (in the case of TiVO subscribers) connections open on a server would seem to be to be just about as resource intensive as a polling model.

 

It would seem that the only obvious benefit is at some level the avoidance of flash-crowd situations since most users will already be connected..

 

What am I missing..?

 

regards,

  David
Jan 25, 2008 7:49 PM Guest Blaine Cook  says:

Great post, Matt!

 

The challenge for XMPP in general is to take the great technology and serve as a platform for compelling services. One of the missing pieces that other commenters have touched on is documentation and practical examples. To that end, Twitter is aggressively exposing our XMPP APIs --- they're a better experience for users than the poll-based architecture, on top of being less resource-intensive for us.

 

As I mentioned on Dave's blog, we (Twitter) have also started to open up our PubSub API; at the moment, it's on a case-by-case basis, and the API is fairly limited, but we're looking to enable a wide range of functionality over our XMPP endpoint.

 

I'm going to be giving a three hour workshop on building web services with XMPP at FoWA Miami, at the end of February. I'm planning on diving into some of the more obscure aspects of XMPP, including building tools using the component protocol, and building real-world services using PubSub (which is a bit of a complicated spec, and can be really hard to parse to the newcomer).
Jan 25, 2008 7:49 PM Guest Blaine Cook  says in response to David HM Spector:

David,

 

Google Talk has millions of subscribers, and modern event-based architectures are able to easily handle this many concurrent sessions; resource utilisation is actually much lower than the same number of clients doing polling. Of course, if the HTTP clients are only polling once or twice a day, then it's a moot point. In the case of Twitter, we see many clients polling once per minute or more.

 

The advantage for web services like Twitter is that we don't need to maintain those connections individually; the Twitter XMPP server just maintains a handful of s2s connections to GTalk, LiveJournal, etc., and can talk to all of the millions of users represented by those services. At the same time, Twitter can talk to your XMPP server that has just one user, so it scales up as well as down.

 

I hope that clarifies the relative benefits vis-a-vis HTTP somewhat?
Jan 25, 2008 10:42 PM Guest David HM Spector  says in response to Blaine Cook:

Blaine,

 

Yes, it does, thank you for taking the time to explain it!

 

regards,

  David
Jan 26, 2008 9:19 AM Guest Michael J  says in response to David HM Spector:

Great post.  I have what is (hopefully) a quick question.  I'm new to XMPP, so please bear with me.

 

Say that I'm building a cloud service and want to connect all cloud servers (and clients too) with XMPP.  How does one build a distributed network of XMPP servers?  So the terminology doesn't get confusing, from this point on I'll use the term "server" to strictly mean an XMPP server, and "client" to mean any other computer that is part of the cloud or is connecting to the cloud.

 

Blaine gave the example of how Twitter talks with GTalk.  For my cloud, would I assign 1 XMPP server to 'x' number of clients, and then connect all 'y' servers via an s2s connection?  Is this scenario supported by something like Openfire Server out-of-the-box?

 

Thanks,

Michael
Jan 26, 2008 9:19 AM Guest JD Conley  says:

Nice one Matt. Glad to see things moving beyond the traditional IM space. I wrote a while ago about what a bunch of our customers were doing outside of IM. This is good news for the internet...

 

http://jdconley.com/blog/archive/2006/09/16/soapbox-platform-possibilities.aspx
Jan 26, 2008 2:33 PM Guest LG  says:

Hi Matt,

 

I wonder why JMS/EMS is not mentioned here. It's already heavily used and I wonder why one should move to XMPP for non-public services. Take a look at the features on http://www.tibco.com/software/messaging/enterprise_messaging_service/default.jsp : "distributed and reliable ... load-balancing, routing and fault tolerant configurations ... over 50,000 messages per second ... 99.999% uptime ... fine-grained control over authentication and authorization permissions ... monitoring and management capabilities".

 

LG
Jan 27, 2008 8:27 PM Matt Tucker Matt Tucker    says in response to Blaine Cook:

Blaine -- very glad to hear that Twitter is taking a leadership position on using XMPP. Looks like you'll be at Foo next week as well. Looking forward to talking more about the issues then!
Jan 27, 2008 8:36 PM Matt Tucker Matt Tucker    says in response to Michael J:

Michael -- the key concept for s2s is domains. In that respect, it works just like email. So, you could run one Openfire server at example.com and that server would handle all the clients that connect to example.com directly as well as all server to server connections, such as from Google Talk. If you have a ton of traffic, you can use a cluster of servers to handle one domain using Openfire Enterprise.
Jan 27, 2008 8:38 PM Matt Tucker Matt Tucker    says in response to LG:

LG -- I think JMS is a fine solution for messaging inside the firewall. XMPP is better for public servers because:

 

  • It works with any programming language, not just Java.

 

  • Supports federation

 

  • Is already very widely used for instant messaging (making it a good platform).

 
Jan 28, 2008 3:22 PM Guest Andy Wang  says:

Matt,

 

Great post! I love the idea. Can the same concept be extended to SIP/SIMPLE? Or is there something inherent to XMPP that makes it a better protocol? Thanks!

 

Andy
Jan 28, 2008 3:15 PM Matt Tucker Matt Tucker    says in response to Andy Wang:

Andy -- I think SIP is a reasonable protocol for VOIP, especially because everyone already uses it. However, SIMPLE is pretty much a joke and nothing like what its name suggests. Both protocols are missing a lot of things that make XMPP work well for this use case:

 

  • SIP presence model is really complicated and not durable like XMPP (from what I remember, you have to keep sending out presence subscriptions all the time)

  • Many very handy features are missing from SIP/SIMPLE like file transfer and pubsub. Even things like buddy lists aren't very well standardized as I remember.

  • The SIP networking model is more complicated than XMPP. You can use a proxy, which most implementations do, but the default model has lots of the same firewall issues as SOAP (for 2 way communication).

  • There is no federation in SIP/SIMPLE.

  • Not extensible via simple XML the way XMPP is.

 

-Matt
Jan 29, 2008 7:19 AM Guest Stephan Schmidt  says in response to Matt Tucker:

"It works with any programming language, not just Java."

 

Java messaging implementations, e.g. ActiveMQ, work with other languages too,

 

http://activemq.apache.org/cross-language-clients.html

 

"Apart from the obvious Java support via JMS 1.1 we support the following language clients.

 

     

  • Ajax

     

  • C

     

  • C++

     

  • C# and .Net

     

  • Delphi and Delphi/FreePascal

     

  • Flash / ActionScript

     

  • JavaScript

     

  • Perl

     

  • PHP

     

  • Pike

     

  • Python

     

  • Ruby and Rails support via ActiveMessaging

     

  • Smalltalk

"

 

Peace

-stephan
Jan 29, 2008 3:08 PM Matt Tucker Matt Tucker    says in response to Stephan Schmidt:

Stephan -- thanks for posting the correction!

Jan 30, 2008 7:22 AM Guest Stephan Schmidt  says in response to Matt Tucker:

My pleasure

Feb 5, 2008 1:47 PM Guest Clarice  says:

I'm not sure why Tivo couldn't open a TCP connection on their own. It's really quite simple.

 

HTTP also has persistent connections that allow for two way conversations and works fine. Is that not good enough?

 

And how do you handle lossless data sync. If I have several thousand messages and I login do I get them on the next connection? If my connection dies do the server notice and know which ones I received so I get them on the next connection?

 

Does anyone think presence is a better mechanism than TCP already provides for know if it's OK to send data. That doesn't even make sense.

 

Not to rain on your parade. But the adulation seems a bit over done.
Feb 5, 2008 2:09 PM Matt Tucker Matt Tucker    says in response to Clarice:

Clarice --

 

  • HTTP servers are generally just not meant to scale to lots and lots of open connections (since that isn't the normal use case). Plus, HTTP isn't really meant for long-lived open connections the same way XMPP is. You could hack something together, but why bother?

  • TCP tells you when the socket is open, and that's great. Presence will do more -- it's a way to know what's going on at an application level.

 

Finally, everything is possible without using XMPP, but the point of the blog is that XMPP makes it super easy and all the tools are ready to be used. Why re-invent the wheel?

Feb 6, 2008 1:46 PM Guest courtney benson  says:

Great post!  Thanks for the input. Sounds like the perfect time for a start-up to outsmart companies like Saleforce using XMMP.  Your explanation has helped me understand that what's being hyped about cloud services needs some serious investigation. The fact that they aren't real-time, won't scale, and often can't clear the firewall is very un-compelling.
Feb 6, 2008 3:26 PM Guest Clarice  says in response to Matt Tucker:

HTTP servers are generally just not meant to scale to lots and lots of open connections

 

That's certainly changing with Comet and Linux support for efficient handling of large numbers of connections.

 

You could hack something together, but why bother?

 

It's not really a hack, you just keep alive and use the connection normally.

 

Presence will do more -- it's a way to know what's going on at an application level.

 

Oh very true. My reading of the use was for low level operations.

 

>Finally, everything is possible without using XMPP

 

On rereading my post it was more shrill than intended. But the sync question is the big one in my mind. I can't really imagine twitter needs help delivering simple messages in real-time. What gets complicated is when you gateway between SMS, etc and deal with persistence.
Feb 6, 2008 5:43 PM Matt Tucker Matt Tucker    says in response to Clarice:

But the sync question is the big one in my mind. I can't really imagine twitter needs help delivering simple messages

in real-time. What gets complicated is when you gateway between SMS, etc and deal with persistence.

 

Right -- I think XMPP is especially useful for federation of services (federation is also something not directly supported by HTTP) and for pubsub type problems. That's exactly how Twitter is experimenting with XMPP.
Feb 7, 2008 7:00 AM Guest prashanth  says:

This is quite a interesting concept. I am also looking at XMPP as a protocol for synchronizing the data distributed across multiple remote nodes. I find there are few features which JMS and XMPP have in common. But the presence part of XMPP makes a lot of difference. Whats your take on JMS versus XMPP part?

 

How efficient XMPP in transfering big chunk data between client and server? How it affects the performance and scalability aspect?
Mar 13, 2008 4:39 PM Guest kavitha  says in response to Cedric Veilleux:

Hi,

 

Can you please throw me more light on this? - Ways to make web services on top of XMPP libraries?

 

Many Thanks

Kavitha

 

There is unfortunately a lack of libraries to ease the work of doing messaging over XMPP. There are a handful of XMPP client libraries available, but few ways to make webservices on top of them. We ended up developing our own in-house RPC over XMPP library based on Smack and java serialization. We always thought of releasing our library as open-source but a few forum posts from us yielded not much interest. I am glad to see this subject coming up. If you are interested, drop me an e-mail.
May 4, 2009 1:02 AM Guest rk tumuluri  says in response to Cedric Veilleux:

Hello Cedric,

 

I am experimenting with some ideas using xmpp. I am most certainly looking for an "rpc" or "soap" like solution over xmpp. I am also using the "smack" library. So, if you can share your library it would be great. Do drop me a note.

 

Later ...

/rk
Learn more about Jive SBS
Subscribe to the Jive Talks RSS Feed

Popular Blog Posts

Jive Tweets

Follow Jive on Twitter

    We're also on: