The fact that a SOAP implementation of a service is inferior to a service-contract is actually an advantage for our purposes. We're not trying to replace service contracts for OACS programmers; rather, we're trying to provide a useful subset of functionality for programmers who aren't ready to make the leap to learn TCL, etc. If, once they start using OACS through SOAP, they can see some benefits to programming in the native toolkit, then we gain another OACS programmer.
I don't know what service contracts actually exist or what they do, but at a minimum, it would be valuable to expose the following via SOAP:
- Permissions
- Access to the content respository
- Workflow
- The email notifications capaibilities
- Portal content
The first four provide basic building blocks for new apps while the last one lets developers pipe OACS apps into a more agonostic portal environment. I'm sure there are others as well.
