• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DOM Object through Session Facade

 
Pearlo Muthukumaran
Ranch Hand
Posts: 79
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Is it advisable mainly from a performance perspective to pass a DOM object to a Session Facade back and forth. Approx DOM Object size is ranging from 800 to 900 bytes?
Thanks in advance
Muthu
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
AFAIK DOM's aren't serializable. You won't be able to do it anyway. Besides, it is my STRONG opinion that XML processing should be done outside the EJB whenever possible.
Kyle
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
Besides, it is my STRONG opinion that XML processing should be done outside the EJB whenever possible.

All XML processing? Why?
Simon
p.s. "Muthukumaran",
Thanks for joining JavaRanch, but could you just take a quick look at the naming policy and edit your profile.
Also, only members with valid names will be eligible for the book giveaways.
Thanks
[ March 31, 2003: Message edited by: Simon Brown ]
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, because basically XML processing (meaning parsing and generation) doesn't fit well into the Distributed object paradigm that EJB is based around. You see, XML is a wonderful technology for use at the edges of your architecture -- it's great for communication between applications, and it's a great storage format for some types of persistent data. However, as an object model, it sucks. EJB's should operate on objects, not raw data. So, my preference is to convert to objects outside the EJB (in the servlet engine or in an explicitly external place like the JAX-RPC engine) and then manage only objects in the EJB's.
I've seen far too many projects tank because they try to turn XML into their object model. It doesn't work -- anything beyond CRUD is a nightmare. There's no good place to put the domain behavior. So keep your XML, and keep your objects, but don't mix up the two...
Kyle
 
Pearlo Muthukumaran
Ranch Hand
Posts: 79
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I can adopt two of the below options:
1. Construct Value-object type of objects from the DOM either at servlets or at some layer between Servlets and EJB and then pass them to the EJB tier.
2. Since the above method shall lead to multiple objects being passed to the ejb tier through multiple method calls, I shall have to group multiple objects in a collection object and then pass the collection to EJB tier so that the network roundtrips will be avoided.
But in the second method, somehow the domain layer objects will get tied up to the external entities and are liable to change often. How to avoid this situation Brown?
Thanks in advance
Muthu
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
Well, because basically XML processing (meaning parsing and generation) doesn't fit well into the Distributed object paradigm that EJB is based around. You see, XML is a wonderful technology for use at the edges of your architecture -- it's great for communication between applications, and it's a great storage format for some types of persistent data. However, as an object model, it sucks. EJB's should operate on objects, not raw data. So, my preference is to convert to objects outside the EJB (in the servlet engine or in an explicitly external place like the JAX-RPC engine) and then manage only objects in the EJB's.
I've seen far too many projects tank because they try to turn XML into their object model. It doesn't work -- anything beyond CRUD is a nightmare. There's no good place to put the domain behavior. So keep your XML, and keep your objects, but don't mix up the two...
Kyle

I agree with this 100% - you should always use objects. I've also seen projects that use XML for maintaining state internally and it's a mess. However, there are times when EJBs should contain XML processing - for example calling web services, loading config data, etc. These are two separate issues IMHO.
Simon
 
Doshi Milan
Ranch Hand
Posts: 112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
This is not in continuation to the last 2 discussion , but the first discussion.
You can certainly have a look at Cator. This can directly convert your XML data to value Objects and vice versia.
http://www.exolab.org/
Thanks and Regards,
Milan Doshi
[ April 04, 2003: Message edited by: Doshi Milan ]
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic