Ансамбль Java-сервлетов

Помимо ансамбля на основе Miva Empressa разработчики оформили альтерна­тивный ансамбль, основанный на Java-сервлетах. Первоочередное проведение анализа ансамбля Miva Empressa обусловливалось наличием в группе разработ­чиков ASEILM серьезного опыта работы с компонентами; следовательно, на этом направлении были сосредоточены наиболее обширные ресурсы. Несколько мень­ше ресурсов пришлось на оценку ансамбля Java-сервлетов. Поскольку исследо­вание, как и в первом случае, сводилось к операциям решения модельной задачи, три этапа удалось сохранить в неизменности.

♦ Этап 1 — проектный вопрос остался без изменений.

♦ Этап 2 — в наборе исходных критериев оценки остались все четыре критерия.

♦ Этап 3 — ограничения также не претерпели изменений.

Таким образом, новая процедура оценки началась с этапа 4, на котором (как изображено на рис. 18.4) конструируется модельное решение.

Рис. 18.4. Ансамбль JavaServer Pages

Два первых критерия в новом решении удовлетворялись теми же процессами, которые ранее были реализованы в ансамбле Miva Empressa. Поскольку прило­жение Cliarl Works пошло в состав ансамбля Java, разработчики продолжили попыт­ки исправить несоответствие протоколов HTTP/HTTPS путем введения адаптеров.

Java-сервлеты предусматривают отделение презентационных аспектов систе­мы от бизнес-логики и логики базы данных. Логика представления была ограни­чена страницами HTML, в то время как бизнес-логику и логику базы данных разработчики перенесли в сервлеты и Java beans, исполнявшиеся на сервере при­ложений Tomcat, — таким способом они обеспечили соответствие критерию 3. Кроме того, заменив Access на SQL-Server, разработчики добились возможности применения удаленного соединения, не предполагавшего вывода базы данных за брандмауэр, — итак, с критерием 4 тоже разобрались.

В процессе разработки модельного решения нового ансамбля произошли сле­дующие четыре события:

♦ Исходные критерии, как мы уже сказали, оказались недостаточными.

♦ Отдельные элементы проектного решения продемонстрировали неспособ­ность удовлетворить исходные критерии. В частности, оказалось, что со­блюдение критерия 2 («Между HTTP-сервером и веб-браузером должна быть организована безопасная передача данных по соединению HTTPS») не позволяет обеспечить безопасность системы (о том, с чем это связано, мы поговорим чуть позже).

♦ Заинтересованные лица сформулировали дополнительные требования.

♦ Новый Java-ансамбль поставил новые задачи.

Рассмотрим три последние проблемы.

Безопасность

Помимо защиты передачи данных по каналам, в пересмотре нуждалась модель аутентификации. Изначально при аутентификации пользователя на его машине в форме cookie записывался и привязывался к данному сеансу уникальный иден­тификатор. Разработчики понимали, что в случае компрометации системы безо­пасности на клиентской машине возможно получение доступа путем обмана с по­следующей компрометацией защиты серверной машины. Для защиты от таких явлений было принято решение о регистрации IP-адреса машины, его привязке к уникальному идентификатору и проверке при каждом последующем запросе.

Иногда хакеры обращаются к методике «перекрестных сценариев» (cross-side scripting). При этом они сохраняют на своей машине веб-форму и вносят в нее определенные изменения. Впоследствии, после подачи такой формы, происходит аварийный отказ сервера, и он выводит на клиентскую машину код или иную не предназначенную для вывода информацию. Стараясь предотвратить атаки по­добного рода, разработчики ASEILM определили ряд исключений.