db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject Re: Vetting Derby. Technical documents?
Date Fri, 07 Dec 2012 02:10:50 GMT
> My company is evaluating whether to use Derby for a desktop/client-server
> application where security and 21-CFR 11 compliance is important.

Although Derby can be used perfectly well as a standalone database, it
is also designed to be embedded into a containing application.

The Derby libraries are small and stable, the memory footprint is
predictable, and many other aspects of Derby favor this embedded usage.

If you thus embed Derby into your application, you can arrange for little
or none of the Derby APIs to be part of the exposed "surface" of your
application, and therefore you can minimize your security exposure.

For example, you say you are designing a client-server application; presumably
Derby is to be part of the server component. But you do NOT need to make
Derby be the *entire* server component. As an alternative design, you could
implement your own completely locked-down web service, which provides
just the APIs that your application client requires, in a highly-secure fashion,
and embed Derby inside your secure web service.

Hope these ideas give you some new perspectives to consider.



View raw message