I would use Java and possibly OLEDB/ADO/ADO.Net form the public side as the consumers of this info will want it nice and easy and I dont want to spend hours developing a bespoke interface but put the onus on the consumers of the service to get what they need.
Thanks for your comments, much appreciated.
On 7/5/07, Richard Huxton <dev@archonet.com> wrote:Patrick Carroll wrote:
> There has got to be some persistence, there will be a lot of tables and
> metadata and it may have to handle validation requirements for other apps
> doing secure file transfer and a bespoke secure http proxy and it's
> going to
> be a speculative buffer against protocol based worms crossing into the
> production environment.
OK, in that case I would have:
- one PG database for each Oracle/MSSQL database being transferred
- two users for each database being transferred, one "inside", one "outside"
- each user is only allowed to connect to that database from a pre-set
IP address (via pg_hba.conf)
- lock down the permissions for each user appropriately
If you want to go the procedure/function route to access each DB you can
define your DBs as SECURITY DEFINER for operations that need "superuser"
permissions.
I'd use Perl to hook it all together, but you mentioned jdbc, so
presumably you'll be going for Java.
--
Richard Huxton
Archonet Ltd