XML between layers


XML & Web services: XML between layers

  1. XML between layers (15 messages)

    Our project uses XML to pass data between layers. We don't want to create any physical xml files. The approach what we are using currently is xml as a String object (The whole XML will be a java.lang.String object with tags). Now we are planning to migrate to Document object instead of String.

    Which is the better approach, if we have cater to multiple channels?

    Threaded Messages (15)

  2. XML between layers[ Go to top ]

    With Document object you will have huge serialization orverhead. Because each node of document will serialized separatly. With String you don't have very little serialization overhead, but it looks weird -).
  3. XML between layers[ Go to top ]

    That's not a complete answer.

    It's a trade off. A String will probably serialize faster than a Document object. But, if you send a String over the wire, then you probably have to re-parse it back into a Document object at the other end, which takes even more time.

    In general, pass the parsed object around, but try not to pass huge trees around (you will probably blow up your stack if you do that, since most implementation use recursion to serialize their trees.

    I would caution you strongly to be very very sure you want to use XML for this kind of messaging, it could cripple your performance.

    You might be better off passing things between layer in a more efficient format and simply persisting it in XML. That tends to perform much better.

    Hope that helps


  4. XML between layers[ Go to top ]

    This is a complete answer because this person mentioned that they alreay using XML as interchange format.
    Blow up stack lol? As I understand they not planing to pass 2gb trees. They jus passing simple entities.
    And I dont thin that for them now is easy to switch from XML to simple plain java objects.
    And btw "You might be better off passing things between layer in a more efficient format and simply persisting it in XML" sounds very informative. This senetence does not give any information just bunch of buzzwords persistence, XML. Why he should pertsist entities as XML if he already using RDBMS ? =)
  5. XML between layers[ Go to top ]

    I wasn't trying to in any way put down your comment, if that's how you took it then please accept my apologies.

    However, since I have built systems of the nature being described I am more than happy to elaborate...

    "You might be better off passing things between layer in a more efficient format and simply persisting it in XML"

    The point here is that you might want to consider passing your data around in object form, what I typically refer to as the volatile format. In other words it doesn't survive a server crash. However, you still have the ability to restore the systems state by pulling the state back in from it's persistent form, where XML would perhaps make sense.

    I do not believe it is always advisable to use XML between layers of a system. As your interface into the system from the outside, absolutely, within your system, not convinced. Parsing XML is highly expensive in terms of CPU usage and if the layers of your system are on different boxes then XML is a rather bulky format which increases your usage of the network as well.

    However, the point of the original question was not "XML or not XML" it was "String or org.w3c.dom.Document" and I stand by my comment about blowing the stack. Whether the DOM you pass round be very wide or very deep the eventual recursive calls to the same serializeChild(...) or similar method DOES eventually blow the stack, I've seen it (at least with Xerces.) The default stack size is, I believe 128K and it's actually not at all that hard to blow that if your XML get's too large. I had to increase stack size to 256K which gets round the problem. I also stand by my comment that the overhead of re-parsing the String into a Document object will probably be much greater than the cost of serializing a Document object rather than a String.

    In actuality, if the nature of the client is unknown then it's easy to Facade this so that it doesn't matter now you do it. These are just adapters in the standard Adapter pattern.

    You can also serialize in another way, using XML serialization, which creates the String representation from the Document object, into an output stream, which is a good way of throwing XML over a socket to a non Java client.

    OK, think that covers it pretty thorougly.


  6. XML between layers[ Go to top ]

    We are currently using hashtable for sending XML between layers. Hashtable contains string with XML being sent and some data allowing us to quickly change the state of operation (success/failure), exceptions, numerical data etc. We considered both methods described by you, and decided to use something "in the middle".

    Consider, that what you need for the multichannel architecture is:
    a\ XML (to be processed by XSLT - in our case) - display
    b\ Some data for controlling navigation/flow - interaction

    First, we were afraid, that the number of additional data in the hashtable will be too big. During the design, we've determined - that flow-info isn't very complex, and can be presented in a very smart way.


  7. XML between layers[ Go to top ]

    Tiny point, but Hashtable or HashMap?

    Unless you're sharing the thing between threads you may find HashMap a lot faster since none of it's methods are synchronized.



    PS. Wrapping the XML with some additional state also makes good sense. JMS works the same way, using the message header and body. Your concept is the same.
  8. XML between layers[ Go to top ]

    Good point. I must think about it a little. The only synchronization problem I can imagine, can occure at the web-app container side.


  9. XML between layers[ Go to top ]


    I have one more question, how can we compare the performance of String and Document if I have to use them with EJBs, I mean which object performs better when serialized?

  10. XML between layers[ Go to top ]

    That really depends on how big the XML is.

    The best thing you can do is run some tests, with fixed XML documents of the size you plan on dealing with. Something like this:

    long start = System.currentTimeMillis();
    Document doc = remoteObject.getDocument();
    long end = System.currentTimeMillis();

    System.out.println("Took '" + end-start + "' ms to get object using Document object.");

    start = System.currentTimeMillis();
    String str = remoteObject.getDocumentString(); // Make sure this works in the same way your remote end would generate the String.

    long string = start - System.currentTimeMillis();

    start = System.currentTimeMillis();
    Document doc = <use parser to convert str into Document>;

    end = System.currentTimeMillis();

    System.out.println("Time to get String was '" + string + "' ms");
    System.out.println("Time to parse into Document was '" + end-start + "' ms");

    That ought to give you at least an order of magnitude. There are countless other factors to consider, but if you make sure your Document objects and String objects are fixed in size (So you have something constant to measure across) then you can get an idea for the cost of serialization versus the cost of parsing.

    Hope that helps


  11. XML between layers[ Go to top ]


    We indeed collected the timestamps for building the XML and parsing it using both the approaches. Document takes less time compared to String (difference is almost a minute for 1000 records with 5 fields).

    Does SAX parser be of any help compared to DOM parser. ie, let the XML be still held in String object, but use SAX parser to parse it?
  12. XML between layers[ Go to top ]

    The SAX parser is less memory intensive, and could be faster. Depends on how you implement your callback method really. You might decide to throw away tags you don't need, which would speed things up for sure.

    In general, if the DOM is small, then a DOM parser is as fast as any of the alternatives, apart from direct parsing which I assume is not desirable or you would probably not bother using XML in the first place. :-)



    PS. Glad it's quicker with Document. Makes sense. Serializing an object graph is much quicker than parsing. Apart from anything else a Document object is a big graph and the parse operation creates a ton of objects, all of which end up on the heap. In a multi-threaded environment thats a performance penalty, since only one thread can create an object on the heap at a time.


  13. XML between layers[ Go to top ]

    instead of usinfg a string object to pass xml doc you can use Jdom parser and very well use document object.
    It's quite possible.
  14. XML between layers[ Go to top ]

    If it's just your code then the container won't touch it and won't manipulate the HashMap so you don't have to worry about it.


  15. XML between layers[ Go to top ]

    Thanks again. I've talk about it with my crew. Seems like we need some refactoring.


  16. XML between layers[ Go to top ]

    if u don't want a physical document to be created, u should atleast have a template of it.
    we tried with a template being on client side which will act as a messenger between layers.
    It will be only an xml document with empty tags.When u try to send it it makes attributes for it and adds values to it and sends it to the next layer.
    i think it would help.
    wrtie to me if u want code sample.