Delegate interfaces vs. stubs vs. XML interfaces

[Wil O'Mullane]

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