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

Richard Landon RLandon at youbet.com
Mon Oct 9 14:21:04 PDT 2000

I thought I would post what we have decided (and to a limited extent already
done) based
on the various inputs on this thread  and other sources (I made the original

(1) Our architecture is an EJB-centric architecture based around the
Model-View-Controller (MVC) paradigm
    Models:= Entity EJB (using CMP persistence)
    Controller:= Stateful Session EJB
    Views:= JSP or Servlets
(2) Some of our clients are EJB clients, and some are not (we currently use
HTTP POST with form data to a 
    servlet URL, which then invokes into the EJB-layer as a EJB client). For
example, we need to support 
    acquisition of the data using an Excel Spreadsheet (that is from VB,
which we greatly regret, but that's
    a requirement at this time) or from a C++ client, which can't use CORBA
because its embedded in a server
    side JavaScript engine related to a product whose acronymn is BV. Thus
we need to respond in some cases
    with XML data.
(1) Our Entity EJB must implement a "model interface" which consists of a
single method
    Model getDetails() where Model is a Serializable subclass. The derived
model subclass for 
    each EJB is a (A) value object (since it can be returned via the remote
interface) (B) is a bulk-accessor
    (since it contains the data elements of the corresponding EJB) and (C)
is a JavaBean since it defines
    a default constructor and the corresponding set and get methods for each
(2) Althought we have not done it yet, we believe that we can therefore use
the BeanMapper to convert our
    Model subclasses in those clients which need to deal with or reply with
(3) The Model subclasses ensure a read-only interface to model data
(surrogated for the EJB) since using the 
    set method only change the client-copy (and yes, we have documented
(4) When a change in the Entity EJB is made, a model notification is sent to
the client tier (details of how
    this is done are omitted) and when the View (JSP or Servlet) receives
this notification, it then acquires
    the derived model subclass by invoking getDetails on the EJB remote
interface. It can then map the data 
    to XML using the (not yet tested BeanMapper class) since the Model
(value object) is also a proper JavaBean.
    Note that a View may be interested in serveral models, and thus, may
need to compose XML from serveral different
    JavaBeans (that is, again, derived models). We are currently trying to
determine if there is some kind of 
    utility we can build or use to help automate the generation of XML in
this case (again, any pointers?

Thanks for all the inputs, we have appreciated the commentary greatly.

-----Original Message-----
From: Laurent Bihanic [mailto:lbihanic at atos-group.com]
Sent: Monday, October 09, 2000 12:01 AM
To: Jdom-Interest (E-mail)
Subject: Re: [jdom-interest] Re: EJB Mapper (was Newbie: JDom-Test)

Alex Chaffee wrote:
> Gee, wouldn't it be nice if the container automatically built you a
> value object at deploy time?  I wonder if any EJB container authors
> are on this list... ;-)
You may look at EJBDoclet (http://www.dreambean.com/ejbdoclet.html) although
it is not integrated in a container and must be used at development time.
To control your jdom-interest membership:

More information about the jdom-interest mailing list