TclSOAP, a Tclpackage, provides method binding for Tcl clients to remote procedures and [web services] implemented using either SOAP, XML-RPC or JSON-RPC. The first two protocols package up a payload as XML and use HTTP to transport the data to and from the service provider. The last formats the payload as JSON. TclSOAP provides a means of binding Tcl procedures to the remote method and for creating RPC servers easily under tclhttpd.

APN 2008-07-05: TclSOAP now includes client side support for JSON-RPC.

PT 2003-06-26: As of version 1.6.6 TclSOAP supports SOAP1.1 and makes some attempts towards supporting SOAP1.2. The SOAP methods have a -version option which can be set to SOAP1.1 or SOAP1.2 or explicitly to the xml namespace required. You can also set the encoding in use using the -encoding option. Currently I'm not planning much work towards full 1.2 compliance.

WSDL is an XML dialect for describing services which are implemented with SOAP.

PT: as of 1.6.5 I've got some WSDL support in the development branch. Hopefully this will get merged into the main package before too long (say 2003-04?). The basic structure is likely to be that calling

[PT]: Not at the moment and perhaps never. I don't have any pressing need to support this extension and it isn't expecially interesting to do. I tend to be interested in communications generally (hence the SOAP and smtpd work). Of course, some sort of financial incentive will guarantee a rapid change of heart and ensure a place at the top of my work pile!!

Position: char[64], starting from upper left, ending to upper right, empty squares are spaces, universal chess notation (whites are capitals), whites are always down. You will have to send the position every single time you access the interface. For example, the initial position will be: "rnbqkbnrpppppppp {insert 4*8=32 spaces in here!} PPPPPPPPRNBQKBNR" (the spaces for empty squares are mandatory).

WhiteMovesNext: bool, defaulted to true.

SearchDepth: int, defaulted to 3, this would be the search depth of the Chess algorithm (please do not abuse the server, do not send values bigger than 5). The default value (3) stands for about 2100 elo... The thinking time growth is an exponential of the search depth

We can come up with a simple example of the white opening move in a chess game.

An alternative is to get a binary distribution like ActiveTcl, which contains all the necessary packages.

In the course of answering a question [3] about how to transmit content which is itself an XML document, TclSOAP author Pat Thoyts makes these points: "You should be fine passing in XML data. It will need to be quoted properly as per XML specs ie: < as &lt; etc.

DAF notes that some servers are not expecting this xml to be escaped, and throw their toys out of the cot when you send escaped xml. I've made a patch which makes the behabiour of TCLSoap more like that of Perl's SOAP::Lite in this regard. It basically introduces a parameter type xml which is treated differently from a standard string -- a dom document object is created, and the root node inserted under the named parameter in the SOAP envelope's body, for example:

I hope that my patch will be taken into consideration for the official TCLSoap package -- apart from this patch, the package did exactly what I needed, and was significantly faster than perl's SOAP::Lite.

Here is a brief example using TclSOAP and tclhttpd as the server. I run these commands under TkCon...

If you have problems you could always pack up the XML as base64 encoded data and send that instead."

The above code will only work for versions prior to 1.6. For newer versions you would create a tcl script file with the method implementation and place it into a directory. Then start tclhttpd, source tclserver.tcl, set the SOAP::CGI::soapdir variable and let rip. Also, newer code needs to be 'exported'. This is so that callers cannot execute arbitrary tcl commands like exec. PT

In a comp.lang.tcl posting, Pat explains that TclSOAP 1.6 includes new capabilities for "structure" transmission. He offers

There was a comment regarding problems with TclSOAP and why someone choose the Java SOAP instead recently on comp.lang.tcl .

PT: So stick in a link then! The reason they made this decision was at my advice. In September 2001 the package was still pretty new and only operated with Tcl-only versions of TclDOM. The relative sluggishness of Tcl for processing DOM trees combined with the CGI process startup for the naive implementation of SOAP services under CGI meant that they were better off using some other system for the server side of their application. You should node that they continued to use TclSOAP for the client side.

Since that time - fixes to the TclDOM C module (dom::c) have made it possible to use a significantly faster DOM processor. Changes to the method used to host the SOAP server side should also improve performance. For instance, using mod_dtcl with Apache or using tclhttpd would mean that there will pretty much no startup delay.

The TclSOAP site at http://tclsoap.sourceforge.net/ hosts some SOAP services - namely implementations of the SOAP Interoperability Lab Test Suite for round 1 and 2. You can test the relative performance of these services against other similar implementations. The server is Apache and using the C TclDOM but nothing has been done (yet) about improving the CGI handling.

If your services are going to be performance intensive I would still recommend using another SOAP toolkit (perl or easysoap++ maybe). However, if you want to generate some protptypes fast and/or flexibly the Tcl is always there.

CL adds: I'll emphasize again that it's ENTIRELY OK to use a different SOAP toolkit for servers than for clients. Tcl/Tk is way cool on the client side--download ActiveTcl, and you're completely ready to build nice clients. Tcl is less competitive for SOAP servers, in my opinion. Also, while I'm sharing my sentiments: Pat's done great work.

More on server-side SOAP work: even as of version 1.6.1, Pat agrees, "The client code is generally very easy to use but the server side stuff is much less so."

Specifically, "To run TclSOAP with tclhttpd there is a tclserver.tcl file in samples/ which can use the SOAP::CGI style setup and code within tclhttpd. It works but the server code could generally use a bit of a redesign to simplify things."

In Pat's summary:

source tclhttpd/bin/httpd.tcl
source tclsoap/samples/tclserver.tcl

are the best current documentation for server-side possibilities using tclhttpd.

PT: I'd suggest reading http://tclsoap.sf.net/SOAP-CGI.html for information on providing a SOAP service using TclSOAP. The example above is the current howto for providing SOAP services from within tclhttpd. This is not as pleasant an experience as it might be due to the reworkings I performed to get it working with CGI under Apache. The SOAP::Domain package was a nicer tclhttpd solution. In the near future I'm going to try and construct a better tclhttpd solution.

SC 2003-09-24: I was just looking at how to add an XMLRPC interface to giggle so that I could implement the blogger API for posting new messages. Currently giggle is a single library called via a simple main script, it handles all uris below it (eg. ../giggle.tcl/foo/bar) through simple CGI and packs nicely into a starkit. It seems from the SOAP::CGI docs that to add an XMLRPC interface I need to supply multiple files to implement the interface (of course these could be inside the starkit). What would be neater would be to be able to get the posted XML and pass it to a proc for interpretation having registered some already loaded procs as being available via XMLRPC. It looks like ::SOAP::CGI::xmlrpc_invocation almost does this -- except it does the sourcing of tcl files too. Would it be easy to provide this kind of entry point into the server side of tclSOAP?

The reason we have the re-sourcing all the time is to support CGI based services, where the whole lot is being loaded into a new interpreter for each call. What you are after is the tclhttpd support which is in the SOAP::Domain subpackage. At this time support for XMLRPC is missing, but either I'll get around to it or you could use the code in the SOAP::Domain package to fix the XMLRPC::Domain code.

The tclhttpd-style support is a much better solution than CGI-based -- but it just so happens that I have to use CGI for my services, hence we support CGI better than tclhttpd.

The ActiveTcl 8.5 series has a reduced set of packages installed by default. The package logger is in that set, uri is not. Any and all packages not installed can be installed by using the teacup repository client. Either

teacup install package-name

to install a specific package and its dependencies, or

teacup update

to pull everything which is not installed yet, or has a higher version number (= newer) in the repository.