Hi,
I'm involved in Castor project and didn't know about the
jRelationalFramework before.
Let me tell about my first impression by jRelationalFramework
(surely, I'm rather biased :-).
The jRelationalFramework seems to be a competitor for Castor,
it serves the similar purposes.
On the other hand, the approaches differ:
Castor consistently follows the JDO paradigm, it uses OQL (Object
Query Language) for queries,
jRelationalFramework seems to be somewhat eclectic, it uses a mixed
object/relational terminology and propose access to SQL syntax.
I guess, in the future jRelationalFramework team might decide to move
in JDO direction.
For now one should evaluate both products, also take a look at Osage
http://osage.sourceforge.net,
and choose one that is more suitable and attractive for you.
I guess, any choice would be better than CMP 1.1 :-)
Best regards,
Oleg
Jonathan Carlson wrote:
JC> I haven't used Castor or any other JDO tool, so I wouldn't be able to tell
JC> you the differences. The jRelationalFramework generates SQL to read and
JC> update objects. I'll have to look into Castor a little more.
JC> -----Original Message-----
JC> From: [EMAIL PROTECTED]
JC> [mailto:[EMAIL PROTECTED]]On Behalf Of Natraj Gujran
JC> Sent: Friday, October 13, 2000 4:18 PM
JC> To: jBoss
JC> Subject: RE: [jBoss-User] Is EJB the model for us ?
JC> Thanks for the reply, Jonathan.
JC> So I guess our understanding was right about the Entity Beans. We have to
JC> stay away from CMP.
JC> Also, how is this SQL framework different from JDO/Castor ?
JC> -----Original Message-----
JC> From: [EMAIL PROTECTED]
JC> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Carlson
JC> Sent: Friday, October 13, 2000 11:34 AM
JC> To: 'jBoss'
JC> Subject: RE: [jBoss-User] Is EJB the model for us ?
JC> I wouldn't recommend accessing your entity beans directly from the client.
JC> In fact, I wouldn't even recommend using entity beans.
JC> We ended up passing data objects to/from session beans which stored or
JC> retrieved the data using a SQL framework (which we have open-sourced at
JC> http://jrf.sourceforge.net) The performance gains by using this instead of
JC> container-managed entity beans were incredible and the framework allowed us
JC> to get a lot of code reuse.
JC> What we gained was transactions, security, and the value of keeping the
JC> database access logic on the server.
JC> Good Luck!
JC> Jonathan Carlson
JC> [EMAIL PROTECTED]
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]] On Behalf Of Natraj Gujran
>> Sent: Friday, October 13, 2000 1:25 PM
>> To: [EMAIL PROTECTED]
>> Subject: [jBoss-User] Is EJB the model for us ?
>>
>>
JC> The scenario we have:
JC> We will have multiple JVMs running across the internet, that will access
JC> some EntityBean objects. For eg: CustomerAccount.
JC> The interactions:
JC> The interactions maybe occasionally write. But a large part will be read
JC> operations. Like 'getName()' , getCompanyName, getAddress .. and stuff like
JC> that.
JC> Problems:
JC> Using the EJB model, if we have a CustomerAccount EntityBean, every method
JC> invocation on that bean from a different JVM will be over RMI. Now that
JC> will be a lot of traffic, and very slow. We accept the slowness when we have
JC> to make updates/write operations into the object, but not for the hundreds
JC> of 'query/get' like methods.
JC> To solve this, we'll ultimately have to implement some interface to the
JC> EntityBean that will be a bunch of all the 'get/query' methods of the
JC> EntityBean, and send the interface & the relevant
JC> data copy down to the remote client. That way, we can prevent all the RMI
JC> invocations.
JC> But doing this, we've essentially overridden the good things in EJB, and end
JC> up reinventing stuff.
JC> So, my question to you EJB experts is :
JC> Is our understanding of EJB/ RMI - as described in the argument above ,
JC> flawed ?
JC> How do we solve our problem, and still use all the good things offered by an
JC> EJB container like persistence, scalability , Object querying, naming
JC> integration, etc.
JC> Thanks in advance,
JC> Natraj
JC> --
JC> --------------------------------------------------------------
JC> To subscribe: [EMAIL PROTECTED]
JC> To unsubscribe: [EMAIL PROTECTED]
JC> Problems?: [EMAIL PROTECTED]
JC> --
JC> --------------------------------------------------------------
JC> To subscribe: [EMAIL PROTECTED]
JC> To unsubscribe: [EMAIL PROTECTED]
JC> Problems?: [EMAIL PROTECTED]
JC> --
JC> --------------------------------------------------------------
JC> To subscribe: [EMAIL PROTECTED]
JC> To unsubscribe: [EMAIL PROTECTED]
JC> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
