Groove Web Services, aka GWS, is a feature of the Groove platform, new in version 2.5. GWS provides a standards-based interface to the Groove application: rich decentralised shared spaces, and their complementary infrastructure (identity, messaging, presence). That interface is SOAP over HTTP.

The name "web services" is specific and accurate, but also might be misleading. Most web services can be characterised as "network services that are very far away, and owned by strangers.". The SOAP activity in the Java world seems to reflect this: there are great toolkits for building server-based SOAP sources and sinks. Ditto, to a large extent, for the .NET environment. GWS inverts this: Groove.exe is the web server, it's very close (on the same machine as the "client" application), and owned by you.

GWS also supports remote access, but right now this is in "preview" mode, for some good reasons. Remote access to Groove presents some fascinating technical challenges: my main Groove account (which is the SOAP webserver) is spread over three machines, all behind firewalls, and usually at most two will be running at the same time. So the remote access to GWS is routed SOAP. And, unlike local GWS, there's not a secure channel (authenticated and confidential) from one end of that route to the other. All that will appear in the future, but for now: GWS == localhost access.

I started dreaming of some great remote-access applications -- picture sharing is my standard example; but I'm deliberately ignoring those use cases at the moment. For commercial users, I think the set of cases where you want to enable remote GWS access (and by doing so, compromise the security of your Groove environment) is vanishingly small. Defer.

Local SOAP
The uses for GWS, then, involve loosely-coupled applications on the same machine. Desktop software talking to Groove, using HTTP.
If you have a desktop application already, there will certainly be places it can leverage Groove and vice versa. Tim Knip's Radio Userland interop tool is a great example. There are plenty more – after all, even the humble spreadsheet was imagined as a collaborative tool, as Bob Frankston recounts:

As Dan described the product I envisioned a group of people sitting around a table with small devices pointing at a screen. Each had the ability to draw on the shared screen with graphics and formulas. The formulas would be recalculated as needed. This seemed reasonable give the technology of the day

For my spare-time hacking, though, I was missing some direction; I don't really have a stake in any desktop applications. Much of my working life is spent using Visual Studio, Word, Notes, and so on, but I don't want to build out a production-ready tool (like, say, co-debugging) just to explore web services. But then: why integrate with an application, when the desktop itself is scriptable with my favourite tools?

Oh yes. My first programming experience was with a powerful shell language (Prime CPL). Windows 95 reinvented the shell script concept, and the script was DHTML. XMLDOM and Javascript. And that magic pair, I know well.

Data structures
I gotta admit, I think file-sharing is really boring. You call that collaboration? When documents are done, they're background – knowledge, perhaps, but not collaboration.

I'm much more interested in how the "doneness" happens. Means, not ends. Some of those means have rules, structure, process and procedure, but those structures themselves tend to be seen as a sort of "doneness", where in practice the end will never arrive. Applications evolve, and cooperative groups need environments which will carry that evolution along with the group's changing needs. Excel, Notes, SharePoint, and the Groove forms tool are all quite good examples of evolvable application environments.

But I digress. The current GWS implementation gives you quite rich access into Groove-land: you can open and interact with your account(s), identity(ies), contacts, shared spaces, and the contents of those shared spaces. But the interaction with space contents isn't very complete: GWS in Groove 2.5 talks to the Discussion, Calendar and Files tools only. All the other core tools – of which I think chat and forms are probably the most important – are still to be done. (Tim has proved that you can build your own GWS services for custom tools, but I won't be following that path for a while – too much like work!). Of the three core tools, then, file sharing is actually quite important.

So over the past few evenings and weekends, I started playing with GWS integration with the filesystem, using the lowest-possible technology: shell script (XMLDOM and JavaScript). I've got to the point where some interesting things are possible, and more possibilities become interesting.