Типовые решения входных контроллеров

Существует два типовых решения проблемы организации входных контроллеров. Наи­более общий подход состоит в создании объекта входного контроллера для каждой страни­цы Web-сайта. В простейшем случае подобный контроллер страниц (Page Controller) можно оформить в виде страницы сервера, сочетая в нем функции представления и вход­ного контроллера. Во многих ситуациях, однако, легче выделить входной контроллер в самостоятельный объект. Нередко взаимно однозначного соответствия между контролле­рами страниц и представлениями не существует. Точнее говоря, следует иметь контроллер страниц для каждого действия, где действием является кнопка или гиперссылка. В боль­шинстве случаев действия соответствуют страницам, но бывает и так, что ссылка, на­пример, указывает на разные страницы в зависимости от определенного условия.

На входной контроллер возлагаются две основные обязанности: обработка HTTP-запроса и принятие решения о том, что с ним делать дальше, которые зачастую имеет смысл разделить, поручив первую функцию странице сервера, а вторую — вспомогатель­ному объекту. В то же время типовое решение контроллер запросов (Front Controller) предусматривает использование единственного объекта, предназначенного для обработ­ки всех запросов. Обработчик интерпретирует полученный адрес URL, определяет, с ка­кого рода запросом он имеет дело, и создает отдельный объект для дальнейшего обслу­живания запроса. Таким образом удается централизовать деятельность по обработке всех HTTP-запросов в рамках единого объекта и избежать необходимости изменения конфи­гурации Web-сервера в случае модификации структуры действий сайта.

Дополнительные источники информации

В большинстве книг по Web-технологиям найдется пара глав, посвященных удачным образцам организации Web-серверов (подобная информация, однако, часто изобилует не­нужными деталями). Прекрасный пример Java-проекта обсуждается в главе 9 руководства [9]. Лучший источник информации о других типовых решениях — книга [3]; многие из них не привязаны к Java и носят универсальный характер. Терминология, касающаяся разделе­ния функций входного контроллера и контроллера приложения, заимствована из [25].

Глава 5 Управление параллельными заданиями

Мартин Фаулер и Дейвид Райе

Параллельное (concurrent) выполнение операций — одна из наиболее сложных дис­циплин в области разработки программного обеспечения. Проблемы параллелизма возникают всякий раз, когда, скажем, несколько процессов или потоков вычислений предпринимают попытки манипуляций одними и теми же элементами данных. Вос­приятие множества параллельных операций затруднено, поскольку перечислить все возможные сценарии развития событий, способные привести к тем или иным непри­ятностям, крайне сложно. Что бы вы ни делали, всегда кажется, что какие-то вещи упущены. Более того, параллельные операции трудно тестировать. Всем нам нравятся средства автоматического тестирования, сопровождающие процессы разработки про­граммного обеспечения от начала и до конца, но найти тесты, которые смогли бы убе­дить в достаточной надежности параллельного кода, практически невозможно.

Забавно и парадоксально, что с возрастанием степени параллелизма операций в кор­поративных приложениях разработчики все меньше заботятся о сопутствующих проблемах. Причиной подобного легкомысленного отношения служит наличие готовых подсистем — диспетчеров транзакций. Модель транзакций позволяет избежать массы трудностей: если вы манипулируете данными внутри транзакции, будьте уверены, что ничего плохого с ними не случится.

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

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

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

На протяжении всей главы для иллюстрации концепций параллелизма приводятся примеры из области, которая, вероятно, вам хорошо знакома: речь идет о системах кон­троля версий исходного кода, которые применяются командами разработчиков для ко­ординации вносимых изменений. (Между прочим, если вы не осведомлены о подобных системах, то не сможете плодотворно работать над корпоративными приложениями.)