I would second that. We've done this using SOAP. We have a DataSource::SOAP
driver that acts as a lightweight interface to a Jakarta TomCat server for
the DB stuff. We get the benefits of Perl on the front-end and Java DB
Connection pooling logic/proxying on the middle tier.
Of course I guess you could do the SOAP Server in Perl too, but Java was a
bit easier because we also get built in shared memory caching for
frequently issued queries with the way our particular interfaces work.
Anyway, with SOAP it doesn't matter what language you use for what -- in
theory.
Later,
Gunther
At 07:38 AM 10/27/00 -0700, Randal L. Schwartz wrote:
> >>>>> "Tim" == Tim Bunce <[EMAIL PROTECTED]> writes:
>
>Tim> You could have a set of apache servers that are 'pure' DBI proxy
>Tim> servers. That is, they POST requests containing SQL (for
>Tim> prepare_cached) plus bind parameter values and return responses
>Tim> containing the results.
>
>Tim> Basically I'm proposing that apache be used as an alternative
>Tim> framework for DBI::ProxyServer. Almost all the marshaling code
>Tim> and higher level logic is already in DBI::ProxyServer and
>Tim> DBD::Proxy. Shouldn't be too hard to do and you'd gain in all
>Tim> sorts of ways.
>
>You could also use SOAP or SOAP::Lite as the interface. Most of that
>code seems ready for this kind of application already.
>
>--
>Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
><[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
>Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
>See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
