Безопасная передача данных

После обработки на сервере IIS HTML-команда направляется приложению ChartWorks и заставляет его предоставить сгенерированное изображение. Таким образом, в том, что касается применения интерфейсов прикладного программи­рования ChartWorks, IIS испытывает серьезные ограничения. ChartWorks npeдусматривает API для HTTP — но не для HTTPS. Отсюда невозможность уста­новления безопасного соединения между ChartWorks и браузером. Пытаясь ре­шить эту проблему, группа разработчиков отказалась от соединения между IIS и ChartWorks по протоколу HTTPS. Действительно, поскольку оба приложения находятся на одном и том же процессоре, безопасность обеспечивается в отноше­нии доступа к процессору, н протокол передачи к этому непричастен. К сожале­нию, ничего не получилось — поскольку на веб-страницах безопасные элементы соседствовали с небезопасными, браузер либо запрещал отображение страницы, либо оповещал пользователя о небезопасном элементе соединения. Ни того ни другого допустить было нельзя.

В целях устранения обозначенных проблем разработчики расположили меж­ду IIS и ChartWorks прокси-сервер, написанный на Perl. Таким образом, безопас­ное соединение устанавливалось между IIS и прокси-сервером, который, в свою очередь, обменивался данными с ChartWorks через простое ПТТР-соединение. Схема этого решения изображена на рис. 18.3. Кроме того, в HTML-команду при­шлось внести изменения, позволяющие ей запускать прокси-сервер Perl.

Рис. 18.3. Введение прокси-сервера

Этап 5: определение конечных критериев оценки

В ходе реализации модельного решения Miva Empressa разработчикам удалось выявить дополнительные критерии оценки; в частности, они установили новые требования по атрибутам качества. По наблюдениям, проведенным в период реа­лизации, элементы графического представления слишком сильно переплетались с серверной логикой. Это обстоятельство усложняло стоявшую перед дизайнера­ми, не разбиравшимися в универсальном программировании, задачу разработки пользовательского интерфейса системы. Таким образом, в модельную задачу был введен новый критерий оценки.

♦ Критерий 3. Логика представления должна быть четко отделена от сервер­ной бизнес-логики и логики базы данных, а выражать ее следует через четко определенные интерфейсы.

Кроме того, разработчики выяснили, что база данных Access не поддерживает удаленные соединения. Обмен данными между базой данных и сервером прило­жений Miva через интерфейс ODBC был возможен лишь в случае размещения базы на одной платформе с сервером ISS. Поскольку ISS располагался за грани­цами брандмауэра SEI и лишь в таком варианте мог быть доступен сообществу пользователей, базу данных также требовалось вывести за брандмауэр. Неприем­лемость этого ограничения привела к формулированию четвертого критерия.

♦ Критерий 4. База данных должна размещаться в безопасном месте и защи­щаться брандмауэром.

Этап 6: Оценка модельного решения

Разобравшись с реализацией модельного решения и выявлением дополнитель­ных критериев оценки, архитектор приступает к оценке первого, исходя из по­следних.

Применение механизмов исправления позволяет обеспечить соответствие обо­им первоначальным критериям. В том, что ни один из новых критериев неудовлет- воряется, нет ничего удивительного. Таким образом, в отсутствие очевидных спосо­бов исправления двух новых проблем, ансамбль был признан неосуществимым.