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: […]

The comments are definitely worth reading as well.

That post was also discussed in ReadWriteWeb, “Could Instant Messaging (XMPP) Power the Future of Online Communication?”, and Bill de hÓra throws in his educated round-up. Both are very interesting reads. I liked about this note especially (from latter; original emphasis):

Atom and XMPP can go anywhere - it’s about reach, and simplicity, two criteria for innovative apps - this stuff will go over phones, web, desktops, tv, planes, trains and automobiles.

Effectively—also surprisingly and unexpectedly—this is a verbalization of our tagline. :) (Everywhere Services.) Thus, Xernel’s case has been built on top of the “XMPP architecture”; quoted, as the most exercised features are actually real-timeliness and bidirectionality, but XMPP furthermore brings in other essential features.

However, XMPP is just the infrastructure which we’re pretty much assuming given. Though, also we’re building yet another xmppd, but we’re not considering that as the most essential layer. (We’re just not happy with creating service clouds¹ based on current implementations.) Our primary interest is in how to wire the real-world services to the XMPP world.

The XMPP infrastructure is not there yet, but if you skimmed the references above you probably saw the strong signs like TiVo and Twitter. The query-response architecture is currently being given life-extension treatment with some hacks² whereas we’re expecting a bit more fundamental paradigm shift starting to happen.

Small, but definite signs.

1) Please note the fundamental difference between providing vs. managing services via XMPP.

2) Surely, the hacks are better than nothing, but these patches are usually leaky and not viable in a longer term. In this case the long-living TCP connections are one problem in context of HTTP.

It is clear that programmable mobiles have the potential to become general purpose “controllers” that allow us to interact, possibly indirectly through online services, with the many devices that service us from moment to moment.

—Vint Cerf on The future of the Internet

Although, we’re actually trying to let people interact with the services, not just through them. And please consider that interaction two-way, while at it.. :)

With the help of our system you could become the man that you have always wanted to be and your partner(s) want you to be.

Certainly better as our current one, or what do you think? :)

Now every application isn’t complete until it can send/receive IMs.

Remember that, folks, when you start planning your next web service / upgrade. :)

> I’ve suggested that I think xmpp is a
> great way to get this done, David has
> shown some very interesting work
> he’s done with XFN, there have been
> people trying to use FOAF for ages, etc.

I think XMPP is interesting, though does require infrastructure changes for large sites. (which might even be harder for smaller sites to implement). LiveJournal already provides a Jabber account for each user with a roster populated with their friends on the service.

(more…)

However, for professional reasons I must note here my minor concern over the Sonera’s technology selection, as it’s now based on Microsoft’s walled garden system. But, I’m sure this issue will correct itself in time and that it’s rather unfruitful to worry about. For example, Google must provide Google Talk for the GPhone [1, 2, 3]; it’d be a wonder if they didn’t. And Google Talk is based on the open, real-time communications standard XMPP (a.k.a. Jabber); also Apple is using XMPP in their products.

Above all, I hope we’ll soon be celebrating the dawn of mobile IM! (We’ll see how it turns out.)

Tags: Mobile, Instant Messaging, XMPP

So, I managed to bump into a couple of earlier articles regarding “mobile commerce”. The first one was saying something like this:

Being able to buy and sell goods/services over mobile devices is an important step towards achieving an anywhere, anytime paradigm. Location and time will no longer constrain people from completing their transactions.

— in “Commerce, e-commerce, and m-commerce: what comes next?”, Communications of the ACM, Dec 2003, pp. 251-257. (Access required.)

Good stuff, but this was already four years ago—ancient history in Internet time. I’m still not yet seeing any major consumer adoption of mobile commerce services. Pardon me, but I very strongly believe that it is not feasible with current services yet. It’s extremely awkward to use eBay with a mobile browser—with the devices it’s at all possible. And you need to constantly refresh it!… Not going to happen with a mobile, was it iPhone or whatever. So, I’m not wondering why the ‘anywhere, anytime paradigm’ is still waiting to be realized.

