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

Brett McLaughlin brett.mclaughlin at lutris.com
Fri Oct 6 11:18:05 PDT 2000

Alex Chaffee wrote:
> On Thu, Oct 05, 2000 at 06:26:16PM -0500, Brett McLaughlin wrote:
> >
> > Richard Landon wrote:
> > > I've looked at the BeanMapper example in the jdom-contrib and want to
> > > simulate something
> > > akin to it for Entity EJB: we're using an MVC based EJB-centric design for
> > > our system.
> > > The idea being that we can return an XML document in a String as data when
> > > we dispatch
> > > the model change notification to the View (which exists within a JavaBean in
> > > the Web-Tier).
> > > I am dreaming, or just insane? I would appreciate any feed-back on the
> > > general design
> > > and approach (Really I would). I understand this is an XML not EJB forum,
> > > but hey, it's
> > > worth a shot? Here's a pointer to a discussion on XML and EJB that I'm
> > > pretty much modeling
> > > the approach after:
> > > http://theserverside.com/patterns/thread.jsp?thread_id=343
> >
> > This is a bad idea, frankly. I've been on Floyd to dump that one, but it
> > is an open forum ;-) You don't want your EJBs returning XML; it exposes
> > your business layer in a way that makes no sense in a Java application.
> > Your servlet should talk RMI to th EJB layer - talking RMI to get back
> > XML is a huge performance hit that gains you nothing in an all Java
> > application. If your EJBs are returning XML to be used in presentation,
> > then you have coupled your business layer to the presentation layer,
> > which isn't good; if they are returning XML object graphs, then you are
> > spending tons of time decoding XML into Java for no purpose.
> >
> > 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.
> >
> 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).

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

> Also, I disagree that it couples unduly -- it just adds a mapping
> layer from the bean to an arbitrary XML representation.  You are free
> to change the bean later and keep the same XML rep, which is, like,
> the whole point of MVC.

Yes, but it really doesn't make sense, because unless you have session
bean results mapped to specific screens, then you have to combine XML
documents from multiple beans into one coherent presentation - and
combining XML documents is arguably one of the toughest things you can
want to do ;-)

> Richard, I wrote BeanMapper recently, and it's still got some
> holes/flaws, but in theory it should work fine on an EJB object, as
> long as said object uses the JavaBean naming conventions for its
> property accessors/mutators.  That is, if you have properties foo and
> bar, just make
>         public Foo getFoo()
>         public void setFoo(FooType foo)
>         public Bar getBar()
>         public void setBar(BarType bar)
> and you should be able to call beanmapper.toDocument(this) from inside
> a different method
>         public String asXML() {
>           Document d = beanmapper.toDocument(this);
>           String s = xmloutputter.outputString(d);
>           return s;
>         }
> Let me know how it works out!  And if you feel like adding support
> for, e.g., List properties to BeanMapper while you're at it, that'd be
> great too... :-)

Go for it - but consider yourself warned that there is a better
methodology ;-) While Alex's code is great at what it does, I think you
would be making a large mistake in going down this road. The only really
valid reason for having EJBs output XML is in a system that is largely
receiving and responding with XML to other non-Java systems that can
only consume that type of data; this is obviously not your case, as you
are simply talking to other Java components.


>  - Alex
> --
> Alex Chaffee                       mailto:alex at jguru.com
> jGuru - Java News and FAQs         http://www.jguru.com/alex/
> Creator of Gamelan                 http://www.gamelan.com/
> Founder of Purple Technology       http://www.purpletech.com/
> Curator of Stinky Art Collective   http://www.stinky.com/

Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 

More information about the jdom-interest mailing list