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 (HTML/CSS/JavaScript)
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.
Peter
On 2/9/06, Scott Willson <scott@butlerpress.com>
wrote:> 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
> PDF:
> vanruby.com/system/files?file=20051025-soap4r-
> emil_marceta.pdf
>
> Thanks for any thoughts or feedback!
> Scott