Definitive version of the VOTable schema for web services

[Guy Rixon]

Hi,

in the AstroGrid codebase, we have SOAP code generated by toolkits  
that does what Ray suggests. For the registry, we have client stubs  
generated by Axis that return Document objects and in the registry  
service we have the matching code generated by XFire.

All this works, but gets into memory trouble with large amounts of  
data; I expect the object-bound approach would fail in the same way  
in the same cases. To allow arbitrary structures  in the SOAP  
messages you need a toolkit (or custom code) that streams the XML:  
SAX or TrAX. I believe that XFire can do something with TrAX; Kevin  
would know more.

I believe that putting VOTables a la TAP output into SOAP messages is  
wrong, not because the schema is difficult, but because the SOAP  
toolkits generate wimpy code that can't handle the big messages. It's  
a trap for naive authors of clients. This was a big driver for  
turning UWS into a RESTful protocol.

Cheers,
Guy



On 30 Jul 2008, at 06:18, Ray Plante wrote:

> Hey Gang,
>
> If I might jump in here...IMHO, one deficiency of these code- 
> binding toolkits is that they are very much oriented around an RPC  
> view of the remote call.  However, when we send VOTable (or  
> VOResource) what we need is a document-view of a remote call.  That  
> is, we send a document as input and we get back a document as  
> output.  (I believe this is the semantic idea behind "doc-literal",  
> which most of our services use.)
>
> In a document approach, what we need from the toolkit is to be able  
> to pass in our XML document in some form (e.g. as a DOM or as a raw  
> XML stream) and get out the XML document back (sans SOAP  
> envelope).  (Or have an RPC approach to input and a document view  
> of the output.)  This way you still can have the typing benefits  
> from the WSDL.  A document-based view is better for VOTable and  
> VOResource because we have *easier* ways creating and ingesting the  
> content than the thoroughly laborious, auto-generated class  
> interfaces.
>
> Axis actually does give you this:  you can get the contents of SOAP  
> responses as an array of DOM Elements.  At that point, you can use  
> any number of generic XML tools on the data, including (often) a  
> custom parser.  This capability of Axis is not as flexible as I  
> would like; however, I suspect that it's not often used because  
> developers are not really aware of this.  Tutorials tend to push  
> the code-binding approach.
>
> I'm less aware of where other toolkits fall.  (.Net has this  
> capability, too.)  I was once a big fan of code-binders, but now  
> I'd rather avoid them.  Nevertheless, other people like them and  
> use them.
>
> cheers,
> Ray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3006 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/grid/attachments/20080730/721860f5/attachment-0009.bin>