from Ian:

[This is the same thing I sent you before but with the middle paragraph
added to describe the WSDL/Schema/BPEL thing]

The Musing web services are standard SOAP web services. They take their
input as binary data - though the services are intended to process text
they can handle input in many formats including XML, HTML and PDF,
extracting the text from the source data using the format handling
mechanism provided by GATE. A service loads the input data into a GATE
Document object, then processes that Document using a GATE
DocumentProcessor (typically a saved GATE application), and returns its
output as RDF-XML.

All the services share a common WSDL interface as their inputs and
outputs are the same, only the underlying GATE application needs to vary
between services.  While the service infrastructure used is able to
produce any XML in any namespace, for better compatibility with the BPEL
orchestration tools used in Musing the WSDL specifies that the output
will be RDF-XML, and embeds an XML schema defining the
{http://www.w3.org/1999/02/22-rdf-syntax-ns#}RDF element.  For this case
we settled on a very simple schema that simply permits any attributes
and any child elements on the RDF element.  While there have been
attempts by others to produce a more detailed schema for RDF-XML to at
least cover the standard elements in the rdf-syntax-ns namespace, the
format allows 'shorthand' forms that can represent the same graph of RDF
triples with many different XML trees.  These shorthands use XML
namespaces in a somewhat unorthodox way and thus any schema ultimately
needs to allow any element or attribute at any level alongside its more
detailed definitions.  Given that our services make little use of the
full forms we chose to use the simpler schema.

[Note to Adam - is the previous sentence a reasonable thing to say?]

The various components making up the service implementation are
configured using the Spring framework, making it simple to slot in
alternative DocumentProcessor implementations for different services
without changes to the code.  The aspect-oriented programming tools
provided by Spring are used to allow pooling of several identical
DocumentProcessors, to support multiple concurrent web service clients.
The web service layer is provided by the Apache CXF toolkit, which
itself uses Spring extensively and thus was a good fit with the
Spring-driven architecture adopted for the business logic.