Extending Groove

HOW DO YOU PORT 5 million lines of Win32/COM code to the Pocket PC? That was the dilemma that Groove Networks faced when considering how to bring its ultrasecure peer collaboration technology to mobile devices. Jamming 10 pounds of potatoes into a one-pound sack wasn't an option, but lateral thinking yielded a new plan: Don't port; use Web services as integration glue. Thus was born the skunkworks project first dubbed "edge services" and now known as GWS (Groove Web Services).

The first release, due later this year, will wrap SOAP/WSDL interfaces around the core elements of the Groove architecture: accounts, identities, contacts, shared-space membership, and presence. It will also encapsulate the most common tools used in shared spaces: Discussion, Files, and Calendar. To export access to these Web services, a SOAP server runs alongside the Groove client.

A SOAP client running on the same machine can hit these services directly. A remote client will reach them through a gateway that, like Groove's existing relay server, provides queuing and through-the-firewall connectivity. In the first release, the Groove security model will not extend to SOAP clients. Remote use of GWS will therefore be considered a developers' preview. Phase two of the project, due next year, aims to leverage the WS-Security framework to authenticate users and devices, and secure the SOAP traffic. That's also when SOAP interfaces will be provided for Groove's messaging subsystem and for more tools, including Projects, Meetings, and Forms.

It might seem disingenuous of Grooveto claim that the first release of GWS -- secure because it's confined to the local machine -- will be "production ready." In fact, the first and best use of GWS will be to empower .Net programmers or Java programmers, as well as scripters using Perl, Python, and Ruby, to interact with shared spaces, combine them with other local and remote data, display Groove information to the local user, and push it out to destinations such as enterprise portals.

The GDK (Groove Development Kit) is optimized for professional programmers who create polished tools that plug into the Groove transceiver or who splice Groove DNA into other commercial applications. There hasn't been an easy way to do simple things such as adding a Groove presence indicator to a directory on the company intranet. Solving that kind of problem is, on balance, an even more vital mission for GWS than downsizing Groove services for PDAs.

"There hasn't been a way to add just a little bit of Groove to something else," says Jack Ozzie, vice president of development.

Once the project got rolling, it became apparent that GWS could help solve quite a few problems. Groove's failure to support non-PC devices wasn't the only barrier to Groove adoption. Even in Windows environments, "mandating the Groove client can be a nonstarter," GWS project manager Matt Pope admits.

For some major customers, the ability to expose Groove functionality outside the transceiver is a key requirement. Broader awareness of shared-space activities is another. Groove's shared spaces are, by design, invisible to the uninvited. The enterprise support in version 2.0 empowers corporate IT to enumerate shared spaces, and see the managed identities and tools within them. But meetings and discussions that are not necessarily private, and so ought to be serendipitously discoverable, are still not easy to find.