[jdom-interest] Re: EJB Mapper (was Newbie: JDom-Test)

[philip.nelson at omniresources.com]

> > > I've seen lots of people doing this lately, and its just 
> bad design.
> > > People are incredibly infatuated with XML, and using it 
> way too much -
> > > use RMI for Java to Java, that's what it's there for. Then build
> > > presentation with your servlet. EJBs are business logic, 
> not application
> > > or presentation logic.
> > >
> > 

no argument here...

> > I agree that people are infatuated with XML, but there are 
> a number of
> > reasons why it makes sense here.
> > 
> > The main one is the whole value object problem -- using RMI to walk
> > through each of the property getters and/or setters is 
> abominably slow
> > -- this would allow you to ship all values to or from the 
> client in a
> > single packet (or at least a single response stream).
> 

This is why DCOM basically failed and why microsoft was pushing XML so
heavily, right?  DCOM always tries to marshall each method and type across
the network and it was to slow.  The answer as pushed in one of thier MSDN
seminars last year was to instead package up everything into an XML string,
parse and go.  The seminar showed using ADO, which can take a database
recordset and save it as XML, to accomplish this.  And it was faster than
DCOM.

> Yes, but surely you know that returning a value object, like:
> 
> public class UserInfo implements Serializable {
> 
>   public void getUsername();
> 
>   // etc.
> 
> }
> 
> is infinitely faster and simpler than conversion to and from XML, and
> also a lot more intuitive. This is a basic EJB pattern that should
> always be followed - never use multiple RMI accessors and mutators,
> simply use one to get the snapshot object, and move on.
> 
> Additionally, the time involved in serialization and deserialization
> from XML is significantly greater than object creation and
> serialization, so you increase the chances of operating upong stale
> data.
> 

so what about using JDOM as a serialized value object ( or a class that
contained a JDOM document)?  That was the point of Peter Gadjokov's
serialzation effort I think.  If it worked well, I like the idea that I
could use a JDOM document to keep the internal state of my business object,
then very easily be able to send a Momento of that object using RMI by
serializing the JDOM document.  Very little code would be needed to make
this transparent to the client apps (assuming JDOM was in the classpath).
Then in the business layer JDOM could be used to generate XML for other
systems, map XML to databases with (allegedly) available tools or even to
work with the file system for persistence of the class (though not with
EJB).  Is this a bad idea?