From inmates to IM mates…

To put a closing section to the latest on IM misconception, I believe this piece to be particularly misleading for casual readers. After the information mashup here comes the statistics mashup. The recipe is simple. Just throw everything IM related in the cauldron, hum some incantation, and the definite truth immediately surface: “Google Talk fails to find an audience!” To be frank, I have no idea how many are using their IM service, as Google is rather secretive. I am not a Google aficionado, but something in the way the post come to this conclusion makes me feel uneasy. In the statistics:

• Legacy consumers IM providers users are cited as services
• Google Talk is cited as an application, and so is Trillian

In such conditions, I would have thought a more appropriate interpretation of the data to be “only 3.4 millions elected to use Google Talk client for IM”. Obviously less catchy than “fails to find an audience”…

Whatever method was used to come up with these figures in the first place, the derived conclusion is a bias on reality. The customers of all the legacy IM services, with their bright colored uniformed IM clients, are easily accounted for. In comparison, people communicating with the Google Talk service are more difficult to quantify. Nonetheless, the number of registered users for the Google talk service cannot be greater than the GMail service’s registered users. But the fact that Google’s IM services is younger than the incumbents service is not factored in. Etc… In the end, an eye catching title will certainly be simpler to create than a critical analysis of these figures.

Most importantly, this blunt statement fails to capture the fundamental difference between a captive and an open IM service. Either you listen to, communicate with, be a resource for, build trust with your users, and once you have established trust, you can build a long and healthy relationship. Or you keep your users behind bars, hopping they will not look outside, until they decide to escape. Google seems to favor the former approach. In this context, following my previous post, AOL’s biggest challenge to respond to the latest tactical move from its competitors involves deciding a drastic departure from its traditional IM model. This tougher than marying a next of kin, as interoperability would imply AIM and Google Talk becoming IM mates, creating a real opening. I doubt Google would welcome a closed partnership with any player, including AOL.

Technorati Tags: XMPP, Jabber, Interoperability, Instant messaging, Antecipate

Is Skype a parasite or a Trojan?

In those days of web 2.x, I often feel that those practicing high doses of ideas mashup usually end up with brain jam. I have had found another good example with this fine piece. Obviously, there has been some discussion going on around IM interoperability lately, which in turn has brought back all the bitterness about our inability to easily and instantly communicate. But have you ever noticed how the same recipes always make for headline of “tabloid blogging”. This one starts with an aggressive title using a few recuperated clichés such a “cold war” and “détente” to awaken old instinctive fears inside the reader. The post follows with a spread of unrelated references, which relevance and validity were obviously never questioned. It goes on enrolling some fellow bloggers unwillingly, citing them partially and out of context. After this the author can pretend to pose as a pundit. Well... Some have different views and present alternatives hypothesis. I personally believe there is one approximately true statement and two major flawed assumptions to justify a lot of conjecture in this paper.

Beyond the tectonic plates’ image, declaring that IM interoperability is a business issue is probably true. Very simply, because this is a matter of toll gates, which is usually solved by a financial transaction. This is turn is business. Am I missing something?

The first flawed assumption is to present LCS as the enterprise federator, and by consequence, suggesting SIMPLE as the federating protocol. In the context of gatekeepers business, it is normal for Microsoft to claim its LCS as the universal federator for an enterprise willing to access public IM networks. This was only a matter of deep pockets and separate negotiation with every “entrenched interest”. Skimming through the recently discovered interoperability guide for LCS 2005 has somehow persuaded the author that LCS was “the” technical interoperability solution. I would only say that it may be a hasted conclusion. LCS (and other federating EIM servers) does not allow federating between public IM clouds, as inter cloud communication is specifically restricted by every individual business agreement. A second hasted conclusion is to use Google’s (very real) inaptitude at marketing Google Talk as a reason to look at XMPP with contempt. Jabberites, you would certainly be happy to learn that “with just 3.4 million [GTalk] users, who really gives a damn what you do”! Beyond the arrogance of the statement, Google is not interested in building communities; it is interested in driving traffic though its sites to increase its advertising broker’s exposure. Google has just opened the door to millions of XMPP users. This was a smart move and was received as a friendly gesture, re-enforcing their “not so evil” perception as a web company. Obviously, seeing this requires thinking outside the IM box. Which in my opinion, neither the IM incumbents, nor this author, have shown a good aptitude at doing.

