Another WebService returning VOTable

[Wil O'Mullane]

actually now that I think back the SdssCOne is a webservice which uses
the HTTPget since thats what the protocol demands so you may also try

http://skyservice.pha.jhu.edu/devel/ConeSearch/sdssConeSearch.asmx?wsdl

also returns VOTable ...


On Fri, Dec 12, 2003 at 09:09:51AM -0500, Wil O'Mullane wrote:
> May I suggest someone points ther java wsdl2java at something like 
> 
> http://skyservice.pha.jhu.edu/devel/CasService/CasService.asmx?wsdl
> 
> it returns a VOTable from 
> GetVOtable
> 
> Pass it sql like 
> 
> select top 10 * from galaxy
> 
> 
> That will give yo a VOTable set of Java classes and you 
> will not have to parse the result ...
> 
> 
> wil
> On Fri, Dec 12, 2003 at 10:18:00AM +0000, Guy Rixon wrote:
> > The question was raised at an AVO meeting "for a web-service that returns a
> > VOTable can the service return a Java object so we don't have to parse the
> > VOTable?"
> > 
> > Well, the web service itself is defined to return XML, so it will return
> > VOTable; it can't return Java directly. In any case, a public service needs
> > to support clients in many languages.
> > 
> > The conversion from VOTable to Java _has_ to be done in the client, but there
> > are three ways to do this:
> > 
> >  - make the author of the client application write the parser;
> > 
> >  - have the service publisher supply a stub that does the parsing;
> > 
> >  - have the service publisher supply a delegate that does the parsing.
> > 
> > Both stubs and delegates are classes in the programming language that provide
> > the function of the XML interface. They do serialization of objects to XML and
> > deserialization of objects from XML to the programming language.  Stubs
> > and delegates are both compiled into client programmes. Stubs
> > and delegates operate at different levels of abtraction.
> > 
> > Stubs are low level.  They match the XML interface closely.  Typically, a stub
> > has one object method for each operation in the XML interface. Arguments and
> > return values of methods in the stub may be objects; the stub maps these to
> > XML fragments in the XML interface.  Stubs are usually generated from WSDL by
> > tools.  I.e. the inteface of a stub is usually fixed by the XML interface.
> > 
> > Delegates are high level.  They are usually hand-coded.  The methods in a
> > delegate class don't always map one-to-one with operations in the WSDL.
> > Arguments and return values of delegate classes don't always map trivially to
> > the structures in the XML interfaces.  I.e., the interface of the delegate can
> > be tuned to help the author of client applications.
> > 
> > A delegate can be written to call a stub.  This lets the delegate use the
> > tool-generated code in the stub and hence to be simpler.
> > 
> > Stubs are hard to produce and use when complex data structures are being
> > exchanged. They work best when all the objects that are arguments or return
> > values are Java beans (or the equivalent in other languages): these can be
> > serialized to and deserialized from XML by standard libraries.  The fall-back
> > position is to have the stub return a DOM: i.e. to do only the lowest level of
> > parsing of the XML.
> > 
> > Trying to generate stubs for services that return VOTable is going to be hard.
> > For the use case in the original question, it seems sensible to provide a stub
> > that returns a VOTable as a DOM and then provide a delegate that calls the
> > stub and returns the VOTable as an object, using a VOTable-specific parser.
> > 
> > AstroGrid provides delegate classes in Java for its services, and these are
> > typically based on Java stubs made with Apache-Axis. Authors of applications
> > in other languages can still used the published XML interfaces in their own
> > stubs and delegates.
> > 
> > The XML interfaces remain the definitions of the services.  Stubs and
> > delegates are just helper classes to make things easier for authors of
> > clients.
> > 
> > Guy Rixon 				        gtr at ast.cam.ac.uk
> > Institute of Astronomy   	                Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523