Как организовать горячий резерв БД
,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель
В некоторых информационных системах требуется обеспечить бесперебойный доступ к БД невзирая на всевозможные сбои и отказы оборудования и программ. Задача придать системе "высокую степень доступности" не имеет единственного решения в ИТ, а вместо этого имеет гамму разных решений, каждое со своими выгодами и ограничениями. Многие из таких решений реализованы и в Oracle рядом специальных конфигураций системы СУБД-БД. Одно из самых доступных - организация "горячего резерва". В Oracle для обозначения горячего резерва используется термин "standby".
Основные принципы горячего резервирования
В общем, принципы организации горячего резерва в Oracle довольно просты:
(1) Организуются две активные БД: одна основная, и другая резервная.
(2) Основная БД работает в режиме архивирования журналов. На возможность подсоединения к ней и на работу с данными никаких ограничений не накладывается.
(3) Резервная БД работает в специальном режиме постоянного восстановления с архивированных журналов, получаемых от основной БД; она все время "догоняет" основную.
(4) Из этого специального режима резервную БД можно перевести в другой, когда она приостановит процедуру восстановления и сможет предоставить свои данные, однако только для чтения. Из этого второго режима мы может вернуться в первый, для нее основной.
(5) Кроме этого, из режима восстановления резервную БД можно перевести в режим обычной полнофункциональной БД, но теперь уже безвозвратно.
Техника "standby" существует в Oracle давно, и в деталях реализации претерпела за прошедшее время несколько изменений. Ниже она будет описана по состоянию для версии 9.0.
Что дает пример ниже
Техника горячего резервирования описана в документации по Oracle. Однако давно замечено (интересно, что и в фирме об этом знают!), что эта документация, за исключением избранных мест, не может служить толковым учебником. К горячему резервированию это относится в полной мере.
С другой стороны есть целый ряд статей, где методично рассказано, как организовать standby database. Однако они все или относятся к Unix, и/или содержат ошибки - по крайней мере те, что попадались мне на глаза.
Пример организации резервного копирования ниже
а) относится к платформе Windows, то есть наиболее демократичен в смысле аудитории
б) не требует наличия второй машины (что, в общем, бестолково для реальной практики, но вполне нормально, и даже удобно, для знакомства)
в) не содержит ошибок.
Пользователи на платформе Unix, как правило, более продвинутые, без особого труда внесут в приводимый пример необходимые правки.
Постановка задачи и план решения
Пусть имеется БД teacher.class (использовано глобальное именование БД). Создадим для нее резервную БД с именем sb.class (имя sb часто используется в таких примерах, но это - чистая условность). Она будет работать на той же машине, что и teacher.class. Расположения каталогов будем считать OFA-удовлетворительным.
Для teacher.class должна иметься копия БД (проще, если холодная) и должен быть включен режим архивации. Если этого нет, перед выполнением примера нужно об этом позаботиться.
Вот, для определенности, выдержка из файла INIT.ORA для teacher.class в исходном состоянии:
|
background_dump_dest=d:\oracle\admin\teacher\bdump core_dump_dest=d:\oracle\admin\teacher\cdump user_dump_dest=d:\oracle\admin\teacher\udump db_domain="class" global_names = true remote_login_passwordfile=EXCLUSIVE compatible=9.0.0 db_name=teacher instance_name=teacher ################################## log_archive_start = true log_archive_dest = "e:\oracle\oradata\teacher\archive" log_archive_format = teachers%s.arc |
Подготовка основной БД к работе в спарке с резервной
Клонирование основной БД и формирование из полученного клона резервной БД
Конфигурирование сетевых компонент Oracle Net для возможности общения двух БД друг с другом
Запуск резервной БД в рабочем режиме
Подготовка места для резервной БД
Сначала резервная БД создается клонированием основной, затем мы "вдохнем в нее жизнь" и запустим в режиме восстановления. Поэтому прежде всего для sb.class нужно подготовить место на диске.
В нашем примере это каталог d:\oracle\admin\sb с подкаталогами udump, bdump, cdump и pfile, а также c:\oracle\oradata\sb - их нужно завести.
Еще не забудем завести каталог e:\oracle\oradata\sb\archive для хранения собственных архивов sb.class (на будущее, когда эту базу переведут в основной режим) и каталог e:\oracle\oradata\sb\teacher_archive для приема архивов от teacher.class.
Готовим основную БД
Подправим INIT.ORA для teacher.class:
|
background_dump_dest=d:\oracle\admin\teacher\bdump core_dump_dest=d:\oracle\admin\teacher\cdump user_dump_dest=d:\oracle\admin\teacher\udump db_domain="class" global_names = true remote_login_passwordfile=EXCLUSIVE control_files=("c:\oracle\oradata\teacher\control01.ctl") compatible=9.0.0 db_name=teacher instance_name=teacher ################################## log_archive_start = true #####log_archive_dest = "e:\oracle\oradata\teacher\archive" log_archive_dest_1 = "location=e:\oracle\oradata\teacher\archive" log_archive_format = teachers%s.arc log_archive_dest_state_1 = enable log_archive_dest_2 = "service=sb.class" log_archive_dest_state_2 = enable log_archive_min_succeed_dest = 1 fal_client = "sb.class" |
Во-первых, от параметра LOG_ARCHIVE_DEST (сохраненному для совместимости) мы перешли к более современному LOG_ARCHIVE_DEST_1. Параметры LOG_ARCHIVE_DEST_N в последних версиях Oracle задают направления копирования освободившихся журналов в архив, а параметры LOG_ARCHIVE_DEST_STATE_N позволяют имеющиеся направления "включать" и временно "отключать".
В нашем случае к старому архиву e:\oracle\oradata\teacher\archive добавилось как раз еще одно такое направление, но уже не в виде каталога, как раньше, а в виде БД, которой teacher.class будет пересылать свои журналы.
Параметр FAL_CLIENT = "sb.class" уточняет, что это будет резервная БД sb.class и что пересылка будет автоматической.
Остановим основную БД и выдадим в SQL*Plus:
STARTUP PFILE=?/database/initteacher.ora
ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'c:\oracle\oradata\sb\control01.ctl';
ALTER SYSTEM ARCHIVE LOG CURRENT;
SHUTDOWN
То есть мы приготовили контрольный файл для резервной БД и зафиксировали точку отсчета для пересылки архивируемых журналов на sb.class.
Готовим клон для резервной БД
Копируем все файлы БД teacher.class, кроме контрольного, в c:\oracle\oradata\sb. Контрольный там уже есть.
Копируем INIT.ORA БД teacher.class в d:\oracle\admin\teacher\pfile. Правим его:
|
background_dump_dest=d:\oracle\admin\sb\bdump core_dump_dest=d:\oracle\admin\sb\cdump user_dump_dest=d:\oracle\admin\sb\udump db_domain="class" global_names = true remote_login_passwordfile=EXCLUSIVE control_files=("c:\oracle\oradata\sb\control01.ctl") compatible=9.0.0 db_name=teacher instance_name=sb ################################## log_archive_format = teachers%s.arc db_file_name_convert = "\ORADATA\TEACHER", "\ORADATA\SB" log_file_name_convert = "\ORADATA\TEACHER", "\ORADATA\SB" standby_archive_dest = "e:\oracle\oradata\sb\teacher_archive" log_archive_dest = "e:\oracle\oradata\sb\archive" lock_name_space = sb fal_server = "teacher.class" |
Параметры DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT нужны только если структуры каталогов основной и резервной БД не совпадают. В нашем случае, когда обе БД работают на одной машине, это неизбежно. Когда обе БД работают на разных машинах, проще использовать одинаковую структуру каталогов и об этих параметрах забыть.
Параметр STANDBY_ARCHIVE_DEST указывает на каталог, куда "принимающая сторона" sb.class будет складывать поступающие от teacher.class архивные копии журнала.
Параметр LOG_ARCHIVE_DEST задает каталог- архив уже для своих изменений sb.class (на будущее).
Параметр LOCK_NAME_SPACE нужен только в нашей не типичной для практики ситуации, когда обе БД будут работать на одной машине; без него две СУБД не смогут одновременно общаться с разными БД, имеющими одинаковые имена.
Наконец, параметр FAL_SERVER симметричен FAL_CLIENT в INIT-файле для teacher.class.
Копируем из e:\oracle\oradata\teacher\archive в e:\oracle\oradata\sb\teacher_archive последний по времени архивированный файл.
Обеспечиваем взаимодействие по Oracle Net
Нужно ненадолго отвлечься от резервной БД и подправить файлы listener.ora и tnsnames.ora, чтобы обе СУБД могли общаться. У нас будет автоматическая пересылка файлов на резервную БД (а могли бы этого не делать и переносить архивные файлы вручную, но это не очень интересно), и для этого основная база должна уметь соединяться с резервной. Нужные конфигурационные файлы у нас находятся в одном месте: в %oracle_home%\network\admin, а в "боевых условиях" они будут разнесены по разным машинам. Добавляем в listener.ora фрагмент:
|
(SID_LIST = (оставить, как было) (SID_DESC = (GLOBAL_DBNAME = teacher.class) (ORACLE_HOME = c:\oracle\ora90) (SID_NAME = sb) ) ) |
В файл tnsnames.ora добавляем
|
sb.class = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = wsa46)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = sb) ) ) |
Теперь резервную БД нужно "оживить". Войдем в консольном окошке ОС в каталог %oracle_home%\database. Скопируем initteacher.ora в initsb.ora и подправим в initsb.ora ссылку на файл: IFILE='c:\oracle\admin\teacher\pfile\init.ora' заменим на IFILE='c:\oracle\admin\sb\pfile\init.ora'.
Создадим файл пароля для sb.class:
orapwd file=PWDsb.ora password=change_on_install
Заведем службу ОС для sb.class:
oradim -new -sid sb -startmode m -pfile c:\oracle\ora90\database\initsb.ora
"Приводим" резервную БД "в чувство" и переводим в режим автоматического подката по получаемым файлам журналов. Выдаем в SQL*Plus:
CONNECT sys/change_on_install AS SYSDBA
STARTUP MOUNT PFILE=?/database/initsb.ora
RECOVER MANAGED STANDBY DATABASE
В этом месте SQL*Plus "зависает", но так и должно быть. Уходим из этого окошка, но не закрываем его.
Проверка
Теперь можно для наглядности вывести на экран два окошка с содержимым каталогов e:\oracle\oradata\teacher\archive и e:\oracle\oradata\sb\teacher_archive соответственно.
Запускаем снова основную БД в окошке с SQL*Plus, где мы эту базу останавливали:
STARTUP PFILE=?/database/initteacher.ora
Выдадим несколько раз
ALTER SYSTEM SWITCH LOGFILE;
Если все было проделано без ошибок, в обоих окошках с каталогами можно наблюдать появление одних и тех же архивных копий журнала, причем с запаздыванием: сначала в одном, потом в другом. Это свидетельствует о том, что архивные копии реально пересылаются на резервную БД.
Еще для проверки можно запустить и процесс внесения в основную БД фактических изменений, в результате чего журнальные файлы начнут переключаться самостоятельно. Для нас результат должен быть тем же самым.
Перевод резервной БД в состояние, допускающее выборку
Откроем новое консольное окошко, где выдадим в SQL*Plus:
CONNECT sys/change_on_install@sb.class AS SYSDBA
RECOVER MANAGED STANDBY CANCEL
EXIT
Вернемся в прежнее окошко с резервной БД и увидим, что сеанс SQL*Plus в нем "отвис". Сейчас архивные копии продолжают поступать в резервную БД, однако сама база уже не подкатывается. Наберем
ALTER DATABASE OPEN READONLY;
Теперь из резервной базы можно делать выборки данных.
Возврат резервной БД в режим подката
В этом же последнем окошке набираем:
CONNECT sys/change_on_install AS SYSDBA
SHUTDOWN
STARTUP MOUNT PFILE=?/database/initsb.ora
RECOVER AUTOMATIC STANDBY DATABASE
CANCEL
RECOVER MANAGED STANDBY DATABASE
Как и прежде, тут мы "зависаем".
Перевод резервной БД в рабочее состояние
Вначале поступаем, как и прежде, а потом - иначе. В новом окошке выдадим в SQL*Plus:
CONNECT sys/change_on_install@sb.class AS SYSDBA
RECOVER MANAGED STANDBY CANCEL
ALTER DATABASE RECOVER STANDBY DATABASE;
ALTER DATABASE RECOVER CANCEL;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
Теперь правильнее всего будет остановить бывшую резервную, а отныне - рабочую БД, снять с нее холодную копию, проделать необходимые правки в файлах Oracle Net и запустить базу снова и подготовить для нее новый резерв. После этого можно будет использовать ее в рабочем режиме.
Интервью Сергея Кузнецова с Вадимом
Nov 2005, Moscow
Добрый день, господин Розенберг! Меня зовут Сергей Кузнецов. Сейчас я представляю компанию ЦИТ Форум, которая здесь в России поддерживает крупнейший сайт, научно-техническую библиотеку по информационным технологиям. Мои личные интересы в основном связаны с технологией баз данных, но я интересуюсь и информационными технологиями вообще. Большое Вам спасибо за то, что Вы согласились дать мне это интервью. Я постарался подготовить вопросы, касающиеся не столько базовых технологий компании Oracle, сколько новых веяний, которые существуют в этой компании. С Вашего разрешения я начну задавать Вам вопросы.
Как мне кажется, в последние годы, может быть, в последние пять-шесть-семь лет немного изменилась ситуация с разделением труда в индустрии программного обеспечения. Раньше было больше специализации, т.е. такие компании, как Oracle, IBM, Informix и т.д. производили базовые программные средства для управления данными. Такие компании, как BEA Systems, Logic Works и т.д. обеспечивали промежуточное программное обеспечение (middleware): мониторы транзакций, системы управления очередями и т.д. В последние годы ситуация как-то изменилась, и все большее число крупных компаний, таких как Microsoft, IBM, Oracle, производит крупные программные комплексы, которые включают в себя очень много разнообразного программного обеспечения. Мой первый вопрос: имеются ли у этого процесса технические причины, или они, большей частью, обусловлены маркетинговыми соображениями, например, стремлением к убыстрению и упрощению выхода на рынок новых продуктов? Чего здесь больше?
Причин для этого несколько. В первую очередь, это технологические причины. Клиентам гораздо легче внедрить у себя решение, которое интегрировано с начала до конца, от самых низких уровней программного обеспечения до самых высоких уровней, от баз данных через middleware до порталов и приложений. Естественно, для клиентов большой плюс, когда они покупают готовое интеграционное решение и не обязаны тратить огромные время и деньги на интеграцию самой интеграционной платформы. При наличии потребности в компонентах, обеспечивающих безопасность, обмен сообщениями, транзакции и т.д., если эти компоненты поставляются разными производителями и, в худшем случае, соответствуют разным стандартам, то для заказчиков вся эта интеграция превращается в настоящее мучение.
Это направление полностью соответствует видению крупнейших аналитиков. Например, компания Gartner Group недавно опубликовала прогноз, что в 2007 г. более 75% корпоративного программного обеспечения будет продаваться именно такими поставщиками интегрированных платформ, а не отдельными производителями каких-то конкретных компонентов. Этот процесс происходит по массе причин, как маркетинговых, так и технических. Естественно, производителю удобно иметь контроль над платформой, когда можно вложить средства и проинтегрировать компоненты сегодня, вместо того чтобы потом работать с клиентами и пытаться каким-то образом слепить систему из разных кусочков.
Вы уже частично ответили и на мой следующий вопрос. Понятно, что когда предоставляется некоторый интегрированный набор инструментов, его проще освоить. А какие-нибудь еще преимущества получают потенциальные заказчики?
Заказчики получают огромное количество преимуществ. Теперь они должны иметь дело с одним поставщиком. Когда поддержка происходит из одного источника, клиент не должен звонить по разным телефонам и общаться с разными представителями групп технической поддержки базы данных, сервера приложений, портала, продукта поддержки безопасности или средства разработки.
Десять лет назад клиент должен был думать о том, где набрать лучшие компоненты. Он должен был звонить в Oracle по вопросам, относящимся к базам данных, в BEA - по вопросам относительно сервера приложений, в Borland - в связи со средствами разработки, в Oblix - при возникновении проблем с продуктами безопасности и в Siebel - при проблемах с приложениями.
Сегодня такие крупные поставщики, как Oracle и IBM, в меньшей степени BEA, ставят своей целью именно предоставление полного спектра решений, когда клиент может иметь дело только с одним поставщиком. В частности, Oracle за счет приобретения готовых решений (как в случае, например, с Oblix и Siebel) или разработки собственной технологии с требуемой функциональностью (например, сервер приложений и среда разработки JDeveloper) Oracle может предложить все нужные компоненты в составе единой платформы.
Я согласен, что call-центр в компании получается один, имеется одна точка входа. Но мне плохо верится, что можно обеспечить централизованную службу поддержки, потому что при наличии большого разнообразия продуктов невозможно найти двух-трех специалистов, которые смогут ответить на все возможные вопросы. Что Вы думаете по этому поводу?
С одной стороны, это действительно так. Но, с другой стороны, когда происходит цикл продажи или уже цикл поддержки, и когда люди принадлежат одной организации, между ними гораздо больше синхронности и гораздо проще коммуникации. Я, например, помню, что когда я работал в BEA, у нас имелись проблемы в понимании того, как разделить поддержку. Например, люди звонили по вопросу драйвера базы данных. BEA баз данных не предоставляла. База данных была или Oracle, или Microsoft SQL Server, или DB2. Проблема была с драйвером. С одной стороны, драйвер - это вроде бы часть сервера приложений, которая в нем работает, но, с другой стороны, это интерфейс базы данных. Сегодня по таким вопросам человек позвонит в Oracle, и ответ будет найден гораздо проще, потому что мы владеем ...
Более короткой цепочкой?
Да, более короткой цепочкой. И мы больше заинтересованы в том, чтобы не перекинуть вопрос другому поставщику, а решить все возникающие проблемы.
Спасибо. Следующая группа вопросов задевает то, что всегда интересовало меня в наибольшей степени. Я привык (в частности, на примере BEA Systems) к тому, что middleware всегда старались делать максимально, предельно независимым от конкретных систем управления базами данных, чтобы при желании можно было использовать соответствующий продукт любого производителя. Насколько глубок уровень интеграции Oracle Fusion с СУБД Oracle? Действительно ли принципиально требуется использовать именно эту СУБД?
Прежде всего необходимо разделить два понятия. К сожалению, на сегодняшний день на рынке существует некоторое непонимание различия между Oracle Fusion и Oracle Fusion Middleware. Oracle Fusion Middleware - это единая интегрированная платформа программ-посредников (если не пользоваться термином middleware), которая предоставляет набор стандартных программных сервисов, начиная от баз данных, поддержки безопасности, объектной модели, поддержки транзакций, поддержки обмена сообщениями и распространяясь на порталы, среды разработки и т.д. Это то, что называется middleware. И Oracle сегодня консолидировал все эти множественные продукты под общим названием Oracle Fusion Middleware.
Вообще говоря, во Oracle Fusion Middleware не существует жесткой привязки к СУБД Oracle, потому что, если говорить, например, о сервере приложений, являющемся частью Fusion Middleware, то этот сервер полностью соответствует стандарту J2EE 1.4, и мы можем использовать любую базу данных, для которой существует драйвер JDBC. И многие другие продукты, которые включены в платформу Oracle Fusion Middleware, как, например, продукт подержки безопасности от компании Oblix, которую мы недавно купили, тоже независимы от базы данных.
С другой стороны, в составе Oracle Fusion Middleware имеются некоторые продукты, в которых оракловская база данных зашита внутри. Для чего это сделано? Во-первых, для этого, конечно, существуют исторические предпосылки, но более важной причиной является то, что с помощью непосредственного глубокого соединения с базой данных можно обеспечить лучшую пропускную способность и т.д. Это уже не JDBC, не ODBC, а соединение напрямую, и, естественно, это дает клиентам преимущества, но, конечно, лишает их определенной степени гибкости.
Что здесь происходит? Обычно, если компонентам Oracle Fusion Middleware требуется именно оракловская база данных, то на нее не требуется отдельная лицензия, она встроена и включена в эти компоненты, а когда появляется техническая возможность замены базы данных, клиент имеет полную свободу выбора.
Хорошим примером служит BPEL - продукт для управления бизнес-процессами, workflow и предоставления общей интеграционной платформы в рамках сервисно-ориентированной архитектуры. Внутри BPEL требуется некоторая функциональность для хранения состояний. На начальном этапе в Oracle BPEL Process Manager использовалась облегченная версия базы данных Oracle. В настоящее время доступна полная версия BPEL, в которой для хранения состояния используется встроенный компонент "dehydration store", основанный на базе данных Oracle. Я знаю, что сейчас ведутся работы по раскрытию этого компонента. Это, наверное, один из немногих примеров, когда база данных действительно требуется, и требуется именно оракловская база данных, хотя, в принципе, при определенном правильном подключении можно использовать и MS SQL-server. Я не знаю, обеспечивается ли сейчас соответствующая поддержка этого продукта, но абсолютно точно могу сказать, что такие возможности будут существовать.
Другой интересный аспект состоит в том, что сам Oracle BPEL может работать на любом другом сервере приложений, не обязательно на Oracle Application Server. Т.е. идея состоит в том, чтобы все компоненты Oracle Fusion Middleware не были жестко завязаны один с другим.
Так вот, то, о чем что я сейчас говорил, - это Oracle Fusion Middleware. Что же такое проект Oracle Fusion? Это - будущее направление развития оракловских приложений, которое будет основано на Oracle Fusion Middleware. Что касается этого направления, то снова есть некоторые продукты, которые включают в себя оракловскую базу данных как необходимый элемент, потому что так они были построены исторически. И опять-таки клиент в таких случаях не должен даже задумываться о том, какая там внутри база данных, потому что она встроена в продукт, она устанавливается вместе с продуктом; это как черный ящик: он закрыт. Когда же у клиента имеется возможность сделать выбор в отношении базы данных, то этот выбор, в принципе, снова раскрыт для любых баз данных, которые существуют в настоящее время. И чем дальше оракловские приложения будут двигаться в направлении Fusion, тем больше будет происходить это раскрытие - потому что сама по себе платформа Fusion определит раскрытость оракловских приложений, потому что вся она основана на стандартах, на сервисно-ориентированной архитектуре. При использовании таких стандартов, как J2EE, для среды выполнения или объединения компонентов приложения в Web-сервисы практически не будет иметь значения, какая база данных используется, потому что все особенности конкретной базы данных будут скрываться Web-сервисами.
Т.е., если я правильно понимаю, идея такая - фиксируется та часть базы данных, которая не представляет внешнего интереса, которая служит именно как хранилище для внутреннего использования. То, что может быть использовано для построения внешнего хранилища данных, должно быть открыто, и по отношению к таким элементам должна существовать свобода выбора.
Да.
В общем, это понятно и логично. На самом деле, Вы уже частично ответили и на следующую пару вопросов: можно ли интегрировать какие-либо компоненты Oracle Fusion Middleware с продуктами категории middleware других производителей? Можно ли интегрировать решения, построенные, например, на основе Oracle Fusion Middleware и IBM WebSphere?
Что касается этого вопроса, то многие продукты, я бы сказал, практически все продукты, являющиеся компонентами платформы Oracle Fusion Middleware, вовсе не обязательно должны использоваться вместе с другими продуктами из оракловской платформы. Идея состояла в том, чтобы создать нечто подобное ресторанному меню. Т.е. да, все компоненты проинтегрированы вместе, да, все они основаны на одной общей технологии, а именно, Java, J2EE, Web-сервис, XML и т.д., но при этом большинство компонентов может работать на любом другом сервере приложений, или с использованием другого продукта поддержки безопасности, или, например, передавать данные на другой портал и т.д. И это потому, что все основано на стандартах.
Можно привести пример интеграции компонентов Oracle Portal и Oracle BPEL Process Manager. С использованием оракловского же продукта JDeveloper с помощью одного-двух кликов можно проинтегрировать бизнес-процесс и сделать из него портлет. И этот портлет будет сразу доступен через Oracle Portal. Но портлет, который генерируется этим продуктом, основан на стандартах JSR 168 и WSRP (Web Services for Remote Portlets), и благодаря поддержке этих стандартов этот портлет может быть установлен на любом портале. Естественно, и этот портал должен быть основан на стандартах, потому что иначе на нем вряд ли кто-либо сумеет что-либо разместить, кроме самого его производителя.
Это и определяет наше основное направление - основываться на стандартах. Потому что все поставщики, включая Oracle, в прошлом уже пробовали все делать по-своему. Обычно из этого не получалось ничего хорошего, за исключением редких случаев, когда технология была ориентирована на достижение каких-то очень конкретных целей, когда имелись особые требования к производительности или уровню готовности и т.д.; в этих случаях, возможно, какие-то проприетарные технологии и имели смысл. Но когда мы говорим об информационных технологиях для предприятий, для бизнеса, для широкого внедрения, сегодня стандарты - это путь к открытости и эффективности.
Я уже говорил, что такой фундаментальный компонент Oracle Fusion Middleware, как BPEL, прекрасно работает на всех основных серверах приложений; у нас есть клиенты, которые используют BPEL на WebLogic, на WebSphere и даже на JBoss. И практически все основные компоненты платформы Fusion Middleware могут использоваться на любых серверах приложений, в том числе и компоненты поддержки безопасности - это еще один пример, когда мы просто увидели лидера и купили компанию (Oblix), но поскольку она была долгое время независимой, то, естественно, свою технологию строила как открытую для разных платформ, и мы унаследовали от нее эту открытость.
Итак, что касается интеграции с продуктами других производителей, то если они основаны на стандартах, проблем не возникает. Это могут быть даже не официальные стандарты, а стандарты де-факто, как, например, у продукта MQSeries компании IBM. Это, может быть, и не стандарт, но у него открытый и известный интерфейс.
Я абсолютно с этим согласен, и всю жизнь, можно сказать, тоже ратовал за стандартизацию в области информационных технологий, но тогда мне хотелось бы спросить Вас: насколько Вы удовлетворены состоянием стандартизации в этой области?
Да, конечно, здесь всегда существует противоречие между тем, что хочется, и тем, что можется. И вот когда то, что хочется, отличается от того, что существует, то нужно вводить новые стандарты. Компания Oracle сегодня вовлечена во все основные комитеты по стандартизации, начиная от J2EE и кончая OASIS и W3C и т.д. И Oracle ведет огромное количество этих стандартов - и в мире J2EE, и в мире порталов и т.д. Вообщем-то, эта тема заслуживает отдельного разговора, но факт в том, что стандарты должны кем-то продвигаться, они сами по себе не возникают и сами по себе не развиваются. Когда крупные поставщики типа Oracle (так же поступают IBM, BEA и другие компании) видят спрос на рынке на определенную технологию, они, естественно, пытаются эту технологию сначала разработать, а потом внедрить ее как стандарт.
Ну что ж, мы отчетливо видем этот подход на примере процесса стандартизации технологии SQL.
Да, а потом крупные поставщики типа Oracle говорят, что мы кооперируемся c другими компаниями в области стандартов, но конкурируем в области реализации этих стандартов.
Ярким примером является BPEL. BPEL - это не оракловский стандарт, он изначально был разработан объединенной группой инженеров из IBM и Microsoft. Стандарт разрабатывался в течение 10 лет, и существовало много параллельных вариантов стандартов для управления бизнес-процессами. Например, компания BEA продвигала свой собственный стандарт, называвшийся Process Definition for Java, который они воплотили в своем продукте. Но, очевидно, люди из BEA неправильно почувствовали требования рынка и направление стандартизации, и предлагаемая ими спецификация осталась воплощенной только ими, только одним поставщиком, и сегодня они отчаянно пытаются двигаться в сторону BEPL. Естественно, это нелегко - перестроить продукт, существующий уже много лет.
В то же время, в Oracle пару лет назад поняли, что BPEL - это то, чего сегодня хотят клиенты, то, что видится как будущее направление информационных технологий в области управления бизнес-процессами и т.д. И компания Oracle приняла сознательное решение - приобретение компании Collaxa, которая в то время являлась лидером в области BPEL. Это произошло около двух лет тому назад, и на сегодняшний день BPEL является такой же неотъемлемой, фундаментальной и проинтегрированной частью Oracle Fusion Middleware, как и все остальное. Т.е. очень важно еще правильно почувствовать, куда дует ветер, в какую сторону двигаются стандарты, потому что во многих областях имеется много предложений для стандартизации.
Меня очень часто спрашивают, поддерживает ли Oracle тот или иной конкретный стандарт? И мой обычный ответ состоит в том, что не все, что существует вокруг, не все спецификации, не все описанные интерфейсы нужно называть стандартами. Спецификация должна зарекомендовать себя в качестве стандарта. По началу это еще не стандарт, а лишь предложение на стандарт. И поэтому крупные поставщики, такие как Oracle, не должны прыгать на первый попавшийся поезд и следовать любому стандарту, потому что это приведет только к путанице на рынке. Такие крупные компании, как Oracle, могут позволить себе быть более медлительными в воплощении каких-то суперновых стандартов, потому что должно пройти определенное время, пока станет понятна жизнеспособность и востребованность этого направления. Но, с другой стороны, как только это становится понятно, именно у таких компаний, как Oracle, имеются фонды и бюджет для быстрого внедрения соответствующей технологии с помощью покупки компании, которая уже разработала лучшее решение в этом направлении, что мы и проделали с Collaxa, с Oblix и, очевидно, будем делать во многих других случаях.
Кроме того, имеется возможность инвестирования в другие привлекательные технологии и их собственной разработки. В качестве примеров можно привести продукты Oracle Enterprise Services Bus, Business Rules engine, Portal. Примером нового стандарта, продвигаемого компанией Oracle (в партнерстве с другими ведущими производителями), является Push Mail (P-IMAP). Целью этой технологии является обеспечение согласованного стандарта, позволяющего принимать сообщения электронной почты на беспроводных устройствах любого типа с так называемом режиме "проталкивания" ("push mode") (в отличие от режима "опроса" ("polled mode")). Сегодня такая технология обеспечивается проприетарным образом популярной в США компанией Blackberry. Oracle и группа других поставщиков создают технологию и продвигают стандарт, чтобы сориентировать рынок в этом направлении. Это хороший пример ситуации, когда такая большая и мощная компания, как Oracle, занимает финансовую и техническую позицию, позволяющую влиять на направление развития рынка.
Вы совершенно справедливо сказали, что одним из компонентов всей этой технологии, связанной с управлением бизнес-процессами, workflow и т.д., является XML; все сообщения представляются в формате XML и т.д. У Oracle имеются очень серьезные продвижения в области управления XML-данными средствами основного сервера баз данных. Но коль скоро на этом уровне ничего, кроме XML, не требуется, не слишком ли дорого содержать там полный сервер Oracle?Не стоит ли на уровне, который касается управления бизнес-процессами и т.д., пользоваться какой-либо более дешевой, легкой Native XML-СУБД?
В принципе, я не думаю, что в этом случае клиенты обязаны использовать именно оракловский компонент. По мере появления соответствующих средств управления XML-данными можно переключаться на их использование. Однако следует задуматься о целесообразности таких шагов.
Когда в начале интервью мы говорили о консолидации программных продуктов, я не затронул еще один очень важный момент, относящийся к жизнеспособности мелких поставщиков. Когда большая компания, например, крупный банк или крупный производитель автомобилей, выбирает решение для своей интеграционной платформы на много лет вперед, ее руководители хотят быть уверенными, что поставщик, с которым они имеют дело, останется в бизнесе еще 10-15 лет, и для них довольно рискованно пользоваться услугами каких-то мелких поставщиков, даже если в их технологии на сегодняшний день воплощены некоторые функциональные возможности, пока отсутствующие в продуктах Oracle или IBM. Что будет с этими многочисленными XML-репозиториями, которые существуют сегодня, завтра, через 2 года, через 3 года? Да, существует шанс, что их купит те же Oracle или IBM, и тогда все нормально, но гораздо больше шансов на то, что их просто не будет. И что тогда делать с поддержкой этих репозиториев? Особенно, если данные в них хранятся в каком-то особом внутреннем формате.
Решение о выборе программного продукта обычно принимается на уровне стратегических IT-решений и часто основывается в большей степени на бизнес-соображениях. При наличии очень многих технических возможностей, пригодных для подобного рода задач, более надежно пользоваться продуктами и услугами крупного поставщика, такого как Oracle, который с большой вероятностью останется в бизнесе еще много лет и будет с большим или меньшим успехом предоставлять корпоративные решения, лидировать в этой области наряду с компаниями IBM, HP, Microsoft - естественно, никто из них тоже не уйдет из бизнеса в ближайшее время.
В то же время, компании среднего уровня, даже такие, как BEA, сегодня теряют темп развития именно потому, что они не в состоянии быстро реагировать на требования рынка. Они не в состоянии так распоряжаться бюджетом, так планировать свои разработки как, например, это может делать компания Oracle, которая сегодня может вложить гигантскую сумму, например, в телекоммуникационный рынок (Oracle очень сильно продвигается в область предоставления телекоммуникационных решений). А что значит вложить средства? Это значит купить какие-то компании, являющиеся ключевыми производителями каких-то конкретных функций, которые могут сразу поставить нас в лидирующую позицию. Кроме того, нужно еще вложить огромные деньги в создание новой внутренней команды разработчиков, которая реализует недостающие функции. Более мелкие производители просто не могут себе это позволить.
Около трех лет назад мне пришлось участвовать в нескольких попытках инициации проектов автоматизации бизнес-процессов в российских государственных организациях. Тогда у меня создалось впечатление, что российские государственные структуры не готовы к принятию технологий уровня workflow. Что думают по этому поводу в Oracle сегодня?
Боюсь, что я не в курсе всех деталей. Может быть, мне поможет присутствующий здесь Владимир Алексеев, руководитель направления Oracle Fusion Middleware Oracle СНГ?
Владимир Алексеев: В секторе государственных структур соответствующие технологии Oracle активно продвигает компания Форс.
Насколько я понимаю, речь идет о некотором проекте для московского правительства. Мне кажется, что в Москве ситуация все-таки проще, чем в других регионах России.
В.А.: Да, этот проект базируется на BPEL, и, конечно, Москва во всех отношениях - и в отношении финансов, и в отношении общего уровня используемых информационных технологий, и в отношении общего понимания технологических потребностей - находится на более высоком уровне, чем большинство других регионов.
Вадим Розенберг: Я думаю, что так или иначе российские государственные структуры воспримут технологию автоматизации бизнес-процессов, поскольку это общемировая тенденция. Еще раз повторю, что мне трудно оценивать состояние российского рынка, но я могу привести характерный пример из жизни государственных ведомств США.
Одним из наших клиентов являются Вооруженные силы США (US Army), которые могут конкурировать с российским правительством по уровню бюрократии, распределенности управления и т.д. Они внедрили BPEL для управления всеми своими жилыми, складскими и промышленными ресурсами. Все процессы по выделению ресурсов, утверждению распоряжений, определению текущего местоположения и т.д. реализованы на основе BEPL. И мне кажется, что этот вариант использования BPEL очень похож на те, которые требуются правительственным организациям.
В.А. Да, у нас имеется много примеров. В частности, в администрациях нескольких голландских городов, включая Роттердам, тоже внедрена технология BPEL для работы с населением, управления бизнесом. И я думаю, что в России это должно начинаться именно с крупных муниципальных образований, таких как Москва и Санкт-Петербург. Их правительства опробуют технологию, определят то, что их устраивает, и то, что нуждается в доделках, и станут лидерами, способствующими распространению технологии автоматизации бизнес-процессов в регионах.
Подходя к концу нашей беседы, мне очень бы хотелось услышать от Вас о ключевых преимуществах, которые обеспечивает Oracle Fusion Middleware, может быть, в сравнении с продуктами основных конкурентов.
Хорошо, начнем с компании Microsoft. Microsoft действительно предоставляет довольно обширные и хорошо проинтегрированные решения. Я бы сказал, что степень интеграции решений Microsoft в их платформах может служить примером для всех, включая Oracle: лучше проинтегрировать просто невозможно (конечно, я говорю про MS Office и среду Windows). Почему так сложилось и какие у этого недостатки? Я думаю, что ответить на этот вопрос очень просто. Когда поставщик имеет дело с одной операционной системой, с одним типом аппаратуры, с одной кодовой линией практически для всех продуктов, то вопрос интеграции как бы решается сам по себе, но это отрицательно влияет на открытость и на возможность внедрения разного рода лучших решений. Если ты становишься клиентом Microsoft, то это надолго, разве что ты примешь какие-то абсолютно радикальные решения что-то полностью изменить. Ты становишься зависимым и по линии аппаратуры, и по линии операционной системы, и т.д.
Вторую отрицательную характеристику Microsoft я бы определил следующим образом. Безусловно, я весьма уважаю эту компанию, как первого и, собственно, единственного на сегодняшний день поставщика программного обеспечения малого и среднего уровня для всего мира. Действительно, существует совсем немного компаний, про которые можно сказать, что они обеспечили возможностью работы на компьютерах людей всего мира! Но при этом для высоконадежных и высокопроизводительных приложений, требуемых в мире корпоративного бизнеса, Microsoft все еще не в состоянии конкурировать с такими поставщиками как Oracle и IBM (и, в меньшей степени, с BEA). И причина в том, что основная компетенция компании, тем не менее, осталась на уровне настольных компьютеров.
Да, продукты Microsoft, конечно, могут сегодня исполняться на разного рода blade-серверах и мультипроцессорных системах, но опять-таки все это ограничено Windows, это все изначально, глубоко внутри основано на тех же решениях, которые используются для домашних компьютеров. Я не уверен, что квалифицированные заказчики захотят управлять авиалинией, или банком, или сталелитейным заводом с помощью, в общем-то, немного расширенного, немного улучшенного, но все-таки домашнего компьютера. Конечно, это может звучать как преувеличение, но, тем не менее, когда речь заходит о высокобезопасных, высокопроизводительных, масштабируемых системах, мы слышим от клиентов, что в этой области компания Microsoft еще не готова к конкуренции с другими крупными производителями и вряд ли и будет готова когда-то в будущем, потому что вся историческая линия развития компании состоит в поддержке индивидуальных пользователей или малого и среднего бизнеса.
Что касается компании IBM, то она тоже может послужить в некотором смысле примером - по обширности решений, по охвату разного рода вертикальных рынков и т.д. Т.е. компания IBM, в принципе, наиболее близка к Oracle в том смысле, что у нее тоже можно проследить решения от базы данных до интегрированных платформ middleware. IBM проигрывает Oracle в отношении уровня интегрированности своих решений. IBM тоже частично шла по пути консолидации путем покупки компаний, но вопрос интегрированности меньше стоял на повестке дня, был менее приоритетным, чем у Oracle.
Можно, например, сказать, что семейство продуктов WebSphere, в действительности проинтегрировано только путем использования общего названия. В частности, продукт MQSeries, хотя теперь и называется WebSphere MQ, был и остается продуктом, который изначально был написан на языке Cobol с некоторыми вставками на языке C и с миром Java общается с помощью внешнего тонкого интерфейса.
Другим примером может служить Tivoli. Этот продукт происходит из мира корпоративного управления, а теперь его предлагается использовать совсем в других целях.
В отличие от этого, Oracle Enterprise Manager разрабатывался совместно не только со многими компонентами Oracle Fusion Middleware, но и со средствами управления базами данных и Grid. Такого уровня интегрированности в IBM нет.
Кроме того, IBM очень сильно полагается на свои консалтинговые службы, очень многие продажи производятся через эти службы. В отличие от этого, Oracle тесно сотрудничает с массой независимых консалтинговых служб по всему миру, с которыми IBM конкурирует. Oracle помогает своим партнерам в тех случаях, когда клиенты считают, что стандартное решение Oracle не полностью удовлетворяет их требованиям, или когда стандартные средства Oracle не могут обеспечить достаточно быстрый цикл разработки. Подход IBM, обязывающий заказчиков работать с собственными консалтинговыми подразделениями компании, ограничивает возможности клиентов.
Компания BEA Systems тоже заслужила почетное место в мире программного обеспечения, ориентированного на поддержку бизнеса. Компания создала лучший для своего времени сервер приложений, WebLogic. Но к сегодняшнему дню они отстали. Отстали в отношении поддержки стандартов, в некоторых направлениях выбрали неверный путь развития, из-за чего и отстали, и теперь им приходится нагонять, как в случае с упоминавшимся ранее BEPL. А может быть, это связано с тем, что компания все-таки небольшая, и у нее не хватило мощности вложить ресурсы в некоторое направление, где они могли бы развить большую скорость в предоставлении решений, чем другие крупные поставщики. Сегодня вообще серьезно стоит вопрос о выживании компании, поскольку у нее имелся очень большой спад в то время, когда у всей отрасли наблюдался подъем.
Сервер приложений BEA Systems продолжает оставаться в группе лидеров, но сервер приложений Oracle по многим параметрам к нему приблизился, а по некоторым и превзошел. То же можно сказать и про WebSphere. Т.е. WebLogic во многом утратил уникальность своих достоинств, и сегодня, в лучшем случае, занимает не более одной трети общего рынка серверов приложений. Технология серверов приложений к настоящему времени уже настолько отшлифована и стандартизована, что клиент, выбирая между серверами разных поставщиков, обращает внимание на массу других вещей: перспективы дальнейшего существования компании, наличие родственных продуктов у этого же производителя и т.д. И поскольку BEA в свое время не приложила усилия к созданию дополнительного бизнеса, то при утрате лидирующей позиции на рынке серверов приложений она просто не может предложить ничего нового.
Монитор транзакций Tuxedo тоже давно ушел в прошлое, на его основе уже не ведутся новые разработки. В результате компания BEA все больше переходит в область обслуживания ранее проданных продуктов, что для софтверной компании является почти приговором. В то же время, рост объема продаж Oracle Fusion Middleware сегодня является рекордным для всего этого сектора рынка.
Теперь я получил ответы на все свои вопросы. Я очень Вам благодарен и думаю, что Ваше интервью будет интересно для многих наших читателей.
Вадим Розенберг (Vadim Rosenberg)
Вадим Розенберг более 15 лет занимается разработкой, проектированием и маркетингом инфраструктурного ПО и бизнес-приложений. Являясь директором по стратегии развития и архитектуре Oracle Application Server Suite, Вадим концентрируется на решении проблем в таких областях, как сервисно-ориентированная архитектура, моделирование и автоматизация бизнес-процессов, grid-технологии и другие инновационные направления разработки и интеграции корпоративных приложений.
До прихода в Oracle Вадим Розенберг в течение 4 лет работал в компании BEA, занимаясь маркетингом и стратегиями продаж сервера приложений WebLogic Server. До этого, работая инженером в компании Compaq Computers (в подразделении Mission Critical Servers, созданном в результате приобретения компании Tandem), Вадим занимался разработкой отказоустойчивой и масштабируемой J2EE-структуры и систем обмена сообщениями. В начале 90-х годов он работал IT-консультантом в одной из крупнейших сетей супермаркетов Северной Америки Safeway Stores, а до этого - разработчиком программного обеспечения в компании Fourth Dimension Software, где занимался созданием приложений по бронированию мест для индустрии путешествий.
Вадим имеет множество публикаций в отраслевых изданиях и большой опыт выступлений на различных отраслевых мероприятиях перед техническими специалистами и представителями сферы бизнеса, а также перед клиентами и партнерами.
В начале ноября 2005 г. Вадим Розенберг приезжал в Москву, чтобы принять участие в Oracle TechForum. Пользуясь случаем, мы взяли у него интервью.
Дополнительные компоненты СУБД Oracle для работы с хранимыми Java-программами
Для работы с хранимыми Java-программами посредством Jserver/OJVM в Oracle добавлены следующие компоненты разного характера:
| Компонента | Описание |
| JVM Aurora/Oracle JVM | Java Virtual Machine, выполняющая хранимый Java-код |
| loadjava | Программа, вызываемая из операционной системы для загрузки в БД Java-элементов из файлов .java, .class, .properties, .jar, .zip, .sqlj |
| dropjava | Программа, вызываемая из операционной системы для удаления из БД ранее загруженных Java-элементов |
| CREATE JAVA SYSTEM | Создает в БД структуры для работы Java; аналогична SQL-предложению заведения БД CREATE DATABASE … |
| {CREATE | ALTER | DROP} JAVA … | SQL-предложения категории DDL, во многом дублирующие функции программ loadjava и dropjava |
| Модификации в CREATE PROCEDURE/FUNCTION … | Позволяют предъявлять хранимые Java-программы в зону видимости PL/SQL-программ |
| JAVA_POOL_SIZE JAVA_MAX_SESSIONSPACE_SIZE JAVA_SOFT_SESSIONSPACE_LIMIT |
INIT-параметры, регулирующие использование памяти Java-программами в Oracle |
| JAVASYSPRIV JAVAUSERPRIV |
Роли, которые дают возможность хранимым программам взаимодействовать с операционной системой (например, читать из файла) |
| DBMS_JAVA | Системный пакет с процедурами и функциями для работы с Oracle JVM (большей частью - внутреннего пользования) |
| DBMS_JAVA_TEST | Системный пакет для отладки хранимых процедур |
| Jpublisher | Средство построения классов Java на основе объектных типов и типов REF в Oracle |
В зависимости от характера перечисленных компонент они заводятся либо при установке программноый среды работы Oracle, либо при создании в БД среды JServer/OJVM.
Java и Oracle - это очень просто
© ,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель
Содержание
Обращение к загруженной в Oracle процедуре Java
Обращение к Java-программе из Java-кода делается как обычно.
Для обращения к сохраненной в БД Java-программе из PL/SQL, ее следует опубликовать для этого языка:
CREATE FUNCTION say_hello_from_java_to (to_whom IN VARCHAR2)
RETURN VARCHAR2
AS LANGUAGE JAVA
NAME 'training.demos.MyJavaAgentInOracle.sayHello (java.lang.String)
return java.lang.String';
/
После этого можно выполнить в SQL*Plus:
SET SERVEROUTPUT ON
EXEC DBMS_OUTPUT.PUT_LINE(say_hello_from_java_to('World'))
Организация справочной информации
Справочная информация о программных элементах Java распределена между словарем-справочником СУБД (таблица DBA_OBJECTS) и специальными структурами, создаваемыми в каждой схеме, владеющей этими элементами.
При первой загрузке программных элементов Java в любую схему loadjava или команда CREATE JAVA создадут там:
CREATE$JAVA$LOB$TABLE - таблицу для хранения кода Java-программ
JAVA$CLASS$MD5$TABLE - хеш-таблицу для хранения цифровых подписей (digest) для каждого загружаемого объекта (с целью учета необходимости перетранслировать предъявляемый объект)
Несколько вспомогательных объектов, играющих вместе с этими двумя таблицами роль своеобразного "словаря-справочника программных элементов Java" в конкретной схеме.
Фактически загрузка программой loadjava вызывает неявную выдачу команды CREATE JAVA … . Описание программных элементов Java заносится в таблицу CREATE$JAVA$LOB$TABLE. Повторная загрузка одного и того же Java-элемента реально выполняться не будет, если только (а) он не изменил свое описание или (б) не указан ключ -force при вызове программы loadjava.
Основные понятия
Начиная с версии 8.1 в состав СУБД Oracle можно дополнительно включать так называемый JServer, позволяющий использовать для хранимых процедур помимо PL/SQL еще и язык Java. В состав JServer входят следующие элементы:
виртуальная Java-машина JVM под названием Aurora, поддерживающая среду для выполнения Java-программ и библиотеки классов Java
средства увязки с PL/SQL
ряд других
JVM Aurora способна исполнять методы Java ("хранимые Java-процедуры") и классы, хранимые в Oracle.
В версии 9.0 JServer переименован в Oracle9i JVM (иногда - OJVM или же Enterprise Java Server).
Особенности Java и среда работы программ на Java
Архитектура и принципы работы Java резко отличаются от архитектуры и принципов работы PL/SQL. Ниже излагаются некоторые особенности Java, существенные для использования этого языка при работе с Oracle.
Преобразование имен
Стандарт именования классов в Java допускает более длинные имена, чем предел в 30 знаков в SQL Oracle. Достаточно длинные Java-имена Oracle при помещении в словарь-справочник самостоятельно заменяет на придуманные более короткие. Получить первоначальное имя по присвоенному Oracle можно с помощью функции DBMS_JAVA.LONGNAME. Пример ее использования:
COLUMN shortname FORMAT A30
COLUMN longname FORMAT A60
SELECT object_name shortname,DBMS_JAVA.LONGNAME(object_name) longname
FROM user_objects
WHERE object_type = 'JAVA CLASS';
Кроме того, при помещении составного имени Java в БД Oracle переводит точки в знаки "/", например
training.demos.MyHiFromOracle
в
training/demos/MyHiFromOracle.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
Пример создания хранимой Java-программы
Хранимые Java-программы могут создаваться в БД под Oracle двумя способами:
загрузкой извне с помощью программы loadjava и
SQL-предложением CREATE/ALTER JAVA …
Ниже показаны оба способа на примере класса, создаваемого в рамках пакета training.demos.
Пример транслирования и выполнения Java-программы
Файл с программой под названием MyJavaAgent.java может иметь следующее содержание:
| public class MyJavaAgent { public static String sayHello (String toWhom) { return "Hello, " + toWhom + "!"; } public static void main(String[] args) { System.out.println(sayHello("World")); } } |
Транслирование программы (класса):
javac MyJavaAgent.java
Запуск программы (класса):
java MyJavaAgent
Программные компоненты в среде разработки на Java
Основными программными компонентами в среде разработки на Java являются исходный код, класс, пакет, интерфейс, файл ресурсов. Взаимоотношение показано на рисунке.
Пакет используется для логический группировки программных единиц Java.
Архив используется для физической группировки программных единиц Java, необходимых для работы конкретной Java-программы, могущих быть вызваных прямо или по цепочке. Технологически часто единственная альтернатива неимоверному числу .class-файлов.
Просмотр исходных текстов
Выгрузить из БД исходные тексты из "словаря-справочника объектов Java" конкретной схемы можно с помощью процедур пакета DBMS_JAVA:
DECLARE
PROCEDURE put_java_source(jclass IN VARCHAR2) IS
b CLOB;
v VARCHAR2(4000);
i INTEGER := 4000;
BEGIN
DBMS_LOB.CREATETEMPORARY(b, FALSE);
DBMS_JAVA.EXPORT_SOURCE(jclass, b);
DBMS_LOB.READ(b, i, 1, v);
DBMS_OUTPUT.PUT_LINE(v);
END;
BEGIN
put_java_source('training/demos/MyJavaAgentInOracle');
END;
/
Исходные тексты программ на Java в БД модно посмотреть также в консоли Oracle Enterprize Manager или в аналогичных системах третьих фирм.
Просмотр Java-элементов
Java-объекты, заведенные в схеме, можно просмотреть из таблицы USER_OBJECTS словаря-справочника обычным способом:
COLUMN object_name FORMAT A30
SELECT object_name, object_type, status, timestamp
FROM user_objects
WHERE object_name NOT LIKE 'SYS_%' AND
object_name NOT LIKE 'CREATE$%' AND
object_name NOT LIKE 'JAVA$%' AND
object_name NOT LIKE 'LOADLOB%' AND
object_type LIKE 'JAVA %'
ORDER BY 2, 1;
Схема вызова хранимых Java-программ
Хранимым Java-программам в Oracle соответствуют методы Java, подверженные следующим ограничениям (версия 8.1):
методы, публикуемые для использования в SQL или PL/SQL, должны быть объявлены как статические
классы не могут делать во время исполнения обращений к GUI-классам (например, к awt)
Соотношение и взаимосвязь PL/SQL и Java в Oracle
Java в Oracle представляет собой полнофункциональную замкнутую систему, однако классы Java средствами Oracle можно "публиковать" для PL/SQL-машины и вызывать из программ на PL/SQL.
Вплоть до версии 9.2 включительно PL/SQL в Oracle несравнимо эффективнее отрабатывает SQL-запросы. С другой стороны Java обладает более богатой и универсальной языковой средой для описания приложений.
Создание хранимых программ на Java в Oracle
Oracle позволяет хранить Java-программы и вызывать их на исполнение с помощью встроенной JVM, полностью наподобие хранимым PL/SQL-процедурам, исполняемым встроенной PL/SQL-машиной.
Создание с помощью loadjava
Пусть в каталоге training/demos имеется файл MyJavaAgentInOracle.java (имеет отличия от файла MyHi.java, приведенного выше):
|
package training.demos;public class MyJavaAgentInOracle { public static String sayHello (String toWhom) { return "Hello, " + toWhom + "!"; } } |
Загрузка в схему SCOTT БД текста кода для класса в этом файле (система обозначений Windows; в Unix-оболочках аналогично):
set CLASSPATH=%CLASSPATH%;%ORACLE_HOME%\javavm\aurora.zip
(в версии 9 %CLASSPATH%;%ORACLE_HOME%\javavm\lib\aurora.zip)
loadjava -user scott/tiger -o training/demos/MyJavaAgentInOracle.java
Если в том же каталоге у нас будет странслированный программой javac класс MyHiFromOracle, можно будет загрузить в БД сразу его:
loadjava -user scott/tiger -o training/demos/MyJavaAgentInOracle.class
Создание SQL-предложением
Загрузить код того же класса можно по-другому:
CREATE JAVA SOURCE NAMED "training/demos/MyJavaAgentInOracle" AS
public class MyJavaAgentInOracle { public static String sayHello (String toWhom) { return "Hello, " + toWhom + "!";
}
};
/
Среда окружения OC
Для работы программ среды разработки Java должны быть выставлены следующие минимально необходимые переменные среды окружения ОС:
CLASSPATH. Переменная, которая указывает на местонахождение файлов с классами, необходимыми для трансляции или выполнения java-программы. Местонахождением может быть (а) каталог файловой системы, в котором расположены файлы с классами и (б) zip- или jar-файл с теми же файлами, упакованными внутрь. Путь к файлу с классом должен быть согласован с полным именем класса, включающим имя пакета. Если имя пакета не используется, в CLASSPATH следует включить "." (указание на текущий каталог). (Строго говоря, для работы программ java и javac переменную CLASSPATH можно и не выставлять, но тогда эти программы обязаны использовать ключ -classpath, иначе не обязательный.)
PATH. Сюда нужно включить доступ к программам среды разработки.
Исполняемые модули из состава JDK в версии 8.1 расположены в %ORACLE_HOME%\apache\jdk\bin, а в версии 9 - в %ORACLE_HOME%\ jdk\bin.
Основные библиотеки классов classes111.zip и classes12.zip (разница между ними - в версиях Java) в обеих версиях Oracle находятся в %ORACLE_HOME%\jdbc\lib
Для проведения экспериментов удобно создать командный файл со следующим текстом для версии Oracle 8.1:
set nls_lang=american_america.ru8pc866
set oracle_home=c:\oracle\ora81
set classpath=%oracle_home%\jdbc\lib\classes111.zip;.
path=%path%;%oracle_home%\apache\jdk\bin;%oracle_home%\lib
или со следующим текстом для версии Oracle 9.2:
set nls_lang=american_america.ru8pc866
set oracle_home=c:\oracle\ora92
set classpath=%oracle_home%\jdbc\lib\classes111.zip;.
path=%path%;%oracle_home%\jdk\bin
Теперь можно открыть консольное окошко и прогнать нужный командный файл.
в виде побочного следствия установки
Проще и короче всего установить JServer/OJVM в виде побочного следствия установки одной из стандартных конфигураций программной среды Oracle (например, Typical или Minimal в версии 8.1).
Тем не менее, JServer/OJVM можно доустановить к имеющейся программной среде, если он отсутствовал ранее, путем запуска сценария initjvm.sql из каталога %ORACLE_HOME%\javavm\install (система обозначений Windows).
Установка среды разработки на Java
Для ведения разработок с использованием Java необходимо установить на компьютере JDK (Java Development Kit, прежнее название - SDK, Software Development Kit for Java).
Начиная с версии Oracle 8.1 JDK присутствует на CD с основной поставкой и может устанавливаться штатной программой Oracle Installer путем специального указания. В типовых вариантах установки программной среды Oracle (например, в вариантах Typical или Minimal в версиии 8.1) JDK появляется на компьютере автоматически.
JDK можно установить и независимо от Oracle, переписав этот программный комплект с
Файл Java-программы для проверки связи через JDBC
Для следующих ниже примеров организации разных вариантов связи с БД через JDBC нужно подготовить файл StaffByJDBC.java с общим для всех примеров текстом:
|
import java.sql.*; import oracle.jdbc.driver.*; public class StaffByJDBC { public static void main(String[] args) { String url = null; if (args.length > 0) { if (args[0].compareToIgnoreCase("thin") == 0) { url = "jdbc:oracle:thin:@localhost:1521:TEACHER"; } else if (args[0].compareToIgnoreCase("oci") == 0) { url = "jdbc:oracle:oci8:@TEACHER"; } else if (args[0].compareToIgnoreCase("kprb") == 0) { url = "jdbc:oracle:kprb:"; } } if (url == null) { System.out.println("usage: StaffByJDBC [thin|oci]"); return; } try { DriverManager.registerDriver ( new oracle.jdbc.driver.OracleDriver()); } catch (Exception e) { return; } try { Connection cn = DriverManager.getConnection (url,"scott","tiger"); Statement st = cn.createStatement(); ResultSet rs = st.executeQuery ("SELECT empno, ename FROM emp"); while (rs.next()) { System.out.println("Number=" + rs.getString(1) + " " + "Name=" + rs.getString(2)); } st.close(); cn.close(); } catch (Exception e) { return; } finally { System.out.println("All that happened"); } } } |
Java и данные из Oracle - все очень просто
©
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель
JDBC-драйверы в Oracle
Фирма Oracle поставляет для работы со своей СУБД следуюшие драйверы, удовлетворяющие спецификациям JDBC:
тонкий (thin; тип IV, для работы извне, через браузер, по TCP/IP)
толстый (thick; тип II, для локальной работы извне)
родной (тип II, для работы изнутри, из хранимых в БД Java-процедур)
Помимо этого около сотни разных фирм поставляют JDBC-драйверы собственной реализации типов I, II, III и IV, в том числе и для связи с Oracle. Они доступны в интернете.
JDBC и JDBC-драйверы
JDBC - это Java API (Application Program Interface) для доступа из Java-программ к SQL-СУБД разных типов. Подразумевается, что одна и та же Java-программа сумеет с помощью JDBC реально работать в среде Windows с данными mySQL или же в среде Solaris с данными Informix. Она же может быть хранимой процедурой в БД под Oracle и работать с данными той же Oracle или, к примеру, Sybase.
Реализуется JDBC в виде интерфейсов java.sql (основной) и javax.sql (расширенный). Конкретный набор классов, реализующий JDBC-интерфейс и осуществляющий доступ к конкретной СУБД, называется драйвером. JDBC-драйверы для своих СУБД поставляют все основные разработчики.
Описаниями JDBC определено четыре типа JDBC-драйверов: два "тонких" и два "толстых".
Соединительный драйвер JDBC (тип I, "толстый")
"Родной" API-драйвер (тип II "толстый")
Общий сетевой API-драйвер (тип III "частично тонкий")
Драйвер прямого доступа через разъем (тип IV "тонкий")
Обращение к БД из хранимых процедур
Загрузка, трансляция и запуск программы:
loadjava -user scott/tiger -oci8 -r StaffByJDBC.java
sqlplus scott/tiger
SQL> ALTER JAVA SOURCE "StaffByJDBC" COMPILE;
Java altered.
SQL> ALTER JAVA CLASS "StaffByJDBC" COMPILE;
Java altered.
SQL> CREATE OR REPLACE PROCEDURE liststaff (drivertype IN VARCHAR2)
AS LANGUAGE JAVA
NAME 'StaffByJDBC.main (java.lang.String[])';
/
Function created.
SQL> EXEC liststaff('kprb')
PL/SQL procedure successfully completed.
Просмотр результатов - в трассировочном файле в каталоге ОС udump.
Обращение к данным из триггеров Oracle
Специальных Java-триггеров в Oracle нет, и поэтому организация триггера на Java требует заведения внешней "оболочки" на PL/SQL, внутри которой делаются обращения к процедурам на Java, опубликованным для PL/SQL.
Вот как это может выглядеть:
CREATE TRIGGER scott.salary_check
BEFORE INSERT OR UPDATE OF sal, job ON scott.emp
FOR EACH ROW
WHEN (new.job <> 'PRESIDENT')
CALL check_sal(:new.job, :new.sal, :new.name);
/
Здесь CHECK_SAL должна быть опубликованной процедурой на Java.
Особенности работы с kprb-драйвером
Работа с kprb-драйвером имеет свои отличия по отношению к работе со внешними драйверами:
для хранимых программ явного подсоединения с БД не требуется - kprb-драйвер выполняет его неявно автоматически (код явного соединения из программ, написанных из расчета на внешнее соединение, будет проигнорирован)
так как драйвер kprb не поддерживает AUTOCOMMIT, выполнять COMMIT или ROLLBACK в программе нужно явно
устройством выдачи Sys.output по умолчанию является для kprb не экран, а трассировочные файлы в каталоге udump
Пример программы с использованием SQLJ
Типовой пример программы с использованием SQLJ (файл StaffBySQLJ.sqlj):
|
import java.sql.*; import sqlj.runtime.ref.DefaultContext; import oracle.sqlj.runtime.Oracle; #sql iterator MyIter (String ename, int empno, float sal); public class StaffBySQLJ { public static void main (String args[]) throws SQLException { Oracle.connect ("jdbc:oracle:thin:@localhost:1521:teacher", "scott", "tiger"); MyIter iter; #sql iter={ select ename, empno, sal from emp }; while (iter.next()) { System.out.println (iter.ename()+" "+iter.empno()+" "+iter.sal()); } } } |
Работа с Oracle через толстый OCI-драйвер
Трансляция и запуск программы (среда Unix - аналогично):
SET CLASSPATH=%ORACLE_HOME%\jdbc\lib\classes12.zip;.
javac StaffByJDBC.java
java StaffByJDBC oci
Работа с Oracle через тонкий драйвер
Трансляция и запуск программы (среда Unix - аналогично):
SET CLASSPATH=%ORACLE_HOME%\jdbc\lib\classes12.zip;.
javac StaffByJDBC.java
java StaffByJDBC thin
Транслирование программы с SQLJ
Пример транслирования программы с SQLJ:
SET CLASSPATH=%ORACLE_HOME%\jdbc\lib\classes12.zip;.
SET CLASSPATH=%CLASSPATH%;%ORACLE_HOME%\sqlj\lib\translator.zip
SET CLASSPATH=%CLASSPATH%;%ORACLE_HOME%\sqlj\lib\runtime12.zip
sqlj StaffBySQLJ.sqlj
После этого в текущем каталоге появятся файлы (вариант версии 8.1.7):
StaffBySQLJ.class
StaffBySQLJ.java
StaffBySQLJ _SJProfile0.ser
StaffBySQLJ _SJProfileKeys.class
MyIter.class
Таким образом, программа sqlj не только предтстранслирует исходный яайл SQLJexample.sqlj, но и странслирует вслед порожденную ею же программу SQLJexample.java с учетом подготовленных свойств. Запуск конечного результата выглядит как обычно:
java StaffBySQLJ
Более сложный пример транслирования:
sqlj -user=scott/tiger@jdbc:oracle:thin:@localhost:1521:teacher StaffBySQLJ.sqlj
Транслирование программ с SQLJ, предназначенных для исполнение на сервере, можно осуществлять
(а) явно (программа sqlj, как показано выше) с последующей загрузкой классов в БД (в этом случае их перед загрузкой удобно объединять в jar-файлы)
(б) неявно, путем загрузки файлов .sqlj в БД (автоматическая предтрансляция будет в этом случае выполнена.внутренними средствами Oracle).
Установка JDBC-драйверов для работы с Oracle
Пакет java.sql с классами JDBC, реализованными фирмой Oracle в соответствии с интерфейсами, предлагаемыми фирмой Sun, входит в состав стандартного JDK. Тонкий драйвер входит в состав файла classes111.zip, или его более поздней версии classes12.zip. При отсутствии на компьютере его можно получить по адресу download.oracle.com/otn/utilities_drivers/jdbc/817/classes12.zip (версия 8.1.7).
Толстый драйвер можно получить по адресу download.oracle.com/otn/utilities_drivers/jdbc/817/jdbc817jdk12-nt.zip (для NT) или download.oracle.com/otn/utilities_drivers/jdbc/817/jdbc817jdk12-sol.zip (для Solaris).
Для работы с драйверами нужно добавить путь к этим файлам к переменной среды окружения CLASSPATH.
Выполнение программы с SQLJ
Для возможности обращения программы c SQLJ, загруженной с помощью loadjava из jar-файла (или напрямую), можно выполнить
CREATE OR REPLACE PROCEDURE my_sqlj_example
AS LANGUAGE JAVA
NAME 'StaffBySQLJ.main(java.lang.String[])';
Программы с SQLJ, написанные для работы с БД извне (с клиентской стороны), всегда будут работоспособны и в качестве хранимых программ (то есть, на сервере). Обратное не обязательно верно (см. комментарий по поводу особенностей использования kprb-драйвера выше).
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
Взаимодействие с базой данных через JDBC
Общение программ на Java с данными в БД под управлением Oracle осуществляется двумя основными способами: через JDBC и через SQLJ.
Взаимодействие с базой данных через SQLJ
SQLJ представляет собой альтернативный JDBC способ работы с БД из Java-программ, использующий схему включающего языка/предкомпиляции. В отличие от JDBC, SQLJ позволяет использовать в программе только статические SQL-обращения к базе, однако исходный текст программ может выглядеть много компактнее.
Подобно Java-программам с JDBC, программы с SQLJ могут работать как на клиенте, так и на сервере.
SQLJ стандартизован комитетом ANSI. Более подробно о нем см. на web-узле консорциума SQLJ .
Java и данные из Oracle в web – все очень просто
,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель
Содержание
Это третья статья из серии про употребление Java в Oracle. Напомню, что цель серии – показать, что средств обыкновенной штатной поставки Oracle Enterprise Edition или Standard Edition хватает, чтобы строить Java-приложения для Oracle, в том числе для использования в сети web.
Модель MVC организации приложения для web
Для построения web-приложений на основе Java часто используют подход («модель») Model-View-Controller (MVC), предложенный фирмой Xerox в 80-х годах для своего языка Smalltalk-80. Согласно этому подходу приложение представляет собой в общем случае организованный набор страниц HTML и JSP, а также сервлетов и компонент JavaBeans и Enterprise JavaBeans (EJB). Задачи, которые решают эти элементы web-приложения, разделяются на задачи моделирования прикладной области (Model), представления данных приложения клиенту (View) и управления работой приложения (Controller):
Общие сведения о сервлетах Java в web
Java-сервлет представляет собой Java-программу, хранимую на web-сервере (точнее – в модуле JServ или Tomcat), кешируемую и исполняемую там же. С точки зрения Java, сервлет – это объект класса (прямо или опосредованно) javax.servlet.GenericServlet, удовлетворяющего интерфейсу javax.servlet.Servlet. Сервлет обладает всеми возможностями объектов Java, например, общения с данными Oracle.
Наборы классов и интерфейсов, удобных для создания сервлетов Java в web, содержатся в двух пакетах: javax.servlet и javax.servlet.http. Согласно интерфейсу javax.servlet.Servlet сервлет имеет жизненный цикл, диктуемый следующими методами:
public void init (ServletConfig config) throws ServletException;
Метод, используемый машиной сервлетов единожды для каждого конкретного сервлета для того, чтобы загрузить его в память (в контейнер) и сделать доступным для работы.
public void service (ServletRequest request, ServletResponse response)
throws ServletException, IOException;
Метод, которым машина сервлетов передает загруженному в память сервлету на обработку пришедший запрос (request) и получает от него ответ (response) всякий раз при обращении к работающему сервлету.
public void destroy();
Метод, используемый машиной сервлетов единожды для каждого конкретного сервлета для удаления его из памяти, обычно по ненадобности, и освобождения ресурсов сервера.
Интерфейс javax.servlet.ServletRequest, которому удовлетворяет поступающий на обработку сервлетом запрос, содержит методы для получения сведений об источнике поступления запроса и о параметрах, передаваемых запросом.
Интерфейс javax.servlet.ServletResponse, в соответствии с которым сервлет формирует свой ответ, содержит методы для выдачи результатов и установки характеристик выдачи.
На практике сервлеты web-сервера удобнее создавать как экземпляры класса javax.servlet.http.HttpServlet, являющегося наследником GenericServlet,. Среди прочих, методы HttpServlet содержат следующие:
protected void doGet (HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException;
Метод, к которому обращается метод service класса, которому прнадлежит сервлет, для обработки операции GET, пришедшей по протоколу HTTP.
protected void doPost (HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException;
Метод, к которому обращается метод service класса, которому прнадлежит сервлет, для обработки операции POST, пришедшей по протоколу HTTP.
Подробнее о технике Java Servlet см. на
Пример обращения к сервлету
Прежде, чем выполнить обращение к сервлету, следует перенести полученный в результате трансляции сервлета файл MyServletAgent.class в каталог %JSERV_HOME%\servlets.
После этого достаточно в строке источника документа для браузера указать (в версии 9 -- ). Первое обращение к этому сервлету проинициализирует его и разместит в памяти в web-сервера, так что последующие обращения окажутся значительно быстрее.
Пример обращения к странице JSP
Перенесем созданный файл
Обратим внимание, что в каталоге, обозначенном выше, появился подкаталог _pages\_demo с файлами:
_MyJSPDemo$__jsp_StaticText.class
_MyJSPDemo.class
_MyJSPDemo.java
Пример сервлета с обращением к базе данных
Ниже приводится пример файла
|
import java.io.*; import java.sql.*; import javax.servlet.*; import javax.servlet.http.*; public class StaffByServletTransactional extends HttpServlet { public void init(ServletConfig config) throws ServletException { super.init(config); try { Class.forName("oracle.jdbc.driver.OracleDriver").newInstance(); } catch (Exception e) { } } public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<html>"); out.println("<head>"); out.println("<title>Servlet Per Transaction Connection</title>"); out.println("</head>"); out.println("<body>"); out.println("<pre>"); Connection cn = null; try { cn = DriverManager.getConnection( "jdbc:oracle:thin:@localhost:1521:teacher", "scott", "tiger"); } catch (Exception e) { } Statement st = null; ResultSet rs = null; try { st = cn.createStatement(); rs = st.executeQuery("SELECT empno, ename FROM emp"); while (rs.next()) { out.println("Number=" + rs.getString(1) + " " + "Name=" + rs.getString(2)); } st.close(); cn.close(); } catch (Exception e) { } out.println("</pre>"); out.println("<hr>"); out.println("</body>"); out.println("</html>"); } public void doPost( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { doGet(request, response); } } |
Трансляция сервлета:
SET CLASSPATH=%ORACLE_HOME%\lib\servlet.jar;.
javac StaffByServletTransactional.java
Пример составления страницы JSP
Для показа работы JSP-страницы составим файл с названием
|
<html> <head><title>MyJSPDemo JSP demo</title></head> <body> < h2>Hello, JSP World</h2> whith date <%= new java.util.Date().toString() %> now and User-Agent <%= request.getHeader("User-Agent") %> < /body> </html> |
Пример страницы JSP с непосредственным обращением к базе данных
Ниже приводится пример файла
|
<%@ page import="java.sql.*" %> <html> < head><title>Direct JDBC Query JSP</title></head> < body> < h3>JSP StaffByJSPDirect result:</h3> < pre> < %= StaffByJSPDirect() %> < /pre> < hr> < /body> < /html> <%! private String StaffByJSPDirect() throws SQLException { Connection cn = null; StringBuffer sb = new StringBuffer(); try { cn = DriverManager.getConnection( "jdbc:oracle:thin:@localhost:1521:teacher", "scott", "tiger"); } catch (SQLException e) { }; Statement st = null; ResultSet rs = null; try { st = cn.createStatement(); rs = st.executeQuery("SELECT empno, ename FROM emp"); while (rs.next()) { sb.append("Number=" + rs.getString(1) + " " + "Name=" + rs.getString(2) + "\n"); }; cn.close(); } catch (SQLException e) { }; return sb.toString(); } %> |
Пример страницы JSP с обращением к базе данных с использованием собственной разметки
Ниже приводится пример файла
|
<%@ taglib uri="/WEB-INF/sqltaglib.tld" prefix="jml" %> <html> < head> < title>User Tag Lib JDBC Query JSP</title> < /head> < body> < h3>JSP StaffByJSPTaglib result:</h3> < jml:dbOpen URL="jdbc:oracle:thin:@localhost:1521:teacher" user="scott" password="tiger"> <jml:dbQuery> select * from emp </jml:dbQuery> < /jml:dbOpen> < hr> < /body> < /html> |
Работа с JavaServer Pages
JavaServer Pages (JSP) – другая техника организации динамических web-страниц. В отличие от Java Servlets, в JSP применяется не генерация HTML-кода из программы, а вставки в HTML-код JSP-указаний, исполняемых, тем не менее, тоже на сервере. При первом обращении к JSP-странице JServ автоматически транслирует ее в Java-сервлет и впоследствии переадресует все запросы к нему.
(Подробнее о технике JavaServer Pages см. на ).
Способы обращения к БД из страницы JSP
В случае JSP не существует единственного способа обращения страницы к базе данных. Вместо этого имеется несколько возможных вариантов:
- прямое обращение
- обращение с использованием user actions (действий пользователя) в странице
- опосредованное обращение к БД из Bean-компоненты
- опосредованное обращение к БД путем вызова сервлета
Далее рассматриваются примеры обращения по первым двум вариантам.
Web-сервер Apache и его расширения JServ и Tomcat
В качестве базового элемента операционной среды построения web-узлов на базе своей СУБД фирма Oracle, начиная с версии 8.1.6 (и продолжая версией 9), выбрала web-сервер Apache.
Для эффективного обслуживания большого числа одновременных запросов по internet в web-сервере Apache имеется поддержка механизма сервлетов (servlets). Она реализуется средствами так называемого сервера JServ, являющегося расширением базовой поставки Apache (модулем сервлетов по терминологии, принятой в проекте Apache), и предназначенного именно для сервлетов на Java. Нынешняя разработка очередных версий Apache происходит в рамках более общего проекта Jakarta, и в рамках того же проекта создается сервер поддержки сервлетов Tomcat, предлагаемый на смену JServ.
В штатной поставке Oracle сервер Apache уже сконфигурирован с JServ. Тем не менее, установка и того, и другого может быть при желании осуществлена самостоятельно (см. и ).
В примерах ниже значения настроек Apache и JServ соответствуют штатной поставке Oracle. Эти настройки несколько разнятся в версиях 8.1 и 9. Например, в поставках 8.1 используется HTTP-порт № 80, а в версии 9 – порт № 7778. В примерах ниже используется вариант порта версии 8.1, который, к тому же, обычно воспринимается браузерами номером порта по умолчанию.
Имена каталогов в примерах также относятся к версии 8.1 и могут несколько отличаться от версии 9.
Для дальнейшей работы удобно завести переменные среды окружения ОС:
set APACHE_HOME=%ORACLE_HOME%\Apache\Apache
set JSERV_HOME=%ORACLE_HOME%\Apache\Jserv