The second flawed assumption is to present the Skype protocol as the “white knight” of interoperability. When writing about IM interoperability, it would not be wise nor popular to support any one of the competing incumbent public IM protocols. If so, what is left in the protocol landscape to fulfill that interoperability role for the public IM crowd? SIP has been ruled out as a contender (look at the bottom of the post). XMPP has been dismissed above. Only Skype remains to take up the role of the messiah. But now that its protocol has been hacked, I personally think Skype will pay a ransom to this group of Chinese hackers and buy them. This is in line with the recent wave of extortion based virus activity. Hacking a proprietary protocol is the just another flavor of it. But Skype could also make their protocol specification public and disable the threat, couldn’t they? They won’t do it, as they would have to admit publicly that their protocol’s client exhibits a singular cross between a parasite and a Trojan’s behavior. For the Skype network protocol, any node is a potential relay for any other node. There is nothing wrong with this design. But there is something very wrong with hiding this behavior from the end user. Aside from the questions of ethics and privacy, it steals from the user by using the computer's memory resources and also by eating bandwidth as it relays traffic via the user's Internet connection. Because it is using memory and system resources beyond the specific user’s need, the client operation may also lead to general system instability. Hence Skype’s relative reluctance to documenting the protocol...

Two approximations in one post make me feel suspicious. However, I know some peoples also define a truth as “an ingenious compound of desirability and appearance”, adding immediately that

Discovery of truth is the sole purpose of philosophy, which is the most ancient occupation of the human mind and has a fair prospect of existing with increasing activity to the end of time.

Who knows, the author may just be a philosopher in the making ;) As a conclusion, his conjectures provided sources for an additional demonstration that IM interoperability is not about technology. The solution to interoperability will never be resolved by interests entrenched in vendors’ consortia, be it Cisco behind SIMPLE, any other incumbent public IM or Skype. In the same way mail clients are on every personal computer, IM consumers and developers would only benefit when they will have the same kind of protocol: free, open and standard.

Technorati Tags: XMPP, Jabber, SIP, VoIP, Skype, Interoperability, Antecipate

IM interoperability: it’s not an IM issue

Stove had it at hand, but it did not push his advantage to finish his move: interoperability is not about IM, it is about multimedia communication.

…interoperability is not about IM it's about multimedia communication…

Only in this context would a regulator (eventually) be required to step in, and force the interests at stake to “play nice”… As soon as one mentions media communication, the only business model that springs to mind is the POTS model. The toll model, with its greedy gatekeepers, has been around for millenniums. It is well known, does not require any advanced technology or an abnormally high IQ, is only based on power. In theory, it should only appeal to the most primitive societies, but there are hard facts proving the opposite…

In effect, there is no business model for IM. For what it is worth, Wikipedia describes instant messaging as a form of real-time text communication. What money is there to be made in text messaging? Same as what can be made in email. Instant messaging as a form of communication has already become a commodity. And if it had been alone, it would be using a single protocol since many years. The curse of IM lies in the bundling by the crowd of IM with presence, which is tomorrow’s real “dial-tone”. Moreover, this misconception is bi-directional. Whenever someone says “presence”, you immediately hear another person replying “IM”. And vice versa.

What is really at stake in these clouds forming is the control over presence, and by extension, over its use as dial tone to enable more efficient multimedia communications.

