I'm posting an update on the progress I made with the SOAP implementation I discussed in previous threads.

Preliminary R&D has provided the ability to use the Microsoft Toolkit, for example, as a SOAP client of my OpenACS install:

' This example shows VBScript InterOp

' Create SOAP object
Set Stub = CreateObject("MSSOAP.SoapClient30")

' Specify the WSDL document containing functional spec
Wsdl = "http://my.server.com/soap/wsdl?my-package"

' Specify the namespace of ops within spec ???
Namespace = "http://MyPackage.openacs.org/wsdl/"

' Initialize SOAP stub
Stub.MSSoapInit2 Wsdl, "", "MyPackage", "MyPackageSoapPort", Namespace

' Invoke Tcl method on OpenACS server
MsgBox Stub.GetLoadedPackages

' Invoke another Tcl method on OpenACS server
MsgBox Stub.GetPackageVersion("ecommerce")

A WSDL file is automatically generated by the soap-gateway package installed in the openacs server. Admin pages are used to configure published functionality. I'm using a native 4.6 install and nsxml (i.e., no tDOM). Based on my current schedule, I don't expect to publish anything until the end of November (I'm very busy.) The implementation will be relatively lightweight; though, effective. I'd like to reserve the package name 'soap-gateway' if possible. I'll post more info if anything should develop sooner.

Excellent news Byrne! I am also looking forward to using your work.

Holy smokes. Excellent. I'm looking forward to this!

Whenever we can see something would be great! (Not to nag...*grin*)

A little history is in order.

my need...

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.

my experience...

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.

my opinion...

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 else’s 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:

1. server side interfaces – these are, in effect, published Tcl procs that are administered by the soap-gateway I’m developing. The published procs would optionally call upon other services within the server.
2. 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 (I’m NOT referring Tcl namespaces) are an important component of the WSDL spec. and are also administered via the soap-gateway. I’ll make recommendations in the admin pages. Details will be made available in the package that I intend to release in a month (or two.)
3. 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. It’s 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.
4. HTTP payload ingest (server side) – using nsxml, the incoming SOAP envelope is parsed and decoded into a Tcl expression. Here I’m using a subcomponent that accompanies the OpenACS dists. I feel this is advantageous.
5. evaluation – the published Tcl proc is executed
6. return path – a SOAP response is constructed from the Tcl evaluation and returned to the caller.

So, that’s basically it… and it’s 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 I’m not concerned with them right now; however, they’ll 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 another’s SOAP solution.