Forum: Ruby on Rails (no subject)

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Ccaa63b09f5168501b194266b9a1e7cc?d=identicon&s=25 Scott Willson (Guest)
on 2006-02-09 17:41
(Received via mailing list)
My application has one central database + Rails server and many
distributed GUI clients. The remote clients need to read and update
different collections of ActiveRecords. They also need to submit
fairly demanding calculation + database update requests.

Have you designed a similar Ruby application? What did you do?

I'll try to summarize the approachs I'm considering without putting
you to sleep with the details.

Rails Web Service. Built in to the Rails framework. Interoperable
with other applications. Easy to get through firewalls/proxy. But I
don't care about interoperability. How fast is XML marshaling/
unmarshaling? Probably requires that I recreate a subset of my domain
model in Structs.

DRb + DRbUndumped. Send ActiveRecords across as remote proxies. Easy
to set up. Faster than XML. Can re-use ActiveRecord. A bit tricky to
get right -- where is that method being called? Won't every method
call be a remote call in this design? This fine-grained remote
interface approach didn't pan out so well with remote EJBs, to say
the least.

DRb + pass ActiveRecords by value. DRb creates a local copy of each
remote ActiveRecord. Coarse-grained remote interface. Can use
ActiveRecord methods locally for formatting, calculations, etc. Big
drawback: ActiveRecord expects a working database connection. It uses
the database connection to "magically" add association methods at
runtime. Requires considerable ActiveRecord hacking.

DRb + custom remote models. Use "service" classes that convert
ActiveRecords to and from remote-friendly domain classes. Precise
control of what is sent to the remote client. Doesn't try to force
ActiveRecord into something it's not. But we're back to recreating
our domain model again. Maybe I should just crack open my Core J2EE
Patterns book.

XML-RPC/SOAP. XML marshalling and SOAP complexity with all the
drawbacks of the DRb approach.

There's not a lot out there, but the best summary I've found is this

Thanks for any thoughts or feedback!
Eea3feaacbe44706164289d068d94828?d=identicon&s=25 Peter Michaux (Guest)
on 2006-02-19 23:14
(Received via mailing list)
I'm also battling with exactly these options/delemas. Anyone else?

In the last few hours I'm starting to think for an ecommerce site this
might be good

Rails server   <------- HTTP -------->  Browser client for shoppers
                    <------- SOAP -------->  Java Web Start client for
store admin

This means the storefront, which is much simpler than the admin, can
be in HTML/CSS and available to anyone with a browser. This also
avoids all the XML with Hibernate/Struts but has the ease of
deployment and maintanence of Java Web Start client. This might be
reasonable compromise if Rails web services are up to the task.

I'd think this topic was of bigger interest for a few reasons:
1) the incompatibilites of browser support for DHTML
2) the lack of a mature JavaScript GUI library (maybe scriptaculous in
the future)
3) the ability to build nice desktop GUI client app to talk with the
remote database.

It's #2 that made me start looking for alternatives to browser based
solution to website database admin. #2 may not be solved until and #1
is solved.

This topic is locked and can not be replied to.