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

[Brett McLaughlin]

philip.nelson at omniresources.com wrote:
> 
> >
> > > know that object serialization had to use such a slow, inefficient
> > > format; but it did.
> >
> > I agree it's not great - but it beats the process of parsing
> > XML itself.
> > Also, there was one tangent about passing around a JDOM document - now
> > you're paying both prices (XML and Java) ;-)
> >
> 
> How are you paying both prices?  If the document was constructed in memory
> and sent over as a serialized JDOM document, there is no parse.  If the

Because every time you create any single construct in memory in JDOM,
you pay an XML-specific price. The name of the element, the attribute,
the data, the values, it's all parsed, character by character, and
verified to be legal XML. Creating a JDOM Document just because it's a
structure you like is fine, I suppose, but you have to realize that it
is a lot more expensive than creating a custom structure without all of
these various checks occurring.

> document was constructed originally from and XML document for legitimate
> reasons (like an use with an external system), you only have the one parse.

You parse it going in; there, there are two prices, both parsing and
serialization.

No matter how you cut it, serializing a JDOM Document pays (1)
serialization costs and (2) medium-to-high XML costs, depending on if it
was created in memory (medium) or created from an XML document (high).

I'm not saying you can't do this - I'm saying for Java-to-Java RMI
communication, it's a poor choice without a /really/ good reason. It
works fine in many other situations.

> The value pattern you prefer may have higher efficiency but nowhere near the
> flexibility of the JDOM document used as a value object.  What if your data
> is more than a simple one dimensional entity?  At one extreme you could have

OK. So? My value objects are often entire maps of entities.

public class UserInfo implements Serializable {

  // Nested value object
  private OfficeInfo officeInfo;

}

> lists of lists of fine grained value objects  which if accessed individually
> would put you closer to the getter/setter problem the value pattern is
> supposed to eliminate.  A JDOM document could handle this with one network
> transfer.

Mine is still one network transfer - and there are only lists of lists
if you have multiple complex objects that are dependent objects. It is
going to take a lot of dependent objects to even out with the JDOM
Document costs of creation or building, and serialization. I also still
think it's clear that it is much easier to do

user.getUsername();

than to have to somehow pass on to your client component

document.getRootElement().getChild("username").getValue();

This works great in a tightly-coupled application, but I'm of the
opinion that applications shouldn't be tightly coupled. It also mandates
that for uniformity, all external applications must supply you with JDOM
Documents; otherwise your client components have to employ completely
different mechanisms for accessing data from one application versus
another. Using standard value objects also removes this problem; at
worse, you can take a foreign response and drop it easily into a value
object, with little cost. Wrapping a foreign response in a JDOM Document
is, again, costly.

> 
> > > More importantly, however, is that RMI is Java-to-Java
> > only, and even
> > > if you're only doing Java-to-Java today, it's hard to predict what
> > > you'll be using tomorrow. Using XMl for the serialization syntax
> > > makes your whole system a lot more flexible, debuggable, and
> > > upgradeable than using RMI.
> >
> 
> Absolutely.  My current project deals with thousands of electronic forms.
> These forms vary from year to year.  Forms are added and dropped constantly.
> The validation rules change constantly.  Adding a hand coded value object
> for each of these would be a tremendous burden on my most scarce resource,
> programmers.  I am constantly looking for ways to eliminate code that varies

You've got to be kidding! If you're doing solid XML programming, then
you are writing a DTD for each one. And I simply don't believe that it's
easier to write a DTD for even a midly-complex form than to code a value
object. Additionally, if you are using EJB, then you already have had to
code the value object. ANd if you're not using DTDs, then that's a whole
other story ;-) You're allowing incorrect (invalid) data to be
proliferated through the system.

> by form.  In the past, database tables were used but because of the
> hierarchal nature of XML, XML has been much easier to use.  And yet I need
> the use of EJB because of the load balancing it offers.  So here is this new
> XML api called JDOM which just might fit in both EJB and my forms world...

Yes it fits. But is it the best fit? I can tell you with a lot of
confidence, no.

> 
> > I don't know that I buy this - I mean, you're saying don't bet on the
> > entire programming language that you have chosen! RMI isn't even an
> > extension, it's the core platform. While it's nice to be flexible,
> > you're saying, essentially, "don't bet on Java." I can't advocate to
> > anyone to choose a language for an application, but then don't bet on
> > the language; it makes all the choices you make virtually
> > lose-lose. So
> > I agree with you in concept, but in practice, if you choose
> > Java, you've
> > chosen RMI, for better or worse. I say use it.
> 
> Shouldn't the discussion be about how to use RMI effectively since that's
> the mechanism for EJB?

That wasn't the assertion that Elliotte made. He said:

> > > More importantly, however, is that RMI is Java-to-Java
> > only, and even
> > > if you're only doing Java-to-Java today, it's hard to predict what
> > > you'll be using tomorrow. Using XMl for the serialization syntax
> > > makes your whole system a lot more flexible, debuggable, and
> > > upgradeable than using RMI.

This specifically says that RMI is a bad choice to use because it isn't
"flexible, etc." I refuted that by saying that you should use RMI. Using
RMI effectively is the original thread, and I reiterate that using a
JDOM Document over RMI is (1) not as effective because of performance
costs compared to a value object (which you agreed with earlier) and (2)
not as good an idea because it tightly couples your application layer to
your EJBs. Your EJBs change the XML document, and your clients suddenly
have to change which element they query, the heirarchy they use, etc.

BTW, this has been a fun conversation ;-) I haven't changed my opinions
(they are even firmer after seeing a lot of people doing some things
that just don't make sense in most cases), but it's been educational for
lots of people, I think ;-)

-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