Groove Web Services
A quick overview of Groove Web Services (GWS), before EDB, I think.
The primary programming interface to Groove nowadays, apart from writing script inside of the Forms tool, is to talk SOAP. (I've written about Groove web services in the past, but not for a while - all my old links are stale). To get started, you'll need Groove, and the Web Services Development Kit (2.6MB EXE).
When Groove is running on your PC, it's listening for SOAP requests -- usually on port 9080 (although if another application gets that port before Groove starts, it might be something else). Yes, Groove is a local web server, albeit a very specialized one. (Note that by default, Groove only listens for requests on localhost - it's possible to enable remote web services access, so other machines can call into your Groove device, but that turns out to be quite an unusual situation -- we'll cover some of the use cases when talking about EDB).
The web service lets you address various Groove facilities at URLs underneath the root. For example, the Accounts service is at http://localhost:9080//GWS/Groove/2.0/Accounts, the Spaces service at http://localhost:9080/GWS/Groove/2.0/Spaces, and so on. Each service has a unique URL endpoint, and the SOAPAction specifies the action you want to perform: create, read, update, delete and so on. This makes for a fairly REST-like and very "regular" development model; once you've used one service, it's very straightforward to see how to call the other services too.
The development kit consists of WSDL and XSD, several samples (in C# and perl), and documentation. It installs usually into Program Files\Groove Networks\Groove Web Services Development Kit\. If you're building an application using Visual Studio .NET, you can just add the WSDL to your solution as web references (from the local disk path). To build the samples, you should refresh each of the web references, just in case they moved. We don't currently have samples for Python or Java or other environments, but the interfaces are the same.
What can you do with the GWS APIs?
- Create new Groove workspaces (empty, or from an existing template or archive); create an archive or template from an existing workspace; add tools to existing workspaces; create new entries within the Files, Calendar, Discussion and Forms tools;
- Create (or forward, or reply to) Groove instant messages;
- Create and send workspace invitations (or create invitation-files, which you can send by email or deliver via a Web page, for example);
- Read: enumerate the Groove accounts, identities, contacts, messages, workspaces, tools, members, files, Discussion entries, Calendar entries, Forms records, including rich-text field content and attachments;
- Update or delete most tool data;
- Subscribe for events, so your application is notified when interesting things happen (when workspace members enter or leave a space or tool; when new members join a workspace; when a new workspace is created or deleted or renamed; when tools are added or removed; and when data changes in a tool);
- Using the "local" web service: execute objects from a Files tool; navigate the Groove UI to a particular place; open various Groove dialogs, such as the Contact Properties, the Create New Workspace wizard, and so on.
So that's a reasonably complete set of actions against most of the interesting parts of Groove. There are a few restrictions you'll notice too; it's not possible to create a new Groove account programmatically, or to manipulate the design elements of a Forms tool (only the data). But the spectrum of possible applications is quite large. In nearly all the usage scenarios, Groove is running on a user's machine, and an external application running on the same machine (custom-built, or with GWS code as an addin to some existing application) reaches in to Groove's workspaces, to provide data integration, or to use Groove's synchronization facilities as a collaborative service layer in that application.
For large-scale data integration, you don't often want to run the integration application on each user's own machine. Which is where EDB comes in.