First of all, there is VoIP. There has been a business model for VoIP alone, related to decreasing cost. Together, VoIP and presence are much more attractive, as presence would enhance the efficiency of placing a voice call. Remember that in the current POTS, you have to actually ring the other party to find out about its availability. Establishing a voice call between two parties creates a significant load on the underlying infrastructure, even if using a separate signaling network somewhat decreases this load. This is mainly what carriers are charging you for. In a presence enabled multimedia communication system, you do not need to call the other party, as you can deduce its availability to accept your communication request from an aggregation of presence state. This approach drastically decreases the load on your infrastructure, and in theory, makes it more efficient. The carrier’s business in turn benefits from this increased operational efficiency.

Second of all, there is presence enabled marketing. Although this is still a fuzzy business model, there has been growing interest in linking focused advertising with presence to achieve really personalized content distribution. The inclusion of presence in communication devices, from mobile phones to set-top boxes, not forgetting all the connected personal computers, will allow aggregating a wide array of real-time information about one’s behavior. This alone creates huge business opportunities, when coupled with multimedia communication. By chance, the average marketer have not yet grasped the potential... This also induces a number of privacy related concerns, for which there are no satisfactory answers yet. The idea of presence enabled marketing has been in the boardrooms of the most visionary multimedia communication companies for over five years now. AOL, Microsoft and Yahoo! are not what I would call visionaries… but they have done their home work and watched their competitors. Beyond the potential, they have come to realize they could be left on the side of the road if they were to remain at stand still.

As this other post rightly describes, interoperability is not a technology issue, it is not even an IM issue. It is a wider scoped tectonic movement, where the business goes beyond the real-time exchange of text messages. I am certain the major “IM” service providers have already figured out how they will get something in return to interoperate: they will simply charge their customers for filling up their “series of tubes” with voice messages… As I said they are far from being visionaries.

Technorati Tags: XMPP, Jabber, Interoperability, Instant messaging, VoIP, Presence, Antecipate

An IM game of Go

So this week has seen the birth of a limited interoperability beta test between Microsoft and Yahoo! IM bastions. The real thing to strike me in the announcement is how un-respectful it is of their respective users’ base.

The press release itself is written entirely in marketing-speak, and is rather arrogant when referring to their users. Not only do they call them “consumers”, but they try to make them, and us at the same time, believe it was so difficult to achieve interoperability. That sounds like a typical telco’s speech, don’t you think? And by many aspects it is. After all Yahoo! always believed they had built “a transport network” and that they could become a carrier. Microsoft is, well … Microsoft and has always believed it was everything. Maybe calling their users “consumers” make them feel more like real “carriers”…

For those a little familiar with the public IM context, this announcement is not about empowering their federated users’ base, but clearly aimed at isolating even more their arch rival AOL. Not directly, as one would immediately believe, by excluding it from their “interoperability”, but rather by undermining potential revenue sources. AOL is deriving revenues from charging for the access to their community of users. In certain industry verticals, such as finance or insurance, AIM is widely used, and AOL as been careful to preserve this population. It is taking advantage of it to extract revenues through “certifying” access to its private IM community. This announcement is an additional nail in their isolationism’s coffin. This is clearly what I read behind Microsoft and Yahoo! declaring that their users

…will be among the first to exchange instant messages across the free services as well as see their friends’ online presence, view personal status messages, share select emoticons, view offline messages and add new contacts from either service at no cost.

Frankly speaking, how would AOL pay toll remain sustainable in the future? Not much! You can trust all the financial institutions’ IT teams to leverage this announcement to their own advantage.

This interoperability move also provides Microsoft with a clear tactical advantage on the enterprise IM server market. They will clearly benefit from this new context and will certainly be pushing their LCS further into the enterprise. Microsoft can provide LCS connectivity to MSN, and through the interoperability agreement, will reach Yahoo! users. They already have “certified” LCS connectivity to AOL. LCS will end being the only certified multi IM networks connectivity for the enterprise. The cleverness touch resides in all this being done without infringing any right. Much unlike the use of XMPP transports in enterprise, if you see what I mean.

…there are no technical barriers to open IM interoprability between AOL and Google…