But wait, that’s actually the head-ache we have the cure for. :) (I know, you knew it coming… ;) With iPhone—for example—it’s probably Meebo who’ll implement our channel. Infrastructure for your next servicing paradigm is being built at a very satisfying pace.

Another excerpt from the same 2003 issue, describing the previous:

The mobile Internet system differs from the stationary Internet system. First, the mobile Internet system usually offers a lower level of available system resources. Second, it provides instant connectivity, which makes it possible to use the mobile Internet at the moment of need, anywhere and anytime. Third, it is more personal than the stationary Internet.

— in “What’s so different about the mobile Internet?”, Communications of the ACM, Dec 2003, pp. 240-247. (Access required.)

In the article was also observed that consumers prefer buying low-risk products over mobile. This was due to limited search and information presentation capabilities, which aren’t going to catch the desktop configuration—unless the next iPhone is going to introduce a 20″ display, which I hope not. :) However, this isn’t the whole truth. For example, with auctions you’ve probably studied the targets in advance; you just control your bidding with the respective mobile application, or search for more instances of the same item. Ok, this was the case which sparked the whole Xernel into existence, so it’s pretty self-evident…

Tags: Mobile, Services, Instant Messaging

Those news were a bit of a surprise as the EIM market has been a little quiet lately—business as usual, merely. (Some links here.) Perhaps some critical mass was achieved lately. Also, for the sake of all reason, I most note here that I have no idea when IM became a “web 2.0 -tool”, but I’m clearly not complaining. :) I only wish this doesn’t result in any negative annotations before long. And hey, quit that sneering already, ‘web 2.0’ is just a mature term for certain concepts in the current web. :)

Now, what’s the major deal here? Briefly put, if the emphasis in communication is moving from email to IM, we’re clearly heading to real-time operations. And when enterprises work internally in real-time, pressure rises to push the “external interfaces” to real-time as well. Xernel isn’t interested in personal communications, but when you want to reach the consumers in real-time, we have the stuff to make it work. That’s our case. In short.

I guess that now as the ball is rolling, there’s no stopping it—and you don’t want to get left behind. It’s best just to embrace the pace!

Tags: Enterprise, Instant Messaging, Web 2.0, Research

However, there were also some more interesting observations, like this:

Adoption of a new mobile service does not automatically lead to abandonment of the previous ones. Instead, new mobile services are adopted in addition to existing ones due to complementarities.

From our point of view this translates into that the mobile services are naturally perceived as to complement the respective web-based services. Thus, a mobile channel seems like a good companion for an Internet service that has some use for the channel’s properties: natively bidirectional, real-time communications, presence sensitive, etc. (Naturally, there should be quite a many services of this kind; how about yours?…)

There was also this note:

[…] it appears the mobile device is perceived as a contact-enabling tool that allows connectivity and communications anywhere and anytime. This is also supported by the second most important benefit, which is “services make me accessible anywhere and anytime.”

The fun part here was that the end of the quotation resembles our precious slogan, which becomes clear if you transpose the previous to “we make services accessible anywhere and anytime.”

Xernel Oy — Everywhere Services :)

Tags: Mobile, Web, Services

So, what do we have to do with IM? No, we’re not creating any instant messaging systems, but we use it as a service interaction technology instead. Yeah, we aim to let you to chat with the services you now access with your browser, phone (as in voice) or by some other means. And while at it, we’d also like the services to be able to initiate conversations. Huh, scary? Sure, like with all new technology, but the reality is merely on the contrary. The odds are that the services will be much more delicate than most of your other contacts—assumed that your service provider has some decent technology.

I’ll set the context first and then I’ll introduce some aspects of instant messaging we’re especially interested in.

Introduction

