Best practice for complex standard XML support via WSDL/SOAP interface

[chriscorbell]

I have a question about best practice for using complex XML as input
or output to a WebService in a Jax-WS, Axis or similar SOAP stack.

I want to have some webservice methods that either take or return a
complex but standard XML format. An example might be a scientific
service that can export MathML, or a financial app that can accept and
return a subset or particular taxonomy of XBLR. The difference
between this and "normal" webservice params or return types is that
there's no expectation that the SOAP stack understand and transform
these XML formats as it would for JAX-WS-annotated POJO's, or XML
Schema <type> and <message> declarations in the WSDL.

An obvious approach is just to use an xs:string parameter or return
type (and String Java type) and put the unparsed XML in; presumably it
will just be treated like any other unparsed string, angle brackets
will be escaped for transport and reconstituted on the other side,
then client or server can parse the string contents as XML.

Is this the standard way to provide this type of integration with a
complex but standard XML format where the application (not the SOAP
stack) is responsible for parsing?

TIA,
Chris

 

[Joseph Kesselman]

The standard way to encapsulate XML within other XML is just to embed it
directly as XML document content, rather than trying to escape it and
having to run a second parse over it. That does require that the
enveloping XML be sufficiently flexible to accept the "foreign" XML
elements at the appropriate point.

 

[chriscorbell]

The standard way to encapsulate XML within other XML is just to embed it
directly as XML document content, rather than trying to escape it and
having to run a second parse over it. That does require that the
enveloping XML be sufficiently flexible to accept the "foreign" XML
elements at the appropriate point.

Thanks Joe.

I agree that you describe a central pattern of XML and certainly the
design of XML Schema supports your suggestion. And WSDL, by
supporting XML Schema, lets one declare aribitrary XML types as valid
content, and bind those types to message parameters in the body of a
SOAP message. But a restriction on the overall implementation
involving the libraries mentioned is that these defined types are
typically mapped concretely to relatively fine-grained Java objects
(as method parameters or returns) by Jax-WS or Axis, and what I want
is for the payload XML in the third-party format to come through as
unparsed text - I don't want it mapped to fine-grained Java types or
objects.

To put it another way, I'm not trying to define an XML message format
that combines features of the envelope with logical structures from
another schema; I'm trying to send an opaque XML payload in the
envelope, but I don't want the tier which handles the envelope to
effect any parsing or transformation on that payload. The goal is not
to extend one XML structure with another here; it is to put a chunk of
XML payload in an RPC parameter or return; it just so happens the RPC
stack also happens to use XML.

So I'm really asking a very specific question about using externally-
defined XML payloads in these kinds of SOAP webservice tools and
applications, not a general question about XML. With the popularity
of Java EE webservices with Jax-WS etc. and XML standards like XBRL,
MathML, etc. I'm hoping there's someone out there who has tread this
path.

TIA,
Chris

 

[Joseph Kesselman]

I'm trying to send an opaque XML payload in the
envelope, but I don't want the tier which handles the envelope to
effect any parsing or transformation on that payload.

If you really want to just send text and worry about possibly parsing it
as XML later, you can certainly do that by escaping it appropriately,
either on a character-by-character basis or by using CDATA Sections, and
any properly written XML API should be able to help you convert it into
and out of escaped form.

For that matter, if you want to just send _data_ and not even worry
about whether it's text, you could base-64 encode the bytestream.

.... But I think you're out of the realm where there's a clear
best-practice. What's optimal will depend on the exact characteristics
of how you're going to process this info and what other kinds of
payloads you might need to support in the future.