My understanding is you're just exposing an remote interface
over the web. In the 'Java.pm' world the Java code would actually
be running on the server.
It's up to the client & server to provide authentication, authorization,
and encryption. All of which are orthogonal to the actual
service provided by the server.
As for speed, if the routine runs on the server the only overhead
is the network calls - presumably not much info is passing between
the client & server. Again, in the Java.pm world only a couple
lines of text referencing the server object & the parameters & a line
with a reference to the returned vale. In fact if the server is a lot beefier
than the client & the service is resource intensive you'd get better
performance running service on the server than on the client.
M
------------------------------------------
Mark Ethan Trostler [EMAIL PROTECTED]
Computing Solutions http://www.zzo.com
------------------------------------------
On Mon, 14 May 2001, B. K. Oxley (binkley) wrote:
> From: "Brian Ingerson" <[EMAIL PROTECTED]>
>
> > I had an idea for Inline::Java. Let's say that you had an Inline
> wrapper
> > class inside a Perl module. You should be able to make a distribution
> > (easy with the new Inline 0.40 features) and distribute the module to
> > various people. Then you could run a server script on one machine and
> > have the others use your Inline::Java based module remotely:
>
> Two comments:
>
> 1. This scares the hell out of me for security. Suddenly, Java's
> sandbox won't catch remote code (if I understand your example), and will
> let it run with the priveleges of local code. Very bad for the guys in
> white hats.
>
> 2. Won't the performance bite? Would the module be compiled locally,
> and run from there afterwards, a kind of cache, or would it need to
> refetch the compiled code each time from the server?
>
>
> Cheers,
> --binkley
>
>
