MTOM/XOP

Discussion in 'XML' started by Default User, Aug 16, 2006.

  1. Default User

    Default User Guest

    I'm working on a research and development project involving binary XML.
    I've been reading lots about the new MTOM and XOP recommendations put
    out by W3. I'm interested in trying to find a toolset that we could
    evaluate as part of this effort, so I thought I'd check and see if
    anyone has used or is otherwise familiar with such packages.

    What we need at this stage is:

    1. Open source. We just want to do concept work at this point.

    2. Linux compatible.

    3. The tech guy wants a Python API (although that looks tough). I'd
    prefer C or C++. I'm not a Java guy, but won't rule it out.


    I'm currently looking at gSoap:
    <http://sourceforge.net/projects/gsoap2>



    Tungsten has gotten some buzz, but I haven't looked at it much:

    <http://www.wso2.com/products/tungsten/>



    Another possibility:

    <http://docs.codehaus.org/display/XFIRE/Home>



    If anyone has feedback about these, or suggestions for other avenues,
    I'd appreciate hearing from you.




    Brian
    Default User, Aug 16, 2006
    #1
    1. Advertising

  2. Default User wrote:
    > I'm working on a research and development project involving binary XML.


    Binary XML (misnomer!) is not a recommendation yet; it's exploratory
    work. Past experiments have generally suggested that:

    1) The advantages of "binary XML" are less than a naive view claims.
    Zip-style data compression is better at saving bytes, and a good parser
    is surprisingly efficient -- even more so if it leverages some of the
    work IBM has done on using schema information to create optimized
    parsers. (A schema-validating parser can actually be _faster_ than a
    non-validating parser!)

    2) No two parties agree on exactly which competing needs "binary XML"
    needs to be optimized for.

    3) Anyone who really worries about performance winds up using XML as a
    portability/interchange representation, and switching to a more
    specialized data representation within their tools, with code and data
    tailored to each other. That's true even if you're doing general XML
    infoset storage and manipulation; you decide in advance which needs are
    most important and optimize for them.

    There is still an effort in progress to see if some common compromise is
    possible... but frankly I expect it to fail. XML's textual
    representation -- the fact that it is accessible to the "desperate perl
    hacker" with minimal investment in education, and that a moderately
    clueful student can implement a moderately efficient system moderately
    quickly -- really does turn out to be a key strength.

    Don't take my word for it. Maybe someone out there really does have a
    new insight that will make this concept worthwhile. But personally, I
    recommend that you take a step back, ask what problems you're really
    trying to solve, and think hard about whether binary XML -- especially
    in its current unstable forms -- is seriously helpful or just a buzzword
    and distraction.


    --
    () ASCII Ribbon Campaign | Joe Kesselman
    /\ Stamp out HTML e-mail! | System architexture and kinetic poetry
    Joe Kesselman, Aug 16, 2006
    #2
    1. Advertising

  3. Hm. I stand corrected about status.

    XOP has in fact been reported out as a Recommendation. It appears to be
    primarily intended as an attempt to avoid re-encoding of binary data
    already available in a base-64 representation, rather than a compressed
    representation of ordinary XML itself. MTOM builds on XOP within the
    context of SOAP.

    I recognize some of the names on both specs as more-than-usually clueful
    individuals.

    None the less, I still stand by my assessment of the general topic of
    binary XML representations. As a special-purpose tool, fine. As more
    than that... it still appears to mean giving up too much of what XML is
    in exchange for an incomplete optimization. Bad tradeoff, in my view.
    Your milage may vary.
    Joe Kesselman, Aug 16, 2006
    #3
  4. Default User

    Default User Guest

    Joe Kesselman wrote:

    > Default User wrote:
    > > I'm working on a research and development project involving binary
    > > XML.

    >
    > Binary XML (misnomer!) is not a recommendation yet; it's exploratory
    > work. Past experiments have generally suggested that:
    >
    > 1) The advantages of "binary XML" are less than a naive view claims.
    > Zip-style data compression is better at saving bytes, and a good
    > parser is surprisingly efficient -- even more so if it leverages some
    > of the work IBM has done on using schema information to create
    > optimized parsers. (A schema-validating parser can actually be faster
    > than a non-validating parser!)
    >
    > 2) No two parties agree on exactly which competing needs "binary XML"
    > needs to be optimized for.
    >
    > 3) Anyone who really worries about performance winds up using XML as
    > a portability/interchange representation, and switching to a more
    > specialized data representation within their tools, with code and
    > data tailored to each other. That's true even if you're doing general
    > XML infoset storage and manipulation; you decide in advance which
    > needs are most important and optimize for them.


    These are good points, and that's part of what R&D in the aerospace
    business is about. You try see where the state of the art is, and try
    some prototypes applying that to common use cases in our business.

    > There is still an effort in progress to see if some common compromise
    > is possible... but frankly I expect it to fail. XML's textual
    > representation -- the fact that it is accessible to the "desperate
    > perl hacker" with minimal investment in education, and that a
    > moderately clueful student can implement a moderately efficient
    > system moderately quickly -- really does turn out to be a key
    > strength.


    That's not really of concern.

    > Don't take my word for it. Maybe someone out there really does have a
    > new insight that will make this concept worthwhile. But personally, I
    > recommend that you take a step back, ask what problems you're really
    > trying to solve, and think hard about whether binary XML --
    > especially in its current unstable forms -- is seriously helpful or
    > just a buzzword and distraction.


    Well, this is the job for 2-1/2 engineers through the end of this year,
    and likely beyond.



    Brian

    --
    If televison's a babysitter, the Internet is a drunk librarian who
    won't shut up.
    -- Dorothy Gambrell (http://catandgirl.com)
    Default User, Aug 16, 2006
    #4
  5. Default User

    Default User Guest

    Joe Kesselman wrote:

    > Hm. I stand corrected about status.
    >
    > XOP has in fact been reported out as a Recommendation. It appears to
    > be primarily intended as an attempt to avoid re-encoding of binary
    > data already available in a base-64 representation, rather than a
    > compressed representation of ordinary XML itself. MTOM builds on XOP
    > within the context of SOAP.


    That's why I'm interested in exploring it versus DIME or SwA. It seems
    like it might have more future stability. If this goes as my boss and
    the tech lead envision, we'll be working on Web Services for avionics
    systems for the next few years.

    I'm certainly aware of and will look into the compression issue. Cokus
    and Winkowski had an interesting research project on that score.

    > None the less, I still stand by my assessment of the general topic of
    > binary XML representations. As a special-purpose tool, fine. As more
    > than that... it still appears to mean giving up too much of what XML
    > is in exchange for an incomplete optimization. Bad tradeoff, in my
    > view. Your milage may vary.


    I've read the paper by Nottingham et al, where many concerns about the
    state of the art in 2003 were raised. It's a good background for the
    situation now, which is very much in flux.

    We are pretty specialized. We'll be looking systems for transmitting
    the kind of data that the (potential) customers want, on platforms
    representative of our typical usage.

    I've read so many papers on the subject of binary XML and the main
    implementations so far that my eyes are bleeding. I understand what
    you're saying, but these are topics we are scheduled to investigate.




    Brian
    --
    If televison's a babysitter, the Internet is a drunk librarian who
    won't shut up.
    -- Dorothy Gambrell (http://catandgirl.com)
    Default User, Aug 16, 2006
    #5
  6. Default User wrote:
    > but these are topics we are scheduled to investigate.


    Good 'nuff. Your application may be in a niche where this makes sense.

    (I've pinged Noah to ask if there's a good paper he could recommend
    which summarizes the current best-practice/best-guess.)

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
    Joseph Kesselman, Aug 16, 2006
    #6
  7. Default User

    Default User Guest

    Joseph Kesselman wrote:

    > Default User wrote:
    > > but these are topics we are scheduled to investigate.

    >
    > Good 'nuff. Your application may be in a niche where this makes sense.


    We hope so. It's not general web services, it's web services for
    propriatary platforms (I hesitate here to say "embedded" as that has
    caused confusion in the past).

    > (I've pinged Noah to ask if there's a good paper he could recommend
    > which summarizes the current best-practice/best-guess.)


    I appreciate that.



    Brian

    --
    If televison's a babysitter, the Internet is a drunk librarian who
    won't shut up.
    -- Dorothy Gambrell (http://catandgirl.com)
    Default User, Aug 16, 2006
    #7
  8. OK, here's what I've been able to gather:

    MTOM is reportedly gaining popularity specifically as a way of passing
    non-XML (eg binary) data as a base-64-encoded block of data within one
    of the XML elements of the SOAP message. "MTOM will allow suitably
    enabled SOAP bindings to optimize the transmission of such things."

    This is a very different matter from past uses of the term "binary XML",
    which were talking about alternate representations of XML rather than
    ways of using XML to represent binary... which is what I (erroneously?)
    assumed you were interested in.

    Apologies if we've been talking at cross purposes!
    Joseph Kesselman, Aug 17, 2006
    #8
  9. Default User

    Default User Guest

    Joseph Kesselman wrote:

    > OK, here's what I've been able to gather:
    >
    > MTOM is reportedly gaining popularity specifically as a way of
    > passing non-XML (eg binary) data as a base-64-encoded block of data
    > within one of the XML elements of the SOAP message. "MTOM will allow
    > suitably enabled SOAP bindings to optimize the transmission of such
    > things."
    >
    > This is a very different matter from past uses of the term "binary
    > XML", which were talking about alternate representations of XML
    > rather than ways of using XML to represent binary... which is what I
    > (erroneously?) assumed you were interested in.
    >
    > Apologies if we've been talking at cross purposes!


    It does seem to be a somewhat vague at times. We are looking into
    attaching binary data (the actual data is still TBD) and route to
    various users on the network.




    Brian

    --
    If televison's a babysitter, the Internet is a drunk librarian who
    won't shut up.
    -- Dorothy Gambrell (http://catandgirl.com)
    Default User, Aug 17, 2006
    #9
    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. Vai2000

    MTOM

    Vai2000, Mar 1, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    662
    Vai2000
    Mar 1, 2006
  2. John Ionides

    ZSI / MTOM

    John Ionides, Feb 23, 2009, in forum: Python
    Replies:
    0
    Views:
    315
    John Ionides
    Feb 23, 2009
  3. Cameron Simpson

    Re: ZSI / MTOM

    Cameron Simpson, Feb 24, 2009, in forum: Python
    Replies:
    0
    Views:
    357
    Cameron Simpson
    Feb 24, 2009
  4. Vai2000

    MTOM!

    Vai2000, Jun 4, 2007, in forum: ASP .Net Web Services
    Replies:
    2
    Views:
    159
    Vai2000
    Jun 5, 2007
  5. Festus

    HELP - XOP MTOM - Soap with Attachments.

    Festus, Feb 12, 2008, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    215
    Festus
    Feb 12, 2008
Loading...

Share This Page