Delegate interfaces vs. stubs vs. XML interfaces

[Guy Rixon]

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