At 03:41 PM 10/27/00 +0100, Matt Sergeant wrote:
>On 27 Oct 2000, (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.
>
>There are some issues still with this architecture, the primary one is
>that SOAP is too heavy weight for anything that seriously needs connection
>pooling for speed issues, especially in Perl (due to the XML parsing speed
>issues).
What we did for our SOAP objects is that we don't use XML Parsing exactly.
The reality is that SOAP parsing with a generic object library is heavy
weight. But if you are supporting only 7-8 method calls, it's really not
bad to write regex that can do all the appropriate parsing with very little
code. Our SOAP drivers have well-defined interfaces and are extremely fast
using IO::Socket, Regex SOAP utility methods (to construct and strip things
like envelope headers).
You might argue that there are more things to go wrong this way and you
would be right. However, method calls are usually quite well defined and
always have the same basic parameter definitions. So as long as you stick
to the well-defined interfaces, it's not bad in practice.
