Веб-приложения и настольные приложения

Конечно, конкретные функциональные возможности этих систем отличаются — PyMailCGI реализует лишь подмножество возможностей PyMailGUI — но они близки достаточно, чтобы их можно было сравнивать. На базовом уровне в обеих системах для получения и отправки почты через сокеты используются модули Python поддержки протоколов POP и SMTP. Но в представляемых ими альтернативах реализации есть важные отличия, о которых следует знать при создании веб-систем:

Издержки производительности

Се ти медлен нее, чем CPU. В настоящей реализации скорость или полнота PyMailCGI не идут ни в какое сравнение с PyMailGui. В Py- MailCGI каждый раз, когда пользователь щелкает на кнопке отправки формы, запрос передается через сеть (в случае использования имени сервера «localhost» запросы передаются другой программе, выполняющейся на том же компьютере, но эта конфигурация используется только во время тестирования). Более точно, каждый запрос пользователя влечет расходы, связанные с передачей по сети, вызов каждого обработчика может выливаться в запуск нового процесса или потока выполнения на сервере, параметры поступают в виде текстовых строк, требующих синтаксического анализа, а отсутствие на сервере информации о состоянии при переходе к новой странице означает, что почту приходится часто перезагружать или использовать механизмы сохранения информации о состоянии, которые существенно сложнее и медленнее, чем простое обращение к памяти.

Напротив, действия пользователя в PyMailGUI производят вызовы функций в том же процессе вместо передачи по сети и ветвления процессов, а информация о состоянии легко сохраняется в переменных процесса. Даже при наличии сверхбыстрого соединения с Интернетом CGI-система на стороне сервера проигрывает в скорости программе на стороне клиента. По правде говоря, некоторые операции tkinter тоже передаются обрабатывающей их библиотеке Tcl в виде строк, которые нужно анализировать. Со временем это может измениться; к тому же здесь производится сравнение CGI-сценариев с библиотеками графического интерфейса в целом. Вызовы функций наверняка всегда будут превосходить в скорости сетевые взаимодействия.

Некоторые из этих узких мест могут быть устранены ценой увеличения сложности программы. Например, некоторыми веб-серверами используются потоки выполнения и пулы процессов, чтобы свести к минимуму количество операций создания процессов для сценариев CGI. Кроме того, часть информации о состоянии можно передавать вручную со страницы на страницу в скрытых полях формы, параметрах URL и cookies, а в промежутке между страницами состояние можно сохранять в базе данных, допускающей одновременный доступ, чтобы свести к минимуму необходимость повторной загрузки почты. Но нельзя пройти мимо того факта, что переправка событий сценариям через сеть происходит значительно медленнее, чем прямой вызов функций Python. Это может иметь большое значение для некоторых приложений, хотя и не для всех.

Издержки сложности

Работать с размет кой HTML не удобно. Поскольку PyMailCGI должна генерировать разметку HTML, чтобы взаимодействовать с пользователем через веб-броузер, она более сложна (или, по крайней мере, менее удобочитаема), чем PyMailGUI. В некотором смысле сценарии CGI встраивают код разметки HTML в программный код Python; механизмы шаблонов, такие как PSP, часто используют противоположный подход. В любом случае в конечном итоге получается смесь двух очень разных языков, поэтому создание интерфейса с помощью HTML в сценарии CGI может оказаться далеко не таким простым делом, как вызовы функций из библиотек графического интерфейса, таких как tkinter.

Посмотрите, например, сколько труда мы приложили для экранирования HTML и URL в примерах этой главы; такие ограничения заложены в природе HTML. Кроме того, внесение изменений в систему с целью сохранения списка загруженной почты в базе данных в промежутке между обращениями к страницам приведет к еще большему усложнению системы, основанной на CGI, (и, вероятнее всего, придется привлечь еще один язык, такой как SQL, пусть даже и в самых низкоуровневых функциях). Использование защищенного протокола HTTP могло бы уменьшить сложности, обусловленные необходимостью реализации шифрования, но с его введением появляются новые сложности настройки сервера.

Издержки функциональности

Язык HTML не обла да ет бо га тыми выра зи тель ны ми возмож но стя- ми. Язык HTML служит переносимым способом определения простых страниц и форм, но слаб или бесполезен для описания более сложных интерфейсов пользователя. Поскольку сценарии CGI создают интерфейсы пользователя путем отправки разметки HTML броузеру, они весьма ограничены в отношении конструкций, используемых интерфейсом пользователя. Попробуйте, например, реализовать программу обработки изображений и анимации в виде сценариев CGI: язык HTML не пригоден за пределами заполняемых форм и простых взаимодействий.

Можно создать сценарии CGI, генерирующие графические изображения. Эти изображения могут создаваться и сохраняться на сервере во временных файлах с именами, сконструированными из идентификатора сеанса и используемыми в тегах <IMG> в сгенерированной разметке HTML ответа. Для броузеров, поддерживающих такое понятие, как встроенные изображения, графику можно было бы встраивать непосредственно в теги HTML, в формате Base64 или подобном. Однако любой из этих приемов существенно сложнее, чем использование изображений в библиотеке tkinter. Кроме того, приложения обработки изображений и анимации, для которых большое значение имеет скорость реакции на действия пользователя, в принципе невозможно реализовать с применением таких протоколов, как CGI, требующих выполнения сетевых взаимодействий для каждой операции. Например, интерактивные сценарии обработки изображений и анимации, которые мы написали в конце главы 9, невозможно реализовать в виде обычных серверных сценариев.

