Calling back

Yay, let the first actual post be about instant messaging. But, as I must now first introduce the whole context, this will be pretty superficial post. I’ll get more into details later, in respect with other aspects of our case.

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