A little history is in order.
My approach to a SOAP implementation in OpenACS began as a selfish one. I want to tie an existing business app with the ecommerce package provided by OpenACS (a job on the side for family.) I spent a little time reverse engineering FORM POST ops to automate the web solution provided by ecommerce with the business app I wrote some time ago. After numerous hours of development, I concluded that connecting the applications, ecommerce & bus. app, in this fashion was ridiculous and a waste of time. What I really needed was SOAP/HTTP connectivity; yet, nothing was available on the required OpenACS platform.
One of the projects I manage at my real job is a Win32 service geared towards things related to broadcast television. The service controls graphics equip. and handles asset dist. The service exposes its functionality in a variety of ways one being SOAP/HTTP. The project has been under development for about 18 months.
We've been tracking the SOAP spec for some time. No one will dispute it's a work in progress. I concluded it's merely XML RPC. Early on, we discovered the irony related to the failed interoperability of diverse systems and tools that implement SOAP. We made an attempt to use emerging tools such as MS SOAP Toolkit and Axis; however, we quickly discovered that the cost in relying on someone elses implementation of new technology was too high in terms of release cycles and reliability (btw, the tools I mentioned are fantastic and should be given serious consideration for SOAP development.) Anyway, I decided we'll bite the bullet and implement subsections of the SOAP spec that meet our requirements. Our goal was to implement both the SOAP spec over HTTP and the WSDL spec. In the process, we gracefully acquired the taste for XML Schema.
my OpenACS implementation...
Given the need to expose OpenACS services to an external system, I became convinced that using SOAP/HTTP was the way to go. A few things are required to support the system as a whole:
- server side interfaces these are, in effect, published Tcl procs that are administered by the soap-gateway Im developing. The published procs would optionally call upon other services within the server.
- published WSDL docs the WSDL documents/specs are automatically generated from IDL definitions that accompany the published Tcl procs above. The docs are returned to a SOAP client using GET. Namespaces (Im NOT referring Tcl namespaces) are an important component of the WSDL spec. and are also administered via the soap-gateway. Ill make recommendations in the admin pages. Details will be made available in the package that I intend to release in a month (or two.)
- client tools - tools such as MS SOAP Toolkit & Axis provide client side connectivity to the service. These tools rely on the WSDL documents published by the soap-gateway. Its possible to grow your own client side SOAP factory. We did so in Java using dom4j. We found axis to be too expensive; however, we had a hard time letting go of it.
- HTTP payload ingest (server side) using nsxml, the incoming SOAP envelope is parsed and decoded into a Tcl expression. Here Im using a subcomponent that accompanies the OpenACS dists. I feel this is advantageous.
- evaluation the published Tcl proc is executed
- return path a SOAP response is constructed from the Tcl evaluation and returned to the caller.
So, thats basically it
and its really not that complicated. The first spin of the soap-gateway will only handle basic data types. In my view, this is ok since Tcl is a loosely typed language. Future revs would handle SOAP arrays that map nicely to Tcl lists. Complex types specified in XML Schema ultimately translate to nested Tcl lists. SOAP attachments are the offspring of recent SOAP spec revisions and Im not concerned with them right now; however, theyll be useful for uploading blob like things.
My goal is to get something working. And at the same time, give the OpenACS community something to poke at. The design I described has been roughly implemented and proven to work. I now need to formalize and provide a package with documentation for you guys to review. I view my SOAP implementation as a springboard package. Something that shows how it can be done. I would certainly not want my implementation to preempt anothers SOAP solution.