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
Received on 2008-07-30Z07:18:33