Добрый день!
У меня такая задача: надо осуществить взаимодействие приложения на Java с различными СУБД (MS SQL, MySQL, Oracle) без использования JDBC. Задачу придумал не я, поэтому советы перестать валять дурака мне пока малополезны .
Может, есть какие-нибудь API-библиотеки фирм-производителей СУБД...
Хотя боюсь, что работа с каждой СУБД через API принесет с собой кучу хлопот

Цитата

Может, есть какие-нибудь API-библиотеки фирм-производителей СУБД...

Для Oracle есть OCI, но она рассчитана на работу с Си, а из Java придется использовать JNI.

Цитата

У меня такая задача: надо осуществить взаимодействие приложения на Java с различными СУБД (MS SQL, MySQL, Oracle) без использования JDBC.

Именно табу на JDBC, или стоит задача абстрагироваться от конкретной СУБД?

Цитата

Для Oracle есть OCI, но она рассчитана на работу с Си, а из Java придется использовать JNI.

Разве это сохранить платформонезависимость?

Цитата

Именно табу на JDBC, или стоит задача абстрагироваться от конкретной СУБД?

Задача абстрагирования стоит давно. С этим пока все проблемы решаются.
А запрет связан с тем, что JDBC не обладает должной надежностью (без комментариев). В общем, как я понял, хочется им обойтись без использования высокоуровневых функций ODBC, JDBC, OLE DB...
Добавлено @ 11:20
Для MySQL нашлось что-то вот здесь: http://www.mysql.com/products/connector/j/.
Надо копнуть глубже...

Цитата

Разве это сохранить платформонезависимость?

OCI реализован для всех платформ на которых работает Oracle. Надо ли будет вносить изменения в Сишную прослойку или достаточно будет ее перекомпилировать под конкретную платформу, я не знаю. А вот Java код можно оставить без изменений. Но работать с OCI то еще удовольствие, библиотека довольно низкоуровневая.
Лучше объясни заказчику, что это весьма трудоемко, а результат может быть хуже чем с JDBC.

Цитата

Для MySQL нашлось что-то вот здесь: http://www.mysql.com/products/connector/j/. Надо копнуть глубже...

Это JDBC-драйвер

. Так точно, на сайте это написано . Есть еще MySQL API для C++ "mysql++".
Не слишком простые пути вырисовываются по грядущей реализации...

Цитата

...А запрет связан с тем, что JDBC не обладает должной надежностью (без комментариев)....

Интересно, а откуда такая информация?

2All А что действительно не обладает?

Цитата(SmaLL @ 25.7.2005, 16:16)

А что действительно не обладает?

Да вообщем-то как любое приложение, которое использует нешифрованный TCP/IP. Весь трафик открыт.

Хотя тот же Oracle по моим сведениям поддерживает в своем драйвере возможность шифрования.

СдаЁтся мне что Рассада будет писать тотже JDBC драйвер только, например, с поддержкой шифрования.

Так надо предварительно посмотреть, может это в драйверах уже есть. Хотя если надо для универсальности, тогда надо делать промежуточный слой для шифрования.

Или организовать VPN внутри подсети.

Я так понимаю у Рассада задача написать мост альтернативный JDBC? Или ему нужно просто обеспечить более высокую надежность? Вообще-то я сомневаюсь, что с мостом у него что-то получится, по-моему гораздо легче и экономнее обеспечить надежность.

Цитата

А запрет связан с тем, что JDBC не обладает должной надежностью

Я понимаю, что требование идет откуда-то сверху и, возможно, из кругов не сильно компетентных, но все же можно поподробнее, что именно подразумевается под "должной надежностью"? Просто слово достаточно многозначное, хотелось бы уточнить.

В любом случае, требование реализовать собственный метод доступа к БД (да еще с условием переносимости между СУБД) есть очевидная и дорогостоящая глупость. Потому что выйдет в итоге тот же JDBC - просто в силу природы взаимодействия ДБ-серверов с SQL-клиентами. Ибо цикл выполнения SQL команды - он и в африке цикл, безотносительно к тому, как называется библиотека доступа: ODBC, JDBC или Vasya Pupkin's Data Access Library

Цитата

СдаЁтся мне что Рассада будет писать тотже JDBC драйвер только, например, с поддержкой шифрования.

SmaLL, мне самому так сдается .

Цитата

Так надо предварительно посмотреть, может это в драйверах уже есть. Хотя если надо для универсальности, тогда надо делать промежуточный слой для шифрования.

1. Точно. 2. Возможный вариант..?
Stampede, под недостаточной надежностью понимается то, о чем сказал
AntonSaburov(как я понял ):

Цитата

Весь трафик открыт.

.

Рассада если тебе надо шифровать трафик, то используй VPN как советовал AntonSaburov, тот же OCI не позволит сам по себе передавать шифрованные данные, только совместно с Oracle Advanced Security. Да и другие низкоуровневые интерфейсы тоже врядли смогут работать с шифрованными данными, если это в них не заложенно изначально.

А если уж никак VPN нельзя, то придется на сервере где стоит СУБД, запускать некого твоего агента, который будет соединяться с БД от имени клиента и передавать ему данные по шифрованному каналу.

Если задача решается шифрованием, можно шифровать данные записываемые в БД.

Тут конечно будет полно побочных эффектов, например перестанет работать сравнение >, <. Но останется ==, !=

Еще можно исключить трафик между приложением и БД по сети посредством сервера приложений, живущего на одном компе с БД. Объекты передаваемые между клиентом и сервером можно шифровать при сериализации.