Параллелизм. Дополнительные требования

Дополнительные требования

В ходе разработки о системе ASEILM узнала другая группа заинтересованных лиц, пожелавшая объединить с ней свои данные. Никакой ясности по поводу содержания, цели интеграции и структуры этих данных поначалу не было. По результатам анализа выяснилось, что у самых разных людей хранились данные, том или иным образом связанные с данными, которые система ASEILM была призвана отслеживать. Для того чтобы максимально сократить влияние введения в ASEILM новых типов данных, разработчикам предстояло выделить в заказных компонентах уровень абстракции данных, изолировав его таким образом от биз­нес-логики. В этом случае система могла бы функционировать, не зная источни­ков и структуры хранилищ(а) данных. Уровни заказного компонента изображе­ны на рис. 18.5..

Рис. 18.5. Уровни заказного компонента

Ансамбль Java-сервлетов, удовлетворявший критериям, которым не смог соот­ветствовать ансамбль Miva, поставил новые задачи, связанные с управлением параллелизмом. Во время работы над модельным решением разработчики поня­ли, что, в отличие от ансамбля Miva, ансамбль Java-сервлетов не справляется с параллелизмом.

В документации по серверу приложений Tomcat параллелизм не упоминался вообще. Для того чтобы определить, насколько серьезна проблема, группе разра­ботчиков пришлось проанализировать потоковую модель ансамбля. В частности, требовалось изучить отношения между IIS и Tomcat и их воздействие на систему Выполнив анализ потоковой модели, разработчики предположили, что в каждом случае регистрации пользователя создается особый поток. Ыа основе этой гипо­тезы они вывели три сценария.

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

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

♦ Два пользователя одновременно обращаются к системе за одними и теми же данными. Один из аспектов этого сценария — обеспечение непротиво­речивости данных в базе — является побочным продуктом решения сцена­рия 1. Поскольку доступ к бизнес-логике осуществляется в последователь­ном режиме, любое обновление предполагает непротиворечивость данных. Второй аспект — вероятность просмотра и манипуляций с устаревшими данными — выражает проблему «проталкивания» данных пользователю средствами HTTP. Разработчики решили встроить в генерируемый HTML- код функцию периодической перезагрузку текущей веб-страницы — таким образом, в рамках заданного допуска гарантируется соответствие отобра­жаемых и манипулируемых данных текущему состоянию. Это решение, которое, по большому счету, нельзя признать оптимальным, легко реализу­ется и, исходя из предполагавшейся пользовательской нагрузки, вполне допустимо.

♦ Один и тот же пользователь одновременно запускает два сеанса. Этот сце­нарий разработчики просто запретили.

Группа разработчиков сопоставила получившееся решение с конечными кри­териями оценки, которые с момента проведения первого эксперимента с Miva оставались неизменными. Убедившись в том, что ансамбль Java-сервлетов удов­летворяет их всех, группа продолжила работу над реализацией.

Решение на основе ансамбля Java-сервлетов обеспечило соответствие всем потребностям проекта, и к началу 2002 года система ASEILM была готова. Утвер­ждать правомерность принятых допущений о моделях использования еще слиш­ком рано, однако первые положительны. Стоит, впрочем, иметь в виду, что рас­сматриваемое решение не предполагает удобства масштабирования.

18.5. Заключение

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

Дата добавления: 2015-04-25