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

Brett McLaughlin brett.mclaughlin at lutris.com
Sat Oct 7 15:42:24 PDT 2000


> > Directly returning Java bytecode,
>
> Um, you mean returning binary data values via JRMP.  Bytecode doesn't
> get serialized in RMI.

Yes, typo. I was multi-tasking (poorly, obviously) with another
discussion on compilers ;-) Binary data, yes.

> > in the object format that it
> > represents, will always, always, always be simpler and faster than
> > converting to XML.
> 
> Faster, yes.  Simpler, yes, *if* you're going to keep it as Java on
> the other end.  But if the RMI/EJB client is going to push XML to one

But those are the scenarios we are looking at! And I clearly said in my
mail if you are going to broadcast to XML-consuming systems,this pattern
makes sense.

> of its clients (say, it's a SOAP servlet), it may be simpler for the
> client to receive XML and then either output or XSL-transform it...

Again, I agree - but most often, this is an unrealistic scenario; it's
not that it's not being transformed, it is that multiple bean results
would be used in an output, which bogs down. In that case, you're going
to lose in XSLT what you could have gained and them some in assembling
the output into one document prior to XSLT. But I think the main point
is in an all Java system, where you have fundamentally uncoupled your
layers, this is a bad idea. If you're consuming XML, or setup your beans
to map to output (really, really a bad idea), then go for it ;-)

> There's no reason the EJB server needs to do the transformation from
> Java->XML, though, unless you want to make life simpler for your
> clients, at the expense of transmission speed.

> > 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 ;-)

> You just recommended two non-solutions.  Using inheritance to build
> your EJB is just asking for trouble, and copy-and-paste is not code

What? No it's not! EJB 2.0 is all about inheritance at the bean level.
Every one of my EJBs inherits from an Entity or Session adapter, because
I hate writing empty method impls in CMP. So that's far-fetched ;-)

> reuse:

>  * After you paste, you'll have to go and check and probably modify
> each line anyway, introducing the chance of bugs or compiler errors,
> and negating any time savings versus just coding a value object from
> scratch

Wrong. You can cut and paste the entire bean implementation class
accessors and mutators (other than the ejbCreate, which isn't an
accessor or mutator), and it works unchanged, in CMP. Basic EJB.

> 
>  * Any properties you add/remove in one later on will need to be
> added/removed in the other, leading to possible subtle bugs and
> migration (version sync) errors
> 

CMP. CMP. CMP. Automates all of this. Design once, write code ;-)

> Got any real alternative rationalizations for why EJB developers
> should be forced to write their beans twice?

Because it's better for the client component. We write code for clients,
no matter how hard that is for us. Want to know how much stupid code I
have had to write in JDOM to make life easier for clients of JDOM?
That's why we're developers, and good ones, and newbies love us. Basic
programming ;-)


> If *I* wrote the EJB spec, I'd have turned it upside down, using
> delegation instead of inheritance.  There would be a Value Object
> which would literally be a JavaBean, without dependencies, and a
> Business Object that is given a pointer to its Value Object, which
> serves the purpose of the current EJB and/or EJBObject.  Then you
> could easily ask the server getValue() and it would serialize just the
> value object, without all the messy wrapper crap.

You can do this now with inheritance if you want. Of course, you don't
take into account exception handling and how your model would blow up
the notion of inheritance and exception handling in Java today, but now
we /are/ getting off topic ;-)

In any case, Java-Java this is bad mojo. Just don't do it - trust me. If
you are writing EJBs to be consumed by non-Java XML-consumers, go for
it, but in other cases, don't.

-Brett

> But this is seriously off-topic, and I have to go do my taxes now.
> Yes, I know, I'm a little late.  :-)

>  - A


-- 
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



More information about the jdom-interest mailing list