Extending Groove

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

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.