4. настройка клиента форм
Когда конечный пользователь запускает Web приложение Oracle, с сервера приложений в его обозреватель загружается клиент форм (и файлы родственных Java-классов). В процессе работы пользователя с приложением, по мере необходимости могут подгружаться файлы дополнительные Java-классы. Существует возможность управления тем, как файлы классов будут загружаться в обозреватель пользователя. Есть два метода загрузки:
Инкрементная (Increment). Является настройкой по умолчанию и обеспечивает загрузку только тех файлов с Java-классами, которые необходимы для отображения начального состояния приложения.
Архивная (Bundled). В момент запуска приложения, на клиентскую машину загружаются один или несколько архивов с Java-классами. Преимущество архивов в том, что каждый архив загружается за одну сетевую транзакцию. Для использования этого варианта необходимо указать имена соответствующих JAR-файлов в HTML файле приложения.
Клиенты. Клиентская часть системы практически не требует настройки, так как базируется на ⌠тонком клиенте■ - Java-совместимом Web-обозревателе. Необходимо использовать обозреватель, имеющий поддержку JDK (Java Development Kit √ стандарт Java) версии 1.1.x или выше.
3.2 Технология доступа к базам данных на стороне сервера с использованием механизма CGI
В соответствии с идеологией CGI-интерфейсов, вся функциональность размещается на сервере приложений. Ее реализует один или несколько CGI-скриптов, которые получают от Web-сервера запрос пользователя. Результатом выполнения скрипта является HTML-документ, содержащий информацию из базы данных. Этот документ передается Web-серверу, а затем отправляется в клиентский обозреватель по протоколу HTTP. Дополнительно, в результате выполнения скрипта возможно изменение информации в базе данных.
Для реализации взаимодействия "клиент-сервер" важно, какой метод HTTP запроса использует клиентская часть при обращении к WWW серверу. В общем случае, запрос - это сообщение, посылаемое клиентом серверу. Первая строка HTTP запроса включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса (URI - Uniform Resource Identifier), и используемую версию HTTP-протокола. Применительно к CGI, клиентская часть использует методы запроса POST и GET. Метод POST применяется для запроса серверу, чтобы тот принял информацию, включенную в запрос, как относящуюся к ресурсу, указанному идентификатором ресурса. Метод GET используется для получения любой информации, идентифицированной идентификатором ресурса в HTTP запросе.
Согласно спецификации, CGI определяет 4 информационных потока:
Переменные окружения;
Стандартный выходной поток;
Стандартный входной поток;
Командная строка.
Переменные окружения
Ниже приводится значение некоторых переменных, объявленных в стандарте CGI:
CONTENT_LENGTH - значение этой переменной соответствует длине стандартного входного потока в символах;
QUERY_STRING - значение этой переменной соответствует строке символов следующей за знаком "?" в URL соответствующему данному запросу. Эта информация не декодируется сервером.
2. Стандартный вывод
CGI - модуль выводит информацию в стандартный выходной поток. Этот вывод может представлять собой или документ, сгенерированный cgi-модулем, или инструкцию серверу, где получить необходимый документ. Обычно cgi-модуль производит свой вывод. Преимущество такого подхода в том, что cgi-модуль не должен формировать полный HTTP заголовок на каждый запрос.
Вывод cgi-модуля должен начинаться с заголовка содержащего определенные строки и завершаться двумя символами CR (0x10). Любые строки не являющиеся директивами сервера, посылаются непосредственно клиенту. На данный момент, CGI спецификация определяет три директивы сервера:
Content-type
MIME или тип возвращаемого документа. Например:
Content-type: text/html <CR><CR>
сообщает серверу, что следующие за этим сообщением данные - есть документ в формате HTML;
Location
указывает серверу, что возвращается не сам документ, а ссылка на него. Если аргументом является URL, то сервер передаст указание клиенту на перенаправление запроса. Если аргумент представляет собой виртуальный путь, сервер вернет клиенту заданный этим путем документ, как если бы клиент запрашивал этот документ непосредственно.
Status
задает серверу HTTP/1.0 строку-статус, которая будет послана клиенту в формате: nnn xxxxx
где: nnn - 3-х цифровой код статуса
ххххх - строка причины
Например: HTTP/1.0 200 OK
Server: NCSA/1.0a6
Content-type: text/plain
<динамически генерируемый текст сообщения3. Стандартный входной поток
В случае метода запроса POST данные передаются как содержимое HTTP запроса и будут посланы в стандартный входной поток. Данные передаются cgi-модулю в следующей форме:
name=value&name1=value1&...&nameN=valueN
где name - имя переменной,
value - значение переменной,
N - количество переменных
На файловый дескриптор стандартного потока ввода посылается CONTENT_LENGTH байт. Так же сервер передает cgi-модулю CONTENT_TYPE (тип данных). Сервер не посылает символ конца файла после передачи CONTENT_LENGTH байт данных или после того, как cgi-модуль их прочитает. Переменные окружения CONTENT_LENGTH и CONTENT_TYPE устанавливаются в тот момент, когда сервер выполняет cgi-модуль. Таким образом, если в результате исполнения формы с аргументом тега FORM - METHOD="POST" сформирована строка данных firm=МММ&price=100023, то сервер установит значение CONTENT_LENGTH равным 21 и CONTENT_TYPE в
application/x-www-form-urlencoded, а в стандартный поток ввода посылается блок данных.
В случае метода GET, строка данных передается как часть URL.
Например
http://host/cgi-bin/script?name1=value1&name2=value2
В этом случае переменная окружения QUERY_STRING принимает значение
name1=value1&name2=value2
... Java, JavaScript и встроенные в сервер средства LiveConnect. Более мощными реляционными возможностями доступа к базе данных и более эффективным выполнением виртуальной Java-машины будут расширены услуги разработки приложений, обеспечиваемых в Enterprise Server 2.0,. Сервис управления. В дополнение к использованию встроенной машины каталога LDAP Enterprise Server 2.0 будет управляем через общие ...
... данных означает, что в распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов. распределённая база данные компьютерный 3 Проблемы распределенных баз данных Исходя из определения Дэйта, распределенную базу данных в общем случае можно рассматривать как слабосвязанную сетевую структуру, ...
... на будущее. DAO и RDO известны уже достаточно давно, и появление двух разных механизмов было связано с необходимостью оптимизации решения двух отдельных задач: доступа к локальным и удаленным базам данных соответственно. Однако естественное развитие вычислительных систем привело к необходимости создания единого механизма, который обеспечил бы единый подход при работе с БД различных классов. В ...
... числе на промышленных предприятиях, больше подходят клиент-серверные СУБД. Мы рассмотрим особенности таких распространенных СУБД, как Oracle и MS SQL Server. Глава 4. Язык SQL в системах управления базами данных SQL (англ. Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных ...
0 комментариев