Messaging Systems, Binary XML, and Reliable Web Services

Home

News: Messaging Systems, Binary XML, and Reliable Web Services

  1. What are these specifications (XOP, MTOM, and RRSHB; WS-R and WS-RM)? How will they impact established messaging system products (like WebSphere MQ, TIBCO Enterprise Message Service, SonicMQ, etc.)? In Better Web Services Performance, I introduce what XOP, MTOM, and RRSHB are. Then in Web Services Compression and Reliability, I consider the impact of binary XML on messaging products. Finally, Reliable Web Services reviews WS-R and WS-RM and considers their impact on messaging systems.

    TSS readers may also be interested in these other recent postings:
    Note: Bobby Woolf is an IBM consultant.

    Threaded Messages (15)

  2. Pointless alphabet soup du jour[ Go to top ]

    Why bother when you can simply use something like JSON-RPC:

    http://www.json-rpc.org/

    Or PL over HTTP:

    http://alt.textdrive.com/pl/

    Or just plain, good, old MIME:

    http://www.faqs.org/rfcs/rfc2045.html

    Binary XML? That sounds like an oxymoron.

    Stick with the known and proven like ASN.1:

    http://asn1.elibel.tm.fr/en/

    Oh, wait... Fast Infoset is ASN.1 after all:

    http://asn1.elibel.tm.fr/en/xml/

    Blotted services discovery? Who needs it when you can simply use good, old, trusted DNS:

    http://www.dns.net/dnsrd/rfc/

    What something more fancy?

    Try Zeroconf:

    http://www.zeroconf.org/
    http://www.dns-sd.org/
  3. Pointless alphabet soup du jour (2)[ Go to top ]

    I agree. These efforts are more akin to "XML-marketing Optimized Packaging". There were several attempts since the early days of XML to provide a marshalling mechanism for XML. They always fail when people realize that serialization / deserialization is expensive - often more expensive then the bandwidth gains that [theoretically] can be made by marshalling the XML.

    Gad Barnea
    GigaSpaces, Inc.
    www.gigaspaces.com
    stormscope.blogspot.com
  4. Pointless alphabet soup du jour (2)[ Go to top ]

    I agree. These efforts are more akin to "XML-marketing Optimized Packaging". There were several attempts since the early days of XML to provide a marshalling mechanism for XML. They always fail when people realize that serialization / deserialization is expensive - often more expensive then the bandwidth gains that [theoretically] can be made by marshalling the XML.

    I worked on an application once where we were dealing with large Java Objects being Serialized across different speed networks. We had to compress the messages because we had some users on very slow connections.

    What I noticed, though, was that compressing the data actually slowed down the application on fast networks because the time cost of compression and decompression was greated than that of the data transfer.

    Not completely analogous to XML but I have to agree that reducing the message size isn't necessarily going to solve the problem.

    I think a lot of people think XML and SOAP are slow because they have worked with tools that have buggy or inefficient implementations. I know that Axis used to or still has a prolem deserializing messages that causes it o be extraordinarily slow. Something like 20 seconds to deserialize a one MB message.
  5. ...I think a lot of people think XML and SOAP are slow because they have worked with tools that have buggy or inefficient implementations. ....
    Some people pretty darn sure that String based technology cannot deliver optimal performance. Check out back to basics :
    http://www.joelonsoftware.com/articles/fog0000000319.html

    I am first who will sacrifice speed for convenience, but SOAP and XML-RPC is NOT convenient to use.
  6. True dat, true dat...
  7. I am first who will sacrifice speed for convenience, but SOAP and XML-RPC is NOT convenient to use.

    Hmmm. That's not been my experience. I guess it depends on the tools you use. With the tools I use most of the time, hooking into a WebService is one of the easiest things to do. Writing a WebService is a different matter of course.
  8. Check out back to basics : http://www.joelonsoftware.com/articles/fog0000000319.html

    Well, this must be the most significant article I read these last days !!! Pragmatic as we like :-)

    Also, the one on XML databases is quite in the mood of this thread !!

    Have fun

    Remi
  9. Pointless alphabet soup du jour[ Go to top ]

    You referenced about 5 different means of communication, incompatible between them. This is "why" web services and all the related standards. We need just one standard (well, set of standards) so that everyone can talk with everyone.

    That said, the best thing about WS for IT companies is that now everything that worked before must be invented again, and thus it can be sold again. So there is a lot of hype and marketing.

    However, I think the balance should be positive. Never before was such agreement in the middleware arena.
  10. Pointless alphabet soup du jour[ Go to top ]

    ... We need just one standard (well, set of standards) so that everyone can talk with everyone...
    You should be promoting Esperanto then. And one measurements system, and one type of car per job, and one sort of tea, etc.
  11. Hi Konstantin,

    Nice to read you, as usual :-)
    ... We need just one standard (well, set of standards) so that everyone can talk with everyone...
    You should be promoting Esperanto then. And one measurements system, and one type of car per job, and one sort of tea, etc.

    ... or be able to describe things in such a way that they can be manipulated in abstraction of the way they work...
    You know, definition language, projection for interoperable implementation...
    :-)

    Have fun

    Remi
  12. future directions of SDO?[ Go to top ]

    Interesting reads.
    To me more involvement in TSS by IBM will be very welcome....

    I have two questions on the subject of SDO's:
    1. I think SDO's would gain a lot by support for Java 5 annotations and generics. Does anybody know wether this is in the making?
    2. I encounter a lot of mentions of the possibility of JAXB generating SDO's. Is such a thing on the horizon?

    groeten,

    Joost


    ps It needed some effort not to use the phrases "for one" and "overlords". :-)
  13. As somebody already said in some blog I do not remember, terming the new W3C specs as "Binary XML" is misleading. "Binary data in XML" would be much more accurate (and also less impressive, of course). I think there is a great deal of discussion between XML gurus about the welness of a Binary XML spec.
  14. Binary XML and WS Forum...[ Go to top ]

    Thanks, Javier. For those interested, there is a Forum at Java.Net that is dedicated to the topic of Binary XML and WS. If interested, check it at : http://forums.java.net/jive/forum.jspa?forumID=44&start=0
  15. Fast infoset could serialize faster on the CPU and smaller on the wire than IIOP. It's a CORBA killer.
  16. You are so much out of scope that's inceredible... How can you even talk about all this ????

    There is no CORBA killer in Web Services. There is not even an opponent. You obviously don't have a clue of what CORBA is when looking at your statements...

    CORBA does not provide the same "features" than WSs. It does not address the same issues. CORBA is about doing real OO programming (but you seemed to have missed that) in a distributed fashion, with all implications it has (transacs, security, fault tolerance, perf., bidir connections, etc. - but once again you don't seem to be aware of that).
    Web Services is only about basic RPC and text-data exchange.
    How can you even *think* there's a fight there ????
    Your statements only have a place in some IBM or M$ executive's PPT presentation...

    CORBA won't be "killed" by WSs or anything else because it has no opponent. Oh yes, what you do with WSs can be done with CORBA (in a cleaner fashion and behave better at all levels - perf, fault tolerance, etc.), what can do more... but the inverse is not true !

    More and more silly things about WSs, frankly speaking it's really funny to see this community now at the end of what they could reach... They were even more convinced at the first attemptst, they say SOAP's gonna kill CORBA from the early beginning. I was there, I remember it like it was yesterday... They also used to think, 4 years ago, that CORBA woulmd disappear and CORBA skills too...
    Well, now they come into "hacks" because of a technology that has no real foundation except making money.
    Really funny.

    I bet a beer a few days ago on TSS, about the future of Web Services. I'm getting more and more convinced that I won't be thursty next year :-)

    Have fun

    Remi