[1403] in java-interest
Re: Third Party Library Loading
daemon@ATHENA.MIT.EDU (Thomas Ball)
Thu Aug 31 21:03:50 1995
Date: Thu, 31 Aug 1995 15:23:47 -0700
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
To: msfriedm@us.oracle.com
Cc: java-interest@java.Eng.Sun.COM
Let's not confuse what a database vendor considers client code and the
actual implementation of the distributed app. A reasonable alternative
to building in and distributing database access libraries is to create
a "client" application which functions as a server for other clients.
Say I want to create a HotJava applet to update employee records stored
in the company database (employee records are the classic first OO
example, after all :-). I've purchased a client-access library from my
database vendor, Foobar, but it only runs on my Snafu server. After
designing a simple protocol for accessing and updating employee records
(see any beginning OO book), I create an app which translates that
protocol into the appropriate access commands, and link it with the
Foobar client-access library. This app will wait on a specified port
on the Snafu server for its clients.
In Java, I create a protocol class to implement this new protocol, and
create an applet to access it (using the specified port and the
server's hostname). Done!
Note that the neither the Java protocol or applet know anything about
Foobar database access, just your new protocol. That way when Foobar
lives up to its name, you can replace your database server and
client-access program without updating your client sites. Also note
that no libraries were distributed (nothing was distributed, clients
can just access a web page). No HotJava security precautions were
circumvented either.
Tom
> Unfortunately this scheme doesn't deal with one of the most common
> scenarios where you need native code libraries (in particular, it
> probably is the one that the original poster is in), i.e. the case
> where you're interfacing to vendor supplied libraries. In that case
> you don't have the right to send those libraries over the net, let
> alone give the source code (which you probably don't have) to some
> third party.
>
> In some cases, you might be able to convince a vendor to allow their
> code to be dowloaded from some central site(s) either their's or
> third-party's. Hopefully those libraries can be digitally signed,so at
> least we know that it is the real vendor supplied code. Then we just
> have to trust the vendors the way we do now.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