By announcing their intent long before they actually delivered, the legacy pair has again used one of the well known techniques of market control byincumbents described by Robert X. Cringely. I believe AOL is bound to move soon to counter the Microsoft Yahoo! interoperability deal. With the small investment from Google in AOL, it makes an interoperability announcement between these two other players a plausible scenario. There are no technical barriers to an open interoperability between AOL and Google, as AOL has already deployed XMPP gateways for the enterprises. On paper, it may allow a rapid reaction by AOL, but they are also known to be such slow negotiators…

You may have noticed how this annoucement is about a “proprietary” interoperability. As a matter of fact, nothing is ever said about how they technocally bridge the two legacy networks. I have seen a suggestion that the next step should be the publication of an open interoperability specification by Microsoft and Yahoo! I wonder if the author is so naïve, or was under the influence of one of his blogging “ingredients”, as to expect an “open” specification coming from these two dinosaurs. Moreover, this is not needed, as the open specification for IM interoperability already exists in the form of XMPP. Email interoperability was never achieved through “industry players”, and almost every vendor led consortium has failed to impose any long lived interoperability standard on the Internet. Is the real issue people’s short memories, their propention to re-invent the wheel, their limited conception of the Internet time-space or (name your own reason here) ...

In spite of their desire to make us believe that something truly revolutionary had been achieved, Microsoft and Yahoo! have only managed to set the foundation for a larger IM island. A 350 millions inhabitants’ continent perhaps, but an island still. Previous similar attempts, such as those by Compuserve or Genie, to deny free communication over the Internet, have failed.

Even more so in a time of user’s empowerment, in the absence of an honest voice, you’re bound to remember John Lydon’s famous words: “Ever get the feeling you’ve been cheated?” Once a fraction of these 350 millions would have realized the vacuity of the announcement and noticed the contempt with which they have been treated, it might become a heavy incentive to force Microsoft and Yahoo! to become really interoperable…

Technorati Tags: XMPP, Jabber, Interoperability, Antecipate

IMteroperable? isn't it amazing, dear?

What is really the best in Microsoft and Yahoo! interoperability announcement is the part, were the customers of the two services:

will be among the first to exchange instant messages across the free services as well as see their friends’ online presence, view personal status messages, share select emoticons, view offline messages and add new contacts from either service at no cost.

So, paying interoperability was amongst the options? Such an unashamed attitude is simply amazing.

I leave you to read the rest of this marketing verbiage and discover how 350 millions where left out of a vast commodity service offered to the XMPP federation for over five years now. You will be surprised to discover that Microsoft and Yahoo!

are proud to deliver this latest advancement in IM services that empower people to communicate with virtually whomever they want, wherever they want and whenever they want.

and that the latest advancement they are referring to is simply that

Consumers worldwide from Microsoft and Yahoo! will be able to take advantage of IM interoperability and join the limited public beta program. They will be among the first to exchange instant messages across the free services as well as see their friends’ online presence, view personal status.

Beyond the fact it looks like an April’s fool day’s press release, I am just wondering how, in our days of user’s empowerment, 350 millions still bear that kind of arrogance from such dinosaurs. But you never know, Microsoft and Yahoo! may well push it further and claim a patent on IM interoperability by tomorrow...

Anyway, this is again a reminder of a sad reality. We find today a bunch of IM services attempting to emulate the grotesque attitude of wireless carriers. Walled gardens are not only alienating, they are essentially hostile to the customer. Customers, beyond an enormous frustration feeling, should have a greater say in the matter. It will be interesting to watch how they will assert their rights, because, from the tone of this announcement,  the IM providers are in a rather arrogant mood.

In the end, what worries me more is the flabergasted attitude expressed by this kind of post. But when someone describes Trillian or Adium as services, no wonder it also writes “IM interoperability took so long that I thought it was never going to happen”. But today everything has changed. Isn’t this really an amazing world?

Technorati Tags: XMPP, Jabber, Interoperability, Antecipate

