Don, I'm not suggesting we expose all of OpenACS service contracts through Web services. The package I'll be working on will produce a list of all registered service contracts, and you can select which contracts you would like to expose as a web service. A tool can take these service contract definitions and create a WSDL file that describes bindings to these service contracts as end points for Web services.
Service contracts allow OpenACS packages to implement plug-ins in a standard way, but we can leverage this with Web services to plug OpenACS into other systems. In the dotLRN space, courseware or learning objects can be shared between systems. In the project management space we can have a service contract for importing data from other packages, but can expose this as a web service to also import data from 3rd Party project management applications.
Instead of having to rewrite code to publish a web service, which is currently being done, we can use existing interfaces such as service contracts which clearly specify an interface of how a package should be used.
