Web application with no access to database

[Borut Bolčina <bo...@gmail.com>]

Hello,

me again troubling you...

I just read the
http://cwiki.apache.org/confluence/display/CAYDOC/Remote+Object+Persistence+Guidein
search of the solution. If someone read my posting about "Database
replication and caching" this is the continuation of the architectural
question.

Two or more web applications will collect data from users and obviously
should be persisted in database. Those web apps will communicate with
backend java applications (cluster) via RMI calls for some other reasons.
Collected web data represent two Cayenne data objects (one is in the to-one
relationship with the other). If we don't want the web apps to have direct
access to database, this two objects should be passed to backend Cayenne
enabled java application to persist them. As I read the thread
http://www.objectstyle.org/cayenne/lists/cayenne-user/2005/09/0205.html I am
not sure what would be the best approach to take for my case
(entity1----toOne--->entity2). Should I

   - make two value objects (those would be to plain serializable beans?)
   and pass them via RMI call to backend java application to connect them and
   persist them, or
   - create DataContext, insert those to CayenneDataObjects into it,
   serialize DataContext and send it over the RMI to backend java application
   just to commitChanges on received deserialized DataContext, or
   - set up Hessian web service on backend machines to receive requests
   from frontend (web applications) to persist data, or
   - not bother with Cayenne at all on the frontend (web apps) and send
   array of user entered values to backend java application to construct
   Cayenne data objects out of the data and then persist them.

Option two seems most appealing to me, but the last one I think is the least
work, although not as elegant. What do you think?

Regards,
Borut

Re: Web application with no access to database

[Andrus Adamchik <an...@objectstyle.org>]

Hi Borut,

(2) is essentially the same as (3), only this is a case of  
"unsupported remoting", in that it works in theory, but hasn't been  
tested much to iron out any possible wrinkles.

Andrus


On Aug 8, 2006, at 4:51 PM, Borut Bolčina wrote:
> Hello,
>
> me again troubling you...
>
> I just read the
> http://cwiki.apache.org/confluence/display/CAYDOC/Remote+Object 
> +Persistence+Guidein
> search of the solution. If someone read my posting about "Database
> replication and caching" this is the continuation of the architectural
> question.
>
> Two or more web applications will collect data from users and  
> obviously
> should be persisted in database. Those web apps will communicate with
> backend java applications (cluster) via RMI calls for some other  
> reasons.
> Collected web data represent two Cayenne data objects (one is in  
> the to-one
> relationship with the other). If we don't want the web apps to have  
> direct
> access to database, this two objects should be passed to backend  
> Cayenne
> enabled java application to persist them. As I read the thread
> http://www.objectstyle.org/cayenne/lists/cayenne-user/ 
> 2005/09/0205.html I am
> not sure what would be the best approach to take for my case
> (entity1----toOne--->entity2). Should I
>
>   - make two value objects (those would be to plain serializable  
> beans?)
>   and pass them via RMI call to backend java application to connect  
> them and
>   persist them, or
>   - create DataContext, insert those to CayenneDataObjects into it,
>   serialize DataContext and send it over the RMI to backend java  
> application
>   just to commitChanges on received deserialized DataContext, or
>   - set up Hessian web service on backend machines to receive requests
>   from frontend (web applications) to persist data, or
>   - not bother with Cayenne at all on the frontend (web apps) and send
>   array of user entered values to backend java application to  
> construct
>   Cayenne data objects out of the data and then persist them.
>
> Option two seems most appealing to me, but the last one I think is  
> the least
> work, although not as elegant. What do you think?
>
> Regards,
> Borut