MSRP: Managing Severely Retarded Protocol

The messaging and presence protocol space is a good miniature of human passions. It exhibit this exquisite duality you find in those good old duck dodger’s cartoons, between those wanting to master the world and those wanting to save the world.

Behind the smoke screen created by using words such as “open” or “simple”, the sipping working group has been actively busy coming up with yet another messaging protocol. And guess what, this protocol is so superior that “in other words you can build a skookum Instant Messaging application using this technology”. What a world savior!

What really struck me in this article is the blunt announcement that “SIMPLE is primarily a done deal from a standards perspective”. Anyone looking at the dependency list for the 3GPP mobile network will somewhat play down this affirmation. There are a lot of non standard drafts left in the list, with a dependency stated as critical, that are stalling many technical implementations. In particular, several of these dependencies relate to XCAP, the new form of XML query devised by another “would be master of the world” recently recuperated by Cisco. The article goes on saying 

The exceptions are to do with some ongoing work in putting together the last of the framework that’s needed for a user of SIMPLE to be able to tell a service provider what their preferences are on how people can reach them. Which are the last parts of the mechanism that let XCAP (XML Control Access Protocol) work. The XCAP data formats are all well defined and the protocol for the most part is well-defined. The one corner that we are working out right now is the modification of partial documents in XCAP.

There are a lot of conditionals in this explanation, don’t you think? To make it short, XCAP does not work yet. I believe its only “raison d’etre”, beyond the “NIH syndrome”, is the blatant inability of many in the SIP world to see beyond HTTP like request response protocols. To their defence, I would only say that, to those wanting to copy the POTS features, HTTP looks definitively like a very advanced protocol. But I maybe biased. In reality, disguising HTTP into XCAP may simply have been required by the inability of many mobile phone to support anything else than HTTP. If I remember well, in the beginning, J2ME and Symbian (two other world saviors) only had HTTP as their communication protocol. Not even a socket was exposed… One way or another, this is part of the ongoing refusal by most telecom players to consider a customer anything but a lucky “user” of the wonderful services they provide.

Going back to implementations, I have a compasionate thought for all the bright developers trying to make an instant messenger out of SIMPLE, XCAP, and now MSRP. But the gloom is somewhat brighten by the nice discovery that

… if we were in an IM session and I had a picture I wanted to show you. I could do that and we could share that image dynamically without interrupting the Text session plus associating that image with the session when we were done.

Don’t you think this alone is of a nature to create real value and reassure the developers about MSRP? Not long ago the excellent XTen client product team was producing sometimes more than a protocol build every week in order to keep up with the changing specifications. I am afraid this is not likely to change soon with the introduction of this new messaging transport.

Is creating new protocols really the way to promote open and inter-operable communication spaces? I frankly doubt it. But as I said at the beginning, there is no fun without would be “world masters” and would be “world saviors” whacking each other.

Technorati Tags: XMPP, Jabber, Interoperability, MSRP, Antecipate

FreeSWITCH has got a clue

The FreeSWITCH project is reaching maturity, and I whish they manage to get their first release out to be presented at ClueCon.

From what I know of its architecture, it possesses all the ingredients for a real internet wide distributed voice system. As such I believe FreeSWITCH would have to be seriously considered as the voice platform of choice to complement XMPP. The philosophy driving their concept of distributed platform bodes well with the XMPP federation cloud. But above all, beyond the necessity to provide early solutions, they really understand the difference between Jingle and Google Talk.

I just hope they fix their registration procedure so I could get a build to run on my Windows server…

Technorati Tags: XMPP, Jingle, Jabber, VoIP, IPBX, SIP, Session signaling, Antecipate

Simple factor is better than two-factor authentication