Это как раз то ограничение, для преодоления которого были придуманы апплеты Java — программы, которые хранятся на сервере, но по требованию загружаются для выполнения у клиента и предоставляют доступ к полноценной библиотеке графического интерфейса для создания более богатых интерфейсов пользователя. Тем не менее программам, строго ограниченным стороной сервера, внутренне присущи ограничения языка HTML.

Кроме того, клиентские программы, такие как PyMailGUI, также обладают доступом к таким инструментам, как многопоточная модель выполнения, которую сложно имитировать в CGI-приложениях (потоки выполнения, порождаемые сценарием CGI, не могут существовать дольше самого сценария или дополнять отправленный им ответ). Модели веб-приложений с постоянными процессами, например FastCGI, могут предоставлять дополнительные возможности в этом направлении, но общая картина выглядит не так четко, как на стороне клиента.

Веб-разработчики прикладывают немалые усилия для имитации возможностей клиентских приложений — смотрите обсуждение модели RIA и HTML 5 далее — но эти усилия связаны с дополнительными сложностями, использованием модели программирования на стороне сервера почти на пределе возможностей и применением самых разнообразных веб-технологий.

Преимущества переносимости

Все, что вам нужно, — это броузер на стороне клиента. Преимущество программы PyMailCGI заключается в том, что она действует в Сети и с ней можно работать на любом компьютере, где есть вебброузер, независимо от наличия на нем Python и tkinter. Это значит, что Python должен быть установлен только на одном компьютере — на веб-сервере, где в действительности располагаются и выполняются сценарии. Фактически это самое значительное преимущество модели веб-приложений. Если известно, что пользователи вашей системы имеют веб-броузеры, установка ее становится тривиально простой. Вам все еще необходим Python на сервере, но удовлетворить это требование значительно проще.

Если вы помните, Python и tkinter тоже весьма переносимы — они выполняются на всех основных оконных системах (X11, Windows, Mac), но для выполнения клиентской программы Python/tkinter, такой как PyMailGUI, вам потребуются на машине клиента собственно Python и tkinter. Иное дело приложения, построенные как сценарии CGI: они будут работать в Macintosh, Linux, Windows и в любой другой системе, которая позволяет отображать веб-страницы HTML. В этом смысле HTML становится для веб-сценариев своего рода переносимым языком конструирования графических интерфейсов, интерпретируемым веб-броузером, который сам является графическим интерфейсом для отображения других графических интерфейсов. Вам даже не нужен исходный программный код или байт-код самих сценариев CGI — они выполняются на удаленном сервере, существующем где-то в сети, а не на компьютере, где работает броузер.

Требования к выполнению

Но вам нужен бро узер. То есть сама природа веб-систем может сделать их бесполезными в некоторых средах. Несмотря на повсеместное распространение Интернета, многие приложения все еще выполняются в условиях, когда отсутствует броузер или нет доступа к Интернету. Возьмите, например, встроенные системы, системы реального времени или защищенные правительственные приложения. Хотя в ин тра се тях (локальных сетях без внешних соединений) вебприложения также могут иногда выполняться, однако мне приходилось работать в компаниях, где у клиентов вообще отсутствовали веб-броузеры. С другой стороны, у таких клиентов бывает проще установить на локальных компьютерах системы типа Python, чем организовать поддержку внутренней или внешней сети.

Требования к администрированию

В дей ст ви тель но сти не обхо дим еще и сервер. Системы на основе CGI вообще нельзя писать без доступа к веб-серверу. Кроме того, хранение программ на централизованном сервере создает довольно существенные административные издержки. Попросту говоря, в чистой архитектуре клиент/сервер клиенты проще, но сервер становится критически важным ресурсом и потенциально узким местом с точки зрения производительности. Если централизованный сервер выйдет из строя, вы, ваши служащие и клиенты можете оказаться лишены возможности работать. Кроме того, если достаточно много клиентов пользуется одновременно общим сервером, издержки в скорости вебсистем становятся еще более явными. В промышленных системах можно использовать дополнительные методики, такие как балансировка нагрузки и использование отказоустойчивых серверов, но все это добавляет новые требования.

На самом деле можно утверждать, что смещение в сторону архитектуры веб-сервера является отчасти движением вспять — ко временам централизованных мейнфреймов и простых терминалов. Некоторые могли бы даже утверждать, что недавно появившаяся модель облачных вы чис ле ний отчасти является возвратом к более старым вычислительным моделям. Какой бы путь мы ни выбрали, разгрузка сервера и перенос хотя бы части обработки данных на клиентские компьютеры позволяет преодолеть это узкое место.

Другие подходы

