|
Эта статья написана, как вводный курс в технологию создания web-приложений средствами Delphi6 и Kylix2. Статья носит характер учебного пособия, в котором продвигаясь от одного приложения к другому, мы будем пошагово осваивать web-технологии и web-компоненты Delphi6 и Kylix2. Поскольку многие вопросы общего характера, касающиеся возможностей создания интернет-приложений в этих системах визуального программирования были неоднократно освещены в разного рода обзорах и статьях (см. материалы на www.borland.com/kylix, www.borland.com/delphi, community.borland.com/delphi/webtech, а так же статью Андрея Боровского Программирование Интернет приложений в Borland Kylix и статью Apache Development with Kylix Server Developer), я не буду останавливаться на особенностях архитектур WebBroker и WebSnap более подробно, чем это сделано в справочной системе Delphi, а попытаюсь больше внимания уделить практическим аспектам создания работающих приложений. Надеюсь, что высокая степень детализации и многословное описание очевидного будет приятна тем, кто только осваивает Delphi и Kylix, а профессионалы меня простят за то, что эта статья написана не для них.
Некоторые замечания к представлению материала
- Поскольку на настоящий момент лишь одна web-технология для Delphi и Kylix является полностью межплатформенной, а именно технология создания CGI-приложений, то основное приложение, которое мы будем разрабатывать, будет построено на технологии CGI.
- Каждая глава разбита на две части. Первая часть посвящена очередной ступени создания приложения на Delphi, а вторая — особенности его создания и работы в Kylix.
- Операционные системы, используемые автором: Microsoft Windows 2000 (IIS) и Mandrake Linux 8.0 (Apache).
Термины
Для того, чтобы понимать, как работает web-приложение, созданное в Delphi, не нужно обладать исчерпывающими знаниями web-технологий и сетевых протоколов. Но понимание некоторых терминов, структуры сообщений, которыми обмениваются клиент и сервер, знание составных частей URL и методов выполнения HTTP-запросов необходимы.
Обмен сообщениями между клиентом и сервером
Когда вы щелкаете мышью на ссылке или другом элементе HTML-документа, формирующем ссылку, броузер конструирует запрос, в который он включает информацию о методе запроса, заголовочные поля, URI (Uniform Resource Identifier ; URI берется как часть адреса (URL) ссылки, на которой был произведен щелчок), и отсылает запрос серверу. Сервер принимает запрос, анализирует метод, которым был произведен запрос, содержимое запроса, если оно присутствует, заголовочные поля, URI, и затем формирует ответ. На содержание сформированного ответа оказывают влияние правила и ограничения, описанные в заголовочных полях, метод запроса, а так же то, был ли обнаружен идентифицирован ресурс по информации, указанной в URI. В результате формирования ответа сервер конструирует HTML-страницу либо содержимое другого типа MIME, и отправляет обратно клиенту. По результатам обработки запроса сервер генерирует код возврата (status code). Если ресурс, указанный в URI, не был найден сервером, клиенту будет возвращено сообщение об ошибке, в которое обычно в явном виде включается код результат.
URL (Uniform Resource Locator)
URL это запись, которая исчерпывающим образом определяет местоположение ресурса в сети. Эта запись состоит из несколько частей, каждая из которых имеет определенную функцию. В качестве примера рассмотрим реальный URL:
http://codecentral.borland.com/codecentral/ccweb.exe/prodcat?prodid=8&catid=4
В этой записи есть все части URL, описанные в сетевых стандартах, их название и назначение описаны в следующей таблице:
Таблица 1.1 Составные части URL
|
Часть URL |
Название |
Назначение |
|
http |
Protocol |
Определяет сетевой протокол, по которому устанавливается соединение между сервером и клиентом |
|
codecentral.borland.com |
Host |
Идентификатор имени машины, на котором расположен web-сервер |
|
codecentral/ccweb.exe |
ScriptName |
Имя серверного приложения, на которое для обработки будет передан запрос от клиента |
|
prodcat |
PathInfo |
Адрес внутри web-приложения, на который для обработки должен быть передан запрос. |
|
prodid=8&catid=4 |
Query |
Запрос, состоит из одного или нескольких имен полей и их значений. Если полей больше одного, то поля разделяются между собой символом амперсанда (&) |
Методы HTTP
HTTP/1.0 поддерживает три основных метода (согласно RFC1945):
Таблица 1.2
|
Имя метода |
Описание |
|
GET |
получить с сервера в теле ответного сообщения информацию, которая описана в URI запроса. Если URI ссылается на процесс, производящий данные, то клиент должен получить производимые процессом данные, а не исходный код самого процесса. |
|
HEAD |
идентичен методу GET, за исключением того, что с сервера приходит только метаинформация (заголовки HTTP), соответствующая ответу на запрос указанного URI, и не приходит содержимое ответа. |
|
POST |
запрашивает сервер принять от клиента информацию, содержащуюся в теле запроса. |
Кроме трех основных, в приложении к RFC1945 описываются необязательные дополнительные методы: PUT, DELETE, LINK и UNLINK
Поля заголовков
Таблица 1.3
|
Имя поля |
Описание |
|
Allow |
Перечисляет методы, поддерживаемые запрошенным ресурсом |
|
Authorization |
Содержит поля авторизации клиента, если запрашиваемый URI требует этого |
|
Content-Encoding |
Описывает метод кодирования или сжатия, который применен к содержимому ресурса, и, соответственно, который должен быть применен клиентом для декодирования содержимого ресурса при получении. |
|
Content-Length |
Размер тела сообщения |
|
Content-Type |
Тип носителя содержимого сообщения |
|
Date |
Дата и время генерации сообщения |
|
Expires |
Дата и время, после которых объект будет рассматриваться как просроченный |
|
From |
E-mail адрес человека, которому принадлежит экземпляр клиентского приложения |
|
If-Modified-Since |
Если запрошенный ресурс не изменялся со времени, указанном в этом поле, то вместо содержимого ресурса будет послан код возврата 304, "не изменен" |
|
Last-Modified |
Дата последнего изменения запрошенного ресурса |
|
Location |
URL запрошенного ресурса |
|
Pragma |
Значение, которое должно быть применено ко всей цепочке передачи сообщения. Например, указание запрещения кэшировать ресурс. |
|
Referer |
Адрес ресурса, с которого был послан запрос |
|
Server |
Тип серверного программного обеспечения |
|
User-Agent |
Тип программного обеспечения, пославшего запрос |
|
WWW-Authenticate |
Посылается клиенту в случае попытки доступа к ресурсу, закрытому паролем; содержит поля, определяющие схему авторизации и список параметров, необходимых для доступа к ресурсу |
Коды возврата (status code)
Когда клиент обращается к серверу, сервер обрабатывает запрос и по результатам обработки генерирует код возврата. Коды возврата распределены по пяти категориям: начинающиеся с 1 зарезервированы для будущего использования; с 2 — обработка завершена нормально; с 3 — коды перенаправления; с 4 — коды ошибок клиента; с 5 — коды ошибок сервера.
Всю информацию, изложенную в разделе термины, более подробно вы можете прочесть в RFC1945.
Архитектуры и типы web-приложений
Архитектуры
В Delphi web-приложение может быть создано в одной из двух архитектур: WebBroker (ей соответствует страница Internet на палитре визуальных компонентов Delphi; для того, чтобы создать приложение, нужно выполнить команду File—>New—>Other, и затем в диалоговом окне New Items на странице New выбрать ярлык мастера Web Server Application) или WebSnap (ей соответствует страница WebSnap на палитре визуальных компонентов Delphi; для того, чтобы создать приложение, нужно выполнить команду File—>New—>Other, и затем в диалоговом окне New Items перейти на страницу WebSnap). Соотношение между этими двумя архитектурами и их отличия друг от друга подробно описаны в справочной системе Delphi. Вкратце отметим, что WebSnap является расширением возможностей, надстройкой над архитектурой WebBroker, и поэтому компоненты со страницы Internet могут быть использованы в приложениях WebSnap, а компоненты со страницы WebSnap не могут работать в архитектуре WebBroker.
Типы
Создаваемое в Delphi web-приложение может быть одного из пяти типов:
- Microsoft Server DLL (ISAPI/NSAPI) — приложение создается в виде динамически связываемой библиотеки, использующей вызовы API Microsoft Internet Information Server (или API Netscape Server). DLL загружается во время первого обращения клиента по адресу, который обслуживается web-приложением, и затем все время остается в памяти для ускорения обработки запросов. Каждый запрос обслуживается отдельной нитью (thread).
- Apache Server DLL — приложение создается в виде динамически связываемой библиотеки, использующей вызовы API Apache Server. Для этого типа приложений справедливо все сказанное для ISAPI/NSAPI приложения.
- Console CGI application — приложение создается в виде консольного исполняемого файла. Веб-запрос принимается на стандартный консольный ввод, вывод информации осуществляется на стандартный консольный вывод. Для обслуживания каждого запроса создается отдельный экземпляр приложения.
- Windows CGI application — этот тип приложение введен для совместимости в приложениями Visual Basic. Это windows-приложение, для работы которого запрос от клиента должен быть записан сервером в специальный конфигурационный файл, откуда он прочитывается приложением. Затем, после обработки запроса, приложение записывает исходящую информацию в файл, из которого эту информацию считывает сервер и передает клиенту.
- Web App Debugger executable — специальный тип приложения. Сложные модули, нуждающиеся в отладке, сначала нужно создавать как Web App Debugger executable, в таком виде они включают себя элементы COM-сервера, и могут быть отлажены при помощи инструмента Web App Debugger, которое входит в состав Delphi. При этом, как и для обычного исполняемого приложения, вы можете устанавливать точки прерывания, инспектировать значения переменных, изменять их, то есть использовать все функции встроенного отладчика Delphi. Наряду с этим, Web App Debugger работает как web-сервер, позволяя отлаживать web-приложения на компьютерах, где вообще не установлен никакой из вышеупомянутых web-серверов. После отладки web-приложение может быть преобразовано к любому из остальных типов web-приложений.
Базовые элементы web-приложения
Простейшее web-приложение можно создать, не используя в явном виде ни одного компонента из палитры компонентов Delphi. Для того, чтобы web-приложение заработало, ему нужно выполнить несколько простых действий: получить от сервера адресованные ему клиентский запрос, "понять" его, и передать на сервер соответствующий ответ, который сервер затем передаст клиенту. Все эти функции выполняет web-модуль, создаваемый в результате работы мастера Web Server Application.
В Delphi выполните команду File—>New—>Other, и затем в диалоговом окне New Items на странице New выберите ярлык мастера Web Server Application. В открывшемся диалоговом окне выберите тип приложения CGI stand-alone executable. В результате будет создано приложение, внешне практически ничем не отличающееся от DataModule (рис. 1.1):
Рисунок 1.1
Несмотря на простоту, этот модуль уже несет в своих свойствах все основные функции web-приложения. Давайте посмотрим на то, каким образом устроен объект TWebModule (см. рис. 1.2):
Рисунок 1.2
Как видите, TWebModule является потомком двух классов: TDataModule и TCustomWebDispatcher. От TDataModule унаследованы функции, позволяющие объекту TWebModule быть невизульным контейнером для невизуальных компонентов. Все признаки web-приложения унаследованы от TCustomWebDispatcher. Основные "рабочие детали" механизма обслуживания web-запроса, которые входят в состав TWebModule (и TWebDispatcher) так же показаны на рис. 1.2. Когда web-сервер получает запрос от клиента, и обнаруживает в поле ScriptName URI ссылку на web-приложение, он (в случае CGI-приложения) запускает отдельную копию приложения и передает обработку запроса ему. В приложении запрос принимает объект типа TWebModule (для краткости будем упоминать только этот компонент, учитывая, что все далее сказанное так же верно и для компонента типа TWebDispatcher). TWebModule создает в памяти экземпляр объекта типа TWebRequest, и размещает в его свойствах полученный от веб-сервера запрос; одновременно создается экземпляр объекта TWebResponce. Как видно из схемы на рис. 1.2, объекты типа TWebRequest и TWebResponce являются прямыми потомками TObject, поскольку создаются динамически и существуют только во время обработки запроса web-приложением. После того, объект TWebRequest создан и запрос, полученный от сервера, размещен в его полях, TWebModule обращается к свойству PathInfo объекта TWebRequest и ищет соответствующее ему значение свойства Name у объектов типа TWebActionItem. Если поиск завершен успешно, и соответствующий запросу элемент коллекции TWebActionItems найден, то выполняется заданное для него действие. Если не удалось сопоставить запрос ни одному из имеющихся в коллекции элементов, то выполняется то действие, у которого установлено в True свойство Default. Затем TWebModule завершает формирование свойств объекта TWebResponce, и передает информацию из него в качестве ответа серверу, который в свою очередь пересылает этот ответ клиенту, приславшему запрос.
Коллекция TWebActionItem создается и заполняется элементами на этапе дизайна приложения, и затем хранится в скомпилированном модуле web-приложения, поэтому TWebActionItem и TWebActionItems являются потомками TPersistent. Именно свойства TWebActionItem, и событиe OnAction, которое наступает, когда TWebModule находит, что полученному запросу можно сопоставить тот или иной элемент из коллекции TWebActionItems лежат в основе динамической генерации содержания ответа, ради которого и создается web-приложение.
Продолжение следует…
|
