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

Discussion in 'XML' started by chriscorbell, Sep 19, 2007.

  1. chriscorbell

    chriscorbell Guest

    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
     
    chriscorbell, Sep 19, 2007
    #1
    1. Advertising

  2. Re: Best practice for complex standard XML support via WSDL/SOAPinterface

    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.

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Sep 19, 2007
    #2
    1. Advertising

  3. chriscorbell

    chriscorbell Guest

    On Sep 19, 11:54 am, Joseph Kesselman <>
    wrote:
    > 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.
    >
    > --
    > Joe Kesselman / Beware the fury of a patient man. -- John Dryden


    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
     
    chriscorbell, Sep 19, 2007
    #3
  4. Re: Best practice for complex standard XML support via WSDL/SOAPinterface

    chriscorbell wrote:
    > 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.

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
     
    Joseph Kesselman, Sep 20, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Bedford
    Replies:
    0
    Views:
    598
    Chris Bedford
    Aug 21, 2003
  2. Guest

    Complex Object Support in SOAP

    Guest, Aug 5, 2004, in forum: Python
    Replies:
    0
    Views:
    293
    Guest
    Aug 5, 2004
  3. Author
    Replies:
    4
    Views:
    313
    Author
    Feb 7, 2009
  4. -P-

    Complex XML document via SOAP?

    -P-, Dec 20, 2004, in forum: ASP .Net Web Services
    Replies:
    4
    Views:
    246
    erymuzuan
    Dec 20, 2004
  5. Me
    Replies:
    2
    Views:
    444
Loading...

Share This Page