Module jserv_module mod_jserv.o -для Unix-система.
Более подробно описание подключения Jserv`а рассмотрено в практической части.
При реализации сценария 3 встает вопрос о выборе качественной платформы для создания информационного хранилища. Реляционная система управления базами данных фирмы Oracle является лидером на рынке СУБД. По производительности, надежности хранения данных, развитию семейства интерфейсов, объему серверных платформ продукты Oracle возглавляют многочисленные рейтинги. Гибкость использования, развитые средства управления доступом и распределенная архитектура делают сервер Oracle чрезвычайно привлекательным для технологии информационных хранилищ, а возможность работы на свободно - распространяемых Unix-платформах расширяет его возможности в некоммерческой среде.
Существенным ограничением использование Oracle в сфере науки и образования является достаточно высокая цена и низкое бюджетное финансирование. Однако с 1996 года фирма Oracle объявила о специальной программе для российских университетов, что позволяет за относительно небольшие деньги приобрести любой набор продуктов Oracle.
Язык Perl был создан для повышения эффективности обработки текстовых документов. Он ориентирован на обработку строк. В настоящее время язык получил большое распространение как инструмент создания исполняемых модулей WWW-сервера. Существующие пакеты расширения обеспечивают доступ к SQL-серверам непосредственно из Perl-программы. Это позволяет использовать его для решения всех задач, возникающих при обеспечении WWW-доступа к базам данных. Perl эффективен также при обработке произвольных структур данных: существующих отчетов, списков, карточек в электронном виде().
Java – это простой, объектно-ориентированный, распределенный, интерпретирующий, живучий, безопасный, архитектурно-нейтральный, переносимый, высокопроизводительный, многопоточный и производимый язык.
Компилятор Java читает исходные файлы и превращает их в байт-код (byte-code). Байт-код представляет собой промежуточную стадию между исходным кодом и машинным кодом, как можно более близкую к машинному коду. Но близкую не настолько, чтобы стать платформо-зависимой. Если точнее, то байт-код является машинным кодом, но не для какой-нибудь физически существующей машины, а для Java Virtual Machine – мифической машины, чье поведение в точности определено Sun Microsystems. Спецификации Java Virtual Machine (JVM) описывают поведение, ожидаемое от любой физической машины, которая выполняет любой заданный байт-код. Подчинение спецификациям JVM – вот что обеспечивает переносимость программ Java.
Сервлеты - это высокопроизводительные платформо-независимые server-side-пpиложения, написанные на Java и составляющие реальную конкуренцию таким технологиям, как CGI, PHP3, Perl, и уж конечно ASP.
К преимуществам сервлетов можно отнести:
Исключительно высокая скорость работы.
Быстpодействие сервлетов объясняется тем, что они, во-пеpвых, пpедставляют собою уже скомпилиpованный и оптимизиpованный код (а в случае с JIT-ом - ещё и пpеобpазованный в машинный) и, во-втоpых, выполняются в единожды загpуженной и инициализиpованной Java-машине.
Таким образом, экономятся ресурсы на запуск обработчика/паpсеpа скpипта, необходимые, например, для Perl или PHP3 (в некоторых ОС, в частности, в OS/2 - это очень серьезная экономия), и ресурсы (как память, так и время), затрачиваемые на непосредственно предкомпиляцию (интерпретацию) кода (что необходимо для тех же Perl, PHP, REXX).
Реально обе этих проблемы сразу не решаются, практически, нигде. Hаибольший эффект даёт, пожалуй, внедрение транслятора скpиптового языка непосредственно в веб-сеpвеp, например, пресловутые .asp-скpипты в серверах от Microsoft, или модули mod_perl или mod_php для apache. (Последний вариант - PHP3, внедренный в апач - является, наверное, самым производительным из всего вышеперечисленного).
Переносимость. В данном случае принцип "write once run everywhere" действует безотказно. Сервлеты, написанные в соответствии со спецификацией от Sun и не использующие какие-то особенности конкретного веб-сервера, работают безо всякой переделки или перекомпиляции под любыми, порой весьма далёкими друг от друга платформами, будь то Solaris, FreeBSD или OS/2. В связи с этим разработчик может совершенно свободно выбирать, в какой системе ему удобнее работать - он ни коим образом не привязан ни к серверу, ни к будущей целевой платформе.
Удобство кодирования и инструментарий разработчика. Не знаю, как другим, а мне Java как язык программирования нравится неизмеримо больше, чем тот же Perl или чрезвычайно быстрый, но, несколько убогий PHP3. Более того, даже некоторые мелочи в C++ начинают раздражать после долгой практики кодирования на Java. (Должен заметить, что я ничего не имею против перечисленных выше языков, отношусь к ним с должным уважением и использую их в своей работе.)
Кроме того, на рынке присутствует немалое количество мощнейших инструментов для разработчиков приложений на Java. Например, тот же VisualAge for Java 2.0 содержит средства визуального создания сервлетов - по сути, этакий WYSIWYG-pедактоp веб-страниц, создающий вместо HTML-документов сеpвлеты, генеpиpующие эти документы на лету.
Работа с базами данных. Работа с реляционными СУБД из Java унифицирована (для этого существует специальный пакет java.sql), удобна и отвязана от специфичных для конкретной СУБД тонкостей. Всё, что Вам нужно - это найти для своей СУБД JDBC-дpайвеpы (а они сейчас существуют практически для всех совpеменных баз данных, зачастую даже по нескольку pазновидностей), и далее можно пользоваться совеpшенно стандаpтными механизмами.
А при переходе на другую СУБД, например, c MySQL на Oracle, достаточно будет просто добавить в CLASSPATH новый драйвер и поменять URL для подключения к другой базе. Ни одного изменения в коде
Перспективность, современность технологий.
Конечно, есть у этой технологии и недостатки. Как технические: например, высокие требования к системным ресурсам - в основном, к памяти (под OS/2, например, запущенная Java-машина занимает 15-20 мегабайт оперативной памяти) или необходимсть в качественной устойчивой реализации Java для выбранной платформы, так и иного плана: такие как отсутствие должной квалификации как у разработчиков, так и, зачастую, у тех, кто принимает решения, их устоявшиеся предубеждения и многое другое...
Итак, как же работают сервлеты. Рассмотрим это на примере модуля JServ к веб-серверу apache.
В момент старта сервера вместе с ним стартует и ява-машина с так называемым servlet-wrapper'ом или средой, в которой в дальнейшем и предстоит исполняться сервлетам. Строго говоря, JServ - это и есть та самая среда. Он целиком написан на Java и занимается непосредственно загрузкой и исполнением сервлетов, следуя спецификации Sun, а также обменом данными с собственно веб-сервером. В последнем для этого должен присутствовать специальный модуль mod_jserv (его необходимо добавить при компиляции и сборке apache, или подключить в виде внешнего модуля).
При получении запроса на документ, приходящийся на специально оговоренный URL или каталог (обычно это что-нибудь вроде /servlets/), apache с помощью модуля mod_jserv передает этот запрос JServ'у, который определяет, какой сервлет должен этот запрос обработать, загружает этот сервлет (если он ещё не был загружен) и затем возвращает веб-серверу тот текст или поток данных, который был сформирован в результате работы сервлета.
Изначально сервер "пуст" - при его старте сервлеты обычно не загружаются (хотя есть возможность принудительно инициализировать нужные сервлеты при старте сервера). При появлении запроса нужный сервлет ищется в списке уже загруженных и, при необходимости, стартуется и инициализируется. После этого он остается постоянно загруженным в Java-машине (и предкомпилированным, если Java-машина содержит JIT) и при последующих запросах просто вызывается соответствующий его метод для их обработки. Преимущества такой идеологии очевидны. Функционально это аналогично вызову простой подпрограммы внутри обычного сервера и проиходит очень быстро и эффективно. Кроме того, заметный выигрыш дают такие вещи, как единожды проведенная инициализация, возможность хранения глобальных данных или поддержка множественных клиентских сессий, ведущаяся самим сеpвеpом (а не сеpвлетами, pазpаботчики котоpых в значительной степени избавлены от изобpетания велосипедов). Например, можно установить одно единственное соединение с базой данных, и пользоваться им при обработке запросов - немалая экономия, учитывая то, что из тех же скриптов на perl или php приходится каждый раз создавать новое соединение, восстанавливать параметры сессии и т.п.
Конечно же, существует возможность принудительной выгрузки отдельных сервлетов из памяти в случае необходимости, а также возможность автоматического распознавания изменения сервлетов и их перезагрузки. Иными словами, при обновлении того или иного сервлета нет необходимости перезагружать весь веб-сервер или JServ, достаточно просто положить новую версию на место старой, и она будет автоматически загружена в память при следующем запросе (естественно, при этом будет сначала произведено корректное завершение работы старой версии, путём вызова специального метода, а затем загрузка и инициализация новой).