This article is spot on looking at how the two-factor authentication generated hype is hiding away simple and inexpensive solutions. The new buzz phrase in corporate boardrooms is “two-factor authentication is the only adequate control mechanism for internet-based products and services such as online banking”. In reality, I would rather say that being in the boardrooms makes upcoming two-factor authentication inadequate. The ineluctable result would be another massive money influx at keeping alive outdated thinking about identity. Many privacy and security professional say the induced costs and operational challenges to implement two-factor authentication on a large scale are making it time to reassess the situation. Their reasons are summed up in two main questions:

• What new risks have been discovered that need to be addressed?
• Are there other ways, besides traditional two-factor authentication, to counter these risks?

The author give the standard answer to the first question:

that the purpose of the second factor of authentication is to compensate for the weaknesses of the first factor, the password. Weak passwords can be cracked with free software available on the Internet; they can often be discovered inside files stored on the network or people’s laptops, or on sticky notes left inside desk drawers; and they can be solicited through social engineering and phishing e-mails.

The article goes on describing different alternatives addressing the second question. But I believe it does not capture the real reason why the question were asked in the first place.  In essence, these questions are telling us that password authentication is inefficient because passwords are available all over the corporate and extra corporate spaces. They nevertheless fail to analyze this finding beyond the mere need to supplement it by an additional control.

If password based control has become so weak, it is because of its inadequacy with human behavior. Passwords would bring the expected level of control when only used by machines. Machine are natively built to understand and remember 256bit hash values, not human beings. On the other hand, photo passwords as described in the article will perfectly suit a human mind, and discourage even the most powerful image recognition algorithms.

Forcing a machine semantic on flesh and blood never works. But I doubt this is common wisdom in the boardroom.

Technorati Tags: Identity, Digital privacy, Digital identity, Antecipate

Live pains on sight...

There have been scarce mentions of the rollout by LiveJournal of an XMPP based instant messaging service. Beyond the expected voice, I have found very few references to the announcement outside the community, and when they were, they had very specific topics of interest.

…the absence of smart integration between applications and XMPP servers is a major bottleneck to a wide adoption of XMPP…

This is somewhat of a concern, as the expected viral endorsement of XMPP is still far from taking off. Obviously, any smart and business savvy community wanting to offer instant communication to its members is better of choosing XMPP as a protocol, rather than developing its own. Google did it, and I have previously exposed some of the business drivers behind this choice. The same applies for LiveJournal. But beyond the marketing numbers claiming an additional 10 millions XMPP users, what is the reality.

LiveJournal has taken a clever approach to managing its IM users’ rosters, which is very similar to what is found in corporation. They have come up with a very controlled process leveraging the existing user base, taking an integration perspective. This is in my opinion the reason why they created their own XMPP server, rather than adapt an Open Source one. I believe the absence of smart integration between applications and XMPP servers is the weakest point of the current wave of Open Source servers. And it is a major bottleneck to a wide adoption of XMPP as an application messaging transport, much more than reliability. Application integration is not about allowing low level access to a database or a directory, which is the bare minimum a server must provide. Application integration means enabling server to servers’ communication at the application level. In the current Internet context it translates into making XMPP servers natively understand HTTP, and Web server have integrated XMPP transport.

LiveJournal is rolling out its own vision of XMPP. I understand perfectly the need for different communities to leverage their own specificity, but I also believe it must always be done without lock-in. Give an end user all liberty to leave at any time, taking with her all her belongings, and you will keep her for as long as you whish. Base your service on wrong assumptions, or tweak the standards, and you create an uneasy feeling. Creating an uneasy feeling is exactly what this statement is doing:

We have SSL support, but we're not enabling it, at least not right away, but the auth is challenge/response w/ anti-replay stuff in it, so people can sniff your conversations, but not your login info. So SSL isn't required. With iChat, you have to explicitly turn it off. Justification: lot of CPU overhead for little gain, especially as clients often use OTR for end-to-end encryption.

Support of TLS is one of the soundest requirements of XMPP. The argument for not using TLS are very light.

