ПараллелизмАнсамбль Java-сервлетов, удовлетворявший критериям, которым не смог соответствовать ансамбль Miva, поставил новые задачи, связанные с управлением параллелизмом. Во время работы над модельным решением разработчики поняли, что, в отличие от ансамбля Miva, ансамбль Java-сервлетов не справляется с параллелизмом. В документации по серверу приложений Tomcat параллелизм не упоминался вообще. Для того чтобы определить, насколько серьезна проблема, группе разработчиков пришлось проанализировать потоковую модель ансамбля. В частности, требовалось изучить отношения между IIS и Tomcat и их воздействие на систему Выполнив анализ потоковой модели, разработчики предположили, что в каждом случае регистрации пользователя создается особый поток. Ыа основе этой гипотезы они вывели три сценария. ♦ Два пользователя одновременно обращаются к системе за разными данными. После разделения заказного компонента на уровни бизнес-логики и абстракции данных было принято решение о кэшировании на последнем отдельных данных. Таким образом, при инициализации данные извлекались бизнес-логикой из базы данных, проходя при этом через уровень абстракции данных, и впоследствии обслуживались средствами бизнес-логики. Разработчики ne предпринимали никаких действий, направленных на организацию многопоточности бизнес-логики. В ситуации одновременного обращения двух пользователей к бизнес-логике она рассматривалась как критическая секция и пользовательский доступ к ней организовывался последовательно. Поскольку все значимые данные ОЗУ-резидентны, любой запрос выполняется быстро, и неприемлемая продолжительность ожидания фиксируется только при обработке многочисленных одновременных запросов. Учитывая условия использования, одновременные запросы обрабатываются в ограниченном количестве. ♦ Два пользователя одновременно обращаются к системе за одними и теми же данными. Один из аспектов этого сценария — обеспечение непротиворечивости данных в базе — является побочным продуктом решения сценария 1. Поскольку доступ к бизнес-логике осуществляется в последовательном режиме, любое обновление предполагает непротиворечивость данных. Второй аспект — вероятность просмотра и манипуляций с устаревшими данными — выражает проблему «проталкивания» данных пользователю средствами HTTP. Разработчики решили встроить в генерируемый HTML- код функцию периодической перезагрузку текущей веб-страницы — таким образом, в рамках заданного допуска гарантируется соответствие отображаемых и манипулируемых данных текущему состоянию. Это решение, которое, по большому счету, нельзя признать оптимальным, легко реализуется и, исходя из предполагавшейся пользовательской нагрузки, вполне допустимо. ♦ Один и тот же пользователь одновременно запускает два сеанса. Этот сценарий разработчики просто запретили. Группа разработчиков сопоставила получившееся решение с конечными критериями оценки, которые с момента проведения первого эксперимента с Miva оставались неизменными. Убедившись в том, что ансамбль Java-сервлетов удовлетворяет их всех, группа продолжила работу над реализацией. Решение на основе ансамбля Java-сервлетов обеспечило соответствие всем потребностям проекта, и к началу 2002 года система ASEILM была готова. Утверждать правомерность принятых допущений о моделях использования еще слишком рано, однако первые положительны. Стоит, впрочем, иметь в виду, что рассматриваемое решение не предполагает удобства масштабирования. 18.5. Заключение Атрибуты качества можно реализовать даже в такой системе, которая по большей части состоит из коробочных компонентов, и, соответственно, заложенные в ней механизмы проектирования и взаимодействия не поддаются контролю со стороны архитектора. С другой стороны, принципы реализации атрибутов качества в подобного рода системах сильно отличаются от тех, что приняты в отношении специально разработанного кода. Процесс выявления требований в таком случае теряет привычную жесткость — компоненты, имеющиеся на рынке, за счет корректности требовании повышают общее качество коммерческого решения, С другом стороны, важнейшие требования в процессе оценки осуществимости ансамблей компонентов должны выступать в качестве критичных ограничений. Необходимо учитывать возможность возникновения непредвиденных обстоятельств, а но мере расширения и усложнения важнейших требований предусматривать резервное решение в виде специальной разработки. Дополнительная литература Материалы по методикам и процессам, рассмотренным в этой главе, содержатся в издании [Wallnau 02]. Вопросы внедрения коммерческих коробочных продуктов — их квалификация, связанные с ними риски и миграция — раскрываются на сайте http://www.sei.cmu.edu/cbs/. Архитектурное несоответствие и методы его исправления подробно рассмотрены в работе [Garlan 95]. Глава 19
|
