Читаем Искусство программирования для Unix полностью

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

Java-аплеты способны открывать собственные соединения для символьных потоков обратно к серверу с целью поддержать более управляемую интерактивность. Однако Java имеет технические проблемы — данный язык может использовать только фиксированную область экрана на странице и не способен изменить часть экрана за пределами этого прямоугольника. Имеются также гораздо более серьезные проблемы, связанные с политикой (частно»? лицензирование со стороны Sun заблокировало Java-разработку и вынудило остальных с недоверием относиться к Java;

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

Кроме того, как Java, так и JavaScript могут столкнуться с несовместимостью браузеров. Сопротивление Microsoft внедрению JDK 1.2 и Swing в Internet Explorer является серьезной проблемой для Java-аплетов. Различные уровни версий JavaScript также могут нарушить работу приложения (хотя ошибки JavaScript исправляются проще). Тем не менее, часто решить данные проблемы не так сложно, как написать и внедрить нестандартный клиентский интерфейс. Более сложной проблемой является растущее число искушенных пользователей, которые по привычке отключают в своих браузерах поддержку Java и даже JavaScript из-за проблем с безопасностью и нарушения интерфейса.

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

При связывании форм подготавливается CGI-сценарий для формирования первой формой уникального идентификатора в скрытом поле второй формы, а вторая и все последующие формы передают данный идентификатор последующим элементам. Cookie-файлы достигают подобного эффекта путем аналогичным переменным окружения (подробные инструкции описаны в любой из сотен книг по CGI-npor-раммированию). В любом случае в CGI-сценарии необходимо использовать идентификатор в качестве индекса сеанса (или cookie-файлов для непосредственного сохранения состояния) и явно обрабатывать мультиплексирование сеансов.

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

Проблема управления сеансами может быть переадресована серверам приложений, таким как Zope или Enhydra, которые обеспечивают отделение сеансов и предоставляют службы аутентификации для программ внутри них. Недостаток данных программ равноценен их достоинству: они облегчают сохранение на сервере информации о состоянии по каждому пользовательскому сеансу. Хранение данных сведений может оказаться проблемой. Оно занимает ресурсы, и данную информацию необходимо удалять по истечении определенного времени, поскольку между транзакциями не существует способа точно определить, остается ли пользователь на связи.

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

Проблемой методики использования браузера в качестве универсального клиента является то, что CGI-серверы очень непросто отделить от среды браузера, поэтому может быть трудно написать сценарий или автоматизировать транзакции к серверу. Unix-ответ — трехуровневая архитектура: Web-формы, вызывающие CGI-сценарии, которые в свою очередь вызывают команды. Интерфейсом автоматизации являются команды.

Перейти на страницу:

Похожие книги

Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT