This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi, I have recently joined a team which has successfully implemented a high performing,robust 3-tier system, using Swing as a front-end, EJB as the middle-tier and Sybase as the data-tier. The architecture uses XML as the data transfer mechanism between the presentation tier and the business tier. I always thought that it's better to use java objects to pass on the data from the 1st tier to the 2nd tier, because serialization of java objects is much quicker than serialization and deserialization of XML. Experienced people, could you please put in your thoughts on this one? Thanks, Kalyan.
You are absolutely right. Though you can use XML as your data transfer format, the importent point is that it doesn't really provide you any tangible benefits. Think about the extra work you are asking your application to do - for each remote call not only do you now have the overhead of the call to contend with, you must now create a Document, serialize it, transmit it, unserialize it and parse it into an new Document, deal with the message and possibly persist it through an ORM layer. The only possible benefit I can see from this route is if your business tier were third party and not within your control - in which case passing Documents which conform to a DTD could be helpful, with regards to keeping method signatures stable, which is straying towards a web services model. This would still be less performant though. And I can't think of any development team which could work like this. XML in traditional J2EE aps (outside of webservices) in my opinion is best kept in the presentation layer. It is a valid thing to do to render a GUI using say XSLT, but in this case I'd use one of the many Object-to-XML utilities out there and do the work in you're swing client.