• Mentioning CPU overhead is irrelevant with today’s workstations. On mobile clients it could have an impact though. With the concurrent connection figures announced for djaberd, I have the feeling the issue is more about server side scalability. Without TLS, connecting to the LiveJournal service from an OpenSource client will create another of these “unnecessary pains” Justin has been rightly moaning about recently.
• The second issue resides in naming OTR as the justification for not using TLS. In the current state of XMPP, this is simply an error, and will remain so until we have enough clients supporting JEP-116 in the loose. And even then, end-to-end encryption will by no mean be a reason not to use TLS.

Creating islands in the communication space is a sensible and realistic approach. But reducing the inter-islands permeability to the lowest common denominator is still legacy thinking.

Technorati Tags: XMPP, Jabber, Interoperability, LiveJournal, Antecipate

What is so advanced in AMQP?

As a matter of fact I was looking at posting on AMQP, but Nolan has beaten me to it. Nevertheless, I believe there is more that hope to see XMPP used as a mainstream application messaging protocol before 2011. It only need to addresses a few additional features found in AMQP to be perceived as a valid contender. Let me explain my position by analysing the claims made in the announcement. Starting with the marketing blurb, the announcement explains in preamble that AMQP was developed

In response to internal requirements, market demand and partners' electronic trading needs, the contributors are collaborating on specifications for defining and building messaging infrastructure that is broadly applicable for enterprise use, totally open, platform agnostic, inter-operable, and which aims to provide developers with simpler and more powerful ways of constructing messaging dependent applications.

I doubt anyone would ever use the world “retarded” in a new protocol name. Similarly it would be very inappropriate to admit that a new protocol is not driven by a real world requirement, does not address a market need, would only be implemented in a narrow vertical community, as a closed protocol, running on dedicated hardware and providing a more obscure API to developers. In the end, AMQP is just another message queueing protocol incarnation, for a very specific vertical: the finance industry. Is that enough for being advanced? 

Let’s now compare the two protocols models. XMPP and AMQP use a similar model that defines a server's semantics explicitly. AMQP explains its approach by “interoperability” which as been part of XMPP from the very beginning. Both models specify a modular set of components and standard rules for connecting these. AMQP defines three main types of components, connected into processing chains in a server to create the required functionality:

• The “exchange” component receives messages from applications and routes these to message queues, based on various criteria, usually message properties or content;
• The “message queue” component stores messages until a consumer client application can process them;
• The “binding” component defines the relationship between a message queue and an exchange and provides the message routing rules.

This is known territory for anyone familiar with message middle ware architecture. An AMQP server is nothing but a specialised email server, with each exchange acting as a message transfer agent, and each message queue as a mailbox. Bindings define the routing tables in each transfer agent. Applications “publish” messages to individual transfer agents, which deposit the messages into the appropriate mailboxes. Other applications “consume” message by taking them out of the mailboxes. Again just another expression of the classic concepts of store-and-forward queues and topic subscriptions, with a zest of on-demand message queues and message queue forking.

XMPP pubsub extensions already address many of these features. Persistent nodes play the role of AMQP store-and-forward queues, instant nodes can be used for on demand AMQP queues. But AMQP also makes way for content-based routing, explicitly using message attributes. XMPP does not provide a similar explicit way to define content-based routing, as the pubsub extension leaves this decision to the implementation.

If we now look at the transport protocol, AMQP is defined as “a binary protocol with modern features: it is multi-channel, negotiated, asynchronous, secure, portable, neutral, and efficient.” This definition alone let me believe that XMPP was very “advanced” and has possessed many modern features for a long time now. From this phrase, the only word that can lead to possible counter arguments is “efficient”. And from my perspective, this is even subject to appreciation.

The AMQP protocol defines a transport layer and a functional layer. The functional layer comprises a set of commands which can be mapped to the XMPP pubsub extension without too many difficulties. The transport layer “handles channel multiplexing, framing, content encoding, heart-beating, data representation, and error handling”. Well, apart from “heart-beating” which is sometimes the cause of heated debates on the JSF mailing list, the rest of the functions is present in the current XMPP standard. What is not yet in XMPP, though, is an appropriate reliability mechanism. But the subject gives rise to similarly heated threads at the JSF. 

