Enterprise collaboration faces a number of challenges in the years to come. IM systems today are where e-mail was back in the late 1980s -- islands of common use separated by protocols, vendors, and the network itself. Jon Udell and P.J. Connolly debate whether Web services will be the catalyst for the transformation of collaboration, and how.
Jon: Effective collaboration is partly about the medium, and we have more of those than we know what to do with: phone, e-mail, IM, SMS. It's also about the message, though, and the messaging technologies we now use need some help. None of them is able to wrap adequate context around documents and discussions. A Web services infrastructure can do that. A year ago, a SOAP message body was a bare XML payload. Today it's likely to arrive wrapped in headers that spell out the who, what, when, where, and why of a transaction. Clients on any platform, communicating over a range of transports, will want to create and use these contexts.
P.J.: Context is a funny thing, and it's a human construct. How is a machine supposed to interpret something so abstract? In the early days of e-mail, there were flame wars over how much information should be in a message header. One of the fields in a message poking fun over long headers indicated the user's assumed psychological state, and if that isn't useful contextual data, I don't know what is. But I have to disagree with your point -- even though it's only implied -- that the major vendors of messaging technologies are somehow failing to provide context. "Presence awareness" is only the tip of the iceberg here. I just don't see where Web services have a monopoly on context.
Jon: Presence awareness is a great example. IM buddy lists normally aren't context-sensitive. When collaborating with a handful of peers, I need awareness of their presence in a shared workspace. Office 2003 solves this brilliantly. An Excel or InfoPath document becomes a task-scoped buddy list -- provided, of course, that your whole team is plugged into IIS, SharePoint Services, Active Directory, and Live Communication Server. Groove solves the same problem, provided your whole team is running Groove. But real life is never that homogenous. So, Groove concluded a year ago what Microsoft will doubtless also conclude: Presence awareness has to become a platform-neutral Web service.
P.J.: Despite what some may think, I'm about as platform-neutral as they come. But here's the problem: There's still no agreement on how presence shall be presented as a Web service. On one side are the proponents of XMPP (Extensible Messaging and Presence Protocol), an XML-based outgrowth of the Jabber project, which doesn't seem to be supported by anyone bigger than Novell. On the other, I see IBM and Microsoft agreeing on something for the first time since OS/2 1.0 was released: that SIP (Session Initiation Protocol)/SIMPLE (SIP Implementation for Messaging and Presence Leverage Enhancements) is the way to go. So, I'm curious, Jon: What side are you on?
Jon: Both, for different reasons, but it doesn't matter for the purposes of this discussion. I know several developers who are using Jabber as a SOAP transport, and I'm told that the new breed of SIP-oriented IP PBXs offers SOAP interfaces. It's not a question of whether Web services will turbocharge the next generation of collaboration, but how. And there are two big answers. First, Web services will provide a general means of access to the messaging substrates. Second, Web services will help us unify metadata (message headers, aka context) and content (message bodies, aka documents) under a common data-management discipline: XML.
P.J.: Well, it would be nice to have a unified approach to both content and metadata -- I agree with you there. I also have to admit that it's hard to envision how vendors are going to package their dream world where e-mails spawn IMs, which turn into telephone calls or launch a business process without XML somewhere in the data-transformation process. But we're a long way from platform-neutral services today. Customers are going to have to open up their wallets to pay for these features, and vendors are going to have to open up their products to add these features in such a way that they are easily deployed and managed. That's the tricky part because the major vendors have turf to protect -- from one another as well as from more nimble competitors.