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

Collapse
2: Re: Which version of xotcl-soap (xosoap) should I use? (response to 1)
Posted by Tom Jackson on 12/27/07 08:43 AM
Do you want to also serve web services or just consume them?

I've written a WSDL server which works with OpenACS, called tWSDL. The server API is called TWiST and works pretty well. I've started working on the client API, but a decent client is much more difficult than a server. In addition, most servers use RPC/encoded, which is unfortunate. The tWSDL client will probably only work nicely with document/literal. As an example, the Google Search API is RPC, but Google's AdSense API is document/literal. Document/literal is considered to be significantly faster and programming language neutral.

However, tWSDL/TWiST has lots of helper procs which can be used to build a client. In fact, the TWiST server has a testing feature where a web form takes inputs and converts them into a correct client request. This is posted back to the same server, and both the request and response documents are shown. This is essentially what the ASP.NET server does, if you have ever seen that work. Significantly, tWSDL/TWiST can perform true validation of entire documents (either request or response) These validation services are independent of the other system components. You can test this with the examples below by supplying invalid data.

Here are some test services:

http://junom.com/ws/

There is a thin OpenACS package which can be used to download and install the releases from Google code:

http://code.google.com/p/twsdl/downloads/list

The OpenACS package should work, although you need svn installed.

You can more easily browse the source, or get a slightly more up-to-date version at

http://junom.com/gitweb/gitweb.perl?p=twsdl.git

If/when the client is finished it should work with pure Tcl, in fact, I recently got the server to work without AOLserver by writing a thin replacement for the ns_conn/ns_return API (it still requires nstclsh).

I'm not suggesting either, but it makes testing easier.

Collapse
4: Re: Which version of xotcl-soap (xosoap) should I use? (response to 2)
Posted by Justis Peters on 12/27/07 05:54 PM
Tom,

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

Collapse
9: Re: Which version of xotcl-soap (xosoap) should I use? (response to 4)
Posted by Stefan Sobernig on 12/27/07 07:03 PM
Justis,

Most of the applications we need to consume provide decent WSDLs and run on Axis

Provide me with the wsdl descriptions of these (or some) of the services. I might be able to give you some pointers to get started realising consumer proxies in xosoap.

//stefan

Collapse
7: Re: Which version of xotcl-soap (xosoap) should I use? (response to 4)
Posted by Tom Jackson on 12/27/07 07:54 PM

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.

Collapse
11: Re: Which version of xotcl-soap (xosoap) should I use? (response to 4)
Posted by Justis Peters on 12/27/07 11:29 PM
Tom and Stefan,

Thanks for the offer to give an opinion based on our actual WSDLs. I'm pretty excited about getting opinions from people who have first hand experience with the complexities of implementing SOAP clients against existing WSDLs. We're trying our best to pick a tool that will work for most of our needs. Once you consider that we may need to upgrade OpenACS versions in order to get XoTCL, it becomes a pretty large decision. We have a decent amount of code which differs from the core, so upgrading is not trivial. Even if it involves upgrading, though, I'd like to go with the right tool. Opportunities to integrate applications via SOAP seem to be around every corner. I'd like to capitalize on as many as possible and having the right tool is key.

There are 3 tools where we currently want to consume their web services from within OpenACS: JasperServer, Corticon, and Intalio. I have example WSDLs from all 3, but pasting them in here would make this a very long thread. I'm new to the forums and don't exactly know the accepted etiquette here. Is there a way to post these as attachments? Should I email them to each of you? Should I just post them?

Thanks in advance for the help. I sincerely appreciate the offers.

Kind regards,
Justis

Collapse
12: Re: Which version of xotcl-soap (xosoap) should I use? (response to 11)
Posted by Tom Jackson on 12/28/07 12:13 AM
I would email them to both of us, if Stefan wants them that way.

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.

Collapse
13: Re: Which version of xotcl-soap (xosoap) should I use? (response to 12)
Posted by Justis Peters on 12/28/07 12:45 AM
Tom,

I emailed them to both of you. Thanks again for the help.

Kind regards,
Justis