In the end, paraphrasing Nolan, I totally agree that:

AMQP offers point-to-point, publish/subscribe, and many-to-many messaging. It's a binary protocol which could provide a slight increase in speed over XMPP, but it lacks a standard message body format, presence, and everything else the JSF has pushed out. Not to mention that AMPQ still hasn't reached version 1.0 yet.

In short AMQP arrives too late, but is by no mean advanced.

Beyond the technical aspect, I also believe AMQP’s announcement is the implicit recognition of the larger space XMPP is bound to take as the real-time, presence enabled messaging protocol. I am basing my analysis on these very simple facts. AMQP is a tentative answer to the threat imposed on incumbent messaging protocols developed for the financial industry by open and extensible protocols such as XMPP. The advent of cheap, standard based, alternatives to proprietary messaging systems opens large breaches in the positions of first tier vendors such as Tibco or IBM. It threatens even more the second tier vendors such as those involved in AMQP. In effect, I believe the risk is greater for the second tier, as displacing the first tier will certainly take longer.

In term of business solutions, 80% of the financial message based communication can be handled through “unreliable” messaging protocols. This has been a strong driver behind the very early adoption of IM by the financial industry to conduct many communications leading to money transactions. I believe XMPP could easily add the required reliability to cater for a great part of the remaining 20% in communications. And I am not mentioning the other advantages that can be derived from XMPP’s embedded presence support.

As a matter of fact, I do not believe AMQP will ever achieve its dream of dominance, simply because it is promoted by a software consortium. Despite known procedural problems, the IT industry has a strong tendency to rely on consortia to produce technology. Web services, middleware’s current silver bullet, represents the archetypal example with its internal fighting, fragmentation, lack of architectural coherence, design by committee, and feature overload. It seems inevitable that Web services’ history will resemble its CORBA ancestor. An alternative exists with open source standards. At the heart of these alternative practices are two essential prerequisites: cooperation and trust. Without cooperation, an evolutionary process cannot exist. Without trust, no common experts group can act as an ultimate arbiter. This is precisely where software consortia find their limitations. Putting customers and competing vendors into a consortium and expecting them to come up with a high-quality product is naïve. Commercial realities ensure that cooperation and trust are the last things any participant will care about. Naturally, software consortia contribute to an evolutionary process just as much as open source projects do. But the final direction will always be set by the customers in the consortium with their wallets. For those acquainted with the financial industry practices, this role is usually not benevolent...

In the end, I believe the AMQP announcement has been driven by the same “Fear, Uncertainty and Doubt” (FUD) practices described in “Accidental Empires”. In chapter 14 of his book, Robert Cringely describes techniques one can use to control the market:

• Announce a direction, not a product, and people will stop buying competing products because you’ve just told them they’re the “retarded” way of doing things.
• Don’t support anybody else’s standards and make your own.

When analysed in context, AMQP represents a strong endorsement of XMPP as a viable technology. In my opinion it also highlight the need for application specific extended specifications build on top of existing XMPP extensions. In particular, instead of defining a “generic” reliability mechanism for XMPP, it might be more efficient to define context related extensions. Don’t you think there is a great probability for “reliability” in the financial industry to bare a different meaning than the same word in another industries?

Finally, again paraphrasing Nolan, “we could learn a few things from them, like their requirements.” I entirely agree users’ requirements are always worth reading. We could probably also get these requirements directly through the main JSF’s sponsor. After all, isn’t JP Morgan Chase one of their blue chip customers? This to emphasised Nolan’s plea for advocacy in this space. But in my opinion, advocacy must move well above the John O'Hara or John Davies level. To a level that understands you can get the same feature set as offered by proprietary messaging protocols for 20% of the cost… This is a message the financial industry usually receives well without a “reliable” protocol.

Technorati Tags: XMPP, Jabber, Interoperability, AMQP, Antecipate