- Generate, cache, and deliver WSDL documents that expose published methods for various packages.
- Bridge the execution of a package's published functions to the SOAP RPC specification
Packages that wish to scale to enterprise solutions would publish methods designed to facilitate the type of connectivity required by existing systems. Consider the burden of payment processing performed by the payment gateways that accompany OpenACS. Would it not be beneficial to have a passive payment processing paradigm on the OpenACS side requiring an external payment processing mechanism to accumulate and execute pending payments? Another example would be the synchronization of a product line maintained in a retail application to the products listed in an ecommerce application.
I wish I had the time and expertise with OpenACS to develop a SOAP package. Unfortunately, I'm still on the outside looking in hoping to improve my OpenACS skills each day I uncover another nuance of its being. Perhaps a coordinated effort by a few experts may yield a suitable package that would provide some basic SOAP gateway functionality. We use SOAP extensively in proprietary solutions and we don't require all facets of things associated with SOAP such as UDDI. On the other hand, we conform to the WSDL spec even though that's not completely necessary if stubs are manually crafted.
I don't know...
... what do you think.