Extending Groove

Groove Web Services will allow PDAs and Web apps to share in Groove collaboration

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.

The current solution to this problem is to create a bot, install it on the Groove EIS (Enterprise Integration Server), and then invite the bot into a shared space. This is a good way to mediate securely between Groove spaces and external partners, but the activation threshold is awfully high for ad hoc internal integration. GWS should lower that activation threshold dramatically. And when secure remote access to GWS does become available, it promises to flip the model on its head. EIS pushes data to external systems, notes Jack Ozzie, vice president of development, "but with GWS, it's a reach-into-Groove model, which means your integration logic can stay where it belongs."

Developers will find GWS to be a textbook example of a style that has come to be called "RESTful SOAP." REST (Representation State Transfer) describes the architectural style of the Web. What that means for SOAP, as recommended in the W3C working draft for SOAP 1.2, is that interfaces should "use URIs [Universal Resource Identifiers] in a Web-architecture compatible way -- that is, as resource identifiers."

For example, the root of GWS is a SOAP service with an address like http://localhost:9080/GWS/Groove/1.0/Accounts. Since a Groove account is a container of identities, a Read operation on this resource produces an XML document that enumerates them. Each identity includes an element like /GWS/Groove/1.0/Spaces/grooveIdentity/123...xyz -- that is, the URI of the SOAP service that enumerates the shared spaces for that identity. Traversal of spaces, tools, and data proceeds in a similar fashion. It's all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete.

This exceptionally elegant and productive Web services API is a second try. The first version, which was set to debut with the release of Groove 2.0 in April, was much closer to Groove's internal API. Recognizing that it might not appeal to a broader audience, Groove sensibly went back to the drawing board. Peter Drayton, a leading Web services educator, was recruited to review and help redesign the schemas and WSDL interfaces. "This is a big thing," Ozzie says, "and we had to get it right." The results are nothing short of spectacular.

As we watched GWS technical lead John Burkhardt build a WinForms GWS client in Visual Studio .Net, we realized that we needed no further explanation to do exactly the same thing in wxPython on a Macintosh or in PHP on a Web page. "I've wanted a search service that will troll through my Groove spaces," Burkhardt says. "We've talked about building that into Groove, but now I can write it externally -- both quicker and with more flexibility." The proof's in the pudding, of course, but GWS's architecture lends much credence to the claim.

Note that Groove tools must still mediate GWS access to the core services. These tools are signed components, installed into shared spaces, that people (and now GWS clients) use to read or update shared-space data. GWS cannot reach directly into, for example, the RecordSet engine, to make direct use of the distributed XML object store. What's more, existing and new tools must be adapted for use with GWS.

However, as Pope points out, the existing "tool surface area," when exposed by GWS, will create a wealth of options. For example, GWS includes an event model, which means that a GWS client should be able to subscribe to change alerts issued by any GWS-aware tool.

Six months ago, at the O'Reilly Emerging Technology Conference, advocates of REST (Representational State Transfer) pointedly asked a panel of SOAP experts: "What does Web services have to do with the Web?" The blunt answer was, to paraphrase, "Nothing." As we noted then (see "Hyperlinks matter," http://www.infoworld.com/articles/pl/xml/02/05/20/020520pllinks.xml ), a linked web of XML documents is a potent architecture that Web services can and should exploit. Happily, GWS does.

Copyright © 2002 IDG Communications, Inc.