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

[Brett McLaughlin]

philip.nelson at omniresources.com wrote:
> 
> > > > 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?

Well, yes. The fundamental problem here is that XML is not useful in
these cases. It takes significant time to convert from Java to XML to
Java. So when you can either supply an object that is directly useful,
like the UserInfo object, or an XML document (in JDOM form or otherwise)
that must be converted to the Java object it represents, or manipulated
to get data in non-intuitive ways (root.getChild("firstName") is not as
useful as userInfo.getFirstName()), you are adding cost to the
application just so the result is in XML.

Directly returning Java bytecode, in the object format that it
represents, will always, always, always be simpler and faster than
converting to XML. And as for Alex's comment that "I already wrote my
bean code", I don't go for it. One, you can actually have your bean
extend the value object (although I talk against that in general - lots
of reasons), you can also just copy/paste... is that not the ultimate in
ease ;-)

In either case, these are fun discussions. And keep in mind I've been
writing this very chapter in my book for three weeks, which is probably
why I sound so sure and heavy-handed on my opinions ;-)

-Brett


-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org