Hi Oleg,
At 01:19 AM 1/11/01 +0200, you wrote:
>Hi Rick,
>
>I'll tell you my opinion if you want to listen :-)
I'm happy to listen to your opinions :)) Thank you for taking the
time. I have some follow up questions if you have some more time to spare.
> > Here are my questions: (I only have a cursory understanding of
> > Castor at this point, so please forgive me for any stupid
> > questions):
> >
> > 1. I would like to use Castor to manage persistence of EJB BMP
> > entity beans, given JAWS' inability at the moment to support
> > dependent objects. An EJB with no dependent objects would have a
> > single Castor persistent object associated with it, whereas an EJB
> > with dependent objects would implement those dependent objects as
> > Castor dependent objects. If I use an architecture like this, is it
> > best to let Castor directly persist the EJBs, themselves, or is it
> > better to store the data for an EJB in a separate Castor data
> > object?
>I believe that EJB class shouldn't coincide with Castor data object.
>EJB class should hold some data object internally,
Why do you think this is preferred?
>use Castor
>db.load(), db.update(), db.create(), db.remove() to implement
>jdoLoad(), jdoStore(), jdoCreate(), jdoRemove().
What are jdoLoad() etc? Do you mean ejbLoad() etc.?
>Probably you can automate this work with the help of some code
>generation tool.
>EJB class may or may not have get/set methods for all fields of
>Castor object, but it should have get/set methods for the whole
>Castor data object used as a value (bulk) object.
Makes sense...i agree.
>In general independent Castor data objects may not correspond to some
>BMP, but only if you need BMP for some non-trivial remote operations,
>some business logic performed for one object instance. Otherwise you
>can use Castor data objects from Session Beans or even from other
>Entity Beans directly, without intermediate BMP (it would be faster
>BTW).
Yes, I understand what you're saying. What I'm thinking is that by tying
Castor data objects to BMPs, that should I want to do so in the future, I
would have an easier time porting to EJB 2.0 CMP. Would you agree?
>Even if you have two BMPs "hosting" two Castor data objects, you can
>use Castor data object from "foreign" BMP.
>In other words, I believe that it is okay to separate some Entity
>into two classes, BMP as a remote object and JDO as a value
>object. For me it is better approach than to claim that Entity ==
>EntityBean and then to solve performance and network traffic problems
>inventing various unclear tricks.
Just to make sure I understand what you're saying, please look at an
example with me. The example has 2 BMPs, A-BMP and B-BMP, backed by Castor
data objects A-Castor and B-Castor, respectively, and if A-Castor
references B-Castor. I load A-BMP from the database through an EJB finder
method. If I call A-BMP.getB(), in an all EJB world, I would want it to
return B, the remote interface to B-BMP. If the A-BMP's getB() method
delegates to A-Castor's getB() method, I would get a reference to the
B-Castor object. If B-Castor is serializable, then I suppose this is
workable, however, it breaks the EJB semantics by returning a (possibly
serializable object), when what I want is a remote EJB reference to
B-BMP. Thinking aloud here, it seems that this could be solved by loading
A-BMP's reference to B-BMP in A-BMP's ejbLoad() method (and likewise with
ejbStore()), and by not delegating the A-BMP.getB() method to
A-Castor. Does all this sound correct to you? Do you see any reasons that
I should not do this, aside from performance?
> > 2. I would like to avoid duplicating data objects as much as
> > possible. One thing that I've noticed with the whole J2EE
> > architecture is that there is a lot of opportunity to duplicate
> > objects that do roughly, or exactly, the same thing. For example:
> > a) Struts uses JavaBeans that extend
> > org.apache.struts.action.ActionForm to pass data from an HTML form
> > in a JSP to the servlet for processing. In addition, both these and
> > other, non-ActionForm JavaBeans are used to pass data back to a JSP
> > for output to the user.
> > b) It is recommended that data objects be used to pass bulk data
> > between the EJB client and the EJB in order to minimize network and
> > transaction overhead. Question: is it a bad idea to use Struts
> > ActionForm beans as these data objects? The tradeoffs seem to be:
> > if yes, then it increases the coupling between the EJBs and the
> > front end technology - BAD, but if no, then it eliminates the need
> > to implement and maintain an additional data object for the EJB.
> > Opinions?
>I would use Castor data objects: you can pass them to client or to
>servlet, then return them back (so called "long transaction") and
>update in the database. Moreover, Castor supports dirty checking for
>long transactions.
Is it the case that Castor "long transactions" use 2 transactions, the
first one does not lock the object(s) in quesiton and the 2nd does? If so,
is this possible in an EJB CMT situation, in particular JBoss? Doesn't
JBoss require setting of the commit level (which would control locking) on
a per container basis, meaning a per EJB basis? Can this be handled (if it
is indeed a problem) by simply allowing locking on both txns? Now you'll
probably tell me that this is not at all how long transactions work :))
>If you need decoupling, you can introduce additional client interface
>which is implemented by Castor data object, so that client works with
>this interface and you are free to change the implementation.
Yes, that probably makes sense to use a business interface for the data
objects represented by Castor and by the clients if I choose to decouple these.
Thanks very much,
--------------------
Rick Horowitz
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
