Forum OpenACS Q&A: Re: Which version of xotcl-soap (xosoap) should I use?

I've already read quite a bit of what you've written on the forums about tWSDL/TWiST and I'm pretty interested. Our priority at the moment is to consume web services and that seems to have been the second priority on your development. Most of the applications we need to consume provide decent WSDLs and run on Axis. Do you think it's worth a look? We're currently evaluating xotcl-soap because it claims to already compile remote WSDL and work with Axis implementations. It also coincided with my supervisor's efforts on evaluating OpenACS 5.3 and xowiki, so it seemed easy to combine efforts. I'm certainly open to suggestions, though. Thanks for the reply.

Kind regards,
Justis

I think Axis is a good platform for web services, but it all depends upon who set it up. Many WSDL are written by hand or semi-generated based upon an existing API. This leads to services which are somewhat tied to the base language and the web service toolkit because they rely on mapping of programming language types and structures to an XML-Schema. You can only go so far with this concept, so client programming is very complicated in the general case.

tWSDL/TWiST takes a toolkit approach. There are many low level support API which are combined to provide the final user layers. The tWSDL client is similar. I have not taken the approach of solving a single problem. Instead I have focused on trying to create some reusable components for the inevitable variability in web service descriptions.

But this is all speculation at this point. If you have a link to a representative WSDL, or if you can email me a copy, I can tell you more. At the very least, tWSDL/TWiST can be used to generate API to easily construct and validate messages using simple Tcl lists as input. The lists are data only, you don't need to include the element names. This allows any method of constructing the input list, your internal API don't need to know about the XML structure.

For instance: http://junom.com/ws/stockquoter2/?op=StocksOperation&mode=display

If you put in multiple stock symbols, like MSFT GM, and 1/0 in verbose, the internal API gets called:

::wsdb::elements::stock2::StocksRequest::new $someNS {{MSFT GM} 1}

This generates the StocksRequest message:

  <StocksRequest xmlns="http://junom.com/ws/stockquoter2">
   <Symbol>MSFT</Symbol>
   <Symbol>GM</Symbol>
   <Verbose>0</Verbose>
  </StocksRequest>

In response to this message, the internal API returns a list of StockQuotes like this:

::wsdb::elements::stock2::StocksResponse::new $someNS {{MSFT 27.44} {GM 26.77}}

Which generates this message:

  <StocksResponse xmlns="http://junom.com/ws/stockquoter2">
   <StockResponse>
    <Symbol>MSFT</Symbol>
    <Quote>27.44</Quote>
    <Name xsi:nil="true"/>
   </StockResponse>
   <StockResponse>
    <Symbol>GM</Symbol>
    <Quote>26.77</Quote>
    <Name xsi:nil="true"/>
   </StockResponse>
  </StocksResponse>

Note that the caller doesn't need to know anything about the handling of missing elements. These are filled in by the new procedure which is based completely on the XML-Schema type definition.

If they are public documents, you could also just give the url here. Also, if they are public, I can post them in my website documents area so others can get them, and even test against them (they'll be served as xml).

Your choice either way.