The thing is that we got tired of ‘polling’ all the services around the web and we started thinking about how to get the services come to us. (The age-old mantra…) The services are now just sitting there doing nothing—at least from my perspective. Service provider’s viewpoint naturally is that they’re struggling with scalability issues already… But I mostly care only about the service I’m getting. (I’m just a spoiled brat of course, but let’s not go there.) So how could we get the services come to us? Or, firstly, when would I even want that?

Justification

If I volunteered to be actively intruded, there should probably be something very important happening? Absolutely. So, we must be talking about services such as online auctions, stock trading, betting, and also games in some cases. In those kind of services there should be something important happening quite frequently, agree? So important that you could even want to be intruded? (When your presence status allows it.) At least I believe so.

What’s wrong with (push-) email then? Or SMS? Let’s get back to that ‘service interaction’ blurb. We’re aiming at providing services not only the ability to send notifications, but also the ability to let you respond instantly to whatever events. Sell! Buy! Bid! Bet! Not by opening your (mobile) browser—which takes time and effort—but by simply sending a few letter response in matter of seconds. Less key presses required. While chatting or whatever. E-mail? Hardly—I’d rather not do stock trading via email. SMS? Going to get replaced with instant messaging anyways; also too expensive in many cases. And neither of those support presence.

Properties

of instant messaging:

• Bi-directional
• Instantaneous
• Presence-enabled 
• Mobile (although only some leader regions apply currently)

Well, I believe that list doesn’t need much elaboration; please notify if you think otherwise. These properties are listed here merely just for pointing out the basic differences between instant messaging and HTTP-based technologies. And, by the way, we’re targeting consumer services, so proprietary technologies don’t count—you can achieve whatever features you like if you can afford to make your customers install custom apps. But we’re not into that so much.

Furthermore, also pervasiveness and ubiquitousness are just around the corner (or the next), pending for further materialization—just if you happen to fancy the terms. I know some who do. And be sure to check that link soon; I know I’ll get tired of it and remove it shortly.

Implementation

Just a bit of more concrete stuff. We’re aiming at applying our system to existing services, which means that the business logic is accessed with REST or SOAP and the data will be in XML or JSON format. We do have some stuff that does wonderful things but, basically, the applications are built right on top of that data; there are no thick UI layers. We like it thin. So, we use XSLT for creating output messages and a very simple DSL to figure out the user intents (ie., to parse input.) The DSL uses XPath to bind user input to the business data. Thus, there’s now just the pure data and the related input/output model (our DSL/XSLT) and that should be pretty manageable.

But wait, we also need to construct the dialog. Fortunately, there’s another standard technology that is just perfect for it, which is BPEL. It is designed for implementing service flows; or, to orchestrate services, as they say. (You just may have the BPEL used in your systems already so I won’t dig into it; and it’s not the topic of this post anyway.) We have integrated instant messaging to these process models and thus created a complete platform for developing IM interfaces for services—with as little overhead as possible, and mostly with standard technologies.

And this is basically how we constructed our lightweight workflow system; which is natively bi-directional and all that. I assure you it’s a whole other ball game compared to the enterprisey workflow systems. And it has the power, no corners cut there.

(Sorry if the boasting is too blatant, but I’m just so thrilled with this stuff. :)

Future directions

The plain text IM is reality for now—with some smileys etc—but there’s a good chance that it will also grow richer. We’re not technically restricted to instant messaging; the underlying technologies have much wider applicability. Instant messaging just happened to be the killer application of the instant, two-way communications and so that’s what we’re providing currently. But as the client applications get more features, we’ll already be there utilizing new possibilities of the active Internet.

Did I even manage to make the case for our slogan ‘Everywhere Services’? Comments are welcome!

Tags: Instant Messaging, Presence, BPEL, Web Services, Mobile

Below is a draft of the ‘agenda’ for this blog, which is just a teaser for now, but I still want to offer some guideline of what might be coming out of this tube—however lengthy process it might be. If we manage to raise any thoughts, positive or negative, we really would be delighted to hear about it!