In preparation for the upcoming launch of Groove Web Services, we've made our wsdl and xsd files available on our public server. This will give those of you who are eager to start looking at the product a chance to see how our APIs are designed. You can now read all about it on the Groove DevZone. (Note the new Groove Web Services section there).
One thing you might notice right away is that there is no specified endpoint for any of the services. There are a couple of reasons for this. First of all, GWS can be accessed from the desktop over localhost, or from a hosted GWSAP (pronounced G' What's Up!). But a more important reason is that most of the service endpoints are dynamically discoverable by the client application. Many of our data structures have a field that is the endpoint URI for another service, and that endpoint URI is dynamic and depends on the context. For example, when I read my list of accounts the data structure contains an array of identities:
The identity descriptor has a field called "Spaces" and the value is the service endpoint URI for accessing those spaces. This style is what we've been calling REST-ful SOAP and was influenced by our work with Peter Drayton. I'm reluctant to even use the term REST because I'm sure REST people will be quick to point out why my API is not REST. And that's fine. The point is that we have heard what the REST folks are saying about SOAP and we would like to embrace those principles as much as is possible with today's toolkits. When we move to SOAP 1.2 we can do even more in this area. SOAP and REST are not opposites and the endless debate of REST vs. SOAP is somewhat pointless. I wonder if its all just a confusion stemming from using the word "Web" in Web Services. To some, the Web means http://www. To me, the Web means a bunch of computers connected together all over the world that everyone can use. We're on the verge of a new frontier of interoperable distributed applications. We're virtualizing the Internet. We're going way beyond databases and documents. And its all good stuff. To Dave's point, there's a big difference between theory and reality. We're building a real product that we can use and that solves real problems today. Yes, I can design a more efficient API that uses my own xml format. But the point of SOAP is interop. Can a SOAP API embrace some of the key concepts of REST? Why not? There is no right or wrong here. There are choices.
Naturally, what interests me the most is not how the API is designed (although this was great fun and I'm quite proud with how it turned out), but what developers will be able to build with this toolkit. As I see it there are two distinct paths that a developer can follow. The first is to use the WSDL interfaces to build applications that can move data in and out of Groove, or provide access to Groove data from a remote application. To use this API a developer needs no prior knowledge of the Groove COM API. The second path is to use our COM API to add Groove Web Services functionality to custom Groove tools. In fact, all of our services use this public COM API for their implementation. While our toolkit doesn't have the ease of use factor that you might find in VS.NET or others, it is very flexible and powerful. Services can be written in C++, or any of our supported scripting languages. Services can use a high level abstraction where method paramters are automatically marshalled from a SOAP envelope to a COM function call, or a lower level API that lets the service get at the raw XML as it came on the wire and have at it. Its even flexible enough so that if you don't like our service implementation for an existing Groove tool you can write your own!
I also want to acknowledge the hard work of my team members, Weidong Wang and Adrian Popescu. I'm very proud of what they have accomplished, and I hope they are too. Congratulations guys on acheiving this important milestone. Huge thanks to the Groove Core Engineering group, Developer Services, QA and marketing teams. Of course I'd also like to thank Ray Ozzie for believing in the project and giving me the green light, Jack Ozzie for his never ending enthusiasm and support and of course Matt Pope for pulling everything together and making this project a reality. It just keeps getting better!
Now, go play with my WSDL. I can't wait to see what you all come up with.
