I may state something pretty obvious here, but maybe there is also an
easier way to solve it than what I have done so far.
Assume I want to develop a backend application that delivers an XML
document over a web service interface. Technically, it doesn't really
matter to me whether this is described in WSDL with rpc or document style -
in essence, though, it is a document style service, so that is what I will
use, with literal encoding. Performance is very important in my case, and
let us just assume also that my backend application has no need to parse
the XML document. It simply returns it as a data stream, or, say, as a
string. Most importantly, I want to avoid using DOM.
I implement my backend application in Java, using a JavaBean, for example.
This JavaBean has one method, which returns a String object: the XML
document. At the same time, I want to describe to my clients what schema
the XML document will follow. After all, it is a document style web service
that returns an XML document, and I want to add a description of this
document to my WSDL definition. The fact that I implement this on the
server side in a JavaBean that does not use DOM to parse its data is an
implementation detail.
So, how do I deal with this in Axis? If I start with a WSDL definition and
generate Java code from that, it will generate DOM-based Java objects from
my schema. If I generate WSDL from Java, it will not add the appropriate
schema to WSDL (because all it sees in the Java method is the returned
String). Thus, the only thing I can do is to create all this manually. I
copy the schema into the WSDL file and manipulate the code so that it
directly stores the String that is returned from the Java method into the
SOAP envelope.
Isn't this a pretty common problem? the Axis tooling seems to always assume
that I want to use Java objects as representations of my XML documents,
using DOM to turn one into the other. This is slow, and in many cases not
necessary at all. Or am I missing something here?
Andre Tost