Так как же лучше всего строить приложения для Интернета — как клиентские программы, общающиеся с Сетью, или как выполняемые на сервере программы, жизнь которых проходит в Сети? Естественно, однозначного ответа на этот вопрос нет, так как все зависит от конкретных ограничений каждого приложения. Более того, ответов может быть больше, чем здесь предложено. Модели программирования на стороне клиента и на стороне сервера имеют свои достоинства и недостатки, тем не менее, для большинства стандартных проблем Веб и CGI уже предложены стандартные решения. Например:

Решения для стороны клиента

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

Другие технологии, такие как встраивание JavaScript или Python непосредственно в код разметки HTML, тоже поддерживают выполнение на стороне клиента и более богатые возможности графических интерфейсов. Такие сценарии располагаются в HTML на сервере, но после загрузки выполняются у клиента и имеют доступ к компонентам броузера через открытую объектную модель.

Новые расширения динамического HTML (Dynamic HTML, DHTML) предоставляют клиентским сценариям еще одну возможность изменять веб-страницы после их создания. А недавно появившаяся модель AJAX предлагает дополнительные способы добавления интерактивности и повышения отзывчивости веб-страниц и составляет основу модели полнофункциональных интернет-приложений (RIA), которая отмечается ниже. Все эти клиентские технологии добавляют собственные сложности, но ослабляют некоторые ограничения, налагаемые обычным HTML.

Решения по сохранению информации о состоянии

В предыдущей главе мы подробно рассматривали средства и методы сохранения информации о состоянии, и нам еще предстоит в главе 17 познакомиться с полномасштабными базами данных для Python. Некоторые серверы веб-приложений (например, Zope) обеспечивают естественную поддержку сохранения информации о состоянии в промежутке между обращениями к страницам, предоставляя объектные базы данных с одновременным доступом. В некоторых из этих систем явно используются базы данных (например, Oracle или MySQL); в других используются файлы или хранилища объектов Python с соответствующей блокировкой. Кроме того, имеются механизмы объектно-реляционных отображений (Object Relational Mapper, ORM), такие как SQLObject, которые позволяют взаимодействовать с реляционными базами данных как с классами Python.

Сценарии могут также передавать информацию о состоянии через скрытые поля форм и параметры генерируемых URL, как это делается в PyMailCGI, либо сохранять ее на стороне клиента с помощью стандартного протокола cookies. Как мы узнали в главе 15, cookies представляют собой фрагменты информации, сохраняемые у клиента по запросу сервера, и отправляются обратно серверу при повторном посещении страницы (данные передаются в обоих направлениях в заголовках HTTP). Cookies сложнее, чем переменные программы, и являются чем-то спорным и необязательным, но они могут взять на себя часть задач по сохранению информации о состоянии.

Дополнительные возможности по сохранению информации предлагают альтернативные модели, такие как FastCGI и mod_python, — там, где они поддерживаются, приложения в модели FastCGI могут сохранять информацию в рамках долгоживущих процессов, а модуль mod_python предоставляет возможность сохранять данные сеанса в Apache.

Решения по созданию HTML

Сторонние расширения тоже могут отчасти уменьшить сложность встраивания HTML в CGI-сценарии Python, хотя и ценой некоторого снижения скорости выполнения. Например, система HTMLgen позволяет программам конструировать страницы как деревья объектов Python, которые «умеют» создавать разметку HTML. Имеются также другие фреймворки, предоставляющие объектно-ориентированные интерфейсы для создания потока ответа (например, объект ответа с методами). При использовании системы такого типа сценарии Python имеют дело только с объектами, а не с синтаксисом самого HTML.

Другие системы, такие как PHP, Python Server Pages (PSP), Zope DHTML и ZPT, и Active Server Pages предоставляют механизмы шаблонов, позволяющие встраивать в HTML программный код на языке сценариев, который выполняется на сервере, чтобы динамически создавать или определять части разметки HTML, отправляемой клиенту в ответ на запрос. Все они позволяют избавить программный код Python от сложностей, связанных с созданием кода разметки HTML, и отделить логику от представления, но они могут привносить свои сложности, обусловленные необходимостью смешивания различных языков.

Разработка обобщенного пользовательского интерфейса

Чтобы охватить обе модели, некоторые системы пытаются максимально отделить логику от представления, благодаря чему выбор модели практически перестает играть существенное значение — полностью инкапсулируя детали отображения, одна и та же программа способна, в принципе, отобразить и традиционный графический интерфейс, и веб-страницы на основе HTML. Однако из-за существенных различий между архитектурами этот идеал труднодостижим, и он не устраняет существенные отличия между клиентской и серверной платформами. Такие проблемы, как сохранение информации о состоянии и необходимость взаимодействия с сетью, имеют более важное значение, чем создание окон и элементов управления, и могут гораздо существеннее влиять на программный код.

Другие системы могут пытаться достичь похожих целей за счет абстрагирования визуального представления — стандартное представление в формате XML, например, можно было бы использовать для создания и графического интерфейса, и разметки HTML. Однако здесь также решается только проблема отображения и никак не затрагиваются фундаментальные архитектурные различия между клиентскими и серверными подходами.

Использованная литература:

Марк Лутц — Программирование на Python, 4-е издание, II том, 2011