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).

Groove Web Services
|
 |
Executive Summary: The forthcoming GWS (Web Services) initiative will wrap SOAP and WSDL interfaces around Groove's core functions and tools,
allowing formerly disenfranchised people, devices, and applications to connect to Groove's peer collaboration services.
Test Center Perspective: Originally designed to deliver Groove services to resource-constrained devices, GWS is poised to help solve several other
problems that have plagued the Groove platform. It's also shaping up to be a model implementation of a Web services architecture
that respects the Web's core strengths.
|
 |
|
|
|
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.